企业上AIAgent,别上来就搞多Agent协作,先想清楚这三件事
我的建议是：别上来就搞多Agent。先把单Agent跑通，跑出真实数据，再决定要不要拆。我见过太多项目一上来就设计五六个Agent协作，最后发现每个Agent的回答质量都很差，协作的精度建立在个体的精度之上——个体不行，协作就是放大错误。
这篇文章讲我真实做过的一套企业级AI Agent架构——从单Agent到多Agent协作怎么演进，意图分类怎么设计，Router怎么兜底，Agent之间怎么分工。
第一件事：先想清楚你的Agent要处理哪几类问题
很多人做Agent的第一步是"我要做一个什么都能答的Agent"。这是最大的陷阱——什么都能答的Agent什么都答不好。
正确的第一步是按业务场景拆意图。我在WMS系统里做了五类意图：
| 意图 | 处理方式 | 为什么单独拆 |
|---|---|---|
| 库存查询 | 不走RAG，查API取数 | 实时数据不能从文档编 |
| 入库流程 | RAG检索入库SOP | 流程类问题需要检索操作手册 |
| 出库流程 | RAG检索出库SOP | 入库出库SOP不同，不能混检索 |
| 异常处理 | RAG+升级人工 | 异常涉及账务风险，必须有人工兜底 |
| 通用问答 | 纯RAG检索知识库 | 兜底场景，不涉及操作和取数 |
为什么要拆意图？ 两个原因：第一，库存查询不能靠RAG——RAG是检索文档不是查实时数据，用户问"还剩多少个"，AI从文档里编一个数字，那就是一本正经的错误答案。第二，入库和出库的SOP混检索会串流程——用户问入库，AI把出库的步骤也讲了出来，用户照做就错操作了。
意图分类是Agent架构的第一道闸门，决定了问题走哪条处理链路。它不是"可选优化"，是"不分类就别上线"。
第二件事：Router怎么做，怎么兜底
意图分类用LLM做Router——给它一个问题，判断走哪条链路。但比分类更重要的是兜底策略。
我踩过一个坑：最初把置信度阈值定在0.7——低于0.7就转人工。跑了一周发现大量正常提问置信度也低于0.7，误转人工太多，运维团队抗议。
后来调到0.4，才平衡。置信度阈值必须用真实提问分布来标定，不能拍脑袋。 你用什么模型、你的问题分布是什么样，阈值就不同。别人的0.7到你这里可能就是0.4。
| 参数 | 行业参考值 | 我的实测值 | 调优过程 |
|---|---|---|---|
| Router置信度阈值 | 0.7 | 0.4 | 0.7时正常提问也低于阈值，误转人工过多 |
| 意图样本配比 | 3:2:2:2:1 | 2:2:2:1:3 | 实测产线问题占比更高，配比按真实分布调 |
| 兜底策略 | 无法识别转人工 | 低于0.4转人工 | 禁止硬答，硬答比转人工更危险 |
没有兜底的意图分类比没有分类更危险。 错误路由到库存查询Agent的流程问题，会得到一本正经的错误答案——因为库存查询Agent的Prompt里写死了"只回答库存数据"，但它收到了一个流程问题，如果Prompt没防住，它就会用库存数据编一个流程回答出来。
每类意图配独立Agent System Prompt，明确回答边界。比如库存查询Agent的Prompt写死"只回答库存数据，不回答流程操作问题"——这是防串意图的最后一道防线。
第三件事：什么时候才该从单Agent切到多Agent
我见过太多项目一上来就设计五六个Agent协作，每个Agent负责一个意图。但真正的判断标准不是"有几个意图"，而是"单Agent的回答质量是否已经到瓶颈"。
演进路径应该是这样的：
| 阶段 | 架构 | 什么时候切 |
|---|---|---|
| 阶段一 | 单Agent+意图Router | 起步阶段，跑通基础链路 |
| 阶段二 | 多Agent+各自独立Prompt | 单Agent回答开始串意图，Prompt互相冲突时 |
| 阶段三 | 多Agent+Agent间协作 | 出现跨意图问题（如先查库存再走异常流程） |
阶段一就够了的时候不要硬上阶段二。判断标准很简单：如果你把所有意图的Prompt塞进一个Agent，它回答某类问题时开始受其他意图Prompt干扰——这时候才该拆。如果没干扰，一个Agent配多个System Prompt切换就够了，不需要物理拆成多个Agent。
阶段二到阶段三的切换标准是：有没有跨意图的问题。比如用户先问"还有多少库存"，得到答案后说"数量不对，我要报异常"——这需要库存查询Agent的结果传给异常处理Agent。如果大多数问题都是单意图的，不需要Agent间协作。
我真实的技术栈和架构
技术栈：.NET 9.0 + MAF（Microsoft Agent Framework）+ PostgreSQL + pgvector + DeepSeek + bge-m3 + SignalR。你用Python+LangChain或Java+Spring AI也一样，架构思路是通用的。
架构链路：
用户提问 → 意图分类Router（LLM判断走哪条链路）
├─ 库存查询 → 查询Agent → API取数 → 生成回复
├─ 入库/出库 → 流程Agent + RAG检索SOP文档
├─ 异常 → 异常Agent + RAG + 升级人工规则
└─ 通用问答 → 兜底Agent + 纯RAG检索
RAG链路：文档切片 → bge-m3向量化 → pgvector HNSW检索 → 上下文注入 → LLM生成（带原文来源标注）
为什么用SignalR：用户提问后AI回复需要时间，不能让前端一直转圈。SignalR做异步推送，用户先收到"正在查询"，结果生成后实时推过去。这个体验细节决定了用户觉得"这个AI是不是可用"。
灰度发布：别直接上线
架构搭完了不要直接上线。先放给内部运维团队用两周，收集误分类案例回灌。灰度的核心目标是发现Router分错意图的场景——意图分错比回答差更致命，因为分错后走到错误的Agent，再好的Agent也答不对。
灰度期间重点盯三类问题：
· 误分类：流程问题被分到库存查询Agent
· 串意图：入库Agent回答了出库步骤
· 兜底失灵：置信度0.4以下的问题被硬答了而非转人工
这三类问题灰度期一定会出现。出现不是坏事——收集案例回灌才是灰度的价值。不上线灰度，这些问题会在真实用户身上发生，代价大十倍。
文末：把你的场景丢给我的AI专家
这篇文章讲的是通用架构思路。但你的业务场景、意图拆分方式、Router阈值、Agent Prompt设计——这些取决于你的具体情况。
我在WorkBuddy上做了一个"企业级 AI Agent 应用架构师"专家，专门帮企业设计Agent架构。你可以直接召唤它，把你的情况描述丢过去：
"我们想给内部系统做AI Agent，有库存查询、流程操作、异常处理三类场景，用.NET技术栈，从哪一步开始设计架构？"
它会按你的具体情况给方案——帮你判断意图怎么拆、Router怎么设计、什么时候该从单Agent切到多Agent、灰度怎么跑。
怎么召唤：打开WorkBuddy，在对话框输入 @企业级 AI Agent 应用架构师，直接问就行。