这项由美国伊利诺伊大学香槟分校牵头，联合Meta和斯坦福大学共同完成的综述研究，于2026年5月18日以预印本形式发布在arXiv平台，论文编号为arXiv:2605.18747v1。这是一篇系统梳理"代码作为AI智能体基础设施"这一新兴方向的综合性调查报告，汇集了数十位研究者的集体智慧，对有兴趣深入了解的读者，可通过上述编号查阅完整原文。

**研究概要**

不知道你有没有想过，今天那些令人眼花缭乱的AI助手——能帮你改代码、操控浏览器、甚至自动做科学实验的那些——到底是怎么运转起来的？它们不只是一个会聊天的程序，背后其实有一套复杂得多的"神经系统"把所有事情串联起来。

这项研究要回答的，正是这个问题的核心：在AI智能体系统中，"代码"到底扮演了什么角色？

传统上，我们认为AI的任务就是"生成代码"，就像一个程序员，你给它需求，它输出代码，完事儿。但这篇研究指出，这种理解已经严重过时了。代码早就不只是AI的"输出物"，它更像是AI智能体的"神经系统"——AI通过代码来思考、通过代码来行动、通过代码来感知世界的状态、还通过代码来和其他AI协作。

研究团队把这个新的理解框架叫做"**代码即智能体套具**"（Code as Agent Harness）。所谓"套具"，借鉴的是马具的概念——就是那套把马和马车连接起来的装备，没有它，再强壮的马也拉不动车。在AI系统中，"套具"就是把AI模型的能力和真实世界任务连接起来的那套基础设施。而这篇研究的核心论断就是：代码，正是这套套具中最关键的材料。

**一、从"写代码"到"用代码思考"：一个根本性的转变**

考虑这样一个场景：你让AI帮你解一道数学题，"计算123乘以456再减去789"。

一种方式是AI直接用语言一步步推理，就像心算一样，在脑子里"想"答案。但这种方式很不可靠，AI语言模型做数学运算时经常算错，就像让一个文科生徒手做大数位乘法，错误率相当高。

另一种方式是：AI先把这道题"翻译"成一段Python代码，比如`print(123 * 456 - 789)`，然后真正运行这段代码，让计算机给出精确答案。这就是所谓的"程序辅助推理"，代码在这里不是目标产物，而是推理过程的载体。

这个区别看似简单，背后却有深远影响。当AI把推理过程"外化"成可执行的代码，三件事发生了：第一，这段推理变得**可以被验证**——你可以直接运行代码看看结果对不对；第二，这段推理变得**可以被检查**——你可以逐行审查逻辑；第三，这段推理产生的中间状态变得**可以被保存和复用**——下次碰到类似问题可以直接调用。

研究团队把这三个特性概括为代码作为套具的核心价值：**可执行性**、**可检查性**和**有状态性**。这三条特性，是自然语言天生无法提供的。你让AI用自然语言解释推理过程，它可能说得头头是道，但你很难验证每一步是否真的正确；而代码则是严格的，跑一遍就知道对不对。

**二、套具的三个界面：AI如何通过代码感知、行动和理解世界**

研究团队把代码在智能体系统中的作用分成了三个层次，这三个层次就像人类的感官、肌肉和认知地图一样相互配合。

先说第一个层次：**代码作为推理界面**。这对应的是AI的"思考"功能。

最基础的形式就是前面说的程序辅助推理——让AI把计算和逻辑判断外包给代码执行器。但更进一步，研究者们发现代码可以充当更复杂的推理"载体"。比如，有一类方法叫"符号规划"，AI把一个复杂问题转化成形式化的逻辑约束，然后交给专门的求解器去找答案。这就好比一个建筑师不自己算结构力学，而是画好设计图，交给专业的结构工程师用专业工具计算，两人各司其职，结果反而更可靠。

更有趣的是"迭代代码推理"。在这种模式下，AI生成代码、运行代码、观察运行结果、修改代码，反复循环，就像一个真实的程序员调试代码一样。每一次运行，都给AI提供了新的信息来修正它的"假设"。还有系统用强化学习的方式训练AI，把代码运行的通过与否作为奖励信号，让AI在反复试错中学会写出更好的代码。

第二个层次：**代码作为行动界面**。这对应的是AI的"肌肉"——如何把想法变成真实世界的操作。

研究里给出了机器人控制的例子。你可能见过那种视频，一个机器人能够根据语音指令完成复杂的桌面操作。这背后，语言模型生成的不是直接的电机信号，而是一段Python脚本，调用机器人API："移动手臂到坐标X，夹取物体，移动到坐标Y，松开"。代码在这里是把高层意图翻译成可执行动作的"翻译机"。

对GUI（图形界面）操控也是同理。当AI帮你操作网页、点击按钮、填写表单时，它生成的其实是类似于`browser.click('button')`、`adb shell input tap x y`）本质上都是代码层面的交互。这意味着环境状态、智能体行动、执行结果三者都可以用代码来统一表示和验证。WebArena、OSWorld等评测基准设计的任务成功判断标准，也是由Python验证脚本来执行的，而非人工主观判断。

在**科学发现**领域，代码套具的意义上升到了哲学层面。科学方法本身——假设、实验设计、执行、观察、修正——和代码套具的PEV循环高度同构。ChemCrow（化学领域AI助手）通过工具调用接口把分子合成预测、逆合成分析、化学反应模拟等18个专业工具串联起来；Coscientist甚至通过代码控制真实的液体处理机器人完成了有机化学实验。最极端的例子是AlphaProof，它把数学证明的每一步都表达成Lean定理证明语言中的形式化步骤，让证明助手在每一步验证正确性——代码不只是工具，代码就是数学本身。

在**个性化推荐**领域，代码套具的作用在于把用户偏好状态结构化。把用户的历史行为、明确表达的偏好、系统推测的兴趣组织成一个可编辑的"偏好状态对象"，比隐式的嵌入向量更透明、更可解释。当用户说"我不喜欢这类内容了"，系统可以直接修改偏好状态，而不是等待模型通过大量负反馈慢慢"学会"。这个领域还面临独特挑战：用户满意度本身是部分可观测的，点击和购买不等于满意，而真正的长期满意更难量化，使得验证环节的难度远高于代码调试。

在**具身智能体**（机器人）领域，代码套具承担了最关键的安全边界职责。机器人操作的失败可能是沉默的——手臂向前伸但碰到了物体，没有任何报错信号，但任务却失败了，甚至可能造成物理损坏。代码套具在这里既是"翻译机"（把高层意图翻译成底层电机指令），也是"安全闸"（在执行前检查目标点是否在运动范围内、路径是否有碰撞风险）。可复用的技能库让机器人不需要每次从头学习基础动作，而是在已验证的安全技能上组合出新的复杂行为。

**七、五大悬而未决的难题**

研究在最后坦诚地列出了这个方向当前面临的核心挑战，每一个都很棘手。

第一个难题是**评估标准的不完整性**。目前最常用的评估指标是"最终任务成功率"——AI有没有解决这个问题。但这个指标太粗糙了，它把AI本身的能力、套具的设计质量、工具的可靠性、环境的稳定性全部混在一起，根本无法诊断哪个环节出了问题。研究呼吁建立针对套具本身的评估体系，包括执行轨迹的效率（用了多少次工具调用、消耗多少token）、验证信号的强度（测试覆盖率有多高）、状态一致性（AI的理解和实际状态的偏差有多大）、安全合规性（权限边界有没有被违反）等。

第二个难题是**可执行反馈的语义局限性**。代码能运行、测试能通过，不等于代码是正确的。测试套件可能不完整，静态分析可能有误报，模拟器可能与真实物理世界有差距。研究指出，未来套具需要一个"分层验证栈"——把单元测试、集成测试、性质测试、模糊测试、形式化规范、人工审查等多种验证手段组合起来，每种手段明确声明自己能验证什么、不能验证什么、以及验证结果的可信度。

第三个难题是**套具自我进化的稳定性**。让套具自动优化自身是一个诱人的方向，但风险也很大。一个看似改进了性能的套具变更，可能同时悄悄降低了安全边界，或者在罕见的边界情况下引入了新的失败模式。研究强调，每次套具变更都应该像处理安全关键系统的代码变更一样对待：有清晰的变更契约、严格的回归测试、可审计的变更理由，以及在高风险变更时的强制人工审批。

第四个难题是**多智能体共享状态的一致性**。当多个AI同时修改同一个代码库，就会遇到和分布式系统一样的经典难题：冲突、竞争、状态漂移。但代码系统中的冲突不只是文件层面的（这用Git就能处理），还有语义层面的：一个AI改了A模块的接口，另一个AI在不知情的情况下继续调用旧接口；一个AI的测试基于错误的假设，通过了但掩盖了真实的bug。研究提出需要类似数据库事务的"语义级共享状态"机制，每个AI的行动都要声明读写集、依赖关系和验证义务，冲突要在语义层面被检测和解决，而不是等到集成时才暴露。

第五个难题是**多模态套具的构建**。目前大多数代码套具处理的主要是文本——代码文件、日志、API输出。但真实世界中，GUI智能体需要理解截图，机器人需要处理摄像头画面和力传感器数据，科学AI需要解读实验图像和仪器读数。把这些视觉和物理信号纳入套具的状态管理、动作接口和验证机制，是一个远未解决的工程挑战。

**研究的深远意义**

说到底，这篇研究做的事情是给一个快速发展的技术方向提供了第一张完整的地图。它告诉我们，AI智能体的真正瓶颈不只是模型本身，更在于把模型能力连接到真实任务的那套基础设施——套具。

这对普通人意味着什么？意味着你使用的AI助手能否真正帮你完成一个复杂任务，很大程度上取决于套具的设计质量，而不只是模型有多聪明。一个有着严密计划机制、可靠记忆管理、安全工具边界和完善反馈循环的套具，能让一个普通的模型表现出超乎想象的能力；反之，套具设计粗糙，再强大的模型也会在真实任务中频繁出错。

这也意味着，随着套具工程这门学科的成熟，AI智能体的可靠性和可控性都会显著提升——不是通过训练出"更聪明"的AI，而是通过建造更好的"神经系统"把AI的智能有效地引导出来。

对于有兴趣深入探究这个方向的读者，完整的原文可以通过arXiv编号2605.18747v1查阅，研究团队还在GitHub上维护了一个相关论文的精选列表，收录了文中提到的数百篇参考研究。

**Q&A**

Q1：代码套具和普通的AI工具调用有什么区别？

A：工具调用只是代码套具的一个组成部分。代码套具是一个更完整的概念，它包含了工具调用、计划管理、记忆系统、权限边界、验证机制、执行沙箱等整套基础设施。简单说，工具调用是套具对外暴露的一个接口，而套具是让AI持续可靠工作的整个运行环境，两者的关系有点像"单个螺丝"和"完整机械结构"之间的关系。

Q2：多智能体代码系统中，如何防止多个AI互相冲突？

A：目前大多数系统采用顺序传递文件的方式，但这并不可靠。更先进的方案是引入类似数据库事务的机制——每个AI的修改行为必须声明它依赖哪些代码状态、修改了哪些内容，系统在合并修改时检测语义层面的冲突，而不只是文件层面的差异。像SyncMind这样的研究已经开始形式化定义"智能体信念状态"和"真实代码库状态"之间的偏差度量，但这仍是一个悬而未决的工程难题。

Q3：AI智能体套具的验证机制为什么不能只依赖测试通过？

A：测试只能验证你测试到的内容，测试本身的质量决定了验证的有效性。一个AI可能生成了能通过所有现有测试的代码，但测试套件设计得不完整，遗漏了重要的边界情况或安全场景。研究中提到的"测试质量检查器"（如QualityFlow系统）就是专门解决这个问题的——在用测试结果作为反馈信号之前，先评估这些测试本身是否足够可信。这就好比不能只因为考试及格就认定学生真正掌握了知识，还要检查考题本身有没有漏洞。