从1个到10个智能体，EMOOSearch这套系统算是我带着团队一路从零搭起来的。最早只是给客服团队做的一个问答机器人，后来不知不觉就变成了十个各司其职的数字员工，分散在运营、研发、市场、财务各个角落。说实话，当第十个智能体上线那一刻，我最大的感受不是“我们真厉害”，而是“这下麻烦大了”。因为多智能体协作真正难的地方，从来不是把每个智能体单独调好，而是让它们在一起干活时不打架、不空转、不互相甩锅。

这篇文章我就用EMOOSearch的真实落地过程当主线，聊聊我们是怎么从1个智能体走到10个智能体，中间踩了哪些坑，最后又是怎么靠一套编排逻辑把场面稳住的。如果你也在犹豫“到底该不该上多智能体”，或者已经被一堆智能体搞得焦头烂额，这篇内容应该能帮你少走不少弯路。

1. 从1个到10个：EMOOSearch是怎么开始失控的

1.1 第一个智能体带来的“能力幻觉”

EMOOSearch的第一个智能体，出发点特别朴素。当时客服团队每天要回复大量重复问题，人力根本顶不住，我们想着做一个“智能问答机器人”能不能分担掉60%的常见问题。于是花了大概两周时间，接了大模型API，搭了知识库，写了一套检索增强生成的流程，把产品手册、FAQ、历史工单全部灌进去。

上线之后效果确实惊艳。第一周就扛掉了大约45%的重复咨询，用户根本分不清对面是机器人还是真人。老板很开心，客服团队也很开心，但问题也随之而来：大家开始默认“AI什么都能做”。

这就是我所说的“能力幻觉”——当一个智能体在某件事上表现得足够好，业务方就会天然地认为它能在别的事情上也表现好。很快就有销售团队来问：“能不能让这个机器人帮我们写客户跟进邮件？”有市场团队来问：“能不能让它自动生成小红书文案？”甚至有财务来问：“能不能让它帮我们对账？”

每一个需求单独看都很合理，但如果你真的把一个客服问答机器人拿去写邮件、写文案、对账，结果可想而知：它可能会用客服话术去回复商务邮件，或者在财务数据里凭空编出一笔不存在的流水。我后来总结了一句话：单智能体做对一件事很容易，做对很多件事几乎不可能。

1.2 数量膨胀的三个真实原因

EMOOSearch之所以从1个膨胀到10个，不是因为我们拍脑袋想“多就是好”，而是三个非常现实的原因逼着我们不断加码。

第一个原因是数据权限隔离。客服机器人为了提高回答质量，我们给它接入了大量客户工单数据。但市场团队如果也用它来写文案，它就可能在文案里引用客户的隐私信息，这是合规上绝对不允许的。于是我们不得不单独做一个市场文案智能体，把它的知识库限定在品牌资料、产品卖点和合规清单里。第二个原因是提示词冲突。不同业务方对同一个模型的要求是完全不同的。客服场景要求语气温和、简洁、不承诺；研发场景要求逻辑严密、有代码规范；财务场景要求严格按模板输出、不允许自由发挥。把这些要求塞进同一个系统提示词里，模型会变得“精神分裂”。第三个原因是考核指标不同。客服看的是解决率，市场看的是转化率，研发看的是代码通过率。指标不一样，你就没办法用一个通用的智能体去满足所有的评价体系。

所以到第三个月的时候，EMOOSearch已经自然生长出了五个智能体。我当时的感受特别像家里养猫：你养了一只之后，很快就会养第二只、第三只，因为你觉得“反正都养了，再多一只也没什么”。直到它们开始满屋子乱跑，你才发现事情没那么简单。

1.3 10个智能体的“马戏团效应”

等到第十个智能体上线，我们内部管这叫“马戏团效应”——看起来热闹，其实混乱。具体表现在几个方面。

首先是互相不知道对方的存在。财务智能体需要市场部的预算数据，但它不知道该去找谁要，于是只能自己“猜”，猜出来的数据经常和真实数据对不上。其次是同一个任务被多个智能体重复执行。有一次客户投诉一个技术问题，客服智能体、技术支持智能体、研发助手居然同时接到了这个任务，并且各自生成了一份处理方案，三份方案之间的说法还有矛盾。最后是上下文混乱。智能体A在和用户对话时，把智能体B的一段输出当成了事实依据，结果导致一整段回答全部跑偏。

我还记得第十个智能体上线的那天，我盯着系统后台的调用日志，发现智能体之间的消息有73%都花在“互相确认信息”上，真正干活的只有27%。那一刻我就知道，多智能体的核心矛盾不是“生成能力不够”，而是“协作效率太低”。

2. 十智能体的分工蓝图：我是怎么排兵布阵的

2.1 按“岗位”而非“技术”拆分

尝到混乱的苦头之后，我们停下来重新思考一个问题：这十个智能体到底该怎么划分边界？一开始我们按技术能力拆，比如“一个负责文本生成，一个负责数据分析，一个负责代码”。但很快就发现这个拆法根本不好用，因为业务方根本不管你是文本还是数据，他们只关心“帮我解决什么问题”。

后来我们换了一种思路：按岗位拆。每个智能体模拟企业里的一个真实角色，有明确的职责边界、输入输出格式和协作关系。用一句通俗的话讲，你不是在搭一套AI系统，你是在组建一支数字团队。每个智能体就是一个数字员工，它要有自己的KPI、自己的知识范围、自己的协作流程。

这个改动非常关键。按技术拆，你得到的是十个“能力很强但不知道干什么”的工具；按岗位拆，你得到的是十个“知道自己该干什么、不该干什么”的员工。后者的管理成本远低于前者。

2.2 EMOOSearch的十角色架构

经过三轮调整，我们最终确定下EMOOSearch的十个核心角色，这里列出来供参考：

这十个角色并不是一开始就全想好的，而是根据实际需求一步步加出来的。但有了这张表之后，最大的变化是：任何一个新需求进来，我们首先会判断“这活该归谁管”，而不是“再训一个智能体试试”。

2.3 协作关系和消息流转规则

角色分好了，下一个问题是：它们之间怎么协作？我们给EMOOSearch定了一套“消息流转规则”，简单说就是：

• 每个智能体有自己的“收件箱”，其他智能体通过参数调用向它发送任务。
• 每个任务必须包含三个字段：目标角色、任务描述、预计产出格式。
• 收到任务的智能体必须在规定时间内回复“接收”或“拒收”，拒收时需要给出原因。
• 所有跨智能体的消息都要经过一个“编排调度层”，不能直接点对点私聊。

为什么要加调度层？因为如果不加，智能体之间就会形成一个完全网状的结构。A找B、B找C、C又找A，消息路径完全不可控。加入调度层之后，所有消息都变成了“广播—响应”模式：谁有能力处理，谁就接收；没有能力的，直接拒收，消息自动转给下一个合适的角色。

这个改造上线之后，系统的无效消息率从73%直接降到了34%。逻辑很简单：以前是“所有人都收到消息，大家七嘴八舌”，现在是“按规则派单，只有对的人才会处理”。

2.4 系统提示词设计的核心原则

岗位和协作定了之后，每个智能体的系统提示词也需要重构。最开始我们每个智能体的提示词都洋洋洒洒写了两三千字，后来发现越长越笨。

我们把每个智能体的系统提示词压缩成四段：

第一段：角色定位，一句话说清楚你是谁。比如“你是财务核对智能体，负责审核报销单据和预算比对”。第二段：核心规则，最多列五条铁律，比如“所有金额数字必须从财务数据库读取，禁止自行推断”。第三段：协作边界，说清楚你接受谁的指令、产出交给谁。第四段：输出模板，限定格式和语气。

这四段加在一起，控制在500到800字以内。不要试图把所有业务规则都塞进提示词里，规则应该放在知识库和工具层，提示词只需要告诉模型“你是什么角色、底线是什么、活干完交给谁”。我们试过把规则写得特别细，结果模型变得极其保守，什么都不敢干，一个简单判断都要反复确认，效率反而更低。

3. 让10个智能体真正协作的落地细节

3.1 编排层比模型层更重要

很多人一听多智能体，第一反应是“要用最强的模型”，第二反应是“每个智能体要单独微调”。实际上对大多数企业来说，这两件事都不是最优先的。我们EMOOSearch踩过坑之后得出的结论是：编排层的设计比模型层重要得多。

什么叫编排层？就是负责“调度、路由、状态管理、工具调用”的那一层。你可以把它理解成企业里的项目经理：模型层是干活的人，编排层是分配活、检查活、验收活的管理者。没有管理者，十个干活的人只会各干各的，产出没法对齐。

我们用的方案是在开源框架的基础上自己封装了一套，内部代号就叫“调度中心”。它维护了一张全局任务表，记录每个智能体当前正在处理什么、已经完成了什么、还需要等谁的输入。每当一个新任务进来，调度中心会根据“职责表”和“资源负载情况”，决定把它派给谁，而不是让模型自己决定。

这个层的代码量不算大，但非常关键。它解决了两个核心痛点：一是任务不重不漏，二是进度可追踪。有了它，我们才能在系统出问题的时候准确回答“这个活现在卡在哪个环节”。

3.2 工具注册与权限边界

十个智能体背后对应着至少二十个工具调用：查订单、查库存、发邮件、生成图片、读数据库、写工单……如果每个智能体都能调用所有工具，那权限就形同虚设。我们给每一个工具都做了“允许调用角色”的配置项，类似于给它装了一把锁，只有拿着匹配钥匙的智能体才能打开。

这一步技术上不复杂，但需要业务方和开发方一起坐下来梳理清楚。梳理的标准很简单：**这个工具的数据敏感程度，决定了谁能碰它。**比如财务数据库只有财务核对智能体能读，客服助手只能通过“查订单状态”这个接口去间接获取信息，拿不到全量数据。

工具注册的另一个细节是“参数校验”。每个工具定义好之后，我们加了一层校验规则，比如订单号必须是数字、日期不能早于今天、金额不能为负数。校验能拦截掉一部分模型幻觉产生的脏数据，别小看这一层，它让我少掉了不少头发。

3.3 知识库隔离与共享策略

十个智能体，知识库不能只有一份。我们按“私有库+共享库”的方式管理。

每个智能体有一个私有知识库，只存放跟自己岗位强相关的资料。比如客服助手的私有库是FAQ和售后政策，市场文案的私有库是品牌调性和爆款案例。这样做的目的是让每个智能体在回答问题时先看自己的私有库，减少无关信息对回答的干扰。

共享库则是所有智能体都能读取的“公共常识”，包括公司介绍、组织架构、系统使用手册等。共享库的内容不需要多，但必须足够权威。我们特别定了一条规矩：共享库里的任何一条信息变更，都要经过“知识管理官”审核，其他智能体没有直接修改权限。

这种隔离策略还有一个额外的好处：出现信息冲突时，排查起来很容易。某智能体回答错了，第一件事就是看它是不是读到了自己的私有库以外的东西，80%的问题出在这。

3.4 记忆管理：短期记忆、长期记忆与全局记忆

多智能体的记忆系统，我一开始天真地以为各家智能体自己记自己的就行。后来发现完全不行。比如用户上周和客服助手聊了一个订单问题，这周又来问进展，客服助手如果记不住上周内容，整个对话体验就会断裂。

EMOOSearch的记忆分成三层：

第一层是短期记忆，存在于单次任务内部，任务结束就清空，用于保证一段连贯对话里的上下文不丢。第二层是长期记忆，每个智能体各自维护，记录它和用户之间的历史互动摘要，比如“该用户上次投诉过物流慢，偏好电话沟通”。第三层是全局记忆，放在数据库里，记录跨智能体的信息，比如“某客户当前有一个未完结工单”，供所有相关智能体查询。

全局记忆要特别小心，搞不好会变成“谣言的温床”。我们给它设置的权限是：只记录事实性结论，比如“工单状态=待处理”，不记录推测性内容，比如“该客户可能要流失”。推测性内容的准确率太低，传着传着就变味了。

4. 我在EMOOSearch上线后踩过的坑

4.1 两个智能体互相“踢皮球”的死循环

最让我崩溃的一次是系统上线后第二周，客服助手接到了一个用户投诉，它判断这是技术问题，于是把任务派给了技术支持。技术支持处理完之后，又把结果发给了客服助手，让它去回复用户。结果客服助手的提示词里有“凡是技术类回复，统一由技术支持直接输出”，于是它又把活推了回去。技术支持那边又说“最终用户沟通应由客服完成”，两边你来我往，整整空转了四十分钟，用户一个问题都没解决。

问题出在哪？出在没有给任务流转设置“终止条件”。后来我们在调度中心里加了一条规则：**同一个任务在智能体之间的流转次数不允许超过三次。**超过三次，系统自动升级给人工处理，同时把整个流转链路记录下来当复盘材料。加了这条规则之后，类似的死循环基本消失了，因为流程会在失控之前被人为掐断。

4.2 幻觉不在生成端，而是出现在“工具调用”端

以前聊幻觉，大家关注的都是模型会不会编造事实。EMOOSearch实际跑起来之后，我发现真正麻烦的幻觉是“工具幻觉”——模型确实没编话，但它调错了工具。

举个例子：运营分析智能体需要统计某个商品的退货率。它拿到商品ID之后，应该去调用“订单明细查询”，但它偏偏去调用了“商品评价汇总”。两个工具返回的数据结构完全不一样，模型自己没发现，直接拿评价数当退货数算，然后一本正经地生成了一份错误报表。

后来我们在编排层加了一个“工具意图校验”：模型在发起工具调用之前，必须先用一句自然语言说明“我要用这个工具解决什么问题”，调度中心会校验这个意图和工具的功能描述是否匹配，匹配度不够的直接拦截。这个改动让工具幻觉导致的错误数据下降了85%。

4.3 提示词越写越长，智能体越来越“怂”

有一个阶段，我们为了让每个智能体更专业，在提示词里加了一大堆限制条件：不许猜测、不许自由发挥、所有数据必须有来源、语气要正式等等。结果模型的输出确实更“安全”了，但也变得特别机械，动不动就“根据现有信息，我无法做出判断”，连一个最基础的简单问题都要折腾半天。

后来我意识到一个道理：**提示词里的每条规则，都会让模型变得更保守。**规则越多，它在每一个输出节点都要做更多的“合规检查”，推理变慢、灵活性下降。那些必须遵守的规则，应该尽量下沉到工具层去硬校验，比如数据格式、权限范围这些，用代码去判断比用模型自己判断可靠得多。留在提示词里的，只要角色定位、协作边界、输出模板就够了。

4.4 监控面板不是用来看的，是用来“找异常”的

系统刚搭好的时候，我们做了一个很漂亮的监控面板，实时滚动显示每个智能体的调用次数、平均延迟、token消耗。一开始大家每天围观数据变化，过了一周就觉得没劲了，因为这些指标好看不代表系统协作得好。

后来我们把监控重心从“资源指标”转向“质量指标”：异常任务占比、任务流转次数分布、拒收率、超时率、人工升级率。发现一个智能体的“拒收率”长期偏高，追查下去发现它的职责定义太模糊，经常收到不属于它干活的请求。填过坑之后，我才意识到监控面板的意义不是“跑起来的时候能看到数据”，而是“跑挂了之后能快速定位是谁出了问题”。

5. 一些经验沉淀与后续建议

5.1 好用的协作编排思路：先把“流程”画在纸上

有人问我EMOOSearch最值得推荐的工具是什么，我的回答可能让人意外：一支笔和一张白纸。在写第一行代码之前，我们花了两天时间把十个智能体之间的所有协作关系画成了流程图：谁发起任务、谁接收、产出交付给谁、异常时升级到哪一级。

这个环节看起来没有技术含量，但它决定了系统最终的秩序。代码写错了可以改，流程画错了是推倒重来。我见过不少团队一上来就接开源框架、写智能体代码，搞了两个月还没跑通，原因就是流程没有先在纸面上理顺。

5.2 智能体不是越多越好，边界清晰才是关键

十个智能体是我们目前的规模，但这不是标准答案。如果你的企业只有二十个人，硬上十个智能体只会让系统变得比组织本身还复杂。合适的数量应该取决于三个前提：业务场景是否足够多样、数据权限是否必须隔离、评价指标是否各不相同。只要这三个前提里有任何一个不满足，你用两个智能体就好过用十个。

另外一个心得是：与其不断加新智能体，不如先优化现有智能体。很多时候业务方提出的新需求，并不是“现有智能体干不了这个活”，而是“他不知道现有智能体能干这个活”。这时候补一句培训、写一份使用说明，效果比新增一个角色更好。

5.3 团队角色变化：人人都是智能体的“训练师”

EMOOSearch落地到后期，我们团队内部的角色也悄悄发生了变化。以前是开发人员写代码、业务人员提需求，中间隔着一道墙。现在是业务人员要参与到提示词撰写、知识库维护、异常工单复盘里来。开发人员的工作重心则从“写智能体逻辑”慢慢转向“写编排规则和工具接口”。

换句话说，多智能体系统稳定之后，真正花时间的不再是“让AI变聪明”，而是“让AI不犯错、守住边界”。业务人员最懂边界在哪，所以他们应该成为智能体的“训练师”。我之前看到某公司甚至为此专门设置了“AI行为训练师”这个岗位，薪资不低，我当时还不理解，现在回想起来，EMOOSearch走到第十个智能体的时候，我最需要的恰恰是这样的人。

5.4 下一个阶段：从“十个人”到“一个组织”

十个智能体的配合跑顺之后，我们开始琢磨另一件事：怎么让它们像一个真正的组织那样运作，而不是永远停留在“被调度”的层面。比如当运营分析发现某个品类的退货率连续七天超过阈值时，它能不能主动发起一次跨智能体的专项任务，而不需要人工在后台配置流程。

这个方向听上去很美好，但技术上和管理上的挑战都不小。技术上需要让智能体具备“发起任务”的权限，这就回到权限边界的问题；管理上需要回答一个问题：如果AI主动发起的任务出了问题，责任在谁？这些问题还没有标准答案，我们也在摸索。但我很确定一点：单智能体解决单点问题，多智能体解决系统问题，而系统问题永远比单点问题更值得投入思考。EMOOSearch的故事还在继续，它已经帮我们处理了上万次客户请求，也让我重新理解了什么叫“数字员工”。