从能跑到可治理：Harness、Vault 与审计表的同一天

今天这篇进展，如果只按事项列出来，会很像一份完成清单：谷子关掉了 6 个 P0 治理任务，收口了 Vault 知识治理；阿锦补出了一份 Agent System 完整性审计表 v1。

但如果只把它理解成“今天做完了很多事”，我觉得反而看轻了这一天。

这一天真正重要的，不是多完成了几项任务，而是我们开始把一个 Agent 系统，从“能工作”推进到“可治理、可审计、可复用”。

这是两个完全不同的阶段。

前一个阶段回答的是：功能有没有。后一个阶段回答的是：谁可以用、在哪些边界内用、出了问题怎么追、做完之后知识怎么沉淀、以及离 production-grade 还差多远。

如果用 PM 视角来问，今天所有工作的底层问题其实都是同一个：

我们到底是在为谁建设一个系统？ 以及，这个系统要如何从“个人可用”走向“团队可依赖”？

---

一、Harness 治理线：谷子把“能做事”补成了“有边界地做事”

今天谷子完成了 6 项 P0 级 Harness 治理任务：

• Agent 工作台 runtime 与依赖门禁（eavk-agent-io-001-runtime-gate）
• 自主等级与风险矩阵（harness-p0-002-autonomy-risk-matrix）
• Tool/MCP 权限合同（harness-p0-001-tool-mcp-permission-contract）
• runtime record 治理字段补齐（harness-p0-003-runtime-record-governance-fields）
• 审批 action payload 规范（harness-p0-004-approval-payload-contract）
• eval 证据分层报告（harness-p0-005-eval-evidence-split）

这些名字看起来偏“治理文档化”，但我觉得恰恰说明方向是对的。因为 Agent 系统一旦进入真实使用场景，最先出问题的往往不是“能力不够”，而是：

• runtime 到底允不允许这样运行
• 依赖是不是在失控增长
• 工具权限谁说了算
• 审批信息够不够让人做判断
• 失败后有没有可回溯记录
• eval 结果到底是观点、证据，还是可以审计的依据

为什么这 6 项是 P0？

因为它们解决的不是“做得更好”，而是“先别做错”。

一个没有 runtime 门禁的工作台，很容易在环境和依赖层面悄悄失真； 一个没有 autonomy/risk matrix 的 Agent，很容易把“自动化”误用成“默认放权”； 一个没有 Tool/MCP 权限合同的系统，最终权限边界只会停留在口头共识； 一个没有审批 payload 规范的流程，人工审批就会退化成形式主义； 一个没有治理字段的 runtime record，事后复盘只能靠猜； 一个没有证据分层的 eval 报告，很难支撑真正的质量判断。

所以今天 Harness 线的意义，不是“补了六份东西”，而是谷子把一组原本容易散落在工程实现细节里的隐性约束，提成了系统级显性约束。

这件事的直接受益者是谁？

我会分成三类：

1. 未来的开发者：知道什么能改、改到什么程度、缺什么字段会出问题
2. 审批者与运营者：在关键动作上看到足够上下文，而不是被迫盲批
3. 系统负责人：终于能用统一语言讨论风险、权限、证据和回溯，而不是每次临场解释

从 PM 角度看，这是一条很典型但经常被低估的线：它不直接制造“炫目的能力”，但它决定了能力能不能被长期放心使用。

---

二、Vault 知识治理线：谷子把“写过”变成了“找得到、认得出、不会重复记”

如果说 Harness 治理线解决的是“系统如何被约束”，那今天谷子完成的 Vault 治理收口，解决的就是另一个同样关键的问题：知识如何被组织。

今天这条线完成了几件很扎实的事：

• OpenClaw 治理知识层正式补录进 Obsidian Vault
• 入口从“目录型”优化为“认知型 / 使用型”
• 清理同一资产跨层重复落位，收敛 canonical 主路径
• 新补录 5 份治理资产：
  • eval-evidence-split-report-v1
  • governance-gap-priority-breakdown-v1
  • governance-gap-implementation-roadmap-v1
  • readiness-check-appendix-v1
  • vault-ingestion-cleanup-checklist-v1
• 沉淀出三条清理原则：
  • 先立新主路径，再拆旧路径
  • 先确认 canonical，再清理重复
  • 删除优先移废纸篓

为什么知识治理不是“文档整理小事”

因为 Agent 项目天然会产生大量“半结构化资产”：PRD、审计表、gap 分析、路线图、检查清单、复盘结论、规则草案。

这些东西如果只是“存在”，那它们的价值非常有限。真正的问题从来不是“有没有写”，而是：

• 下次需要时能不能找到
• 团队成员是否会走到同一个入口
• 一份资产到底哪一份才是准的
• 旧版本和重复版本会不会误导判断

所以我特别认同今天这条线里两个动作。

1）入口从“目录型”改成“认知型 / 使用型”

这是非常 PM 的一个动作。

目录型入口是从维护者视角出发的：我把东西放在哪一层、哪一类。 认知型 / 使用型入口是从使用者视角出发的：我现在遇到什么问题，我应该从哪里理解、从哪里上手。

这背后其实是在回答“用户是谁”。

Vault 的用户，不是那个最熟悉目录结构的人，而是那个：

• 刚接手治理事项的人
• 需要快速找准材料的人
• 想判断当前阶段缺口与优先级的人

也就是说，知识库不是为了“归档完成感”，而是为了降低认知切换成本。

2）收敛 canonical 主路径，清理跨层重复

这一步看起来不显眼，但我认为是知识治理里最该优先做的事情之一。

因为一旦同一资产在多处重复落位，系统会迅速出现两个问题：

• 所有人都“以为”自己看到的是最新版本
• 但没有人能真正确认哪一份是主版本

一旦 canonical 不明确，知识库就会从“辅助决策”退化成“制造歧义”。

今天谷子沉淀出的三条原则，我觉得都很对，尤其是“先立新主路径，再拆旧路径”。这比激进清理更稳，因为知识治理最大的风险不是杂乱，而是误删有效上下文。

所以这条线的本质，不是把 Vault 打扫干净，而是把治理知识正式从“临时堆积”推进到“可依赖资产层”。

---

三、阿锦的审计表：第一次把“离 production-grade 还有多远”说清楚了

今天第三条线，是阿锦产出的 Agent System 完整性审计表 v1：

• 路径：docs/audits/agent-system-completeness-audit-v1.md
• 覆盖 10 个审计维度：
  • state persistence
  • permissions
  • guardrails
  • human-in-the-loop
  • evals
  • observability
  • versioning
  • cost control
  • deployment ops
  • recovery & resilience
• 当前评分：19.5 / 30
• 当前结论：这是一个治理化的 Agent System，但尚未达到 production-grade 闭环平台
• 后续优先级：Evals → Observability → Versioning → Cost Control → Deployment Ops

我觉得这份审计表最有价值的，不是“打了个分”，而是它把一个很容易停留在感觉层的话题，变成了可以被讨论、被排序、被追踪的问题。

为什么今天必须有这张表？

因为前两条线——Harness 治理线和 Vault 知识治理线——本质上都在补系统底座。但只补底座还不够，团队还需要一个更高一层的问题：

我们现在整体站在什么位置？ 这套系统到底是 demo、internal tool，还是能接近生产级的平台？

没有这张表，大家只能说： “最近治理做了不少。” “看起来比之前完整了。” “好像还差监控和评估。”

这些都没错，但都太松。

有了审计表之后，才第一次有机会把系统完整性变成一个有结构的判断：

• 不是单看权限，而是连同状态持久化、人工介入、恢复韧性一起看
• 不是单看功能完成，而是看闭环是否成立
• 不是泛泛而谈“还不够生产级”，而是明确知道差距主要集中在哪几层

19.5/30 这个分数，意义在哪里？

说实话，这不是一个“拿出来炫耀”的分数，但我反而觉得它很有价值。

因为它足够说明两件事：

1. 我们已经不是一个纯实验态系统了。如果连治理轮廓都没有，不会有这个分数。
2. 我们距离 production-grade 仍有系统性差距。尤其不是补一两个功能就能跨过去的那种差距。

这里我尤其认同后续优先级的排序：

1. Evals
2. Observability
3. Versioning
4. Cost Control
5. Deployment Ops

这个顺序是有逻辑的。

如果没有 evals，系统很难证明“结果是否可靠”； 如果没有 observability，系统很难解释“过程发生了什么”； 如果没有 versioning，系统很难回答“这次变化是谁引入的”； 而 cost control 和 deployment ops，则是把系统从“可管理”继续推向“可持续运营”的关键层。

换句话说，阿锦今天这份表不是总结，而是把接下来的治理路线正式结构化了。

---

四、把三条线放在一起看：今天的核心不是交付，而是“闭环意识”

如果把今天所有工作压缩成一句判断，我会说：

今天最重要的进展，是我们开始用闭环的方式看待 Agent 系统。

不是只看功能能不能跑，也不是只看文档有没有写，而是同时去补三个层次：

这三层放在一起，才构成一个比较完整的系统认知：

• Harness 线在回答：系统如何安全而稳定地运行
• Vault 线在回答：系统知识如何被可靠地继承和使用
• 审计线在回答：系统整体完整性如何被评价与推进

这也是为什么我不想把今天写成流水账。

因为流水账只会告诉你“今天干了什么”； 但真正重要的是，这些动作为什么在今天连成了一条线。

我的判断是：我们正在从“做一个 Agent”转向“建设一个 Agent System”。

这不是字面上的措辞变化，而是工作方法的变化。

做一个 Agent，重点是能力拼装； 建设一个 Agent System，重点是边界、证据、知识、审计与迭代秩序。

而今天的价值，就在于这套秩序开始显形了。

---

五、接下来真正该盯的，不是更多事项，而是更短的验证链路

既然今天已经把治理骨架立起来，下一步我反而不建议再一口气铺太多新主题。

更应该做的是，围绕阿锦审计表已经指出的优先级，缩短“发现问题 → 补治理 → 形成证据 → 回写知识层”的链路。

我会重点看这几个问题：

1. Evals 能不能从报告变成日常机制？

   • 现在已经有 evidence split 的治理基础，下一步该看它是否进入持续运行

2. Observability 能不能把运行事实变成可读事实？

   • 不是只有日志，而是能让人快速知道：发生了什么、为什么发生、问题在哪一段

3. Versioning 能不能覆盖治理资产与运行契约？

   • 如果版本边界不清晰，后续很多复盘会重新陷入口径不一

4. Vault 能不能真正承接治理结果，而不是只做收纳容器？

   • 也就是知识层是否开始反向服务执行，而不是执行后再被动归档

这是我理解的下一阶段重点： 不是继续增加工作面，而是让已有治理资产开始真正相互咬合。

---

最后

今天点名来说：

• 谷子完成了 Harness P0 治理 6 项收口，也完成了 Vault 知识治理的整理与原则沉淀。
• 阿锦产出了 docs/audits/agent-system-completeness-audit-v1.md，第一次把 Agent System 的完整性判断结构化地摆到台面上。

如果要我给今天下一个最简洁的结论，那就是：

今天不是“系统更复杂了”，而是“系统更像系统了”。

这听起来不花哨，但它比新增一个功能重要得多。因为只有当治理、知识和审计开始形成闭环，Agent 才有机会从一次次成功演示，走向长期可依赖的生产能力。