最近 AI 圈又流行起了一种很有未来感的产品形态：AI 办公室。
打开软件，左边是一排员工。产品经理 Alice，前端工程师 Bob，后端工程师 Charlie，设计师 David，QA Eve。每个人都有头像、职位、自己的记忆，甚至还有一份 SOUL.md，规定性格、工作习惯和专业领域。
你扔进去一句：“帮我做一个 SaaS 产品。”
产品经理先梳理需求，设计师开始画界面，前后端互相对接口，QA 最后出来挑刺。几个人还会在群里互相 @，遇到问题讨论两轮，再向你汇报。
第一次看 Demo，很容易冒出一种感觉：
好家伙，我一个人已经带着一家软件公司上班了。
Grok Bot 最近在往这个方向走，Hermes Agent Desktop 的 Bot Mode 也做了类似的东西。后者甚至把 Agent 做成了完整的员工 roster：有名字、有头像、有岗位、有独立聊天窗口，还可以把几个 Bot 拉进群里讨论。
这个产品形态很漂亮。
但我一直有一个疑问：这里面到底增加了多少“智能”？
如果五个员工背后接的都是同一个强模型，只是 system prompt 不同，那么我们究竟组建了一支团队，还是给同一个人发了五张不同颜色的工牌？
五个 Agent 开会，可能只是一个模型把一句话说了五遍
先把头像和职位拿掉。
所谓“前端 Agent”“后端 Agent”“产品 Agent”“QA Agent”，底层很可能长这样：
1 | 同一个基础模型 |
当然，这些设置会影响模型。
让模型扮演 QA，它会更喜欢找问题；让它扮演产品经理，它会更多考虑用户需求；让它扮演后端工程师，它会关心数据库和 API。
可这些差异更多来自注意力方向。
五个 Agent 仍然拥有高度相似的知识边界、推理习惯和盲区。尤其当它们使用同一个最新 frontier model 时，这种同质性会更加明显。
于是会出现一个非常有趣的场景。
产品 Agent 第一个发言，把需求理解错了。
后端 Agent 看完它的需求文档，觉得很合理，于是设计了一套错误的 API。
前端 Agent 接着实现。
QA Agent 最后郑重其事地检查了一遍，然后宣布：
功能符合需求，可以上线。
整个群配合得行云流水。
唯一的问题是，一开始大家就理解错了。
这也是“独立记忆”很难解决的问题。每个 Agent 确实可以有自己的长期记忆，可只要它们进入同一个群聊，当前任务的上下文依然快速共享。
A 说完，B 看到了 A 的判断；B 说完，C 又同时看到了 A 和 B。
三轮以后，大家的长期记忆也许依然不同，对眼前这个问题的判断却已经越来越接近。
这和真正的独立判断差别很大。
如果我真想利用三个 Agent 提高研究质量，我反而更希望它们一开始互相看不到：
1 | A 独立调查 |
这样至少有机会得到三个不同的搜索路径。
一上来就把所有 Agent 拉进微信群，让第一个人先定调，很容易把 multi-agent 做成 AI 版会议室。
会议开得很热闹，信息增量却没有想象中那么高。
有篇论文，专门研究了“几个 AI 坐下来辩论”到底有没有用
这个问题最近已经有人认真做实验了。
2026 年的一篇论文叫《Demystifying Multi-Agent Debate: The Role of Confidence and Diversity》。
作者研究的正是 Multi-Agent Debate：让多个 LLM Agent 先回答问题，然后互相阅读对方的答案，讨论几轮，希望通过“集体讨论”提高正确率。
结果很有意思。
普通的 multi-agent debate 经常打不过一个极其朴素的方法：
多采样几次，然后投票。
几个 Agent 辩论半天，消耗了更多 token，最终效果甚至可能低于 majority vote。
为什么？
论文给出了一个很值得注意的解释：如果这些 Agent 高度同质，又采用差不多的方式更新自己的判断，那么讨论本身并不会神奇地把答案往正确方向推。
大家交换了大量文字，整体正确率在期望上可能原地踏步。
论文后来确实让 multi-agent debate 变好了，但用的方法很说明问题。
作者先刻意提高初始答案的多样性，让不同 Agent 真正拿着不同候选方案进场；随后又加入经过校准的 confidence，让 Agent 知道“这个人虽然说得很肯定，但他的置信度到底有多可信”。
效果才开始明显提升。
这里面有一个很重要的启示：
真正值钱的是差异，职位名称本身并不值钱。
把同一个模型复制五份，一个叫产品经理，一个叫架构师，一个叫研究员，只能制造表面上的角色差异。
如果五个人一开始想到的都是同一种方案，讨论再久也只是围着同一个坑转圈。
更麻烦的是，有些工作拆成多人协作以后，效果真的会下降
另一篇更有意思的论文叫《Towards a Science of Scaling Agent Systems》。
这篇论文没有停留在“multi-agent 好不好”这个问题上，它进一步测试了不同任务到底适不适合 multi-agent。
研究覆盖了单 Agent、多个 Agent 独立执行、中心化调度、去中心化协作和混合结构，而且控制了总计算预算。
结果非常极端。
在适合拆分的金融分析任务中，表现最好的 multi-agent 架构，相比单 Agent 提升了 **80.8%**。
可到了需要连续状态跟踪和严格顺序推理的规划任务，所有 multi-agent 架构都变差了，下降幅度达到 **39% 到 70%**。
这个结果我觉得比争论“单 Agent 和多 Agent 谁先进”有价值得多。
它说明 multi-agent 有没有意义，很大程度取决于一个特别朴素的问题：
这个任务到底能不能切开。
比如我要研究一家上市公司。
一个 Agent 看财报，一个查新闻，一个调查竞争对手，一个研究管理层，最后交给主 Agent 汇总。这种任务天然适合并行，因为四个人完全可以半小时不说一句话，各做各的。
但如果任务是开发一个完整功能，情况就复杂了。
数据库字段刚改，API 就要跟着改；API 一变，前端状态也要变；产品规则突然增加一个例外，测试逻辑又要重写。
这些步骤互相咬得很紧。
硬拆成五个 Agent，很可能出现一种真实公司里大家都讨厌的东西：
沟通成本。
只不过人类公司的沟通成本是开会、Slack、Jira 和需求文档，AI 公司的沟通成本变成了 token、上下文压缩、消息转述和状态同步。
人类用了几百年才发展出复杂的组织结构，是因为人的能力天然有限。
一个后端工程师通常不会同时负责视觉设计、法务审核、市场分析和财务建模。
大模型却很奇怪。
同一个 frontier model 本来就能写前端、写后端、设计数据库、做产品分析，顺手还能跑测试。
我们拿到这样一个东西以后，第一反应居然是按照人类公司的组织架构，再把它切回产品经理、程序员和 QA。
多少有点绕了一圈又回去了。
所以我怎么看 Grok Bot 和 Hermes Bot Mode？
我觉得它们都做了很多真正有价值的东西。
比如 Grok Bot 最吸引我的部分，其实是它的 computer。
根据 Grok Bot 官方介绍，Bot 可以长期运行在云端电脑里，登录真实业务系统，用浏览器、Terminal 和已有软件完成工作。电脑关掉以后，任务照样继续。
再看它的 Computer 文档，会发现这里还有一个很有意思的细节：同一个用户创建的多个 Bot 实际共享一台持久云电脑。文件、浏览器登录状态、CLI credentials 都能共享，每个 Bot 拥有自己的 screen，因此可以并行操作。
这个设计解决的是很现实的问题。
Agent 终于从“给你写一段建议”进化到了“进去把事情做完”。
Hermes 也一样。它的 Profiles 可以拥有各自独立的 memory、sessions、skills、API keys、cron 和 SOUL.md。Bot Mode 再把这些 profile 包装成一个个有名字的员工，让用户更容易管理。
这些基础设施都很有价值。
我怀疑的主要是另外一层：
把 Agent 做成员工，再让这些员工在一个群里像真人一样聊天，到底带来了多少额外能力？
目前看来，这部分的产品价值和能力价值并不对等。
从产品角度，它特别好。
一个 Agent 在后台跑三分钟，界面上只有一个 loading，用户会怀疑它是不是死了。
五个 Agent 在群里不停冒泡：
“我来检查一下 API。”
“发现一个问题，我交给后端处理。”
“已收到，我开始修复。”
“修复完成，请 QA 再检查。”
这就有一种办公室灯火通明、所有员工都在加班的感觉。
算力变成了看得见的劳动。
尤其在今天这种“别人已经开始运营 AI 公司，我是不是落后了”的焦虑下，左边摆二十个 AI 员工，心理冲击力远远超过一个孤零零的聊天框。
所以我觉得，“AI 办公室”这一层设计有很强的情绪价值。
情绪价值也属于产品价值，只是别顺手把它解释成集体智能已经出现。
不过，另一种“每人一个 Agent”，我反而非常看好
说到这里，有一个想法会让事情突然变得有意思起来。
前面讨论的 AI 办公室，是公司凭空创建五个虚拟员工：
1 | AI 产品经理 |
我最近越来越感兴趣的是另一种形态：
假设公司里本来就有 100 个真人员工，然后在每个人自己的工作电脑上，都常驻一个 Agent。
这个 Agent 不需要假装成“高级产品经理”或者“资深工程师”。
它只需要长期跟着这个人工作。
每天看他处理哪些文件，用哪些系统，负责哪些项目；知道他经常联系谁，习惯怎样写邮件，哪些事情需要向老板确认；理解他电脑里的项目结构，也逐渐积累这个人的工作记忆。
久而久之，它会变成这个真人员工的数字工作分身。
这件事情和前面的 AI 办公室有一个关键区别。
差异终于是真的了。
财务同事的 Agent 天天接触 ERP、报销系统和财务模型。
投资经理的 Agent 看的是访谈纪要、公司材料和 IC Memo。
工程师 Agent 长期泡在 GitHub、Terminal 和生产日志里。
HR 的 Agent 熟悉候选人、岗位和面试流程。
即使它们底层调用的是同一个模型，几个月以后，它们拥有的工作上下文、历史经验和权限边界都会完全不同。
这里的“多 Agent”终于出现了真正的异质性。
这种异质性不需要靠写五份 SOUL.md 演出来。
现实世界已经替我们完成了训练。
更妙的是，公司的权限体系也天然存在
今天做企业 Agent，有一个特别棘手的问题：
到底应该给它什么权限？
做一个“超级公司 Agent”，你很快会发现它需要访问 Slack、邮箱、CRM、数据库、财务系统、代码库、Google Drive……
权限越接越多，最后得到一个令人害怕的超级账号。
如果 Agent 跟着真人员工走，情况会自然很多。
公司原本就有一套权限体系。
工程师能看的代码库，他的 Agent 可以看；财务人员能打开的报表，他的 Agent 才能打开；普通员工没有付款权限，他的 Agent 同样没有。
换句话说：
人本身已经是公司的权限边界。
Agent 可以在这个边界里面活动。
当然，真正部署时还需要更细的限制。员工可以查看工资表，不代表 Agent 可以把工资表上传到外部网站；员工可以发邮件，也不代表 Agent 可以自主给全公司群发。
所以未来很可能出现一套“Agent 权限层”。
人的 RBAC 决定它能看到什么，Agent policy 再决定它能自动做到哪一步。读取也许自动允许，发送和修改需要更严格审批，付款、删除数据、发布生产环境则需要明确的人类确认。
相比让一个中央超级 Agent 拿着全公司的钥匙到处跑，我觉得这种架构自然得多。
但它也可能迅速变成企业监控的噩梦
每人一个常驻 Agent 的问题同样巨大。
最直接的就是隐私。
如果 Agent 真正长期驻扎在员工电脑上，它理论上可能看到邮件、聊天记录、本地文件、浏览器历史，甚至看到员工尚未发送的草稿。
这已经远远超过今天普通 SaaS 工具掌握的信息。
公司会不会要求管理员能够检索这些 Agent 的 memory？
员工离职以后，Agent 学到的东西归谁？
它知道一个人三年来是怎么工作的，这部分记忆算公司的知识资产，还是个人工作习惯？
如果员工电脑同时存在一些私人内容，Agent 怎么区分？
再往前想一步，问题会更尖锐。
老板很可能会发现，Agent 是一个完美的员工监控工具。
以前老板最多知道你几点上线、开了多少会议、提交了多少代码。以后可以直接问你的 Agent：
“他今天主要干了什么？”
甚至：
“过去半年，他有哪些工作实际上是别人替他完成的？”
如果企业把数字分身做成了一套全天候监控系统，员工很快就会想办法绕开它。
所以这套东西能不能成立，技术可能只是其中一半。
权限、数据所有权、可审计性，以及什么东西公司永远无权查看，会变得非常重要。
还有一个问题：千万别让一千个 Agent 天天在群里聊天
假设一家 1000 人的公司，每个人都有一个 Agent。
千万不要顺着今天的“AI 办公室”思路，建一个拥有 1000 个 Bot 的超级群聊。
那会是 token 版本的企业微信群灾难。
真正合理的方式很可能安静得多。
比如我要找法务确认一份合同。
我的 Agent 知道公司里谁负责这个业务，也知道对方 Agent 可以接受什么类型的请求。它把合同中的三个问题和相关上下文结构化发送过去。
法务的 Agent 在自己的环境中查询规定和历史合同，生成初步判断。
涉及真正法律决策的部分，再交给法务本人确认。
整个过程中，两边 Agent 完全没有必要寒暄：
“你好，我是 King 的数字助理。”
“很高兴认识你，我是 Alice 的法务 Agent。”
“好的，我先来看看这个问题。”
这些话全部都是 token 垃圾。
机器和机器之间最有效率的交流，很可能越来越不像聊天。
它应该更接近结构化任务、权限声明、证据引用、状态更新和结果返回。
人类看到的只是最后那一小段：
法务已确认，第 7.2 条存在风险，建议修改。Alice 已审核。
这才是我真正期待的 multi-agent。
Agent 不需要演人。
它只需要替人工作。
如果沿着这个方向走，未来的公司可能很有意思
我现在反而觉得，未来几年更现实的“AI 公司”，可能和今天很多 Demo 展示的样子差别很大。
今天大家想象的是：
1 | 1 个真人老板 |
老板打开一个类似 Slack 的界面，下面一群数字员工忙来忙去。
我越来越觉得，另一种形态可能先大规模出现：
1 | 100 个真人员工 |
组织架构依然是人的组织架构。
只是每一个节点都变成了：
Human + Agent。
一个优秀投资人背后有一个跟了他三年的研究 Agent。
一个工程师旁边有一个熟悉整个代码历史的 coding agent。
一个销售身边有一个知道所有客户上下文、每天主动整理跟进事项的销售 Agent。
人与人之间仍然负责判断、谈判、信任和最终责任；大量信息搜集、准备工作、重复操作和跨系统搬运，逐渐沉到各自 Agent 身上。
这时候公司甚至不一定需要一个无所不能的“中央 AI 大脑”。
中央系统负责身份、权限、协议和审计就够了。真正的智能分散在每个员工身边。
从计算机架构上看，它反而有一点像分布式系统。
每个人都是一个节点。
每个节点拥有自己的本地状态、专业上下文和权限。
需要协作的时候交换必要信息，完成以后继续保持独立。
有趣的是，这种架构恰好绕回了前面两篇 multi-agent 论文讨论的核心。
Multi-agent 真正可能产生收益的地方，本来就来自独立的信息源和可以并行处理的任务。
到了“每个真人员工都有一个 Agent”这个世界，这两个条件突然都满足了。
不同 Agent 看到的世界真的不同。
他们负责的工作也真的不同。
这时再让几个 Agent 协作，和给 GPT 复制五份人格文件，已经完全是两回事了。
所以，我依然不太相信今天的“AI 办公室”
如果一个产品告诉我：
我们创建了产品经理、架构师、程序员、设计师和 QA，五个 Agent 会像真人公司一样在群里协作。
我第一反应还是会问：
为什么需要五个？
它们掌握了什么彼此不同的信息？
有没有真正独立的搜索和判断？
任务能不能并行？
各自是否拥有不同工具和权限？
最终结果由什么东西负责验证？
把姓名和头像全删掉以后，它是否依然比一个强 Agent 更好？
如果这些问题都回答不了，那么所谓 AI 团队大概率只是把一个 Agent 的工作步骤，外显成了一场办公室情景剧。
它确实更有戏剧性，更适合 Demo，也更容易让人产生“我已经领先别人一个时代”的满足感。
可真正值得期待的 multi-agent，可能没有那么热闹。
它甚至没有一个所有 Agent 都在里面说话的大群。
每个 Agent 安静地待在自己的工作环境里，拥有真正不同的数据、权限和经验。需要的时候互相调用，完成以后把决定权交回真人。
那时候，我们也许真的可以说，一家公司里出现了一层新的数字组织。
只是它看起来大概不会像《办公室》。
更像 Unix。