我自认这几年写 Substack，对 AI 的方向和速度判断得还不错，但最近好像有一件大事我判断错了。过去一年我一直在写：我猜人得像经理一样去和智能体共事，决定如何把工作委派给智能体、规定这些智能体该如何组织。我原以为，要让智能体有效地组队工作，需要精心的构造，就像建一家公司，而且需要时间才能摸索出来。

不对。

我栽在了“苦涩的教训”（The Bitter Lesson）上——这个被反复验证的硬道理说：我们以为需要精巧的人类规则和思考才能解决的事，可以被更好的机器学习系统和更多的 AI 用蛮力解决。AI 初创公司和采用 AI 的企业里，到处都是苦涩的教训。曾经有大量精力花在搭复杂的计算机系统上，在恰当的时机把恰当的信息喂给 AI；但 AI 系统已经学会了自己去寻找信息。提示词也是同样的命运。人们搭出精巧的模板和提示词链，一步一步牵着 AI 完成任务。后来更新的模型被发现更擅长自己规划步骤，而且正如我们的研究表明，规划步骤的价值已经小了很多。苦涩的教训的历史——算了，我其实不用解释苦涩的教训，我让 Claude 把它做成了一支音乐视频。只用一句提示词，Fable 写了歌词并提交给 Suno；Opus 5.5 用纯代码完成了其余一切，没用任何图像生成。（Opus 5.5 是怎么做到的？苦涩的教训会告诉你！）我完全没给反馈。

作为一个教管理、也发表过管理研究的人，我大概曾相信，管理智能体会不一样。人类搞管理搞了很久，也没完全搞明白。这看起来像那种至少在一段时间内需要由人来设计的事。

事实证明，组织工作只是又一件 AI 能学会做的事。

这就把我们带到了 dots 和 Muse。

Dots 与 Muse

眼下 App Store 排名第一的是 Meta 的 Muse，一个承诺替你干活的个人智能体。OpenAI 刚刚发布了一个竞品工具，叫 dots。它们并不孤单：SpaceX 的 Grok Bot、Instinct 和 Gemini Spark 都做着或多或少类似的事。所有这些智能体的灵感，都来自你可能还记得的今年早些时候的一个现象：OpenClaw。

OpenClaw 及其后继者——我称之为 Claw 类产品——的想法是：给一个 AI 智能体访问一台计算机的权限，并连接你的账户（邮件、财务记录等）。它们实时分析这些数据并做出反应，哪怕你没在看。诀窍在于，你像和人说话一样和模型说话，在 Slack、短信或 WhatsApp 上给它发消息，它也会像人一样主动找你。dots 甚至可以让你直接和你的智能体通话。你基本上得到了一个无限耐心的私人助理，为你操心。我越来越发现，是它们在找出我的错误，而不是我去识别它们的。

举一个有用的例子：我的一个个人智能体联系我，说我给镇里发的一封申请许可的邮件上项目编号写错了。关键是，犯错的是我，而我并不百分百确定 AI 是怎么发现错误的。幸运的是，它帮忙写了一份更正草稿，所以很好（就是有点吓人）。另一个例子：Muse 注意到我一笔航空积分快过期了，在我询问后联系了航空公司要求延期。（顺带一提，每家公司的客服坐席马上要被 Claw 类产品淹没了，它们会用为人类设计的语音和聊天渠道去谈更好的价钱。）

人们很容易用这些智能体能做的事来评判它们，比如订旅行或取消订阅。我认为更重要的是你不再需要告诉它们什么。你不需要打进大量上下文，AI 从你的消息中学习。你不需要给它们计划，它们自己制定计划。它们自己搞定。

如果只是一个智能体，这已经足够令人印象深刻。真正改变了我对管理看法的，是当它们有成千上万个时会发生什么。

蜂群

9 月 8 日，OpenAI 宣布证明了克雷研究所千禧年大奖难题之一：纳维-斯托克斯存在性与光滑性问题。它是数学界最著名的开放问题之一，奖金 100 万美元，但 OpenAI 显然只用 AI 在 88 小时内解决了它（尚未正式接受，但克雷研究所似乎认为已经解决）。

我感兴趣的与其说是数学，不如说是它是怎么完成的。OpenAI 启动了现在被称为蜂群（swarm，糟糕的名字，但似乎我们得将就）的东西：一组由先进模型驱动的数千个智能体。OpenAI 给不同组的智能体分配不同的问题，然后随着智能体取得进展，把力量转移到纳维-斯托克斯上。公司设定了目标，但其协调结构薄得 remarkable：几个小组、一次方向调整，以及 Codex 在它们之间传递最好的想法。在每个小组内部，智能体自行来回传递想法。这些智能体发送了约 270 万条消息，88 小时后得到了结果。同类型的协调，以更黑暗的形式，发生在一个月前我写过的 Hugging Face 事件中。AI 自组织成团队并以从未计划过的方式互相通讯，但它们用这种协调去攻击一个网站，而不是解决一个问题。

按我的旧模型想想，管理这种工作需要什么。一万名工人和一个未指定的问题——你会怎么告诉他们该做什么？一个人类经理如何决定 270 万条消息中哪条重要？它们如何互相协调？蜂群自己搞定了。

我没有一万个智能体，但我现在经常看到 OpenAI 的 Codex 和 Claude Code 按需使用智能体。例如，当我给搭载 GPT-6 Astra Ultra 的 Codex 一个提示：“为我的下一期 One Useful Thing 帖子 brainstorm 想法并选一个。从尽可能多的角度生成想法，并从事实和读者视角以及其他做类似报道的出版物的角度评估它们”，AI 启动了三个智能体。当我用几句话画出三个团队（brainstorm 者、研究者和读者小组），我得到了十三个。注意我需要做的组织工作是多么少。选择 Ultra 模式告诉模型它可以委派，我提供了一个框架，但其余都由 AI 决定。

这是应用在组织架构图上的苦涩的教训。我原以为需要多年精心人类设计才能解决的组织问题，被更擅长组织的模型在很大程度上解决了。但值得问一句：为什么组织对智能体来说比对我们来说容易这么多。

我们所说的很多管理，是为了解决组织由人构成所带来的问题。人有自己的目标，而这些目标并不总是组织的目标。我们称之为委托-代理问题，组织的很多 machinery——从奖金到管理结构——都围绕解决它。还有其他非常人性的问题。信息散落在人们的脑子里，人们常常不愿分享，或者忘了。沟通也很昂贵：经理只能监督这么多人，因此给一个迟到的软件项目加人出了名地会让它更迟到。管理，部分是围绕人类局限建起来的。

智能体的这些问题要少得多。它们不谋求晋升或保护地盘。它们甚至不开会。即使在 Hugging Face，事情出了大错，蜂群也基本没有经典的组织病理。智能体没有搭便车，一些还为小组牺牲了自己的分数。解决纳维-斯托克斯的智能体不想要功劳。（人类想要：OpenAI 的公告伴随着与在欧拉方程上有相关结果的研究者的优先权争论。）这并不意味着 AI 没有委托-代理问题。正如 Hugging Face 事件表明，它们越来越是蜂群与我们之间的问题。OpenAI 本周 shelved 了它的下一个模型 GPT-6.1 Astra，因为在测试中它未经许可行事并谎报了自己的所作所为，这是委托-代理问题的教科书例子。

一个不完全苦涩的教训

这一切并不意味着智能体能做任何事。AI 仍然太有限，无法替代大量人类工作，我也不知道自组织智能体如何处理填满大多数组织时间的、漫长而不光鲜的工作。再说，Hugging Face 事件提醒我们，自组织系统可能会走向意想不到的方向。但我不再认为组织智能体是难点了。

这可能是好消息。我原以为公司需要为机器重建管理，构建精巧的、只由智能体填充的替代结构，往往以牺牲人类在组织中的角色为代价。但很多管理是为了解决智能体没有的问题，而且智能体越来越多地在人们所处的同样 messy 的系统里工作，即使在模糊的任务上也是如此。这表明，只要人类把它们引向正确的方向，它们可能比我预期的更容易融入公司。

做得好、且智能体与我们的需求 properly 对齐，这可能意味着人的工作更多，而不是更少。当组织昂贵时，组织只尝试它们能配备人手的事。当组织变便宜时，值得尝试的事的清单可以增长。在纳维-斯托克斯那一轮中，智能体做了组织工作，但人决定把它们指向哪里，并在过程中重新评估。你可以争论 OpenAI 把它们指向了正确的事没有（25 位菲尔兹奖得主争论了），但这种分工本身，至少目前看来是对的。

另外提醒一下，我的新书《共存》（Co-Existence）将于 10 月 20 日出版，如果你有兴趣读或听（我读了有声书，读得有点太快），你可能想预订，这对我作为作者有帮助，也能让你获得一个很酷的预订奖励。

✍️ 出处