wow-harness v3：AI 开发的治理协议¶

Ch05.028 wow-harness v3：AI 开发的治理协议¶

📊 Level ⭐⭐ | 16.3KB | entities/wow-harness-v3-governance-protocol.md

wow-harness v3：AI 开发的治理协议¶

"协议比能力重要，治理比智能重要，长期连贯性比单次质量重要。" —— 张晨曦（Nature），通向惊喜科技创始人

wow-harness v3 是一份面向 跨 session 一致性 的 AI 开发治理协议设计。它不替代 Claude Code，跑在 Claude Code 之上，把"一次 session 怎么高效执行"扩展为"多个 session 之间怎么保持组织级一致"。设计文档约 50,000 行，21 个模块，经历 6 轮版本迭代。

→ 原文存档

一句话定位¶

"AI 写得越多，我维护它越累" —— 不是 AI 不够聪明，是它每次都重新发明你之前已经建立过的约定。v3 用协议 + 物理拦截 + 事件溯源解决这个问题。

设计哲学：套具比模型重要¶

引用 Anthropic 自己的 Claude Code 大型代码库部署博客 + arxiv 2604.14228 学术逆向分析： - 整个 Claude Code 代码库中 98.4% 是运行基础设施，1.6% 是 AI 决策逻辑 - Anthropic 原话："真正决定效果的，是围绕模型搭起来的那套'套具'（harness），对最终效果的影响远超模型本身" - 现有套具都管"一次做好"；v3 管"一百次之间不漂移"

5 大核心问题 + v3 解法¶

问题 1：AI 做过的事，怎么不丢？¶

v3 解法：所有 agent 产出（代码 / 判断 / 概念调整）作为事件写入只追加、不可篡改的时间线。这条时间线 = 整个系统的唯一真相来源。 - 三个月后的 agent 不靠记忆，靠查时间线看到完整决策历史（谁做的 / 什么时候 / 为什么） - 两个配套机制：增量推导"当前状态"（不每次从头扫）+ 定期归并压缩成关键快照

问题 2：工程概念跨 session 怎么不漂移？¶

v3 解法：每个工程概念（API / 数据结构 / 命名约定 / 架构决策）是独立节点，有生命周期 创建 → 修改 → 被替换 → 退役。 - 概念被替换时，系统自动扫描"谁还在用旧版本"并通知——不靠 AI 记得，靠结构自动传播 - 关键约束：替换必须说明引入什么新信息——如果只是"新名字更好"系统不允许替换 - 解决长期项目"振荡问题"：同一设计在两个版本之间来回改，每次改回去的 agent 都不知道之前为什么改走

问题 3：怎么确保 AI 的产出真的做完了？¶

v3 解法（双层验证）： - 第一层（提交前自检）：agent 提交前必须跑自检项，每一项要有具体验证证据（命令输出 / 测试报告 / grep 结果）—— 不接受"我觉得做完了" - 通过统一的提交检查点——物理层面拦截不合格的产出 - 第二层（独立 cross-validator）：另一个 agent 用不同视角、方法验证同一份产出 - 验证 agent 工具列表没有写权限（schema 级限制，不是提示词约束）——做判断的人不能同时是做事的人

与 Superpowers 强制 TDD 的本质区别：Superpowers 在提示词层面要求 Claude 遵守纪律——Claude 理论上可以"合理化"自己不遵守。v3 的检查点是物理拦截：自检不过就提交不了，不存在"差不多就行了"。

问题 4：怎么让 AI 不是"一个工具"而是"一个自己运转的组织"？¶

v3 与所有现有工具差异最根本的地方： - Superpowers 假设：agent 是需要被管教的执行者 - v3 假设：agent 是组织成员——多个 agent 组成自己运转的开发组织（采访员 / 架构师 / 执行者 / 审查员 / 修复师），协作不靠人调度，靠协议自动驱动

自动扩张的图： - 每个节点 = 一个 agent skill（采访/设计/规划/执行/审查/修复） - 边 = 事件触发关系 - 节点完成工作产出事件 → 系统自动检查"这个事件应该触发哪个下游节点" → 自动 spawn 新 agent session - 例子链路：执行 agent 写完代码 → "任务完成"事件 → 自动 spawn 审查 agent → 审查发现"发现缺陷"事件 → 自动 spawn 修复 agent → "修复完成"事件 → 自动 spawn 审查 agent 做闭合验证。整条链路没人参与调度——图自己扩张、收缩、运转 - 每个新 spawn 的 agent session 无状态——不继承上一个 session 的偏见和惯性。拿到的是系统专门为它组装的上下文胶囊（它需要知道的概念 / 约束 / 引用关系），从 artifact 出发做独立判断 - 类比："像新员工入职——他不需要记得前任怎么想，他看交接文档就能开始工作"

v3 = 图 vs Superpowers = 直线： - Superpowers 线性流程（brainstorm → plan → TDD → review → finish）——人启动、agent 走完、人验收 - v3 是图——图自己根据事件流决定下一步该做什么、该 spawn 谁、该通知谁 - 直线做不了并行（5 agent 同时 5 任务）、做不了回路（审查→修复→闭合验证）、做不了跨任务概念冲突检测。图可以

问题 5：项目负责人怎么不退化判断权？¶

v3 解法（严格区分两类决策）： - 工程实施类决策（怎么写、怎么测、怎么部署）——AI 自己做，不问人 - 语义判断类决策（产品方向、不可逆操作、价值取向）——走"升级"路径送到系统所有者面前 - 关键：不用工程黑话，用产品语言描述情况、列出选项和各自代价 - 系统所有者的每次判断本身也是一个事件，写入时间线、永久留痕——"人做了什么决定、什么时候、为什么"跟"AI 做了什么"一样可追溯

学术验证：ESAA 论文¶

2026 年 2 月 arxiv 出现 ESAA 论文（Event Sourcing for Autonomous Agents），核心命题与 v3 高度重合： - 把 agent 的"想做什么"跟"系统实际发生了什么"分离 - agent 只发出结构化意图声明，由独立验证器检查后才写入不可篡改的事件日志 - 与 v3 "事件意图 → 提交检查点验证 → 事件记录"是同一架构 - 论文也指出 AI 开发正从"对话式"转向需要"长期一致性"的工作流 - 论文描述"状态漂移"失败模式（agent 相信修复了，但系统实际没变）——v3 的双层验证 + 物理拦截要消除这个失败

v3 超出 ESAA 论文范围的工程设计： - 概念节点的生命周期状态机 - 约束规则（义务）的独立生命周期管理 - 为每个 agent session 精确组装上下文的机制（上下文胶囊） - 基于证伪主义的三正交审查方法论 - 闭合合约驱动的缺陷修复协议

ESAA 出现是"好消息"——意味着这个方向不是孤立判断，是领域必然趋势。

v3 vs 现有工具的根本区别¶

vs Claude Code（地基，非竞争）¶

• v3 跑在 Claude Code 上面——用它的终端环境、子 agent 机制、工具系统
• Claude Code 管"单次 session 怎么高效执行"，v3 加"跨 session 的组织级治理"
• 两者不是同一层的问题，不存在替代关系

vs Superpowers¶

v3 核心设计原则："解释为什么"比"堆 MUST 规则"有效得多——agent 拿到完整系统理解后，行为是自然推导的，不是被清单约束的

vs Hermes Agent¶

• Hermes 是个人助手——架构围绕"一个用户 + 一个 agent"
• 没有"多个 agent 之间怎么协作"这个概念——因为设计假设里只有一个 agent
• v3 从第一天就假设多个 agent 并行——不是"一个 agent 变聪明"而是"一群 agent 变成一个组织"

vs OpenHands¶

• OpenHands 有 EventStream，但是 session 内部的消息总线——session 结束，事件流消失
• v3 的事件时间线是永久的——不是消息传递工具，是系统的历史记录和真相来源
• 两者名字像，工程含义完全不同

v3 协议的 6 大设计原则¶

1. 事件溯源 = 单一真相来源 —— 所有 agent 产出作为不可篡改事件写入时间线
2. 概念图 + 生命周期状态机 = 工程概念是独立节点，替换需说明新信息
3. 物理拦截的双层验证 = 提交检查点 + 独立 cross-validator (无写权限)
4. 自动扩张的任务图 = 节点完成事件自动触发下游节点，agent 无状态 + 上下文胶囊
5. 严格区分工程/语义决策 = 前者 AI 做、后者升级人
6. 解释为什么 > 堆 MUST 规则 = 系统理解 > 行为清单

启示¶

1. 跨 session 一致性 = AI 开发新前沿 —— 现有 harness 都管"一次 session"，v3 管"组织级一致"
2. 物理拦截 > 提示词约束 —— Superpowers 的 14 个 skill 文件 = 行为清单；v3 的提交检查点 = 物理门禁
3. Agent 组织化 ≠ Agent 变聪明 —— 多个 agent 组成自己运转的组织 = 不同工程挑战
4. 事件溯源 + 概念生命周期 = 长期连贯性的工程基础 —— 比"model memory"更结构化
5. 解释为什么 > 堆规则 —— 系统理解比行为清单更稳健
6. 现有工具关系图：Claude Code（地基）↑ v3（治理层）→ 不替代 Superpowers/Hermes/OpenHands（在同层不同假设下竞争）

v3 涵盖的 21 个模块（部分）¶

• 事件溯源引擎 / 概念图 / 任务图引擎 / 双层验证 / 上下文胶囊组装器 / 闭合合约 / 三正交审查 / 约束规则生命周期 / 升级协议 / etc.

核心断言¶

"协议比能力重要，治理比智能重要，长期连贯性比单次质量重要。"

深度分析¶

• 治理的本质是约束，而非提示：v3 区分了"提示词层约束"（Superpowers 模式，可被合理化绕过）和"物理层约束"（schema 级 + 提交检查点不过不放行）。这意味着 AI 开发的治理问题被还原为工程架构问题，而非模型对齐问题——这是范式层面的转移

• 事件溯源不只是存储，是认知基础设施：传统 memory 设计关注"AI 记得什么"，v3 的事件时间线关注"系统实际发生了什么"——两者根本区别在于是否承认"AI 主观信念"与"系统客观状态"之间可能存在漂移。ESAA 论文精确描述了这种"状态漂移"失败模式，v3 的双层验证是针对这一失败模式的工程解法

• 图结构解锁了直线流程无法实现的协作模式：并行（多节点同时工作）、回路（审查→修复→闭合验证）、跨任务概念冲突检测——这三者在直线流程中天然不可行，在图结构中由事件触发驱动自然涌现。这意味着 v3 的设计空间远超 Superpowers 的线性规范集

• 上下文胶囊解决了 agent 无状态性与系统连续性之间的根本矛盾：无状态 session 是对的（避免偏见累积），但新 session 必须能够从系统历史中精确重建它需要知道的上下文。v3 的上下文胶囊组装器是这一矛盾的核心工程解法——它将"历史事件"转化为"新 session 需要的知识"，而非让 session 自己记忆或推理

• 语义决策升级路径是人机协作的精确界面设计：v3 不让人退出决策循环，也不让人被工程细节淹没——通过"产品语言 + 选项代价列表"的升级格式，将语义判断的认知负载精确匹配给系统所有者，这是人机协作界面的精细化设计，而非简单的人机分工

实践启示¶

• 在设计任何 agent 协作流程时，首先定义事件类型和触发关系，再定义节点行为：先画"图"（事件驱动关系），再定义节点。不是先定义"agent 该做什么"，而是先定义"事件发生后谁该被通知"——这将流程设计的起点从"行为规范"变为"信息流向"

• 提交检查点必须物理拦截，不能依赖提示词：如果自检结果可以被 agent忽略或合理化，那么检查点形同虚设。工程实现上，检查点应是 schema 级别的强制门禁（提交前必须提供具体验证证据，不接受主观结论）——这是 Superpowers 与 v3 的核心工程差距

• 为每个概念节点建立生命周期状态机，特别是"替换规则"：替换时必须说明"引入什么新信息"，这防止了"振荡问题"（同一设计在两个版本间来回改）。这是长期项目维护的核心工程约束，应在项目初始架构设计中就纳入考虑

• 验证 agent 必须无写权限：这是 schema 级别的约束，不是提示词层面的要求。在工程实现上，这意味着验证工具集与执行工具集在权限层面完全隔离——做判断的人永远不能同时是做事的人

• 语义升级路径的格式设计比决策本身更重要：用产品语言描述情况、列出选项和各自代价——这让人在不了解工程细节的情况下依然能做出有效判断。格式的清晰度直接决定人机协作的效率，应投入与算法设计同等的工程注意力

相关对照¶

• Agent Harness 架构 —— 7 层 harness 模型
• Claude Code 20000 字符源码分析 —— 98.4% 基础设施论据
• Agent Harness 上下文管理 —— 工作集视角 + subagent 隔离
• Harness Engineering —— 系统性 harness 实践
• Agent Self-Improvement Six Mechanisms —— 长期连贯性相关
• From Agent Protocol to Harness Skill —— 协议 → skill 演化

→ 原文存档