Amp 用主智能体统筹多任务编程

Amp 在 2026 年 11 月 6 日推出 Spaces，把多智能体编程里的协调工作交给了一个专门的 agent：你向它描述目标，它负责拆任务、创建线程、安排执行并汇总结果。人从逐个管理线程，转向检查目标有没有完成。

值得关注的不是少开几个标签页，而是这种分工能否支撑持续数天的工作。原文给出了 Amp 团队内部的三个案例，也留下了关键疑问：协调者判断错了怎么办，多出来的模型调用是否划算？

把任务交出去之后，谁来管理线程

使用 coding agent 处理稍大的需求，很容易变成「一个任务一个线程」。哪个任务该单开、哪个已经完成、哪里需要追问，都由人判断。agent 执行代码工作，人维护任务之间的关系。

Spaces 把这层职责交给 space agent。用户只和这个协调者对话，由它拆分工作、派生线程，再报告进展。所谓协调，就是决定谁做哪部分、结果交给谁，以及什么时候需要继续处理。

创建入口也围绕目标设计：点击侧边栏 Spaces 区域的 +，设置标题和项目，再告诉 agent 要做什么。

与需要维护任务图或 YAML 配置的编排方式相比，这个方案把协调要求放进了对话。空间同时保存讨论、执行线程和汇总产物，后来加入的同事可以沿着这些记录了解进度。对于发布、周期性审查这类长期任务，它还提供了一个持续保留目标的地方。

用户少管理一层线程，协调者就必须多承担一层判断。

三个内部案例，分别验证了什么

第一个案例是用 Spaces 开发 Spaces。Tim、Lewis、Nicolay 和其他成员共同使用名为「Spaces v1」的空间，把反馈、缺陷和新想法放进聊天，由 agent 分派到不同线程。成员需要讨论时使用评论，准备好让 Amp 介入时再标记它。

这个案例展示了团队讨论与任务执行如何放在一起，但没有提供交付速度或返工率的对照数据。

第二个案例跨度更大。Lewis 从一个空间推进 service accounts 发布，覆盖功能上线、监控 X、Slack 和缺陷报告、修复问题，以及向受影响用户发送邮件和退款。此后，这个空间继续监控用户问题与系统健康，持续到当周结束。

这里协调的已经不只是代码任务，还包括发布后的运营处理。不过，原文没有说明各项操作的权限、确认步骤，以及人工介入比例，不能据此认定整个流程已经无人值守。

第三个案例最适合拿来参考。Will 给空间设定持续目标：审查近期改动中的安全问题。首次执行把代码库划分为 16 个区域，分别在线程中审查，再用另一个线程交叉核验每项发现，最后在空间内保留汇总产物，供 Will 检查和跟踪。这次有人监督的首轮执行创建了 14 个 issue。

这里有两个细节比 issue 数量更有价值：发现经过复核，结果有固定产物。14 个 issue 只能说明流程产出了多少待处理项，原文没有给出误报率、严重程度或最终确认数量。

团队还表示，部分原本发生在 Slack 的沟通自然转移到了空间，包括视频通话和讨论。这说明空间开始承载协作过程，但仍只是他们团队的使用反馈。

我的判断

我认同 Spaces 瞄准的问题：多 agent 的负担经常落在协调上。线程越多，人越需要反复传递上下文、检查遗漏、决定后续动作。对真正能够并行、或者需要长期跟进的工作，设置一个协调者有合理性。

但「自然语言交代目标」并不会自动让协调可靠。space agent 一旦理解错目标，或者把职责分错，错误可能沿着多个线程扩散。安全审查案例中的首轮监督，承担的正是校准目标和检查分工的工作。

它与显式任务图、配置式编排的取舍也很清楚：对话更容易临时调整，明确配置则更便于检查执行路径。哪种更适合，要看流程变化频率，以及团队需要多强的可重复性。原文没有做这方面的对照实验。

证据范围也要收住。产品发布前，Amp 团队已经内部使用了数周，但全部案例都来自他们自己的团队和代码库，缺少独立验证。作者认为协调者足够可靠后，人可以从过去两年的「管理线程」转向「管理目标」，这是方向判断，还不是已经验证的普遍结论。

成本同样没有消失。每派生一个线程，就增加模型调用和上下文开销。修一个范围明确的小 bug，单线程通常更简单；Spaces 是否划算，需要看它节省的协调劳动能否覆盖新增成本。

能拿来做什么

• 如果已经使用 Amp，可以先选一个边界明确、能够重复执行的审查任务，把检查范围和最终产物写清楚，并监督首次运行。原文推荐的 review、audit、迁移检查清单都属于这种尝试。
• 对前端或 Node 项目的安全审查，可以借鉴「分区审查、逐项复核、统一汇总」的流程。16 个区域是 Amp 的具体拆分结果，自己的项目应按代码规模和职责划分。
• 尝试持续任务时，要求空间保留可检查的汇总产物，并明确哪些结果需要人复核。先检查遗漏、误判和后续是否有人跟进，再决定是否扩大范围。
• 对单文件修改、定位清楚的缺陷修复，继续使用单线程即可。等任务出现多个可并行部分，或者需要连续数天跟踪，再考虑增加协调者。