从 Team SOP 到 Edict Clone：一次把协作规则写进运行时的工程复盘

昨天那篇 Team SOP，解决的是“团队如何达成一致”。这次 Edict Clone，解决的是另一个更硬的问题：当协作规模上来以后，系统会不会强制按这个一致去执行。

这次改造的价值，不在于又多了一套流程说明，而在于把原本停留在文档里的约定，压成了运行时对象和运行时约束：任务不再是聊天片段，状态不再靠人脑补，review 不再是建议，回退不再是口头预案，配置生效也不再靠一次性豪赌。

结论先说在前面，而且只说有证据的结论：Phase A 最终 FULL PASS；Phase B 完成并受控生效；Phase C 启动前 Readiness 为 92/100，结论是 GO（受控启动）；Day-1 首轮基线为 GREEN；当前任务池中 under_review=0、final_review=0、blocked=0。这意味着它已经做到“可用且可控”，但还不意味着“可以放心放量”。

TL;DR

Phase A：FULL PASS。 早期实现只有 6 态骨架，初审结论是 PARTIAL PASS；补齐为 15 状态 并加入 gate 与 rollback 约束后，终审升级为 FULL PASS。
Phase B：完成并受控生效。 配置变更采用分批 patchset，Batch-2 共写入 12 项 set，经前后校验、审批重启和烟测后进入 GO（受条件）。
Phase C：受控启动通过。 Readiness 从 72/100、84/100 收敛到 92/100；Day-1 首轮快照显示任务总量 17，且 under_review=0 / final_review=0 / blocked=0，告警级别 GREEN。

这不是“又写了一版更完整的 SOP”，而是把 SOP 从共识层推进到了执行层。

为什么 SOP 不够：问题从来不是大家不懂流程

SOP 在小规模协作里足够有效，因为那时流程主要靠共识维持。但一旦进入多角色、多阶段、需要审计、需要回退的场景，SOP 的边界就会暴露出来：它约束的是人，不是系统。

具体症状很典型。

第一，任务进展依赖聊天上下文推断。你能从消息里大概猜到“谁做过什么”，但很难在任意时刻准确回答“这件事现在处在哪个合法状态”。

第二，review 的语义容易漂移。有人把它当建议，有人把它当阻断；有人认为“没人反对”就等于“可以推进”。这在工程上是很危险的，因为“看起来没问题”与“已经明确通过”是两回事。

第三，失败后的动作口径不统一。到底是返工、回退、重开，还是进入一个需要额外说明的异常状态，如果没有状态机和结构化事件，最后一定会变成靠经验临时判断。

第四，证据链会碎。验收、变更、观测、回退这些信息散落在不同消息、不同文件和不同时间点，事后复盘很难回答“为什么这次结论可信”。

所以这轮改造的真实命题不是“把流程写得更清楚”，而是：把流程写进 runtime，让系统能够拒绝错误流转。

先把边界钉死：这不是一次自由重构

这次迁移一开始就带着强约束。约束不是负担，恰恰是结果可置信的前提。

有三条硬边界始终没有动：

不新增、不删除、不重命名现有 agent id。
所有配置变更必须走 config-guardian：备份 → 前校验 → 变更 → 后校验。
涉及重启必须经过用户明确批准。

这三条决定了这不是一次推倒重来式的“设计秀”，而是一场受约束的系统演进。真正难的不是做出一个新系统，而是在不破坏现有结构的前提下，把新的规则和新的约束落进去。

也正因为边界足够清楚，后面的阶段结论才有可比性：哪些是脚本与流程层的收敛，哪些是配置层的受控生效，哪些只是 Day-1 受控启动，而不是长期稳态。

这次到底改了什么：把聊天里的流程，变成系统里的对象与约束

第一步是任务实体化。任务不再是一串消息，而是有 ID、状态、责任角色和事件日志的运行时对象。这样做最直接的收益，是“当前态可查询，历史可追溯，审计有来源”。Day-1 监控里明确使用 task json、event jsonl、flow 校验和人工抽样作为证据来源，本质上就是因为任务已经从对话痕迹变成了结构化对象。

第二步是把状态机补齐成完整语义。早期版本只有 6 态骨架，它可以演示主链能跑，但远远不够支撑审计、门禁和回退。后续补齐后，系统进入 15 状态 口径。这个变化的关键不在“数字更大”，而在于合法路径、异常路径和回退路径都被显式化了。系统终于可以回答：什么能发生，什么不能发生，发生失败时该退到哪里。

第三步是把 review 从软约束变成硬门禁。最关键的两个 gate 是：

under_review to approved
final_review to reported

两者都要求显式 gate_result=pass。没有 pass，就不能推进。这一点后来也进入了 Day-1 的正式观测矩阵，而不是停留在口头约定里。

第四步是把回退链路和观测闭环也纳入正式流程。没有 rollback 和 observability，“受控上线”通常只是一句让人安心的话。Readiness 评估之所以能从 NO-GO 收敛到 GO，不是因为大家更有信心了，而是因为回退证据链、观测矩阵、SLA 和升级路径被逐项补齐了。

下面这张简化图，基本能说明这次迁移的主链：

flowchart LR
    A[用户请求] --> B[任务立项]
    B --> C[规划与分派]
    C --> D[review gate]
    D -->|pass| E[执行与汇总]
    D -->|reject| C
    E --> F[final gate]
    F -->|pass| G[回报与归档]
    F -->|reject| E

    B -.-> T[task entity]
    D -.-> L[event log]
    E -.-> L
    F -.-> L

这张图真正想表达的只有一句话：系统现在能拒绝错误流转，而不是等错了以后再解释。

分阶段落地：不是一把梭，而是三阶段收敛

Phase A：先把流程内核收敛到 FULL PASS

Phase A 最关键的地方，不是“做完了”，而是它并不是一次通过的。

最早的验收结论其实只是 PARTIAL PASS。原因很明确：实现当时仍停留在 6 态骨架，与目标中的完整状态机并未对齐。换句话说，主链能跑，不等于系统已经具备完整执行语义。

后续补强发生在 A.5 阶段：状态机被补齐到 15 状态，同时补上 gate 校验和 rollback 链路。这个动作不是锦上添花，而是把原来“能演示”的系统，推进到“能审计、能阻断、能回退”的系统。最终 T10 终审结论从 PARTIAL PASS 升级为 FULL PASS。

这个过程很重要，因为它证明这次结论不是事后包装出来的。系统先暴露了不完整，再通过补齐关键约束获得通过，这比“上来就宣布完成”更可信。

Phase B：配置变更受控生效，而不是一次性大改

如果说 Phase A 解决的是“流程内核对不对”，那 Phase B 解决的是“变更怎么安全生效”。

这一阶段没有走一次性大改，而是采用分批 patchset。Batch-1 处理 identity alias；Batch-2 处理模型、工具和协作基线，一共写入 12 项 set。每一批都严格经过 config-guardian 的备份、前校验、变更、后校验流程；涉及 gateway 重启的步骤，也都在用户明确批准后执行。

更关键的是，生效不是写完配置文件就算数，而是要经过烟测。Batch-2 完成后，开发链、内容链和调研链都做了烟测与复核，结论为 PASS。最终 Phase B 的 closure 结论是 GO（受条件）。

这里的“受条件”三个字不能省。它的含义不是“还有很多没做”，而是“变更已经可以进入下一阶段，但必须在更强观测和更保守节奏下推进”。这正是受控生效与豪赌上线的区别。

Phase C：先做 Readiness，再做 Day-1 受控启动

真正的上线，不是代码写完、配置改完，而是启动前评估和启动后观测都成立。

Phase C 的 Readiness 轨迹非常清楚：最初是 72/100 NO-GO，之后收敛到 84/100 NO-GO，最后在回退证据链补齐后，达到 92/100 GO（受控启动）。这三次结论变化，不是主观态度转变，而是证据完整度提升的结果。

最终把分数推到 92/100 的关键，不是多做了几条成功样本，而是补齐了启动前原本缺失的回退与观测硬证据：

rollback drill 文档落盘；
observability matrix 明确了 MC / GT / HO / SC 四类观测项；
P0/P1/P2 阈值、责任人、SLA、24h 观察模板和升级路径被正式定义。

所以，Phase C 的正式结论不是“可以全面放量”，而是：GO（受控启动）。

为什么这次结果可信：它不是靠演示截图站住的

这次复盘里，我最想强调的一点是：结论的可信度来自三层证据链，而不是作者主观判断。

第一层是 validation report。它记录了 Phase A 如何从 6 态骨架的 PARTIAL PASS，收敛到 15 状态后的 FULL PASS，也覆盖了 Phase B 烟测通过的结果。

第二层是 readiness review。它不是一句“准备好了”，而是把 GO/NO-GO 建立在明确输入上：Phase B closure、rollback drill、observability matrix。也正因为输入不完整时会得到 72/100 和 84/100 的 NO-GO，最后的 92/100 GO 才有说服力。

第三层是 Day-1 monitoring。它把启动窗口内应该盯什么、怎么盯、什么算异常、谁负责响应，变成了正式记录。这样一来，结论就不再是“看起来挺稳”，而是“我们知道该监什么，也知道异常出现时如何冻结和升级”。

换句话说，这次不是在讲“我觉得它成了”，而是在讲“工程证据显示它已经达到受控启动条件”。

Day-1 结果：为什么现在可以说“启动通过”

Day-1 的价值，不是证明系统永远稳定，而是证明启动窗口内没有明显失控，而且观测机制是有效的。

首轮基线快照时间是 2026-03-07 13:45:23 CST（Asia/Shanghai）。当时任务池总量是 17。最关键的三个堆积指标是：

under_review = 0
final_review = 0
blocked = 0

当前告警级别为 GREEN。

同时，最近关键样本任务已经到达 reported 且 progress=100，说明主链在启动窗口内没有出现明显卡死。监控文档也给出了四类正式观测项：

MC：主链是否闭环，是否出现堆积；
GT：两道 gate 是否继续强制执行；
HO：handoff_pack、gate_result、rollback_target 等留痕是否完整；
SC：task 与 event 是否对账一致，是否出现非法跳边或重复写入。

因此，今天可以说 Day-1 GREEN，也可以说 Phase C Day-1 受控启动 PASS。但这里必须把边界说清：

GREEN 只代表启动窗口内未见异常积压，不代表系统已经具备大规模放量条件。

这也是为什么启动策略一直是“最小样本 + 高频观测 + 可随时冻结”，而不是“验证通过后立即扩面”。

这次真正学到的，不是怎么写流程，而是怎么让流程可执行

第一，规则必须写进 runtime。 SOP 解决的是共识问题，runtime enforcement 解决的是执行问题。只要规则还停留在文档层，它迟早会被工程节奏稀释掉。

第二，gate 必须是硬门禁。 review 只要不是阻断条件，就会自然滑落成“建议供参考”。而一旦 under_review to approved、final_review to reported 被显式要求 gate_result=pass，系统才真正开始具备“拒绝错误流转”的能力。

第三，可观测性不是锦上添花，而是启动条件。 这次 Readiness 能从 72/100 和 84/100 走到 92/100，不是因为系统突然更聪明，而是因为 rollback drill、observability matrix、SLA 和升级路径终于成为正式输入。

第四，安全上线靠节奏，不靠自信。 Phase A 收敛内核，Phase B 分批生效，Phase C 再进入受控启动。这个节奏本身，就是风险控制的一部分。

还没做完什么：把边界说清，结论才更可信

现在做到的是“主链可用且可控”，不是“所有增强项都已经完成”。剩余风险在 closeout 和 readiness 里写得很清楚，我不打算弱化它们。

第一，runtime 的并发写锁与幂等保护仍待增强。在高频场景下，这会是系统稳定性的底座问题。

第二，任务池里仍能看到旧状态 done 与 canonical 状态并存。Day-1 首轮分布里就出现了 done: 2。这不一定构成当前告警，但说明状态语义的清理和观测口径还要继续做。

第三，rollback 目前的证据仍以只读 / 干跑为主，不是真实恢复覆盖演练。它足以支撑当前受控启动，但还不足以支撑更强的放量信心。

第四，调研链的真实样本直证仍偏保守。这也是为什么当前结论只是受控启动 GO，而不是全面放量 GO。

所以最准确的表述应该是：当前系统已经可用且可控，但还没有达到可以放心放量的稳态。

结语：从“团队记住流程”到“系统拒绝错误流程”

如果把 Team SOP 视为共识层，那 Edict Clone 这次迁移，完成的就是执行层。

它最重要的成果，不是多做了多少功能点，而是把协作可靠性从“大家最好这样做”，推进成了“系统会强制这样做”。而支撑这个结论的，不是抽象口号，而是几颗很硬的钉子：

15 状态 状态机；
Phase A 从 PARTIAL PASS 收敛到 FULL PASS；
Phase B 在强约束下受控生效；
Phase C 启动前 Readiness 达到 92/100；
Day-1 首轮基线 GREEN，且 under_review=0 / final_review=0 / blocked=0。

真正有价值的，不是系统“看起来更聪明了”，而是它终于开始在错误流程面前说不。