《Code as Agent Harness》论文精读：把代码当作 Agent 的工装
这次精读伊利诺伊大学 Jingrui He 团队领衔的综述 《Code as Agent Harness: Toward Executable, Verifiable, and Stateful Agent Systems》(arXiv
.18747)。论文 102 页、30+ 作者、横跨 UIUC / Meta / Stanford，是目前我看到对”代码在 agent 系统里到底承担什么角色”讲得最系统的一份综述。配套论文清单见 YennNing/Awesome-Code-as-Agent-Harness-Papers。下面是中文精读 —— 按论文原结构走，把核心定义、关键论点、关键图表的意思用中文重写一遍，关键术语保留英文原文。短引文标 §X.Y 出处；我自己的判断和补充用 按 引出。建议配合原文图 1（taxonomy）、图 4（mechanisms roadmap）、图 10（multi-agent overview）使用。
0. 一句话总结¶
“Code is not only an artifact generated by LLMs, but also an executable, inspectable, and stateful medium through which agents reason, act, observe feedback, and verify progress. We refer to this view as code as agent harness.” —— §1 Introduction
Harness（工装）原本指”把不稳的东西稳稳套住、让它能干活”的那层东西 —— 马具、安全带、底座。论文借用这个比喻：在 agent 系统里，代码就是把 LLM 这个”无状态、纯文本生成器”套成”长程任务执行体”的那一层。代码同时具备三种性质，正好对应工装的三种功能：
| 代码性质 | 工装功能 |
|---|---|
| Executable（可执行） | 工装能 验证 模型的意图 |
| Inspectable（可检查） | 工装能 诊断 失败、回灌反馈 |
| Stateful（有状态） | agent 的交互历史不会在步骤之间丢失 |
论文把整个领域按”代码进入 agent 循环的顺序”组织成三层：
- Harness Interface（接口层） —— §2，代码作为推理/行动/环境建模的基本接口
- Harness Mechanisms（机制层） —— §3，规划、记忆、工具、控制（PEV 循环）、自适应优化
- Scaling the Harness（规模化） —— §4，多 agent 共享代码工装
加上 §5 应用与开放问题。
1. 论文的概念创新：三种元素的区分¶
论文最值得记下来的一处概念整理在 §1：把长程 agent 系统拆成三种相互耦合的元素。
| 元素 | 含义 |
|---|---|
| Model-internal capabilities | 模型自身的推理、感知、规划、模拟、评估能力 |
| System-provided harness infrastructure | 系统预先定义的工具、API、沙箱、记忆系统、验证器、权限边界、遥测、工作流 —— 这是传统”harness engineering”的主战场 |
| Agent-initiated code artifacts | Agent 在任务执行循环里自己创建、执行、观察、修订、持久化、共享的代码对象 —— 例如回归测试、临时工具、DSL 程序、可执行工作流、可复用技能、中间程序状态 |
按： 这一刀切得很关键。以往讨论 agent 时常把后两者混在一起说”工具调用”。论文明确指出，第三类”agent 自己造的代码”是被研究得最少、但恰恰是 code as agent harness 视角的核心。Claude Code、Codex、LangChain、企业 agent 平台之所以能用，本质就是把这三类元素拼起来。
2. Harness Interface：代码作为接口（§2）¶
核心问题：harness 把无状态语言模型变成”能干活”的 agent，最基础的设计问题是 —— 模型和任务环境之间的”介质”应该是什么？
论文的回答是 代码。代码不像自然语言只是 notation，它的三大性质让它能 作为接口 工作：可执行 → 可验证模型意图；可检查 → 失败能被诊断；有状态 → 交互历史不丢。
2.1 Code for Reasoning —— 代码作为推理基底¶
把 LLM 的”中间推理”从文本搬到可执行程序里。论文把这条线分三类：
-
Program-Delegated Reasoning（程序委托式推理） PoT、PAL、MathCoder、Chain of Code 这一脉。模型生成程序，外部解释器执行。本质是 把符号、逻辑、算术运算交给可靠的执行器。论文特别提了 CodeAdapt、CodeI/O 这些新工作，表明紧耦合代码执行接口的 LLM 可以打败专门的推理模型。
-
Formal Verification & Symbolic Reasoning（神经-符号混合） 一支是 Graph-of-Thoughts、CodeSteer、VisualCoder —— 用代码作为”持久中间表示”，把推理过程做成可分支、可合并、可重用的图。另一支是 Lean / Isabelle / Coq 这类机器可验证的形式化语言，加上 DeepSeek-Prover、Kimina-Prover 等 LLM 定理证明系统。论文给出一个有意思的概括：
“Formal languages can serve not only as reasoning tools, but also as executable contracts that constrain, certify, and audit agent behavior.” —— §2.1.2
-
Iterative Code-Grounded Reasoning（迭代式代码接地推理） NExT、CodePRM、CYCLE、Self-Edit、CodeRL、RLEF、StepCoder、R1-Code-Interpreter…… 共同点是 generate-execute-verify-refine 闭环 —— 把执行反馈当作监督信号或 RL 奖励，让推理在运行时被真实状态约束。
2.2 Code for Acting —— 代码作为行动接口¶
跟”推理用代码”不同，行动用代码遇到的核心难题是 grounding（接地）：把抽象的语言输出映射到环境约束下可执行的行为 —— 包括具身极限、API 接口、环境动力学、安全要求。机器人可能尝试抓取一个本就够不着的物体，并不会抛 runtime exception。
论文强调一个常被忽视的观点：
“Executable action code is an interface to these components, not a replacement for them.” —— §2.2
代码 连接 感知模块、可行性估计、运动规划器、控制器、安全层、DOM/可访问性树、后端 API、权限系统、程序验证器；它不替代它们。
三种实现路线：
- Grounded Skill Selection（接地式技能选择）：SayCan 把语言规划与”可行性受约束的技能执行”耦合起来；KnowNo 用 conformal prediction 给 planner 加上不确定度，让 agent 在不确定时主动澄清；BOSS、LRLL、SkillVLA 让技能库本身能演化、扩展、跨任务复用。
- Programmatic Policy Generation（程序化策略生成）：Code as Policies (CaP) 是这一支的代表 —— 直接让 LLM 生成 Python 程序作为机器人控制策略。RoboCodeX 走多模态、树状代码；Code-BT 把生成的代码编译成行为树；NormCode 强调 governance and auditability，用半形式化语言强制数据隔离。
- Lifelong Code-Based Agents：Voyager 在 Minecraft 里建可持续扩展的可执行技能库；LYRA 把人类修正转成可复用的可执行技能；UI-Voyager 把这套自演化范式搬到 GUI agent；SkillsCrafter 处理”技能累积时的灾难性遗忘”。
2.3 Code for Environment —— 代码作为环境表示¶
最有意思的一节。问题是：如果 agent 只能通过 文本观察、API 返回、稀疏反馈 间接接触环境，环境状态就会”隐式、瞬时、难以验证”。
代码 作为 环境本身的解：
- Structured World Representations：ViStruct 把视觉场景表示为类/对象层级；FactoredScenes 把房间表示为 room programs；PoE-World 用大量小程序化专家组合；Code2World 把 GUI 状态预测重构为可渲染的 HTML 生成。
- Execution-Trace World Modeling：SemCoder 把代码与详细执行轨迹配对训练；CWM 直接在程序执行轨迹上原生训练大模型；WorldCoder 让 agent 显式 写出并更新可执行的世界模型（Python 程序）。
- Code-Grounded Evaluation Environments：InterCode、CRUXEval、LiveCodeBench、SWE-bench、AgentBench、CRUXEval-X、CoRe、Endless Terminals…… 共同主张：评测 agent 不靠人类打分，而是把基准本身做成可执行环境。
- Verifiable Environment Construction：SWE-smith、EnvScaler 等把”可执行环境”本身当作可程序化合成的工装产物。
“From the harness perspective, these methods make the environment interface itself an object of construction.” —— §2.3.4
3. Harness Mechanisms：让 agent 在循环里活下去（§3）¶
代码进入 agent loop 之后，工装要决定四件事：下一步执行什么、保留哪些状态、暴露哪些工具、把失败转成什么修正。论文把这一层拆成五个相互作用的机制（§3.1–§3.5）。
3.1 Planning：规划即工装的”控制器”¶
论文反复强调：规划 不是 LLM 的内部推理能力，它是 harness 的控制机制。按”控制力的实现位置”分四类：
| 类别 | 机制 | 典型 |
|---|---|---|
| Linear Decomposition | 先线性拆解再生成 | Self-Planning、WebAgent、Plan-And-Act |
| Structure-Grounded | 在仓库图/依赖图/电路图上规划 | CodePlan、GraphCodeAgent、VerilogCoder |
| Search-Based | 在思路空间/轨迹空间/代码空间搜索 | Tree-of-Code、ReThinkMCTS、SFS、Meta-Harness |
| Orchestration-Based | 系统级编排：角色专门化 / 阶段流水线 / 控制器 | AgentCoder、MapCoder、ChatDev、Cursor planner-worker、Natural-Language Agent Harness（IHR） |
值得展开的一个细节：当代实践把规划从”瞬时 prompt”提升为 filesystem-backed control object。PLAN.md、Implement.md、状态日志 —— 这些文件作为里程碑、验收标准、验证命令、恢复规则的载体，被 git 版本化、被子 agent 消费、跨 session reload，变成了一份可被人类审阅的合同。
“Planning is no longer merely an internal reasoning trace, but a filesystem-backed control object.” —— §3.1.1
3.2 Memory：状态管理层¶
论文把记忆定位为 state-management layer，不是更大的上下文窗口、也不是向量数据库 —— 是 “哪些信息留在活跃上下文、哪些被压缩、哪些被卸载到外部持久存储” 这件事的决策面。
按功能角色分六类：
| 类别 | 作用 | 典型 |
|---|---|---|
| Working Memory | 维护当前轨迹下”对下一步动作最有用”的状态 | SWE-agent、CodeMem、RepairAgent |
| Semantic Memory | 把仓库结构、调用关系、文档变成可查询证据空间 | AutoCodeRover、RepoCoder、CodeRAG |
| Experiential Memory | 跨任务的可复用经验：反思 buffer、经验卡片、record-and-replay | ExpeL、MemGovern |
| Long-Term Memory | 长程驻留 + 治理（何时写、何时压缩、何时检索） | MemGPT、MemoryOS、MemCoder、TALM |
| Multi-Agent Memory | 跨角色共享，更像协作黑板/状态图 | MIRIX、ChatDev、G-Memory |
| Context Compaction & State Offloading | 决定活跃上下文 vs. 持久任务状态的边界 | LongCodeZip、SWE-Pruner、SWEZZE |
按： 论文一句话点破：记忆的研究离不开评测可靠性。如果测试不充分、日志解析有误、benchmark 有数据泄漏，所谓”记忆增益”可能根本不反映长程行为。
3.3 Tool Use：受治理的执行接口¶
工具使用是 agent 的”动作 + 观察层”。论文把它从”附属能力”提升为 a governed interface between model intent and external systems —— 一个受治理的接口。
四类（按 harness 中的角色）：
- Function-Oriented：填知识空白（API 检索、库检索）—— ToolCoder、CodeQA、CodeRAG
- Environment-Interaction：在仓库/IDE/终端/浏览器里行动 —— CodeAgent、SWE-agent、RepairAgent
- Verification-Driven：把测试、编译器、静态分析、类型检查当作 deterministic sensors —— AgentCoder、VeriGuard
- Workflow-Orchestration：跨工具、跨角色协调 —— ToolNet、MapCoder、OpenHands
论文反复强调 tool lifecycle hooks：调用前可以做权限检查、参数校验、HITL 门控；调用后可以做输出清洗、日志压缩、状态卸载、触发验证。工具使用从”模型选了什么动作”变成”agent 执行循环里被监控的状态迁移”。
3.4 Plan-Execute-Verify (PEV) Loop —— 论文的关键贡献之一¶
这是 §3 最值得记的概念创新。论文把”反馈引导的迭代调试”重新框架成 PEV 控制环路：
- Plan：把意图变成对下一次状态迁移的显式契约。不仅有实现步骤，还有相关文件、期望不变量、验证命令、回滚点、风险操作。
- Execute：在沙箱化、权限化的环境里有界、可观察地应用变更。
- Verify：用 deterministic sensors（linter、parser、编译器、类型检查、单元测试、集成测试、fuzzer、运行时监视器、CI）评估结果。
“Reliability comes from governed state transitions, not simply from better repair prompts.” —— §3.4 总结
三个子点尤其重要：
(a) Planning as Contract Formation：一个稳健的 plan 不只是任务拆解，而是 next state transition 上的契约 —— 哪些文件可读、哪些可改、什么验证标准必须满足。AGENTS.md 风格的仓库指引、MCP 服务器注册、类型化工具 schema 让”可用动作”在执行前就可被检查。
(b) Sandboxed Execution + Permissioned State Transition：执行底座按功能聚类 —— coding sandboxes（Daytona、E2B、OpenHands）暴露文件系统/git/shell/包管理；computer-use substrates（带浏览器/桌面/LSP/IDE 状态）；durable runtimes（microVM/WASM 隔离、快照、warm pool、可恢复 session）。权限按三层切：
| Tier | 允许操作 | 是否需要 HITL |
|---|---|---|
| Read-only | 仓库浏览、检索、静态检查、日志分析 | 否 |
| Sandbox-edit | 局部 patch、运行测试、临时安装依赖（在隔离 workspace 内） | 通常否 |
| Full-access | 网络访问、凭证、部署、包发布、破坏性 fs 操作、git 历史改写 | 是 |
(c) Verification through Deterministic Sensors：编译/静态分析（低成本前置）→ 运行时信号 → 测试反馈 → 评估 harness（不只是单条测试命令，而是可重复任务分布 + 评测器逻辑 + 仿真 hook + RL 风格环境）。论文强调，与自然语言批评相比，这些传感器是确定的、可重现的，可以作为控制信号。
3.5 Agentic Harness Engineering (AHE) —— 论文的另一关键贡献¶
这一节是 §3 最具理论原创性的部分。 AHE 提出了一个 harness-level 的设计问题：如何度量并迭代”把 LLM 变成 agent 的那层软件底座”本身？
“Whereas prompt engineering changes instructions and context engineering changes what evidence is presented to the model, AHE treats the operating environment itself as the object of analysis.” —— §3.5
被纳入分析对象的：“tool schemas, planning artifacts, memory policies, retrieval strategies, sandbox configuration, verification sensors, permission tiers, routing rules, multi-agent workflows, and human-review gates”。
为什么这件事重要？ 论文给的论证非常清晰：现实里 agent 失败的大量原因 不在模型生成，而在 —— 仓库上下文缺失、工具接口脆弱、验证器太弱、token 成本失控、重试策略糟糕、权限边界错配。这些没法靠换模型解决，只能靠改 harness。
AHE 的三个支柱：
(a) Deep Telemetry —— 优化的底座¶
“Shallow log” 只记最终答案或 pass/fail。Deep telemetry 记决策过程：prompts、检索上下文、token 消耗、模型/工具延迟、工具参数、权限请求、被编辑文件、沙箱快照、命令输出、测试结果、堆栈、lint 警告、分支决策、被拒方案、人工介入、最终结果。
业界栈：Langfuse、OpenLLMetry、Promptfoo、LiteLLM 等 observability/governance 系统正在补齐这一层。Telemetry 把”哪个 harness 组件该改”从轶事调试变成 comparative diagnosis —— token 消耗 trace 揭示哪些阶段在烧预算却不改进结果；决策树 trace 揭示 agent 在哪些工具间反复横跳。
(b) The Evolution Agent —— 元 agent¶
“Unlike a task agent, which edits the target repository, the Evolution Agent edits the operating conditions under which later task agents work.” —— §3.5.2
五阶段循环：观察轨迹 → 诊断失败模式 → 提出候选修订（重写工具描述、调整上下文打包规则、加 linter、改重试上限、在风险命令前插 HITL gate）→ 在保留任务/replay 上评估 → 只有通过验证、且不在已解决案例上回退 才推广。
(c) Governed Harness Mutation¶
AHE 不是无约束自我修改 —— Evolution Agent 自己也受 PEV 循环约束。候选 harness 变更必须在沙箱内评估、对比固定回归套件、留下可审计的 rationale。改动权限边界、网络访问、凭证处理、部署行为、HITL 要求的变更，必须有人审批后才能激活。
代表系统：AutoHarness（自动合成 harness）、Meta-Harness（把 harness 设计当作优化问题）、GEPA（反思式 prompt 演化）、EvoMAC（工作流拓扑演化）、SEW（自演化工作流）、Live-SWE-agent（在线演化）。
按： AHE 是论文给”harness engineering”这个新兴工程学科下的最完整定义。下一年我估计 Evolution Agent / Governed Mutation / Change Contract 这套词汇会迅速进入主流。
4. Scaling the Harness：多 Agent 共享代码工装（§4）¶
4.1 单 agent 的三大限制 → 多 agent 的三个维度¶
单 agent 的三大瓶颈：(1) 上下文窗口装不下整个代码库 + 长交互历史 + 执行轨迹；(2) 一个通才 agent 同时干规划、合成、测试、审阅、调试效率低；(3) 缺乏独立的协调和验证通道，agent 难以可靠地发现并纠正自己的错误。
多 agent 系统在三个维度上展开：
- 角色专门化：Program Synthesis / Program Understanding / Verification / Execution / Planning
- 共享程序状态下的交互模式：协同合成、批评修复、对抗验证、推理辩论
- 工作流拓扑：链式（瀑布）、循环（敏捷）、层级、星型、目标驱动自适应
详细对照表（论文 Table 9 简化）：
| 系统 | Harness 底座 | 交互模式 | 拓扑 |
|---|---|---|---|
| Self-Collaboration | 黑板（隐式） | 批评-修复 | 预定义循环 |
| ChatDev | 隐式，偶尔执行 | 批评-修复 + 辩论 | 瀑布链 |
| MetaGPT | 隐式 + 部分黑板 | 批评-修复 + 发布订阅 | 瀑布链 |
| AgentCoder | 执行 | 批评-修复 | 循环 |
| HyperAgent | 仓库 + 执行 | 批评-修复 | 预定义层级 + 循环 |
| MAGIS | 仓库 + 演化记忆 | 批评 + 辩论 + 委派 | 层级 + 循环 + 动态池 |
| EvoMAC | 执行 | 文本反向传播 | DAG（自适应） |
| FlowReasoner | 执行（隐式） | 运行时工作流生成 | 目标驱动自适应 |
4.2 一个被低估的发现：拓扑复杂度与共享底座形式化负相关¶
论文做了一个很犀利的横向观察：那些拥有显式、形式化共享底座的系统，拓扑反而越简单；没有形式化共享状态的系统，拓扑越来越复杂 —— 后者是在用拓扑工程补偿缺失的状态表示。
“Topology complexity is partially a symptom: when the substrate is formally represented and queryable, agents can coordinate through simple, transparent protocols.” —— §4.4
L2MAC 是最干净的反例 —— 它有显式持久文件存储 + 显式上下文调度，于是用最简单的顺序链 + 复杂状态管理就够了。
4.3 论文的”立场（Position）“：共享代码工装底座¶
§4.3 是论文对未来多 agent 系统给出的明确立场（position paper 风格的一节）。论文按 形式化程度 把共享底座分四级：
| 层级 | 描述 | 代表 |
|---|---|---|
| Implicit / File-only | 没有持久可查询表示；从对话历史隐式重构状态 | ChatDev、MetaGPT、MapCoder、CodeCoR、SEW、CodePori |
| Repository-based | 可导航的代码库 + 依赖图 + 版本历史 | MAGIS（演化记忆）、HyperAgent（仓库导航工具）、Lingma SWE-GPT（AST 骨架）、SyncMind（形式化 Sk / Bk） |
| Execution-based | 通过执行行为表示状态 —— 编译、测试、fuzz、性能 | AgentCoder、AutoSafeCoder、QualityFlow、MACRO、EvoMAC、CANDOR、MAGE |
| Blackboard / Shared-State | 显式全局可读写数据结构 | Self-Collaboration（首次引入黑板）、L2MAC（持久文件存储 + 控制单元）、GameGPT、Cogito（三层记忆） |
关键 gap：现有文献的”大多数都在 implicit / file-only 这一层” —— 这就是为什么 agent 经常出现”状态分歧（state divergence）“，且系统检测不到、也修不了。
4.4 Harness-State Convergence —— 何时停？¶
代码作为可执行底座的独特好处：收敛标准可以建立在客观行为信号上，而不只是 agent 之间的口头一致。论文整理出六种收敛模式：
| 收敛模式 | 含义 | 代表 |
|---|---|---|
| Correctness convergence | 测试门控：所有测试通过 | AgentCoder、L2MAC、SyncMind、CANDOR |
| Security convergence | 静态扫不出 CWE + fuzzer 不崩溃 | AutoSafeCoder |
| Performance convergence | 满足用户设定的运行时/内存阈值 | MACRO |
| Score-based convergence | 多准则量化分数排序 | MAGE、CodeCoR、Trae Agent |
| Consensus convergence | 多评审者投票 | CANDOR、QualityFlow |
| Implicit convergence | 固定迭代数 / 固定阶段后终止，无客观信号 | ChatDev、MetaGPT、Self-Collaboration、EvoMAC |
最后一类 implicit convergence 是 现有文献最常见、也最严重的缺陷。论文一针见血：
“The prevalence of implicit convergence is a direct consequence of the lack of formal shared substrates: without an objective representation of the program state, systems have no principled criterion for convergence.” —— §4.3.2
4.5 一个有意思的反直觉发现¶
论文记录了一个值得深思的实证现象：Self-Collaboration 和 QualityFlow 都报告，“LLM 模拟执行”在预测实际测试结果上能达到 98%+ 精度和召回。
这意味着：执行反馈的价值 不是均匀分布 在所有失败模式上的。LLM 模拟擅长处理大量可修正的常见 bug；但那些”语言模拟从结构上无法想象”的失败模式（运行时崩溃、资源耗尽、边界条件、性能回归）必须靠真实执行。论文呼吁的”成熟 harness”是 两条路径都集成：语言推理走快路径，执行只在需要的故障类型上作为验证 oracle。
5. 应用与开放问题（§5）¶
5.1 五个应用域，五个”程序世界”¶
论文用 program world 这个比喻贯穿应用部分 —— 每个领域都有一个代码定义的”世界”，agent 在其中行动。
| 应用 | 这个”程序世界”是什么 | 关键 harness 元素 |
|---|---|---|
| Code Assistants | 仓库 + 测试 + Issue + PR + CI | repo 状态、test feedback、code editing、PR 工作流、shared repo |
| GUI / OS Agents | DOM/可访问性树 + 应用 API + 屏幕渲染 | DOM 状态、动作 API、视觉 grounding、UI 记忆、可执行检查 |
| Autonomous Embodied Agents | 物理世界 + 仿真器 + 机器人 SDK | 技能库、机器人控制、affordance grounding、仿真反馈、终身技能 |
| Scientific Discovery | 假设 + 实验协议（XDL/Opentrons）+ 仿真 + Jupyter notebook | 假设、实验、仿真循环、数据分析、实验室自动化 |
| Agent Personalization | 用户状态 + 偏好记忆 + 反馈循环 | 用户状态、偏好记忆、反馈循环、自适应策略、长期 profile |
值得记下来的几点框架性观察：
- §5.1.1 代码助手：论文把当代代码助手（Claude Code、Codex、Copilot Cloud Agent、OpenHands、DeepAgents）统称为 agent harnesses as executable development interfaces —— 它们的核心不是模型本身，而是把 仓库、工具、沙箱、记忆、验证、人工审阅 编排成可重复发起的工程接口。
- §5.1.2 GUI/OS agent：把 GUI/OS 比作 partially observable program world —— 每一次观察都是渲染的代码，每一次行动都是对另一段代码的调用。
- §5.1.3 具身 agent：代码把行动 grounding 到物理可行性，把可复用技能累积成记忆，并支持可审计的真实世界部署。
- §5.1.4 科学发现：hypotheses as code, protocols as code, analyses as code —— 代码同时承载科学推理、科学行动、科学环境本身。
5.2 七个开放问题（论文最值得反复看的一节）¶
这一节论文写得最锋利、也最有”指明下一阶段研究该做什么”的价值。完整罗列如下：
5.2.1 Harness-Level Evaluation and Oracle Adequacy¶
问题：现有评测把”基座模型能力、harness 质量、工具可靠性、反馈丰富度、环境难度”全部混在一个 end-task accuracy 里。 该做什么：harness 层指标 —— (i) 轨迹效率（工具调用次数、token、编辑次数、执行次数、wall-clock）、(ii) 验证强度（覆盖率、oracle 多样性、误接受率）、(iii) 恢复能力、(iv) 状态一致性（记忆/仓库/轨迹/agent 信念是否同步）、(v) 安全合规、(vi) 可重放性 —— 完整轨迹能否从日志和产物里重建并审计。
5.2.2 Semantic Verification Beyond Executable Feedback¶
问题：可执行反馈本身可能制造 false sense of correctness —— 测试是绿色的不代表满足完整规范。“agent 看到绿色测试，但绿色测试不是完整规约。” 该做什么：每个被接受的动作携带 evidence bundle —— 跑了哪些检查、保留了哪些假设、哪些区域没测、剩余风险。Verification 不是终点门控，而是 agent、harness、环境之间不断演化的可检查契约。
5.2.3 Self-Evolving Harnesses without Regression¶
问题：固定 harness 在不同任务分布下会失败 —— 竞赛编程的 harness 不适合仓库修复；GUI 调优的 harness 在科研工作流里浪费算力。但 自动演化 harness 不能以削弱安全为代价。 该做什么：把 harness 变更当作”对安全攸关 runtime 的代码改动”对待 —— 每个变更携带 change contract（改了什么组件、针对什么失败模式、预测什么改进、保留什么不变量、什么评测能证伪、如何回滚）+ 留出的回归套件 + 灰度发布 + 因果证据。
5.2.4 Transactional Shared Program State and Semantic Conflict Resolution¶
问题：多 agent 同步的不只是产物，还有 假设、版本依赖、不变量、reviewer 引入的约束 —— 现在的同步机制处理 artifacts，不处理 assumptions。 该做什么：每个动作声明自己的 read set / write set / assumptions / version dependencies / verifier obligations / conflict policy。冲突在 plans、tests、retrieved evidence、permissions、memory、latent user requirements 这些层面被检测，不只是 file diff。语义合并、回滚、依赖锁、信念状态对账、合并后重新验证。
5.2.5 Human-in-the-Loop Safety and Accountability as Harness State¶
问题：在软件部署、网络安全、金融、医疗、科学实验、企业自动化、具身控制这些后果敏感的场景，安全不能委托给基座模型、也不能只编码为自然语言指令。 该做什么：harness 作为 safety governor。多 tier 权限模型 + executable accountability —— 每次审批、拒绝、策略例外、reviewer 修正都更新 harness 的权限规则、升级策略、验证标准、未来记忆检索。高风险审批是 可审计的状态迁移：提了什么动作、展示了什么证据、揭示了什么风险、谁批准/拒绝、责任边界后续如何变化。
5.2.6 Multimodal Code-Harness Systems¶
问题：现有 harness 大多围绕文本状态设计，但 GUI agent、具身 agent、科研 agent 的关键状态是 多模态 的 —— 截图、可访问性树、深度/力/触觉信号、显微镜图像、分子结构。 该做什么：(a) 多模态上下文压缩 —— 多级记忆设计：原始帧作为不可变证据 / 对象-区域-元素-姿态级标注作为结构化中间状态 / 紧凑文本或符号摘要供检索和规划；(b) Visual grounding —— 每个动作携带 grounded reference（bounding box、对象 ID、UI 元素、帧索引、姿态）+ 执行后验证视觉状态是否如期改变；(c) 多模态验证栈 —— 视觉状态检查 / 对象跟踪 / OCR / 仿真状态 / 物理传感器 / 触觉反馈，每个信号声明自己的范围和不确定度；(d) 多模态技能 —— (precondition, action pattern, expected postcondition) 的三元组，跨布局/视角/具身/传感器迁移。
5.2.7 Toward a Science of Harness Engineering¶
最后这一节是论文给出的结论性观点：
“The most important future systems will likely be those that combine four properties. First, they will be executable… Second, they will be inspectable… Third, they will be stateful… Fourth, they will be governed.” —— §5.2.7
Executable + Inspectable + Stateful + Governed —— 这四个性质就是论文给出的”下一代可靠长程 agent 系统”的标尺。
6. 译者按：这篇论文给我们留下了什么¶
读完一圈我自己的几点判断：
(1) 真正的概念创新有两处。其一是 PEV (Plan-Execute-Verify) 循环 —— 把”调试”从事后修复重新框架成”对可执行程序状态的控制过程”。其二是 Agentic Harness Engineering —— 把”为 agent 设计 harness”作为一门工程学科独立出来，给了它术语（Evolution Agent、Change Contract、Deep Telemetry、Governed Mutation）和方法论。这两套词汇明年应该会很常见。
(2) 横向最锋利的观察：拓扑复杂度与共享底座形式化负相关（§4.4）。多 agent 系统拓扑越花哨，往往说明它的共享状态表示越简陋；反过来，给 agent 一个干净的可查询共享底座，简单顺序链就够用。这一观察直接打脸了过去两年大量”复杂多 agent 拓扑”的论文叙事。
(3) 最有警示意义的发现：LLM 模拟执行能达到 98%+ 精度（§4.5）。这暗示我们一直在用执行反馈解决很多”语言模拟其实也能解决”的问题；而执行反馈真正不可替代的，是 语言模拟从结构上想象不到 的那部分 —— 运行时崩溃、资源耗尽、性能回归、边界条件。未来的 harness 应该有意识地把这两条路径分开。
(4) 我对论文的一处保留：综述对 open challenges 的整理非常齐全，但对”为什么是 code 而不是其他可执行表示能担当 harness”这件事，论证略偏直觉。代码的可执行/可检查/有状态三性质很有说服力，但其实形式化规约、proof script、DSL、配置文件也满足这三条 —— 论文自己在 Scope boundary（§2 开头）里也承认了这一点。这里其实留了一个理论空间：未来或许会有人提出 executable specification as agent harness 之类的延伸。
(5) 如果只读三节：
- 想理解全图 → §1 Introduction + Figure 1
- 想理解 harness 控制原理 → §3.4 PEV loop + §3.5 AHE
- 想理解多 agent 真正缺什么 → §4.3 Shared Code-Centric Harness Substrate + §4.4 Patterns and Trends
(6) 我自己最受用的一句：
“Code therefore serves as an executable medium inside the harness, while the harness remains the larger policy-governed system that decides what code may be executed, trusted, persisted, reused, or promoted into future workflows.” —— §3
—— 这句话基本可以当作我之后做 agent 工具/skill/MCP 服务的设计准绳。代码是介质，harness 是治理。
引用：
@article{ning2026codeasharness,
title = {Code as Agent Harness: Toward Executable, Verifiable, and Stateful Agent Systems},
author = {Ning, Xuying and Tieu, Katherine and Fu, Dongqi and Wei, Tianxin and Li, Zihao and Bei, Yuanchen and others},
journal = {arXiv preprint arXiv:2605.18747},
year = {2026}
}- 原论文：https://arxiv.org/abs/2605.18747
- 配套论文清单：https://github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers
本文是个人理解性的中文精读，论点出处尽量标注到原文小节。如发现摘要或转述与原文不符，以原文为准。