代码即智能体框架：迈向可执行、可验证、有状态的智能体系统 Code as Agent Harness
提出「代码即智能体框架」视角，让代码成为智能体推理与行动的运行时底座。
前置知识
Agent Harness（智能体框架）
指包裹在LLM之外、把无状态的模型变成可执行长程任务的功能系统的软件层。它由工具、API、沙箱、记忆、验证器、权限边界、执行循环与反馈通道等组成，是模型「思想」通往「动作」的中介基础设施。
本文的核心论点建立在「智能体的瓶颈不仅是模型推理能力，还包括把模型输出与长程动作/持久状态相连的框架可靠性」这一观点之上，必须先理解harness才能理解为什么本文要把代码升格为harness的本体。
代码即推理（Code-for-Reasoning）
用可执行程序替代纯自然语言CoT进行中间计算的方法，例如Program-of-Thoughts、PAL、Chain of Code等。模型生成代码、解释器执行、返回结果与执行轨迹，外部runtime可以验证、修正并持久化中间状态。
这是「代码即框架」的第一层接口范式，理解它能帮读者抓住论文「用代码替代纯文本推理」的核心迁移思路。
Plan-Execute-Verify (PEV) 闭环
把智能体的迭代调试重构成一个控制论闭环：Plan把意图外化为状态变更合约；Execute在沙箱/权限边界内应用变更；Verify用确定性传感器（lint、类型检查、单元测试、CI）决定状态是否被接受。失败时通过相同证据触发修正、回滚或升级到人审。
PEV是本文把「调试」从prompt工程升格为harness级控制机制的关键抽象，也是后续Agentic Harness Engineering把harness自身当对象优化的基础。
可执行/可检查/有状态（Executable/Inspectable/Stateful）
本文归纳代码作为harness接口的三大属性：可执行意味着模型输出能通过执行被验证；可检查意味着中间计算以结构化trace暴露给harness，可诊断、可回放；有状态意味着程序状态在多步执行间持续可修改。
这是全文反复出现的判别标准——它划清「代码当产物」和「代码当harness」的边界，凡是具备这三种属性的对象，论文都视为框架的载体。
多智能体代码协作（Multi-Agent Code Generation）
把软件开发拆给Manager、Planner、Coder、Reviewer、Tester等角色，通过共享代码工件、test/diff/log/blackboard等中介通信。常见拓扑包括chain（瀑布）、cyclic（敏捷）、hierarchical、star，以及动态DAG重构。
论文第4章用此概念把单智能体harness扩展到多智能体共享harness，并提出「共享代码中心化harness底座」的新立场，是评测其「可扩展性」贡献的必备背景。
研究动机
现有智能体研究在系统层面存在一个被反复忽视的瓶颈：单点模型能力（如推理、规划）已不再是限制智能体长程自主性的唯一短板，更大的短板在于「把模型输出变成可观察、可回滚、可验证的状态变更」这一整套基础设施——也就是harness。当前文献对agent harness的讨论多停留在「工具+沙箱+反馈」的工程清单上，却未给出一个统一的视角去解释代码在其中扮演的角色。结果是大量系统把代码仅当作LLM要生成的「目标产物」，而忽略了代码天然具备的可执行、可检查、有状态三大属性其实正是harness所需的全部底座。具体的工程痛点包括：长程软件任务（如仓库级issue修复、PR review、CI反馈）依赖多次工具调用与持久状态，模型上下文窗口会被build log、trace、diff迅速撑爆；GUI/OS与具身智能体的「动作」实质是DOM事件、shell命令或电机原语，但被以非结构化文本形式送回模型；多智能体协作时plan、coder、tester对仓库状态的理解常出现隐式分歧（论文称为state divergence，SyncMind用$|B_k - S_k|$来形式化），却没有任何共享的、可查询的程序状态层来对账。这些问题在Coding Assistant、GUI Agent、Scientific Discovery、Embodied Agent、Personalization五大领域都同时出现，但缺少一个横跨领域的统一分析框架。
本文的目标是本文提出「Code as Agent Harness」这一新视角，把代码从LLM的输出产物重新定位为智能体系统的运行时底座：推理、行动、环境建模、状态、记忆、反馈、验证都应围绕可执行、可检查、有状态的程序来组织。为系统化地展开这一论点，作者把整个harness栈拆为三层——Harness Interface（代码如何成为推理/行动/环境的接口）、Harness Mechanisms（规划、记忆、工具、PEV控制、harness自优化）、Scaling the Harness（多智能体在共享代码工件上的协作）——并在此基础上覆盖五大应用领域（代码助手、GUI/OS、具身、科学发现、个性化），最后梳理出7个开放问题。论文的目标不是提出一个具体新算法，而是给学界与工业界提供一个统一的术语表、分析维度和研究路线图，让「造一个能长程工作的智能体」这件事被当作harness工程问题来研究。
与已有工作不同的是，本文的独特切入角度在于「把harness视作一等公民，并让代码成为它的本体」。与现有三类文献相比有清晰差异：(1) 与一般agent survey（如关于LLM agent、agentic foundation models的综述）相比，本文拒绝把代码当作「被生成的产物」或「被调用的工具集」，而把它视作harness本身的「介质」——harness的接口、机制、规模化都通过代码实现；(2) 与code LLM survey（如code generation、code completion综述）相比，本文关心的不是「如何生成正确的程序」，而是「代码如何在agent loop中承载推理、行动、状态与反馈」；(3) 与agent harness本身的早期讨论（如Anthropic/OpenAI的harness engineering博客）相比，本文用三层taxonomy + 五大领域 + 七个开放问题给出了学术化的形式化框架，并把harness的自演化（Agentic Harness Engineering）和多智能体共享底座作为独立研究议程提出。这一组合是现有文献所缺乏的——尤其「共享代码中心化harness底座」作为一个position paper式的论点，明确指出当前多数MAS的harness仍停留在「隐式/文件级」状态，没有真正利用代码的可执行性去锚定多智能体共识。
核心方法
作为一篇综述，本文没有提出单一新算法，而是用「三层架构 + 五大领域 + 七个开放问题」的方式组织现有方法，整体思路可以直觉理解为「把代码从产物升级为底座」：先承认harness是智能体可靠性的关键变量，再论证代码天然具备executable/inspectable/stateful三性，正好是harness所需的全部底座属性，于是把所有围绕智能体的方法按「代码扮演的角色」重新归类。具体技术路线上，第一层Harness Interface把代码作为推理/行动/环境三类接口；第二层Harness Mechanisms在接口之上引入规划（线性分解、结构约束、搜索、编排）、记忆与上下文工程（working/semantic/experiential/long-term/multi-agent memory、context compaction）、工具使用（function-oriented / environment-interaction / verification-driven / workflow-orchestration）、PEV控制循环、Agentic Harness Engineering（深度遥测、Evolution Agent、governed mutation）五大机制；第三层Scaling the Harness把单智能体框架扩展为多智能体共享框架，通过functional role specialization、interaction mode、workflow topology和execution feedback/shared harness synchronization四维度展开。最终把所有方法映射到5个应用领域并识别7个开放问题。每个层次都配以代表性系统的表格（Tables 1–11），并用roadmap figures（Figures 3, 4, 11）按时间线展示领域演化。
本文与已有方法最本质的区别是把「代码在智能体中的角色」做了一个center-of-gravity迁移：在传统视角里，代码是模型要生成的工件，harness是用工具+沙箱+prompt围起来的「壳」；本文视角里，代码本身就是harness——它的可执行性提供验证、可检查性提供诊断与回放、有状态性提供持久化与可共享的底座。围绕这一核心，本文还提出两个新立场：(1) Agentic Harness Engineering——把harness自身作为可观测、可演化对象，用Evolution Agent基于深度遥测修改工具schema、检索策略、权限规则等，再用PEV循环治理这种「自修改」行为；(2) Shared Code-Centric Harness Substrate——多智能体协作应建立「可查询、可更新、有版本依赖」的共享程序状态层，而不是依赖文件级隐式传递或消息总线。这两个立场把「harness工程」从工程经验升级为可被系统化优化与评测的学科。
方法步骤详情
本文作为综述，其「方法」是把整个研究领域用以下层次化步骤组织起来供读者系统化使用：(1) 概念分层：先把agent系统解耦为「模型内部能力 / 系统提供的harness基础设施 / 智能体发起的代码工件」三类，明确本文聚焦于第三类如何被前两类构造与演化；(2) 范围边界声明：明确「code」在本文指executable/machine-checkable artifacts（程序、proof script、API schema、test、repo、simulator、log等），并把raw perception/physical state/latent reasoning排除在外以避免泛化；(3) 沿三层分别review：§2把代码作为harness interface按「reasoning/acting/environment」三轴分别列出program-delegated reasoning、formal verification、iterative code-grounded reasoning、grounded skill selection、programmatic policy generation、lifelong code-based agents、structured world representations、execution-trace world modeling、code-grounded eval environments、verifiable environment construction十个子方向，并配Tables 1–3；§3按planning（4子方向，含Table 4）、memory（6子机制，含Table 5）、tool use（4子方向，含Table 6）、PEV control（含Table 7）、Agentic Harness Engineering（含Table 8）展开；§4按functional role specialization、interaction mode、workflow topology、execution feedback & shared harness synchronization四个维度系统盘点多智能体系统（含Tables 9–11）；(4) 应用映射：§5把上述方法落到五大领域，每个领域都用「perception/observation、action API、memory、simulator、evaluation」五要素描述代码如何成为harness；(5) 开放问题：§5.2用7个子节展开harness-level evaluation、semantic verification、self-evolving harness、transactional shared state、HITL safety、multimodal harness、science of harness engineering。这些步骤的输入是大量已有文献（200+引用），输出是统一taxonomy + 表格化代表性系统 + roadmap figures + 7个未来议程。
技术新颖性
本文的技术新颖性不在单点算法，而在四个系统级贡献：(a) 概念框架化：把「代码即harness」从直觉升格为带scope boundary、attribute定义（executable/inspectable/stateful）和三层taxonomy的形式化框架，并显式区分agent-initiated code artifacts与system-provided harness infrastructure；(b) 分类学的统一：把过去分散在code reasoning、code generation、agent planning、agent memory、agent tool use、multi-agent collaboration等子领域的方法按「代码作为harness的何种角色」重新组织，让跨子领域的方法学可以横向比较，例如把Program-of-Thoughts、SayCan、CaP、Voyager、Lean4Agent这些不同领域的方法放在同一张harness mechanism表中；(c) 立场化新方向：明确提出Agentic Harness Engineering（含Evolution Agent、deep telemetry、governed mutation）和Shared Code-Centric Harness Substrate（formal harness representation的四级形式化：implicit/file-only、repository-based、execution-based、blackboard/shared-state）作为新研究议程，把「harness工程」建为一个独立学科；(d) 工程实践综合：把工业界已经出现但未在学术综述中被系统化的实践——如Claude Code/Codex/OpenHands的harness loop、Cursor Composer的在线RL、AutoHarness/Meta-Harness的harness合成、WorkArena的23,150个ServiceNow任务——纳入综述，让学术与工业的对话有了共同词汇。
实验结果
作为综述，本文的核心「发现」是组织性的而非数值性的，体现在以下几条结论上：(1) 代码在智能体中已经承担三种不同但耦合的接口角色：推理（PoT[6]用程序把自然语言推理外化为可执行计算，CodePRM[31]用execution trace做process reward）、行动（SayCan[9]/CaP[10]/Voyager[32]把程序作为可执行policy与skill library）、环境建模（Code2World[38]用HTML渲染预测GUI下一态、CWM[37]训练LLM原生学习program execution trace）。每一种角色背后都对应一系列benchmark提升与新能力，例如AutoCodeRover在SWE-bench上的仓库级定位能力来自结构化检索；AlphaProof在Lean中用程序化证明步骤取代纯文本推理取得IMO级突破；(2) harness机制五大子模块已经形成相对成熟的设计模式：规划从linear decomposition（Self-Planning[40]）走向structure-grounded（CodePlan[42]、VerilogCoder[156]）、search-based（CodeTree[43]、SWE-Search[164]、Meta-Harness[13]）和orchestration-based（MapCoder[44]、Blueprint2Code[165]、Natural-Language Agent Harnesses[173]）；memory被分为working/semantic/experiential/long-term/multi-agent五类，并叠加context compaction和state offloading（LongCodeZip[194]、SWE-Pruner[195]）；tool use被分为function-oriented/environment-interaction/verification-driven/workflow-orchestration四类（ToolCoder[19]、SWE-agent[57]、AgentCoder[50]、OpenHands[58]）；PEV循环把调试重定义为harness级控制（含CodePlan、MapCoder、Self-Debugging[243]、Reflexion[244]、AutoSafeCoder[52]、VeriGuard[226]等代表系统）；Agentic Harness Engineering用Evolution Agent + deep telemetry把harness自身纳入优化（AutoHarness[14]、Meta-Harness[13]、GEPA[18]、EvoMAC[328]）；(3) 多智能体层面的关键经验：收敛模式与harness substrate形式化程度强相关，QualityFlow[253]用code quality checker作为single gating signal可在75–84%的问题上首轮收敛；Self-Collaboration[56]和QualityFlow都发现LLM-simulated execution可以在MBPP上达到98%+ precision/recall，挑战「必须真实执行」的直觉；但AutoSafeCoder[52]的fuzzer-based adversarial validation和MAGE[339]的clock-edge waveform checkpoint证明对corner case仍必须用真实执行信号；拓扑复杂度与harness-state形式化呈反向关系——L2MAC[344]用最principled的blackboard D+Control Unit反而采用简单chain，而EvoMAC/SEW因substrate是隐式的，只能用越来越复杂的adaptive DAG去补偿；(4) 工业规模证据：Alibaba Cloud的LingmaAgent在内部issue上fully autonomously解决16.9%、人工介入下解决43.3%[372, 373]；MLE-bench上OpenAI o1-preview+Weco AIDE在75个Kaggle比赛中达到16.9%的bronze medal率[456, 457]；MLE-bench的AIDE比次优agent medal率高约3倍[457]；Cursor的Composer通过在线RL在真实使用trace上训练，证明「harness正在成为训练数据」[375, 376]；OpenAI codex-1/GPT-5-Codex/GPT-5.1-Codex-Max都基于长程多轮Codex harness loop训练[27, 377, 378]；multi-agent失败归因的最佳step-level accuracy仅14–53%[384, 385, 386, 387]，说明production harness仍然缺少结构化trace；(5) GUI/OS与scientific领域的具体数字：WebShop含1.18M真实Amazon商品[422]；WebArena fork了4个full-stack开源网站到Docker[60]；OSWorld含369个真实Ubuntu/Windows/macOS任务[396]；WindowsAgentArena在Azure并行[392]；WorkArena额外加23,150个ServiceNow任务[398]；AndroidWorld提供116个programmatic tasks[391]；ScienceAgentBench把102个任务统一为self-contained Python program[458]；A-Lab在17天连续运行中合成41种新无机化合物[452]；Virtual Lab用AI PI团队在数天内设计92个SARS-CoV-2纳米抗体，2个经实验验证[440]；El Agente Q在6个大学级基准上超过87% task success[449]；DiscoveryBench best system仅~25%[459]。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| MBPP上的quality-gated正确性收敛 | precision/recall of imagined execution vs real execution | QualityFlow用LLM-simulated imagined execution达到98%+ precision/recall | 真实Python interpreter执行 | 在MBPP上避免label leakage的同时达到近等价信号 |
| MLE-bench（Kaggle ML工程） | Kaggle bronze medal达成率 | OpenAI o1-preview + Weco AIDE tree-search agent在75场比赛中达到16.9% | 次优agent | medal rate约为次优的3倍 |
| SWE-bench（仓库级issue修复） | issue-to-patch success rate | Agentless[354]用fault-localization+test-guided patch generation流水线即取得有竞争力结果；SWE-bench Verified/SWE-bench Pro/SWE-Lancer等扩展到更长时间跨度与经济价值 | 纯LLM completion | execution-guided pipeline显著超越prompt-only方法 |
| step-level failure attribution in multi-agent systems | attribution accuracy | AgenTracer[386]、AgentDebug[387]、Who&When[385]等系统report best step-level accuracy | 随机/naive归因 | 目前最好结果仅14–53%，说明production harness严重缺乏结构化trace |
| Virtual Lab SARS-CoV-2 nanobody设计 | 实验验证的binder数量 | 在数天内设计92个纳米抗体，2个经实验验证结合JN.1和KP.3变异株 | 传统湿实验流程 | 在数天时间窗内完成传统上需要更长时间的设计-验证循环 |
| A-Lab自主合成无机化合物 | 17天内合成的目标化合物数 | 从58个目标中合成41种新无机化合物 | 传统人工合成 | 17天连续无人值守完成 |
| Alibaba Cloud issue-resolution agent | 公司内部issue自动解决率 | 16.9% fully autonomous + 43.3% with manual intervention | 无agent基线 | production-scale自治修复证据 |
局限与改进
本文明确承认与隐含的局限包括：(1) scope局限——作者明确把raw perception、physical state、human intent、模型内部latent reasoning排除在「code」之外，因此论文不能直接处理纯感知驱动的智能体或纯human-in-the-loop工作流，这些领域需要互补survey；(2) 评估局限——作者在多处（§3.1、§3.2、§4.4、§5.2.1）反复强调「现有planning/memory/MAS的收益结论高度依赖evaluation pipeline」，很多benchmark的test不充分、log解析有缺陷、存在memorization/contamination，这使得不同系统的横向比较未必可靠；(3) generalization局限——五领域分别覆盖明显不均：coding assistant和GUI/OS有大量production证据，scientific discovery、embodied和personalization更多是单点系统证明，缺乏统一benchmark；(4) 安全与对齐的浅层处理——虽然§5.2.5列出了HITL safety、permission tiers、capability governor等议题，但本文对harness在安全、对齐、价值对齐（value alignment）层面的系统化讨论仍较浅，更多停留在「应被设计」层面而非「已可评测」；(5) 多智能体共识机制的局限——作者在§4.3.1指出多数MAS的harness仍停留在implicit/file-only级别，仅有SyncMind[347]形式化定义$|B_k - S_k|$作为agent belief divergence度量、AgentCoder[50]用deterministic Python script作为test executor，其他系统仍缺乏可形式化评测的substrate；(6) 多模态harness尚未成型——§5.2.6明确指出multimodal context compression、视觉grounding contract、multimodal verification stack都是开放问题，目前没有可比较的统一方案。从我作为读者的观察看，论文还隐含一个更深的局限：它把「代码可执行」等同于「可验证」，但在很多GUI/embodied场景中「按下了按钮」可执行却不等于「完成了任务」，这种语义鸿沟在第5章被多次点出但尚未给出系统化解决路径。
独立分析的弱点
独立分析本文的弱点可分场景看：(1) 作为taxonomy论文的弱点——三层分类的边界并非互斥，例如Chain-of-Code[8]既属于program-delegated reasoning也属于hybrid symbolic reasoning，routing decision依赖读者经验；这种「分类重叠」使得「按本文框架做新研究」时会出现「我究竟该用哪一层」的歧义；改进方向是引入决策树式分类法或允许overlap标签显式化。(2) 缺乏可执行artifact——论文承诺github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers作为paper list，但taxonomy本身没有formal ontology，读者难以机器化复用；改进方向是发布一个linked open data版taxonomy（JSON-LD/OWL）或一个可交互的网页工具。(3) 量化评估缺失——作为综述本文几乎没有「哪种harness设计在哪个任务上更优」的定量meta-analysis，多数论断依赖「代表系统X在某benchmark上做得好」的anecdotal evidence；改进方向是组织一个针对harness的benchmark suite（类似MLE-bench/SWE-bench但评测harness本身）并报告meta结果。(4) 对PEV的「PEV」三阶段划分在跨域迁移时不稳定——scientific discovery里plan不是合约而是「待验证的hypothesis」，personalization里verify几乎没有oracle，这种domain-specific PEV变体未被显式建模；改进方向是引入domain-conditioned PEV变体（如Hypothesis-Plan-Execute-Verify、Profile-Update-Verify）作为子类。(5) 跨层交互未充分讨论——例如「代码即推理」会污染「代码即环境建模」（用train-time trace当test-time oracle时产生data leakage），本文在§4.4用一句话提及但未深入；改进方向是在每节末尾增加「cross-layer risks」小节。(6) 立场化新方向（Agentic Harness Engineering、Shared Code-Centric Harness Substrate）被嵌入综述但缺乏独立formalism，读者难以直接follow up；改进方向是为每个position paper式立场配套一个formal definition + evaluation metric + minimal reproducible example。
未来方向
作者明确提出的未来研究方向主要落在§5.2的7个open problems中：harness-level evaluation metrics（trajectory efficiency、verification strength、recovery ability、state consistency、safety compliance、replayability六维度）、semantic verification stacks（unit/integration/property/fuzz/static/type/security/runtime/coverage/formal/model-critique/human的「scope-explicit verification」）、self-evolving harness without regression（mutation operator + telemetry standard + safety invariant + canary deploy + rollback）、transactional shared program state with semantic conflict resolution（read/write set + assumption version + verifier obligation + CRDT-like merging for plans/tests/memories）、HITL safety as harness state（多tier permission + context-sensitive permission + executable accountability）、multimodal code-harness systems（multimodal context compression、grounding contract、calibrated multimodal feedback、multimodal memory with precondition/action/postcondition skills）、science of harness engineering（「executable + inspectable + stateful + governed」四性作为下一代系统的判据）。基于这些成果可延伸的方向还包括：(a) 把本文的position（Shared Code-Centric Harness Substrate）形式化为类似数据库事务的ACID-for-agent概念，让多智能体协作有可形式化验证的commit/rollback协议；(b) 在GUI/OS与embodied领域发展「grounding-as-code」——把bounding box、object id、frame index等感知结果编入action的provenance，让executable accountability自然延伸到物理世界；(c) 把Agentic Harness Engineering与continual learning结合，构建harness在生产环境下的closed-loop self-improvement，但用governed mutation防止regression；(d) 与formal methods结合——用Lean4Agent[95]和VERINA[93]的风格，把harness policy、permission rules、tool schemas本身建模为可证明的程序，使harness进入可验证软件工程的范畴；(e) 与经济/法律研究结合——多stakeholder personalization中平台、creator、user的目标冲突需要可审计的policy层，本文已点出但未展开。
复现评估
本文作为survey paper没有传统意义上的实验复现，但提供了相对丰富的复现材料：(1) 配套开源仓库——github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers整理了综述中引用的200+论文，读者可按taxonomy索引导航；(2) 表格化代表性系统——Tables 1–11列出了每个子方向的关键系统、机制、paradigm、key innovation，读者可按表直接定位原文；(3) Roadmap figures——Figures 3, 4, 11按时间线（2022–2026）展示了每个子领域的演化，方便读者识别pioneer work和近期SOTA；(4) 但本文在算力、数据、训练recipe等「实验级别」的可复现性上几乎为零——它没有发布任何benchmark、没有报告meta-analysis、没有提供可执行demo，这意味着读者无法独立验证综述中的具体数字（如「16.9% MLE-bench bronze」或「97% Self-Collaboration simulated-execution accuracy」），只能回到原始论文。复现难度方面：底层所需的GPU/算力分布在被引论文中（训练SWE-agent、OpenHands、Composer、codex-1、GPT-5-Codex等都需要大量H100/A100级资源，普通研究者难以全栈复现），数据方面各领域差异巨大（SWE-bench需从GitHub爬issue/PR，WebArena需Docker化4个网站，ScienceAgentBench需102个peer-reviewed任务的Python实现），整体复现难度为「高」——作为综述它本身无需复现，但若要基于本文做新工作，需要逐论文跟进被引系统的实现细节。
论文图表
整张综述的总图，把code as agent harness拆为三层：Harness Interface（code for reasoning/acting/environment modeling）、Harness Mechanisms（planning、memory、tool use、orchestration、workflow、infra、environment）、Scaling the Harness（agent role taxonomy、interaction modes、workflow topology），并把结果映射到Code Assistants、GUI/OS Agents、Scientific Discovery、Personalization、Embodied Agents五大应用领域。
这是全文的roadmap图，决定了读者如何理解后文所有章节的相对位置，必须先看才能跟住论文叙事。