auth9、orchestrator、deck：同一个人对同一个问题的三次回答

这篇是《同一套方法论，我用了三次》的补充。那一篇讲方法论在三个项目上的不同结果，这一篇讲产品本身：它们各自是什么，orchestrator 和 deck 在哪些地方做了相反的选择，为什么会有那次修正，以及下一步怎么走。

数据截至 2026 年 9 月 6 日。三个仓库我各让一个 agent 按同一份提纲翻了一遍，每条结论都能追到具体文件，这篇是综合。

---

三代放在一起看

	一代 auth9	二代 orchestrator	三代 deck
时间	2026-01-29 ~ 06-27	2026-02-09 ~ 08-26	2026-08-27 ~
提交	491	1,606	207（10 天）
规模	约 21.5 万行	约 20 万行 Rust + 1 万行 TS	约 3.4 万行
它是什么	IAM 平台 × AI-native SDLC 实验	agent 工作流控制平面	macOS 原生注意力看板
现在	实验结束	已归档	我每天在用
一句话	方法 × 外生规格	方法自我产品化，意图来自品味	意图来自观察，方法压到最小

三者的角色：auth9 验证方法论；orchestrator 扩张方法论，但扩张太早，产品哲学来自我个人的偏好；deck 是方向修正。deck 的文档单向引用 orchestrator，反过来一次都没有。

orchestrator 和 deck：七件事上的相反选择

这两个是同一个人面对同一个问题（怎么和一群编码 agent 共事）给出的两个方向相反、又各自自洽的答案。把它们并排放着看，挺有意思。

1. 谁是操作者。 orchestrator 说 “Humans steer, agents execute”，工作流自己跑几天，出了例外才进 attention 收件箱。deck 说 agent 在跑，人决定看哪里，“No automatic card movement, ever”。
2. 控制还是投影。 orchestrator 是一个声明期望状态、系统自己收敛的控制平面，它拥有执行。deck 只是 tmux 上面的一层投影（“tmux owns the shells; deck is only the board projection”），它崩了不会杀任何 agent，它什么都不拥有。
3. 面怎么长。 orchestrator：126 个可见 CLI 命令、12 种 K8s 式资源 Kind，大面加守门（“概念预算”：新增一个顶层概念必须论证为什么这不是一个字段）。deck：0 个 CLI 子命令、8 个设置项，小面本身就是设计（“Resist adding features tmux already provides”）。
4. 信任怎么建立。 orchestrator 靠度量和门禁：CHANGELOG 每条带实测数字，变异测试杀”碰巧通过”的测试，双向覆盖率棘轮。deck 靠诚实和认知谦逊：“QUIET IS NOT READY”，崩溃窗口宁标 ambiguous 不说成功，错误文案统一成”做了什么 + 回滚到什么”。
5. 平台还是器物。 orchestrator：daemon 加 gRPC 加 SQLite 46 张表，跨平台，面向 operator。deck：只支持 Apple Silicon macOS，单实例，本地 JSON，面向我自己的日常使用，零遥测。
6. 技术债谁买单。 orchestrator 做制度化记账（legacy 错误码、freshness 记录），集中到破坏性版本窗口一起清，升级的人买单；治理体系自己也在积债。deck 用小面预防，加上软件启动时原地消化（数据目录加固、旧日志脱敏、legacy 字段静默清理），从不要求用户重置。对债的姿态，反映的是产品对”自己有没有用户”的真实认知。
7. 怎么和 AI 协作。 orchestrator 走平台化：30 个 skill 加功能请求注册表加门禁护栏，多个主体直接提交，信任交给机器验证。deck 走委托制：零 skill，仓库外面放编号的任务书（带验收标准、授权边界、进度勾选），我保留全部对外写入权，信任靠诚实汇报。各自的开发方式，恰好就是各自产品对待 agent 的方式。

它们共同的 DNA：拒绝假绿灯（变异测试、“never stub the writer and call it proven”）；把”为什么不做”记得比”做了什么”更认真；脱敏和隐私是硬约束；轻依赖、Rust 加 Tauri、MIT；AI-native 开发。贯穿一切的一条原则：不让系统声称它没有证据的事。

那次修正是怎么发生的

1. 制度成本吃掉了产品速度。 orchestrator 归档前最后一个月的提交全是治理体系在给自己收敛，零新功能。门禁体系是按”多人长期平台”设计的，团队两个人，用户约零。制度成本固定，收益跟用户数成正比。
2. orchestrator 自己诊断出了根本矛盾。 7 月的设计文档记着：生产 workflow 大约 70% 是给哑 agent 契约付的协调成本，“The dumber the agent contract, the smarter the YAML must be”。推到头就是：agent 越聪明，外部 harness 存在的理由越薄，而 agent 变聪明是模型厂商在推。
3. Dogfooding 暴露出真正的瓶颈在人。 七个月下来，我实际的痛点不是”agent 缺治理”，而是”我盯不过来”。orchestrator 里的 attention 收件箱是整个平台最有用的部分。deck 就是把它单独拿出来，把其他的都删了。
4. 核心前提不成立。 2026 年的 agent 撑不起”几天的自主循环”，working、needs-input、turn-done 才是现实。愿景和观察冲突的时候，我选观察。
5. 验证能力不对称。 orchestrator 的目标用户是平台团队，我一个人没法在自己身上验证它。deck 的目标用户就是我，假设可以在每天的使用里直接验证。deck 验证的是从产品出发的 AI-native SDLC：先有一个每天在用的东西，需求由使用暴露，方法论按需进来。

怎么评价这次修正：执行是干净的（聚焦式转向、止损、保留学习、验证先行）；成因是七个月没碰到任何能证伪假设的使用；结论还没有，deck 用得还不够久。归档本身也是那条共同原则的一次执行：一个挂着最新提交的仓库，就是在声称”这里有人维护”。

从 auth9 能搬走的东西

auth9 的四个发现在上一篇里写过了，这里只列确认能迁移的部分：

• 变异验证：要求测试证明自己还能失败。
• 类型化纪律：agent 没有记忆，规范必须下沉成编译器性质的东西。
• 双向棘轮：涨太多不更新基线也算失败，不然回归检测能力会静默丢失。
• 概念预算和它的门禁悖论：门禁只能检查它看得见的东西。这句话对方法论自己也成立：它能验证实现是否符合意图，生成不了正确的意图。
• 仓库就是制度记忆：给没有长期记忆的协作者设计的外部记忆体。

下一步

第四代是什么，我不知道。deck 还在用，它会暴露什么问题、哪些问题值得用机制解决，要用得够久才知道。谱系里已经有过一次”先有构想、后找验证”的教训，这次不预设规格了。

现在能确定的只有做法，不是内容：

• 需求从使用中来。deck 的 agent 状态模块是唯一的先例：启发式先上，真实使用暴露它的不足，再引入类型化的状态上报。之后每一件机制都按这个顺序走。
• 逐件进口，不成套进口。orchestrator 里被验证有效的做法（变异验证、类型化纪律、双向棘轮、概念预算）是备选，不是计划。取哪件、什么时候取，由 deck 里冒出来的具体问题决定。
• 不让系统声称它没有证据的事。这条不随代际变。

其余的，从 deck 里学。