做客服 Agent 时，我最早踩过的一个坑，是把所有东西都往 Prompt 里塞。FAQ 放进去，SOP 放进去，工具说明也放进去，最后再加一堆“你必须”“你不能”。短期看起来有效，但只要场景稍微复杂，Agent 就会开始混淆：它不知道哪些内容是知识，哪些内容是流程，哪些内容必须查工具。
后来我把这个问题重新拆了一遍，核心只有一句话：RAG 负责知道什么，SOP 负责怎么做，工具负责实时事实和动作。
RAG 不是 Agent 的行为准则
RAG 的职责是提供依据。它可以告诉 Agent 某条政策、某个 FAQ、某段 SOP 原文里写了什么，但它不应该直接承担行为控制。比如知识库里写着“规则外取消需要联系酒店确认”，这只是一条知识；真正的行为准则应该在 Agent 的 SOP 里明确写成：未取得酒店或渠道确认前，不得承诺免费取消，不得执行真实取消。
如果把这两者混在一起，Agent 就可能出现一个很危险的倾向：只要检索到相关文字，就以为自己有权执行后续动作。客服系统里，这种错误不能接受。
SOP 是 Agent 的操作系统
我现在更愿意把 AGENTS.md 看成 Agent 的操作系统。它不负责堆知识，而是负责约束行为。
- 哪些问题属于当前 workspace。
- 哪些问题必须先检索知识库。
- 哪些问题必须先查订单事实。
- 哪些字段不能由模型猜测。
- 哪些场景必须转人工或带教确认。
- 哪些动作只允许 dry-run，不允许真实写入。
这些东西写清楚以后，Agent 才不会每次都靠模型自由发挥。对于生产环境来说，可控性比“灵活回答”更重要。
工具调用要分三类
客服 Agent 的工具不能一股脑开放。我现在会按风险把工具分成三类。
- 只读查询工具：例如订单查询、订单详情、取消原因列表。它们可以提供实时事实，但不改变业务状态。
- dry-run 计划工具：例如生成取消计划、生成工单处理步骤、生成逆向回填预案。它们只做结构化判断，不提交真实动作。
- 真实写入工具：例如取消订单、退款回填、创建工单。这类工具必须有二次确认、pending action、人工确认文本和执行后复查。
这套分类看起来麻烦，但非常必要。因为 Agent 一旦具备写能力，就不能再只靠“请谨慎操作”这种提示词来约束。
回答边界怎么判断
客服 Agent 判断一个问题是否可回答，不应该靠枚举关键词。关键词只能做辅助，不能做核心逻辑。更成熟的做法是结合三类信号。
- 范围信号：问题是否落在当前业务域，例如酒店客服、政策、订单、SOP、异常处理。
- 证据信号：RAG 是否召回足够相关的知识片段，证据是否能支撑结论。
- 风险信号：问题是否涉及退款、赔付、真实订单变更、客户承诺、敏感信息。
如果范围不匹配，就礼貌拒答并引导用户提供酒店客服相关信息。如果证据不足，就说明缺什么资料，建议人工确认。如果风险高，就算能回答一部分，也要把动作交给人工或确认流程。
训练模式和正式模式要分开
另一个很关键的实践，是把训练模式和正式模式拆成不同 workspace。训练模式可以展示匹配过程、RAG 片段、置信度和训练师反馈入口；正式模式则要更克制，只输出员工真正需要执行的结论和步骤。
如果把训练信息直接带到正式环境，用户体验会变差，甚至可能暴露内部判断过程。反过来，如果训练环境不展示过程，训练师又无法判断 Agent 到底哪里错了。所以两套 workspace 分开，是更清晰的工程边界。
结语
AI 客服不是聊天机器人。它更像一个受控的流程协作者。RAG、SOP 和工具调用各自承担不同职责：RAG 给证据，SOP 管行为，工具查事实或执行动作。只有这三条线分清楚，Agent 才能从“会回答”走向“能落地”。