当AI"大脑"不再孤立思考：伊利诺伊大学香槟分校等机构联合研究，揭示代码如何成为AI智能体的"神经系统"

这项由美国伊利诺伊大学香槟分校牵头，联合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('#submit-button')`这样的代码指令。代码既是行动本身，也是行动的记录——你可以事后审查AI的每一步操作。

有一类特别有意思的系统叫做"终生技能库"，以著名的Voyager系统（在Minecraft游戏中自主探索的AI）为代表。AI在执行任务过程中，会把成功完成子任务的代码片段存储起来，形成一个可复用的"技能库"。下次碰到类似情况，直接调用之前学会的技能，而不需要从头再来。这就好比一个人学会了骑自行车，这个技能就永久保存在肌肉记忆里，不需要每次都重新学。

第三个层次：**代码作为环境建模界面**。这对应的是AI的"认知地图"——如何理解和追踪自己所处的世界状态。

这是最抽象但也最重要的一层。传统AI系统面临的一大痛点是：世界的状态是"不透明"的，AI只能通过文本描述或截图来感知环境，无法直接"摸"到世界的状态结构。但如果用代码来表示环境——比如用程序数据结构来表示网页DOM树，用代码仓库来表示软件项目状态，用可运行的物理模拟器来表示机器人的工作环境——那么AI就拥有了一个可以直接查询、修改和验证的"世界模型"。

SWE-bench（一个测试AI解决真实GitHub问题的著名基准测试）就是这种思路的体现：整个代码仓库、测试套件、运行环境，都是AI可以交互的"世界"，而任务的成功与否由能否通过测试来客观判断，没有任何模糊性。

**三、让AI"保持可靠"的四大机制：计划、记忆、工具和反馈**

光有好的界面还不够。一个真实的工程项目可能需要AI工作几个小时，完成几十甚至几百个步骤。在这么长的执行过程中，如何保持可靠性？研究总结了四大核心机制。

先来说**计划**。AI的计划不只是"想好了再做"，在套具视角下，计划本身就是一种程序化的控制对象。

最简单的计划方式是线性分解：把一个大任务分成有序的步骤，然后逐步执行。比如修复一个软件bug，可以分解为"理解报错信息→定位问题代码→分析原因→设计修复方案→实现修改→运行测试"。

更复杂的是基于结构的计划，比如根据代码仓库的依赖图来规划修改顺序——改了A文件可能影响B和C，所以要先改B，再改A，最后测试C。这种计划利用了代码本身的结构信息来指导行动顺序。

还有基于搜索的计划，类似于棋手思考几步棋：AI先"想象"几种可能的执行路径，评估每条路径的可行性，然后选择最优的那条。蒙特卡洛树搜索（一种游戏AI常用的算法）被应用于此类规划，让AI在执行之前就能"模拟"出多种可能的结果。

更前沿的是把计划本身变成一个"合同"——在开始执行之前，AI要明确声明它计划修改哪些文件、预计满足哪些条件、如何验证任务完成。这个合同成为后续执行的约束，防止AI"走偏"。

说完计划，来看**记忆**。对于需要处理整个代码仓库的AI来说，上下文窗口（AI一次能"看到"的信息量）根本装不下所有内容。记忆机制解决的就是这个问题。

研究区分了几种不同类型的记忆。"工作记忆"是AI当前任务中需要时刻在场的信息，比如当前正在修改的文件、最近运行失败的测试结果、待办步骤列表。"语义记忆"是代码仓库本身提供的结构化知识，通过检索增强的方式，AI可以按需查询"这个函数在哪里定义"、"这个类被哪些模块使用"等问题。"经验记忆"则是跨任务积累的经验，比如"上次遇到这类错误，用了XX方法解决"，让AI在面对新任务时能借鉴历史经验。"长期记忆"关注的是经过验证的、可信赖的知识沉淀，而非简单地把历史记录堆积起来。

上下文压缩和状态迁移是支撑这一切的工程技术。当对话历史太长时，需要把不重要的内容压缩成摘要，把完整的执行日志归档到外部存储，让AI在有限的"注意力"窗口内始终保持对任务的清晰认知。

接着说**工具使用**。代码智能体不是孤立运行的，它需要调用各种外部工具：代码检索工具、代码编辑器、测试运行器、静态分析工具、API调用接口……工具使用是AI连接真实世界能力的关键渠道。

研究把工具分成四类。面向功能的工具帮助AI填补知识缺口，比如API搜索工具帮助AI找到正确的库函数，避免"幻觉"出根本不存在的接口。面向环境交互的工具让AI能够直接操作代码仓库，在文件系统里游走，运行命令，读取输出。面向验证的工具是质量守门人，测试结果、编译错误、静态分析警告都是这类工具的产出，给AI提供客观的反馈信号。面向工作流编排的工具则是"指挥中心"，管理多个工具的调用顺序和权限边界，确保整个执行流程有条不紊。

研究特别强调了"工具生命周期控制"的重要性——不是说AI想调用什么就调用什么，而是套具要在工具调用前进行权限检查、参数验证，在调用后对输出进行清理和归档。工具调用必须是可审查的、有权限边界的行为，而不是无约束的系统操作。

最后来说最重要的机制：**计划-执行-验证循环**（简称PEV循环）。这是把前三种机制串联起来的控制逻辑。

计划阶段，AI把任务意图外化为具体的行动合同：打算修改哪些文件、预期满足什么条件、如何回滚（如果出错的话）。执行阶段，修改在隔离的沙箱环境中进行，限制了潜在的破坏范围，也保证了可重复性。验证阶段，通过确定性的传感器来判断结果——不是AI自己说"我觉得对了"，而是跑测试、看编译、运行静态分析，由机器给出客观答案。

如果验证失败，系统不只是简单地把错误信息转发给AI重试，而是根据错误类型决定下一步：是AI自己修复、换一种方法尝试、降低操作权限、还是上报给人工审核。这种多层次的失败响应机制，让整个系统在面对意外情况时更有弹性。

**四、套具如何自我进化：一个更大胆的设计思路**

研究还探讨了一个更前沿的问题：能不能让套具本身也进化？

传统做法是工程师手动设计套具的每个组件，然后固定下来。但这篇研究提出了"智能体套具工程"（Agentic Harness Engineering，AHE）的概念，核心思想是：把套具本身也当成一个可以被测量、被分析、被改进的对象。

具体来说，这需要三个要素。首先是"深度遥测"——不只记录最终任务是否成功，而是记录每一次工具调用的参数、每次决策的上下文、每次失败的详细轨迹。就像给汽车装了行车记录仪，不只知道事故发生了，还知道事故前5分钟的每个细节。

其次是"进化智能体"——一个专门分析这些遥测数据的元级AI，它的任务不是解决具体问题，而是从大量执行轨迹中发现套具的系统性缺陷。比如发现"每次遇到这类任务，AI都会在第三步卡住，原因是检索工具返回的内容太多太杂"，然后提出改进建议：精简检索策略，或者增加一个结果过滤层。

第三是"受治理的套具变更"——对套具的改动不是随意的，每次变更都需要在隔离环境中测试、通过回归测试套件验证不破坏已有功能，对于涉及权限边界的变更还需要人工审批。这就好比软件代码的版本管理，套具的每次迭代都是可追溯的、可回滚的。

OpenAI、Anthropic和LangChain等业界领先机构的工程实践都印证了这一思路：真正可靠的AI智能体，需要显式的套具循环、工具契约、执行轨迹回放、评估套件和受控的执行边界。

**五、从一个AI到一群AI：多智能体如何共享同一套套具**

当任务复杂到单个AI无法胜任时，就需要多个AI协作。研究专门用一大章节探讨了这种情况下套具的变化。

多个AI协作面临三大挑战：第一，单个AI的上下文窗口装不下整个代码仓库加上完整的执行历史；第二，不同AI各有专长，让一个通才什么都干不如让专才各司其职效率更高；第三，没有独立的审查机制，一个AI很难可靠地检查自己的错误。

研究梳理了多智能体代码系统中常见的角色分工。负责生成代码的"程序合成智能体"是最基础的，消费规范和反馈，产出代码实现。负责理解代码库结构的"程序理解智能体"不写代码，但负责读懂现有代码，告诉其他智能体"这个功能在哪里"、"改这里会影响哪些地方"。负责评估代码质量的"验证智能体"生成测试用例、运行静态分析、检查安全漏洞，像一个独立的质检员。负责直接与运行时交互的"执行智能体"运行测试、读取输出、报告结果。负责任务分解和资源调度的"规划智能体"把大任务分配给合适的工作智能体。

这些角色之间的交互方式也有多种形态。"协作合成"是两个智能体像结对编程一样共同构建代码，一个提出方案，一个实现，相互补充。"批评与修复"是最常见的模式，验证智能体给出反馈，合成智能体根据反馈修改，反复迭代。"对抗验证"更激进一些，有专门的智能体尝试"攻破"生成的代码——用模糊测试、边界输入去触发崩溃，从而发现人工测试难以发现的漏洞。"推理辩论"是多个智能体对同一个问题提出不同见解，最终通过投票或综合形成共识。

特别值得关注的是工作流拓扑的演进。最早的多智能体系统（如ChatDev、MetaGPT）使用固定的"瀑布流"拓扑——设计→编码→测试，一步一步顺序进行，简单可控。后来发展出带有反馈回路的循环拓扑，测试失败了就回到编码阶段重来。更先进的系统开始根据任务复杂度动态调整参与智能体的数量，甚至让套具的拓扑结构本身也成为可优化的对象——通过分析执行日志，自动重构哪个智能体应该在什么时候与哪个智能体交互。

研究特别指出了一个"中心差距"：目前大多数多智能体系统的共享状态还是隐式的——智能体们通过传递文件副本来交流，没有一个正式的、可查询的共享状态表示。这导致了一个根本性问题：一个智能体对代码库状态的理解，可能和实际的代码库状态悄悄地"漂移"，而没有任何机制能及时发现和纠正这种漂移。形式化的共享套具状态表示，是未来多智能体系统走向真正可靠的关键所缺失的一环。

**六、代码套具在五大应用领域的真实面目**

研究不只是讲概念，还详细梳理了代码套具在五个具体应用领域的表现形态。

在**代码助手**领域，这一演变最为明显。从最初的代码补全（给几行上下文，预测下一行），到今天的完整工程智能体（可以处理整个代码仓库、运行测试、提交Pull Request），中间发生的核心变化就是套具的扩展。Claude Code、Codex等系统展示了一个完整的"可执行开发套具"：包含本地文件编辑权限、命令执行能力、测试运行器、审批边界、上下文隔离、日志记录、人工审核门控……整个开发循环被套具化为一套可管理、可审计的流程。

研究特别提到，生产环境套具正在成为训练下一代模型的数据来源。Cursor的代码补全模型通过在线强化学习，持续从真实用户的使用轨迹中学习；OpenAI的Codex系列明确基于长程多轮编程交互训练；Anthropic也通过内部大规模使用Claude Code来收集训练信号。套具不只是模型的运行环境，它本身正在成为模型能力的孵化器。

在**GUI/OS智能体**领域，代码套具的特性表现得最为直观。因为GUI本身就是由代码渲染出来的——网页是HTML/CSS/JavaScript，移动应用是XML布局加上业务逻辑代码。智能体观察到的界面状态（无障碍树、DOM结构、截图坐标）和它执行的动作（`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系统）就是专门解决这个问题的——在用测试结果作为反馈信号之前，先评估这些测试本身是否足够可信。这就好比不能只因为考试及格就认定学生真正掌握了知识，还要检查考题本身有没有漏洞。