AutoSwarm实测：Codex与Claude协作审查及验收边界

作者：@天选嘉鲤敦赵图图

原视频封面；本文整理作者实测，不代表本文独立复现或性能保证。

原视频封面；本文整理作者实测，不代表本文独立复现或性能保证。

AutoSwarm 能把协作流程接起来，但验收标准仍要自己定

这期视频以一个离线字幕微调器为例，讲解如何安排 Codex 与 Claude 分工，以及如何检查多智能体协作的实际结果。作者使用 AutoSwarm 2.0 开发版，把写代码、只读审查和修改串成流程。它在这个案例中的作用是派发任务、返回结果和续接会话，不是自动保证代码质量。

1. 先把任务和验收条件写清楚

目标是做一个纯网页版离线字幕微调器：显示三条中文字幕、允许改字、按毫秒整体前移或后移；前移越过零点时需要处理边界，两条字幕时间重叠时要提示错误并禁止导出。作者在开发前准备了16项隐藏自动化测试，包括超过24小时的时间、负数平移和整个输入文件为空等情形。

2. 两组都用 AutoSwarm，区别在审查者

A组：Codex 写页面，在同一会话里只读自审，再进行一次修改。
B组：全新的 Codex 写页面，Claude 进行只读审查，再把报告交回原 Codex 修改。

两组都通过了预先准备的16项测试。视频中还检查了 -2000 ms 平移、零点边界、字幕重叠提示和导出按钮状态。

3. 单条字幕清空，暴露了测试未覆盖的差异

作者随后把第一条字幕正文删空。A组提示“字幕内容不能为空”，并禁止导出；B组仍允许导出。更进一步，B组自己的读取函数又拒绝接收这份含空正文的输出。

按照视频展示的工作记录，A组在自审时发现并修复了这类边界情况；B组的审查没有指出它，后续修改阶段也没有改代码。这里的关键是：“整个文件为空”和“文件中某一条字幕正文为空”是两个不同场景。后者不在原先16项测试里，所以不能把两组原有的通过记录改写成失败，也不能仅凭这次结果断言某个模型总是更强。

4. 会话管理省交接，不等于自动验收

按视频介绍，AutoSwarm 可以沿用原生命令行工具的账号与配置，让各工具保留各自会话，再由主任务发起新工作或续接已有会话，并留下调用记录。这样能减少手工切换窗口和复制上下文，但审查要求、是否返工以及验收覆盖哪些边界，仍需要在任务设计中明确。

5. 这次实测还有哪些限制

A组三阶段工作时间约5分15秒，总耗时7分钟出头；B组工作时间超过8分钟，总耗时接近10分钟。但两组是先后运行，电脑后台还有其他训练任务，视频没有测试并行加速，因此这些数字只用于理解本次协作开销。

两组 token 统计口径不同，也没有绑定真实账单，不能据此比较费用。另外，作者确认了页面行为与底层生成、读取测试，但浏览器自动化下载工具没有返回完成状态和文件路径，最终落盘文件未做回读确认，下载闭环仍有未验证环节。

适合怎样的任务

如果只是很短的小脚本，单个会话可能已经够用；当任务需要多角色分工、连续交接和汇总结果时，AutoSwarm 的调度价值更容易体现。可以借鉴本例的方法：先固定验收条件，再记录各阶段工作，最后补做真实界面的边界操作。协作、审查和验收需要分别检查。

项目地址：HKUDS/AutoSwarm

本文根据原视频官方可见字幕及画面整理，具体演示和上下文请观看原视频。