OpenAI客服分流与交接模式研究

它解决什么问题

生产级客服 Agent 的第一个坑往往不是模型能力，而是「谁来接、接到哪、什么时候交出」。一个工单进来，如果路由逻辑、专家交接、护栏和上下文延续都散落在业务代码里，代码会很快变成一堆 if/else 拼起来的黑盒：升级规则写死在提示词里，交接时上下文丢失，敏感操作缺少硬约束，出问题也难以回放。

这个技能把 OpenAI 官方的 customer service agents demo 当作一份参考工作流，让你在动手写生产支持 Agent 之前，先看清分流与交接到底由哪些部分组成。

核心能力与关键步骤

• 分流（triage）：先用一个入口 Agent 解析用户意图，判断问题属于哪一类，再决定是直接回答、转给专家，还是先收集补充信息。
• 专家交接（specialist handoff）：当入口 Agent 判断自己无法继续时，把控制权连同对话历史交给对应领域的专家 Agent，而不是重新问一遍问题。
• 护栏（guardrails）：在执行动作前后设置校验，例如检查输出是否越界、是否包含敏感信息、是否触碰了不允许的外部操作。
• 工单编排（support-case orchestration）：由 Python 后端统一承担编排逻辑，把多轮会话、Agent 切换和状态流转收敛到一处；前端 UI 通过 Node.js/Next.js 与后端协作呈现。
• 环境依赖：需要 OpenAI API key，接口层依赖 OpenAI Agents SDK 与 ChatKit，OPENAI_API_KEY 可放在 python-backend 根目录的 .env 中，由 python-dotenv 加载。

阅读时建议按「先读编排层，再读单个 Agent 的职责边界」的顺序进行，这样交接发生的时机和原因会比较清楚。

适用边界与注意点

• 它是 demo 级别的参考实现，主要价值在于展示结构与职责划分，不等于可以直接上线的生产方案。
• 语料来自开源仓库的 README 提取，遇到版本变化时需要回到上游确认当前行为，不要把它当作稳定契约。
• 实际落地时仍需自行补齐鉴权、限流、审计、人审回退与失败重试等工程能力，这些在参考工作流中并未覆盖。