AI未开源软件工具

一个 Agent 指挥一队 Agent：Amp 的 Spaces 把「开线程」这件事交给了 AI

2026年11月9日1 次阅读
一个 Agent 指挥一队 Agent：Amp 的 Spaces 把「开线程」这件事交给了 AI

先讲结论

2026 年 11 月 6 日，Amp 发布了一个叫 Spaces 的新东西。它要解决的问题很具体：当你同时开五个编码 Agent，真正累的不是写代码，是当调度员——记不清哪个线程停在哪、谁在等审批、哪件事已经做完了。

Spaces 的做法是：你只跟一个 Agent 对话，把目标告诉它，由它自己去拆任务、开并行线程、盯着进度，再把需要你拍板的事端回来。用官方的话说，Space 是「你和单个 Agent 的对话，这个 Agent 的工作是替你生成并协调其他 Agent」。

需要先说明来源性质：本篇核心事实来自 Amp 官方公告与官方文档；发布时间、功能定位另有多家中文媒体在同一时间窗口内转述印证，涉及第三方描述的部分是基于多家媒体转述整理。

这次到底新在哪

过去一年，多 Agent 工作流的默认形态是「你自己管」：你在侧栏开一个线程、起个名、想清楚这块给谁做，然后再开第二个、第三个。工具帮你并行执行，但拆分和追踪仍然是人干的活。

Spaces 把这一层拿走了。你不用再创建和整理线程，只需要在一个聊天窗口里说「把这版功能推上线」或者「把最近的改动做一次安全审查」，主 Agent 会把目标翻译成若干线程，每条线程在聊天里变成一张实时卡片，显示它跑到哪、是不是在等人。

这个变化听起来像 UI 调整，实质是操作对象的层级变了：以前你操作的是线程，现在你操作的是目标。

还有一层容易被忽略：Spaces 从一开始就是按团队设计的，不是单人自动化。同一个 Space 可以共享给同事，大家在同一个聊天里提需求、反馈 bug，评论里讨论；点开卡片就能进对应线程继续迭代、直接交付。官方博客里提到，他们自己内部那个用来做 Spaces 的 Space，就是这么用的——反馈、bug、新想法全丢进聊天，Agent 负责分发成线程。

顺带一句：Amp 是 Sourcegraph 的编码 Agent 产品，几个月前把 CLI 包名从 @sourcegraph/amp 改成了 @ampcode/cli，产品线一直在往「Agent 运行环境」上走（orb、Portal、service account 都是这条线上的东西）。Spaces 是这条线上最上层的一块。

一个 Space 里其实只有五个字段

官方文档把创建流程写得很干净，一共就填五项：

  • Name：侧栏和页面顶部显示的名字。
  • Goal（可选）：这件工作是为什么做的。Amp 会用这个目标把 Space 里的线程往同一个方向拽。
  • Project（可选）：线程在哪个仓库里跑。也可以选 No Project，用来做不需要代码仓库的事，比如调研、方案规划。
  • Shared with：工作区里谁能看到、能在里面说话。
  • Slack Channels（可选）：把这些频道里的 @Amp 请求直接送进这个 Space。

前四项是「定义工作」，最后一项是「定义入口」。这个拆分很实用：你不需要为了「让 Slack 里的一句话变成一条线程」而去改整个工作流。

怎么用：五步起第一个 Space

  1. 打开侧栏的 Spaces 区域，点 +（或 New Space）。
  2. 起名 + 写目标。目标别写「优化代码」这种，写「把这周的线上 bug 按模块归因，输出一份可排期的清单」——目标越具体，Agent 拆出来的线程越像样。
  3. 选项目。有仓库就选项目；纯调研就选 No Project，这时线程会跑在没有 checkout 仓库的 orb 里。
  4. 设共享范围。只想自己用就设 Only You；要团队一起指挥，就共享给工作区或某个组，此时 Space 自动进入多人模式。
  5. 在聊天里说需求。Agent 要么直接回答，要么为每块工作开一条线程，以卡片形式贴回聊天。点卡片进线程，看结果、继续提要求、最后 ship。

三个真正省时间的细节

一、状态是"卡片"，不是"我记得"。 每条线程在聊天里是一张实时卡片，带当前状态和「是否需要人」。这意味着你不用挨个点开线程确认——哪条卡住了，聊天窗口自己会告诉你。

二、评论默认不打扰 Agent。 团队成员可以在消息下评论讨论，而 Amp 不会读这些评论，除非有人在评论里 @amp。这个设计很聪明：人类之间的窃窃私语不会污染 Agent 的上下文，要它介入就得明确叫人。

三、Slack 里的 @Amp 可以直接变成线程。 把频道绑到 Space 后，频道里任何人对 @Amp 说话，请求就进这个 Space，由它开线程。限制也很明确：只有共享给整个工作区的 Space 才能绑频道，且只能是 Amp 已加入的公开频道，其他消息（包括 bot 发的）不会进 Space。

另外，要「说」而不是「打字」，可以开 Space 的 Huddle——团队语音，边聊边指挥。

权限边界：官方写得很直白

这部分值得单独看，因为多 Agent 协作最容易出事的就是权限。

  • 共享的 Space 只能用共享的资源：它只能在「与工作区共享的 orb 或 runner」上开线程，不能用你的个人 runner。它的线程本身也是多人可见的。
  • 它只能给"大家都看得到"的线程发消息、收报告。
  • 它只能加入共享范围不窄于自己的线程。私人线程不会被悄悄拉进团队空间。

换句话说，一旦你把 Space 共享出去，它就不再能碰你的私有机器和私有线程。这是产品层面的硬边界，不是靠提示词约束的。

进度是怎么算出来的

Space 的目标下面有一张 30 天图，每条线程被记成三种状态之一：

  • Shipped：工作真的落地了——提交进了默认分支、PR 被合并、或者线程被 ship 归档。
  • Archived：没有可提交的东西（调研、规划），你手动归档。
  • Open：还没落地也没归档。

这里有个技术细节挺关键：Amp 是靠提交信息里的 Amp-Thread-ID trailer 来认「这条线程的代码到底进没进主干」的。而且它只能看到三类仓库的落地情况——Amp 托管的仓库、装了 Amp GitHub App 的 GitHub 仓库、装了 Push Updates 的 GitLab 项目。推到别的地方（Bitbucket、自建 Forgejo/Gitea）就不算数，图表会把 Shipped 降级成 Done。

对你的实际含义：想让这张图可信，先把仓库接进它认得的那条链路；否则你看到的进度是打折的。

为什么这事值得关注

2026 年下半年，AI 编程工具的竞争重心已经从「补全准不准」挪到「Agent 能不能干完一段活」，现在又往前挪了一格：能不能同时干很多段活，而且不用人来调度。

三家头部给出的答案方向不同：JetBrains 把多个 Agent 收进 IDE 的同一个工作台；Cursor 让你用语音跟 Agent 对话、把 Agent 做成可评测的 SDK；Amp 的选择是把「调度」本身交给一个 Agent，人退到目标层。

这个方向对不对，取决于一件很现实的事：拆任务这件事，模型现在到底做得够不够好。做得好的时候，你确实像坐在船长椅上；做得不好的时候，你会得到十条半成品线程和一个更乱的下午。所以它不是「开了就变快」的功能，是「开之前先想清楚哪些工作能被拆」。

适用场景：谁现在就该试

  • 同时维护多个仓库、习惯并行开 Agent 的人：这是最直接的受益者，卡片式状态能立刻省掉一轮巡检。
  • 团队里有「固定的重复职责」：每周安全审查、每个 PR 的评审、文档保鲜——这类工作天然适合挂在一个长期 Space 里。
  • 已经把 Slack 当工作入口的团队：频道里 @Amp 就能开线程，入口成本几乎为零。
  • 需要「谁都能接手」的协作：线程是多人可见、可被同事继续 prompt 的，不是锁在某个人的会话里。

不适用的情况

  • 只有你一个人、任务基本都是线性的人：多一层编排只会多一层间接。
  • 代码不能出内网/不能用云端 orb 的团队：共享 Space 只能用共享的 orb 或 runner，能不能满足合规要自己确认；自建 orb 是另一条配置线。
  • 追求「确定性交付」的生产流水线：Spaces 是让人定方向、Agent 拆任务，拆错了要你纠正。要的是稳定可重复的话，固定脚本 + CI 更靠谱。
  • 只想省钱的人：编排不省 token。并行五条线程就是五份推理成本。

避坑：四条现在就能预见的

  1. 别把 Space 当项目管理工具用。它记的是「线程有没有 ship」，不是「需求优先级」。排期还是得在你的 issue 系统里。
  2. 共享前先想清楚 runner。共享 Space 用不了个人 runner，如果你所有算力都挂在个人机器上，共享出去会直接跑不动。
  3. Amp-Thread-ID 别被你的提交规范洗掉。有人用 commit hook 重写 message 的话，进度图会失真。
  4. 别指望它读评论。团队在评论里吵了半小时的结论，Agent 一句都不知道——要它知道，就在评论里 @amp。

成本与时间

  • Hobby：免费。Amp 托管的 orb 按用量付费，自建 orb 免费，也可以直接用自己的 ChatGPT / Claude 订阅或自己的 key（官方写明：用自己的订阅或 key 时不收 Amp 的 token 费）。
  • Individual：20 美元/月，含 45,000 分钟 orb 运行时间。
  • Teams：不加钱。成员可以各自停在 Hobby 或付费档，团队共享线程、多人协作、共享 Portal/插件/skills、SSO 等能力在这个层。
  • 时间：起第一个 Space、跑通一条线程，10 分钟内；把「目标怎么写才拆得对」摸出来，大概要一两周的实际使用。

行动建议

  1. 今天先做一个：挑一件你这周本来就要做的、能被拆成 3–5 块的工作（比如「把这版发布前的检查清单过一遍」），建成一个 Space，把目标写成一句可验收的话。
  2. 只观察两件事：它拆出的线程数是否合理、有没有线程卡在等人。这两个数字决定它对你有没有用。
  3. 顺手接一个入口：如果你团队在 Slack 里干活，把一个公开频道绑上，下次有人 @Amp 就等于自动开工——这是成本最低的一次试用。

参考来源

评论

0 条已公开
登录或注册后可以参与评论。

正在加载评论...