读 Block 的这篇访谈，我总在想 PR 发出之后的事。
Block 的 AI 能力负责人 Bradley Axen 说，公司会让 Fable 编排跨仓库的大规模代码迁移，涉及数百乃至数千个 PR。工程师引导方向，Fable 处理数据模型、API 规范和算法，Opus、Sonnet 等相对较小的模型负责改文件、跑测试。
我读到这里最想知道，面对成批的变更，团队怎么判断它们是否值得合并，怎么发现一项看似正确的修改破坏了另一处约定。这篇访谈让我愿意更认真地看待大规模 Agent 编排，也让我对它的验收环节有了更多要求。
迁移计划里，要写进怎样才算完成
Section titled “迁移计划里，要写进怎样才算完成”原文介绍的分工有清楚的层次：人掌握方向，强模型处理复杂设计，执行模型落实具体修改。Block 把协作放在 Buzz 的共享频道和线程里，让人能看见工作进展。
进展可见之后，仍得有人判断结果是否可接受。
假设要把旧接口迁到新接口，执行任务不能只写“替换调用并通过测试”。还应说明旧行为中哪些必须保留，兼容逻辑何时能删，碰到无法映射的调用该停下来问谁。否则，执行模型可能各自做出了局部合理的决定，合起来却是一套互不相容的迁移。
这是我从案例里延伸出的要求，访谈没有披露 Block 的具体任务协议。对准备尝试类似流程的团队，我会建议把验收条件与任务一同下发：交回修改时，也交回对应测试、尚未确认的假设和需要人决定的例外。审查者才能沿着证据检查，而不用重新猜一遍修改者的意图。
原文链接的 Anthropic 团队实践文章有个细节很贴近这个问题：当 Agent 更独立之后，团队开始教它们批量提交问题、补齐上下文，并限制人同时接收的信息。这说明沟通本身也需要设计。把每个小决定立即抛给人，会让自动化留下很长的消息列表。
那篇背景文章的职责原图，把维护代码库的角色与工作节奏分开列出：有人维护优先级，有人检查方案，有人写代码。它展示的是 Anthropic 的实践示例，并非 Block 的团队配置。我喜欢它把“检查方案”和“写代码”分开这件事，因为前者很容易在追求产出时被忽略。
省下的 token，要和返工放在同一张账单上
Section titled “省下的 token，要和返工放在同一张账单上”Axen 说，他们的早期结果显示，复杂规划使用前沿模型，更多执行 token 转向较小模型，质量没有下降。访谈没有给出可复算的成本账单、质量基线或返工数据，我无法据此判断自己的项目能省多少。
我能从中带走的是一种测试方法。模型的名字不够，effort 也要一起测。Axen 描述，他们会针对用例检查不同模型与不同 effort 的组合。昂贵模型少走弯路，可能比便宜模型反复修正更合算；一个边界清楚的文件修改，也可能根本用不上复杂规划。
这与站内那篇按任务结果核算 Claude Code 成本的讨论接得上：费用应跟着完成的工作来算。放到多 Agent 迁移里，我还会把协调和审查纳入账目。规划调用花了多少，执行重试了多少，人为了弄懂这些变更又读了多久，都可能改变最后的判断。
PR 数量在这里很容易造成错觉。拆得细有利于检查，也可能增加重复说明、排队和跨 PR 依赖。我会同时看迁移目标推进了多少、审查花了多久，以及变更合并后有没有回退。任务拆分是否合适，要由这些结果来回答。
人工审批需要一条可执行的权限边界
Section titled “人工审批需要一条可执行的权限边界”访谈里，我最愿意照着检查自己流程的部分，是 Block 对权限的处理。
按 Axen 的描述，合并主干和部署生产环境留给人；Agent 的修改要通过安全检查，部署还需要两个人批准。这里的双人批准指部署，不能直接理解为每个 PR 都必须有两人审查。
他们还把便宜、明确的检查尽量放在模型循环之外，有些甚至只是正则。能由程序明确判断的条件，我也倾向于交给程序检查，省得反复让模型解释自己为什么符合。
原文也说，在他们的测试中，Claude 拒绝尝试绕过双人审批。我会把这视为模型行为测试的结果，同时继续检查工具权限。模型愿意遵守规则，和生产凭据、审批接口确实不允许它单独放行，是两项需要分别验证的事。
原文引用的模型安全发布说明，也把分类器描述为检测潜在滥用的独立 AI 系统。它在模型服务侧检测滥用，Block 自己的部署审批则决定变更能否上线。读案例时如果把这些都合成“模型很安全”，反而不容易看清每一层该检查什么。
审批的内容同样重要。如果审查者只收到一段自信的总结，很难判断迁移有没有遗漏。我希望看到的是目标、实际变更、验证结果和仍需判断的地方；遇到解释不清的例外，就暂停对应任务。这样的材料，才值得人花时间批准。
让试点留下团队下次能用的东西
Section titled “让试点留下团队下次能用的东西”另一个让我停下来想的细节，是技术债。
Axen 坦言，功能和变更发得更多，技术债也积累得更快。他说他们会让 Agent 每日或每周检查代码库，寻找需要清理、合并的地方。我不认为这意味着维护问题已经解决，但它提醒我，试点应该把后续维护也算进去。否则，眼前的迁移完成了，接手的人仍可能要面对重复抽象和逐渐失效的约定。
访谈最后谈到组织知识：个人电脑上的 skills 很有用，成熟的组织还要把这些上下文记进系统，让其他人也能受益。对我来说，这比照搬模型组合更容易着手。
可以先选一项范围清楚、允许回退的迁移，写下现有行为、验收办法和需要升级给人的例外。让 Agent 提交一批可检查的改动，记录实际费用、返工和审查时间。遇到解释不清的失败，先修任务说明或验证方式，再决定是否增加并发。
试点结束时，我希望留下的还有一份别人接得住的记录：哪些情况能自动处理，哪些必须停下来，判断依据在哪里。这些记录能进入共享文档、测试或可复用的技能，下一次迁移才不用从某个人的聊天记录里重新找答案。
我读完 Block 的案例，更愿意把编排看成一项团队工程。模型可以承担更多工作；团队则需要认真决定，什么结果能够被接纳，以及由谁、凭什么来接纳。