Harness 之后：状态边界与失败闭环（若飞续篇）¶

Ch05.015 Harness 之后：状态边界与失败闭环（若飞续篇）¶

📊 Level ⭐⭐ | 21.8KB | entities/harness-之后-状态边界与失败闭环-ruofei.md

摘要¶

若飞 2026-06-02 续篇把 Agent Harness Engineering 综述（LLM-Harness Survey）从"组件清单"推到"运行时闭环"。核心论断：Harness 之后，Agent 可靠性的下一步是状态边界和失败闭环——模型可以给出可能性，但系统不能轻易把可能性当成事实。下一步拆成三件事：运行时契约 / 状态提交闸门 / 失败回写闭环。

综述给的是 ETCLOVG 七层分类（Execution / Tooling / Context / Lifecycle / Observability / Verification / Governance），但分类 ≠ 闭环。一个系统可以有 memory、tools、sandbox、trace、eval、policy，仍然可能不可靠——关键是这些组件互相咬合、形成能恢复能复查的闭环。

与若飞 long-running-agent 系列的关系¶

续篇 A 的 5 张卡偏信息分层（不同信息用不同载体分开）。本文续篇 B 偏动作生命周期（一个动作从候选到提交的完整链路）。两篇互补不重叠：5 张卡解决"哪些信息在哪个层"，本文解决"一个动作经过哪些闸门"。

核心框架 1：状态提交链路（候选 → 已验证 → 已执行 → 已提交）¶

若飞从 Google DeepMind 的 AutoHarness 论文 得到启发：模型在游戏里走非法动作不可怕，可怕的是系统没有外部机制把非法动作挡在提交之前。放到企业系统里：

一次动作的状态提交链路：

大多数 Agent 事故出在中间两层：

• 模型"猜了一下"，系统却当成"已经确认的事实"（候选→已提交跳过验证）。
• 模型"试了一次"，工具却已经把外部状态改掉（候选→已执行跳过 dry-run）。
• 模型"当前 session 的临时结论"，memory 却把它写成长期偏好（候选→已验证跳过退场）。

这条链路与 Codex /goal Runtime 的 GOAL.md → PLAN.md → PROGRESS.md 外部状态文件互补：本文关注单个动作的提交闸门，Codex /goal 关注任务级别的状态文件。两者不冲突，前者更细粒度。

核心框架 2：Trace 回写 + 前馈/反馈 + 计算/语义控制¶

Trace 之所以有用，不是因为"我有日志"——日志只是事后查账。Trace 能进入 Harness 是因为它能回答几个问题：失败从哪一步开始、当时模型看到了什么、工具返回了什么、哪个验证没触发、哪条规则写得太虚、下次反馈该放在更早还是更晚的位置。

Martin Fowler 的控制二分法（前馈/反馈 × 计算/语义）：

工程里更稳的分配是：便宜、稳定、快速的检查尽量前移；昂贵、不确定、需要取舍的检查留给关键节点。

这与 六条经验 里的"测试和重构不是旧时代包袱，而是 AI 时代的价值锚——AI 生成越快，确定性反馈环越值钱"完全一致：Martin Fowler 与 OpenAI Harness Engineering 的共识在这里再次出现。

核心框架 3：先做三件事（运行时契约 / 提交闸门 / 失败回写）¶

3.1 运行时契约¶

Agent 开工前，运行边界要清楚。至少包括：目标、停止条件、输入来源、输出收件人、可读系统、可写动作、人确认动作、上一轮证据。

"Prompt 如果只写'帮我做竞品分析'，它会自然扩散。运行时契约会写清读哪些站点、看哪些字段、输出几段、哪些地方不预测、什么时候停止、哪些链接打不开要标出来。Agent 任务越长，这份契约越重要。"

与 Hermes Agent Operator上手 把一个 Agent 养成可运营系统 若飞 的 "TERMINATION" 段直接相连——若飞把 Cowork 模板里的 TERMINATION 概念搬到了长任务 Agent Runtime。

3.2 状态提交闸门¶

状态分类与对应闸门：

"不是所有发生过的事情都值得记住。尤其是那些临时绕路、失败猜测、一次性偏好，如果被写进长期记忆，会变成未来判断里的噪声。"

这与 Hermes Agent Memory System Three Layer Architecture 的"记忆预算观"（注意力预算 + 上下文预算 + 判断预算）一致——若飞在 5 张卡续篇就提出过，本文再次强调。

3.3 失败回写¶

Agent 错误按类型写回正确位置：

"每个反复出现的 Agent 错误，都值得追问一次：它是提示词问题、状态问题、权限问题、验证问题，还是流程问题。这个问题问清楚，补丁才知道落在哪里。"

三条分歧：模型 vs Harness 的边界¶

分歧 1：模型会不会把 Harness 吃掉？¶

• Big Model 派（Boris Cherny、Cat Wu、Noam Brown）：让模型发挥能力，外层包装保持很薄；强推理模型会吸收掉很多旧 scaffold。
• Big Harness 派（Jerry Liu、LangChain、AutoHarness）：模型能力上去以后，任务也变大，新的约束又会出现。

若飞折中：模型会吃掉一部分 Harness，但不会吃掉外部状态和责任边界——只要 Agent 还要进入文件系统、浏览器、数据库、生产环境、审批链和人类团队，外部状态、权限、证据和回滚就不会消失。

分歧 2：同一个模型在不同 Harness 里差多少？¶

Ry Walker 的说法贴近企业实践：同一个模型经过不同 CLI/framework/runtime 表现会有明显差别。架构师提醒：运行时约定别绑死在某一个工具形态上——把约定沉到项目层（AGENTS.md、测试、类型、checklist、权限），让不同 Harness 读取但不依赖。

分歧 3：Harness 能不能解决欠规格？¶

Hamidreza Saghir 的 Your coding agent is under-specified 讲得直接：很多 coding agent 的问题不是模型坏，而是任务本身没写清楚——代码要精确到分支、状态、错误路径和副作用，但自然语言任务常常只写 happy path。

Harness 能做的是把缺失规格放到 Agent 能看到、能执行、能被检查的位置（AGENTS.md、测试、类型、review checklist、权限、结构化日志、工作流脚本）。但 Harness 不能替我们想清楚所有规格——如果团队自己都没有说清楚"这个项目到底怎么做事"，Agent 只会用训练数据里的平均习惯补空。

"Harness 更像一个放大器——它能放大清晰的规则，也会放大模糊的流程；它能让清晰流程跑得更快，也能让模糊流程更快地产生半成品。" "Harness 有价值，前提是流程本身值得被放大。"

落地：先稳再自动化¶

长期 Agent、cron、subagents、orchestrator——能力诱人但流程没跑明白时自动化会放大混乱。

反面教材：

• 竞品扫描流程：输入列表每周变、输出格式没人看、失败链接不记录——接上 Agent 只会定时生成更多半成品。
• 代码 review 流程：风险分类不清、测试口径不清、谁来裁决不清——多 Agent 并行后 review 压力被推后。

正确路径：

1. 选一个低风险、可审阅、输入稳定的流程（每周固定站点的竞品扫描、PR 第一轮只读审查、文档来源归档、发布前 smoke checklist、公众号素材来源台账）。
2. 先连续跑几轮，只让 Agent 读和整理，不让它写外部系统。
3. 每轮都要求它留下失败记录和证据。
4. 人类 review 后，把重复问题写回规则、Skill 或检查脚本。
5. 等输入、输出、失败和权限都稳定，再考虑定时任务和更高自动化。

"这条路看起来慢一点，但对 Agent 系统来说，慢一点反而更真实——因为要验证的不只是'它能不能偶尔做对一次'，还有'它出错以后，状态还能不能被看懂'。"

与其他实体的关系¶

• 基础理论：
• Harness Engineering Survey（CMU/Yale/Johns Hopkins，ETCLOVG 七层分类的源头）
• Harness Engineering — ETCLOVG Taxonomy（七层分类的独立条目）
• 同作者系列：
• Ralph Loop 与可接管 Harness（2026-05-10）（2026-05-10，三类漂移 + 可接手标准）
• Hermes 5 张卡治理框架（2026-06-01）（2026-06-01，don't automate slop）
• Hermes Agent Operator上手 把一个 Agent 养成可运营系统 若飞（Cowork + TERMINATION 段）
• Agent Memory 架构：过去影响未来（记忆预算的更早版本）
• 互补实践：
• Codex /goal Runtime（任务级状态文件 GOAL.md/PLAN.md/PROGRESS.md）
• Anthropic 长时运行 Agent 架构（对抗式设计 + 合同谈判 + 审美量化）
• 六条经验：让 AI 编码 Agent 变得可控（Martin Fowler 反馈环共识）
• Harness design for long running apps（Anthropic 官方长任务 Harness 解读）
• Martin Fowler：非确定性进了研发链路（前馈/反馈原文）
• 概念图：
• Long-Running Agent 架构三大模式与演进路径

→ 原文存档

核心结论¶

1. Harness 之后，Agent 可靠性的下一步是状态边界和失败闭环——不是再加一个组件，而是让七层组件咬合成可恢复可复查的运行时闭环。
2. 一次动作要走完四层闸门（候选→已验证→已执行→已提交）——大多数事故出在中间两层跳过验证。
3. 先做三件事：运行时契约（边界清楚）、状态提交闸门（每类状态不同严格度）、失败回写（按错误类型写到正确位置）。
4. Harness 是放大器，不是银弹——前提是流程本身值得被放大，欠规格的流程自动化后只会跑得更快地产生半成品。
5. 模型会吃掉一部分 Harness，但不会吃掉外部状态和责任边界——文件系统、数据库、生产环境、审批链和人类团队这些地方，外部状态、权限、证据和回滚不会消失。
6. 最后拼的是不太炫的东西：状态能不能被看懂、错误能不能被拦住、证据能不能被复核、状态能不能被回滚、下一轮能不能接着做。

深度分析¶

1. 状态闸门跳级是 Agent 事故的本质模式¶

若飞的核心发现不是"模型会犯错"，而是"系统没有机制拦住跳级"。候选→已提交、候选→已执行、候选→已验证——这三种跳级分别对应三类事故：把猜测当事实、把试跑当确认、把临时结论当长期偏好。这与 Martin Fowler 的"非确定性进了研发链路"形成深层呼应——当模型作为非确定性协作者介入外部系统时，如果外部没有强制的状态边界机制，跳级几乎不可避免。这个规律在任何语言模型、任何 scaffold、任何任务复杂度下都成立，所以比"模型能力不足"更接近事故的本质。

2. ETCLOVG 七层分类只是地图，不是路线图¶

CMU/Yale/Johns Hopkins 的七层 ETCLOVG 分类（Execution / Tooling / Context / Lifecycle / Observability / Verification / Governance）是迄今最完整的组件清单，但若飞指出分类 ≠ 闭环。一个系统可以同时拥有 memory、tools、sandbox、trace、eval、policy，仍然不可靠——问题在于这些组件之间没有咬合成环：工具调用没有权限闸门、日志没有归因能力、验证结果没有回写到规则层。这提示我们：Harness Engineering 的下一个工程问题不是"还有哪层没覆盖"，而是"已有的层之间如何形成可验证的闭环"。

3. 记忆预算观重新定义了 memory 的角色¶

若飞在本文和 5 张卡续篇里反复强调"记忆像预算，不像仓库"——长期记忆不是存储，而是选择性消耗认知资源的决策。这个框架与 六条经验 里"AI 生成越快，确定性反馈环越值钱"共享同一个底层逻辑：资源（token 预算、注意力预算、判断预算）越稀缺，越需要把资源分配给高价值验证，而不是把所有中间结果都沉淀成"经验"。把临时绕路、失败猜测、一次性偏好写入长期记忆，是在预支明天的认知预算。

4. 前馈/反馈 × 计算/语义的二维控制矩阵有实操价值¶

Martin Fowler 的控制二分法（feedforward/feedback × computational/inferential）被若飞拿来直接用。这个二维矩阵的实操价值在于：它给了一个判断"某项检查放在哪里"的依据——便宜且确定的检查（类型检查、lint）尽量前移；昂贵且语义不确定的检查（LLM judge、人工 review）留给关键节点。这意味着工程团队不需要在"全用 AI"和"全用规则"之间二选一，而是可以用矩阵决定每一项检查的放置策略。这个框架也比单纯谈"AI 何时可信"更具可操作性。

5. Harness 是放大器而非银弹，澄清了行业的一个误区¶

若飞明确写出"Harness 有价值，前提是流程本身值得被放大"，这是对当时行业主流叙事的一个直接澄清。行业内有一种隐含假设：给团队配上更好的 Agent、更强的 Harness，问题自然会解决。但若飞指出这是本末倒置——欠规格的流程（Harness 放进去只会跑得更快地产生半成品）和清晰流程（加了 Harness 能稳定产出高质量结果）之间的差距，是 Harness 放大了流程质量本身，而不是 Harness 弥补了流程质量的缺失。这个区分对团队决策有直接影响：先评估流程质量，再决定要不要上 Agent。

实践启示¶

1. 从"候选→已提交"全链路追踪开始建状态可见性¶

在任何一个现有 Agent 流程里，先画出一次动作的完整链路：模型输出 → validator → 工具调用 → 外部状态写入。找出中间哪一步被跳过了（通常是"已验证"和"已执行"之间），给跳过的地方加上对应闸门。这不需要重构整个系统，只需要把每一次 action 标注状态（候选/已验证/已执行/已提交），让日志可追踪。状态可见性是一切后续闭环的基础。

2. 给 Agent 写运行时契约，从 TERMINATION 反推边界¶

参考若飞在 Hermes Agent Operator上手 把一个 Agent 养成可运营系统 若飞 里的 TERMINATION 段落，从"任务在哪里停"反推边界：目标、停止条件、输入来源、输出收件人、可读系统、可写动作、人确认动作、上一轮证据。契约不需要完美，但需要把"模糊地带"变成"明确条目"。这份契约应该落在 AGENTS.md 或项目入口文件里，让不同 Harness 读取但不依赖。

3. 用"错误回写表"把每次失败变成一次系统改进¶

建立一张错误类型→写去哪里的映射表（本文的失败回写框架）。每当 Agent 出现一次可归类的失败，立刻执行回写：约定没读到写 AGENTS.md、步骤不稳定沉淀成 Skill、忘记跑测试加 Hook/Stop check。循环两次之后，这张表本身就成了团队 Harness 的一部分——每次回写都在减少下一次同类错误的概率，同时积累成团队的"Agent 运营知识库"。

4. 用"记忆预算"思维替代"记忆仓库"思维重新审视 memory 设计¶

检查现有 Agent 的 memory 写入逻辑：如果 memory 正在把 session 里的临时结论、失败尝试、一次性偏好写入长期记忆，立刻加一道闸门。判断标准：如果这段内容从今天起消失，明天 Agent 会不会反而判断更准确。长期记忆的写入权限应该比草稿/候选结论更严格——不是所有发生过的事都值得记住，只有那些能反复使用的模式才值得进入长期记忆。

5. 用"先读整理、不写外部"的小循环验证流程质量，再决定是否扩大自动化¶

若飞的正确路径：低风险流程 → Agent 只读整理 → 人类 review → 把问题写回规则 → 稳定后才扩大。这个路径对任何想引入 Agent 自动化的团队都适用，核心价值在于：用小规模实验逼出真实流程质量问题（输入是否稳定？失败有没有记录？输出谁来审？），而不是等到 Agent 跑大了才发现流程本身就是半成品。先在"只读"模式下跑三到五轮，每轮积累失败记录，再判断要不要解锁写外部系统的权限。