字节笔记本
2026年10月24日 · 约 12 分钟读完
实战四：搭一个多 Agent 客服中心
本文是《从 0 写 Agent》系列第 48 章。这个系列基于开源项目 agents-go（OpenAI Agents SDK 的 Go 移植版），用 Go 从零实现一个生产级 Agent 运行时；本章讲「实战四：多 Agent 客服中心」。
第 45 章的客服 Agent 是单 Agent 干所有事。真实客服中心要分工，分诊、退款、物流、技术，多 Agent 协作。
这个案例是 Part III 多 Agent 理论的实战应用，用 Handoff（接力）+ Agent-as-Tool（委托）搭建一个客服中心。
架构设计
用户 → 分诊 Agent（判断问题类型，交接）
├─ Handoff → 退款 Agent（处理退款）
├─ Handoff → 物流 Agent（查物流）
├─ Handoff → 技术 Agent（技术支持）
│ └─ Agent-as-Tool → 知识库 Agent（查文档）
└─ Handoff → 人工坐席（兜底）分诊用 Handoff（接力），技术 Agent 用 Agent-as-Tool 调知识库（委托）。 两种多 Agent 模式组合使用。
分诊 Agent
triageAgent := &agents.Agent{
Name: "分诊",
Instructions: agents.StaticInstructions(`你是客服分诊。
判断用户问题类型，交接给对应专家：
- 退款相关 → transfer_to_refund
- 物流查询 → transfer_to_shipping
- 技术问题 → transfer_to_tech
- 其他/处理不了 → transfer_to_human
不要自己解决问题，只做分诊。`),
Model: "openai/gpt-4o-mini", // 分诊用便宜模型
Handoffs: []agents.Handoff{
agents.HandoffTo(refundAgent),
agents.HandoffTo(shippingAgent),
agents.HandoffTo(techAgent),
agents.HandoffTo(humanAgent),
},
}分诊用 mini 模型（便宜），它只做分类，不需要强推理。专家 Agent 用强模型（gpt-4o），它们要解决具体问题。这是模型路由（第 21 章）在多 Agent 的应用，不同 Agent 用不同模型，按能力需求分配成本。
专家 Agent 们
// 退款 Agent
refundAgent := &agents.Agent{
Name: "退款专员",
Instructions: agents.StaticInstructions("你是退款专员。查订单、判断退款条件、处理退款。"),
Tools: []agents.Tool{getOrderTool, refundTool},
// refundTool.NeedsApproval = true（第 45 章）
}
// 物流 Agent
shippingAgent := &agents.Agent{
Name: "物流专员",
Instructions: agents.StaticInstructions("你是物流专员。查物流状态、联系快递。"),
Tools: []agents.Tool{getOrderTool, trackShipmentTool},
}
// 技术 Agent，它还能调知识库子 Agent
knowledgeAgent := &agents.Agent{
Name: "知识库",
Instructions: agents.StaticInstructions("你是知识库查询。根据问题搜索产品文档，返回相关内容。"),
MCPServers: []agents.MCPServer{knowledgeMcpServer},
}
techAgent := &agents.Agent{
Name: "技术支持",
Instructions: agents.StaticInstructions("你是技术支持。先查知识库，再解答。"),
Tools: []agents.Tool{
knowledgeAgent.AsTool(agents.AgentToolConfig{ // Agent-as-Tool！
Name: "search_docs",
Description: "搜索产品知识库",
MaxTurns: 3, // 知识库查询最多 3 轮
}),
},
}技术 Agent 用 Agent-as-Tool 调知识库，第 18 章。知识库 Agent 是"黑盒工具"，技术 Agent 不关心它怎么搜，只要结果。
Handoff 历史处理
分诊交接给专家时，专家要看到之前的对话（用户说了什么）。用第 16 章的 InputFilter 精简历史：
handoff := agents.HandoffTo(refundAgent)
handoff.InputFilter = func(data agents.HandoffInputData) agents.HandoffInputData {
// 只保留消息，去掉分诊的内部推理
var filtered []agents.TResponseInputItem
for _, item := range data.InputHistory {
if isUserOrAssistantMessage(item) {
filtered = append(filtered, item)
}
}
return agents.HandoffInputData{InputHistory: filtered}
}专家 Agent 看到的是"干净的对话历史"，不含分诊的中间步骤。 减少干扰，聚焦问题本身。
Session 跨 Agent 持续
// 整个客服过程用一个 Session（跨 handoff 持续）
sess := memory.NewFileSession("sessions", sessionID)
agents.Run(ctx, triageAgent, userMessage, agents.RunOptions{
Session: sess,
// ...
})Session 跟着用户走，不跟着 Agent 走。 分诊→退款→（可能的）人工，全程一个 Session，历史连续。这呼应第 16 章的"双 item 列表"，sessionItems 保留完整历史（含所有 Agent 的产出），不管 handoff 怎么过滤模型视角。
完整流转示例
用户："我买的手机有质量问题，要退款，但物流还没到"
→ 分诊 Agent：分析问题（退款 + 物流混合）
→ Handoff → 退款 Agent（退款是主诉求）
→ 退款 Agent：
查订单 → 订单状态"运输中" → 退款条件：需先拒收
Agent："您的订单还在运输中。需要先拒收包裹，才能发起退款。要我帮您查物流吗？"
用户："那先查物流"
→ 退款 Agent 处理不了物流 → Handoff → 物流 Agent
→ 物流 Agent：查物流 → "包裹明天到达"
→ Agent："包裹预计明天到达。您可以拒收后联系我退款。"注意，退款→物流的交接，是专家之间的二次 Handoff。 Handoff 不限于分诊→专家，专家之间也能交接（如果问题超出自己领域）。
多 Agent 的监控
多 Agent 系统调试更难，要追踪"控制权在谁手里"。用 Tracing（第 25 章）+ Hooks（第 19 章）：
// Tracing 会记录每次 handoff（SpanTypeHandoff）
// trace 视图能看到完整流转：
trace: 客服会话
├── span: agent(分诊)
│ └── span: handoff(→退款) ← 第一次交接
├── span: agent(退款)
│ ├── span: function(get_order)
│ └── span: handoff(→物流) ← 第二次交接
└── span: agent(物流)
└── span: function(track_shipment)一目了然，会话经过了分诊→退款→物流三个 Agent。 没有这个 trace，多 Agent 的调试是噩梦。
小结
多 Agent 客服中心的设计要点：
- 分诊用便宜模型，专家用强模型，按能力分配成本
- Handoff（接力）+ Agent-as-Tool（委托）组合，分诊转专家用 Handoff，技术调知识库用 As-Tool
- InputFilter 精简历史，专家看干净对话
- Session 跨 Agent 持续，一个用户一个 Session
- Tracing 追踪流转，多 Agent 调试必备
这个案例体现了 Part III 的核心，什么时候用 Handoff（接力）、什么时候用 Agent-as-Tool（委托）、什么时候组合。
下一篇
第 49 章，实战五：内部 AI 平台。把客服/分析/代码这些 Agent 做成企业内部平台，多用户、配置驱动、可观测。这是 agents-server 在真实企业的延伸。
本文是《从 0 写 Agent》系列第 48 章，案例代码基于开源项目 agents-go（OpenAI Agents SDK 的 Go 移植版）。全系列目录见总览。
