畅想：瓶颈与更高效的协作未来

一、瓶颈的迁移史#

回头看这几年的 AI 协作，瓶颈换过四次地方。

prompt 时代，瓶颈是「怎么问」。同样一个模型，会写咒语的人产出高一截，于是提示词模板、咒语工程满天飞。后来各家把 prompt 做成了产品内置的东西——这个瓶颈就商品化了，没人再为它付钱。

context 时代，模型够聪明了，瓶颈变成「塞得下吗」。上下文窗口、RAG、记忆机制，一整代产品都在解决「让模型记住该记住的」。

loop 时代，context 也商品化了，瓶颈变成「怎么让它连续做事」。agent loop、工具调用、任务规划——这一代解决的是从「一问一答」到「接手任务」的跨越。

现在是 attention 时代。 模型的产能在爆炸：一天之内，它能写完我一个月读不完的代码、读完我一个月读不完的邮件。但我吃不下。瓶颈第一次从模型侧挪到了人类侧——不是模型产出得太少，是人接收得太少。 究其根本，人类的思考和输入输出模式太弱了：我们还是用眼睛读、用键盘敲、用脑子单线程想。这几十年，模型的带宽在翻倍，人的一直没变。

产能在模型侧过剩，消费在人类侧卡死。这就是当下的瓶颈。

二、软件行业已经预演过一次#

这个迁移有个现成的历史剧本，就在软件行业里。

五年前，开发一款软件需要一个团队：前端、后端、运维，外加一名产品经理。四个人的协作，一半的工时花在沟通上——对齐需求、同步进度、处理代沟。每个人的专业深度都很窄，靠协作网络拼出完整的产品。

如今，一个开发者加上 AI，就能覆盖这条流水线的大半。他最底层的能力只剩下两样：产品思维，和全栈的知识体系。 协作从「人与人」收缩成了「人与模型」。

被覆盖的，是每一个 API 的底层实现。你不需要知道这个 HTTP 库内部怎么管理连接池，不需要记得那个排序算法的底层用了哪种优化——这些是被文档和抽象封装好的确定性知识，AI 比你熟，查它就行。硬要背，就是给分支浇水的老路。

剩下不能被覆盖的，是三件事。

权衡。 缓存换一致性、成本换延迟、上线速度换技术债——软件里真正难的决定全是 trade-off，没有标准答案，只有「这个场景下值不值」。AI 能列出所有选项和各自的代价，但「我们的场景更在乎哪一头」，这个定价权在你手里，因为它需要知道业务里哪个数字不能碰。

定基调。 一个系统的基调是它的第一块砖：命名风格、错误处理哲学、模块怎么切、什么算「够了」。定了基调，AI 后续产出的每一块都会沿着它走——你拍下的第一个决策，会被当成惯例无限复制。所以第一块砖必须是人拍的：AI 能执行基调，甚至能从既有代码里学出基调，但为一个还不存在的系统发明基调，需要的是立场，不是概率。

驳斥反常的写法。 AI 交来的 diff 大体是对的，真正的风险藏在反常处：和代码库既有惯例冲突的写法、悄悄超出性能预算的实现、把错误处理做得看似优雅实则吞掉的方案。驳斥它们靠的是「见过正常的样子」——你的主干越扎实，反常在你的眼里越刺眼。这其实就是「验证变贵」落到个人头上最日常的形态：不是去啃每一段底层实现，而是扫一眼就知道这块砖放歪了。

所以「全栈的知识体系」不是让你精通每一层，是让你在每一层都有能力做三件事：权衡、定基调、认出反常。这三件事有一个共同点——它们都要求你对「好」有一个立场，而立场，是模型生不出来、只能由拥有它的人带进协作的东西。

这次收缩有一个被低估的副产品：磨合成本近乎消失了。 四人团队里有性格摩擦、有信息损耗、有谁也不肯让步的技术分歧；人和模型之间没有这些。产能上去了，成本下来了，而真正省掉的，其实是协作成本。

三、多智能体的第一次尝试：chatparty，和它的翻车#

沿着「协作收缩」的思路，自然会想到下一步：一个人管不过来了，能不能让多个 AI 互相协作，我只管最后的把关？

我自己先撞了一次墙，过程值得完整讲一遍。

chatparty 的思路是多角色多专家：几个不同立场的 agent 互相讨论、互相挑错，用群体智慧抑制幻觉。前期效果不错。但跑到十轮以上，输出开始变味——越来越啰嗦、越来越趋同、越来越像在写实验报告。

我们第一反应是老办法：堆提示词。堆了三轮，没用。提示词治不了会漂移的东西。最后上的是土办法：把「什么是合格的输出」从模型的模糊判断，改写成硬编码的筛选规则，接进 harness 做自检。这次收口之后我才意识到一件事：模型的产能从来不是瓶颈，我的验证带宽才是。

那次尝试的结论是半对半错的。错的那半：专家多样性并没有兑现成正确率，多 agent 真正起作用的机制，主要是靠扩充上下文对抗对话腐坏。对的那半：众 bot 拾柴火焰高，这个方向没有死——死的只是当时不成熟的模型和架构。

四、Grok Bot：一个具体的产品尝试#

2026 年 8 月 11 日，x.ai 官网发布 Grok Bot，定位是一支持续在线的 agent 团队，发布时处于 beta 阶段。同月 14 日，Cursor 宣布正式被 SpaceX 收购。比起收购本身，更值得我关注的是 Grok Bot 的产品形态：它开始把多 agent 协作、云端电脑和例程执行放进同一个工作入口。Grok Bot 发布公告 · Cursor 收购完成公告

回到产品本身，它的几组设计，确实和上面讨论的协作思路接得上：

多 Bot 分工。 官方展示了工程 Bot 在产品界面复现问题、建立 ticket，再把修复交给调试 Bot 的例子。Bot 可以相互发消息、在群聊里交接任务，不必由用户反复复制上下文。发布公告：协作示例

首席 Bot 统筹。 发布公告介绍了一种内部用法：用一个「幕僚长」Bot 协调收件箱、报销、招聘、修复等专业 Bot，在需要判断时再请用户介入。这是官方描述的使用方式，不意味着每次协作都能可靠地做到只让人看最后的拍板点。发布公告：多 Bot 协作

持久运行。 官方入门指南说明，它的电脑运行在云端，带有桌面、文件系统、终端和应用，关掉本地电脑后仍能继续工作。不过，这不等于每个 Bot 都有一台独立虚拟机：指南还特别提醒，在共享电脑上登录的网站，其他 Bot 也能访问。Grok Bot 101：云端电脑与共享权限

例程固化。 用户可以示范工作步骤，让 Bot 保存为 Routine；官方指南还介绍了定时执行和监听其他应用事件的触发方式。指南同时说明，动作会受权限、允许与阻止列表及审核 agent 约束，审核结果可以是允许、阻止或交给用户决定。保存了流程，不等于从此不需要验证。发布公告：例程 · Grok Bot 101：触发与审核

这一组设计让我看到一种可能：人可以少做上下文搬运，把更多注意力留给关键判断。 这是我对产品方向的理解，不是「attention 瓶颈已经被解决」的实测结论。官方功能介绍和内部案例能说明它在尝试什么；至于审阅时间是否真的减少、错误和返工有没有增加，仍要看具体任务中的表现。

五、但两个问题还没被回答#

畅想归畅想，多 agent 协作有两个实际的问题，我自己在做 chatparty 时就撞过。这两个问题，我目前只有阶段性的答案。

第一，偏离主线怎么约束？ 多个 agent 自主协调，谁来保证它们讨论的永远是正题？

为什么约束这么难？因为约束的本质是验证——你得先能快速判断「它偏了没有」，才谈得上拉回来。而群聊里每一次发言都是一个潜在的分叉点，人手验证的速度，根本跟不上发散的速度。所以我的判断是：不能只靠提示词，还得把验证器接进来——自主权能放多宽，要看反馈环路能覆盖哪些错误。Grok Bot 的例程和动作审核，是把执行路径复用、把部分判断交回用户的具体尝试。但例程跑完、审核放行，都不自动等于结果正确；不能因为某条路径成功过一次，就默认它可以无监督重跑。

第二，账算得过来吗？ 用更高性能的旗舰模型一次做完，为什么要选一个慢得多、token 加起来不一定便宜的多 agent 流水线？

我判断的方法很简单，只问一个问题：你的任务队列，长过单个模型的吞吐了吗？ 没超过，旗舰单模型就是最优解，多 agent 只是为了架构好看多花钱。超过了，或者一个任务天然需要多份互不污染的上下文——多 agent 的并行和隔离才开始值钱。多 agent 不是更高级的架构，是更贵的架构；贵的东西，要用吞吐量来摊。

这两个问题没有标准答案，但谁先答好，谁的产品就先跑通。

六、PA：把瓶颈交还给机器#

畅想再往前一步，就到了这篇的主角。

随着旗舰模型继续发展，我有理由相信：一个读完了你全部数字资产的 PA，足以和你协作完成大部分杂项工作——写本子、读邮件、处理报销、盯项目进度。

它为什么比人类团队强？不是因为它更聪明，是因为它懂你。它读过你所有的对话记录和决策（就是《新时代的重要资产》里说的那条决策链），知道你的偏好、你的雷区、你上次为什么否掉那个方案。没有代沟，没有磨合期，没有「我以为你以为我以为」。

这时候人的角色就变了。你不再是执行者，你是 leader——带着一支不懂疲倦、完全懂你的团队做任务。而 leader 要做的事，拆开就三件：给方向、做拍板、担责任。开发者的角色会越来越像一个项目经理——不写每一行代码，但为每一个结果负责。

一个人，爆发一个团队的产出。 这不是效率的线性提升，是协作成本被清零之后的形态。

七、瓶颈之后，还是瓶颈#

别急着把这套叙事当成定论——这篇是畅想，畅想的规则是往还没到来的地方看。attention 之后，瓶颈还会继续迁移。我猜，下一个是信任。

想象那个时刻：PA 读完了你全部的数字资产，本子初稿写好了，邮箱里的邮件处理完了，然后给你发来一条消息：「都做完了，三件事需要你拍板。」

那一刻，瓶颈已经不是它能不能做——它能，而且做得不差。瓶颈变成一个很安静的问题：怎样验证？

它说这个方案可行，你要不要抽掉验证那一步？它说这封邮件回得没问题，你要不要连点开都不点？

我不知道答案。也许信任会像产量一样逐步上升：从可逆的小事开始放权，它错一次就收一点，对一次就放一点——信任变成一个随记录浮动的滑块，而不是一个按下去就不回头的开关。也许到那时候，「验证」这个动作本身会换形态：你不再亲自验每一步，只是定期翻一翻它的验证记录，像 leader 翻团队的周报。

还有一种可能：瓶颈根本不在信任，而在更远的地方——比如「决定问什么」。当 PA 能回答一切的时候，知道该问什么的人，又成了新的瓶颈。往这个方向想下去，瓶颈的终点似乎是一个悖论：机器越强，对人的要求越高，只不过要求的东西，从记忆和手速，一路换成了品味、判断，和现在还没名字的东西。

这篇只能写到这儿了，再往前就是幻想，我想留给时间。

但有一件事我比较敢肯定：瓶颈永远在迁移，而且每一次迁移，都会把上一代瓶颈变成商品，再把新的问题递到人面前。 prompt 时代考验表达，context 时代考验组织，loop 时代考验架构，attention 时代考验品味——下一个考验什么，我不确定。