Agent 虚拟组织实录

PR #54 第一版 CI 是绿的，Reviewer 还是打回了 3 个具体问题。

我把问题交回技术会话，第二个 commit 修完，CI 再跑一遍，最后才合入。整个过程都能从公开的 digital-employee #42、PR #54 和 commit 1d94ea4 回看。

这篇只复盘已经验收的 Phase A read-only harness。Phase B/C 还在后续范围。

1. 我怎么摆这支小队

我在 fullstack-ai-infra 工作区长期留了三个角色会话：运营、产品、技术。

基于真实工作区截图的脱敏处理：仅保留公开工作区名和三个角色标签；画面不含 session id、账号或路径。

P9、P8、P7-like 是我给 Agent 用的责任标签：P9 管长期结果，P8 管一个方向，P7-like 做具体任务；人类 Owner 负责优先级、风险和最终放行。

1
2
3

目标：P9 → P8 → task Agent
实跑：产品 P9 ↔ 技术 P9 → Gate Reviewer
                    └── 技术 P9 当时还兼任 P8 和实现

我说“自己的虚拟组织 CEO”，意思也很简单：问题选错、范围失控、权限放大、结果没拿到，都算我的。它不是职级，也不代表我已经搭出一支 Agent 军团。

我现在只留一条组织规则：一个结果一个 Owner。 跨 P9 任务再指定一个 Lead；范围或权限冲突，回到人类 Owner。

8 月 5 日，我遇到过一次很典型的断点：产品会话已经把 Issue 写进 GitHub，却在 readback 前失败。

我没让技术会话重试 POST，只让它回读外部状态。6 分 36 秒后，Issue 正文与冻结正文逐字节一致；接手会话的 GitHub 写入是 0，也没有多建一个 Issue。

后来我把交接压成三行：

1
2
3

TASK     goal / revision / scope / done / dont / source
HANDOFF  verified / not_verified / next_authorized_action
GATE     READY | HOLD

session id 找回会话，revision 和 commit 保存事实，Handoff 告诉下一个角色还能做什么。同角色可以 resume；跨角色先回读 contract 和 commit。真实 session ref 只留本机，公开交接只用 Issue、PR、commit 和 CI。

8 月 10 日，我用 PR #54 的公开事实包重跑了一遍。Product P9 先抛出一条故意放大的主张——Phase A/B/C 都已完成；Tech P9 把 Phase B/C 标成 NOT_VERIFIED，Reviewer 给 HOLD；主张收窄后再过 Gate。

Codex 多 Agent 证据门禁实跑

8 月 10 日公开事实包重跑：Handoff → HOLD → 修订 → PASS。图为真实 CLI 输出的脱敏重排版；8 月 6 日历史过程以公开 PR/CI 为准。

这和 OpenCode Agent 在“角色可配置、任务可委派、child session 可恢复”这一层很像。task_id 的实现也说明了它负责恢复哪一个 child session，不负责携带 revision、证据或发布授权。

我自己的分层是：OpenCode Agent 管 Host 内角色与委派；Employee Package 管跨 Host 分发的岗位包；Virtual Organization 管多个岗位之间的责任、交接和 Gate。第三层还是组织协议，当前 Runtime 没有交付完整编排。

公开 PR 记录：2 个 commit、5 项 checks，最终已合入。

首版问题	第二个 commit
loopback 请求不能被 redirect 带到外部	禁止跟随 redirect，补 307 回归测试
非法 grant 必须返回准确错误	修正错误映射，补 array-shaped grant 测试
component matrix 是唯一版本权威	移除 endpoint 与 port 硬编码