大模型负责理解或生成内容;工作流负责按预先规定的步骤办事;智能体会在授权范围内根据当前情况选择下一步和工具。三者可以一起使用,但不是同一个东西。用“处理一张客服工单”来拆开看,选择哪种方案会更清楚。
同一张工单,三种能力分别做什么
| 能力 | 在客服场景中的角色 | 它单独做不到什么 |
|---|---|---|
| 大模型 | 理解用户说“包裹没收到”,把问题归纳成简短摘要,起草礼貌答复 | 没有连接订单系统时,不能知道包裹真实物流状态 |
| 工作流 | 固定执行“查订单→核对物流→按规则分支→生成回复→人工审核” | 未预先设计的异常情况,可能需要新增分支或人工介入 |
| 智能体 | 接到目标后,在允许的工具中判断先查订单、再查知识库,还是直接升级给人工 | 不能因为会选择工具就自动拥有退款、改地址或查看所有客户数据的权限 |
LangGraph 官方文档把工作流描述为预先确定执行路径,把智能体描述为能动态决定流程及工具使用。这有助于划清边界,但实际产品可以将两者结合。

把一张工单拆成可检查的输入和输出
假设客户说:“订单 A-100 显示已签收,但我没收到,想退款。”这是一条虚构示例,不是实际客户记录。系统至少需要用户身份、订单归属、订单状态和处理规则;模型只看到这句话,不能确认包裹位置,也不能承诺退款。
| 环节 | 示例动作 | 核对点 |
|---|---|---|
| 大模型 | 将诉求归为“签收异常+退款请求”,生成待核实摘要 | 摘要有没有误写成“已经退款” |
| 固定工作流 | 先校验订单是否属于当前用户,再查真实物流状态,按规则转人工 | 缺订单号、接口超时、归属不符时能否停止 |
| 智能体 | 若允许,可在订单查询、物流查询和帮助文档中选择下一项只读工具 | 是否只调用授权工具,是否留下调用记录 |
| 人工 | 确认异常、退款资格与实际处理动作 | 真实业务系统是否返回成功记录 |
一条合格的暂时回复可以是:“我已记录您的签收异常,需要先核对订单和物流;退款申请将由售后人员确认后处理。”如果订单接口没有返回结果,系统应明确“暂时无法核实”,不能根据模型生成的文字显示“已退款”。
什么时候先用工作流
如果步骤稳定、规则清楚,例如“收到咨询后核对订单状态,再套用已批准的回复模板”,先用工作流更容易检查每一步。订单号缺失、物流接口失败、用户要求退款,都可以走明确分支。大模型可以负责摘要和草拟文字,关键状态仍从订单系统读取。
可以先写出最小决策表:没有订单号→请用户补充;订单不属于当前用户→停止查询并提示核对账号;订单属于用户但物流接口失败→转人工;查询成功且仅需解释政策→生成草稿并由客服复核。把这四条跑通,比先给智能体开放所有工具更容易验收。
什么时候考虑智能体
如果用户问题变化大,需要在多个资料库和工具之间选择路线,例如既问商品说明,又问订单进度,还提出售后诉求,智能体能帮助决定下一步查什么。设计时应限制可调用的工具、可读取的客户范围、最大执行轮次和超时处理。退款、改订单等写操作要经过已有权限和审核流程;模型生成一句“已处理”不能替代真实系统状态。
在这个例子里,允许的智能体工具可以先限定为“查当前用户订单”“查对应物流”“查已批准的售后政策”,不开放退款写入。智能体应返回用过哪些工具、从哪个真实结果得出建议;如果查不到,就交回工作流的失败分支。产线设备的工业智能体工单示例也遵循类似的只读起步与人工确认原则。
做一个小样例检验你的方案
- 选三种匿名工单:普通物流查询、缺订单号、物流与退款混合问题。
- 写出各类工单的期望动作,以及必须由人工确认的条件。
- 先用固定工作流跑通普通物流查询,再让模型只负责理解问题和起草答复。
- 需要动态选择资料或工具时再加入智能体,并记录它实际调用了什么、为什么调用。
- 对照原始工单检查结果:订单状态有没有来源、是否错读客户数据、失败时有没有交给人工。
用什么标准比较两种方案
准备匿名的普通咨询、缺订单号、订单归属不符、接口超时和混合诉求各类案例。比较两种方案是否都能正确取数、阻止越权、在失败时转人工,并记录处理时间和人工修改量。不要只比较回答是否“像人说话”;客服最重要的订单状态与退款状态必须来自真实系统。
可按一句话记忆:模型处理内容,工作流固定步骤,智能体在边界内选择步骤。真正可用的系统还需要数据接口、权限和复核机制;名字里有“智能体”,并不等于业务动作已经安全完成。
Ai菜鸟网。发布者:AI小管家,转载请注明出处:https://www.alyyhw.com/29709.html