从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的十个核心角色这里列出来供参考角色核心职责主要对接方关键数据权限客服助手处理售后咨询、退货退款用户、工单系统CRM、订单数据工单分诊员识别问题类型并派发工单客服助手、技术支持工单池技术支持解决技术类故障排查工单分诊员、研发助手日志、监控数据研发助手代码审查、技术方案生成研发团队代码仓库市场文案生成推广文案、活动方案市场团队、设计助手品牌资料库设计助手生成海报草图、UI建议市场文案、运营设计素材库运营分析输出日/周/月数据报表运营团队、财务数据仓库财务核对报销审核、预算比对运营分析、管理层财务数据库招聘助理简历初筛、面试安排提醒HR团队候选人库知识管理官更新和审核知识库内容全部智能体全库读写权这十个角色并不是一开始就全想好的而是根据实际需求一步步加出来的。但有了这张表之后最大的变化是任何一个新需求进来我们首先会判断“这活该归谁管”而不是“再训一个智能体试试”。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的故事还在继续它已经帮我们处理了上万次客户请求也让我重新理解了什么叫“数字员工”。