https://x.com/0xjmori/status/2109648700897116554 看看这篇文章

回复 群友 7739： 这篇文章的作者 Mori 写了 Grok Bot + Opus 5.5 搭一套“7×24 AI 工程团队”的 12 步方案，但他自己反复强调一句话：别指望指定模型，关键是围绕模型搭系统。 整体结构是一个 Chief 带四个专家：Triage 复现 bug 出失败测试，Builder 调 Cursor cloud agents 在独立分支修，Reviewer 独立看 diff 和证据，Release 准备交付物。所有状态写进共享的 /workspace 文件账本，每条 issue 走状态机 NEW→TRIAGED→REPRODUCED→BUILDING→TESTED→REVIEWING→DRAFT_PR_READY→人工审批，每次状态推进都要有对应证据文件。 我觉得有几个点值得注意： 一是他把“模型路由不可控”当成设计前提而不是缺陷。10月7日那个公告只是让 Opus 5.5 成为可选后端之一，平台不给你 per-request 选模型。所以他的结论是让 agent 能继承任务、读项目状态、朝同一套验收标准继续，换模型也不散架。这个思路是对的——可迁移的是任务契约和校验，不是某个模型的脾气。 二是权限不写在 prompt 里。他说“说一句别 merge”是软约束，protected branch 才是硬约束。他还点了个很多教程会忽略的坑：同一个账号下所有 Bot 共享同一台云电脑和凭证，改名不隔离权限。这跟你上次让我看的那篇 Anthropic 的授权问题是同一层，只是这里是实操版本。 三是并行要挑独立任务。三个 agent 改同一个函数，那不是产能，是把协调问题包装成了产能。 四是失败恢复写得很具体：同样的失败出现两次就停、测试挂了改实现不改结果、复现不出来就交复现报告而不是硬编一个修。 我的看法：这套东西的真实价值不在“12 步”这个包装，而在它把多 agent 协作的约束落到了文件、状态和分支上，而不是靠对话里互相喊话。缺点是作者自己承认的——routine 不是无限常驻进程，用量上限、机器恢复都会打断，靠持久状态续跑；而技能一旦固化成 skill，procedure 是对的但判断力不会自动长，第二次跑同一个坑还是同一个坑。想真正用起来，第一步应该像他说的，拿一个无害 issue 手测，别一上来就开无人值守。