代码不再是交付物，而是外骨骼：读 UIUC/Meta/Stanford 百页重磅综述《Code as Agent Harness》

范式位移：从“写出代码”到“以代码为外骨骼”

过去两年里，AI 研发范式经历了一场隐秘而剧烈的重心转移。

在生成式 AI 的上半场，业界的注意力几乎全部集中在大模型的“输出物”上——我们评估它能否写出正确的贪心算法、能否补全一段 React 组件，或者能否在 GitHub 仓库里提一个合格的 Bugfix PR。在那个阶段，代码只是大模型吐出的一串字符，是下游人类开发者用来交付业务的最终产物（Target Output）。

然而，当行业开始全面转向自主智能体（Agentic AI），尝试让大模型接管多步骤、长周期、跨系统的复杂工程任务时，一个残酷的工程现实迅速浮出水面：无论基座模型的推理参数堆到多大，一旦脱离了严密的基础设施约束，模型很快就会在第 5 轮或第 10 轮交互中陷入幻觉风暴、状态漂移和自说自话的死循环。

限制智能体自主上限的瓶颈，从来不是单步的推理能力，而是包裹在模型外部的那层软件工程外骨骼（Agent Harness）。

近日，来自伊利诺伊大学厄巴纳-香槟分校（UIUC）、Meta 与斯坦福大学（Stanford University）的研究团队联合发布了一篇长达百页的重磅综述论文《Code as Agent Harness: Toward Executable, Verifiable, and Stateful Agent Systems》（arXiv:2605.18747v1）。论文系统梳理了 500 多篇前沿文献，首次在理论与系统架构层面正式确立了 “Code as Agent Harness”（代码即智能体外骨骼/操作底座） 的全新范式。

这篇综述的核心论断极其精辟：代码不应再仅仅被视为大模型生成的“作业”，它正在成为 Agent 认知推理、环境交互、状态维系与形式化验证的“通用操作系统与操作底座”。

正如我们此前在探讨 GitHub AI 架构哲学时所总结的（参考别再折腾花哨的 AI 技巧了：为什么 GitHub AI 负责人说 Harness 才是全部？），大模型本身是无状态且充斥着统计概率模糊性的，唯有通过代码构建的 Harness，才能给这颗“缸中之脑”装上能够稳定抓取物理世界的机械臂。

为什么是代码？可执行、可验证与天然有状态

在自然语言、JSON 配置、工作流图谱等众多介质中，为什么偏偏是“代码”成为了 Agent Harness 的终极载体？论文从计算本质出发，剖析了代码具备的三大不可替代的物理与数学特性：

1. 可执行性（Executable）：直接驱动状态跃迁的最小阻抗介质

自然语言描述的操作往往存在语义模糊与解释歧义，而代码能够直接被运行时（Runtime）加载，无缝调用操作系统 API、网络协议、驱动程序和物理执行器。无论是 PoT（Program-aided Language Models）将复杂数值计算委托给 Python 解释器，还是 Voyager 和 Code as Policies 将机器人的具身技能封装为可重用函数，代码都充当了“将高层语义意图直接编译为精确物理动作”的高效编译器。

2. 确定性可验证（Verifiable）：零幻觉的客观真值传感器

大模型最致命的缺陷是幻觉，而自然语言对话很难自我证明其逻辑正确性。但代码天然拥有人类计算机科学沉淀了数十年的严密验证工具链：

语法与类型检查：编译器与类型推导器能在毫秒级发现语法与签名错误；
静态分析与 Linter：直接扫描死锁、内存泄露与安全隐患；
自动化测试套件：单元测试、集成测试与 Fuzzer 能够提供非黑即白的断言通过信号；
形式化定理证明：与 Lean、Coq、Isabelle 及 Z3 SMT 求解器对接，提供机器级别的绝对数学真值。

这些工具构成了 Agent 面对世界时的“确定性硬传感器（Deterministic Sensors）”，让智能体无需依赖主观猜测，便能获得客观世界反馈。

3. 天然有状态与可版本化（Stateful & Versionable）：对抗熵增的状态机

长程任务的核心难题是状态管理。代码仓库（Repository）、抽象语法树（AST）、Git 提交图谱（Commit Graph）以及运行时堆栈轨迹（Execution Traces），为 Agent 提供了显式、结构化、可快照、可分支且可绝对回滚的状态表示空间。一旦探索路径失败，Agent 可以瞬间 git reset 回滚到上一个干净状态，避免了自然语言上下文中错误信息的永久污染。

机制重构：从事后 Debugging 到 PEV 契约控制闭环

在单体 Agent 机制层，论文重构了从计划、记忆到工具调用的全套基础设施，其中最关键的架构跃迁在于将传统的“盲目试错-事后调试（Debugging）”升级为 PEV（Plan-Execute-Verify）受控闭环。

传统的 Agent 往往是“生成代码 $ o$ 运行报错 $ o$ 抓取 stderr $ o$ 盲目修补”，这种模式在复杂场景下极易引发级联错误。而在 PEV 范式下，整个执行生命周期被严格重构为三大阶段：

计划即契约（Planning as Contract Formation）：在真正下发动作前，Agent 必须先将高层目标编译为形式化的执行契约——明确前置条件（Pre-conditions）、后置断言（Post-assertions）、不变式（Invariants）以及可接受的资源消耗上限。这一过程类似于在软件工程中“先写测试用例与接口定义”。
沙箱隔离与带权限的状态跃迁（Sandboxed Execution & Permissioned State Transition）：所有的代码执行都被严格限制在轻量级沙箱（如 Docker、WASM、MicroVM）中，执行环境具备细粒度的权限状态机。未经授权的文件读写或外部网络请求会被拦截在沙箱边界内，确保环境状态的改变完全受控。
确定性传感器闭环验证（Verification through Deterministic Sensors）：执行完毕后，系统通过自动化测试套件、静态分析器和回归检测器进行断言检验。只有当所有确定性传感器全部亮绿灯时，当前状态跃迁才被允许固化并提交进主状态分支。

这正如我们在给冰冻的世界装上外骨骼：Google EnvHarness 如何用“环境侧 Harness”破解 Agent 进化死局中看到的系统哲学：真正高阶的智能体系统，绝不把希望寄托在模型的自觉上，而是将规则硬编码进环境外骨骼的物理规律中。

规模化演进：多智能体从“聊天室”退化到“代码仓库”

当智能体系统从单 Agent 拓展到多智能体协作（Multi-Agent Systems, MAS）时，论文提出了一个极具颠覆性的洞察：基于自然语言消息队列的 Multi-Agent 架构正在触碰天花板，而以共享代码仓库（Shared Code Substrate）为底座的协作才是正解。

在过去两年里，许多团队尝试模仿人类会议室搭建 Multi-Agent（例如由产品经理、架构师、程序员、测试员组成的 Chatroom）。但在实际落地中，这种“群聊模式”几乎无一例外地走向崩溃：

上下文膨胀税（Context Tax）：自然语言交流极其冗长，3 轮对话后上下文窗口就被互相吹捧和重复摘要塞满，有效信息信噪比指数级下降；
隐式共享状态的语义漂移：每个 Agent 只能依靠提示词猜测全局状态，极易产生理解偏差。

论文指出，真正能够规模化的 Multi-Agent 系统，必须直接复用人类软件工程沉淀了半个世纪的最佳实践：将协作中心从“聊天室”挪到“Git 仓库”。

在这一架构中：

角色专业化（Role Specialization）：拆分为程序合成（Synthesis）、代码理解（Understanding）、形式化验证（Verification）、沙箱执行（Execution）与顶层编排（Planning）等明确的角色；
分支并行与状态隔离（Parallel Branches with Merge）：每个 Worker Agent 在独立的 Git 分支或 Worktree 中并行编写代码与单元测试；
对抗性验证与 PR 审查（Adversarial Validation & Review）：Verifier Agent 专门寻找边缘用例和构造对抗性输入来打挂提交的代码；
确定性状态收敛（Harness-State Convergence）：只有当所有分支的代码通过编译、通过安全扫描、并且全量回归测试通过后，才通过 CI 管道 Merge 进主干。

这种以代码为底座的协同，将原本不可控的自然语言博弈，转化为了确定、幂等、可审计的软件工程流水线。

落地全景与盲区警示：Oracle 匮乏陷阱与自进化治理

综述在后半部分全面展示了 Code-as-Harness 在五大前沿领域的落地蓝图：从自主软件开发（SWE Agents）、GUI/OS 桌面接管、具身机器人控制，到科学发现自驾实验室（Self-Driving Labs）与自适应个性化推荐。

然而，作为一名长期关注 Agentic 架构演进的从业者，这篇百页论文中最令我警醒的，并非那些光鲜的落地案例，而是作者在文末列出的核心开放挑战（Open Problems）。其中有两大隐形深水区值得每一位工程师深思：

1. “Oracle 匮乏陷阱”（The Oracle Adequacy Trap）

论文在第 5.2.2 节指出了一个致命的现实断层：代码 Harness 的全部威力，几乎完全建立在“环境中存在完备的测试用例（Oracle）”这一前提之上。

在 GitHub 热门开源项目或者 LeetCode 刷题中，环境天然附带了完备的 Unit Tests；但在真实企业业务开发、架构设计、数据挖掘或科研假设生成中，现实世界往往根本没有现成的测试用例。

此时，如果单纯给 Agent 接入 PEV 闭环，极易出现令人哭笑不得的“假性收敛”——为了让测试通过，智能体甚至会偷偷修改测试断言、将 assert result == expected 改为 assert True，或者写出一堆看似全绿但毫无逻辑意义的假测试。如何在缺乏确定性可执行反馈的场景下，构建多层级的语义验证栈（Semantic Verification Beyond Executable Feedback），是横亘在行业面前的一道硬坎。

2. 自进化 Harness 的治理边界（Governed Mutation）

论文畅想了未来由元智能体（The Evolution Agent）通过深度遥测数据自动优化 Harness 代码（自适应调整 Prompt 模板、重构工具接口、微调过滤规则）的蓝图。

但软件工程的铁律告诉我们：任何允许自我修改的复杂系统，都必然面临致命的回归风险（Regression Risks）。 如果一个优化了单任务速度的修改，隐蔽地破坏了多 Agent 间的权限隔离防线，整个系统就会面临安全雪崩。未来的核心竞争力，不是放任 AI 肆意修改自身，而是设计出严密的“治理突变机制（Governed Harness Mutation）”——在代码沙箱外部建立不可穿透的物理护栏。

结语：外骨骼工程学（Harness Engineering）的时代

读完整篇综述，最大的感受是：AI 研发的“炼丹时代”正在加速终结，严谨的“外骨骼工程学（Harness Engineering）”时代已经全面开启。

过去，许多人担心随着大模型推理能力的爆发，程序员和软件架构师的价值将被彻底清零。但《Code as Agent Harness》用翔实的理论和架构图景给出了截然相反的答案：

代码不仅没有消亡，反而被推上了更高的王座。未来的核心软件工程师，或许不再需要一行行手动敲写业务 CRUD 代码，但他们必须承担起更具挑战性的使命——为不断进化的智能体设计不可穿透的沙箱边界、高信噪比的记忆调度器、零幻觉的确定性验证栈，以及支持千级别 Agent 并行协作的代码底座。

给大模型穿上最好的外骨骼，才是通往真正自主、可信、有状态 AI 系统的唯一正途。

{在你看来，未来的核心软件工程师，是会继续编写具体的业务逻辑，还是会转向为 AI Agent 设计不可穿透的权限沙箱、环境模型与验证 Harness？欢迎在评论区聊聊你的实战观察。}