2023-2024 年，大量企业完成了大模型客服的从 0 到 1 上线。进入 2025-2026 年，一个更根本的问题浮出水面：大模型客服能不能真正帮企业"办事"——不只是回答一个 FAQ，而是查到客户的订单信息、自动创建一张服务工单、把客户投诉自动派发到对应部门，并在问题解决后触发回访。
回答这个问题的关键不在模型推理能力，而在系统集成架构。模型负责理解客户意图和生成回复，但调用 CRM、查询订单、创建工单、回写状态这些业务动作，需要一层明确的任务规划和工具编排层来承接。
从问答到执行：Agent 的任务规划模型
传统 AI 客服的工作模式是"一问一答"：客户提问 → 检索知识库 → 生成回复。这种模式天然不涉及系统调用。但当 AI 客服要向业务执行演进时，工作模式必须升级为"任务规划"：
客户意图 → 任务拆解 → 工具选择 → 参数提取 → 系统调用 → 结果处理 → 回复生成
这一链条中的关键变化是"任务拆解"和"工具选择"。模型不再直接输出回复，而是先判断：当前客户想要什么？需要查什么系统？需要调用什么接口？返回的数据应该怎么组织成回复？
意图到任务的映射：以"帮我查一下订单号 ORD2025XXXX 到哪了"为例，Agent 的任务规划层需要完成：
- 识别意图为"物流查询"
- 确认必要参数：订单号（已提供）
- 匹配可用工具：物流查询 API
- 构造工具调用：
queryLogistics(orderId: "ORD2025XXXX") - 将 API 返回的数据转换成自然语言回复
这个映射过程不是简单的 if-else 路由，因为客户输入具有不确定性——订单号可能用"O"开头还是"ORD"开头、客户可能只说"查个快递"而不给单号。任务规划层需要处理参数缺失时的追问逻辑、多意图并行时的调度优先级、以及工具调用失败时的降级策略。
工具编排层：Flow + Tools 的设计模式
任务规划确定了"要做什么"，工具编排层解决的是"怎么做"。
在需要对接多个业务系统的场景中，工具编排层通常需要提供三个核心能力：
1. 工具抽象与注册
每个业务系统的能力（CRM 客户查询、订单状态查询、工单创建、审批状态回写）需要被抽象为可调用的工具单元。每个工具单元需要声明：
- 输入参数（schema）：如工单创建需要
customerId、problemType、description、priority - 调用方式：HTTP API、gRPC、数据库查询、消息队列
- 返回结构：成功响应格式、错误码、超时策略
- 权限范围：哪些 Agent 角色可以调用
在合力亿捷 MPaaS 的架构中，Tools 层承担这一角色——每个工具对应一个业务系统操作，通过 Flow 编排决定调用顺序和条件。Tools 可连接订单查询、物流查询、客户信息查询、工单创建、预约确认、进度通知、CRM/ERP 调用等业务动作。
2. Flow 编排：状态机 + 大模型双轨
纯 LLM 驱动的 Agent 在客服场景中面临一个固有风险：模型可能跳过关键步骤（如跳过工单派发直接输出"处理完成"），或者因为推理偏差执行了错误的系统操作。这在客服场景中是不可接受的——工单派错部门、订单状态误改都会产生真实业务后果。
更可靠的方案是状态机 + 大模型双轨架构：
- 状态机轨道：定义业务流的固定节点——意图识别 → 信息采集 → 系统查询 → 结果判断 → 建单/转人工/结束。每个节点的迁移条件和可执行操作由业务规则预先编排。
- LLM 轨道：在状态机框架内提供灵活的语义理解——客户的口语化表达映射到固定意图、不完整的参数通过多轮追问采集、API 返回的非结构化数据重组为自然语言回复。
两条轨道的关系不是二选一。状态机保证流程可审计、不跳步，LLM 保证交互自然、不机械。合力亿捷 MPaaS 的 Flow 正是以这种双轨架构运行——Flow 承载了"识别意图、追问信息、判断条件、调用工具、创建工单、返回结果、转人工"等流程节点，每个节点内部调用 LLM 处理具体的语义理解和生成。
3. 参数提取与上下文传递
系统调用的前提是参数完整。客户说"帮我查下王先生上次报修的东西修好了没"，Agent 需要从中提取出 customerName="王先生"、problemType="报修" 等参数，然后通过 CRM 查询匹配的客户 ID，再用客户 ID 查最新的工单状态。
参数提取层需要支持：
- 实体抽取：从自由文本中提取结构化参数
- 参数补全：缺失的字段通过追问采集
- 跨工具参数传递：工具 A 的输出作为工具 B 的输入
- 上下文缓存：同一会话内采集的参数在后续话轮中自动复用
在合力亿捷的流程设计中，Flow 的节点可以配置参数校验规则——缺少必要字段时不走工具调用、先触发追问节点。同时，Agent 在通话中自动识别的意图、追问的字段、查询的结果，都在会话上下文中保留，转人工时传递给坐席。
闭环架构：从客户触达到运营复盘的完整链路
单一的系统调用（查个订单、建个工单）只是工具编排的原子操作。企业客服 Agent 要真正进入业务闭环，需要一条从客户触达到运营复盘的数据链路。
客户触点 → Agent 接待 → 任务规划 → 工具编排 → 系统执行 ↓ 运营复盘 ← 质检/VOC ← 服务记录 ← 结果输出
这条链路中几个关键节点的技术实现值得单独讨论：
工单的生命周期管理
工单不是一次创建就结束的。从创建、派发、处理、升级到关闭和回访，每个状态变更都可能涉及业务系统和客服系统的双向数据同步。
在工单系统的接口设计中，建单接口通常不是最大的挑战（标准 REST API 即可），真正的技术难点在于：
- 状态一致性：客服 Agent 创建的工单进入业务系统后，业务系统更新工单状态时，客服系统需要实时感知。实现方式可以是 Webhook 回调、消息队列订阅或轮询。
- SLA 计时与预警：工单的 SLA（服务水平协议）计时需要从派发开始计算，超时需要触发通知。这部分逻辑通常在工单系统中实现，但预警消息需要由客服系统推送给坐席。
- 转派/升级的权限判断：工单转派到其他部门时，Agent 需要判断目标部门的处理范围和当前坐席的转派权限，不允许越级转派或跨部门错误路由。
合力亿捷工单系统支持 SLA 提醒、超时预警、转派、升级、退回、工单池抢单等全生命周期操作，并通过与呼叫中心和在线客服系统的联动，让 Agent 在通话或会话中完成建单和状态查询。
CRM 集成的字段映射
客服场景中的 CRM 调用通常是读操作多于写操作——查客户等级、查历史订单、查会员权益。但与知识库的 RAG 检索不同，CRM 查询返回的是结构化数据，且这部分数据通常是动态的、权限敏感的。
Agent 调用 CRM 时的典型技术链路：
- 客户识别：通过来电号码、会话中的手机号或会员 ID 确认客户身份
- CRM 查询：调用 CRM 的客户资料接口，返回客户等级、消费记录、服务历史
- 数据注入：将查询结果注入到会话上下文中，供 Agent 应答参考
- 权限控制：CRM 接口本身完成数据权限过滤，Agent 只读取有权限的数据
在这个过程中，合力亿捷的呼叫中心和在线客服系统支持来电弹屏和客户信息查询——坐席在接起电话时即可看到 CRM 客户资料，Agent 在通话中也可以引用这些信息进行有针对性的应答。
数据回写与审计
工具调用的另一个方向是写操作：工单状态更新、服务记录写入、客户标签修改。这些写操作需要满足审计追溯的要求——谁（哪个 Agent）、什么时间、调用了哪个系统的什么接口、传入和返回了什么数据。
审计日志的技术实现方案：
维度 |
实现方式 |
调用记录 |
每个工具调用的入参和出参持久化到操作日志表 |
会话关联 |
每条调用记录关联到对应的会话 ID 和客户 ID |
权限追溯 |
确认调用时使用哪个身份凭据（bot / user / 系统账号） |
异常标记 |
调用失败或返回异常状态码时自动标记为待人工确认 |
集成模式的选择：API 直连 vs 低代码编排 vs 消息中间件
对接 CRM 和工单系统的具体技术选型取决于系统现状和集成复杂度。
集成模式 |
适用场景 |
优点 |
限制 |
API 直连 |
业务系统有成熟 REST/gRPC 接口 |
延迟低、实现直接 |
每个系统独立开发适配，缺乏编排能力 |
低代码编排 |
需要多系统串并联、有条件分支 |
可编排复杂流程、可视化维护 |
对系统接口规范性要求较高 |
消息中间件 |
高吞吐、异步解耦、跨系统状态同步 |
削峰填谷、解耦 |
不适合实时问答场景 |
对于多数企业客服场景，API 直连 + 低代码编排的组合是实际使用较多的模式：高频且简单的查询走 API 直连（如查订单状态），涉及多步骤和条件分支的流程走低代码编排（如"客户投诉 → 创建工单 → 通知坐席 → SLA 监控"）。
合力亿捷 MPaaS 的 Tools 层支持 API 接入和系统集成，Flow 层提供低代码编排能力，可以根据业务场景灵活组合——一个意图的完整流程可以在 Flow 中编排为多个节点，每个节点调用不同的 Tools，串成一条可审计、可运营的业务闭环。MPaaS 同时支持多模型调度和运行监控，集成的系统接口可以在一个平台上统一管理。
从架构到业务价值的两个验证点
当技术架构搭建完成后，有两个验证点可以判断 CRM 和工单系统集成是否真正起了作用：
验证一：一条需要系统调用的请求，AI 能否独立完成？
比如客户说"帮我看看上次报修的空调修好没"。验证路径：Agent 是否识别到意图（报修进度查询）→ 采集客户身份 → 调用 CRM 匹配 → 调用工单系统查最新状态 → 输出结果。如果这个链路中任何一个节点需要人工介入才能继续，集成层就存在缺口。
验证二：转人工后，客户是否需要重复描述？
客户在 AI 端已经说了"查 ORD2025XXXX 的物流"，转人工后坐席应直接看到这个意图、订单号和查询结果。如果坐席接起电话问"您想查什么"，说明上下文传递层没有做好。合力亿捷的通话 Agent 在转人工时可以保留客户意图、对话摘要和已采集信息，AI 原生工作台将这些信息展示在坐席接待界面上，减少客户重复描述。
这两个验证点对应的不是模型能力，而是任务规划、工具编排和上下文传递的系统能力。架构设计到位后，AI 客服才能从"能回答"走向"能处理"。
