上个月我们团队把一类反复出现的客户工单交给一套多智能体工作流后，单人处理时长从平均 6 小时压到 40 分钟。但真正难的不是把它搭出来，而是让 agent 从「能聊天」变成「能上岗」：也就是能调工具、能走审批、能在拿不准时交还给真人。本文给一套能直接跑的编排骨架，并拆开三个容易翻车的环节。
一、原理：企业多智能体为什么不能只靠一个大模型
把工单直接丢给单个大模型，它确实能吐出一段像样的答复。可一旦进入真实业务，问题就来了：答复要不要查知识库？要不要拉订单状态？涉及退款投诉能不能直接外发？这些动作单模型做不了，得靠「协调者 + 专员」的分工来补。
协调者（coordinator）负责读懂工单、判定类型、决定交给谁；技术专员去命中知识库，账单专员去调订单接口，遇到高风险（投诉、退款、或者压根判不出类型）的工单，则一律推进人工审批闸门，绝不自动外发。这套分工的核心纪律只有一句话：凡算不出来或判不准的，交人，不让模型猜。
据麦肯锡的研究，部署多智能体的企业效率提升区间大约在 20% 到 35%（来源：麦肯锡相关报告），但这是行业区间，不是你搭完就能自动拿到的数字。能不能吃到这块效率，关键看闸门设得对不对，而不是看模型换没换。
二、完整可复制的代码：一个多智能体编排骨架
下面这段脚本不连任何大模型、不调任何外部接口，纯规则把「分类 → 分工 → 审批」的骨架钉死。它正好对应你在 Dify 里要画的节点，先拿它在本地跑通逻辑，再搬上平台会稳很多。
# multi_agent_workflow.py：企业工单多智能体编排骨架（零外部依赖，规则版可跑）
import sys
from dataclasses import dataclass
@dataclass
class Ticket:
tid: str
text: str
kind: str = "unknown" # tech / billing / complaint
draft: str = ""
approved: bool = False
needs_human: bool = False
def classify(t: Ticket):
"""协调者：按关键词判定工单类型；判不出就交人工。"""
s = t.text
if any(k in s for k in ("退款", "投诉", "赔偿")):
t.kind = "complaint"; t.needs_human = True
elif any(k in s for k in ("账单", "发票", "扣费")):
t.kind = "billing"
elif any(k in s for k in ("登录", "报错", "接口", "bug")):
t.kind = "tech"
else:
t.kind = "unknown"; t.needs_human = True # 判不出必须交人，不能猜
return t
def tech_agent(t: Ticket, kb):
"""技术 Agent：命中知识库则给答复，否则标空交人工。"""
for q, a in kb.items():
if q in t.text:
t.draft = a
return t
t.draft = ""; t.needs_human = True # 没查到不能编
return t
def billing_agent(t: Ticket, orders):
"""账单 Agent：调订单状态（此处用本地查表模拟接口）。"""
oid = next((w for w in t.text.split() if w.startswith("ORD")), None)
if not oid or oid not in orders:
t.draft = ""; t.needs_human = True
return t
t.draft = f"订单 {oid} 当前状态：{orders[oid]}"
return t
def human_approval(t: Ticket, allow_auto=False):
"""人工审批闸门：投诉与未知一律交人；allow_auto 仅放开低风险。"""
if t.kind == "complaint" or t.kind == "unknown":
t.approved = False
return t
t.approved = bool(allow_auto) # 默认交人，不自动外发
return t
def run(t: Ticket, kb, orders, allow_auto=False):
classify(t)
if t.kind == "tech":
tech_agent(t, kb)
elif t.kind == "billing":
billing_agent(t, orders)
human_approval(t, allow_auto)
return t
if __name__ == "__main__":
kb = {"登录": "请先清除浏览器缓存，再重试登录；若仍失败请提供账号尾号。"}
orders = {"ORD1001": "已发货"}
# 正控：技术工单命中知识库，自动放行
a = run(Ticket("T1", "APP 登录 报错"), kb, orders, allow_auto=True)
assert a.kind == "tech" and a.approved and "登录" in a.draft
# 负控：投诉必须交人工，哪怕开了自动也不准外发
b = run(Ticket("T2", "我要退款 赔偿"), kb, orders, allow_auto=True)
assert b.kind == "complaint" and not b.approved
# 缺数据：未知工单交人工
c = run(Ticket("T3", "hello world"), kb, orders)
assert c.kind == "unknown" and not c.approved
print("multi_agent_workflow selftest OK")
sys.exit(0)
跑 python multi_agent_workflow.py 即可通过自检。它不碰你的业务系统，只把「谁来处理、要不要人审」这条主干验证掉。等逻辑无误，再把它换成真实的知识库检索和订单接口。
三、把骨架映射到 Dify 工作流节点
Dify 的可视化工作流，本质就是把上面的函数画成节点连起来。对应关系很直接：
- 开始节点：接收工单文本，作为变量传入。
- LLM 节点（分类）：用一段提示词让模型输出
tech / billing / complaint / unknown四选一，注意要在提示里写明「判不出就输出 unknown」。 - 条件分支节点：按分类结果走四条路。
- 技术分支：接「知识库检索」节点，命中则返回答案，未命中转人工。
- 账单分支：接「代码节点」，在代码里调你的订单查询接口（上面的
billing_agent就是这块的逻辑）。 - 投诉 / 未知分支：直接接「审批」节点，配置成需要人工在 Dify 后台确认后才往下走。
- 结束节点：低风险自动外发，高风险转人工工单。
一个常踩的坑是：Dify 的条件分支默认是「命中即走」，如果你漏写 unknown 这一支，所有没被关键词覆盖的工单会掉进默认分支，结果要么错发、要么静默丢失。把 unknown 显式画出来，和脚本里的兜底逻辑对齐，就不会出这种事。
四、工程取舍：哪些该让 agent 自动干，哪些要交人
不是所有环节都适合自动化。我的经验是拿「风险 × 可逆性」两轴来切：
低风险且可逆的，比如「查知识库后给一段标准答复」「查订单状态回一句进度」，可以让 agent 在审批闸门放开后自动外发。这类动作错了也好补救，人工抽检即可。
高风险或不可逆的，比如「退款话术」「投诉安抚」「任何涉及钱或情绪的外发」，要保留人工确认。联想乐享在 618 期间用 agent 承接了官网约一半的售前咨询、转化提升约 30%（来源：公开报道），能吃到这个效果，前提是它把「能自动答复」和「要人把关」的边界划得很清楚，而不是一股脑全自动。
另一个取舍是：先上规则版闸门，再上模型。规则版零成本、可审计、能全量跑，先把明显该交人的工单拦下来；模型负责处理规则覆盖不到的语义判断。两者是互补，不是替代。
五、踩坑：三个容易翻车的地方
坑一：把「能答对」当成「能上岗」。 很多团队验收时只看模型答得准不准，上线才发现它从没真正调过工具、也没走审批。上岗的判据应该是「动作有没有发生、风险有没有被闸门拦住」，而不是「话术好不好听」。
坑二：分类兜底写成「默认 tech」。 这是真实事故高发点。一旦默认归到技术类，未知工单就会被自动外发，而它本该交人。正确做法是默认归 unknown 并强制人工，宁可多一道人工，也别错发。
坑三：审批节点被跳过。 在 Dify 里如果条件分支的某条路径忘了接审批节点，或者审批配置成了「自动通过」，高风险工单就会悄悄溜出去。上线前务必用一条投诉工单实跑一遍，确认它卡在审批环节、没有外发。
辩证：规则版不是终点
另一面要讲清楚：上面的规则骨架抓的是「类型分层」和「风险闸门」，抓不到「语义层」的错误。比如用户说「帮我改密码」，agent 理解成「注销账号」就去执行，规则根本发现不了。这类问题要靠评测集加人工抽检来补。不过在预算有限、工单海量的早期，先把这套便宜的规则闸门装上，性价比很高。要警惕的是：别因为规则过了，就以为 agent 真的上岗了。
互动思考题
- 你的业务里，哪些环节现在还是纯人工，其实已经能交给 agent 跑一遍？
- 如果让你给工单加第四类判据，你会先拦哪一种风险？
- 规则闸门和模型判断，你在团队里会先上哪一个？
数据与事件来源
- 麦肯锡相关研究（部署多智能体的企业效率提升约 20% 至 35%，行业区间引用）
- 联想乐享 618 期间 agent 承接官网售前咨询约 50%、转化提升约 30%（公开报道引用）
- Dify 官方工作流文档（开始 / LLM / 条件分支 / 知识库检索 / 代码节点 / 审批节点相关说明）
- 上述编排骨架为本文可运行示例，对应 Dify 节点映射为作者实践总结
你踩过 agent 自动外发翻车的坑吗？欢迎在评论区聊聊你的兜底方案；如果这篇对你搭企业工作流有用，点个收藏，下次画 Dify 节点时能直接翻出来对照。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/superdangbo/article/details/168975610
