# 复杂客服任务怎么拆给Planner与Router？

> 客服任务不是一条链，而是一张带条件、并行和重规划的图。

```text
[读者] 正在把客服 Agent 从 Demo 推向生产的 FDE 与架构师
[痛点] 任务一复杂就串行到底，失败后不知道从哪重来
[现在读] Router、Planner、Orchestrator、Evaluator 已能落到工程图
[读完] 能把复杂客服任务拆成可并行、可串行、可重规划的执行图
```

```text
[旧方案] 一个 ReAct Agent 循环调所有工具
    |
    v
[新需求] 识别客户、理解意图、查知识、查订单、判断政策、生成方案、执行动作、确认结果
    |
    v
[冲突] 全局规划、局部工具、失败恢复混在一个循环里
    |
    v
[后果] 延迟不可控、权限难隔离、失败难审计、重试不可恢复
```

我是老李，在给一家全球智能客服平台做 FDE。平台同时服务多个企业，每个企业有不同项目、语言、渠道，后端接着 CRM、订单、支付、物流、工单和知识库。过去一个客服 Agent 能回答 FAQ 就算成功，现在客户要的是一条闭环：认出客户是谁，理解他为什么来，查到订单和知识，判断政策，给方案，执行动作，再确认结果。

V0 很自然，把所有工具挂给一个 ReAct Agent，让它边想边调。最初处理单轮咨询够用，但一旦任务跨越订单、退款、工单和多语言，Agent 的思考轨迹就变成不可审计的长文本。一次失败后，你不知道是客户识别错了、意图路由错了、政策判断错了，还是动作已经执行但确认丢失。

团队内部争论也很大。有人说继续把 prompt 写厚，有人说上多 Agent，有人说用 Workflow。真正的问题是：复杂客服任务到底该拆成什么粒度，哪些步骤能并行，哪些必须串行，失败后是重试、补偿还是重规划？

冲突问句：复杂客服任务到底是串行链，还是并行图？

选择问句：该让 ReAct 一个循环管到底，还是让 Router、Planner、Orchestrator、Evaluator 分层？

选错后果问句：如果全局规划、局部工具和失败恢复混在一起，退款、工单和审计会付出什么代价？

# 01、故事

全球智能客服平台接了一个欧洲租户，任务是处理物流延迟退款。客户在聊天里说订单没到，要求退款。看似一句话，背后要识别客户、理解意图、查知识、查订单、判断政策、生成方案、执行动作、确认结果。

最初团队用一个 ReAct Agent 加八个工具。它能跑通，但每次执行路径都不一样。今天先查订单再查知识，明天先查知识再查订单。遇到订单服务超时，它把整段任务重跑一遍，结果退款动作被重复调用。工单系统里出现两条相同工单，支付系统出现一次预授权。

我们开始记录每一步的输入输出。证据显示，问题不在工具本身，而在编排：Router 没有把租户、语言、渠道和意图分开；Planner 没有声明依赖；Orchestrator 没有状态所有权；Evaluator 只在最后说成功或失败。

> 单环能答问
> 多步难闭环
> 工具一多乱
> 状态无处安

# 02、问题

旧方案失效的地方很具体。第一，串行链把无依赖步骤排成固定顺序，查知识、查订单、查客户等级本可并行，却被人为串行，延迟叠加。第二，订单系统超时后没有检查点，失败恢复从 START 开始，已经执行过的动作再次执行。第三，政策判断与动作执行没有隔离，高风险动作和普通查询共用同一权限。

业务影响随之出现。高价值客户等待时间拉长；重复退款需要人工冲正；工单重复导致客服重复跟进；审计只能翻 LLM 对话，无法按状态字段还原。技术表现是状态散落在 prompt、工具历史和日志里，Router 用 LLM 分类却不记录置信度，Planner 不输出 DAG，Evaluator 不区分步骤失败与最终失败。

可验证的完成标准应该包括：每个步骤有明确输入输出契约；Router 能输出可审计的路由理由；Planner 能标记并行、串行、人工节点；Orchestrator 能持久化状态并从最近完成节点恢复；Evaluator 能触发重规划、补偿或人工接管。

> 延迟叠成墙
> 失败从头来
> 权限无边界
> 审计缺证据

# 03、原理

反直觉判断：复杂客服任务的第一性问题不是让 LLM 更聪明，而是把不确定性关进可验证的状态机里。LLM 适合理解意图、生成方案、解释政策，但全局步骤依赖、失败边界和副作用提交，必须由工程层掌握。

Router 负责识别请求属于哪个租户、渠道、语言、业务域和风险等级，并选择流程。Planner 把任务拆成步骤图，标记哪些可并行、哪些必须串行、哪些失败后只能人工。Orchestrator 执行图，管理状态、超时、重试、补偿、幂等和检查点。Evaluator 评估每步产物和最终结果，决定继续、重规划、回滚还是升级人工。

ReAct 的价值在局部：当工具选择依赖当前观察时，交错推理与行动很有效。但把全局规划也塞进 ReAct 循环，等于让模型同时负责策略、调度和副作用，失败不可恢复。Microsoft Agent Framework 官方仓库把 agent 与 workflow 编排作为一等能力；LangGraph 官方仓库用 StateGraph、条件边、checkpointer 和 durable execution 表达长任务；ReAct 论文 arXiv:2210.03629 强调推理与行动交错。三者定位不同，需按官方文档核验当前 API。

> 先定状态权
> 再分规划层
> 局部交反应
> 全局走图程

# 04、架构

```text
[输入] 客户消息 + 租户 + 渠道 + 语言
    |
    v
[模块] Router -> Planner -> Orchestrator -> Evaluator
    |
    v
[数据/状态] 任务状态、步骤状态、检查点、幂等键、审计事件
    |
    v
[处理] 并行查询、串行政策、动作执行、结果确认、失败重规划
    |
    v
[输出] 客户答复、退款/工单动作、人工任务、可追溯证据链
```

边界上，Router 不碰业务数据，只输出路由与风险等级。Planner 不直接调工具，只产出步骤图。Orchestrator 不解释政策，只按图执行并维护状态。Evaluator 不生成业务动作，只判定并给出下一步建议。

收益是并行可控、失败可恢复、权限可隔离、审计可按状态字段追踪。代价是状态模型变复杂，需要定义步骤契约、幂等键和检查点存储。适用条件是任务跨越多个系统、有副作用、需要人工接管或合规审计。单轮 FAQ 不必上完整图。

> 路由识场景
> 规划生步骤
> 编排管状态
> 评估定去留

# 05、实战一次

环境：Python 3.11。依赖：LangGraph 官方 StateGraph 接口，具体版本按当前官方文档核验。配置：先用确定性节点模拟 Router、知识、订单和政策，避免把 LLM 不确定性混入状态流验证。

安装：

```bash
pip install langgraph
```

核心实现：

```python
from typing import TypedDict, List, Dict, Any
from langgraph.graph import StateGraph, START, END

class CustomerTaskState(TypedDict, total=False):
    request: str
    tenant: str
    customer_id: str
    intent: str
    knowledge: List[str]
    order: Dict[str, Any]
    policy: str
    plan: List[str]
    action_result: str
    final: str

def identify_customer(state: CustomerTaskState) -> CustomerTaskState:
    return {'customer_id': 'C-10086'}

def classify_intent(state: CustomerTaskState) -> CustomerTaskState:
    text = state['request']
    if '退款' in text or 'refund' in text:
        intent = 'logistics_refund'
    else:
        intent = 'general'
    return {'intent': intent}

def retrieve_knowledge(state: CustomerTaskState) -> CustomerTaskState:
    return {'knowledge': ['物流延迟退款政策：需订单已支付且未签收']}

def query_order(state: CustomerTaskState) -> CustomerTaskState:
    return {'order': {'order_id': 'O-2024-001', 'paid': True, 'delivered': False}}

def judge_policy(state: CustomerTaskState) -> CustomerTaskState:
    order = state['order']
    if order['paid'] and not order['delivered']:
        policy = 'refund_allowed'
    else:
        policy = 'manual_review'
    return {'policy': policy}

def make_plan(state: CustomerTaskState) -> CustomerTaskState:
    return {'plan': ['create_refund', 'notify_customer', 'create_ticket']}

def execute_action(state: CustomerTaskState) -> CustomerTaskState:
    return {'action_result': 'refund_created_for_O-2024-001'}

def confirm_result(state: CustomerTaskState) -> CustomerTaskState:
    return {'final': '已创建退款并通知客户，工单待跟进'}

graph = StateGraph(CustomerTaskState)
graph.add_node('identify_customer', identify_customer)
graph.add_node('classify_intent', classify_intent)
graph.add_node('retrieve_knowledge', retrieve_knowledge)
graph.add_node('query_order', query_order)
graph.add_node('judge_policy', judge_policy)
graph.add_node('make_plan', make_plan)
graph.add_node('execute_action', execute_action)
graph.add_node('confirm_result', confirm_result)

graph.add_edge(START, 'identify_customer')
graph.add_edge('identify_customer', 'classify_intent')
graph.add_edge('classify_intent', 'retrieve_knowledge')
graph.add_edge('retrieve_knowledge', 'query_order')
graph.add_edge('query_order', 'judge_policy')
graph.add_edge('judge_policy', 'make_plan')
graph.add_edge('make_plan', 'execute_action')
graph.add_edge('execute_action', 'confirm_result')
graph.add_edge('confirm_result', END)

app = graph.compile()
result = app.invoke({
    'request': '我的订单还没到，我要退款',
    'tenant': 'acme-eu',
    'customer_id': '',
    'intent': '',
    'knowledge': [],
    'order': {},
    'policy': '',
    'plan': [],
    'action_result': '',
    'final': ''
})
print(result['final'])
print(result['policy'])
print(result['plan'])
```

启动：

```bash
python v1_serial_router.py
```

未在当前环境实测，以下为预期结果。示例输出：

```bash
已创建退款并通知客户，工单待跟进
refund_allowed
['create_refund', 'notify_customer', 'create_ticket']
```

验证点：状态字段是否完整流转；政策判断是否在订单查询之后；动作执行是否只发生一次。V1 先跑通串行链，但并行和恢复问题被留到下一章。

> 先跑串行链
> 再留并行口
> 检查点落地
> 动作要幂等

# 06、排查

现象一：高峰期退款咨询 p95 延迟升高。怀疑：知识检索和订单查询被串行。检查：在节点入口和出口打时间戳，记录外部调用耗时。证据：两个无依赖调用在同一链上顺序执行，总耗时接近两者之和。根因：Planner 没有声明依赖，Orchestrator 只能按固定边执行。修复：在 V2 中把知识、订单、客户等级标为可并行分支。

现象二：订单服务超时后重跑，客户收到两次退款。怀疑：失败恢复没有检查点，动作没有幂等键。检查：按 thread_id 和 order_id 查询动作日志。证据：同一 order_id 出现两次 create_refund。根因：恢复从 START 开始，执行节点不判断动作是否已提交。修复：引入 checkpointer、幂等键和已执行动作短路。

**错误尝试：** 把重试完全交给 ReAct Agent 自主决定。它看到超时后重新规划整段任务，却不知道退款已经提交。错误在于 LLM 看不到副作用边界，重规划不能越过已提交动作。正确做法是由 Orchestrator 在状态层判断哪些步骤已完成、哪些可重试、哪些必须补偿或人工。

> 看时间戳
> 查副作用
> 证根因
> 再修复

# 07、优化

根因有三条：全局规划与局部执行未分离；无依赖步骤未声明并行；失败恢复无持久状态。V2 的修改是：Router 输出 route 和 risk；Planner 输出带依赖标记的步骤图；Orchestrator 用检查点维护步骤状态；Evaluator 对每步产物判定 ok、retry、replan、manual。

关键修改片段：

```python
from langgraph.checkpoint.memory import MemorySaver
from langgraph.graph import StateGraph, START, END

def route(state: CustomerTaskState) -> str:
    if state['intent'] in ('logistics_refund', 'order_query'):
        return 'order_flow'
    return 'faq_flow'

builder = StateGraph(CustomerTaskState)
builder.add_node('router', router_node)
builder.add_node('retrieve_knowledge', retrieve_knowledge)
builder.add_node('query_order', query_order)
builder.add_node('evaluate', evaluate_node)
builder.add_conditional_edges('router', route, {
    'order_flow': 'fanout_order',
    'faq_flow': 'retrieve_knowledge'
})
builder.add_node('fanout_order', lambda state: state)
builder.add_edge('fanout_order', 'retrieve_knowledge')
builder.add_edge('fanout_order', 'query_order')
builder.add_edge('retrieve_knowledge', 'evaluate')
builder.add_edge('query_order', 'evaluate')
builder.add_edge('evaluate', END)
app = builder.compile(checkpointer=MemorySaver())
```

原因：查知识和查订单没有依赖，可以并行；政策判断依赖订单和客户等级，必须串行；退款执行有副作用，必须幂等并记录检查点。新行为：可并行分支同时执行，join 后进入政策判断；Evaluator 失败时触发重规划或人工；重复请求命中幂等键后直接返回已提交结果。

验证方案：构造订单超时、重复请求、政策不允许三个用例，检查是否只执行一次退款、是否从最近检查点恢复、是否进入人工队列。未在当前环境实测，具体并行 join 与 checkpointer 语义需按 LangGraph 当前官方文档核验。

> 并行查知识
> 串行审政策
> 条件边重规划
> 幂等键护动作

# 08、演进

```text
[同一输入：物流延迟退款]
    |
    +--[V1] 串行八步，失败从头来 / 代价：延迟叠加、重复动作
    |
    +--[V2] 并行查知识与订单，条件边重规划，checkpoint 恢复 / 代价：状态和幂等复杂度上升
    |
[Trade-off]
得到：可控并行、可恢复、可审计；失去：简单线性脚本；边界：政策与动作必须串行，副作用必须幂等
```

正确性上，V2 把可并行和必须串行分开，减少无依赖等待。稳定性上，V2 用检查点和幂等键防止重复副作用。复杂度上，V2 需要状态模型、步骤契约和失败分类。成本上，V2 增加存储和审计事件，但降低人工冲正成本。适用范围是多系统、多步骤、有副作用的客服任务。遗留问题是 Evaluator 的判定标准、跨租户状态隔离和权限模型仍要细化。

> V1 求可见
> V2 求可控
> 得到并行速
> 失去简单性

# 09、洞见

## 9.1 编排的第一产物是状态所有权

反直觉判断：不是先画流程图，而是先定义谁拥有状态、谁只能读写哪些字段。Router 只能写路由字段，Planner 只能写计划字段，Orchestrator 拥有步骤状态，Evaluator 只能写判定。状态所有权不清，图越漂亮越难排查。

## 9.2 ReAct 适合局部，Planner 适合全局

反直觉判断：把全局规划交给 ReAct，往往不是更智能，而是更不可恢复。ReAct 在工具选择依赖当前观察时很强，但全局依赖、并行边界和副作用提交必须由 Planner 与 Orchestrator 掌握。

## 9.3 并行不是性能优化，是正确性边界

并行只应发生在无依赖且可幂等的查询步骤。政策判断依赖订单和客户等级，动作执行依赖政策，确认结果依赖动作回执。把不该并行的步骤并行，会把错误从延迟问题变成数据一致性问题。

## 9.4 Evaluator 不是打分器，是失败路由器

Evaluator 的价值不是最后给一个总分，而是在每个关键节点判断继续、重试、重规划、补偿还是人工。它必须消费结构化状态，而不是只读自然语言。

> 编排即状态
> 局部非全局
> 并行有边界
> 评估即路由

# 10、系统落地

原来平台只有一个 ReAct Agent 和工具清单，状态藏在对话里。本篇新增 Router、Planner、Orchestrator、Evaluator 四层，以及并行、串行、重规划三类步骤标记。现在能把物流退款任务拆成可执行图，并在订单超时后从检查点恢复，避免重复退款。

还缺三件事：第一，Evaluator 的判定数据集和人工复核标准；第二，多租户状态隔离和字段级权限；第三，跨语言、跨渠道的统一路由词典。下一步先把退款、改地址、查物流、开工单四类任务纳入同一状态契约，再补权限和审计。

> 原来单循环
> 现在分层图
> 能跑能恢复
> 还缺指标墙

# 11、小结

```text
Q1 → 串行链只适合低风险单步，复杂客服要用并行图加串行审批
Q2 → ReAct 管局部工具，Router、Planner、Orchestrator、Evaluator 分层管全局
Q3 → 混在一起会导致重复退款、工单错乱、审计缺口和人工兜底成本上升
状态 → 本篇交付一个可表达的客服任务 DAG 与 V1 串行 LangGraph 原型
```

> 问题有答案
> 状态可交付
> 并行串行清
> 重规划有据

# 12、作业

## 12.1 理解题：为什么 ReAct 不适合单独承担全局客服任务编排？

参考答案：ReAct 的交错推理与行动适合局部工具决策，但它不天然维护全局步骤依赖、并行边界、检查点、幂等和审计。全局编排需要状态所有权和失败恢复，应由 Router、Planner、Orchestrator、Evaluator 分担。

## 12.2 实战题：把查知识、查订单、查客户等级、判断政策、执行退款拆成并行与串行。

参考答案：查知识、查订单、查客户等级可并行；判断政策等待订单和客户等级，必须串行；执行退款等待政策结果，必须串行且幂等；确认结果等待退款回执。并行分支要有 join 和超时策略。

## 12.3 排障题：重复请求导致两次退款，优先查什么？

参考答案：先查动作日志和幂等键，确认同一 order_id 是否重复提交；再查 checkpointer 的 thread_id 是否稳定；最后查 Evaluator 是否把已提交动作判为失败并触发重跑。修复顺序是先幂等，再检查点，再重规划边界。

## 12.4 架构判断题：是否应该一开始就上多 Agent？

参考答案：不必。先定义状态契约和步骤图，单 Agent 加显式编排能跑通再拆多 Agent。多 Agent 会放大状态同步和权限复杂度，只有当任务域、工具集或责任边界确实需要隔离时才拆。

> 理解边界
> 实战补图
> 排障找因
> 判断取舍

# 13、思考

复杂客服任务的拆分，不是把八个步骤写成八段 prompt，而是定义一张有状态所有权、有并行边界、有串行审批、有失败路由的图。Router 决定走哪条路，Planner 决定步骤依赖，Orchestrator 决定状态与恢复，Evaluator 决定继续还是改道。

可复用的工程判断是：查询可并行，政策要串行，动作要幂等，失败要分类，重规划不能越过已提交副作用。只要这五条守住，Agent 数量增加才不会变成故障源。

> 复杂非多智
> 而是有边界
> 规划知进退
> 编排见真章

我是老李，在给一家全球智能客服平台做 FDE。平台同时服务多个企业，每个企业有不同项目、语言、渠道，后端接着 CRM、订单、支付、物流、工单和知识库。过去一个客服 Agent 能回答 FAQ 就算成功，现在客户要的是一条闭环：认出客户是谁，理解他为什么来，查到订单和知识，判断政策，给方案，执行动作，再确认结果。

FDE进化36记-第24记-复杂客服任务怎么拆给Planner与Router？

用全球智能客服案例拆解Router、Planner、Orchestrator与Evaluator，把复杂客服任务做成可并行、可串行、可重规划的执行图。

架构师

人工智能

后端

架构设计

复杂客服任务拆解需将Router、Planner、Orchestrator、Evaluator分层协作：查询步骤可并行，政策判断与动作执行须串行，动作幂等防重复，失败时从检查点恢复而非重跑全局，确保可控、可审计、可恢复。

数据一致性

代码解释

路由器

LangGraph

路由

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

FDE进化36记-第24记-复杂客服任务怎么拆给Planner与Router？-腾讯云开发者社区-腾讯云

FDE进化36记-第24记-复杂客服任务怎么拆给Planner与Router？

FDE进化36记-第24记-复杂客服任务怎么拆给Planner与Router？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐