长任务 Harness Engineering：让编码 Agent 跑完6小时的工程方法

让 agent 跑完一夜的，不是模型，是它周围那套工程

凌晨两点你下班，给编码 agent 留下一个"把这个原型补成可用应用"的任务，第二天早上回来希望看到 PR 已经躺在那里等你审。OpenAI 团队自述，他们经常看到单次 Codex 运行在一个任务上连续工作超过六个小时，多半就在人类睡觉的时间段。能不能稳住这种六小时、跨多个上下文窗口的运行，决定权不在模型本身，而在围绕模型搭起来的那套工程系统（通常被叫做 harness，挽具）。换句话说，让 agent 跑过几小时甚至几天的关键，是搭一套能管上下文、强制约束、提供反馈、跨会话延续状态的外壳。这个判断在 LangChain 那里被压成了一个公式：Agent = Model + Harness。原始模型不是 agent，是 harness 给它接上了状态、工具执行、反馈回路和可强制执行的约束，它才成为 agent。想从更高的视角看这套挽具由哪些组件拼成，可以参考 harness engineering 总览 的整体地图。

光说"换更强的模型不行"还不够具体。Anthropic 在自家长任务实验里反复看到两类绕不开的失败。第一类是 agent 倾向于一次 one-shot 整个应用，常常实现到一半上下文耗尽，下一节会话接手时面对的是一个写了一半、没文档的烂摊子。第二类发生在项目后期，新一轮 agent 实例环顾四周，看到已有进展，就直接判定"任务完成"宣告退出。这两类失败的共同点：再怎么改 prompt，也阻止不了模型在第三万个 token 处忘掉自己最初要做什么，也阻止不了它把已有代码误读成最终交付物。

模型基准分单看本身就会骗人。有一项被多方引用的对比数据：同一个模型，仅仅更换文件编辑接口的调用方式，编码基准分从 6.7% 跳到 68.3%。 同一颗"脑子"，外面套不一样的工具壳，分差能拉到十倍量级。这是 harness 工程价值最直白的证据。决定 agent 表现的，是模型加上它能用的工具、它走的流程、它撞墙后被谁拽回来。

所以"harness engineering for long running"这件事，本质上是在围绕模型搭六条线：上下文怎么管（不让窗口被填爆）、状态怎么跨会话延续（让下一段会话知道上一段做了什么）、工具怎么暴露（既够用又不淹没模型）、反馈怎么回流（编译错误、测试失败、端到端验证结果怎么注回 agent）、多主体怎么编排（谁规划、谁实现、谁审查）、记忆怎么分层（哪些落盘、哪些常驻、哪些当下加载）。

让 agent 跨会话跑下去的三种核心模式

长任务 harness 长什么样，可以从三种已经被生产团队反复验证的模式入手。它们解决的是同一个问题：单个会话装不下整件事，让 harness 接管会话之间的连续性。如果你需要先看清整套零件再回来看这三种模式，可以回到 harness engineering 总览，了解组件全貌。

三种模式各自管一段：会话续命靠 Ralph Loop，状态延续靠二段式，行为约束靠前馈和反馈配对

Ralph Loop：用钩子和文件系统把单会话拼成多会话。 LangChain 把这个模式拆得很清楚：钩子拦截模型的退出动作，把原始 prompt 重新注入一个干净上下文窗口，强制 agent 继续推进。每轮迭代起步都是干净的，但通过读写文件系统拿到上一轮的状态。OpenAI 在 Codex 上把这套机制用得很激进，指示 Codex 在本地审核自身改动、请求本地和云端 agent 审查、对反馈做出回应，循环到所有 reviewer 都满意为止（团队内部把它直接叫 Ralph Wiggum 循环）。LangChain 的 PreCompletionChecklistMiddleware 是这个模式的一个具体应用：在 agent 准备退出前拦下它，对照任务规格再跑一遍验证。

Ralph Loop 落到 Claude Code / Codex CLI / Cursor 上的最小骨架

落到具体 agent 工具上，2026 年的现状是三个主流 CLI 都给了官方钩子位，不用自己挖：

• Claude Code：用 Stop 事件钩子。模型尝试结束会话时 Stop 钩子触发，脚本读 stdin 上的 JSON 拿到当前 transcript_path 和 stop_hook_active，决定是否往 stdout 写一段"还没完，请继续 X"的 JSON 把会话续上。社区现成的 /ralph-loop 命令把这套封装好了，调用形如 /ralph-loop "把当前 PR 跑通端到端测试" --max-iterations 10 --completion-promise "DONE"，--max-iterations 是真正的安全开关，--completion-promise 只是结束信号 [CLAIM_MAP
  ]。
• Codex CLI：同样在 hooks 里支持 Stop 事件。要让 Codex 在尝试退出时继续干，hook 脚本回 {"decision": "block", "reason": "再跑一遍测试，把红的修了"}，Codex 会基于 reason 生成续作 prompt。payload 里有 stop_hook_active 字段判断"这次是不是已经被钩子续过一次了"，避免无限循环 [CLAIM_MAP
  ]。
• Cursor：用 hooks 里的 followup_message 字段。任何 hook 返回非空 followup_message，Cursor 会把它当作下一条用户消息自动提交，agent loop 就接着跑。2026 年的 Cursor Background Agent 默认 Agent Loop 也支持 test-run-fix 自动迭代 [CLAIM_MAP
  ]。

三处统一可以归到同一最小骨架：钩子守在退出节点，状态文件守在文件系统（最常见的是 progress.json 和 todo.md），迭代上限和结束条件分两个变量管。上限是硬刹车，结束条件是软信号。新手最容易栽的坑是只设结束条件不设上限，模型一直说"我马上就好"但永远不打那个结束字符串，账单和上下文同时炸掉。

Anthropic 二段式：initializer 一次、coding agent 多次。 Anthropic 的做法是把长任务切成两个角色。一个 initializer agent 在首次运行搭好环境、把用户的初始 prompt 扩展成一份需求文件，在 claude.ai clone 实验里这份清单里有 200 多个特性，每个最初标记为 failing。之后每个会话由 coding agent 接手，做增量进展并留下交接产物。两个工程细节值得抄走：特性清单用 JSON 不用 Markdown，因为模型不太容易擅自改 JSON；coding agent 每次推进都要 git commit 带描述性 message 并把进展写进进度文件，这样 harness 在出错时可以用 git 回退到可工作状态。Firecrawl 概括的两阶段结构（一次性初始化阶段 + 重复运行阶段）讲的是同一类骨架。

feedforward 配 feedback：行动前引导，行动后纠错。 Martin Fowler 网站把 harness 控制拆成两类。feedforward 在 agent 行动前引导它（像类型系统、lint 规则、AGENTS.md 这类预先约束），feedback 在 agent 行动后让它自我纠正（像 typecheck、测试、LLM-as-judge 这类传感器）。两边必须配对。只有反馈的 agent 会反复犯同一个错，只有前馈的 agent 会编码规则但永远不知道规则是否生效。Fowler 还把传感器再分成 computational（CPU 上的确定性快速检查，毫秒到秒级）和 inferential（GPU 上跑的语义判断、AI 代码评审，慢且贵但更丰富）。HumanLayer 的写代码 hook 把这条原则做成了一句口号：成功要静默、失败要冗长，退出时跑 biome 加 typecheck，通过时一句不说，失败时把错误注入回上下文并强制 agent 继续修。Mitchell Hashimoto 给整个套路下了一个更长期的定义：每次发现 agent 犯错，就花时间工程化一个解决方案，让它以后再不犯。两类缺一，长任务会在某处静默失败而 harness 不知道。

最小可用的前馈三件套和反馈三件套（Next.js 和 Python 项目通用）

普通业务项目想把这套配对落地，不用一上来就搞全套。两种栈都可以从下面这套最小组合起步，先把"模型在行动前知道规则、行动后立刻吃到错误"这条回路跑通：

• 前馈三件套（Next.js）：
  • AGENTS.md 写 30 行以内，只列三类东西：这个仓库写代码的硬约束（比如"不用 next/image"）、目录速查（哪类代码放哪）、运行命令；
  • 严格 TypeScript（strict: true、noUncheckedIndexedAccess: true），让类型系统直接当传感器；
  • ESLint 自定义规则 + import 边界规则（eslint-plugin-boundaries 或 @typescript-eslint/no-restricted-imports），把分层约束钉死，比如禁止 app/ 直接 import db/。
• 反馈三件套（Next.js）：
  • pre-commit / Stop 钩子里跑 tsc --noEmit && next lint，通过静默、失败把错误 JSON 注回 agent 上下文；
  • 一组针对核心路径的 Playwright 端到端测试，对应 Anthropic 那条"agent 看不见端到端"的教训；
  • PR 上跑一个独立 evaluator agent 做 LLM-as-judge，专挑"代码能跑但语义错"这一类（典型例子是 server action 拿错权限）。
• 前馈三件套（Python）：
  • AGENTS.md 同样 30 行内，写依赖管理工具（uv / poetry）、运行入口、类型规范；
  • mypy 或 pyright 开 strict 模式，配合 Pydantic 模型作为数据契约；
  • ruff 自定义规则做架构边界（比如禁止 services/ 反向 import api/）。
• 反馈三件套（Python）：
  • Stop 钩子跑 ruff check && mypy --strict，错误格式统一为 ERROR: file:line: reason 方便 grep；
  • pytest 跑核心路径的集成测试，关键链路套一层 schemathesis 或 Hypothesis 自动生成的属性测试；
  • 同样在 PR 阶段挂一个 evaluator agent 看语义层面的问题。

题主问的"AGENTS.md 一行规则 + ESLint 自定义 rule + pre-commit hook 是不是就够了"，答案是够起步的最小集，但要注意几条边界。AGENTS.md 那一行规则必须对应一条 ESLint 或 typecheck 能机械执行的检查，否则就回到了 OpenAI 那句"不能机械执行的约束 agent 迟早会偏离"。pre-commit 还要捕获 agent 退出时的状态，否则它跳过 commit 直接 push 上下文，pre-commit 永远不会跑。这套最小组合的目标不是覆盖所有失败，是把"前馈和反馈都没有"这个 0 推到 1，剩下的按照"见到一类失败就加一条对应约束"的节奏长。

这三种模式还要解决一个让人不太舒服的事实：模型不会主动做端到端验证。Anthropic 观察到 Claude 在未被明确指示时常常改完代码、跑完单元测试、用 curl 戳一下 dev server 就判定特性完成，并不验证整条链路是否真的可用。他们的解法是给 Claude 接入 Puppeteer MCP 做端到端验证，性能显著提升。换句话说，feedback 这条线还要包含 agent 自己看不见的那层，光靠 typecheck 远远不够。

最后还有一条平台层的伏笔：上面这些模式都假设 agent turn 能跑完。Cloudflare 给出的现实是 agent turn 根本不是单次请求。模型流式输出 token、调用工具、等待结果、有时要等人审批或派子 agent，整段序列可能几秒到几分钟，任何一点崩溃，内存里的流连接、待执行工具调用和 turn 状态会全部丢失。Claude Code 新推出的 dynamic workflows（Claude 在运行时写 JavaScript 把工作派给数十个子 agent）就是这种压力的极端形态：harness 自己提供不了，必须由平台做持久化执行，持久化每一步、重试失败、在中断后从断点恢复。Ralph Loop 的钩子重注入是会话级的续命，平台层的持久化执行是 turn 级的续命，两者解决的是不同尺度的同一类问题。

三主体架构：把生成和评审拆开，是单 agent 之外最便宜的杠杆

单 agent 自评几乎总会给自己打高分。Anthropic 团队的观察很直白：让生成 agent 一边写代码一边反思自己写得怎么样，结果几乎总是"看起来不错"。同一个脑子既造问题又判定问题，没办法变得真正苛刻。把判定权交给另一个独立的 evaluator agent 才是可行的杠杆，因为调一个外部 evaluator 让它挑剔，比让 generator 自己学会自我批判容易得多。一旦外部反馈存在，generator 就有了具体可以对着改的目标。Anthropic 借鉴 GAN 的对抗思路，在这个基础上搭出 Planner-Generator-Evaluator 三主体架构，专门跑多小时的自主编码会话。

同一句 prompt：单 agent 20 分钟 9 美元 vs 三主体 6 小时 200 美元

把同一句话提示分别交给单 agent 和完整三主体 harness，Anthropic 公布的对照数据是这样的：

方案	耗时	成本	产物
单 agent（solo）	20 分钟	9 美元	半成品，玩不起来
完整三主体 harness	6 小时	200 美元	完整可用的应用

贵 20 多倍，但质量差异立刻看得见。这条数据给读者的判断很清楚：如果任务只是改几个文件、跑几个小时就能交付，单 agent 已经够用。只要任务规模到了"要造一个完整可跑的东西"，那 20 倍成本换的是从"半成品"到"可用"，是质量上 0 和 1 的差别，不是几个百分点。

这个 20 倍倍率换到 CRUD 中后台还成立吗？双主体有没有数据

题主问的换成普通业务（内部管理后台、CRUD-heavy 中后台）这个 20 倍是否成立，以及 generator+evaluator 双主体的中间档成本，先说结论：Anthropic 公开的对照只覆盖了 DAW 这类完整全栈应用，没有 CRUD 中后台的同句 prompt 公开数据，双主体作为独立中间档的成本基准也没有公开的横切对比。能拿到的最接近的旁证来自 Artificial Analysis 的 Coding Agent Index：同一个模型套不同 harness，单次任务成本能从 0.07 美元到 2.26 美元跨 32 倍，而代码质量几乎一致。这条数据说明"harness 设计本身就是成本变量"，但具体到三档之间怎么分摊还得自己跑数 [CLAIM_MAP

]。

对 CRUD 中后台，20 倍这条倍率几乎肯定不该照搬。CRUD 的特征数据库 schema 决定了大部分代码，列表/详情/表单这套范式很重复，验收标准（增删改查通不通）相对客观，evaluator 能拦的"坑"远没有全栈应用多，三主体里 evaluator 那一节带来的边际收益会被压扁。靠谱的工程做法是先按双主体起步：generator 主写 + evaluator 只在 PR 关口跑一次（对应 Anthropic 升级 Opus 4.6 之后把 evaluator 改成"最后一次检查"那一档的形态），算上后者的一次性 token 成本，量级一般落在 1.5 到 3 倍单 agent。只有当你能列出 evaluator 真正需要拦下的两三类典型故障（比如"权限边界没考虑"、"事务边界写错"），并且这些故障在单 agent 跑下来时确实频繁出现，再考虑往上加专门的 Reviewer 节点。具体数字得自己在自己的仓库上拿一组样本任务跑 A/B，没有公开基线可直接抄。

Sprint Contract：让 generator 和 evaluator 在写代码前先把"算通过"谈清楚

三主体真正起作用的细节在 sprint 这一层。Anthropic 跑游戏生成器的实验里，planner 把一句话 prompt 扩成 16 个特性、分到 10 个 sprint。每个 sprint 开始前，generator 和 evaluator 先协商一份 sprint contract：这次 sprint 要实现哪些具体细节、用什么可测试的行为来验收。等 generator 真正动手时，它面对的是一份双方都签过字的验收单。evaluator 验收时也不会临时改标准。这套机制把"评审随心情飘"这件事提前钉死在合约里，避免长任务里最常见的"写完了发现根本不是要的东西"。

Opus 4.6 之后：拆掉 sprint，evaluator 改成最后一次检查

模型变强之后这套结构要怎么动？Anthropic 自己给了答案。升级到 Opus 4.6，他们把 sprint 拆分整个去掉，让 generator 一次性贯穿整个 build，evaluator 也从每个 sprint 检查一次改成只在最后做一次检查。同一个 DAW 实验，新版 harness 跑下来约 3 小时 50 分钟、124.70 美元，比 Opus 4.5 时代的 6 小时 200 美元又便宜了一截，质量没有掉。这件事给读者的暗示比成本本身更重要：harness 的每一个组件都编码了"模型当下做不到某件事"的假设，模型变强之后，这些假设要拿出来重新核一遍。Sprint Contract 这种为了对抗"generator 中途跑偏"而存在的结构，等 generator 不再跑偏，它就成了死代码，该拆就拆。

腾讯云的六主体扩展：模型差异化 + 权限隔离 + VERDICT 协议

三主体之上还有人继续叠。腾讯云开发者社区的一篇实战文章把它扩成六主体流水线：用户需求 → Planner → Generator → Code Reviewer → Security Reviewer → QA Engineer → 交付。三处细节值得关注。

• 模型差异化：Planner 和 Reviewer 用 Opus（推理更强），Generator 和 QA 用 Sonnet（执行更快）。重思考的节点上贵模型，重产出的节点上快模型。
• 权限隔离：Code Reviewer 和 Security Reviewer 没有 Write 和 Edit 权限，只能读、只能分析。评审者拿不到改代码的手，评审独立性是被工具权限钉死的，不是被 prompt 嘱咐出来的。
• VERDICT 协议：Reviewer 和 QA 的输出必须以 VERDICT: PASS 或 VERDICT: FAIL 结尾。"代码看起来还行"这种主观判断被强制翻译成二元信号，流水线下游可以纯靠 grep 这个字符串决定是否进入下一节点。

这套扩展属于"任务规模再上一档"才划算的范围。简单工具型应用上三主体已经够，到了多模块协作、合规要求明确、长期持续交付的产线，六主体的拆分才开始把人力评审的成本省回来。

自检：什么任务上单 agent，什么任务上三主体，什么任务才值得上六主体

读者最该问自己的不是"哪种架构最先进"，而是"我手上这个任务在哪一档"。一个简单的自检办法：

• 任务能在一两小时内由单 agent 一遍跑完、产物你自己 review 一遍就敢合并的，继续单 agent，加三主体只是徒增成本。
• 任务规模到了"我自己 review 一遍要花半天、还容易看漏"，这是 generator 和 evaluator 该分家的信号。三主体的 evaluator 替你做第一道把关，省下来的人工 review 时间够覆盖 20 倍成本。
• 任务涉及多个模块协同、有明确安全或合规审查要求、且这条流水线要长期跑，这时候才把 evaluator 进一步拆成 Code Reviewer / Security Reviewer / QA Engineer，并用权限隔离和 VERDICT 协议把评审独立性焊死。

至于三主体之外别的 harness 组件怎么和这套架构拼起来（上下文管理、长任务记忆、失败模式拦截、生产团队的实测数据），可以回到 harness engineering 总览看完整的组件图。

上下文会"锈蚀"：长任务 harness 必须对抗的物理约束

LangChain 把这种现象叫 context rot（上下文锈蚀）：模型在上下文窗口被填满的过程中，推理和完成任务的能力会变差。Chroma 在 18 个模型上做 needle-in-a-haystack 测试发现，性能随上下文长度增加而下降，当问题与相关信息的语义相似度低时劣化更陡。Dex Horthy 给出了一个更直觉的阈值：168K token 的上下文窗口用到大约 40% 时输出质量就开始明显下降，进入他所谓的 "dumb zone"，幻觉变多、兜圈子、代码变差。Firecrawl 引用的 Anthropic 内部实验把这条物理约束推到极致：Opus 4.5 在没有 harness 时无法跨多个上下文窗口完成一个生产 Web app，即便用 200k+ token 的窗口，藏在上下文中间的密集内容仍会被忽视。

三类对抗手段各管一段

LangChain 把对抗 context rot 的常见手段归成三类：compaction 在接近上限时做智能摘要并卸载老内容；tool call offloading 只在上下文里留住工具输出的头尾，把完整结果落盘供后续按需读取；Skills 用 SKILL.md 前言做渐进式披露，不一次性把所有工具暴露在上下文里。

compaction 不等于 context reset。Anthropic 的实践显示，compaction 是就地摘要保留连续性，但 context anxiety（模型感受到窗口紧张时变得焦躁、抢着收尾）还在。reset 是清空上下文从结构化交接文件重启，给一张白纸但要求交接文件够完整。Anthropic 在 Sonnet 4.5 上的测试发现 context anxiety 严重到 compaction 单独不够，必须用 reset。这一族手段和前文 Ralph Loop 的"钩子+干净上下文"是同一族。

记忆要分层放：filesystem / RAM / context window

DecodingAI 提出的三层记忆心智模型把"这条信息该放哪"变得可判断。filesystem 是长期记忆，跨会话持久化。RAM 是短期工作记忆，承载活跃会话的对话历史和工具结果，快但易失。context window 是模型实际看到的部分，最严格的约束。Letta 联合创始人 Sarah Wooders 把这条原则讲得更直接：memory 不是插件，而是 harness 本身，记忆放哪、谁拥有、什么在会话之间持久化、agent 如何检索，这些都是 harness 必须回答的工程问题。这也是回到 harness engineering 总览了解组件全貌时最容易被低估的一条线。

三层记忆心智模型让 "这条信息该放哪一层" 变成可判断的工程问题

生产 harness 长什么样：Claude Code source map 给的样本

engineerathear 引用的一个意外事件给了我们一份珍贵的样本：2026 年 4 月 Anthropic 在 Claude Code npm package v2.1.88 里意外打包进 debug source map，约 51.2 万行 TypeScript 暴露了 system prompt 的组装逻辑。system prompt 由约 40 个条件区段动态组装（不是一段静态字符串）、管理约 50 个工具定义、用 cache boundary marker 把全局可缓存内容和会话特定内容隔开、约一打种压缩/卸载/摘要方法在跑、上下文里只保留最近 5 个函数结果。一个跑长任务的生产 harness 在上下文管理上的复杂度，大致就是这个量级。

具体抓手：todo.md 背诵 + AGENTS.md 做目录

落到日常做法上有两个具体抓手。engineerathear 的 todo.md 模式让 agent 维护一个列着总目标和当前子任务的文件，每次行动前重新读取并更新，相当于把全局目标"背诵"到上下文窗口末尾，那里是注意力最强的位置，用来对抗跨 50 个工具调用的目标漂移。OpenAI 的做法是把 AGENTS.md 控制在约 100 行当目录用，详细信息散落在结构化的 docs/ 里，agent 从一个小切入点开始被指引到下一步去哪查，而不是开局就被一份豪华手册淹没。两套做法看似不同，背后是同一条原则：上下文是稀缺资源，把对当下这一步最重要的那点东西摆到最显眼的位置，其余的按需检索。

长任务 agent 的几类典型失败模式

长任务跑久了，agent 会以几种相当固定的方式坑你。把它们列在同一张表里更便于对照，左边是触发条件、中间是 harness 的拦截动作、右边是出处。这些动作和回到 harness engineering 总览，了解组件全貌里的其他机制配合，构成 harness 在长任务里的防御层。

失败模式	触发条件	harness 拦截动作	出处
单文件 doom loop	同一文件被反复编辑 N 次仍未收敛	LoopDetectionMiddleware 用工具调用 hook 跟踪 per-file 编辑次数，到达阈值后注入"考虑重新评估方案"提示，把 agent 从死循环里推出来	LangChain LoopDetectionMiddleware
Generator 风格漂移	单次执行超过 40 轮工具调用	据腾讯云开发者社区团队实测，跨过这条线代码风格一致性显著下降。对应做法是拆短 session，不让单个 Generator 跑太长	腾讯云开发者社区《Harness Engineering 最佳实践》
状态全丢	进程崩溃或被强制退出	据腾讯云开发者社区团队介绍，他们的做法是三层持久化：每个 Agent 执行完成瞬间写盘、每 30 秒定时存档、退出前再存一次，最差情况丢半分钟	腾讯云开发者社区《Harness Engineering 最佳实践》
工具集合膨胀	工具列表变长 + 工具定义把上下文塞满	Cloudflare 的做法是只给模型一个执行代码的工具，让它自己写 TypeScript 调 API，由 harness 在 Worker isolate 跑（10ms 内启动、单次约 $0.002）	Cloudflare Flue
MCP 注入风险	接入了不可信的 MCP 服务器	HumanLayer 的警告很直接：MCP 工具描述会被注入 agent 的 system prompt，不信任的 MCP 不要接。STDIO 和本地 MCP 即使没有 prompt injection 也能在宿主上执行代码	HumanLayer
自评打高分	单 agent 既写又评	把评审角色拆出来用独立 evaluator + 二元判定信号反制（如前文所述的三主体架构）	见 SEC-3

Carlini 在他那个用 16 个并行 Opus 编译器项目里给了几条值得抄的做法。日志全部写文件、不打控制台，采用 grep 友好的单行格式 ERROR: [reason]，主动减少上下文污染。测试不全部跑，每个 agent 只跑随机 1-10% 的子集，单次确定性、跨 VM 随机，整体覆盖全测试但单 agent 不会在测试上耗几小时。agent 角色逐渐专业化拆成核心编译器、去重、性能、代码质量、文档几条线（Carlini 编译器项目）。这几条都指向同一件事：运行环境本身设计得好，模型才发挥得出来。

Vercel 那条"减少 agent 可用工具数提高任务成功率"被传得很广，但 Augmentcode 的核查指出原话里"这一提升超过任何模型升级"的说法没有可核实证据支撑，不应当作已验证的结论用。方向上"工具少 = 选对率高"和 Cloudflare 的论据一致，但具体增益的量级先打个问号。

用 6 项指标量化 harness 是变好还是变坏

光知道哪些失败要拦截还不够，得有数告诉你这套 harness 是在往好走还是在劣化。Augmentcode 给的这套指标可以直接照抄：

指标	衡量什么	采集口径
Task Resolution Rate（任务解决率）	agent 正确解决任务的比例，由自动化测试判定	按 commit 或 PR 记测试通过/失败
Code Churn Rate（代码扔掉率）	写完后两周内被丢弃或重写的代码占比	每周按作者归因统计
Verification Tax（验证税）	工程师审计 AI 代码所花的时间，把生成省下来的时间又花回去多少	首次 commit 到 PR 批准的时间差
Harness Constraint Effect（约束效应）	同一批任务，加约束 vs 不加约束的成功率差	控制变量对比，模型不变
Defect Escape Rate（缺陷逃逸率）	AI 生成代码进入生产的缺陷率	每月按 AI / 非 AI commit 元数据分两条线
Pass@1（一次过率）	首次尝试就正确解决的比例，不计重试	每次评估运行记一次

Augmentcode 自己也给了反例：lines of code accepted、number of AI suggestions used 这类窄输出指标只衡量量、不衡量可靠性，不能当 harness 主信号，DORA 报告里直接警告过这条。

外部基准和内部指标得并用。 Augmentcode 的引用数据显示，顶级 agent 在 SWE-bench-verified Python 上的解决率是 65，76.8%，但 METR 发现很多通过基准的 PR 实际上不会被仓库维护者合并，基准刷得好不等于真能交付。同样的模型，engineerathear 引用 SWE-bench 数据显示，基础脚手架 23%、同模型的 250 轮优化脚手架 45%+，22 个百分点的差距来自 harness 本身。所以团队 dashboard 上既要有外部基准（看模型+harness 在公开任务上的天花板），也要有内部 6 项指标（看在自己仓库上的真实交付质量）。

写得多不等于写得好。 HumanLayer 引 ETH Zurich 对 138 个 agentfile 的研究：LLM 生成的 agentfile 反而损害性能且多花 20% 以上的成本，人手写的也只能把解题率提升约 4%；agent 在处理上下文文件指令时多耗 14-22% 的推理 token 但结果没改善。这条数据直接打脸"写一份豪华 CLAUDE.md"的常见做法。上 Harness Constraint Effect 这把尺子，才能看出哪些约束是真有效、哪些只是在烧 token。

生成省的时间被审计花回去。 DORA 报告显示，AI 采用率越高，软件交付吞吐和软件交付不稳定性同时上升，写代码省的时间常被审计代码花回去。这就是 Verification Tax 这条指标存在的理由：只看生成速度，会把代价藏在审计环节里看不见。

Defect Escape Rate 必须按 AI / 非 AI 分两条线。 Augmentcode 引 Apiiro 2025 年 9 月分析：截至 2025 年 6 月，AI 生成代码每月引入超过 1 万个新安全发现，相比 2024 年 12 月增长 10 倍。两类 commit 的缺陷分布完全不一样，合在一起看会被均值稀释，看不出 AI 这条线是不是在恶化。

信任本身是 harness 要服务的目标。 DORA 报告里 30% 的开发者表示对 AI 生成代码"很少甚至完全没有信任"，DORA 把这归类为信任架构问题。agent 行为越可预测，审查的认知负担越低，信任就越好建立。Harness Constraint Effect 这条指标在长期看也是信任建设的代理变量。

回到 harness engineering 总览看其他组件的位置时，会发现这套指标其实是把"组件假设有没有起作用"翻译成数字。没有这把尺子，前面讲的失败拦截、上下文管理、三主体架构都是凭感觉调。

真实团队跑成什么样：八条生产数据并列看

模式、机制、失败模式、指标都讲过了，回到一线团队真实落到生产环境上的 harness 长什么样。

团队 / 项目	规模与产物	harness 关键组件
OpenAI Codex	5 个月，空 git 仓库长到约 100 万行代码 / 约 1500 个 PR 合并 / 3 人扩到 7 人 / 人均 3.5 PR/天且吞吐还在增	"不手动编码"为核心理念；AGENTS.md 约 100 行做目录 + docs/ 结构化知识库渐进式披露；Types→Config→Repo→Service→Runtime→UI 强制分层；自定义 linter 报错信息直接注修复指令；后台垃圾回收 agent 扫偏差发 PR，多数 1 分钟内自动合并；Chrome DevTools 协议接入 + LogQL/PromQL 让"服务启动 <800ms"这种 prompt 可行
Stripe Minions	每周合并约 1300 个 AI 生成 PR	混合状态机：lint/push 是确定性节点、实现功能与修 CI 是 Agent 节点；预热的 Devbox 池约 10 秒分配；Toolshed MCP 集中管理近 500 个工具，每个 Minion 拿到筛选后的子集
Spotify Honk	自 2024 年中起跨数百个仓库合并 1500+ AI 生成 PR	围绕验证回路解决 agent 可靠性
Anthropic（横向对照）	二段式与三主体两条线（如前文所述，三主体 6 小时 / 约 200 美元产出完整可用应用）	用作长任务 harness 的对照基线
LangChain deepagents-cli	模型固定 gpt-5.2-codex，只改 harness 把 Terminal Bench 2.0 从 52.8% 提到 66.5%，Top 30 跳到 Top 5	"reasoning sandwich"：规划与验证两端用 xhigh、生成段用 high。纯 xhigh 因 agent 频繁超时只跑出 53.9%，high 反而 63.6%
HumanLayer	CLAUDE.md 控制在 60 行以内	每一行对应一次已观察到的失败或一条硬性外部约束
Nicholas Carlini 个体级	约 2 周 / 16 并行 Claude Opus / 约 2000 个 Claude Code 会话 / 10 万行 Rust / GCC torture 通过率 99% / 编译 PostgreSQL、Redis、FFmpeg、CPython、Linux 6.9 Kernel 等 150+ 项目 / API 成本约 2 万美元（据 JavaGuide 转述）	单人极限并发，靠脚本化串联
Manus	平均每任务约 50 个工具调用、约 100 输入输出比	缓存命中 token 0.30 美元/MTok vs 未缓存 3.00 美元/MTok（截至 2026 年 6 月数据点），10 倍价差

共性：能机械执行的才算约束

OpenAI 那句被反复转引的原话直接点出长任务 harness 的物理底线：If it cannot be enforced mechanically, agents will deviate（只写在文档里的约束不够，不能机械执行的约束 agent 迟早会偏离）。把上表横着扫一遍，能跨团队对上号的就这几件事：

• 架构边界用代码强制，不靠文档。OpenAI 用自定义 linter + 结构测试把 Types→Config→Repo→Service→Runtime→UI 这条分层 钉死，横切关注点必须从 Providers 单一接口进入。Stripe 用混合状态机把"lint"和"push"做成确定性节点，让 Agent 节点只在中间负责语义判断。共同动作是：能用确定性检查表达的事情，绝不交给 LLM 自觉。
• AGENTS.md / CLAUDE.md 当目录用，不当百科。OpenAI 把根目录的 AGENTS.md 控制在 约 100 行做目录，详细信息靠 docs/ 渐进式披露。HumanLayer 控制在 60 行以内，每行对应一次具体失败。Mitchell Hashimoto 的 Ghostty AGENTS.md 每一行也都对应一个过去的 Agent 失败案例。叠加 ETH Zurich 对 138 个 agentfile 的研究，LLM 自动生成的 agentfile 反而损害性能且多花 20%+ 成本，结论非常一致：长不等于好，每一行都得有过一次"血"。
• 错误信息直接当下一步的修复 prompt。OpenAI 自定义 linter 错误消息会在 agent 上下文里直接注入修复指令，让 CI 失败和约束违反本身就是下一轮 agent 的输入，省掉了"读报错再翻译给 agent"的中间人。Birgitta Böckeler 把 OpenAI 这套整体归成三类：context engineering、architectural constraints、garbage collection（不断增强的仓库知识库 + 确定性约束 + 定期清理 agent），是当前看到的最清晰的 OpenAI 类 harness 解剖。
• 后台 agent 反向打扫卫生。OpenAI 定期跑 后台 Codex 垃圾回收 agent 扫描偏差、更新质量等级、发起重构 PR，多数能在一分钟内审查并自动合并。这条决定了为什么 OpenAI 仓库能从 0 写到 100 万行还没塌：熵是被另一组 agent 反向压住的，不是靠人工 review。
• 让 agent 自己能验证。Anthropic 工程师 Boris Cherny 给的 2-3 倍质量提升判断很直接：让模型有方式验证自己的工作。OpenCode 选择直接集成语言服务协议（Language Server Protocol），OpenAI 选择把 Chrome DevTools 协议、LogQL、PromQL 接进 agent 运行时。共同的事是把"什么算完成"用工具变成 agent 自己能跑的检查，而不是交给后面的人。

推理预算花在两端，不要均匀摊

推理预算配置上 "两端重、中间轻"，同模型同任务能拉开 22 个百分点

LangChain 的 reasoning sandwich（xhigh-high-xhigh） 数据值得专门拎出来：纯 xhigh 反而因为 agent 频繁超时只跑出 53.9%，全 high 反而 63.6%。把推理预算集中在"开始定计划"和"结束验证"这两端、中间生成段用低一档，是当前同模型下吃到的几乎免费的提升。这条规则之所以重要，是因为它和"工具更少、状态更稳、上下文更短"那一族技巧叠加之后，能把模型替换带来的提升再放大一次。LangChain 在同样的 gpt-5.2-codex 上只改 harness 就 拿到 13.7 个百分点的提升、Top 30 跳到 Top 5，而且他们同时观察到 Opus 4.6 在 Claude Code 上 Terminal Bench 2.0 远低于同模型在其他 harness 的得分。换句话说，模型分给定，分差悬殊到 22 个百分点的差异完全来自 harness。

Claude Code 和 Codex CLI 里怎么拨这套预算

reasoning sandwich 落地不一定要自己手写 harness，两个主流 CLI 都给了官方开关：

• Codex CLI 直接提供 minimal / low / medium / high / xhigh 五档 reasoning effort，可以在 ~/.codex/config.toml 里用 model_reasoning_effort 全局设一档，也可以建多个 profile（比如一个 fast、一个 thorough），用 codex -p fast / codex -p thorough 在不同阶段切。要复刻 LangChain 那个 xhigh-high-xhigh 的样板，最直接的做法是 planner 阶段切 thorough（xhigh）、生成阶段切到默认（high）、再在 PreCompletionCheck 那步切回 thorough 跑验收 [CLAIM_MAP
  ]。
• Claude Code 提供 --effort low/medium/high/max 四档（medium 是默认），非交互模式可以在 CI 脚本里给不同步骤设不同值。想在单轮临时拉高深度而不改 session 设置，在 prompt 里塞 ultrathink 也会触发更深的 extended thinking [CLAIM_MAP
  ]。
• Cursor 目前没有把 reasoning effort 暴露成显式 CLI 标志，但 hooks 里可以在不同阶段切换底层模型（Opus 用于规划/验收、Sonnet 用于生成），靠模型分档拿到等价的"两端重、中间轻"效果。

实务建议：把 reasoning sandwich 当成一个工程结构而不是一组魔法开关。重点是"规划和验证两端独立成节点、拨高一档；中间生成节点拨低一档"，至于具体调用的是 --effort 还是切 profile 还是换模型，按你用的 CLI 选最省事的那个就行。

缓存命中是长任务里的生死指标

Manus 给出的是另一类数据：缓存命中 token 0.30 美元/MTok vs 未缓存 3.00 美元/MTok，10 倍价差（截至 2026 年 6 月数据点）。一个任务平均 50 个工具调用、100

的输入输出比意味着上下文会被反复读取。只要 prompt 前缀稳定、工具列表稳定、文件读取入口稳定，命中率上去成本就直接砍十倍。反过来，每次 turn 都重排工具列表、每次都改 system prompt 前缀，等于把 6 小时长任务的成本直接乘十。这也是为什么前面反复强调"工具 schema 稳定 + cache boundary marker + 只保留最近 N 个函数结果"，它们既是上下文管理手段，也是直接的成本控制手段。

单 agent 派 vs 大并发派：选哪边

同一份数据墙里，两条路线张力明显。

Mitchell Hashimoto 这一派坚持 一次只跑一个 agent，目标 10-20% 工作时间有后台 agent 在跑，AGENTS.md 走"每一行对应一次失败"的递进积累路线，强调人始终深度参与每一次 turn。OpenAI / Stripe / Spotify 这一派直接把并发拉到几十 PR/天、上千 PR/周量级。Carlini 把这条路推到极端的个体上限：16 并行 Opus 实例、约 2000 个 Claude Code 会话、约 2 万美元 API 成本两周做出一个 99% GCC torture 通过率的 C 编译器。

读者怎么选？两个判断维度。第一，仓库的 harnessable 程度（强类型、清晰模块边界、确定性测试是否成立，这条 SEC-9 会展开）。harnessable 弱的仓库强行上大并发，等于把 Carlini 的成本结构搬来但没他的验证密度。第二，你愿意把多少工程师时间投在 harness 本身。OpenAI 的"工程师工作的重点从写代码转向 系统、架构、杠杆作用"是这套并发要立起来的入场费。

该把自己投到三层栈的哪一层

Cloudflare 把生产 agent 栈分成的 framework / harness / runtime 三层 是当下最清晰的分工切面：framework 管工程结构、约定、集成和开发者体验（Flue）；harness 管 agentic loop（调工具、读结果、管上下文、循环到任务完成。Pi、Project Think）；runtime/platform 管 compute、state、storage 这些底层原语（Cloudflare Agents SDK）。多数读者最该亲手做的是中间这层。上表里 OpenAI、Stripe、LangChain、HumanLayer、Manus 真正不可外包的都在 harness 这一层，framework 和 runtime 越来越多被平台吃掉，harness 是当前少数还必须自己写的部分。如果你只读到这里就要动手，可以先 回到 harness engineering 总览，了解组件全貌，再决定哪一层是你团队接下来 6 个月该深投的地方。

harness 不会消失，只会移位

模型变强之后这套脚手架是不是就该退场？Addy Osmani 给出的判断是不会消失，只会移位。Opus 4.6 大体消灭了 context anxiety 这类失败模式，半年前为缓解它而写的一整类防御性脚手架确实变成了死代码，但天花板跟着模型一起上移：多日记忆策略、协调多个专门 agent、对生成 UI 做设计质量评估，这些新挑战又得搭新的脚手架。harness 的每个组件都编码了一个模型当下做不到的假设，模型变强意味着这些假设需要定期复核，发现非承重的部分就拆掉，发现新的失败模式就补新部分上去。这才是这套工程长期演化的正确姿势，想要回到 harness engineering 总览看清各组件全貌时也是同一套坐标系。

研究界已经在试着让这种复核自动化。arXiv 上的 Agentic Harness Engineering（AHE，自动演化的 harness 工程）论文给出了一个闭环：组件可观测性给每个可编辑组件文件级表示，让动作空间显式可回滚；经验可观测性把数百万条原始轨迹 token 蒸馏成分层证据语料供演化中的 agent 消费；决策可观测性给每次编辑绑一条自声明预测，由下一轮任务结果验证。论文报告 10 轮迭代把 Terminal-Bench 2 的 pass@1 从 69.7% 提到 77.0%，超过人手设计的 Codex-CLI 71.9% 以及自演化基线 ACE 和 TF-GRPO。冻结后的 harness 在 SWE-bench-verified 上以少 12% 的 token 拿到最高累计成功率，并在三个备选模型族上带来 +5.1 到 +10.1pp 的跨族提升。值得注意的是消融把增益定位到工具、中间件、长期记忆这三个事实性结构层，而不是 system prompt。散文式策略难以跨族迁移，结构化组件可以。

短期内想要观望"等模型再强一点就不用搭"的读者要小心一个反证。Firecrawl 引 Harrison Chase 的数据显示，截至 2026 年 6 月 Claude Code 这套官方 harness 自身已经超过 51.2 万行代码，并且随模型变强继续扩张而不是萎缩。更强的模型扩展了 harness 要做的事，并不会替代对它的需求。把它当作一个可观察的工业级指标：手工搭脚手架仍然是当下投入产出比最高的杠杆，AHE 这类自动演化是值得跟踪的中长期方向。

自检你的仓库是不是 "harnessable"

不是每个仓库都能被同样地 harness 化。Martin Fowler 把这点叫 harnessability：强类型语言天然有类型检查可以当传感器、清晰的模块边界让架构约束有地方落、像 Spring 这类框架已经替你抽象掉很多细节，这些属性缺一样，对应那条控制就根本搭不起来。Böckeler 进一步把它叫 Ambient Affordances（环境本身的可供性）：把 harness 套到一个没有这些属性的遗留代码库上，难度像"在从没用过静态分析的代码库上跑静态分析"。

绿地团队从第一天就能把 harnessability 烤进架构。遗留团队面对的是一个更难的悖论：harness 最被需要的地方，恰恰是它最难搭起来的地方（Martin Fowler）。这里的卡点不是模型，是环境本身。Adnan Masood 把它具象化成 Orientation Tax：agent 每次开始任务都要花数千 token 在混乱的目录里绘图，这是结构性的经济损耗。连带的失败模式是 Grep-Spree：没有结构化映射，agent 只能盲目遍历目录。对应解法是先用 tree-sitter / RepoMapper 这类工具预生成一张代码结构地图，把它注入 harness 上下文，让 agent 一进来就有地图，不用现画。

如果 Orientation Tax 持续偏高、即使加了结构映射也压不下来，说明真正的杠杆已经不在 harness 这一侧。Adnan Masood 把这条路叫 Environment Engineering：反向去重构环境本身，标准化企业 API、整平遗留数据库，让工作空间对 agent 天生可读。随着 harness 这套东西本身成熟，瓶颈正在从 agent 移到环境上。判断标准简单：harness 改一两轮还能见效，就继续搭；连续几轮都顶不住、agent 一进仓库就先烧几千 token 找路，就该把预算投到环境改造，而不是继续给 harness 加补丁。

打开你最近 5 个 agent 生成 PR 的列表，把每个 PR 里出现的失败模式或返工原因各写一行，挑出 3 条出现频率最高的；把这 3 条编码成自动化约束（自定义 lint 报错带修复指令 / pre-completion 钩子 / per-file 编辑次数上限），让 CI 在违反时失败，并在仓库根目录的 AGENTS.md（或 CLAUDE.md）里只用一行追溯到具体哪次失败。这就是你这周可以交付的第一版长任务 harness。

FAQ

Sonnet 4.5 上 context anxiety 严重到 compaction 单独不够、必须用 context reset 是什么原因？

compaction 是就地对当前上下文做摘要，保留连续性，但摘要之后的上下文仍然很长，模型还是处于接近窗口上限的状态，焦躁感（context anxiety）不会消失。Anthropic 在 Sonnet 4.5 上观察到，这种窗口紧张感让模型倾向于抢着收尾，质量变差。reset 的做法是完全清空上下文，从一份结构化交接文件重启，给模型一张白纸，anxiety 彻底解除。代价是交接文件必须写得够完整，否则下一段会话丢失关键状态。不同模型对窗口压力的敏感程度不同，Sonnet 4.5 的阈值较低。

Anthropic 长任务 harness 为什么选 JSON 存特性清单而不是 Markdown？

模型处理 Markdown 时倾向于把它当成可以自由改写的文本，容易在迭代中悄悄改掉特性状态或格式。JSON 有明确的结构和字段，模型修改 JSON 的门槛更高，不容易"顺手"改掉不该动的字段。用 JSON 存 200+ 特性清单，配合每个特性一个 failing/passing 状态标记，让 initializer 和 coding agent 之间的交接产物可以机械校验，而不是靠语义理解来判断哪些做完了。

OpenAI 团队 5 个月在空 git 仓库长出 100 万行代码 / 1500 PR / 3 人扩到 7 人是怎么做到的？

OpenAI 团队的核心理念是"不手动编码"，工程师的工作重心从写代码转向系统设计、架构决策和杠杆点判断。具体依靠几个关键 harness 组件：AGENTS.md 约 100 行做目录配合 docs/ 结构化知识库做渐进式披露；Types→Config→Repo→Service→Runtime→UI 强制分层用自定义 linter 机械执行；linter 错误信息直接带修复指令注入 agent 上下文；后台 Codex 垃圾回收 agent 持续扫偏差、发重构 PR，多数 1 分钟内自动合并；Chrome DevTools 协议、LogQL、PromQL 接入运行时，让"服务启动 <800ms"这类量化 prompt 变得可验证。这套组合让每个工程师平均每天产出 3.5 个 PR，且吞吐还在增加。

Manus 缓存 token 和未缓存 token 成本差 10 倍（$0.30/MTok vs $3.00/MTok）在长任务里为什么是生死指标？

长任务的成本结构由输入输出比决定。Manus 平均每任务约 50 个工具调用、约 100

的输入输出比，意味着 system prompt、工具定义、文件内容会在同一任务里被反复读入。只要 prompt 前缀稳定、工具列表不随机重排、文件读取入口固定，这些高频重复的输入就能命中缓存，成本直接从 3.00 美元/MTok 降到 0.30 美元/MTok。反过来，每次 turn 重排工具列表或修改 system prompt 前缀，每次都打破缓存，6 小时长任务的成本等于乘以 10。这也是为什么工具 schema 稳定和 cache boundary marker 既是上下文管理手段、也是成本控制手段。（以上为截至 2026 年 6 月的价格数据点，具体数字以 Anthropic 官网最新定价为准。）

Vercel 报告"减少 agent 可用工具数提高任务成功率"这条结论可信度到哪一层？

方向可信，具体量级存疑。"工具少 = 模型选对率高"这个方向和 Cloudflare 的论据一致：工具列表变长、工具定义填满上下文时，模型选对工具的能力确实变差，Cloudflare 为此选择只给模型一个执行代码的工具。但 Augmentcode 的核查指出，Vercel 原话里"这一提升超过任何模型升级"的说法没有可核实证据支撑。所以这条原则在方向上可以采纳，作为减少工具集合的参考依据，但"超过模型升级"这个量级的说法不应当作已验证结论引用。

harness engineering 和 prompt engineering、context engineering 到底怎么划界？

DataScienceDojo 给的那句压缩最干净：prompt engineering 塑造 agent 尝试什么、context engineering 塑造 agent 知道什么、harness engineering 塑造 agent 能做什么和不能做什么。换成可操作的边界，prompt 决定了一次模型调用里的指令；context engineering 多管"该看到什么信息"，比如 RAG、知识库注入、上下文压缩这些动作；harness 多出来的部分是这两者完全管不到的：钩子拦截退出、文件系统读写、工具权限隔离、状态跨会话延续、确定性约束（linter / 类型检查）能不能阻止 agent 真去做某件事。一句更直白的判别法：能不能"阻止"或"强制"某件事？能，就是 harness 的活；只是"建议"或"提供信息"，就还在 prompt / context 那一档 [CLAIM_MAP

][CLAIM_MAP]。

腾讯云那条"单 session 超过 40 轮工具调用代码风格一致性显著下降"的阈值是怎么测出来的？换模型会移动吗？

这条阈值是腾讯云开发者社区团队在实战里观察到的现象，文章里没有公开样本量、统计方法或可对照的指标定义，属于经验值而不是基准化结论。不同模型大概率会让这条线挪动，但具体落在哪没有公开数据。自己怎么判断 session 该不该切，可以套两个不需要观测平台的代理信号：一是 LangChain 提到的 doom loop 信号，同一文件被反复改 N 次还没收敛，基本就是该切了；二是 Dex Horthy 那条"上下文窗口用到约 40% 就开始进入 dumb zone"的物理阈值，对 168K 窗口对应 60-70K token，可以用 CLI 的 token 计数粗估。两条任一中线，就交接到下一个干净会话，不必非等到 40 轮。

OpenAI 的 AGENTS.md 100 行 vs HumanLayer 的 CLAUDE.md 60 行差在哪？新仓库该按哪个量级写？

差别不在行数本身，在每一行承担的角色。OpenAI 的 100 行是"目录"，指 agent 去 docs/ 下哪个文件查详细信息，渐进式披露。HumanLayer 的 60 行是"防错清单"，每一行对应一次具体观察到的失败或一条硬性外部约束，Ghostty 的 AGENTS.md 也是同样路数。新仓库起步建议从 60 行内的"防错清单"路线开始，仓库小、失败案例还没攒起来，没必要先搭 docs/ 目录骨架。等到 docs/ 真的复杂到需要导览、AGENTS.md 顶部就得给个"去哪找"的目录时，再过渡到 OpenAI 那种 100 行目录式风格。至于 ETH Zurich 那条"agentfile 写多了反伤性能、多花 20%+ 成本"，研究里 LLM 自动生成的 agentfile 才是负收益的主要来源，人手写的还能拿到约 4% 的提升，但前提是每一行都对应一次真实失败。如果是手抄网上模板凑长度，几乎一定会落到那 20%+ 成本里去 [CLAIM_MAP

][CLAIM_MAP][CLAIM_MAP]。