从 Harness 到 Operating Loop：Coding Agent 可托付性的控制层

2026 年 6 月，Anthropic Claude Code 负责人 Boris Cherny 在 X 上说，他已经不再直接 prompt Claude，而是写 loop、让 loop 去 prompt Claude。OpenClaw 创始人 Peter Steinberger 接力，几天后 Google 工程师 Addy Osmani 用 “Loop Engineering” 一文把这个说法命名定型，并明确称它是 “harness engineering 上面一层”。

几个人几乎同时把“手动 prompt”交给了一个自动运转的 loop。prompt 没消失，loop 里的模型照样靠 prompt 驱动；变的是发 prompt 的人：过去工程师一轮轮手动喂的活，现在由 loop 自动接管。换句话说，loop engineering 不是 prompt 的替代品，而是 harness 之上又长出的一个工程化方向。这个转向之所以值得琢磨，是它把一个隐含已久的问题摆上了台面：一个 coding agent 什么时候才算“可靠”？

往前推一年，答案通常落在模型能力上：代码能不能写对，测试能不能修好，能不能读懂仓库。Coding agent 进展飞速，开始承担日常开发的主力执行角色，但生产里的可靠性已经不再能被模型分数解释。它越来越取决于另外两个工程级对象：一个是包在模型外面的 agent harness，它决定一次任务中的行动轨迹是否可控；另一个是 harness 之上的 operating loop，它决定任务能否被持续发现、分派、验证、记录和升级。

我前阵子在读 Agent Harness Engineering: A Survey，ETCLOVG 七层 taxonomy 定义比较有架构参考性，翻完之后,印象比较深的是这篇论文把 harness 提升成一个独立的系统层。execution、tooling、context、lifecycle、observability、verification、governance 这些能力被放在同一张图里，从系统架构设计上回答了“agent 如何在真实环境里有边界地行动”。Loop engineering 再往外推一层：当agent 的行动已经能被 harness 约束，如何设计一个系统替人完成任务发现、任务续跑、验证闭环和状态写回。

可靠性的单位，已经从 answer 变成 trajectory

一个聊天应用答错了问题，你关掉对话，世界上没有任何东西被改变。模型在给出答案之前可能推理了几千 token，走过岔路又折回，但这一切发生在前向计算内部，对环境零副作用，丢弃成本为零。所以这类应用只需要评估最终文本；就算对 chain-of-thought 做监督，被监督的也仍是一段无副作用的计算。过程对系统而言是私有的。

coding agent 的中间过程没有这种豁免。它的交付物和 LLM 应用一样是结果物，小到一个修 bug 的 diff，大到一次跨模块重构或一个能直接运行的新项目，区别在抵达结果的路上。agent 的每一步是真实动作：切一个分支，改一个文件，执行一条命令，安装一个依赖。动作落下时就已经作用在环境上，花掉的预算收不回，改掉的状态要有人负责，有些操作不可逆。过程从模型内部的私有计算变成了环境中的公共事件，trajectory 因此成为一个工程对象：任务开始后的每个动作、每次错误观察、每次状态更新，以及最终留下的 diff、日志和证据。

换句话说，交付单位没有变，受控单位和验收单位变了。一个回答错了，爆炸半径就是那段文本；一条轨迹失控，爆炸半径是它途经的每一处状态：改错的文件、污染的环境、泄露的上下文、耗尽的预算、无法复现的 PR，甚至被写回项目事实源的错误状态。并且轨迹层面的风险独立于交付物的对错：即使最终 diff 是正确的，agent 中途也可能读过不该读的凭据、在错误目录执行过破坏性命令。所以验收一个 agent 的工作，验收的是 outcome 加 evidence 的组合，而不只是孤立的交付物。模型越强，越能跑得远，这类风险越明显。弱模型经常停在“不会做”；强模型的问题更像“它做了很多事，但系统不知道哪些应该被允许、哪些已经完成、哪些需要回滚”。

可以把一次 agent 任务抽象为：

τ = (task, s0, a1, o1, s1, a2, o2, ..., sn, outcome, evidence)

其中 a 是 agent 选择的动作，o 是环境返回的观察，s 是任务状态，evidence 是轨迹完成后留给 verifier、人类 reviewer 或下一轮 loop 的证据。Harness engineering 盯的是整条 τ 能否在可接受边界内演化，单个 a 漂不漂亮是次要问题。execution environment 限制 a 在哪里发生；tool interface 限制 a 怎样被调用；context policy 决定模型基于什么状态选择 a；lifecycle/orchestration 决定 s 如何读写；observability 记录 τ；verification 判断 outcome；governance 决定某些 a 是否需要提前被拦截。

ETCLOVG这篇论文没有把 harness 当成“模型外面的一圈胶水代码”，而是把它当作直接影响真实任务可靠性的独立系统层来处理，这篇论文把 real-world reliability 从模型质量里拆了出来，归到 agent execution harness 的工程质量上。[1]

ETCLOVG - 探究agent失控原因的边界

然后我们可以来扩展解读下ETCLOVG， 按这个checklist来进行分析：有没有 sandbox，有没有 MCP，有没有 memory，有没有 eval，有没有 audit。论文配套了一个按七层编码的开源项目 catalog，逐项对照本来拿来盘点一个 agent 框架缺哪些组件也够用。但 checklist 无法解释这样的问题：组件都齐了，agent 为什么还是失控。回答这类问题，需要去分析 ETCLOVG 对失控原因的边界划分。

一个 coding agent 修 bug 修坏了，原因不会只落在“模型判断错了”这一项。它可能跑在一个不可复现的本地环境里，导致它看到的失败和 CI 看到的失败不是同一个失败，这就是 Execution。它可能调用了一个 schema 模糊的工具，把 dry-run 当成真实执行，把 partial log 当成完整日志，这就是 Tooling。它可能读到了过期设计文档，或在 context compaction 后丢掉了关键约束，这就是 Context。它可能不知道什么时候该停止，重复在同一条错误路径上修补，这就是 Lifecycle。它可能没有留下结构化 trace，人类 reviewer 只能翻对话猜测发生了什么，这就是 Observability。它可能通过了一个局部测试，却没有覆盖任务实际的 acceptance condition，这就是 Verification。它可能拥有不该拥有的写权限，或者在敏感路径上绕过审批，这就是 Governance。

论文把 Observability 和 Governance 提升为一等层级，这是结合工程生成落地的考虑。许多 agent 框架把 trace、eval、permission、audit 都塞进 orchestration 的边角里，好像它们只是运行流程上的几个 hook。但生产系统里，这些能力有独立的工具栈、数据模型和责任归属。observability 要回答成本归因、延迟尾部、工具失败率、上下文漂移、轨迹重放、失败归因；governance 要回答身份、权限、审批、审计、供应链、合规、人类检查点。把它们隐藏在 lifecycle 里，短期会起来框架似乎更简洁，但长期会让节点失败归因、权限治理和回归分析失去明确边界。[3][4]

论文中的 detailed taxonomy 图把这一点表达得更细：Execution 下有 managed sandbox、browser environment、OS permission sandbox；Tooling 下有协议标准、工具描述、会话管理；Context 下有短期 active window、中期 session state、长期 memory 和 context drift；Verification 下有 pre-execution readiness、controlled execution、trace capture、multi-level judgement、regression feedback。这里的“层”划分的是控制问题的归属，跟工程实现的具体目录不需要一一对应。[2]

但是这些层还不是各管各的，它们之间会耦合。论文在 cross-cutting concerns 里专门讨论了 cost-quality-speed trilemma、capability-control tradeoff 和 harness coupling problem。执行环境越真实，启动越慢、成本越高；上下文越丰富，token、检索和压缩成本越高；验证越深，吞吐越慢；工具越多，能力越强，但 tool selection error 和 prompt injection surface 也变大；memory 越持久，连续性越好，但 provenance、staleness 和 privacy 风险也越高。[5]

所以 harness 不能只做局部优化，它更接近一个闭环控制器的设计问题：给 agent 加一个更强的工具，可能会消耗更多 context budget，改变模型选择动作的分布，也可能要求治理层新增权限审计；换一个 sandbox，可能会改变 eval 可复现性；增加一个 verifier，可能会改善质量，却降低任务吞吐。agent 分数也不能只归因于模型，因为同一模型在不同 controller、context policy、tool schema 和 recovery loop 下，会产生不同的轨迹分布。[6]

Harness 的工作是控制内层 action loop

一个 agent 系统里其实同时有两层循环在转。里面一层管一次任务的执行：模型想一步、做一步、看一眼结果、再想下一步，直到任务结束或被叫停。外面一层管任务本身：任务从哪里来，跑到一半要不要续，跑完结果写回哪里，失败了要不要重试。前者决定一次任务能不能在真实环境里可靠推进，后者决定一批任务能不能被持续地运营下去。这一节只谈里面这层，外面那层留到后面讲 operating loop 时再展开。

以 coding 场景为例，让模型从“生成代码”变成“执行软件任务”的核心逻辑，就是这个内层 loop：它组织用户、模型和工具之间的交互，让模型在上下文、工具调用、环境反馈之间循环推进。

这个内层 loop 可以简化成四个动作：plan、act、observe、update。模型基于任务和上下文形成计划，harness 将模型输出映射为工具调用，环境返回观察，harness 更新状态和上下文，然后进入下一轮。表面上是模型在“思考并行动”，实际是 harness 在控制模型能看到什么、能调用什么、调用结果如何进入下一轮、什么时候必须停下。

内层 Action Loop 与外层 Operating Loop

内层 Action Loop 与外层 Operating Loop

martinfowler.com 上 Böckeler 的 harness engineering 文章提供了一个从实践切入的视角：coding agent harness 是 guides 和 sensors 的组合。guides 在行动前把架构规则、代码约定、测试方式、设计原则推给 agent；sensors 在行动后用 lint、static analysis、dependency rules、test suite、architecture fitness function、review 等方式让 agent 和人知道偏离在哪里。[17] 这个视角能解释为什么仅靠“好模型”不足以获得稳定工程结果：模型可以提出动作，但动作进入真实代码库以后，必须被传感器捕获、校正和记录。

OpenAI Codex 的分享实践也是类似的思路。它强调把 repository knowledge 做成版本化事实源，让 agent 能稳定读到项目结构、测试方式和工作约定；AGENTS.md 不应该变成百科全书，而应该像入口地图，把 agent 引到项目里实际起作用的文档、脚本和验证路径上。[9] 这正是 harness 的本职：把人的隐性知识、项目约束和验证标准转成 agent 可操作的环境结构。

LangChain 在 Deep Agents 的 harness engineering 给出了实际的测试数据。他们固定模型，只改 harness，通过自验证、tracing、context optimization 等方式，使 coding agent 在 Terminal Bench 2.0 上从 52.8 提升到 66.5。[15] 这个结果里分数本身次要，要点是 harness 已经成为可实验变量：模型权重不变，轨迹分布仍然能因为 tool schema、context injection、self-verification、middleware、trace feedback 的改变而改变。

这些线索指向同一个定性判断：harness 不是模型的附属配置，而是模型外面一套有自己组件谱系的执行结构。运行时管执行，策略引擎管权限，测试夹具管验证，可观测栈管追踪，发布控制器管上线。把一个 coding agent 做到可靠，做的主要是这层结构，模型只是被它包在中间的一个部件。

到这一步，这些线索指向同一个定性判断：harness 不是模型的附属配置，harness engineering 已经成为了coding agent运行的框架组件，将软件系统中的 runtime、policy engine、test harness、observability stack、deployment controller 等设计模块迁移映射到agent框架的工程架构设计中，成为了agent工程构建的重要组成模块，给核心agent模型套上一层结实的外壳。

长任务让状态外部化成为硬约束

单个 context window 内的任务，可以用对话历史勉强维持连续性。一旦任务跨越多个 session，这种连续性就会失效。Anthropic 在 long-running agents 的文章里用一个很贴切的比喻：多 session agent 像轮班工程师，每个新工程师到场时都没有上一班的原生记忆。要让任务持续推进，状态必须通过 task file、progress file、git commits 等外部 artifact 存活下来。[11]

长任务状态交接

长任务状态交接

状态外部化在这里是架构基础，而不只是 memory feature 的一次升级。一个长任务系统必须把目标、计划、已完成事项、失败尝试、阻塞点、证据、diff、测试结果和下一步动作写进可恢复事实源。这类事实源在多智能体研究里一般叫做ledger（账本）：一份 append-only、只追加不覆盖、可逐条回放和审计的记录。Microsoft 的 Magentic-One 用一个 task ledger 装总体计划、一个 progress ledger 记进度与分派，据此决定下一步和何时终止；Cloudflare 的 Flue 把每个 prompt、工具响应、模型选择都当成一条不可变的 ledger 记录，进程死了另一个能从 log 接着上一步继续。[13] 模型可以更换，session 可以结束，context 可以被压缩或重置，但 task contract 和 progress ledger 不能丢。否则下一轮 agent 只能基于残缺对话重建世界，很容易重复错误或把已经推翻的假设当成事实。

Anthropic 后续的 Managed Agents 进一步把这个思想抽象成稳定接口。它将 session、harness、sandbox 分开：session 是 append-only log，harness 是调用 Claude 并路由工具调用的 loop，sandbox 是代码和文件操作发生的执行环境。三者解耦后，底层 harness 实现可以替换，sandbox 可以恢复，session log 可以作为事实源延续任务。[12]

这套解耦给 loop engineering 留出了工程化实施的地基。外层 operating loop 调度的对象是一组可恢复的任务状态：ledger 里的 task contract、worktree 里的代码、artifact 里的证据和测试结果。chat thread 的某个session关掉，session log 还在，loop 仍能从这些地方把任务重新拉起来。

Operating Loop 是 harness 之上的工作控制层

当 harness 能把单个 agent 的行动轨迹控制住，新的瓶颈会出现：为什么仍然由人来当任务调度器？

真实 coding agent 工作流里，人类所做的工作并不只是“给 agent 下达需求”。人在做的事很像是在做信号处理：发现 CI 变红，判断是真的有问题还是测试本身不稳定，挑选复现命令，整理上下文，给 agent 一个边界，读 agent 的 diff，跑一遍 AI review 和验证再自己复核一遍，把失败日志重新喂回去，决定是否重试，最后写 PR 描述、更新 ticket、按风险决定要不要人来做进一步终审。agent 负责写代码，AI review 也接手了不少机械检查，但把这些环节串成一条任务、盯着每一步走到哪、决定下一步做什么的那个系统，仍然运行在人的脑子里。

Loop engineering 关注的就是这部分。Addy Osmani 在 2026 年 6 月将 loop engineering 描述为设计一个会替你 prompt agent 的系统：系统自己发现任务、运行 agent、验证结果、写状态，并决定是否继续。[19] 这里的 loop 位于任务生命周期层，在agent loop 之外。

可以把两层控制器区分为：

inner trajectory controller:
    τ_task = H(M, task_contract, runtime_state)

outer work controller:
    work_state[t+1] = O(work_state[t], evidence(τ_task), policy, budget)

H 是 harness，它把模型 M 包进执行环境、工具、上下文、状态和验证中，产出一次任务轨迹 τ_task。O 是 operating loop，它不直接写代码，而是根据信号、证据、策略和预算决定下一个任务状态：继续、重试、交给 reviewer、开 PR、暂停、升级给人、关闭任务，或把某个失败模式写入 harness backlog。

这一区分能避免两个常见的架构设计偏差。第一，把内层问题交给外层重试。比如 agent 每次都因为缺少 repo 规则改错路径，正确做法是改 harness 的 context policy 或 permission model，让 operating loop 多跑几次只会消耗预算。第二，把外层问题塞给内层 agent 判断。比如一个后台任务最多能花多少钱、能否修改数据库迁移、失败几次后需要人工介入，这些决定不应该由 agent 在任务中临场拿捏。预算、权限范围、升级阈值这类东西放在 loop controller 的策略层里，agent 看到的是已经被裁掉的可行域。agent 拿到任务时，那些越界的动作已经被挡在外面，它只能在允许的范围内行动，而不是自己在任务中临场决定可习惯边界。

这跟用 agent 自带的 hooks 手搓一个循环有什么区别

Loop engineering 这个词出现后，也有不少声音质疑这是否又是“新瓶装旧酒”。2026 年的 coding agent 早就自带了拼出循环的全部原语。Claude Code 有 /loop 和一组 cron 工具，agent 能在会话里给自己排期，把 “每 15 分钟” 直接转成一个定时任务；有 /goal，让它一直干到某个条件为真；hooks 这边，PreToolUse 能在工具调用前直接拦下一个动作，Stop hook 能在 agent 想收工时把它按住、强制要求它继续。也就是说，“定时醒来、干活、卡在某个 gate、没到条件就接着跑”这套东西，用自带原语就能手搓出来。[21][22] 那么问题就是：operating loop 跟这样一个手搓循环，差在哪？围绕这个问题的社区讨论并不小。[20]

差别不在有没有循环，而在循环之外靠什么保证它可托付。

第一，任务怎么定义。手搓循环最常见的形态，是 cron 定时把同一段 prompt 重新喂给 agent，每一轮的输入是那段固定文字。operating loop 把任务固化成 task contract：失败日志、复现命令、目标 gate、允许修改范围、风险分类、最大尝试次数、升级条件。循环这一轮到底在干什么、干到什么算数，由 contract 定义，而不是由一段被反复投喂的 prompt 定义。一段 prompt 能表达的约束是有限的，一份 contract 才装得下"只能改这些路径、最多试三次、碰到 migration 就停手叫人"这类硬边界。

第二，证据落在哪里。Stop hook 能把 agent 按住继续跑，这解决的是"别提前收工"，但它没规定跑的过程留下什么。用自带原语手搓时，状态和证据往往散在会话里：这一轮改了什么、为什么这么改、测试输出是什么，都活在当前 transcript 中，会话一断就没了。operating loop 要求这些写进一个可恢复的 ledger：断了能重建上下文，换个 session 能接着跑，出了问题能回溯是哪一步、凭什么证据判定的完成。一个把证据留在会话里的循环，等于一个每次重启就失忆的系统。

第三，谁来验证。这是最容易被跳过、也挑战很大的一个点。/loop 的自查模式是 agent 读自己这一轮的输出、自己判断达没达标，等于让它给自己的作业打分。社区里已经有人把这条单独拎出来做对比：/goal 换了个做法，用一个独立的小模型去读 transcript、独立裁决，就是为了不让主 agent 判自己。[23] operating loop 把这一点落实为硬要求：验证必须由 agent 之外的东西完成，独立 verifier、独立评审模型或人工 gate 都行，唯独不能是 agent 自己宣布"我做完了"。

所以agent 自带的 hooks、gates、/loop 给了你造循环的零件，但没告诉你怎么把零件组织成一个可托付的系统。如果只是用 prompt 里的硬规则、检查输出的代码、skills、gates、hooks、workflows 一个个去堵 agent 的可靠性缺口，每一个都只堵住一部分、留下另一部分敞口，直到把它们组织成一个有明确完成定义、有独立裁判的循环，缺口才收拢。[23] 散着用这些原语补不严可靠性；把它们组织成 contract、ledger、独立验证三件套，才是 operating loop，而 loop engineering 讲的正是这个组织方式。

反过来说，这个质疑对市面上很多所谓的 loop 是成立的。如果一个 loop 只是 cron 定时把同一段 prompt 喂给 agent，不写 task contract，不留 ledger，验证只靠 agent 自己宣布"已完成"，那它确实不值得冠以新名词，而且比一个规规矩矩的定时脚本更难以保证效果，因为它每次行为都不同却没有任何证据留痕。所以判别一个 loop 是否可以实现工程化复用，可以收敛成三个问题：contract 在哪里，证据写到哪里，谁在 agent 之外做验证。

一个具体架构：CI Repair Loop

最适合落地operating loop的场景，通常是低风险、高重复、强验证、可回滚的任务。CI repair 是很好的起点，因为它有清楚信号源，有复现命令，有可执行 gate，有 PR 作为交付物，也有天然的人类审查点。

它把 CI 失败事件直接接入到agent链路上：测试一红，就拉起一次修复。但这个版本跑起来会立刻暴露一连串问题，而且这些问题几乎都不是 agent不够聪明造成的。

最典型的是 flaky test。flaky test不是 agent 对应的特定测试，而是一直以来的自动化测试就存在的问题：同样的代码，测试有时候过、有时候不过，红得没有道理。它的规模比直觉大得多。Google 报告近 16% 的测试带有某种程度的 flakiness，而在 CI 里，一个测试从通过转为失败时，约 84% 的情况是 flaky 而非真实回归。[25] 也就是说，红色里的大部分是噪声，不是信号。

噪声本身不致命，麻烦的是它会腐蚀对信号的判断。Google 在同一篇里点出一个人性规律：当一个系统总在发假告警，人就会开始忽略它的告警，他们甚至类比了飞行员对反复误报的座舱告警的钝化。人处理 flaky，靠的正是这种廉价的判断：瞥一眼，知道是测试在抽风，重跑一下即可。但直连的自动触发器没有这层判断，它只看到"红了"，就可能把一个抖动的假失败当成任务派下去，让 agent 去修一个未必存在的 bug。人脑里那个"这红先不用管"的过滤器，在自动 loop 里是缺失的，得由别的东西补上。

另外几种失败也来自同一个原因。稳定复现的真失败，如果没有一个地方登记"已经有 agent 在修了"，会被多个触发点各自领走，几个 agent 并行修同一个 bug、产出互相冲突的 diff。有些失败在 agent 的环境里根本复现不出来，它验证不了自己改得对不对，就一直空转烧预算。而只要一次没修好，没有机制拦着它越改越多、离正确越来越远。

这些问题全部属于任务调度层：该不该起任务、起几个、值不值得继续、什么时候停。agent 只看得见自己手里这一个任务，看不见别的 agent 在干什么、信号是不是噪声、全局预算还剩多少，所以它自己解决不了。触发器和 agent 之间因此需要一个 controller。它管的不是某一个 agent，而是任务流本身：哪些红值得起任务、同一个失败起没起过、这个任务试到第几次、还剩多少预算、什么时候该升级给人。这些是纯调度决策，跟"改哪行代码"那种开放判断不同，多数可以写成确定性规则：一个触发器，加一段做去重、记账、判预算的逻辑，一个模型都不用调。它恰好对应多智能体系统里的 orchestrator（也叫 central controller、control plane），但并不依赖"多个 agent"才成立：哪怕整个 loop 只用一个 implementer agent，只要任务是源源不断来的，就得有东西管这个任务流。[^orchestration]

controller 是不是一个 agent，其实无关紧要，要紧的是它管的那些边界是前置定死的、而不是丢给干活的 agent 临场拿捏。简单场景里它就是一段脚本；复杂场景里它自己也可以是个 agent。Kong 的调度层就是后者：一个编排 agent 先下载历史 CI 日志、把上下文喂足，再派修复 agent 去改，专门防止后者凭空猜测。[26] 无论哪种形态，把红点直接丢给修复 agent、中间什么都不放的架构，现实里几乎见不到。Datadog 也是先按类型给 flaky 失败分组，只把"代码修复大概率有效"的高价值类别往下送。

这层 controller 做的事，就是这些方案共有的那部分：对失败信号去重，把抖动的 flaky 和稳定复现的 deterministic failure 分开，分配预算和优先级，决定是否创建 task contract。task contract 比自然语言请求更硬，它包含失败日志、复现命令、目标 gate、允许修改范围、风险分类、最大尝试次数和升级条件。然后 loop 为任务创建 worktree 或 sandbox，把 implementer agent 放入隔离环境。agent 产出 diff 后，verifier 运行测试、lint、typecheck、review agent 或人工 gate，并把结果和证据写回 ledger。ledger 再驱动下一轮决策：成功则开 PR，失败则带证据重试，重复失败或越权则升级给人。

这套结构也有对应的生产落地。Kong 在自家 Gateway 代码库上搭的 flaky 修复 loop 几乎逐组件对应：一个跑 Opus 的编排 agent 先拉历史 CI 日志做信号甄别，再派 Opus 子 agent 去修，由一个独立的 Haiku 小模型来验，带最大尝试上限，跑出的 diff 走正常 code review 由人工 merge。[26] 它的验证环没有让修复 agent 自己判自己，而是换一个更小的模型独立裁决，落的正是前面那条要求：验证由 agent 之外的东西来做。

这条链路的承重部件是状态和证据。失败日志不能只出现在 agent 对话里，它应该成为 task contract 的一部分。agent 的复现命令、修改理由、diff 范围、测试输出、review 结果和成本也不能只是临时文本，它们应该写回 state ledger，用于 PR 描述、审计、下一轮重试和后续 harness 改进。

这类 loop 的自治级别也应该渐进。最初只自动开 PR，不自动合并；只处理 lint、typecheck、单元测试这类强验证任务，不处理业务语义模糊或安全敏感改动；只允许修改低风险路径，不碰 migration、auth、billing、deployment。等 loop 的成功率、误报率、回滚率、成本和人工介入率都稳定后，再扩大自治范围。

这里的架构思想和 OpenAI Codex app / cloud 的方向是一致的：agent 可以在后台、并行、worktree 或 cloud sandbox 中处理任务，人的角色逐步变成监控、批准和在关键节点纠偏。OpenAI 文档也把 Codex app 描述为带 worktree、automations 和 Git 功能的命令中心。[10]

Harness 优化正在变成“系统学习”

当 traces、evals 和 regression gates 搭建和使用成熟后，harness 本身就可以进入优化循环。LangChain 的 Better Harness 把 evals 类比为 agent 的训练数据：每个 eval case 为下一次 harness 改动提供信号，作用位置类似训练样本，只是被更新的对象从模型权重换成了 harness 配置。[16] Anthropic 在 long-running application harness 中引入的 generator/evaluator 结构走的是同一方向：评价者本身成为 harness 的一等组件，用来支撑前端设计这类验收标准偏主观的任务。[14]

这个优化链路以harness为优化对象，但实际使用时也存在对应的误用风险。相比模型训练的目标函数优化而言，harness optimization 更容易被误用，因为它直接改的是工具、上下文、权限、验证和恢复路径。如果 eval 集太小，系统可能学会钻 benchmark 空子；如果 holdout 不够独立，系统可能把局部任务技巧当成通用改进；如果只看 pass rate，不看成本、延迟和安全，harness 可能在分数上变好，在生产上变差。

Harness 优化循环

Harness 优化循环

失败轨迹应该进入 harness 改进循环，但 promotion 必须经过 holdout、回归、安全 gate、成本预算和人工审查。

AutoHarness 和 Meta-Harness 把这条线推到了自动化层面。AutoHarness 让模型自动合成 code harness，防止 game environment 中的非法动作；论文报告中，自动合成的 harness 能阻止 145 个 TextArena games 中的非法动作，并使较小模型在特定任务上超过更大模型。[27] Meta-Harness 则把 harness 当成可搜索对象，通过 coding agent 读取代码、提出改动、运行验证，在数学推理和 TerminalBench-2 等设置中搜索更好的 harness 配置。[28]

走到这一步，harness 已经不再只是人写死的一套框架，而是一个能被观测、比较、修改、回归、搜索的工程对象。但 AutoHarness 和 Meta-Harness 这类工作也带出了新的风险：当“优化 harness 的 agent”出现后，系统多了一层 meta-controller。这个 meta-controller 的输出如果没有独立验证和治理，可能会把不可解释的策略变化注入生产 harness。“晚上让 agent 自己改、早上看分数”，这构不成一个可托付的 auto-harness。候选 harness 至少要走和代码变更一样的 promotion 流程：实验记录、holdout、回滚预案在场，再决定是否替换在生产里跑的那一份。

这条线还有一个目前没被认真处理的盲点：harness 一旦成为可被 agent 修改的对象，自己也就成了潜在的安全攻击点。一次设计得足够精巧的 prompt injection，如果能诱导 meta-controller 把 verifier 的判定阈值放宽一档，整个 promotion 流程就会被绕过，而 ledger 里看起来一切正常。ETCLOVG 在 Governance 一层提醒了 trust assumptions 的演化，但具体到“优化 harness 的 agent”这一层，目前没有看到像 sandbox 那样成型的隔离方案。

自治范围是验证强度的函数

从 Osmani 的定义出发，loop engineering 很容易被归结成一句话：让 agent 更自动，人从循环里退出来。这个角度抓住了优化方向，却仍然只看到一个维度。自动化程度是结果，不是一个直接可调节的开关，决定一个 loop 能自动到哪一步的变量是验证强度，也就是系统能为每个动作出示多强的证据。

一个 chat assist 级别的 agent，可以在人类注视下给建议，验证弱一点也能接受，因为人承担最终判断。一个自动开 PR 的 loop，就必须提供复现命令、测试结果、diff 范围和风险说明，因为 reviewer 不能再逐轮追问上下文。一个低风险自动合并的 loop，必须有更强的 deterministic gates、回滚机制、审计和成本上限。至于自动部署、自动修改权限、自动迁移数据这类高风险动作，只有在验证链、回滚链和 human wake-up chain 都成熟时才有讨论空间。

自治范围与验证强度

自治范围与验证强度

一个比较实用原则是：如果某个错误会被 loop 放大，就不要只靠 agent 自觉避免。低风险建议可以依赖人类判断，自动执行必须依赖系统 gate，后台循环必须依赖 ledger 和 audit，自动合并必须依赖可回滚证据链。

这也是 Governance 成为框架设计中一等公民的原因。随着 loop 从“手动触发”走向“后台运行”，安全问题不再是执行后 review 能解决的事情。权限、身份、审计、审批、预算和策略都必须前置到 loop controller 和 harness policy 里。ETCLOVG论文在 governance 章节中也提出，长任务 agent 会引入 context drift、session-spanning state 和 evolving trust assumptions，很多现有治理管线仍停留在短 session 或单轮 agent 假设上。[4]

从 runtime 到 operating system

2022—2023 年的 ReAct、AutoGPT、BabyAGI 让人看到“单 loop agent”可以怎样跑起来，也暴露了 runaway、context blowout、state loss 和 unmonitored side effects。2023—2024 年工具接口、多 agent 协作和 benchmark 成熟。到 2025—2026 年，sandbox、observability、verification、governance、harness optimization 进入中心位置。[7]

把这条 timeline 和上文提到的 OpenAI、Anthropic、LangChain、AutoHarness 各条线叠在一起，可以看到好像在往同一个方向收敛：agent 系统正在从“模型调用 runtime”走向“面向长任务的软件操作系统”。操作系统对进程提供调度、隔离、权限、持久化和审计，agent 平台对任务要提供的恰好是同一组原语，分别由 loop controller、sandbox、governance policy、ledger 和 trace 承担。一个只会调用工具的模型，是 runtime 级 agent；一个有 sandbox、state、trace、verifier 和 policy 的系统，是 harnessed agent；一个能持续发现任务、分派 agent、吸收失败证据、更新事实源、管理预算和权限的系统，才接近 operating system 级 agent 平台。

然而也不是可以直接将os的概念照搬到agent。操作系统面对的进程模型是确定的，而 agent 平台调度的是一个会即兴发挥、也会犯错的模型，所以 agent 平台里 verification 和 governance 的分量，比传统 OS 里重得多。类比给的是结构直觉，不是现成蓝图。

harness engineering 已经过了检验，从 Hashimoto 的提法到 OpenAI、Anthropic、Thoughtworks、LangChain 和学术综述，几个月内全部入场。loop engineering 则更新，连叫法都还没定下来：swyx 把它称作 loopcraft，LangChain 在 6 月 16 日用这个概念给出了一套四层实现：agent、verification、event-driven、hill-climbing，每层对接一个产品原语。[^langchain-loopcraft][^loopcraft] 这个名字，连同 automations、agent orchestration，都可能最终把 loop engineering 这个词吸收掉。

但名字之争不影响底层判断。Steinberger、Cherny、Karpathy 这些来自不同团队的人，几乎同时收敛到：agent 的价值在于你围绕模型搭起来的那些 loop。术语谁最后胜出，远不如这种跨团队的不约而同来得要紧。即使 loop engineering 这个名字没能存活，“harness 控制单次轨迹、外层系统运营任务流”这个架构区分也会以别的名字留下来。

可托付性是系统属性

想让 coding agent 更可靠，直接想到的做法是沿模型能力往上堆料：更长的上下文、更多的工具、更强的基础模型。这三条轴都能带来不同程度的提升，却缺少工程化的持续扩展基础。

更长的上下文推迟了状态问题，却不会顺带送来审计；更多工具扩大能力的同时，也把误用面和攻击面一起撑大；更强的模型减少了一部分错误，代价是 agent 有能力制造更远、更隐蔽的那一类错误。三条线很难汇聚到这样一个核心点：在agent的生产使用上，让使用者(个人和组织)敢于放权的可托付性。它不落在在任何模型能力轴上，在模型外面那层结构中。

可托付性有几个必要条件。首先任务要有 contract，而不只是一句许愿式的prompt；行动要发生在具备可恢复的执行环境里，本地那种不可复现的偶然状态不算。状态写进 ledger，不只留在会话上下文里；验证要落成证据，不能只由 agent 自己宣布“已完成”；权限要能审计、能撤销，事后补一轮 review 顶不上。当然还有loop Engineering的内核要求：loop 得知道什么时候停下、什么时候需要人介入，而不是在后台无限重试。

这些条件组合起来，汇聚出迁移线：可靠性的落点一路在外移，从模型，到 harness，再到 loop。harness 让一次任务的 trajectory 受控，operating loop 让一组任务的 work ledger 可运营，两层叠起来，才是“可托付性的控制层”。模型仍然重要，但它只提供原料；你敢把多少事交出去，取决于在它外面建了多厚的这层结构。

这些条件连起来，是一条落点不断外移的线：可靠性先系于模型，再系于 harness，最后系于 loop。harness 让一次任务的 trajectory 受控，operating loop 让一组任务的 work ledger 可运营。两层各管一段：一段是“这次能不能干对”，一段是“这一批能不能持续地交出去”，叠起来才是这篇文章标题里那个“可托付性的控制层”。

把这条线倒回文章开头，能看清它真正改变了什么。最初，agent 系统的调度器是人：哪些任务值得起、边界划到哪、进度走到哪一步、这一轮算不算数、什么时候该继续、什么时候该收手交人，全靠人一件件在脑子里盯着。agent 负责干活，可把这些环节串成一条任务、判断每一步的那个系统，一直运行在人的脑子里。

这套外移分两步落地，也对应文章前后两半。harness 解决的是"这一次能不能干对"：给模型一个可恢复的环境、一套工具、一份 contract、一层权限 gate、一个能验证结果的 verifier，让单次任务的轨迹受控。但 harness 管不到任务之间和任务之上的事，而恰恰是那部分一直压在人身上：任务从哪来、要不要续、跑完写回哪、失败重试还是升级、整批工作什么时候该停下叫人。operating loop 接手的就是这一层，这也是 loop engineering 真正的内核：它不是又一圈把模型包起来的结构，而是在 harness 之上运营一整条任务流的调度层，尤其是那套决定"何时停、何时把人叫回来"的退出与升级逻辑。harness 把人从"盯着一次任务"里解放出来，loop 把人从"当整条任务流的调度器"里解放出来。人退出的不是判断，是当人肉调度器的那份苦役。

这一路加上去的 contract、gate、ledger，再加上 loop 那套预算与升级阈值，单看每一样都像在给 agent 上锁。但它们合起来不是镣铐，是放权的前提。没有 contract，你不敢把一个没写清边界的任务交出去；没有 ledger 和独立验证，你不敢相信一句“已完成”；而没有一个知道何时该停、何时该把你叫回来的 loop，你根本不敢让它在你看不见的时候连续跑下去。这些结构各就各位，自动化才谈得上交出去：harness 管住单次任务，让它这一趟干得对；loop 管住任务之间和任务之上的事，让任务能持续地流转下去而不必有人盯着。

可托付性从来不是模型自带的属性,而是它外面这层控制结构的属性。这层结构也不是静态的:模型的能力边界在持续外扩,昨天还要靠 harness 兜住的事,正一件件被模型原生吸收。但吸收改变的只是分界线的位置,不是这层工程的存在。被吃掉的部分让给模型,模型够不着的任务流治理顶上来,控制层随着模型一起上移。模型越强,留在外面的这层工程,离生产价值反而越近。

参考资料

1. Junjie Li et al., *Agent Harness Engineering: A Survey*, OpenReview, 2026（TMLR 在审）. https://openreview.net/forum?id=3hXEPbG0dh （作者在项目页 BibTeX 中给出的 PDF 链接为 https://openreview.net/pdf?id=eONq7FdiHa ，两者为同一论文的不同入口。）↩︎ 2. 同 [^survey]，Figure 4 及 taxonomy 章节。↩︎ 3. 同 [^survey]，Observability 章节：tracing、cost tracking、reliability engineering 与 unified observability。↩︎ 4. 同 [^survey]，Governance 章节：permission、lifecycle hooks、hardening、constitutions、audit infrastructure 与 long-horizon governance gaps。↩︎ 5. 同 [^survey]，Section 11：cost-quality-speed trilemma 与 capability-control tradeoff。↩︎ 6. 同 [^survey]，harness coupling problem：不指明外围 controller 时，模型分数无法被干净归因。↩︎ 7. 论文项目页与 PDF 提供 2022—2026 年代表性 agent-harness 系统的 timeline。https://picrew.github.io/LLM-Harness/↩︎ 8. Michael Bolin, “Unrolling the Codex agent loop,” OpenAI, Jan 2026. https://openai.com/index/unrolling-the-codex-agent-loop/↩︎ 9. Ryan Lopopolo, “Harness engineering: leveraging Codex in an agent-first world,” OpenAI, Feb 2026. https://openai.com/index/harness-engineering/↩︎ 10. OpenAI Developers, “Codex app.” https://developers.openai.com/codex/app↩︎ 11. Anthropic Engineering, “Effective harnesses for long-running agents,” Nov 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents↩︎ 12. Anthropic Engineering, “Scaling Managed Agents: Decoupling the brain from the hands,” Apr 2026. https://www.anthropic.com/engineering/managed-agents↩︎ 13. ledger 作为“记录任务计划与进度、append-only、可恢复可审计的结构化事实源”，在 agent 领域有多个一手出处。Microsoft Magentic-One（arXiv 2411.04468)↩︎ 14. Anthropic Engineering, “Harness design for long-running application development,” Mar 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps↩︎ 15. Vivek Trivedy, “Improving Deep Agents with harness engineering,” LangChain, Feb 2026. https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering↩︎ 16. Vivek Trivedy, “Better Harness: A Recipe for Harness Hill-Climbing with Evals,” LangChain, Apr 2026. https://www.langchain.com/blog/better-harness-a-recipe-for-harness-hill-climbing-with-evals↩︎ 17. Birgitta Böckeler, “Harness engineering for coding agent users,” martinfowler.com, Apr 2026. https://martinfowler.com/articles/harness-engineering.html↩︎ 18. Boris Cherny（Anthropic，Claude Code 负责人）在 WorkOS 主办的 Acquired Unplugged 活动（2026 年 6 月 2 日）访谈中的说法被广泛传播：他不再直接 prompt Claude，而是写 loop 让 loop 去驱动 Claude。Peter Steinberger（OpenClaw 创始人）在 X 上的接力进一步扩散了这一讨论。↩︎ 19. Addy Osmani, “Loop Engineering,” Jun 2026. https://addyo.substack.com/p/loop-engineering （Osmani 将 loop engineering 定位为 agent harness engineering 的上一层。）↩︎ 20. Firecrawl, “Loop Engineering: Should You Stop Prompting Agents and Start Designing Loops,” Jun 2026. https://www.firecrawl.dev/blog/loop-engineering↩︎ 21. Claude Code Docs, “Run prompts on a schedule”（`/loop`、`/goal` 与 CronCreate/CronList/CronDelete 工具，2026 年 3 月起）. https://code.claude.com/docs/en/scheduled-tasks↩︎ 22. Claude Code Docs / Agent SDK hooks 参考：PreToolUse 可在工具调用前拦下动作，Stop hook 可在 agent 试图停止时将其按住并要求继续。https://code.claude.com/docs/en/hooks↩︎ 23. 一线实践对 `/loop` 自查与 `/goal` 独立裁决的对比，以及"逐个用 gates/hooks/workflows 堵漏、最终靠组织成 loop 收口"的描述，见 buildtolaunch, “Claude Code /loop: How to Keep It Running Until the Work Is Done,” 2026. https://buildtolaunch.substack.com/p/claude-code-loop-guide↩︎ 24. 自我验证在缺乏外部 grounding 时不可靠，是 LLM 推理研究中的一个稳定发现。Stechly et al. 观察到无外部 grounding 的自我批判会使性能退化；ReVeal（Xie et al., arXiv 2506.11442）指出 LLM 通常缺乏可靠的自我判断，常见对策是引入独立的 critic 模型来验证 policy 模型的输出。相关综述见 VerifiAgent, arXiv 2504.00406。↩︎ 25. 数据与“系统反复发假告警则人会忽略告警”的类比，均出自 Google Testing Blog, “Flaky Tests at Google and How We Mitigate Them,” 2016. https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html 。补充规模数据（每年约 15 万工程师小时、Jira 前端仓库中 flaky 一度占 master 构建失败的 21%）见 Atlassian Engineering，2025 年 12 月披露。↩︎ 26. 两个把失败甄别前置于修复 agent 的工程实例：Datadog, “Automate flaky test fixes with the Bits AI Dev Agent”（先按类型分组、只将高价值类别交给 agent）, 2026, https://www.datadoghq.com/blog/bits-ai-test-optimization/ ；Kong, “How We Used Agentic AI to Fix Kong Gateway's Flakiest Tests”（编排 agent 先拉取历史 CI 日志做 grounding，再派子 agent 修复）, 2026, https://konghq.com/blog/engineering/how-we-used-agentic-ai-to-fix-kong-gateways-flakiest-tests 。这些为厂商工程博客，此处仅引用其架构做法，不采信其对问题严重性的表述。↩︎ 27. Xinghua Lou et al., “AutoHarness: improving LLM agents by automatically synthesizing a code harness,” arXiv 2603.03329, 2026. https://arxiv.org/abs/2603.03329↩︎ 28. Yoonho Lee et al., “Meta-Harness: End-to-End Optimization of Model Harnesses,” arXiv 2603.28052, 2026. https://arxiv.org/abs/2603.28052↩︎