1. 为什么一个人需要一支 AI 团队去年年底我接手了一个智能客服知识库的迭代项目需求方给的时间是两周要完成意图分类、多轮对话、知识检索、回复生成、质量抽检五个模块。按传统做法这至少是一个三人小组干一个月的活。我当时手上只有自己一个人还有一堆日常运维要盯。硬扛肯定扛不住于是我把这五个模块拆开每个模块交给一个专门配置的智能体去跑我自己只做编排和验收。结果两周不到就交付了而且后续维护成本比我预想的低得多。这就是我理解的“一个人的 AI 团队”——不是让一个万能智能体包打天下而是像带一个小团队一样给每个智能体明确岗位、明确输入输出、明确交接规则然后自己当那个项目经理。多智能体协作这个词听起来很唬人但落到实操层面它解决的就是一个很朴素的问题单个智能体的上下文窗口有限、能力边界模糊、任务一复杂就开始胡说八道。拆成多个各司其职的智能体之后每个智能体的提示词可以写得更聚焦输出格式可以卡得更死出错时也更容易定位是哪个环节崩了。这篇文章适合两类人看。一类是已经在用单个智能体做事情但发现稍微复杂一点的任务就力不从心的朋友另一类是想搭智能体但不知道从哪下手被各种框架名词绕晕的新手。我会用我自己那套客服知识库项目作为主线把五个智能体的分工、协作机制、踩过的坑全部摊开讲。你不需要有很深的编程基础但需要对提示词工程有一点基本概念知道什么是系统提示、什么是结构化输出。先说结论这套方案的核心不在于用了多高级的框架而在于分工的颗粒度和交接的协议设计。框架只是壳真正决定成败的是你怎么定义每个智能体的职责边界以及它们之间怎么传话。下面我从整体设计思路开始拆。2. 五个智能体的岗位设计与选型逻辑2.1 为什么是五个而不是三个或十个一开始我其实只想拆三个一个负责理解用户问题一个负责找答案一个负责组织语言回复。跑了两天就发现不行。问题出在两个地方第一找答案这个环节既要判断知识库里的内容相不相关又要决定用哪几条来拼答案两个判断混在一起准确率掉得厉害第二回复生成之后没有人把关偶尔会冒出一些语气生硬或者信息遗漏的回复我得一条条人工看反而更累。于是我把“找答案”拆成了检索和筛选两个角色又在最后加了一个质检角色。五个智能体的分工是这样的智能体编号岗位名称核心职责输入输出Agent-1意图识别员判断用户问题属于哪类业务、是否需要转人工用户原始问题意图标签 置信度Agent-2知识检索员从知识库中召回候选答案片段意图标签 原始问题候选片段列表带来源Agent-3答案筛选员从候选片段中挑出最相关的几条并排序候选片段列表精选片段带排序理由Agent-4回复撰写员根据精选片段组织成自然语言回复精选片段 用户问题草稿回复Agent-5质量检查员检查草稿的事实性、语气、完整性草稿回复 精选片段通过/打回 修改意见这个数量不是拍脑袋定的。我的经验是一个智能体只做一件事且这件事能用一句话说清楚。如果某个智能体的职责描述里出现了“并且”“同时”“或者”这种连接词就说明该拆了。五个是我这个场景下的自然结果换成写代码、做数据分析、搞内容创作数量可能不一样但拆分逻辑是一样的。2.2 每个智能体的提示词怎么写才不打架拆分之后最大的坑是提示词冲突。比如意图识别员如果写得太宽泛它会把“你们家产品怎么退款”和“退款政策是什么”当成两类意图导致后面的检索员无所适从。我的做法是给每个智能体写提示词时严格遵守三条规则。第一条只写这个岗位需要知道的事。意图识别员的提示词里绝对不出现知识库的结构信息检索员的提示词里绝对不出现回复格式的要求。信息隔离做得好每个智能体的注意力就集中输出稳定性明显提升。第二条输出格式用 schema 卡死。我不指望智能体“自觉”输出规范格式而是直接在提示词里给出 JSON schema并且要求它只输出 JSON不要任何解释性文字。比如意图识别员的输出我要求长这样{ intent: 退款咨询, confidence: 0.92, need_human: false }这样下游的检索员拿到的是一个确定的结构不用再去解析自然语言省掉了一层不确定性。第三条给每个智能体设定明确的“不知道”策略。这是很多人会忽略的一点。意图识别员如果遇到完全无法分类的问题不能瞎猜一个标签而要输出intent: unknown触发转人工流程。检索员如果召回为空要输出空列表而不是硬凑几条。把“不知道”当成一种合法输出整个系统的容错性会好很多。2.3 协作模式选型流水线还是辩论式多智能体协作常见的模式有两种。一种是流水线式Agent-1 的输出给 Agent-2Agent-2 的输出给 Agent-3一路传下去。另一种是辩论式多个智能体对同一个问题各自给答案然后投票或者互相批评最后收敛出一个结果。我选的是流水线为主、局部辩论为辅。主流程走流水线因为客服场景对响应时间有要求辩论式太慢。但在质量检查环节我让 Agent-5 和 Agent-4 之间有一个最多两轮的来回Agent-5 打回Agent-4 修改Agent-5 再检查。两轮还不通过就直接转人工不再无限循环。注意辩论式协作听起来很美好但实际跑起来 token 消耗是流水线的三到五倍而且容易出现两个智能体互相说服不了对方、陷入死循环的情况。除非你的场景对准确率的要求远高于成本否则不建议全流程用辩论式。选流水线还有一个好处是调试方便。哪个环节出问题我直接看那个环节的输入输出就能定位不用在多个智能体的对话记录里翻来翻去。这一点在项目初期特别重要因为那时候提示词还没调稳几乎每天都要改。3. 智能体之间的交接协议怎么定3.1 数据格式统一是协作的地基五个智能体要能串起来前提是它们说同一种“语言”。我在项目里定义了一套内部消息格式所有智能体之间的传递都走这个格式不允许直接传自然语言。格式大概是这样{ trace_id: 本次请求的唯一标识, from_agent: Agent-1, to_agent: Agent-2, payload: { ... }, timestamp: 2025-01-15T10:30:00Z }trace_id是我强烈建议加的一个字段。一个用户请求走完五个智能体中间可能经过好几次重试和打回没有 trace_id 的话日志会乱成一锅粥。有了它我可以把一次请求的完整链路捞出来看排查问题效率高很多。payload里放的就是各个智能体的具体输出结构由上下游约定。比如 Agent-1 到 Agent-2 的 payload 里必须有intent和original_question两个字段Agent-2 到 Agent-3 的 payload 里必须有candidates数组。这些约定在项目开始时就写死后面改的话要同步改上下游的提示词成本很高所以前期多想一步很值。3.2 超时、重试与降级策略智能体调用大模型是有延迟的而且偶尔会超时或者返回格式错误。如果不管这些一个环节卡住整个流程就挂了。我的处理方式是给每个智能体设置独立的超时时间和重试次数。意图识别和检索这两个环节我设的是 8 秒超时、重试 1 次。因为这两个环节相对简单超时大概率是网络抖动重试一次基本能过。回复撰写环节设的是 15 秒超时、重试 1 次因为生成内容比较长。质量检查环节设的是 10 秒超时、不重试因为如果检查员本身都超时了说明这次请求可能有问题直接降级转人工更稳妥。降级策略也要提前想好。我的规则是任何一个环节连续失败两次整个请求直接转人工并且把已经产生的中间结果附在工单里让人工客服不用从头问起。这个设计在实际运行中救过我好几次尤其是知识库刚更新、检索员还没适应新内容的那几天。3.3 上下文怎么传才不爆窗口五个智能体串起来如果每个都把完整历史传给下一个token 消耗会爆炸。我的做法是只传必要信息不传对话历史。具体来说Agent-1 只接收用户当前这一轮的问题不接收历史对话。多轮对话的上下文由外层系统维护在调用 Agent-1 之前把指代消解掉比如把“它怎么退”改写成“XX产品怎么退款”。Agent-2 接收意图标签和消解后的问题不接收 Agent-1 的推理过程。Agent-3 接收候选片段不接收原始知识库全文。Agent-4 接收精选片段和用户问题不接收检索过程的中间日志。Agent-5 接收草稿和精选片段不接收前面所有环节的输入输出。这样每个智能体的输入都控制在几百 token 以内整个链路的 token 消耗比我最初设想的低了将近一半。代价是外层系统要多做一点指代消解的工作但这个投入完全值得。4. 完整实操流程与关键环节实现4.1 从零搭建的最小可行版本如果你现在就想动手试我建议先搭一个最小可行版本不要一上来就搞五个。最小版本只需要两个智能体一个负责理解加检索一个负责生成加检查。跑通之后再逐步拆分。第一步准备知识库。我用的是一个简单的向量检索方案把产品文档切成 300 字左右的片段每个片段存成一条记录包含文本和来源链接。切片的粒度很关键太短了信息不全太长了检索精度下降。300 字是我试下来比较平衡的值你可以根据自己文档的特点调整。第二步写 Agent-1 的提示词。核心是让它输出结构化的意图标签。我用的模板大致是你是一个意图识别助手。根据用户问题判断意图类别。 可选类别产品咨询、退款咨询、物流查询、投诉建议、其他。 只输出 JSON格式{intent: ..., confidence: 0.0-1.0, need_human: true/false} 如果无法判断intent 填 unknown。第三步写 Agent-2 的提示词让它根据意图和问题去检索知识库输出候选片段。这一步需要把你的检索接口和智能体对接起来具体方式取决于你用的平台。我用的是函数调用function calling的方式把检索封装成一个工具让智能体调用。第四步把两个智能体串起来用一个简单的主程序控制流程先调 Agent-1拿到意图再调 Agent-2拿到候选最后把候选拼进回复模板返回。这个版本大概半天就能跑起来。4.2 逐步拆分到五个智能体的过程最小版本跑通之后你会发现两个问题。第一检索出来的候选片段有时候不相关直接拼进回复会答非所问。第二回复的语气和完整性没人管偶尔会出洋相。这时候就可以拆了。先拆出 Agent-3 答案筛选员。它的提示词核心是让它在候选片段里做相关性排序并且给出排序理由。我要求它输出一个数组每个元素包含片段 ID、相关性分数、理由。相关性分数用 0 到 1 的小数理由是简短的一句话。这个理由字段看起来多余但在调试时特别有用我能看出它为什么把某条排前面从而判断是检索的问题还是筛选的问题。再拆出 Agent-5 质量检查员。它的提示词要写得像一份检查清单逐项核对事实是否与精选片段一致、语气是否礼貌、是否遗漏了用户问题的关键点、有没有编造信息。每项给出通过或不通过不通过的要给出具体修改意见。这里有个技巧让检查员先复述一遍它认为的正确答案再对比草稿。这样能有效减少它自己也被带偏的情况。最后把 Agent-4 独立出来专门负责把精选片段组织成自然语言。它的提示词里要强调“只使用给定片段中的信息不要自行补充”这一条能挡掉大部分幻觉。4.3 编排层的代码结构编排层不需要很复杂我用的是一个简单的状态机。伪代码大概是这样def handle_request(question): trace_id generate_trace_id() # 指代消解 resolved resolve_coreference(question, history) # Agent-1 intent call_agent(Agent-1, resolved, timeout8, retry1) if intent[intent] unknown or intent[need_human]: return transfer_to_human(trace_id, resolved) # Agent-2 candidates call_agent(Agent-2, {intent: intent, question: resolved}, timeout8, retry1) if not candidates: return transfer_to_human(trace_id, resolved) # Agent-3 selected call_agent(Agent-3, {candidates: candidates}, timeout8, retry1) # Agent-4 draft call_agent(Agent-4, {selected: selected, question: resolved}, timeout15, retry1) # Agent-5最多两轮 for i in range(2): check call_agent(Agent-5, {draft: draft, selected: selected}, timeout10, retry0) if check[passed]: return draft draft call_agent(Agent-4, {selected: selected, question: resolved, feedback: check[feedback]}, timeout15, retry1) return transfer_to_human(trace_id, resolved, draft)这个结构的好处是每个环节的失败都有明确的处理路径不会出现某个智能体返回了奇怪的东西导致整个流程崩掉。call_agent这个函数负责拼提示词、调模型、解析 JSON、处理超时和重试是编排层的核心工具函数。4.4 参数选择与成本控制跑五个智能体成本是绕不开的话题。我算过一笔账一次完整的五智能体流程token 消耗大概是单智能体的 2.5 倍左右。但因为每个智能体的提示词都很短单次调用的成本其实不高。真正影响成本的是重试和打回。我的控制手段有三个。第一意图识别和检索用较小的模型回复撰写和质量检查用较大的模型。因为前两个环节是分类和匹配任务小模型够用后两个环节涉及生成和判断需要更强的能力。第二设置每日调用上限超过之后自动降级到单智能体模式保证服务不中断。第三定期分析 trace 日志找出打回率高的环节针对性优化提示词从源头减少重试。实测下来这套配置在日均一千次请求的量级下成本完全可控而且回复准确率比单智能体方案高了大概二十个百分点。这个提升在客服场景里意味着少转很多人工省下来的成本远超多出来的 token 费用。5. 常见问题与排查技巧实录5.1 智能体之间互相甩锅怎么办这是我最开始遇到的一个典型问题。Agent-3 筛选出来的片段不相关Agent-4 就照着不相关的片段写Agent-5 检查时发现事实对不上打回给 Agent-4Agent-4 改了两轮还是不对最后转人工。表面上看是 Agent-4 的问题实际上是 Agent-3 的锅。排查这类问题的关键是看 trace 日志里的中间输出。我把每个智能体的输入输出都记下来出问题时从后往前看Agent-5 为什么打回因为草稿和片段对不上。草稿为什么对不上因为 Agent-4 拿到的片段本身就不相关。片段为什么不相关因为 Agent-3 的排序逻辑有问题。一路追下去很快就能定位到根因。定位到之后解决办法不是去改 Agent-4 的提示词让它“更聪明地处理不相关片段”而是去修 Agent-3 的排序逻辑。让每个智能体只对自己的职责负责不要指望下游去弥补上游的错误这是多智能体协作的一条铁律。5.2 输出格式偶尔跑偏怎么治即使提示词里写了“只输出 JSON”智能体偶尔还是会加一句“好的以下是结果”然后才给 JSON。这种格式跑偏在下游解析时会直接报错。我的处理方式是双保险提示词里强调解析时做容错。解析容错的做法是先用正则把 JSON 部分抠出来再尝试解析。如果解析失败就把原始输出记进日志然后触发一次重试。重试时在提示词末尾追加一句“上次输出格式有误请只输出纯 JSON不要任何其他文字”。实测这一招能解决九成以上的格式问题。还有一个更彻底的办法是用平台提供的结构化输出功能。如果你的智能体平台支持 JSON schema 约束直接开启让模型在解码层面就保证格式正确。这个功能能省掉很多解析上的麻烦强烈建议用起来。5.3 响应太慢怎么优化五个智能体串行跑延迟是累加的。如果每个环节平均两秒加起来就是十秒用户等不了。我的优化手段有三个。第一个是并行化能并行的环节。比如 Agent-2 检索的时候可以同时让 Agent-1 把意图识别的置信度算出来两者不冲突。不过这个要看具体场景我的项目里检索依赖意图标签所以没法并行但你的场景可能可以。第二个是流式输出。Agent-4 生成回复时用流式用户能先看到部分内容感知上的等待时间会短很多。这个改动不大但体验提升明显。第三个是缓存。高频问题的意图标签和检索结果可以缓存起来下次遇到同样的问题直接命中缓存跳过前两个智能体。缓存命中率在客服场景里通常不低因为用户问来问去就那些问题。5.4 常见问题速查表问题现象可能原因排查方向解决办法回复答非所问检索或筛选环节出错看 Agent-3 的排序理由优化检索关键词或筛选提示词回复编造信息Agent-4 超出给定片段对比草稿和精选片段强化“只用给定信息”的提示词格式解析失败智能体输出多余文字看原始输出日志加解析容错 重试时强调格式响应超过 15 秒某环节超时重试看各环节耗时日志定位慢环节考虑换小模型或加缓存打回率居高不下上游质量差或检查员太严统计打回原因分布针对性优化上游或放宽检查标准转人工率突然升高知识库更新或模型变更对比变更前后的 trace回滚变更或重新调优提示词提示这张表建议打印出来贴在工位上。多智能体系统出问题时先从表里对号入座能省掉大量瞎猜的时间。5.5 几个我踩过的坑第一个坑是过早引入复杂框架。我一开始想用某个多智能体框架结果光是把框架跑起来就花了两天而且它的抽象层让我很难看清每个智能体实际收到了什么提示词。后来我退回到最朴素的方式自己写编排代码每个智能体就是一个函数调用。代码量不大但完全可控。我的建议是除非你的场景真的需要框架提供的复杂调度能力否则先用最笨的办法跑通再考虑要不要上框架。第二个坑是提示词写得太长。我一度觉得提示词越详细越好把各种边界情况都写进去结果智能体的表现反而下降了。后来我意识到提示词太长会稀释重点智能体抓不住核心要求。现在的做法是每个智能体的提示词控制在 200 字以内只写最关键的职责和格式要求边界情况靠输出校验和重试来兜底。第三个坑是忽略了指代消解。多轮对话里用户会说“它怎么退”“这个多少钱”如果不做指代消解直接丢给意图识别员它会一脸懵。我后来在外层加了一个轻量的指代消解步骤把代词替换成具体实体整个链路的准确率提升了一大截。这个步骤可以用规则做也可以用一个小模型做成本很低但收益很高。6. 这套方案还能怎么扩展跑通五个智能体的客服知识库之后我把这套模式复制到了另外两个场景。一个是技术文档的自动问答把知识库换成内部技术文档五个智能体的职责基本不变只改了提示词里的领域描述。另一个是周报生成把意图识别换成信息抽取检索换成数据查询筛选换成重要性排序回复撰写换成周报草稿质量检查换成格式和事实核对。两个场景都在一周内跑起来了因为协作的骨架是通用的。如果你也想扩展我的建议是先把一个场景做深把每个智能体的提示词调到稳定把编排层的容错做扎实然后再复制。复制的时候重点改的是提示词和工具接口协作协议和编排逻辑基本不用动。这就是多智能体协作最大的价值一次搭好骨架多次复用。最后分享一个我在实际运行中总结的小技巧。每周花十分钟看一下 trace 日志里打回率最高的前十条请求把它们拿出来分析。这十条里往往藏着提示词可以优化的点改完之后整体准确率会有肉眼可见的提升。这个习惯我坚持了三个月打回率从最初的百分之十八降到了百分之四。维护多智能体系统就像带团队定期复盘比天天救火有用得多。