企业 Agent 的终局，可能不是一支 AI 团队
原文作者：Mocha · 原文来源：今日头条
本文为作者本人文章的站内同步版本。
很多企业开始搭建 Agent 后，做的第一件事，往往是给它们分工。
有人负责产品，有人负责研发，有人负责数据，有人负责客服，还有人负责测试和运营。
这些 Agent 拥有不同的名字、头像和岗位说明，像极了一家由数字员工组成的新公司。
这种设计很容易获得管理者的认可。
因为它足够熟悉，也足够直观：现实公司有多少部门，就给 AI 配多少角色；现实工作如何流转，Agent 就按照同样的方式协作。
但问题恰恰出在这里。
我们可能只是把人类公司的组织结构，原封不动地搬进了 AI 系统。
连同被搬进去的，还有跨部门沟通、信息转述、任务交接和上下文丢失。
越来越多走在前面的公司，已经开始反思这种思路。
Sierra 将原本分散的多个 Agent 逐渐整合为统一入口；Anthropic 让 Claude 以一个持续存在的身份进入团队协作场景；Shopify 的 River 也不是某个部门专属的机器人，而是服务于整个组织的公共 Agent。
它们的业务并不相同，内部工具和工作方式也不一样，却不约而同地走向了同一个方向：
不再要求员工管理多个 Agent，而是让一个 Agent 管理背后的多种能力。
Agent 越多，员工的负担可能越重
多 Agent 方案看上去很合理。
不同角色负责不同专业任务，既符合分工逻辑，也方便企业根据部门逐步落地。
但这种方案有一个隐藏前提：
员工必须知道，每个问题究竟属于哪个 Agent。
这在简单任务中并不困难。
查询销售记录，可以找销售 Agent；修改代码，可以找研发 Agent；分析数据，可以找数据 Agent。
可企业中真正有价值的问题，通常不会严格属于某一个岗位。
例如：
新版本上线后，退款率突然上升，请找出原因并完成修复。
这件事首先需要确认产品版本发生了哪些变化，然后检查退款指标的变化范围，再结合客服反馈判断问题集中在哪些用户身上。
如果问题与系统逻辑有关，还要继续进入代码仓库、生产日志和测试环境，最终验证修复结果。
这不是一个数据问题，也不是一个研发问题。
它是一件需要多个专业能力共同完成的事情。
按照传统的多 Agent 架构，这项任务很可能被拆成若干部分：
产品 Agent 整理版本背景，数据 Agent 查询指标，客服 Agent 提取用户反馈，研发 Agent 排查代码，测试 Agent 验证结果。
流程本身并没有错。
真正的问题在于，每一次任务转交，都需要重新描述背景。
数据 Agent 未必知道产品团队为什么怀疑某次版本更新。
研发 Agent 收到的，也可能只是经过整理和压缩的数据结论。
如果客服 Agent 在中途发现了新的用户反馈，又需要把信息重新传回前面的环节。
最终，员工不仅要提出问题，还要承担额外的协调工作：
决定找谁、整理背景、转发结论、跟踪进度，并在任务偏离时重新指定负责角色。
表面上，企业拥有了一支各司其职的 AI 团队。
实际运行起来，却可能变成了一套更快、更自动化的转述系统。
三家公司的共同选择：让 Agent 成为一个身份
Sierra 早期同样尝试过多个角色 Agent。
不同 Agent 分别承担客户服务、数据分析、工程和销售等任务，岗位边界清楚，使用场景也容易理解。
但随着任务复杂度增加，这种边界逐渐变成了阻力。
员工需要先判断问题应该交给谁；一旦任务跨越多个领域，还需要在人和多个 Agent 之间反复同步信息。
后来，Sierra 将这些能力逐步合并到统一 Agent 中。
员工只需要面对一个 Slack 入口。
至于任务需要查询数据、查看代码、调用业务系统还是进入其他工具，由 Agent 在后台自行判断。
Anthropic 对 Claude 的内部使用，也体现了类似的思路。
Claude 并没有被拆成研发版、销售版、数据版和客服版。
它以统一身份进入 Slack 频道，直接参与团队原本的讨论。
员工可以在正在进行的对话中调用它，它会读取当前线程中的背景，理解团队已经讨论到哪一步，再连接被授权的工具继续完成任务。
同一个 Claude，既可以参与代码工作，也可以查询指标、处理工单和协助排查复杂故障。
Shopify 的 River 则进一步强调了 Agent 的公共属性。
River 存在于公司的共享协作空间中，可以查看代码、运行测试、查询数据、检查生产日志，甚至协助提交代码修改。
一个人发起任务后，其他成员也可以进入原有线程继续补充信息、提出约束或纠正方向。
Agent 不会因为提问者发生变化，就把任务重新开始一遍。
这三个案例真正值得关注的，不是它们用了什么名字，也不是背后接入了多少模型。
而是它们开始把 Agent 从“岗位工具”变成“组织身份”。
员工不必记住每种能力分别属于谁，只需要记住一个可以持续协作的入口。
企业需要的不是角色分工，而是任务连续性
在统一 Agent 模式下，工作方式会发生明显变化。
面对退款率上涨的问题，员工不再需要先把任务拆成五份。
只需要完整地提出目标：
找出新版本上线后退款率上涨的原因，并推动问题解决。
接下来，同一个 Agent 可以沿着任务自然向前推进。
它先读取相关产品讨论，确认版本变更；再进入数据系统，分析退款指标；随后调取客服记录，寻找集中出现的用户反馈；如果判断与技术问题有关，就继续查看代码和生产日志，并在修复后完成测试。
整个过程中，能力可以不断切换，但任务主体不需要切换。
从系统内部看，它依然可能调用数据分析模型、代码 Agent、测试工具或者其他专业工作流。
但从员工的视角看，协作对象始终没有改变。
任务仍在同一条线程中推进，历史信息不会因为能力切换而被重新压缩，新的参与者也可以在原有上下文上继续工作。
这是一种完全不同的设计重点。
传统多 Agent 架构关注的是：
谁负责哪一步。
统一 Agent 架构关注的则是：
一件事如何不间断地被推进到完成。
对企业而言，后者往往更加重要。
人类需要部门，AI 未必需要
公司之所以形成部门，并不是因为部门天然就是最高效的组织方式。
根本原因在于，人类个体的能力和精力都有限。
一个人不可能同时精通销售、产品、研发、财务、法务、客服和数据分析。
企业只能通过专业分工，把复杂工作拆给不同的人，再通过会议、文档、审批和管理流程重新组合。
换句话说，组织结构本身就是人类应对能力边界的一种方式。
但 Agent 面临的限制并不完全相同。
它可以同时连接知识库、数据库、代码仓库、客服系统和办公平台，也可以在一个任务中连续调用不同工具和模型。
当能力可以被实时调度时，提前把 Agent 固定成某个部门角色，未必仍然是最合理的做法。
如果我们先把 AI 拆成产品 Agent、研发 Agent、数据 Agent，再让它们按照人类公司的方式互相沟通，就等于让 AI 继承了人类组织中最昂贵的部分：
信息壁垒、任务交接和管理成本。
这并不意味着企业不再需要专业能力。
恰恰相反，后台的专业分工可能会越来越细。
不同模型负责不同任务，专业 Agent 处理特定流程，代码在隔离沙箱中运行，高风险操作需要人工审批，权限系统负责限制数据访问。
只是这些复杂性，不应该直接暴露给员工。
员工不需要知道一次任务背后调用了几个模型、进入了多少系统、启动了多少子 Agent。
就像我们使用搜索引擎时，不需要理解它背后的索引、排序和分布式计算。
好的系统，应该把复杂能力留在后台，把简单交互留给用户。
多 Agent 不会消失，只会退到后台
统一入口并不等于单模型，也不意味着所有事情都由一个 Agent 独立完成。
复杂企业任务往往需要多种执行机制。
数据分析可以由专门的查询工具完成，代码修改可以交给工程 Agent，测试可以进入隔离环境，法务和财务环节也可能需要独立的审核工作流。
多 Agent 仍然会存在。
但它更适合作为系统的内部架构，而不是面向员工的产品界面。
前台的 Agent 负责理解目标、维护上下文和协调进度。
后台的模型、工具和子 Agent 负责完成具体动作。
员工面对的是一个完整任务，系统内部处理的是一组复杂步骤。
这两者不应该混为一谈。
如果员工每天都要决定调用哪个 Agent、如何在 Agent 之间传递结果、什么时候补充上下文，说明系统仍然把过多的组织成本留给了人。
企业真正应该设计的，是公共入口
当企业开始规划 Agent 时，最先讨论的往往是部门。
销售部配什么 Agent，研发部配什么 Agent，客服部是否需要独立模型，运营部应该设计几个角色。
但如果按照统一 Agent 的思路，问题应该换一种问法。
企业需要先回答：
这个 Agent 在组织中究竟是什么身份？
它是一个临时问答工具，还是一个可以长期协作的成员？
它应该存在于独立平台，还是进入员工原本使用的 Slack、飞书、Teams、邮件和业务系统？
它能够看到哪些信息，又如何根据员工身份和任务范围继承权限？
它可以调用哪些系统，哪些操作必须经过审批？
一项任务被暂停或执行环境被销毁后，它是否仍然保留完整的状态？
不同员工加入同一任务时，能否继承此前的讨论、证据和判断，而不是重新从头说明？
这些问题比“要创建多少个 Agent”更加关键。
因为企业 Agent 最终竞争的，未必只是模型能力。
真正决定它能否进入日常工作的，是它能不能成为一个可靠的组织入口：
有稳定身份，有持续上下文，有明确权限，也有把事情推进到结果的能力。
总结一下
企业对新技术的第一反应，通常是用旧世界的结构理解它。
电脑刚刚进入办公室时，人们把纸质文件搬进了电子文件夹。
互联网出现后，很多公司只是把线下流程搬到了网页上。
如今 Agent 进入企业，最自然的做法，仍然是把原有组织架构复制一遍。
现实中有产品经理，就创建产品 Agent；有数据分析师，就创建数据 Agent；有研发工程师，就创建研发 Agent。
这种方式容易落地，也容易展示，却未必真正发挥了 Agent 的价值。
未来成熟的企业 Agent，可能不会表现为一间坐满虚拟员工的办公室。
它更像一个贯穿组织的公共身份。
员工只需要说明目标，Agent 负责理解背景、组织能力、调用系统，并让任务持续向前。
从员工面前看，只有一个入口。
从系统背后看，却连接着整个企业。
Agent 的未来，可能不是复制一家公司的组织结构。
而是把整家公司的能力，收进同一个协作入口。