Harness Engineering十一个编码智能体的源代码解剖、架构与演化概述“一个智能体 一个模型 一个 harness操控层”——这是 2026 年编码 Agent 领域最流行的一句话。模型负责智能harness 负责把智能变成实际工作它的循环、工具、上下文管理、安全控制、编排和扩展接口。但这篇论文最狠的地方在于它不 benchmark、不排名而是直接钻进十一个生产级编码 harness 的源代码里一行一行地看它们到底是怎么写的。论文标题叫《Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents — A Source-Code Study of Eleven Systems》arXiv 2609.00006v12026 年 7 月版。它其实是这项研究的第二版作者把 4 月的初版和 7 月的新版对着源码 diff 了一遍于是文章里不仅有横截面的解剖还有一段 90 天的演化史。读下来的直观感受是——这个领域变得太快了快到作者自己三个月前的结论都被新证据推翻了好几处。下面按原文结构把核心内容梳理一遍。文章的全部技术细节、数据和对比我尽量保留因为这篇论文的价值恰恰在细节里。什么是 harness定义、边界与七个子系统论文开篇先把研究对象钉死。Agent Model Harness这个一行公式由 Trivedy 的 LangChain 工程系列在 2026 年初普及而 “harness engineering” 这个词最早由 Mitchell Hashimoto 随口提出随后被 Trivedy 在 LangChain 的 Deep Agents 工作里正式定义。这里有个讽刺的细节这个词是从 LangChain 内部命名出来的而 LangChain 这类框架恰恰缺席于论文里每一个 harness 的运行时——后面会细说这个双重缺席。作者区分了四个容易混淆的概念harness 不是 scaffold脚手架指结构性代码不是 agentic framework开发者 import 进来造 Agent 的库不是 evaluation harnessSWE-bench 那种包住 Agent 跑任务的壳方向相反也不是 orchestrator在它之上协调一个或多个 harness 的元层。每个 harness无论大小都必须对同样的七个子系统表态——哪怕它的答案是故意不做子系统最小形态最大形态Agent loopMini-SWE-Agent一个 bash 工具上的线性 whileOpenHands基于持久事件日志、带并行批的事件源对话LLM 集成Mini-SWE-Agent一次 LiteLLM 调用、一个 Jinja 模板Hermes5 个自有传输、29 个 provider 配置Codex服务端下发的模型目录工具与动作Mini-SWE-Agent只有 bashClaude Code43 个带延迟加载的类型化工具Codex工具调用即 V8 执行的代码内存与上下文Mini-SWE-Agent无界线性历史CodexAgent 维护的跨会话内存管道Gemini CLI基于图的上下文蒸馏安全与权限Mini-SWE-Agent成本和步数上限Codex策略规则 LLM 审批审查器 三平台 OS 沙箱编排Aider无天生单 AgentClaude Code递归组合Omnigent跨厂商协调元层扩展Mini-SWE-Agent结构类型Python protocolPi一切皆扩展的运行时Codex市场分发的插件除了这七个还有两个横切面接口层TUI、CLI 参数、IDE 协议、HTTP 服务、SDK和会话基板transcript、持久化、恢复/fork。论文还给了一个最小 harness的存在性证明Mini-SWE-Agent 用大约 100 行代码实现了全部七个子系统——一个 while 循环、一个模板、一个工具、一个消息列表、两个上限、没有编排——却能在 SWE-bench Verified 上报出和比它大三个数量级的系统相近的结果。当然作者谨慎地标注了这是自报数字、模型和日期都不同。但重点是地板真的很低。研究的十一个系统与十二个对照点论文的主体语料是十一个 harness外加两个对照点。四个是商业大厂的旗舰Claude CodeAnthropicTypeScript用一份流传出来的源码快照、Codex CLIOpenAIRust、Gemini CLIGoogleTypeScript、Mistral VibeMistral AIPython。七个开源OpenHands、Aider、Mini-SWE-Agent、HermesNous Research、Pi、OpenCode、OpenClaw。再加上 Databricks 的 Omnigent——作者所知第一个元 harness作为对照点分析。几个版本与规模的关键数据截至 2026 年 7 月Codex 规模最大约 112 万行 Rust126 个 crateGemini CLI 约 60 万 行。Hermes 是增长最快的开源 harness5 个月内约 212k starsOpenCode 是 star 最多的专用编码 Agent约 184k stars。Pi 是最小核心反潮流的代表约 790 行函数式核心。OpenClaw 是外部对照点它是跨 20 消息平台的个人助理网关本身不带代码编辑工具通过插件把编码任务外包给别的 Agent。论文每个系统都给了一个签名能力——截至 2026 年 7 月其他系统都没有的独特本领。比如 OpenCode 的 client/server 架构、Codex 的 Agent 维护跨会话内存、Gemini CLI 是语料里唯一的 A2A 服务器、Pi 的一切皆扩展核心等。Agent 循环设计三种范式Agent loop 是每个 SWE Agent 的架构主干在 LLM 推理和动作执行之间交替。论文识别出三种范式迭代式动作-观察循环九个系统用这个。这是最主流的但各家实现差异极大OpenHands是事件源对话引擎每个事件追加到持久 EventLog一个事件一个文件带文件锁和密钥脱敏LLM 看到的历史是活跃分支的缓存投影。对话状态是一棵带可移动头部的树replay/fork/分支导航都是一等公民。每一步执行一次 LLM 调用但把响应里的所有工具调用作为一个 action batch 执行可通过资源锁管理器并行。Claude Code通过 SSE 流式响应最独特的是智能工具批处理工具调用按并发安全性用一次 reduce 算法分区默认isConcurrencySafe false只读工具grep/glob/读文件安全写工具edit/bash不安全。Codex是用 Rust 实现的 Tokio 异步状态机通过 FuturesOrdered 有序并行处理工具调用。Mini-SWE-Agent是最简线性循环论文直接给了代码Listing 1一个while Truestep()里一次query()加一次execute_actions()没有状态机、没有事件源、没有并发。消息列表线性无界增长全靠模型的本地上下文窗口。Mistral Vibe是中间件管道循环turn 级策略被抽成可组合的中间件六个中间件开箱即用步数、价格、token 上限、自动压缩、上下文警告、只读 Agent新增策略不用改循环体。Gemini CLI是异步生成器循环独特的是混合式 LoopDetectionServiceSHA-256 哈希廉价地抓住常见失败5 次相同工具调用或 10 个相同内容块就中止30 轮后跑一个 LLM 自检。Hermes是带预算的循环默认 90 次迭代预算独特的是十一个枚举的 turn 退出原因和两个 stop-guard其中 verify-on-stop 会把没有新鲜验证证据的纯文本响应重写成 continuation。Pi是语料里除 Mini-SWE-Agent 外最纯粹的迭代实现约 790 行函数式核心没有 planner、没有反思、没有 turn 上限、没有 stuck 检测、没有成本kill-switch——这些缺席都是有意记录的设计拒绝。OpenCode是 log-as-queue 循环消息日志同时就是工作队列未决的子 Agent 生成和压缩都是持久化的消息部分循环每次弹出一个——这让循环天然可跨进程重启恢复因为队列就是 transcript。反思增强循环Aider。run_one()实现一个嵌套循环每次 LLM 响应后应用编辑再检查 lint 错误三阶段 Python 流水线语法检查 → compile 检查 → flake8、测试失败和未解决的文件引用有问题就用反射消息触发 LLM 重新调用最多 3 次反思。Aider 仍是唯一一个主循环是反思形状的系统。协调者-工人模式叠加在迭代循环之上。Claude Code 和 Codex 支持 coordinator 模式Hermes 把它藏在配置后面。论文的观察 1 很有意思十一个系统横跨三个数量级的代码规模却做着相似的任务而循环的复杂度并不预测 benchmark 表现。Mini-SWE-Agent 的最小线性循环报出的结果和 OpenHands 的事件源对话引擎在同一档尽管后者光循环编排就多写了大量代码。生产系统里的大部分代码处理的是和完成任务正交的事安全、用户体验、扩展——以及越来越重的客户端和传输层。LLM 集成与模型-智能体协同设计十一个系统在和底层 LLM 怎么相处这件事上从紧耦合到完全解耦排成一条谱系共五种策略单 provider 紧耦合Anthropic、OpenAI、Google。Claude Code 只用 Anthropic SDKCodex 用 OpenAI Responses APIGemini CLI 用 Google SDK 并额外耦合 Vertex AI。它们不容易换 provider。provider 优先 通用回退Mistral。Mistral Vibe 的工厂在 MistralBackend 和 GenericBackend 之间选给自家 provider 更深集成把别的当逃生通道。通过抽象层多 providerOpenHands、Aider、Mini-SWE-Agent。都用 LiteLLM支持 100 模型。Aider 走得最远有 350 模型的注册表。通过自有传输多 providerHermes、Pi、OpenCode。这是 4 月版谱系里没有的新位置完全多 provider 但不用抽象库矩阵手写且深度不输厂商原生集成。Hermes 手写 5 个传输、29 个 provider 配置、3800 模型元数据Pi 手写 9 个 wire 协议、35 个内置 provider还玩了语料里最大胆的耦合技巧——harness 模仿harness mimicry在 Claude Pro/Max OAuth token 上整体伪装成 Claude Code 的身份系统提示开头、beta 头、连工具名的大小写都照搬来蹭消费级订阅。混合插件式OpenClaw。10 provider 的一等适配器带 auth profile 轮换。观察 2 的结论是provider 原生优化缓存边界、扩展思考、推理力度、模型专属提示并不依赖紧耦合而是取决于谁愿意付每 provider 条件代码的代价。紧耦合唯一独有的是服务端协同进化Codex 的脚手架行为——提示、推理层、工具模式、甚至多 Agent 工具生成——都由 provider 的 catalog 端点按模型发布重调不用发客户端。提示工程这部分信息量很大。论文列了每个系统的提示架构Table 6还专门读了每个系统的规范系统提示抽出重复出现的修辞轴身份与人设从极简Mini-SWE-Agent“你是一个能操作计算机的有用助手”到 elaborate。Codex 的 GPT-5.2 提示最直白地体现模型耦合“你是运行在 Codex CLI 里的 GPT-5.2”而 5.5/5.6 逐渐淡化成你是 Codex一个基于 GPT-5 的编码 Agent。冗长度控制11 个里有 9 个有明确的冗长指令但实现差别很大。OpenCode 最激进“你必须用少于 4 行简洁回答……一个词最好”还配示例块。Mistral Vibe 保持 150 词预算。禁用短语和禁忌表面形式Mistral Vibe 首创禁用词表“robust/elegant/seamless/powerful/Great!…”还保留语料里最严的 emoji 禁令。反镀金指令anti-gold-plating几乎普遍——告诉模型不要扩大需求。Claude Code、Mistral Vibe、Codex、OpenHands、OpenCode、Hermes 六个各自独立开发的脚手架都预判了同一个失败模式LLM 在欠指定需求上过度交付用修辞上近乎同构的措辞回应。读后再改、验证后再声称。Git commit 策略一个已经瓦解的收敛。这是很有意思的一段4 月时这是语料里最紧的修辞收敛——每个提到 git 的提示都禁止自主 commit。到 7 月分化成三路禁止在 Claude Code、OpenCode、Hermes、Codex 5.2 里存活Mistral Vibe 反过来删掉了永不 commit硬规则改成主动教模型怎么 commit 并强制加 Co-Authored-By 签名尾注Codex 最新提示则完全丢掉了这条规则。唯一普遍保留的是外边界没有任何提示允许自主 push、force-push 或改写历史。作者点评4 月的 commit 收敛不是一个稳定的工程结论而是信任校准的一个快照——而信任在一个季度里明显移动了。观察 3提示修辞在工程经验收敛处收敛然后随信任校准而变薄。反镀金语言在六个独立系统里近乎同构不自主 commit 规则在 4 月普遍。到 7 月这些规则进入生命周期Mistral Vibe 把禁止反转成指导Codex 最新模型代次把 commit 规则和反镀金指令都从提示里删掉——行为策略在变薄因为模型把这些规范内化了。三个修辞策略并存harness 强制的策略散文、结构化契约Mistral 的七级指令层级、近乎完全委托给用户上下文Pi 的 30 行提示。所有十一个系统里稳定的不变量是没有任何策略级的拒绝语言——对齐工作从不在 harness 提示里重复。工具与动作系统工具系统定义 Agent 能做什么。工具数量从 1 个到 109 不等Figure 3Mini-SWE-Agent 只有 bashPi 建 7 个默认暴露 4 个Mistral Vibe 12Aider 13 种编辑格式OpenCode 17OpenHands 25Codex 25-30Gemini CLI 35Claude Code 43Hermes 69OpenClaw 109。文件编辑策略是 SWE Agent 的核心动作十一个系统实现了八种根本不同的策略Table 7Claude Code精确字符串替换靠文件里唯一子串匹配。Codex*** Begin/End Patch统一 diff hunks自定义 patch DSL。Aider13 种格式SEARCH/REPLACE、udiff、diff-fenced…模糊匹配用 diff_match_patch还有独特的 RelativeIndenter用 Unicode 标记把绝对缩进转成相对变化。Gemini CLIold/new 字符串工具级联匹配精确 → 空白灵活 → 正则 → 模糊最后接一个别的系统都没有的 LLM “edit fixer” 子调用。Hermes一个 patch 工具9 策略模糊链。OpenCode按模型切换编辑方言GPT 系用 Codex 式 patch DSL别的用 SEARCH/REPLACE9 阶段替换级联。观察 4文件编辑策略是代码修改准确率最重要的决定因素之一而模型感知的多态不再是 Aider 独有。语料里的编辑机械现在显示出显式的跨 harness 谱系Hermes 的匹配器注释受 OpenCode 启发OpenCode 的级联致谢 Cline 和 Gemini CLI而且它在明显运动Mistral Vibe 在一个季度内从模糊 SEARCH/REPLACE 迁移到 Claude Code 式精确匹配Gemini CLI 加了 LLM 辅助编辑修复。执行与沙箱Table 8。Codex 是语料里最认真的沙箱投入Linux 上用 vendored 并在树内编译的 Bubblewrap通过 C FFImacOS 用 SeatbeltWindows 用受限 token 进程——不用容器运行时的开销就做到 OS 级隔离。Gemini CLI 是第二个跨平台沙箱者三平台栈和 Codex 一样但投入更轻因为它复用 Node 的子进程 API。观察 6以及 10.2OS 级沙箱是语料里最耗代码的能力之一但它是一个选择不是规模的后果。4 月版曾猜测最大的两个系统也是唯二跨平台沙箱者是结构性的扩大后的语料推翻了这个猜测Hermes约 642K 行和 OpenCode约 578K 行都很大却零 OS 级隔离原语把安全预算花在内容携带威胁promptware 扫描和语法感知权限上。Pi 则把不做记录成一个安全论点部分进程内沙箱很容易被误解为安全边界。内存与上下文管理十一个系统实现四种策略Figure 4线性历史Mini-SWE-Agent、递归摘要Aider 的递归折半、可插拔浓缩OpenHands 的 Condenser、阈值压缩七个系统。观察 5持久内存已经取代压缩成为上下文工程的前沿。压缩设计已经收敛11 个里有 7 个用阈值触发的 LLM 摘要现在区分这个领域的是内存写入路径。四种治理模型并存Agent 维护Codex一个沙箱子 Agent 在 git 基线的存储上合并内存、人类门控Gemini CLI抽取子 Agent 写到补丁 inbox用户通过 /memory 审查应用、模型直写但有界Hermes 的字符上限 Markdown 快照OpenHands/Claude Code 的上下文文件约定、turn 前 Agent 回忆OpenClaw 的 Active Memory 子 Agent。值得注意的是11 个系统里没有一个用基于 embedding 的检索作为主内存基板——这个发现从代码延伸到了内存。安全与权限模型范围从基本没有安全控制到多层架构Claude Code三层权限系统——Layer 1 静态 hook 规则PreToolUse 模式匹配、Layer 2 基于 LLM 的权限分类器allow/ask/deny、Layer 3 交互式用户对话approve/reject/edit。论文称之为架构上最优雅。Codex四层权限栈——Layer 1 执行策略Starlark不是 TOML4 月版曾误报成 TOML、Layer 2 生命周期 hooks事件词汇近乎照搬 Claude Code、Layer 3 Guardian一个 LLM 审批审查器、Layer 4 原生 OS 沙箱。Gemini CLI四个审批模式PLAN/DEFAULT/AUTO_EDIT/YOLO加跨平台沙箱。Hermes一个能在 YOLO 之下存活的策略地板——12 条硬线模式rm -rf /、mkfs、dd 到块设备等在--yolo下依然生效而且 YOLO 环境变量在模块 import 时就被冻结让被注入的 skill 无法在运行时翻转它。威胁模型是内容携带的对上下文文件、内存写入、MCP 工具描述、skill 安装做 promptware 扫描。Pi把没有安全基础设施记录成设计原则。OpenCode语法感知命令权限——用 web-tree-sitter 解析每个 bash 命令always allow授权按一个约 130 条、明确由 LLM 生成的命令元数词典来定范围git→2npm run→3产生像git commit *这样的授权而非 blanket 批准。多 Agent 编排11 个里有 9 个支持多 Agent这是语料里最分散的维度。论文识别六种模式Figure 6单 AgentMini-SWE-Agent、Aider、Pi 核心、顺序委派Mistral Vibe、并行子会话OpenHands、OpenCode、带 fan-out 的分层线程树Codex、递归组合Claude Code、注册表 跨进程协议Gemini CLI、OpenClaw、Hermes swarm。观察 7协调者-工人模式在语料里独立出现了七次。实现各有侧重Claude Code fork 上下文并在子代间共享提示缓存省成本、Codex 建带深度的线程树隔离与规模、Gemini CLI 用对称本地/远程会话协议抽象调用可移植、Mistral Vibe 进程内顺序跑子 Agent简单、Hermes 交集工具集并默认 block 递归遏制。扩展机制Skills 反超 MCP两个跨切面的扩展标准MCP 和 skills。MCP8/11 系统支持所有四个 provider 原生 OpenHands、Hermes、OpenCode、OpenClaw。语料里唯一的原则性拒绝者是 Pi文档里 outright 拒绝 MCP——“用带 README 的 CLI 工具”。Skills9/11 系统实现某种 skill 系统只有 Aider 和 Mini-SWE-Agent 省略。格式基本通用一个以 skill 命名的目录含一个带 YAML frontmatter 的 SKILL.md。.agents/skills/这个 agentskills.io 标准路径被六个系统接受。最尖锐的互操作数据OpenCode 故意搜索竞争对手的家目录~/.claude/skills所以为 Claude Code 装的 skill 能原封不动地在 OpenCode 里用。观察 8Skills 已经反超 MCP成为语料里采用最广的扩展标准——9/11 对 8/11。4 月时两者 tied at 6/87 月因为 Pi 实现 agentskills.io 却明确拒绝 MCP 而打破了平局。三个二阶发展标志这层成熟了延迟加载成为近乎通用的策略9 个 adopter 里 8 个条件激活Claude Code 的 paths、OpenHands 的 PathTrigger、OpenClaw 的 requires把 JIT 上下文工程推进到扩展层供应链出现了——四个系统有托管注册表Hermes 有信任层和隔离OpenClaw 有来源验证甚至还出现了非人类作者的 skillHermes 的自我改进循环、Gemini CLI 的抽取 inbox。两个横跨观察没有框架没有代码 RAG这是全文最著名的发现。观察 9在大约 400 万行 Python/TypeScript/Rust 里没有任何一个生产 Agent 运行时 import 通用 agentic 框架LangChain、LangGraph、AutoGen、CrewAI 等十几个都查了Gemini CLI 连 Google 自家的 Genkit、ADK 都不用也没有任何一个用基于向量 embedding 的 RAG 检索代码。每个循环都是手搓的asyncioOpenHands、Mistral Vibe、Hermes、阻塞同步 PythonAider、Mini-SWE-Agent、Promise/async-iteratorClaude Code、Gemini CLI、Pi 等、TokioCodex。每个工具注册表都是自建的Pydantic、Zod、TypeBox、Effect Schema、Rust enum。代码检索全靠 ripgrep、tree-sitter、glob、自动发现的 Markdown 上下文文件。为什么作者给的理由很实在代码带着密集的确定性结构元数据文件路径、语言服务器、tree-sitter 解析、类型信息这是语义相似度检索复制不了的代码分分秒秒在变预索引的 embedding 几乎天生就过期每个编码环境都已经自带一个近乎最优的检索系统ripgrep、find、glob。在典型 SWE-agent 任务上RAG 加了运营成本却不给边际价值。观察 10 补充Anthropic 的 Effective Agents 工程系列2024.12–2025.9里描述的架构模式和四个 provider 原生系统独立开发的架构高度吻合。智能体间协议ACP 的三重角色观察 11 记录了变化最大的一块。ACPAgent Client Protocol现在在 11 个系统里的 6 个中作为一等依赖或实现出现并且扮演三个不同角色Editor → agent对外服务像 ACP 的 LSP 角色Zed、JetBrains 等 IDE 像驱动语言服务器一样驱动本地 Agent。Agent-as-backend对内托管4 月没人扮的角色——OpenHands 的 ACPAgent 把它的 step() 委派给外部 ACP 服务器rival harness 变成 OpenHands 对话里可互换的大脑。为编辑器而造的协议结果成了托管的接口。跨厂商 meshA2A仍是 Gemini CLI 独有。对实践者的建议很尖锐建一个 ACP 服务器它一次给你编辑器、托管者和元编排器三个受众把自己的子 Agent 留在进程内把 A2A 当作对跨厂商 mesh 的下注——可辩护但未证实。平台化转折harness 从工具变成了平台这是论文的中心论点第 14 节。2025 到 2026 年中编码 Agent harness 完成了一次从工具到平台的转折——一个有自己的扩展生态、package 经济、治理层、切换成本和2026 年 6 月起自己的元层的运行时。四个收敛信号支持这个解读Skills 即声明式程序一个 skill 功能上就是一个为 LLM 运行时而非 CPU 运行时写的程序。Hooks 和事件总线作为扩展基板9/11 系统有用户可见的生命周期 hooksPi 本身就是一个带约 33 个类型化事件的事件总线。工具与工作流边界的消失Agent 循环就是工作流引擎。harness 作为服务表面OpenCode 内嵌 HTTP 服务器发 OpenAPI 和 SDKOpenHands 通过 OpenAI 兼容网关暴露对话Mistral Vibe 把本地会话传送到托管运行时。harness-框架合并14.2如果 harness 就是框架那这两类应该合并——2026 年它们正从两个方向合并。Claude Agent SDK、openai-codex、OpenHands agent SDK 是harness → 框架LangChain 的 Deep Agents、Pydantic AI Harness、Strands harness-sdk 是框架 → harness。双方收敛到同一个制品形态循环 工具 skills 子 Agent hooks MCP 会话。那个 2025 年代框架的双重缺席由此得到历史性的解释harness 没有采用那些框架它们取代了框架、自己变得可 import把我该用哪个 agentic 框架这个问题变成了你已经在跑哪个 harness。平台经济学14.3市场Codex 的插件市场、四个系统的 skill 注册表、切换成本Codex 为 Claude Code 的磁盘状态写了 importer把~/.claude/projects的 session JSONL 转成 Codex rollout、企业治理Codex 的配置栈延伸到 MDM、主机级、企业云下发。元 harness 层14.4Databricks 2026 年 6 月开源的 Omnigent 不是第十二个 harness它是押注harness 已成商品组件持久价值在它之上那一层。约 100 万行其中 312K 生产 Pythonregistry 里有 23 个规范 harness 适配器形式化成五种集成模式声明的能力要过一致性 benchmark——harness 被像硬件一样测试。它在众多 harness 之上加了四样东西组合任一 registry harness 都能作为另一家的子 Agent 会话、跨 harness 策略、统一沙箱和出口栈、可分享会话。它的旗舰示例 Polly 是一个跨厂商协调者-工人一个 Claude Code 大脑的编排者自己不写代码把活 fan-out 给六个厂商 harness并强制跨厂商审查审查者必须是和实现者不同的厂商。90 天的 harness 演化14.5因为 4 月版的八个系统是被 re-pin 而非替换语料里含着一个受控纵向样本。四个动向收敛变成模仿Codex 照搬 Claude Code 的 hook 事件词汇OpenHands 采用 Claude Code 的插件格式、模式向下扩散、策略移出散文Codex 最新提示把 no-commit 和反镀金规则换成 feature flag、树本身以平台速度移动Codex 工作区一个季度几乎翻倍621K→112 万行。观察 12 总结编码 Agent harness 在 2026 上半年完成了平台转折竞争的单元不再是 Agent 循环而是它周围的生态表面。18 条设计建议与 90 行最小可用 harness论文第 16 节把观察蒸馏成 18 条可操作建议每条都锚定在引用的观察和实现它的系统上。挑几条关键的建议 1从线性 while 循环开始只有当出现正交的 turn 策略时才升级到中间件管道。建议 3从一个 bash 工具开始只在观察到失败模式时才加工具。建议 4工具数超过约 15 个时采用延迟工具加载。建议 5让编辑工具契约匹配你的模型档位——前沿模型用精确唯一子串替换开放/弱模型用模糊级联。建议 8 / 16不要为代码建 RAG用 ripgrep、glob、tree-sitter。建议 15不要用 LangChain、LangGraph、AutoGen、CrewAI 等做 Agent 运行时。建议 13建一个 ACP 服务器把自己的子 Agent 留在进程内。作为具体起点Listing 3 给了一个约 90 行的 Python 最小可用 harness融合了上面推荐的模式线性循环、中间件式策略、四工具表面bash/read/write/search_replace、分层 Markdown 上下文自动发现、阈值压缩。观察 13 说它直接实现了 18 条建议里的 10 条和其余 8 条兼容——没有框架依赖、没有 RAG、没有向量库、没有多 Agent、没有沙箱正好对上双重缺席。总结这篇论文给编码 Agent harness这个年轻学科交出了一份我认为是迄今最扎实的实证基础。它不做 benchmark、不排名而是把十一个生产系统对着源码逐个解剖再叠加一段 90 天的纵向 diff——这种读代码而非跑分的方法论在这个跑分数据大多自报、模型配置月月变的领域里反而更可信。我最在意的几个点双重缺席无框架、无代码 RAG是最反直觉也最有解释力的发现。它和 Anthropic 的工程建议、以及 AHE 自动演化 harness 的消融结果互相印证——结构性 scaffold 比散文式提示策略更可移植。平台转折的论证是有力的harness 变成可 import 的 SDK框架厂商反过来造 harness元 harness 出现竞争单元从循环移到生态表面。读的时候我会想这和当年 IDE、操作系统走过的平台化之路确实像论文自己也点了这一点。安全是昂贵的且是选择。这个结论纠正了大系统自然有沙箱的直觉对要做企业部署的人是个提醒。需要提醒的是论文的局限它自己在 Threats to Validity 里说得很坦白它基于源码阅读而非运行时测量Claude Code 用的是流传的 3 月快照而非官方发布可复现性最弱框架缺席的查找没有追踪动态 import 和转译产物。另外文中所有 benchmark 数字都是系统自报、模型和配置各不相同别拿末位小数当真。一句话如果你在做或想用编码 Agent这篇值得逐节读——尤其是第 16 节的 18 条建议和那份 90 行 scaffold基本是可以直接抄来专门化的起点。参考资料论文本体HTML: https://arxiv.org/html/2609.00006v1论文摘要: https://arxiv.org/abs/2609.00006文中涉及的主要系统与项目OpenHands: https://github.com/OpenHands/OpenHands 新版 SDK: https://github.com/OpenHands/software-agent-sdkAider: https://github.com/Aider-AI/aiderMistral Vibe: https://github.com/mistralai/mistral-vibeHermes: https://github.com/NousResearch/hermes-agentPi: https://github.com/earendil-works/piOpenCode: https://github.com/anomalyco/opencodeGemini CLI: https://github.com/google-gemini/gemini-cliMini-SWE-Agent: https://github.com/mini-swe-agent/mini-swe-agentOmnigent: https://github.com/omnigent-ai/omnigent相关标准与厂商工程文章Anthropic《Building Effective Agents》: https://www.anthropic.com/engineering/building-effective-agentsAnthropic《Effective Context Engineering for AI Agents》: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agentsAnthropic《Writing Effective Tools for AI Agents》: https://www.anthropic.com/engineering/writing-tools-for-agentsAnthropic《How We Built Our Multi-Agent Research System》: https://www.anthropic.com/engineering/multi-agent-research-systemLangChain Deep Agents: https://docs.langchain.com/oss/python/deepagents/overviewAgent Client Protocol: https://agentclientprotocol.com/agentskills.io: https://agentskills.io/