四种常见多 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，哪步错了一目了然