四种常见多 Agent 模式234 - 研究报告/客服/电商
昨天发了模式一 软件开发多Agent模式，今天把剩下的发出来
其实我正在调整类似模式二的单智能体，如何提高任务完成率难度仍然非常高，在高端模型运行时候也尝试了大量的新点子新方法，总之还在试。调这些基本上就是大力出奇迹到经济高效率化优化。这个，调试一套程序搜索额度不太够用了啊。
模式二：研究/报告 Agent ⭐ 团队实用
多 Agent 深度研究 ≠ LLM + 搜索工具。单 Agent 搜索的问题是"搜一次就写结论"——没有交叉验证、没有多方比对、搜不到关键信息也不会重试。多 Agent 把搜索、分析、写作拆成独立环节，让 Searcher 只管找资料、Analyst 只管验证矛盾、Writer 只管输出结构。
▼text复制代码Planner Agent（将主题拆成子问题 → 规划搜索策略） ├── Searcher Agent × N（多路并行搜索，每路不同关键词/来源） ├── Analyst Agent（综合对比 → 交叉验证 → 标注分歧） │ ↓ 发现信息不足 → 回退 Planner 重新规划搜索 └── Writer Agent（按模板输出结构化报告，附来源链）
与多 Agent 架构的关系： 这是 Pipeline + 并行执行模式。Planner 拆解问题，Searcher × N 并行搜索（可扩展到 N 路，互相独立不干扰），Analyst 做垂直整合和验证，Writer 最终输出。如果 Analyst 发现信息不够，可以触发 Planner 做第二轮搜索——这是"递归深入"的关键能力，单 Agent 很难做到。
代表实现： Deep Research（各类变体）、OpenAI Deep Research、Gemini Deep Research 难点： 搜索质量把控（搜到垃圾信息 → 结论偏了）、多源矛盾处理（两个来源说相反的，谁可信？）、报告结构一致性（多人协作容易风格不统一） 关联项目： P3 产品对比流的核心引擎就是 Deep Research
单 Agent vs 多 Agent：关键区别
| 维度 | 单 Agent（一个 LLM + 搜索工具） | 多 Agent 分工 |
|---|---|---|
| 搜索广度 | 搜一轮就问，容易遗漏关键角度 | Searcher × N 多路并行，不同关键词/来源覆盖更多维度 |
| 交叉验证 | LLM 倾向于用自己的"知识"圆场，不真正核验来源 | Analyst 独立对比多个来源，明确标注"信息冲突"或"证据不足" |
| 递归深入 | 搜到表面信息就停，不会追问 | Analyst 发现信息缺口 → 回退 Planner 重新搜索，可多轮深入 |
| 报告质量 | 平铺直叙，缺框架，容易幻觉编造引用 | Writer 按模板输出结构化报告，每句话标注来源，可追溯 |
一条典型的演进路径
| 阶段 | 架构 | 本质 | 是不是多 Agent？ |
|---|---|---|---|
| L1 手动研究 | 人搜、人读、人写报告 | 传统 desk research | ❌ |
| L2 单 Agent 搜索 | LLM + web search，一次性回答 | AI 辅助搜索 | ❌ 单 Agent |
| L3 Deep Research 基础版 | Planner + 多路搜索，但分析和写作合一 | 半自动研究 | 🟡 部分多 Agent |
| L4 完整多 Agent 研究 | Planner → Searcher × N → Analyst → Writer，支持递归深入 | 全链路分工 | ✅ 真正多 Agent |
研究/报告 Agent 为什么需要多智能体？因为"找资料"和"判断资料对不对"是两个不同能力——LLM 擅长总结但不擅长质疑自己。拆出独立的 Analyst 做交叉验证，是防止 AI 研究报告变成"看起来很对但其实是编的"的关键设计。
模式三：客服/工单 Agent ⭐ 企业最爱
多 Agent 客服 ≠ 一个聊天机器人回答所有问题。单 Agent 客服最大的问题是"什么都能聊但什么都不精"——售前话术和售后流程混在同一个 Prompt 里，技术排查和投诉处理共用同一个知识库，工具权限要么过大要么不够用。多 Agent 把不同业务域拆成独立 Specialist，各管各的知识和工具。
▼text复制代码用户请求 │ ▼ ┌─────────────────────────────────────────────────┐ │ 意图识别 / 路由分发 Agent │ │ · 判断用户属于售前/售后/技术/投诉 │ │ · 多意图 → 拆分 → 分别派发 → 结果融合 │ │ · 不确定 → 反问确认或分配兜底 Agent │ └──────┬──────────┬──────────┬──────────┬───────────┘ │ │ │ │ ▼ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ 售前 Agent│ │ 售后 Agent│ │ 技术 Agent│ │ 人工转接 Agent │ │ 产品咨询 │ │ 退换货 │ │ 故障排查 │ │ 复杂问题升级 │ │ 推荐配置 │ │ 退款处理 │ │ 参数设置 │ │ 带上下文移交 │ │ 促销政策 │ │ 物流查询 │ │ 兼容性判断│ │ SLA 跟踪 │ └──────────┘ └──────────┘ └──────────┘ └──────────────┘ │ │ │ │ └──────────┴──────────┴──────────┘ ▼ ┌─────────────────────────────────────────────────┐ │ State 统一管理 │ │ 跨 Agent 上下文共享 · 会话状态持久化 │ │ 售前转售后时上下文干净传递 │ └─────────────────────────────────────────────────┘
与多 Agent 架构的关系： 这是最标准的 Supervisor + Specialist 模式。意图识别 Agent = Supervisor，各业务 Agent = Specialist。和模式四（电商导购）共享同一套架构模板，区别在于 Specialist 职责不同——客服的 Specialist 按"业务阶段"划分（售前→售后→技术），电商导购按"业务类型"划分（商品→订单→售后）。
代表实现： 几乎所有企业的 AI 客服都在做（Zendesk AI、Intercom Fin、京东言犀、淘宝问问） 难点： 意图识别准确率（用户说"我想退"是退款还是退 subscription？）、多轮状态追踪（用户说了 5 轮才提出核心诉求，前面都是铺垫）、情绪感知和升级策略（什么时候该转人工？） 关联项目： P4 S4 的 Supervisor + Specialist 模式
单 Agent vs 多 Agent：关键区别
| 维度 | 单 Agent（一个 LLM 管所有客服） | 多 Agent 分工 |
|---|---|---|
| 知识域隔离 | 产品知识+退货政策+技术手册混在一个 Prompt，互相干扰 | 每个 Specialist 只加载自己领域的 KB，Prompt 精简聚焦 |
| 工具权限 | Agent 能看到所有内部 API（退款+改价+删单），安全风险大 | 售前不能调退款接口，售后不能改商品价格，最小权限原则 |
| 人工转接 | 靠 Prompt 说"解决不了转人工"，经常卡住或误转 | 专用转接 Agent，带完整对话上下文结构化移交，SLA 跟踪 |
| 多轮状态 | 所有轮次塞进同一个 history，越长越混乱 | State 分域管理，售前聊完转售后时只传必要上下文，干净切换 |
一条典型的演进路径
| 阶段 | 架构 | 本质 | 是不是多 Agent？ |
|---|---|---|---|
| L1 关键词机器人 | if-then 规则匹配，固定话术 | 传统客服机器人 | ❌ |
| L2 单 Agent LLM 客服 | 一个模型回答所有问题，无工具调用 | AI 聊天客服 | ❌ 单 Agent |
| L3 Agent + Tool 客服 | 能查订单、查物流、退款的单 Agent | 有行动力的客服 | ❌ 还是单 Agent |
| L4 多 Agent 客服 | Supervisor 路由 + 多个 Specialist + 人工转接 | 分工协作 | ✅ 真正多 Agent |
客服/工单 Agent 为什么需要多智能体？不是因为一个 LLM 回答不了问题，而是因为"一个 Agent 什么都能做 = 一个 Agent 什么权限都有"。多 Agent 的真正价值是工具隔离和错误域隔离——退款 Agent 出 bug 不会影响商品咨询，人为操作风险也被限制在最小范围。
模式四：电商导购 Agent ⭐ 实用性高
电商导购 Agent 是不是多智能体？看架构深度。 同样叫"AI 导购"，从简单到复杂可以分三个层次：
🥉 层次一：单步 RAG（单 Agent）
▼text复制代码用户问 → 检索商品 → LLM 生成回答
这只是单 Agent 套了个检索工具，不是多智能体。把所有逻辑塞进一个 LLM 调用，Prompt 越来越臃肿，但架构上没有拆分，错误不隔离、职责不清晰。
🥈 层次二：管线式多 Agent
▼text复制代码需求理解 Agent → 商品检索 RAG → 比价分析 → 推荐生成
每个环节拆成独立 Agent。算多 Agent，但属于 Pipeline 模式——问题在于：前半截 Agent 挂了后半截就拿不到输入，全链路断；而且没有 Supervisor 兜底，错误不会重路由。
🥇 层次三：Supervisor + Specialist（真正的多 Agent）
真正的多 Agent 导购把售前、售后、决策拆成独立角色，通过 Supervisor 统一路由：
▼text复制代码用户请求 │ ▼ ┌─────────────────────────────────────────────────┐ │ 意图理解 / 需求澄清 Agent（轻量 Supervisor） │ │ · 单意图 → 直接路由 │ │ · 多意图 → 拆解 → 分别派发 → 结果融合 │ │ · 意图模糊 → 反问澄清 │ └──────┬──────────────────────────┬────────────────┘ │ │ ▼ ▼ ┌──────────────────┐ ┌──────────────────────────┐ │ 售前导购 Agent │ │ 售后客服 Agent │ │ · 商品搜索/推荐 │ │ · 订单查询/物流跟踪 │ │ · 比价/参数对比 │ │ · 退换货/退款处理 │ │ · 库存查询 │ │ · 地址修改/投诉升级 │ │ · 装机方案推荐 │ │ · 人工转接 │ └──────────────────┘ └──────────────────────────┘ │ │ └──────────┬───────────────┘ ▼ ┌─────────────────────────────────────────────────┐ │ 汇总 Agent（融合结果 + 风险提示） │ │ 引用商品来源 · 标注退款条件 · 给出下一步建议 │ └─────────────────────────────────────────────────┘
与多 Agent 架构的关系： 这是 "Supervisor + Specialist" 模式的电商版——意图理解 Agent 充当 Supervisor，售前/售后 Agent 是 Specialist。和模式三（客服工单）共享同一套架构模板，区别在于 Specialist 的 Tool 集和知识域不同。
代表实现： 京东言犀、淘宝问问、Shopify Sidekick 难点： 用户真实意图推断（"这个鼠标不好用"→ 退款还是换货？）、多约束排序（预算+品牌+性能的综合排序）、售前售后跨域协作（退旧买新涉及两个 Specialist 接力） 关联项目： P4 GamingGear 的 S1→S4 演进路径，S4 设计中的 Supervisor + Order Agent + Product Agent 结构
单 Agent vs 多 Agent：关键区别
| 维度 | 单 Agent（一个 LLM + RAG） | 多 Agent 分工 |
|---|---|---|
| 一个 Prompt 管所有事 | 推荐逻辑和退款逻辑写在一起，容易冲突 | 售前 Agent 看不到退款 Tool，安全隔离 |
| 多意图混在一起 | "退鼠标+推荐新的" → LLM 自己拆，容易漏 | Supervisor 显式拆成两个子任务，分别派发 |
| 错误传播 | 商品搜索接口超时 → 整个对话崩 | 搜索 Agent 超时 → 只降级推荐结果，售后不受影响 |
| 可调试 | 返回一句话，不知道信息哪来的 | 每步中间结果写 State，哪步错了一目了然 |
