客服升级单：按工单挑专家 Agent

场景

典型场景：客服团队一天里绝大多数工单流程一模一样——分类、起草回复、质检；升级单则各有各的查法：物流件要查订单和承运记录，账单件要查扣款和订阅，两类工单需要的专家完全不同。用一套写死的流程覆盖全部，就得在每张工单上都跑一遍用不上的分析步骤。

示例把这两种形态分开演示：形态会变的走运行时决策，形态固定的走显式任务图，并在源码注释里说明了取舍——固定路径若也用协调者，等于每次请求都重新推导同一张图，还要多付一次合成调用。

方案

表中模型为示例仓库的默认配置；实际选型在方案阶段按场景确定。

cookbook 脚本走 runTeam()：协调者拿到工单原文、账户证据、政策摘录，输出一份 JSON 任务数组（标题、描述、执行人、依赖），示例通过 coordinator.instructions 把选人规则追加进协调者系统提示。两个内置场景由 TICKET_SCENARIO=shipping（默认）或 billing 切换，编排层与团队的并发上限都设为 3。

Express 应用走 runTasks()：三个任务在路由处理函数里声明一次，OMA 按拓扑序执行，把上游产出注入下游提示的 ## Context from prerequisite tasks 段。八个 Agent 全部用 Zod outputSchema 约束输出；都未声明 tools 或 toolPreset，按 OMA 默认拒绝的授权规则解析为零个内置工具。

结果

可运行产物与验证方式：

都需要 API key。cookbook 脚本头部写明需要 OPENAI_API_KEY，并可通过 OPENAI_BASE_URL + OMA_MODEL 指向任意 OpenAI 兼容端点，或用 OMA_PROVIDER=copilot 配合 GITHUB_COPILOT_TOKEN / GITHUB_TOKEN。Express 应用默认需要 DEEPSEEK_API_KEY。

能看见协调者的选人结果。脚本跑完打印任务总数，并逐行列出每个任务的状态、标题、执行人——物流场景下应当看到 billing-specialist 未被派活，账单场景反之。随后打印 response-specialist 的结构化 JSON 与协调者的合成结论；整体失败时把进程退出码置为 1。

Express 应用可独立起服务。npm install && npm start 后监听 3000（可用 PORT 覆盖），POST /tickets 传 {subject, body}，返回 category / urgency / draft_reply / qa_notes 四字段。

错误路径是显式的。启动时逐个 Agent 校验对应 provider 的 key，缺失即报错退出；请求期 400 对应请求体非法，502 对应流水线未成功或某个 Agent 未产出结构化结果，504 对应 60 秒超时（超时会 abort 在途的 LLM 调用）。

自带冒烟测试。npm run smoke 在临时端口起服务、发一条登录失败工单、用响应 schema 校验，通过打印结果并以退出码 0 结束，失败则退出码 1。

可核实

与元定义的关系

本页素材是 open-multi-agent 官方仓库里的 cookbook 示例与配套 Express 应用，由元定义维护。

如果你要把工单分类、专家分诊、回复起草、质检做成一套能接进现有客服系统的服务——固定流程写成显式任务图，升级单交给运行时决策——元定义对应的服务见下方「相关服务」，从这里进入 AI Agent 定制开发 →