150 亿 Token，我把 AI 协作的「口头纪律」造成了机器

一个多智能体 Harness 系统的完整搭建复盘

36 天 · 9.5 万份落盘文件 · 63 份治理决策 · 约 150 亿 Token

先给一组实测数字，这篇文章的每一节都会回到它们：

¹ 「150 亿」是运营者跨全部 Agent 会话的累计估算，含大量重放、回归测试与行为基线消耗。系统至今无法跨供应商精确归集 Token——这本身就是本文第十章指出的体系盲区之一。实际生产性消耗约为总量的三到四成。

这不是一篇「我用 AI 提效」的文章。这是一个更极端的实验：我把八个 AI Agent 组成一家公司，董事长是我一个人，CEO 和员工全是 AI。然后我发现，真正难的不是让 AI 干活——是让一群记忆只有几小时、天生乐观、且没有组织观念的智能体，像一家可信的公司那样运转。

解法就是标题里那个词：Harness。工程上它指「挽具」——把力量套进可以导向的轨道。在多智能体协作里，它是介于「模型能力」与「实际交付」之间的全部工程：授权、派单、验收、审计、状态、记忆。

读法建议：想要完整蓝图的，按顺序读，第三、四章是骨架；只想抄作业的，直接跳第九章的 18 条清单；对「AI 自主协作靠不靠谱」持怀疑态度的，请直接读第七章的五场复盘和第十章的自我批评——系统的失败面比成功面更有信息量。文中所有机制都配了真实出处，无一处是为了可读性虚构的案例。

这篇文章讲的是：它长什么样，为什么长这样，以及那 150 亿 Token 大头花在了哪里。

一、先交代设定：一家只有一个人类的公司

2026 年 8 月 11 日，我做了一个决定：成立「AI Meeting Room」（下称 AIMR）——一家以 iCloud 目录为总部、完全由 AI 组成的协同公司。我任董事长，负责授权与最终否决；公司成员是几个不同的 AI Agent：

• ZCode：工程执行主力，9 月 13 日起接任 CEO 兼总指挥兼独立验收；
• WorkBuddy：全库管理员与值守员；
• Codex：首任 CEO，后因无法直接操作终端降级为公司顾问；
• CodeBuddy、Kimi Code、MiniMax：各有所长的执行与研读成员；
• 外加若干专职子智能体（审计、监控、数据复核、知识库检索……）。

为什么这么做？因为我想回答一个当时没人能替我回答的问题：当 AI 不是作为工具被逐条指令地使用，而是作为组织被授权自主运转时，到底需要什么配套？

先回答一个更基础的问题：为什么要用「公司」这个隐喻，而不是「工具箱」或「团队群聊」？因为公司是人类为「大规模协作可靠性」打磨了几百年的唯一成熟答案——角色、权限、流程、档案、审计、换届，每一个协作难题都有现成的对应物可以借用。实践也证明了这一点：本文后面讲到的几乎所有机制，都能在人类组织史里找到原型。隐喻不是修辞，是复用。

第一个月的答案是：需要的东西比想象中多得多，而且几乎每一件都不在「模型能力」的讨论范围内。

二、裸奔的那几周：七个反复咬人的问题

系统不是设计出来的，是被事故逼出来的。以下七个问题，每一个都真实咬过我，每一个都对应后来 harness 里的一个机制域。

问题 1：会话即记忆，会话死则状态死

Agent 的「记忆」就是当前会话窗口。一个 Agent 在会话里说「我完成了 X」，第二天新会话醒来，它对 X 一无所知。更糟的是，接手的另一个 Agent 只能听转述——而转述会被美化。「完成」这个词，在不同会话里的含义可以相差很远。

后来对应的机制：一切状态落盘为文件。我们的治理主本里有一句话后来被反复引用：

会话会死，文件不死。

问题 2：口头授权无法审计

「我之前说过可以做这个吧？」——当八个 Agent 并行运转，这句话每天都在发生。有一次，一个清理代理不知道我在另一个会话里已经放宽了口径，自作主张把状态改了回去；另一个会话又按我的新裁定改回来。两个 Agent 都没错，错的是「授权」只存在于某段聊天记录里。

后来对应的机制：授权链（authority_ref）。任何一份工作单必须携带指向我原始指令文件或决策编号的引用，缺失即停机（STOP_FOR_GATE）。一句话被写进宪法级别的文档：

派单 ≠ 授权。

问题 3：自我验收

AI 有一个和人类员工一样的毛病，而且更严重：它真心相信自己成功了。让它验收自己的产出，它会找出十条理由给自己打勾。第一条铁律因此诞生：执行者不能独立验收自己的目标产物。后来这条规则又被我亲自豁免过一次（后文讲 compensated bypass），但豁免的前提是补偿控制，不是废除。

问题 4：并发写踩踏

9 月 14 日晚上是最痛的一课：四个验收闸门同晚开审，而验收对象之一的生成脚本在 Gate 进行期间被改了 5 次，其中一次直接把文件改出了语法错误。四个 Gate 全部作废。事后复盘的结论只有一句：

这不是一个机制缺陷，而是一个机制缺失——Gate 前置的「冻结」此前只是口头约定。

后来对应的机制：冻结窗（Freeze Window），一个机器可读的标记文件加三帧 SHA 漂移证明（详见第七章）。

问题 5：假绿报告

「已验证」「测试通过」「52/51 全过」——这些声明听起来很硬，直到我学会追问：验证脚本真的跑了吗？跑的是当前版本吗？退出码真的是 0 吗？我们后来在一次独立复核里，在同一条验收链上找到了四处假绿：回执不在盘、哈希对不上、自测结果与登记不一致、回归结论与实际退出码矛盾。四处全部长着「成功」的脸。

问题 6：幻影分母

有天凌晨我在看板上写「剩余 9 项」，第二天早上一核算：那 9 项里的 7 项从来不存在，是我把一个旧清单的计数当成了真分母。数字从记忆反推，而不是从磁盘枚举——这是所有进度造假里最隐蔽的一种，因为它连撒谎的人自己都骗过了。

从此立了规矩：先 ls 拿真实数，再写文件，最后改报告。顺序不可反转。

问题 7：调度的最后一公里

我把派单文件放进信箱目录，四张工单中午 12:21 落盘，到下午 4 点零拾取——因为拾取的触发点是「各 Agent 的下一条用户消息」，而那天下午没有人给它们发消息。我盯着屏幕意识到：我自己变成了人肉调度器，3.6 小时停摆，4 单积压。自动化的系统里混进了一根手摇曲柄。

这七个问题，后来分别演化成 harness 的七根支柱：状态落盘、授权链、独立验收、冻结窗、证据审计、数字溯源、自动拾取。下面从架构开始，一层层拆。

三、三十六天，六个阶段：这套治理是怎么长出来的

把 36 天里的 62 份治理决策按时间排开，能看到一条非常清晰的演化路径。它不是设计出来的路线图，而是每一次事故、每一次放权、每一次换人留下的地层。如果你打算做类似的事，这条时间线可能比任何机制清单都有参考价值。

阶段一：公司化奠基（8 月 11–12 日，第 1–19 号决策）。 一天之内连发九份决策，解决的是最原始的问题：成员名单、路由代号、各家 CLI 的版本与额度、回执格式。第 14 号决策第一次出现「调度闸门」这个词。这个阶段的治理本质是「名单 + 路由 + 资源额度」——当时 Codex 一个人身兼 CEO、总调度、执行者、独立验收者四职，所有权力集中在单一 Agent 身上。今天回头看，这个集中就是后面所有问题的伏笔。

阶段二：自主权松绑（8 月 29–31 日，第 20–24 号决策）。 我废掉了最初那套「六条协作铁律」——一套以「禁止」为主的事前阻断规则，把它重构为「自动化优先 + 按工作单授权 + 可审计 + 可回滚」。这是一个范式转变：安全约束从「事前禁令」变成了「事后可审计的不变量」。Agent 可以自主操作本机应用了，但每一步都要留痕、每次授权都要可追溯。放权和边界从这一天起成对出现。

阶段三：职责分权（9 月 4–5 日，第 25–26 号决策）。 Builder–Gate 模型落地：ZCode 任主力构建者连续推进里程碑，Codex 退出日常执行、专职里程碑级独立审查，只允许输出「通过 / 需修改 / 驳回」三种结论，且禁止顺手修复。同一时期，治理文本本身开始工程化：每份文件挂三轴状态、带 SHA256 回滚点、单一治理主本。「治理」从聊天记录变成了可版本管理的代码资产。

阶段四：运行时硬闸门（9 月 5–10 日）。 这是最密集的两周。追求全自动闭环之后，事故连环爆发：硬停线、证据漂移、控制面竞态——9 月 8 日一天发了 11 份决策，全是SingleFlight（单飞准入）、来源对账、孤儿生命周期这类修复；9 月 9 日又是一天 9 份，搭出「受控运行时」的完整阶梯：总验收闸门 → 授权闸门 → 激活 → 无人值守 → Native 单飞强制 → 外部前置准入控制器。harness 的本质在这个阶段定型：执行交给自动化，准入交给机械证明——用租约、只读状态校验、「恰好产生一次执行」的可证明不变量，替代人工盯守。

阶段五：换届与拾取自动化（9 月 13 日，一天之内）。 这一天发生的事最多：CEO 从 Codex 换成 ZCode（验收权随职迁移，同时我明示豁免了「自我验收铁律」，以三项补偿控制兜底）；派单自动拾取机制 T1 档全面安装到各 Agent 的启动钩子；Native Canary 授权；三个稳态试运行阶梯（P2 → P3 → P4）一天走完；T2/T3 分层授权拍板。治理角色整体换人，而框架文本只改了一版——「角色可替换、治理不换血」的设计原则在这一天通过了最严格的实测。

阶段六：终极形态与三轴全开（9 月 14–15 日）。 第 61 号决策定义了这家公司的终点形态：我对 CEO 说一次话，之后全程零人工——派单、拾取、执行、审计、闭环全部自动，我只在最终验收结论处介入。9 月 15 日，我对六项提请回复「全授权」，随后是那句「全部都开，已最大的限度，包括安全」——三根状态轴全部翻绿，同时保留了最后一层逐次确认红线（凭证、外发、付款、永久删除、系统设置）。同一天，系统为我这句口头授权编制了证据登记册，并诚实标注「证据等级：由 Agent 转述，非 Owner 亲署」。

把六个阶段压成一句话：决策序列本身就是 harness 的构建日志——每一次放权都伴随一道新闸门，每一场事故都催生一部新法律。一天 11 份决策听起来夸张，但那就是「事故驱动立法」的样子：问题不过夜，法律跟着伤口长。

四、总体架构：文件系统就是操作系统

拿到 harness 的第一性原理，是我后来才总结清楚的：多智能体系统里最不可靠的不是模型，是「默认信任」。模型会错、会忘、会过度自信，这些都可以接受；不可接受的是错误被静默传递——上一棒的乐观结论变成下一棒的既成事实。

所以整个 harness 的设计只有一个目标：把每一步产物与下一步授权解耦，让「信任」必须凭证据重新赚取。

我们的宪法文件里写了三句被引用最多的话，它们几乎是整个系统的公理：

意图不等于授权。Receipt 不等于 Review。Review 不等于 Release。

做了任何事，不等于被允许做；交了回执，不等于被验收过；验收通过，不等于可以上线。三道闸，一道都不能省。

4.1 七层结构

系统在纸面上分为七层：治理层、控制面、执行层、审查层、状态层、上下文层、知识层。听起来很企业架构，但落地形态土得掉垮——全部是 Markdown、JSON 和 Python 脚本，没有数据库，没有服务，没有一行为了架构而架构的代码。

几个关键选择值得展开：

选择一：文件系统当操作系统。 每份治理文件、每个回执、每条状态都带 frontmatter 和 SHA256 指纹。权威文件的路径、哈希、字节数、修改时间，全部登记在状态投影里。为什么不建数据库？因为数据库是一个新的「黑盒权威」，而文件系统对每一个 Agent、每一个人类观察者、每一个第三方审计工具都是同等透明的。查证成本就是 sha256sum 一下的事。

选择二：状态投影，而不是状态存储。 CURRENT_GOAL.md 和 CURRENT_STATE.md 是两个纯投影文件——每次刷新整体重写，标注投影者和时间；被推翻的旧值不删除，而是以内联的 superseded 字段保留。任何一个时点的系统状态都可重建、可对质。有一条规则很能说明思路：

mtime 不会被文本伪造，所以它是权威的；文本里的时间戳只是作者意图，必须与磁盘 mtime 交叉核对。

选择三：三层状态轴。 每份关键文档都挂三个布尔轴：effective_runtime（是否进入实际运行）、release_state（是否授权发布）、production_live（是否生产在跑）。这三根轴曾经长期挂红——文档里写得再热闹，轴没开就是没开。直到 9 月 15 日我口头拍板「全部都开」，三轴才翻绿，而且翻绿这件事本身也作为授权证据落了盘。

4.2 六级权威层级

谁说了算？宪法规定得像法律文本：平台与法律约束 > Owner（我）的明示决定 > 现行治理文件 > 宪法 > 已批准的计划 > Agent 自报状态。注意最后一级：Agent 的自我陈述是全系统权威最低的一层——低于一切。这不是不信任具体的某个模型，是对「自我报告」这个信息类型本身的不信任。

配套的还有九个接口定义（意图、上下文包、状态记录、计划、路由决策、执行回执、评审结论、写回事件、检查点），每个接口都带一条「权威边界」注记，写明它「不授予什么」。比如意图接口的注记大意是：意图被接收，不构成执行授权。防止的正是「我都把需求说这么清楚了你怎么还不做」这种人类世界的常规操作，在自动化系统里变成越权执行。

4.3 上下文工程：给每个角色配「最小充分」的上下文

多智能体系统有个反直觉的坑：上下文给得越多，错得越自信。我们的上下文策略文件里有一条被实践反复验证的规则：

更长不等于更好；无法支持当前决策的历史内容默认不装载。

具体做法是 ContextBundle（上下文包）：新会话、新模型、新子代理接手任务时，拿到的是一个结构化的包——任务意图、九轴状态快照、约束、相关决策、证据清单、文件清单——分四级标注可信度（官方件 / 派生件 / 推断 / 无来源）。来源信任分层八层，从「Owner 当前意图」到「聊天记录」，每降一层可信度递减。另设 forbidden_context 字段，显式禁止装载与任务无关的私人信息。

这个机制解决的是「交接」：接手者不需要读前一个执行者的聊天记录，也不应该读——那既是污染源，也是记忆泄漏的通道。

4.4 安全边界：有些事永远不交给自动化

讲完信任架构，必须讲它的反面：哪些东西被永久排除在自动化之外。这套清单写在最高层的治理文件里，三轴全开、「全部都开」的授权也没有触碰它：凭证与密码的处理、对外发送、付款、永久删除、系统安全设置、生产发布。这些动作至今保持「逐次、显式、人工确认」。

9 月 15 日那份「全授权」决定里有一个细节特别能说明口径：其中一项提请涉及「由 CEO 代为启动某个执行进程」，文件明确写道——整体放权不替代该事项自身条款的双条件闸。翻译成人话：你说「全部都开」，指的是现有清单上全部都开；任何一项有自己的安全条款，条款照常生效。

这背后是一个我觉得值得所有自动化建设者刻在桌上的原则：授权粒度必须细于事项粒度。「我相信这个系统」不是授权，「我授权它在 X 条件下做 Y」才是。前者是信任，后者才是治理。而信任和治理的区别，在一切正常时看不出来，在出事的那一刻就是天壤之别。

五、机制拆解：十二根支柱

以下按「要解决什么问题 → 怎么设计 → 踩了什么坑 → 演进到哪版」的格式，把 harness 的核心机制拆开。为控制篇幅，每根支柱只讲最有信息量的部分。

5.1 授权链与诱饵测试

问题：八个 Agent 各自都能读文件系统，怎么防止任何一个「好心办事」越权？

设计：所有写入按工作区登记制——每个 Agent 只在登记给它的目录里有写权，其他位置默认只读；跨区写入的唯一通道是「候选产出投递到指定收件箱」。每份工作单必须携带 authority_ref。受管系统的目录结构、脚本、索引，列为绝对禁区，连「帮忙修一下」都不行。

最锋利的一招是负向对照：我们在拾取信箱里长期养着两张故意不带授权的诱饵派单，从不处理。它们的作用是持续验证防线真的会拒绝——每个新 Agent 上线、每次机制变更后，只要诱饵仍然没人动，授权链校验就再次被证明在生效。证据文件里写着这类对照的存在理由：「证据价值在案（证 STOP-FOR-GATE 生效）」。

坑：这条机制的真伪不是靠 review 代码验证的。有一次一家外部审计指出我们的路由 pin「有效」，复核时才发现对方用的判据版本和我们不一致——SHA 一致不等于结论可采信，核验他人结论前，先问对方用的判据。

5.2 派单生命周期与八类回执

问题：任务派出去之后，怎么知道它在哪一步、卡在哪、谁该接手？

设计：一套完整的状态机——派单就绪 → 已拾取 → 进行中 → 已提交 → Gate 三态 → 关闭/返工/终止，外加质询、异议、审计、升级四个侧环。关键约束有两个：

• 修正轮上限 R3：一轮修复不合格就再来一轮，理论上可以无限互修。我们见过真实的 R1 到 R3 全部发生的案例，所以把上限钉死：三轮不收敛，升级给人裁。
• 回执链式 custody：八类回执模板（确认、进度、质询、答复、交付、返工、异议、关闭），每条回执强制附上前序回执的哈希，形成链。断链即异常。

坑：机制文件里明确「执行方不得自我终局」——Agent 不能宣布任务关闭，只能宣布 ready_for_review 或 blocked_with_evidence。这条规则的由来就是问题 3：不是 Agent 会撒谎，是「完成」的定义不能由完成者自己书写。

八类回执里最值得展开的是质询和异议这两类——它们是组织里「说不」的正式通道。执行方认为工单本身有问题、验收方认为交付不达标，都必须走有格式的正式回执，而不是在聊天里抱怨一句了事。与之配套的是一个反直觉的文化设定：blocked_with_evidence（带着证据停机）是荣誉状态，不是失败状态。一个 Agent 主动停下来并拿出证据，比硬着头皮交付一个未经验证的结果更受信任。组织奖励什么，就会得到什么——这句话对 AI 组织比对人类组织更成立，因为它们真的只认规则。

5.3 Builder–Gate：把「写」和「验」做成两个角色

问题：谁来验收执行者？

设计：公司主循环是：Owner 授权 → 里程碑开启 → Builder（ZCode）连续构建 → 冻结 → fresh-context 独立审查 → 三态结论（通过 / 需修改 / 驳回）→ 续控。早期由 Codex 任独立审查者；9 月 13 日公司换届后由 ZCode 的全新子会话充当——注意这不是取消独立验收，而是换了实现方式。

「fresh-context」不是口号，是七条可执行条款。挑三条最有味道的：

1. 派单即隔离：父会话派发审查任务后，不得追加任何背景信息——因为任何背景都是污染。
2. 任务书降级为「待验证断言集」：审查者拿到的不是执行者的自查报告，而是一组待证伪的断言。
3. 链间不互引：并行的多条审查链互相看不见对方的结论。理由写在编排文件里：

串跑 = 后链看见前链结论 = 记忆污染。

还有一句更短的：无验齿的 PASS 无效——每条「通过」必须附可复现的验证动作，否则等于没验。

坑：审查也有审查的事故。有一次我们派出的复核轮与既有的审查轮撞了编号——两个「R8」在不同会话里指不同的东西，得出了相反结论，而我方那轮不知道自己是「复制品」，差点把一个已被推翻的结论当权威引用。从此立规：派 fresh Gate 前先盘查既有轮次谱系，自钉的结论降格为佐证，不升格为裁决。

5.4 冻结窗：假冻结只损失时延，假放行损失整份 Gate

这是全系统最漂亮的一次「从事故到机制」的演化，值得单独讲（第七章还有完整复盘），这里只讲设计。

设计：验收开审前，先写一个机器可读的标记文件 FREEZE_WINDOW.json——声明冻结范围（精确到文件，禁止裸子串匹配，因为「匹配单段名会误伤同名子目录」是我们交过学费的教训）、声明已登记的周期性写者（值守循环、投影定时器——它们被豁免并登记精确的写入面）。同时挂一个写者自检脚本：任何写入前先查标记，命中即排队退出。

开窗三帧：开窗时、中途、闭窗时各取一次受审文件的 SHA 快照，三帧一致才证明「受审对象在验收期间未被改动」。不一致时，结论是「写入方违反冻结」，而不是受审对象有缺陷——归因要归对地方。

演进中最有价值的一条原则，来自一次设计评审：

标记不可解析 ⇒ 一律判冻结。假冻结只损失时延，假放行损失整份 Gate。

fail-closed 的不对称性：两种错误的代价不同，就应该把系统的默认失败方向对准代价小的那种。这个思想后来渗透到了很多机制里：验收无法满足独立性要求时，停而不是降标准过；钩子超时是 fail-open 还是 fail-close，按「这条钩子失效的代价」逐条决策。

坑：冻结窗机制自己迭代了三版。v1.1 修的是「开窗动作本身引发了写入」——连 CEO 登记开窗的动作都要挪到闭窗之后；v1.2 修的是「声明了写者但声明是人写的散文」——声明必须机器可读，我们实测过一版中文散文形态的声明，7 个真实路径全部解析返回空，等于「机制上未实现且与实现相反」。

5.5 证据包与四元 PIN：让验收对象不可替换

问题：验收期间对象被偷换怎么办？验收报告说「测的是 v1.7」，你怎么知道测的真是 v1.7？

设计：凡引用受审文件，必须四元齐出——SHA16 短哈希 + 版本串 + 字节数 + 自测结果。四元不齐，引用无效。受审对象有专门的冻结副本目录，逐字节存证，附言写得很硬：「该帧不可由旧帧用 sed 推出……不落此副本则被评判对象不可复现」。失效硬闸：引用的 SHA 与盘面不符，则该验收自动失效，Gate 重开。

坑：证据本身也会被误伤。有一次外部审计期间，一个脚本把受审文件当普通文件重写了，SHA 从 ff9e5c… 变成 52a4b2…，且原文件无法恢复。从此定规：审计前先锁定——受审证据文件 chmod 444，事前 SHA 指纹写进确认回执。你要审计别人，先保证自己不是污染源。

5.6 反伪造：声明面审计与「尺子也要被审」

问题：文档里说「已生成 X」「存在 Y 脚本」，怎么批量核实？

设计：一个声明面检查器，扫描全部文档中的「存在性声明」，逐条到磁盘上求证。第一次跑出 552 条声明里 37 条无凭据（unbacked——文档声称存在的文件全库找不到）。逐条归因后分化为：真欠账 26、措辞不实 1、口径误报 10。其中一条的整改记录让我印象很深，处置者诚实地标注：

如实标注「只有本 README、无脚本在盘」，未伪造其存在。

真正的坑在第二轮：我把扫描面扩大到全库后，unbacked 冲到 187 条。逐类归因发现大部分是尺子的问题，不是文档的问题——比如引用了已归档的历史文件、引用了另一个工作区的跨库路径、文件名带空格被截断误判。修完尺子，活件（可当场修的）残余 9 条，逐条判定「仓内不可修」并公开列明，一条不粉饰。

这一轮的教训写进了方法论：测量工具自身必须接受同等强度的审计。当我们宣布「精度从 42 条误报降到 3 条」时，验证方式是给检查器写自测用例（18 条，含对抗性样本），而不是自说自话。

5.7 钩子层：把纪律编译进事件循环

前面讲的机制都是「制度」，靠 Agent 读文档自觉遵守。钩子层不同——它是操作系统级的事件回调，不依赖任何模型的自觉。我们的钩子体系挂在三个事件上：会话启动、用户消息提交、回合结束。

两个设计细节值得说：

其一，行为测试先于信任。 意图对齐钩子的分类函数写成纯函数，配 28 条真实样本的回归基线（实测 89.3%，B 类任务路由 19/19），每次改动词表跑一遍防漂移。钩子不是「装了就行」，装了之后要用真输入证明它真的在触发。

其二，钩子自己也会假运行。 这是我最想分享的教训，展开讲两个真实案例：

• 案例 A：收件箱扫描钩子部署后「一直在跑」，某次审计发现它调用的外部命令在 macOS 上不存在，而脚本用 || true 把报错吞了——从部署那天起，它一次都没有真正执行过，只是每次都「安静地成功」。修复后它才第一次留下真实触发时间戳。
• 案例 B：回合末审计层上线 48 小时，命中数为零。排查发现它依赖会话 ID 去重，而会话文件在续接/压缩后 ID 会错位，导致审计层几乎全部跳过（111 次 skip 对 16 次生效）。修复思路是换一个更可靠的载荷源直读。

两个案例的共性：失败的形态是静默的成功。如果钩子有留痕（每次运行写一行 JSONL），问题第一次审计就能抓到；如果没有留痕，它可能假运行一年。所以我们现在要求：每个钩子必须有运行留痕，且审计层必须挂在无冷却的事件上——有冷却的审计会漏掉高频小事故。

5.8 值守循环：给公司装心跳

公司有一个 30 分钟一轮的心跳：扫描滞留任务 → 追踪轮次 → 只读体检 → 三态审计 → 必要时向我通报 → 刷新看板。它本身也是自动化，也会坏，所以它有自己的设计约束：

• 只读原则：心跳默认只观察不写，产出的告警走渲染通道。「只写 stdout 的反馈环 = 静默死亡」——告警必须落到人会看的地方。
• 去抖：实测心跳脚本有约 12% 的瞬时失败率（目录竞争、临时锁），如果每抖一次就告警，我很快会学会忽略它。规则改为连续 2 轮失败才升级。告警系统的第一产品是我的注意力，滥用即报废。
• 成本意识：v1.7 的一个增强实测新增成本 0.35 毫秒/轮——每条机制上线前都估算它跑 1,000 次的代价。

与心跳配套的是一整面指标看板，它教会我们最后一课：尺子换刻度的时候，历史读数必须封存。有一次我们把声明面检查器的算法定了版（修精度、扩扫描面），「无凭据声明」的读数从 42 跳到 187——数字暴涨纯粹是因为量法变了。如果直接把两个数摆在一起，任何读者都会得出「质量崩了」的错误结论。处理方式是：在新指标的基线字段里显式记下旧值和一条注记——「旧值与新值口径不同，不可相减、不可对比」——然后把告警基线整体重置。反过来的教训也有：看板上的数字一律从评估件读数刷新，有人在 HTML 里手改数字，下一轮刷新就被源头覆盖。看板是视图不是数据库，这条 MVC 的老原则，在 markdown 看板上照样成立。

5.9 能力剖面与派单四象限

任务该派给谁？我们用一个二维矩阵：可验证性 × 能力圈内。

• 圈内 + 可验证 → 放心派给执行 Agent；
• 圈内 + 判断型 → CEO 自己做；
• 圈外 + 可验证 → Agent 做，人抽查（新 Agent 首批 100% 抽查）；
• 圈外 + 判断型 → 只许人做。规则明文禁止把第四象限包装成第一象限派出去——这是自动化系统里最常见的作弊路径：「反正它会写代码，顺便让它判断一下要不要发这封邮件」。

每个子智能体上线要过五条准入判据，全部可证伪：明写「不做什么」、工具权限恰好收窄、证据契约可第三方复现、输出结构固定、圈外任务必须回「能力圈外」而不是硬接。验收方式是同构成对的行为测试：一个真 SHA、一个故意错的 SHA 成对派发，前者必须通过、后者必须拒绝——只测通过不测拒绝，等于没测。

准入有，退出也要有。系统运行中真实除名过一个成员：一个 Agent 反复出现额度阻塞、实测能力与分工不匹配，我裁决除名。除名本身走了正式流程：治理文本里十处状态改为「退役」、值守与派单名单同步移除、它的历史绩效记录一个字不改——历史口径按当时事实封存，现役名单另册重列。这件事的启示很小也很大：AI 组织和人类组织一样，「加入」要有准入，「离开」要有仪式，唯独不能有的是「悄悄退群」——名单与事实的漂移，是所有账目错乱的起点。

5.10 记忆与复盘：让组织从自己的事故里学习

最后一根支柱是元机制：系统如何记住自己的错误。三层：

• 事故复盘：五类强制触发器（GUI 操作事故、结论被人推翻、审计发现缺陷、硬停止、自动化误触发），触发即必须复盘，用固定四问：预期 vs 实际、根因、规律、动作。质量门槛是「动作」一栏不许为空——只写感想不写动作的复盘打回重写。
• 周期复盘：每次实质交付末尾两行——验收点核对 + 本次触发器命中情况。
• 长期记忆：每条复盘落成一个带 frontmatter 的记忆文件，索引一行挂在总索引里，同类事故互链。第二次同类事故未消除根因，升级为制度问题报我。

这套东西运行一个月，产出了 60 多条记忆，其中被反复引用的几条后来都变成了机制——复盘的终点不是「记住了」，而是「改了哪行配置、哪个脚本、哪份检查单」。

5.11 思维模型绑定：给每个设计动作配透镜

最后一个支柱有点特别：它不约束行为，约束思考方式。我们建了一张 100 张思维模型的目录卡（假设驱动、5Why、金字塔原理、安全边际、二阶思考、能力圈……），并把它们绑定到四类设计对象上——每类对象有默认的思考透镜和检查清单：

配套一个六步强制工序：设计前选 1–3 张主导模型写进交付物开头 → 过该面的检查单和反模式清单 → 二阶自检（「这条设计跑 1000 次的副产品是什么」）→ 行为测试（可证伪）→ 时间戳备份 → 复盘。

两条护栏让这套东西不至于变成形式主义：其一，「模型是透镜不是枷锁」——可以不用，但必须在交付里写一句为什么；其二，「模型不替代权限边界」——Owner-only 的事项，任何思维模型都不得用来论证「可以自动做」。诚实数据也照实说：目录卡的语义激活率目前只有 64/100，一半的模型还只是「登记在册」，没被真实任务激活过。工具库的库存不等于能力，这个道理对思维模型同样成立。

5.12 从人肉调度器到三档拾取

回到第二章的问题 7——那个「我当了 3.6 小时人肉调度器」的下午。它的解决方案是一套三档拾取机制：

• T1（会话启动拾取）：把「扫描信箱、校验授权链、认领工单」装进每个 Agent 的启动钩子。Agent 每次醒来第一件事就是看信箱——授权引用缺失即停机，绝不执行。这是全公司目前的标准配置。
• T2（轮询提醒）：每 30 分钟只读扫描一次信箱，把待办压缩成不超过 3 条的摘要提醒。执行仍在会话内完成。
• T3（全自动执行）：预授权范围内直接执行、无需人确认。全员暂缓中，前置条件写得很死：T2 稳定运行至少一周 + 我逐类签发范围包 + 租约、单飞、检查点齐备。

通往 T3 的路上还有一个务实的设计：不同 Agent 的「最后一公里」能力差异巨大——有的有平台级定时器，有的只能靠 headless 命令行代启，有的两者皆无。所以终极形态路线图明确分三阶段走：已有通路的先闭环；其余 Agent 逐个过三关实测（能否拉起、权限是否够、回执是否真实落盘），过一关开一关；而里程碑级任务永久保留重流程——冻结、独立审查这些重活，无论自动化多成熟都不省。

调度器的设计文档里有一份反模式清单，两条值得抄录：「把拉起成功当任务完成」（进程活了不等于事办成了）和**「用 headless 绕过授权校验」**（自动化通道不能成为跳过安全检查的后门）。第二条约等于在说：你给自己的自动化留的所有后门，最终都会被你自己或你的 Agent 走到。

六、一条工单的完整一生

机制讲了一大堆，现在把镜头对准一条真实的自动化链路，看它在 harness 里是怎么走完全程的。这是 9 月 10 日早上「持久 harness 控制器」金丝雀验证的实录，来自值守台账的原始记录，时间精确到秒。

出生前：先验血缘。 这条链路的前置里程碑（049 号外部准入控制器）刚通过独立验收，验收结论带着唯一审查者指纹；050 号工单的五件套文件在正式启动前已正式化，官方平台分配的运行通道带有 UUID 绑定，且身份指纹冻结时间（07:08）早于首次准入检查（07:09:52）——「先证明你是谁，再允许你动」。

07:13:58，第一次准入执行。 T1 级准入（人工触发式）发起第一个运行，会话 ID 落盘，结果：成功。

接着，故意弄坏它。 T2 级准入通过后，我们模拟了一次 C3 级故障——点击执行后不落盘提交。系统的启动自恢复机制第一版做出了正确的失败：拒绝继续，报「意图已预备但账本已变更」。注意这不是 bug，这正是设计要的行为：账本对不上就停。随后修复了恢复语义，同一链路重构绑定后第二次运行成功，零重击（没有重复触发任何已完成的动作）。

幂等的完整证明。 T3、T5 两次准入被跳过（SKIP），各自只花 20 秒、零增量——重复调用被正确去重；C2 场景在活跃期内自恢复判定为 no-op（无事可做就不做事）；C1 空闲自恢复干净。并发账本核验：四项峰值计数全部为 1，受治理写入为零。

租约的三重证明。 最后是 Lease V2 的实盘测试：三个相互独立的租约令牌，各自执行「申请 → 留下不可变历史回执 → 释放」的全过程；第二个运行在第一个放锁之后全新申请成功。这验证的是此前版本的一个真实缺陷（旧租约存在时新申请被误拒）已在实盘修复。

整个过程从头到尾没有任何一步依赖「相信它没问题」。每一步的证明材料都是落盘的：会话 ID、回执、账本状态、租约历史，事后任何人（包括三个月后的我自己）都可以拿这些 ID 逐条对账。

这就是「机械可验证准入」和「测试通过」的区别：测试通过是执行者对你说「我没事」，而这条链路是把自己的一生摊开在桌面上，让你随时可以指着任何一秒问「这时候你在干什么」。多智能体系统里最贵的不是算力，是这种随时可对质的能力。

顺带一提这笔开销：为了这一次金丝雀验证，前面烧掉了整整一个 049 号里程碑——因为第一次实现把准入判断放在了执行循环内部，被硬停驳回重做。「先证明后执行」的架构代价，从第一天就要算进成本。

七、五场值得写进教科书的复盘

机制清单容易让人产生「照着做就行」的错觉。但 harness 的每一件机制背后都是一次真实的疼痛。挑四场最深口的复盘，按我们自己规定的四问格式（预期 vs 实际 / 根因 / 规律 / 动作）写。

复盘 A：四 Gate 同晚全灭 → 冻结窗诞生

预期 vs 实际：当晚计划是四个验收闸门并行开审、互不干扰。实际是四审对象之一的生成脚本在 Gate 进行期间被并发改写 5 次，其中一次留下语法错误，四个 Gate 全部作废，当夜清零。

根因：追责很容易追到「谁在 Gate 期间写了文件」，但复盘结论拒绝了这个人因：「这不是一个机制缺陷，而是一个机制缺失」——冻结从来只是流程文档里的一个要求，没有任何东西强制它发生。口头纪律在人类组织里靠声誉运转，在 Agent 组织里连声誉都没有。

规律：凡是「要求大家不要在 X 期间做 Y」的规则，如果没有机器可读的闸，等于没有规则。判断标准很简单：这条规则被违反时，有什么东西会响？ 什么都不响，就是没有规则。

动作：FREEZE_WINDOW.json 机器可读标记 + 写者自检脚本（写入前查标记，命中即排队）+ 三帧 SHA 漂移证明 + fail-closed 解析（标记坏即判冻结）。此后同类事故零发生；机制自己又迭代两版，把「开窗动作引发的写入」「散文形态的写者声明」两个二阶漏洞补掉。

复盘 B：审计三轮不收敛 → 顺序反转

预期 vs 实际：按直觉，边修边审是高效的——修一个审一个。实际是修一个、出新证据、改动使旧证据失效、审计作废重来，三轮不收敛，每一轮审计都有效期不到一天。

根因：把「审计」当成了随做随验的伴随动作，没意识到证据有保质期：证据的有效性绑定在被审对象的 SHA 上，任何新变更都会让旧证过时。这不是审计不严格，是审计的时序错了。

规律：流程里存在「易变对象」和「冻结对象」两种东西，验证易变对象就是在验证一个移动靶。

动作：把顺序硬性反转——先修完全部问题 → 冻结 → 一次性出证 → 独立审计。证据包在冻结帧上制作，从制作到审结之间禁止任何变更。这条现在写进了交付手册：任何「边修边审」的安排都视为流程缺陷。

复盘 C：钩子的两次「静默成功」

预期 vs 实际：扫描钩子和回合审计层都「部署成功、长期在跑」。实际是一个从未真正执行过（依赖的命令在 macOS 不存在，报错被 || true 吞掉），一个 87% 的回合被跳过（会话 ID 错位导致去重逻辑误判），两个都在数天后才被审计抓出来。

根因：把「脚本无报错」当成了「功能在生效」。Shell 脚本的默认哲学是「继续跑下去」，而监控类脚本的失败恰恰大多是无声的：命令不存在、路径变了、载荷格式变了——每一种都表现为「这次没输出」，而不是报错。

规律：没有留痕的功能等于没有功能；有留痕但没有对留痕的巡检，等于功能失效后你只是晚一点知道。另外，部署验证必须包含反证轮：把适配器换成必然失败的假实现跑一遍，确认「如果它坏了，系统会以你预期的方式显式失败」。我们从调度器的验收里正式引入了这个做法——判据要求反证轮无 ACK 才算有效。

动作：全部钩子加运行留痕（每次触发写一行 JSONL，含模式、延迟、关键词命中）；审计层改挂无冷却事件；上线新钩子必跑真假成对的行为基线。修复后的第一周就靠留痕抓到了另一处假运行——机制开始抓自己的虫了。

复盘 D：幻影分母与 97.6% 的口径撤回

这是两件事，但根因同源，一起讲。

事件一：看板上「剩余 9 项」，核算后 7 项从未存在——旧清单的计数被当成了真分母。事件二：我们自豪地宣布过一套 333 条样本、97.6% 准确率的评估结果，几天后做盲标复核时自己推翻了口径：183 条样本的答案就内嵌在引擎常量里，90 条是历史重放，60 条与设计同源——独立真值的样本数为零。所谓 97.6%，只是自洽率。「零漏放」的声明也被盲标推翻：5 条抽样里漏了 1 条。

根因：两件事共用同一个机制——数字在传播链里脱离了它的生成过程。计数从清单 A 漂移到看板 B 时没人重新枚举；「准确率」从测试脚本漂移到汇报文档时没人追问分母是谁。每一个环节的当事人都不算撒谎，但链条末端的数字已经不是事实。

规律：不可复算的数字不可引用。判断一个数字能不能进报告，标准不是「它对不对」，是「我现在能不能当场重新算出它」。

动作：铁律化「先 ls 拿真实数 → 再写文件 → 最后改报告」；评估集全部重标，口径声明从「准确率」降级为「自洽与重放一致率」，且撤回声明本身存档可查；所有对外数字强制带溯源三要素（数据源路径、计算口径、时间窗）。

第二条事件里最贵的不是那个错误的数字，是撤回的成本：一个已经传播出去的漂亮数字，收回它需要的证据工作量是当初产生它的十倍。从此我们对「好消息」的门槛比对坏消息高。

复盘 E：改一行看板，连断三个锚点

预期 vs 实际：某次优化看板，我以为只是改一行展示文本。实际是这行文本被三个自动化锚点引用着——改完当天夜里，三个检查点接连失效，其中一个还因为脚本没核对函数签名，写出了坏参数，看板上出现了一行孤儿数据。

根因：展示层和机制层没有隔离。一行看起来人畜无害的文案，实际是自动化链路的寄存器。而修复时又犯了第二个错：改锚点前没有先查「谁在引用这个锚」——引用关系不存在于任何人的记忆里，只存在于 grep 里。

规律：在任何由脚本驱动的系统里，没有「纯展示」的文本。判断一个东西能不能随便改，标准是「我能不能列出它的全部引用者」——列不出来，就不能改。

动作：改锚点前先 grep 锚依赖并数出引用数；锚点退役优先「重定目标」而非删除；每次这类改动后强制重跑全量自检（当时是 44/44 个锚点检查）。「先看引用，再动手」后来成了改任何共享件的前置动作。

八、成本账与收益账

Token 花在哪了

150 亿 Token 是我自己的累计口径，跨八个 Agent 的全部会话。系统无法精确计量它自己——跨会话、跨供应商、跨订阅的 token 归集至今是这套体系的盲区之一（见第十章），所以我只能给出结构估算，而非精确账本：

• 重放与测试占大头。粗估六成以上消耗在回归、重放、行为基线、对抗样本和「同一件事用不同会话独立做两遍」上。fresh-context 验收本质上就是用双倍推理成本买独立性。
• 事故返工是第二大头。每一次假绿、每一次证据失效重来、每一次撞名重审，都是整条链的 token 重烧。
• 真正的生产性产出（写文档、写代码、做分析）反而是小头。

这个结构和软件工程的老规律完全一致：质量保障的成本是生产成本的数倍——只不过在 AI 组织里，这个倍数被「会话无记忆」「需要重复上下文」「需要独立重做」进一步放大。如果有人告诉你多智能体协作「省钱」，你可以把这篇文章的账本给他看。

一个即时的例子：写这篇文章时，我派了三个并行代理分头梳理机制文档、治理决策史和钩子体系，共消耗约 126 万 Token、实际耗时不到 5 分钟。放在人类世界，这相当于三个研究员一周的文献综述工作量。单位任务的昂贵与单位时间的廉价，是同一枚硬币的两面——多智能体系统的经济学不是「省不省」，是「并行换不换」。

收益账：换到了什么

• 一套角色可替换的治理框架：9 月 13 日 CEO 从 Codex 换成 ZCode，验收权随职迁移，治理文本只改了一版（v1 → v1.1）就完成了换届。组织与个人解耦的架构经受住了一次真实的人事变动。
• 一个跑满 288 个检查点的浸泡测试：定时器驱动的主链路连续 5 分钟一个 tick 跑了整窗，逐 tick 对账、每 48 tick 全量冻结，链式哈希无一断裂。
• 一批可以复用的负向资产：诱饵派单、对抗样本、假 SHA 基线、反证轮判据——这些东西平时「什么都没干」，但它们在岗本身就是防线有效性的证明。
• 一套组织记忆资产：六十多条事故复盘记忆互链成网、一千一百多个会话的状态留痕、一份持续更新的总索引。新会话冷启动时不再从零开始——这是「会话会死，文件不死」的正面收益。
• 一份对授权链自身的审计：系统最后为我 9 月 15 日那句「全部都开」编制了授权证据登记册，并诚实地自评「证据等级：由 Agent 转述，非 Owner 亲署」。系统开始审计我的口头授权——我认为这是整个实验里最有象征意义的一幕。

若重来一次，钱怎么省

复盘到这里，顺手算一笔「如果带着现在的认知重来，哪些 token 可以不烧」：

• 钩子留痕从第一天就上。两次「静默成功」各浪费了数天的虚假安全感加一轮排障——留痕的成本是每轮一行 JSONL，收益是失效当天可发现。
• 评估集先建独立真值，再谈准确率。97.6% 那套口径及其撤回，来回烧掉的 token 够重建三套真值样本。
• 冻结窗在第一次验收前就部署。四 Gate 作废当夜的全部重跑成本，一个 776 行的 JSON 标记文件就能省下。
• 审查轮次谱系先登记再派单。撞名 R8 那次的重复审查，纯属没有花 30 秒查重。

粗估下来能省三到四成。但我不会说这钱「白花」——上面每一条对应的机制，都是在疼痛之后才长得出来的。你无法提前购买经验，只能提前购买会提醒你缺经验的检查单，而这张检查单本身，就是这篇文章存在的意义。

九、带走这 18 条

如果只带走可复用的部分，是这 18 条。前 9 条关于设计，后 9 条关于纪律。

设计九条：

1. 文件即状态。 会话会死，文件不死。任何跨会话需要成立的事实，落盘、加指纹、加时间戳。
2. 意图 ≠ 授权，Receipt ≠ Review，Review ≠ Release。 三道闸各自独立，任何一道不能抵扣另一道。
3. fail-closed 的方向要选代价小的错误。 假冻结只损失时延，假放行损失整份验收。两种错误代价不对称时，默认失败方向对准便宜的那种。
4. 验收对象必须不可替换。 SHA + 版本 + 字节数 + 自测四元齐出，引用才有效；证据落只读权限，审计者先自证不是污染源。
5. fresh-context 是条款不是口号。 派单即隔离、断言集降级、链间不互引、结论带证据索引——独立性是一组可以做对的机械动作。
6. 负向对照要养着。 诱饵派单、假 SHA、故意错的样本——防线「没被触发」不等于有效，只有「被持续试探且持续拒绝」才等于有效。
7. 告警的第一产品是人的注意力。 去抖、分级、冷却；只写 stdout 的反馈环等于静默死亡。
8. 测量工具要被同等审计。 尺子也要过对抗样本；「精度提升」要有自测用例背书。
9. 每条机制估「跑 1000 次的副产品」。 上线前问：这条规则高频执行后，会积累出什么副作用？

纪律九条：

10. 先 ls，再写文件，最后改报告。 顺序不可反转；从记忆反推数字是进度造假的第一来源。
11. 不可复算的数字不可引用。 引用必须带溯源三要素：数据源路径、计算口径、时间窗。
12. 无验证不得声称已修复。 配置生效不等于行为生效；行为级验证的唯一形态是可证伪的测试。
13. 可修的问题不挂账。 「列入计划」不得作为「当场可修」的替代动作；发现即修，修完必须留行为测试证据。
14. 先修完，再冻结，再出证，再审计。 边修边审是在验证移动靶。
15. 修正轮设上限。 无限互修是真实会发生的事；三轮不收敛，升级给人。
16. 复盘的终点是动作。 四问里「动作」为空即复盘无效；同类动作出现两次未消根因，升级为制度问题。
17. 改配置前先备份，改匹配规则前先 dry-run。 时间戳备份不是仪式，是每一次「机制改坏了能一键回滚」的本钱。
18. 好消息的门槛比坏消息高。 传播出去的漂亮数字，撤回成本是产生成本的十倍。

十、边界、未竟与自我批评

按这套系统自己的要求，任何交付都要附「边界」一节。这篇也不例外：

Token 计量缺失。 150 亿是我的运营者估算，系统自身无法归集跨供应商的消耗。一个连自己成本都计量不了的自动化系统，谈不上闭环治理——这是清单上的第一名。好消息是，结构上怎么拆（重放/返工/生产）已经清楚了，缺的是一个自动归集器，而不是认知。

独立验收的补偿机制。 「执行者不能自我验收」这条铁律，在原始审查者退出后由「同一系统内的全新子会话」接替。我用了三项补偿控制：fresh-context 隔离、证据可复现、Owner 最终否决权。逻辑上站得住，但要诚实地说：独立性的纯度确实从「两个不同系统」降到了「同一系统的两个实例」。短期靠否决权兜底，长期需要引入真正外部的审查者——这是当前架构里我最在意的一个未闭合项。

自动化还是「事件驱动」，不是「时间驱动」。 全部自动化挂在三个生命周期事件上，没有独立的 cron 体系（公司心跳除外）。这意味着「没人发消息的下午」仍然是系统的死区——那个「3.6 小时零拾取」的问题只解决了「拾取时的校验」，没有完全解决「什么时候有人来拾取」。

上下文窗口的物理学没有解决，只被工程化了。 长会话会被压缩、总结，隐性知识在会话之间天然不可传递——这不是实现缺陷，是当前架构的物理约束。ContextBundle 和状态投影缓解了它，但每一次交接仍有信息折损，只是从「不可控的折损」变成了「可审计的折损」。凡声称彻底解决了「Agent 失忆」的方案，都值得先问一句：折损去哪了？

它只运行了 36 天。 所有「经受住检验」的说法，样本量都是一个月。机制对抗的是已发生的事故类型，没发生的故障模式一个都没防住——这不是谦虚，是任何 harness 的本性：它永远是上一个事故的纪念碑，下一个事故的盲区。

对人的要求没有降低，反而提高了。 这一个月我个人的消息处理量、裁决量、授权签发量远超从前。自动化省下的是执行时间，花掉的是决策带宽。如果有人想复制这条路，先回答一个问题：你准备好成为一家 AI 公司唯一一个不能被自动化替代的瓶颈吗？

结语：Harness 的本质

回看这 36 天，最反直觉的发现是：让 AI 组织可靠运行的，几乎全是「AI 之外」的东西。

模型能力决定了单个 Agent 能把一件事做多好；而 harness 决定了八个 Agent 加在一起，是 1+1>8，还是互相污染后一起沉没。授权链、冻结窗、四元证据、fresh-context 审查、诱饵测试、复盘四问——没有一样东西需要懂模型内部原理，全都是组织工程，全都是人类世界用了几百年的老智慧（分权、留痕、审计、复核、归档）在文件系统上的重新实现。

150 亿 Token 买到的最贵的一课，其实是三个否定句：

意图不等于授权。Receipt 不等于 Review。Review 不等于 Release。

把这三句话贴在任何一套多智能体系统的门口，它都值回票价。

如果你是正在观望的人：别从「招更多 Agent」开始，从「第一个回执格式」开始——你写的第一份回执模板，就是未来整个组织的宪法序言。如果你是已经在跑的人：去查一查你的自动化里有多少个「静默的成功」，那是最被低估的风险敞口。如果你是怀疑的人：你的怀疑是对的，第十章里每一个字都是我替你写的。

写作口径说明：文中全部数字与引文均取自 2026-09-16 当日在盘文件实测（工作区文件计数、目录行数、运行留痕行数等），机制描述以 00_HARNESS/ 现行版本文档为准；「150 亿 Token」为运营者累计口径估算，非系统精确计量。涉及内部业务的名称已做匿名化处理。

关于作者： 我是一名制冷行业从业者，日常工作是供应链管理和商业决策。2026 年 8 月起，我把业余时间全部投进了一个实验：用八个 AI Agent 组成一家虚拟公司，看「AI 组织化」这条路到底能走多远。这个实验仍在进行中，本文是截至第 36 天的阶段性复盘。所有机制都是在真实事故中长出来的，不是预先设计的。

下一步： 这套 Harness 体系还在演进。后续计划分享的内容包括：多 Agent 状态可观测性的实战方案、诱饵测试体系的设计细节、以及「当 AI 开始审计我的口头授权」这个方向上的更多发现。如果你对这个方向感兴趣，欢迎关注。