Dong-skills — 智能体协作工作流
- Codex
- Claude Code
- OpenCode
- Grok CLI
- Agent Workflows
- Code Review
- Verification
一个公开的个人 skills 仓库，把反复使用中的多智能体 coding 实践写成明确的操作规则。四条已命名工作流覆盖实际在用的配对 — Claude-Codex 互评、Codex-OpenCode、Codex-Grok 与 Codex-Antigravity — 每条都固定同样几个问题：什么可以委派、什么保持私有、谁负责 git，以及第二 agent 的意见在成为被采纳的改动前必须通过哪些检查。三条之中有两条跑在 Codex CLI 里，编排的是我自己那组六插件矩阵中的插件；第三条跑在 Claude Code 里，编排的是一个第三方插件。
项目概览
角色 独立作者 — 工作流设计、安全边界、审查协议、文档，以及实测失败记录
场景
多智能体 coding work 如果范围、隐私、审查权限和验证责任不明确，很容易失控。第二个 agent 只有在职责范围受控，且其结论被真实 repo 验证时才有价值。而真正耗时间的失败很少是推理出错，多数是运行时出错：一个让第二 agent 启动即死且没有有效报错的配置值、一个只回 id 的长任务、一个被 wrapper 静默丢掉的参数。
产品策略
我把反复使用中的协作实践整理成 skills：限制第二个 agent 能看什么、做什么，设置审查关卡，并在交付前逐条对照 repo 验证 — 对方是被委派方时用任务包，对方是同侪时则用一份被评审过的 spec 与 plan。每个运行时失败都连同症状、真正成因和确切恢复步骤一起记下，让下一次会话认得它，而不是重新踩一遍。
成果与当前阶段
公开 skills 仓库 · 四条已命名工作流，两种形态 — 一条同侪互评、三条受控委派 · 实测失败记录跨 2026-07 与 2026-08 累积 · 三条委派 skill 以已安装插件的当前 contract 为准，不钉版本号
我的工作
- Claude-Codex 互评，分两个阶段：设计先在 fresh thread 里被评审到 GO，才允许开始写代码；之后 Codex 按任务实施，Claude 跑 Codex 沙箱跑不了的测试，并且只在测试绿加一轮评审之后才提交。测试绿本身不算完成；而且每次复查都开新 thread，因为被续用的评审 thread 会漂移，并且会凭空造出不存在的 bug。
- Codex-OpenCode 受控委派：可用性不确定时先做能力检查，每次调用只承担工具表上的一个角色，完成与否只认该次运行自己的完成标志，之后在 Codex 侧重读每个被引用的文件、重跑每条相关命令。
- Codex-Grok 受控委派，四个角色 — 受控实施、独立评审、对抗式评审、救援诊断 — 另加一份 acceptance ledger，把每条 Grok 结论标记为采纳、拒绝或收窄。
- Claude-Codex 那条 skill 里跨 2026-07 与 2026-08 累积的实测失败记录 — 九条 operational gotchas，另有六条红线与五条反模式：让第二 agent 启动即死且没有有效报错的配置值；只回一个裸 job id 的长任务 — 应该去轮询，而不是当成失败；wrapper 不保证转发、必须从 session 记录读回确认的 model 与 effort 参数；以及升级 CLI 却碰不到已在运行的共享 runtime。
- 把验收关卡写成错误实现无法通过的样子 — 起因是连续三轮评审打的都是关卡本身而不是代码：要求的文案必须绑定到真正渲染它的那个字段与语言，因为「关键词在文件里出现过」不构成关卡。
技术证据
- 三条受控委派工作流共用的硬边界：不执行破坏性命令、被委派方不 commit / push、不读私有 runtime paths、一棵工作树只能有一个写者，未经验证的结论一律不当作 finding 采纳。
- 为三条受控委派工作流准备的可复用任务包结构：目标、二元验收、限制在一到五个文件或一个窄目录的 scope（Grok 那条再放宽到一个明确 diff）、读写权限、禁止动作、验证命令、要求的返回格式和风险。同侪工作流不用这个结构 — 那边的单位是 spec 与 plan，不是任务包。
- 同样是那三条工作流的要求 — 每次委派都留一份 handoff record：角色、job 或 session id、确切范围、终态、该次运行是否真的报告完成、第二 agent 的结论、已做的验证、被拒绝的结论、实际跑过的命令，以及剩余风险。
- 在那三条工作流里，决定工具行为的是已安装的插件而不是 skill 本身：skill 绝不从自己的正文重建缺失的工具或参数，也不钉死 contract 版本 — 正因如此，同族插件可以持续发版，而一条自 2026-07 起就没再改过的工作流依然有效。
为什么做这个仓库
这个仓库把反复使用中的本地实践整理成操作规则，让 Claude Code、Codex、OpenCode 与 Grok 之间的协作有清楚范围、可供检查，也能用实际结果验证。这些 skills 定义了什么能委派、什么保持私有、谁负责 git，以及第二 agent 的意见在被采纳前必须通过哪些检查。
写下来的规则能活得比产生它的那次会话久。仓库在 2026-07 与 2026-08 期间增加的内容，很多不是新理论，而是被记录下来的失败 — 症状、真正的成因、确切的恢复步骤 — 因为这些细节，一个全新的会话没有办法用低成本重新发现。
第二 agents 的审查角色
Codex-OpenCode 工作流把 OpenCode 定位为第二 reviewer 或受控 helper。流程在可用性不确定时先做能力检查，再发送明确任务包，禁止 commit 和破坏性命令，最后要求 Codex 对照真实文件与测试输出验证每个发现。
Codex-Grok 工作流把同一规则套到 grok-plugin-codex：在可用性或版本兼容性不确定时先做能力检查，只委派一个受控任务或 review，检查完整结果，并让 Codex 继续负责文件、测试、git 与最终判断。每条返回的结论随后被标记为采纳、拒绝或收窄 — 一段不完整的日志或一句肯定的断言只是线索，不是结论。
Claude-Codex 工作流刻意不是这个形态。它是双向的：两侧互相评审，直到两个模型与测试套件都同意；角色被固定住，不允许倒置；而且设计阶段在实施开始前就设了关卡。受控委派拦得住一个坏 diff；只有在 fresh thread 里被评审到 GO 的设计，才拦得住那种根本就不该被实现出来的方案。
工作流跑在什么之上
工作流之所以区分宿主与供应方，是因为插件本身就是这样分的。三条 skill 之中，一条跑在 Claude Code 里；跑在 Codex CLI 里的那两条附带对应的 agent 注册文件。我自己的六个同族插件把三个第二 agent 接进两个宿主 — Claude Code 侧是 opencode-plugin-cc、grok-plugin-cc 与 agy-plugin-cc；Codex CLI 侧是 opencode-plugin-codex、grok-plugin-codex 与 agy-plugin-codex。三条工作流挂到这个矩阵上的方式并不齐整：Codex-Grok 那条直接点名 grok-plugin-codex；Codex-OpenCode 那条是对着 opencode_* 工具面写的，并未点名某个插件；而 Claude-Codex 那条依赖的是一个第三方插件，根本不在我这组里。
覆盖范围比矩阵窄，也比矩阵看上去的更窄。四条已命名工作流覆盖的是 Claude-Codex 这一对，加上矩阵里整个 Codex CLI 侧 — OpenCode、Grok 与 Antigravity。Claude Code 那一侧 — opencode-plugin-cc、grok-plugin-cc 与 agy-plugin-cc — 目前仍然没有自己的已命名工作流。一对配对要等我用到它的失败模式值得记录，才会被写成 skill；这个仓库要当的是「实际坏过什么」的记录，而不是「什么可以接起来」的地图。