Amp Spaces：让主 Agent 带队写代码

Amp 在 2026 年 11 月 6 日上线 Spaces，试图把 AI 编程里最麻烦的任务拆分、线程管理和进度追踪，也交给 AI 完成。用户不再需要亲自创建一组 Agent、逐个编写提示词并来回收集结果，只需向一个主 Agent 描述目标，由它启动并协调多个并行线程。(aiticker.site)

Amp Spaces 是一个由主 Agent 负责创建、组织和协调多个编程线程的团队工作空间。 它不是简单地在聊天窗口里增加一个“并行执行”按钮，而是把开发者从 Agent 操作者提升为目标制定者：人负责说明要完成什么、检查关键决策，主 Agent 负责判断应该拆出哪些任务、哪些任务可以同时运行，以及什么时候需要人介入。

这项更新真正值得关注的地方，不是 Amp 又多了一个多 Agent 功能，而是它开始处理多 Agent 编程的第二阶段问题：当同时工作的 Agent 越来越多，管理 Agent 本身也会成为一份工作。

从“使用 Agent”变成“管理目标”

传统多 Agent 工作流的瓶颈已经从执行能力转向组织成本。开发者当然可以同时打开几个 Claude Code、Codex、Cursor 或 Amp 会话，一个负责查代码，一个负责修改功能，一个负责测试，另一个负责安全审查；但人仍然需要决定任务如何切分、复制项目背景、检查线程状态，并把几个线程的结果重新拼起来。

这类工作看起来不像编程，却会持续消耗开发者的注意力。尤其在涉及多个代码目录、测试环境和交付步骤的任务中，开发者很容易从“写代码的人”变成“不断切换聊天窗口的人”。

Spaces 的设计思路是把这层调度工作交给一个主 Agent。每个 Space 表面上仍是一段用户与单个 Agent 的对话，但这个 Agent 可以围绕目标创建其他线程，并在主对话中以实时任务卡片展示执行状态。用户可以看到哪些任务正在运行、哪些已经完成、哪些因为缺少信息或权限而需要人工处理。(ithome.com)

例如，用户可以直接提出“把服务账号功能推进到可发布状态”，而不是分别下达以下指令：

• 检查现有认证与权限模型；
• 实现服务账号的数据结构和接口；
• 补齐单元测试与集成测试；
• 更新迁移脚本和文档；
• 执行安全审查；
• 汇总阻塞项并准备发布。

主 Agent 会把目标转化为一组更具体的任务，在不同线程中并行推进，并将结果重新收拢到 Space。官方展示的实际场景包括通过一个 Space 完成服务账号功能发布，以及组织周期性的安全审查。

这更像是给项目负责人配了一名能亲自调动工程师的技术项目经理。区别在于，这名“项目经理”不仅创建任务卡片，还可以直接阅读仓库、运行命令、修改代码、执行测试，并根据返回结果继续调整计划。

Spaces 到底改变了什么

Spaces 首先改变的是任务入口。过去，开发者倾向于为每个子任务创建一个独立会话；现在，用户可以先描述一个更高层级的结果，再让主 Agent 决定需要多少线程。

Spaces 其次改变的是上下文分配方式。Amp 的 Task 子 Agent 拥有独立上下文窗口，适合处理代码搜索、依赖研究、变更审查、方案设计和局部实现等工作；主线程主要接收子 Agent 的结论与交付结果，而不是塞入全部命令日志和检索过程。(ampcode.com)

Spaces 最后改变的是团队协作界面。团队成员可以在同一个 Space 中提出需求、补充限制条件或反馈问题，也可以点击任务卡片进入具体线程，查看 Agent 的产出并继续迭代。评论区不会默认成为模型上下文，只有成员通过 @amp 明确提及时，Amp 才会读取相关评论，这能减少闲聊、讨论分支和无关信息对 Agent 的干扰。

这一设计看似保守，却比“让 Agent 阅读所有团队消息”更实用。软件项目中的大量讨论并不需要触发代码变更，如果 Agent 对每条评论都作出响应，不仅会增加模型消耗，还可能让尚未形成结论的讨论被错误地当成执行指令。

它不是一群 Agent 自由开会

多 Agent 编程是由多个拥有独立上下文和工具权限的 AI Agent，围绕同一目标分工执行任务的工作方式。Spaces 采用的并不是多个 Agent 平等协商的“圆桌会议”结构，而是一个主 Agent 统一分派、追踪和汇总的层级式结构。

这种结构可以概括为三个步骤：

1. 主 Agent 理解目标，建立任务边界和验收条件；
2. 子 Agent 在独立线程中搜索、实现、测试或审查；
3. 主 Agent 汇总结果，处理冲突并决定是否追加任务。

中心化编排的优势是责任链清楚。某个子 Agent 即使给出了错误结论，也不会天然成为最终交付；主 Agent仍需检查结果、比较不同线程的发现，并决定是否采纳。

中心化编排的代价是主 Agent 可能成为新的瓶颈。如果任务拆分不合理，两个线程可能同时修改同一个模块；如果主 Agent 只读取摘要，没有检查测试记录和代码差异，它也可能错过隐藏的接口冲突。Spaces 降低了调度成本，但不会自动消除软件工程中的依赖管理和质量控制问题。

与其他多 Agent 方案有什么区别

Spaces 的差异不在于“能够启动子 Agent”，而在于把持续存在的多线程任务组织能力直接放进团队对话。单次子 Agent 调用更像临时委派，动态工作流更像生成一段可重复执行的流程，而 Spaces 更接近一个长期存在、可以由多人共同使用的 Agent 控制台。

| 方案 | 用户主要输入 | 谁负责任务拆解 | 子任务载体 | 适合场景 | 主要风险 | |---|---|---|---|---|---| | 单 Agent 会话 | 具体问题或修改要求 | 用户或单 Agent | 同一上下文 | 小型修复、代码解释、局部重构 | 上下文被日志和检索结果塞满 | | 传统 Subagent | 已拆好的子任务 | 主 Agent | 临时独立上下文 | 搜索、审查、研究、局部实现 | 用户仍要管理整体任务结构 | | 动态工作流 | 目标与执行条件 | 模型生成的编排逻辑 | 后台流程节点 | 阶段明确、依赖稳定、可重复任务 | 流程错误可能被自动放大 | | Amp Spaces | 高层级项目目标 | Space 中的主 Agent | 可查看的持久线程 | 功能发布、安全审查、跨模块任务 | 主 Agent 的拆分和汇总质量决定上限 |

Spaces 比普通 Subagent 更强调可见性。用户不是等所有任务完成后只收到一份总结，而是可以在主界面查看线程状态，并随时进入具体任务检查代码、测试和推理结果。

Spaces 比固定工作流更强调临场调整。软件开发任务经常在执行后才暴露真实依赖，例如修改鉴权逻辑后发现数据库迁移不兼容，或者前端实现完成后才发现接口缺少字段。主 Agent 可以根据线程产出继续创建任务，而不必提前把全部流程写死。

Spaces 也没有完全走向“自治软件公司”。它更像人类团队组织方式的一次界面映射：一个负责人把目标拆给多个执行者，各执行者保留自己的工作区和上下文，负责人再汇总结论并处理依赖。

真正有用的场景是跨模块交付

Spaces 最适合任务边界能够拆分、但最终结果必须统一验收的工程项目。一个只改两行配置的任务没有必要启动多个线程，因为编排成本可能高于执行成本。

复杂功能发布则更能体现价值。假设团队准备为一个 SaaS 产品增加企业级单点登录，主 Agent 可以同时安排不同线程检查身份提供商协议、实现后端认证流程、修改前端登录页面、补充数据库迁移、编写测试，并审查现有会话管理逻辑。只要各子任务的写入范围相对独立，并行执行就可能明显缩短等待时间。

安全审查也是理想场景。不同 Agent 可以分别检查依赖漏洞、权限边界、密钥处理、输入验证和日志泄露问题；主 Agent 再对发现进行去重、排序，并把高风险问题转化为修复任务。与单个 Agent 顺序扫描相比，这种方式不仅更快，也更容易通过独立线程隔离大量搜索结果。

大型重构则需要谨慎使用。如果多个 Agent 同时修改高度耦合的核心模块，速度提升可能被合并冲突、重复实现和测试失败抵消。一个聪明的主 Agent 应先安排只读分析线程绘制依赖关系，再决定哪些模块可以并行修改，而不是看到复杂任务就盲目增加 Agent 数量。

最大的不确定性仍是验证

Spaces 没有解决 Agent 生成代码的可信度问题，只是让更多 Agent 更容易同时工作。并行化可以缩短执行时间，也可以让错误更快扩散。

主 Agent 的任务描述必须包含清晰的退出条件。与其说“完成支付模块重构”，不如要求“保持现有接口兼容、全部单元测试通过、补充退款失败场景测试，并列出涉及的数据迁移”。验收条件越具体，主 Agent 越容易判断线程是否真正完成，而不是仅仅提交了一段看似合理的代码。

团队还需要明确写入边界。多个线程同时编辑同一批文件时，应由主 Agent指定模块范围、分支策略或提交顺序；涉及生产部署、数据删除、权限修改等高风险操作时，仍应保留人工确认点。

成本也会成为多 Agent 工作流的现实约束。一个任务被拆成五个线程，意味着模型推理、代码检索、测试运行和远程计算资源都可能同步增加。多 Agent 的合理目标不是使用尽可能多的 Agent，而是让可以独立推进的关键路径真正并行。

Amp 押注的是“Agent 管理层”

Spaces 代表 AI 编程产品正在从代码生成工具转向任务执行系统。第一代工具争夺的是补全质量，第二代工具争夺的是谁能自主读代码、修改文件和运行测试，而现在的竞争开始转向谁能组织多个 Agent 完成一次真实交付。

这也是 Spaces 最值得肯定的地方：它没有把多 Agent 包装成一排炫目的机器人头像，而是正面处理线程太多、状态不透明、结果难汇总这些实际问题。实时任务卡片、可进入的子线程和按需读取评论，都围绕工程团队的真实协作成本设计。

但 Spaces 能否成为开发者的“AI 项目经理”，最终不取决于它能启动多少线程，而取决于三个更难量化的能力：任务拆分是否合理、结果汇总是否可靠、出现冲突时是否知道暂停并寻找人类。

如果这三点做得好，开发者会逐渐从逐行指导 Agent，转向定义目标、约束边界和审查证据；如果做不好，Spaces 只会把“管理一个不稳定 Agent”的问题，扩大成“管理一支不稳定 Agent 团队”。

Amp 这次至少选对了问题。多 Agent 编程真正缺少的从来不是更多并行窗口，而是一个能够看懂全局、控制依赖并对最终结果负责的协调层。

参考来源

• IT之家：AI 编程工具 Amp 推出 Spaces — 介绍 Spaces 的发布时间、任务卡片、团队评论和官方使用场景。
• GitHub：How to Best Prompt Amp — 社区实践指南，说明 Amp 的线程、子 Agent、工具执行与任务验收方式。
• 知乎：AI Agent 多智能体协作机制演变 — 梳理主 Agent 委派、独立线程执行和结果汇总等多 Agent 编排模式。