太空中的 Lisp：自主航天器控制的高低起伏

太空探索的历史常常通过硬件的视角来叙述——火箭、着陆器和探测车。然而，支配这些机器的软件才是最激烈的技术与政治斗争的舞台。其中一个故事是尝试将 Lisp（以其灵活性和高级抽象著称的语言）整合进 NASA 的喷气推进实验室（JPL）关键任务系统。

这是关于 Ron Garrett 的故事——一位机器人与人工智能研究员，他试图推动太空自主性的边界，并且在实现一种与当时机构文化根本冲突的编程范式时所经历的斗争。

火星自主探索的追求

1988 年，操作火星探测车的挑战被一个残酷的限制所定义：40 分钟的往返光时延。这种延迟意味着实时遥控是不可能的；当操作员看到探测车路径上的岩石并发送转向指令时，探测车可能已经撞上了。

为了解决这个问题，Garrett 和他的团队专注于提升自主水平。目标是让探测车只需给定目的地，就能自行规划路径。此工作在一系列原型上进行，包括：

虽然 NASA 大多数软件使用 C、Pascal 或 Basic 编写，Garrett 的团队却利用了 Lisp。在 1980 年代后期，Python 或 Java 还未出现，Lisp 提供的高级抽象使研究人员能够快速迭代。

Garrett 将这种方法描述为把每个问题都转化为编译器问题。对于内存受限的小型机器人，团队使用 Lisp 设计专用于机器人领域的自定义语言，然后编译为嵌入式代码。对于大型机器人，Lisp 直接运行在硬件上。

然而，这一选择遭遇了显著阻力。NASA 当时的主流观点对 Lisp 持怀疑态度，因为它的垃圾回收可能导致进程意外暂停，并且占用大量内存。在实时响应至关重要的嵌入式环境中，这被视为灾难性风险。

技术分歧常常掩盖更深层的政治冲突。在 JPL，Garrett 的研究导向小组与更传统的运营小组之间出现了领地争夺战。

传统方法依赖“低自主性”，即操作员为探测车描述一条精确路径。虽然这降低了机器人“失控”的风险，却给人类工作人员带来了巨大的运营负担。相反，Garrett 的方法则试图彻底将人类从循环中移除。

正如 Garrett 所指出的，这不仅是技术争论，更是生计的冲突。那些职责依赖于手动操作航天器的人们的基础设施，自然不愿支持一种旨在让他们的工作自动化并消失的技术。

尽管高自主性的 Lisp 方法未能用于 Sojourner 探测车，但它在 NASA 的新千年计划中获得了第二次机会。该计划旨在展示通过规模经济降低任务成本的技术。

于是诞生了 Remote Agent，一个用于 Deep Space 1（DS1）任务的自主飞行控制器。系统由多个组件组成，其中三部分使用 Lisp 编写。Garrett 的具体贡献是“执行器”，即根据输入数据和应急情况决定航天器瞬时行为的软件。

为确保可靠性，执行器使用一种自定义语言编程，旨在防止常见的多线程问题，如竞争条件和死锁。该语言的安全性得到形式化正确性证明以及在与飞行硬件相同的地面测试的充分验证。

尽管有形式化证明，Remote Agent 在为期三天的飞行实验中仍然失败。航天器距离地球 1.5 亿英里后，停止了决策。

由于系统在航天器上运行了 Lisp REPL（读取-求值-打印循环），团队拥有一种独特的能力：他们可以通过深空网络直接向机器发送 S 表达式（Lisp 代码）。在经过管理层批准和 70 米天线传输的艰苦过程后，团队请求系统状态转储。

回溯显示出竞争条件——正是该语言旨在防止的情况。故障发生的原因是，一名开发者因无法使用语言的安全构造实现特定功能，绕过安全保障调用了底层 Lisp 构造。这一“非安全”逃生口导致了死锁。

借助 REPL，团队成功手动注入事件以“解卡”系统，使任务得以完成目标。然而，这段经历留下了深刻印记。自主项目随后被取消，高级 Lisp 方法被边缘化。

回顾这段经历，Garrett 认为 Lisp 之类工具的价值不在于其普遍的优越性，而在于与用户思维方式的“阻抗匹配”。对 Garrett 来说，Lisp 将代码视为数据以及其强大抽象的方式是完美契合的，即便在 NASA 这类机构中显得格格不入。

归根结底，太空中的 Lisp 故事提醒我们，形式化证明的强度取决于其假设，而最复杂的技术方案也可能因人为错误和组织政治的组合而被打断。