结论先说：agent 的下一次大变化，不是干活的 agent 变得更聪明，而是多了一个更好的前台。你只跟一个 agent 说话，在一段很长的对话里。它把活分给别的 agent，盯着它们每一个，只在你真的需要知道某件事时，才拍拍你的肩膀。
今年有两个产品指向了同一个方向：Claude Dispatch 和 Grok Bot 的 Primary Bot。它们看起来只是小功能，但我觉得，下一代 agent 大概就是这个样子。
1. 问题：我们不知不觉成了管理者
一年前，“用 agent”指的是一个聊天窗口、一件事。
现在是五个会话、三个终端、几个云端任务，再加手机上一个 bot。每一个都能不用你管，自己跑上一小时。听起来很好。但总得有人去：
- 记住哪个会话在做什么，
- 发现哪个卡住了，
- 回答它的问题，
- 看它的结果，
- 再决定下一步做什么。
这个人就是你。你没打算带团队，团队却来了，你成了它的经理。
很多人已经有感觉了。Simon Willison 在 Lenny's Podcast（2026 年 4 月）里说，同时跑几个 agent 让他更快，但还没到中午就累垮了。Addy Osmani 写过“并行 agent 的上限”：跑的 agent 多了，你并没有变多。也有人换了个说法：累人的是来回切换，不是做决定。
研究早就说过这件事：
- Gloria Mark 跟踪过办公室职员，发现被打断的工作平均要过约 23 分钟才会被重新拾起，中间常常还插进了两件别的事（Gallup 访谈）。具体数字不重要，重要的是量级：几十分钟，不是几秒。
- Sophie Leroy（2009）提出了注意力残留：切换任务时，一部分心思还留在上一件事上，新的事就做得更差。
所以瓶颈不在算力，在人的脑子。每多一个 agent，脑子里就多压一点重量。
想象一个厨房，有十个好厨师，却没有主厨。菜都不错，可在出菜口传菜的那个人累坏了。
2. 两个产品，同一个想法
Claude Dispatch
Dispatch 是 Claude 桌面 app 里一个一直在线的 agent。你和它只有一段对话。你说想要什么结果，它把活拆开，每一块开成一个独立的 Cowork 或 Code 会话，做完后把结果放进侧栏。Anthropic 的帮助中心说，这段对话不会重置，会记得之前做过的事。
文档里有几个细节很关键：
- 它只派活，不干活。写代码的交给 Code，知识类工作交给 Cowork。
- 子任务不能再生子任务。整棵树只有一层。
- 每个子任务都有明确的状态：运行中、等你输入、等你回答、已完成、出错、已归档。
- 权限请求会转给你：十分钟内你不回应，请求就被拒绝，任务不带这个权限继续跑。系统不会因为等你而卡住。
Dispatch 的工具更能说明这个设计。它大概只有四个动作：启动任务、给任务发消息、读任务的记录、给用户发消息。它自己不干活，只能派活、引导、检查、汇报。
这张很短的工具清单，是整个设计里最有意思的一点。它逼着前台一直只当前台。
Grok Bot 的 Primary Bot
Grok Bot（xAI 出品，现在属于 SpaceXAI）在 2026 年 10 月初加了一个主 Bot。0.67.0 版的更新日志说，被标星的主 Bot 会主动找出能替你分担的事，并提出由它来做。发布报道说它是一个坐在其他 Bot 上面的主助手，把任务分给合适的 Bot，并且“需要你帮忙时才来找你”。Bot 还能开一个 Project：一个会自己规划、自己调度 agent 的云端 agent。
报道里有个例子：航班改签后，Bot 发现 Uber 的接机还对着旧航班，没等人问就提了出来。
同一个形状
| Claude Dispatch | Grok Primary Bot | |
|---|---|---|
| 唯一入口 | 一段一直在的 Dispatch 对话 | 一个标星的主 Bot |
| 把活交给 | Cowork / Code 会话 | 你的其他 Bot、Project |
| 自己干活吗？ | 不干，只调度 | 主要是分派 |
| 什么时候找你 | 任务完成、有问题、要权限 | 需要帮忙，或发现可以替你做的事 |
| 记忆 | 长对话保留上下文 | 知道其他 Bot 在做什么 |
两家公司各自走到了同一个设计上。这说明它解决的是一个真问题。
3. 里面的三个设计想法
我看到的是三个叠在一起的想法。
想法一：只有一扇门
你不该需要知道哪个 agent 负责什么。告诉前台就行，前台会把你领到对的房间。
这是经典的编排者–执行者模式。Anthropic 自己的多 agent 研究系统就是这么做的：一个主 agent 做计划，开出多个子 agent 并行搜索，再把结果汇总。在 Anthropic 内部的研究评测里，Opus 当主 agent、Sonnet 当执行者的组合，比单个 Opus agent 高出 90.2%。
但 Dispatch 和 Primary Bot 把这个模式往上提了一层。编排者不再藏在某个任务里面，它成了产品的大门。用户跟编排者说话，不跟执行者说话。
想法二：默认安静
好的前台不会每来一个快递就打电话给你。只有快递是你的、很急、或者坏了，它才找你。
所以第二个想法是一道过滤：只告诉用户该知道的事。在 Dispatch 里，这是一个单独的工具（给用户发消息），找你是一个刻意的动作，不是干活时顺带发生的。在 Primary Bot 里，它“需要你帮忙时才来找你”。
这也是老研究了。1999 年，微软研究院的 Eric Horvitz 等人写了Attention-Sensitive Alerting。一句话概括：打断别人之前，先比一比现在打断的代价和等一等的代价。只有等一等更亏时才打断。他们后来的文章把注意力称为“稀缺的商品、关键的货币”（CACM 2003）。
更早，1995 年，施乐 PARC 的 Mark Weiser 和 John Seely Brown 写了平静技术：技术应该“告诉你信息，但不要求你盯着它”。东西平时待在边缘，就像开车时的发动机声，出了问题才移到中心。
前台 agent 就是 agent 工作里的平静技术。执行者在后台嗡嗡地干活，有事时，前台只把那一件事端到你面前。
想法三：让长对话记着，而不是你的脑子
这是我最在意的一点。
用很多 agent，真正的代价不是在窗口之间点来点去，而是得把整张地图装在脑子里：什么在跑、什么卡住了、定过什么、下一步是什么。这张地图很重。
前台的长对话就是放这张地图的地方。它记得你上周问过什么，知道哪个子任务卡住了，你问“X 进行到哪了？”它能直接回答，你不用打开五个标签页。你不用再当整个系统的记忆。
就像一个带着笔记本的好助理。你不用记住每一场会，问他就行。你的脑子留给真正要做的决定。
所以“一段长对话”不是个小细节。每次都重置的 Dispatch 对话，只是一个启动器；记得住的对话，才是搭档。
LangChain 的 Harrison Chase 推过一个相关的想法，叫环境 agent（ambient agents）：agent 跟着事件流运行，只在有重要的事时才找你，好“把注意力留给最要紧的时候”。前台正适合安放这些 agent：它们的问题都汇到一个地方，而且已经排好了序。
4. 为什么我觉得这是以后的样子
- 瓶颈换了地方。模型已经便宜、快到可以同时跑很多个，现在稀缺的是人的注意力。谁花用户的注意力更少，谁就赢。
- 它能变大，你不用跟着变大。一个前台下面挂十个执行者，占你的注意力和只有一个前台差不多；十个散着的会话，就占你十份。
- 它符合人本来就怎么分派工作。没人靠参加每一个会来管公司。他们有幕僚长、一个统一的收件箱、每周的汇总。
- 它能跨设备。Dispatch 可以在手机上发起，在电脑上跑。一段对话好带着走，十个会话不行。
- 角色分开，每部分都更简单。执行者可以很专、用完就扔；前台可以谨慎、慢、长期在线。各做好一件事。
5. 难的地方（还没解决）
想法很简单，做好却不简单。
- 过滤两头都可能错。太吵，你又回到通知地狱；太安静，一个坏掉的任务放着几个小时，你还以为一切正常。假安静比噪音更糟，因为你根本不知道它发生了。
- 信任需要一扇窗。前台说“做完了”，你得有便宜的办法去核对。Dispatch 让每个子任务的记录都在一次点击之内。这应该是规矩，而不是加分项。汇报只是说法，不是证据。
- 长对话会越来越长。一段活上好几周的对话，迟早超出任何上下文窗口。它需要好的摘要、一个记忆库，还要能安全地忘掉东西。这主要是工程问题，但它决定了“搭档”的感觉能不能撑过第二个月。
- 等不等人，是一个设计选择。Dispatch 十分钟后拒绝权限请求，继续往下跑。这个立场很清楚：用户不说话，不算阻塞。别的产品会选别的立场，但每一种都应该让用户看得见。
- 主动可能变成强推。Primary Bot“不用你开口”就主动揽活，很强大，也意味着由 agent 来决定什么值得你注意。据说 Grok 的建议不收费，这就少了一道限制它多提建议的刹车。Horvitz 那条规则，只在等一等更亏时才打断，还是得有个地方来执行。
- 一扇门也是一个单点故障。前台理解错了你，每个执行者都会跟着错。好的前台会在分派之前，先确认一遍任务。
- 层数限制很重要。Dispatch 只让树有一层。现阶段这大概是明智的：agent 管 agent、层层往下的深树，很难看清，也很难叫停。
6. 做一个前台 agent 的小清单
如果你要做一个，下面是我会从这两个产品里抄的东西：
- 只给前台调度用的工具。启动、发消息、读记录、汇报。它要是能自己干活，就一定会自己干，然后就不再是前台了。
- 把“告诉用户”做成一个单独、刻意的工具。不是每一步都说，也不是每做完一件都说，只说用户该知道的。
- 每个子任务都要有看得见的状态。运行中、等你、完成、失败。用户一眼就能看到全局，不用开口问。
- 记录要在一次点击之内。摘要为了快，原始日志为了信得过。
- 永远不要无限期地等人。定一个超时和一个默认做法，并且说清楚是什么。
- 先让长对话记得住，再压缩。记忆就是产品本身，要为第二个月做打算。
- 树要浅，直到你有好工具能看清深的那种。
7. 再往前一步：你的 agent 和对方的 agent 对话
到这里，前台都站在你这一边，把活分给你的执行者。现在把这个想法再往前推一步。
你想办的很多事，其实是由某家公司来办的：把宽带迁到新家、改签航班、弄清一张错账单。今天你得通过这家公司的 App 来办：它的页面、它的表单、它的菜单。就算有 agent，agent 也得像人一样，一页一页点过去。
下一步是：公司那边也有一个前台。你的 agent 把你想要的告诉对方的 agent。对方的 agent 在公司内部把活全做完，查覆盖、约时间、改账单、找它自己的内部 agent，然后回来汇报。交接一次，代替点五十下。
举个小例子。你说：“20 号把宽带迁到新地址。”你的 agent 知道新地址、日期和你的日程；运营商的 agent 知道覆盖范围、空闲时段和价格。它们俩商量好，你只收到一句：“20 号上午 9–12 点师傅上门，价格不变。可以吗？”
我把这叫作agent 即服务（agent as a service）。公司卖的是一个结果，接口是两个 agent 之间的一段对话。
| 接口 | 另一头是谁 | 你发过去的是什么 |
|---|---|---|
| App / 网站 | 一个在点击的人 | 点击和表单 |
| API | 一段程序 | 精确的字段、固定的调用 |
| agent 即服务 | 一个 agent | 一个目标，加上你的限制 |
零件已经在造了
- agent 和 agent 对话。A2A（Agent2Agent）是一个开放协议，让不同厂商的 agent 能互相对话。每个 agent 公开一张“Agent Card”：它能做什么、怎么联系它。它由 Google 发起，现在归 Linux 基金会管；基金会在一周年时（2026 年 4 月）说，已有 150 多家组织支持。
- agent 付钱。agent 商务协议让 agent 能替你买东西。ACP（OpenAI 和 Stripe 推出）负责在聊天里结账。AP2（Google 推出）把你的同意变成签了名的“授权书”：你想要什么、购物车里有什么、要扣多少钱，这样商家能核实确实是一个人点了头。
也得说清楚现状：目前 A2A 在生产环境里的用法，大多还在公司内部。一家公司的 agent 和客户的 agent 跨公司协作，还处在早期。
同一个前台，出现两次
这是把前台的想法用在两边。你的前台守着你的注意力，对方的前台守着它的系统。两者之间的交接，就是你的意图变成对方工作的地方。
这会改变公司比拼的东西：
- 产品不再是 App，而是 agent。App 可能缩成一张收据加一个“同意”按钮。
- 比较变得很便宜。你的 agent 可以同时问三家的 agent，再比较答案。靠熟悉的界面留住用户，效果会变弱。
- 好打交道，就是品牌。对方的 agent 有多懂你，说到的能不能做到。
难在哪里
- 谁代表谁。你的 agent 得证明它是替你办事，而且只在你给的范围内。AP2 的授权书想在支付上解决这件事；其他大多数操作，还没有这样的证明。
- 两个 agent，各为其主。对方的 agent 替公司做事。加价推销和各种暗坑，会从页面上搬进对话里。你的 agent 得是个难缠的谈判者，而不是个客气人。
- 是谁理解错了？结果不对时，需要一份双方共有的交接记录。记录就成了合同，也就是“记录要在一次点击之内”这条规矩，只是现在跨了公司。
- 对方的回复，就是你的 agent 的输入。别家 agent 发来的消息里可能夹带指令，提示词注入从此可以跨公司发生。你的 agent 应该把它当数据，而不是命令。
- 有些步骤还是得你来。钱、合同、个人信息。Horvitz 那条规则依然成立：只在等一等更亏时才打断，而付错一笔钱，永远是等一等更亏。
结尾
我们花了两年，让 agent 更会干活。下一步，是让它们更会不打扰我们，并且替我们记住全局，让我们不用自己记。
以后的 agent，不是你要守着的十个窗口，而是一段对话：它管着整个屋子，平时安安静静，只在要紧时拍拍你的肩膀。
而这扇门也许很快会变成双向的：你的前台把目标交给一家公司的前台，整家公司在它后面干活。
一句话：一扇门进来，门后很多执行者，你脑子里要装的东西更少。
参考资料
- Claude docs — Run tasks in the background with Dispatch
- Claude Help Center — Assign tasks to Claude from anywhere in Cowork
- xAI — Grok Bot changelog (v0.67.0, 2 Oct 2026)
- Progressive Robot — Primary Bot: Quick, Smart and Proactive, Now on Grok 4.7
- TestingCatalog — post on Primary bot
- Anthropic Engineering — How we built our multi-agent research system
- Horvitz, Jacobs, Hovel — Attention-Sensitive Alerting (UAI 1999)
- Horvitz et al. — Models of Attention in Computing and Communication (CACM 2003)
- Weiser & Brown — Designing Calm Technology (1995)
- Gallup — Too Many Interruptions at Work? (Gloria Mark interview)
- Leroy, S. (2009). Why Is It So Hard to Do My Work? The Challenge of Attention Residue When Switching Between Work Tasks. Organizational Behavior and Human Decision Processes.
- Addy Osmani — Your parallel agent limit
- SEP — Where AI fatigue actually comes from
- LangChain — Introducing ambient agents
- A2A Protocol — Agent2Agent protocol
- Linux Foundation — A2A Protocol surpasses 150 organizations (April 2026)
- AP2 — Agent Payments Protocol
- ACP — Agentic Commerce Protocol