我最近在做一个酒店客服 Agent 的改造，起点不是从零开始，而是从一套之前基于 LangChain 自建的项目出发，逐步迁移到 OpenClaw。这个过程中最重要的判断是：第一阶段不要试图把所有系统都接上，也不要一开始就追求“全自动处理”。先把知识问答、SOP 路由、回答边界和转人工规则跑通，才是更稳的路线。
很多 AI 客服项目失败，并不是因为模型不够聪明，而是因为一开始目标太大。既想回答 FAQ，又想查订单，又想创建工单，还想自动取消、退款、赔付。结果每条链路都没有真正闭环，出了问题也很难判断到底是知识库错、工具错、模型错，还是流程边界错。
第一阶段我只做三件事
我把第一阶段拆成三个明确目标。
- 第一，能基于知识库回答问题。员工问酒店政策、FAQ、业务术语、SOP 操作步骤时，Agent 必须先从知识库召回证据，再组织回答。
- 第二，能按 SOP 做路径判断。同样是“取消”或“查无预订”，不同岗位、不同流程、不同风险等级，处理路径不一样。Agent 不能只给泛化建议。
- 第三，知道什么时候停止。不能解决的问题要明确转人工、带教或组长，不能为了显得智能而继续编。
这三个目标看起来朴素，但它们决定了系统能不能稳定迭代。先把“该回答什么、依据什么回答、什么时候不回答”定义清楚，后面接订单查询、工单、取消、退款工具时，才不会变成一堆不可控的工具调用。
为什么要迁到 OpenClaw
自建 LangChain 的好处是灵活，坏处也是灵活。所有会话、工具、记忆、路由和提示词约束都需要自己维护。早期验证可以接受，但当项目开始进入客服流程时，就会出现几个问题。
- Agent 行为约束散落在代码和 Prompt 里，难以审计。
- 知识库和 SOP 的边界不清楚，容易混在一起。
- 训练模式、正式模式、评测模式缺少统一结构。
- 新增工具时，安全门禁和确认机制需要重复建设。
OpenClaw 的价值不只是“能跑 Agent”，而是它天然有 workspace、AGENTS.md、TOOLS.md、memory 和插件工具这类结构，可以把 Agent 的行为、知识、工具和运行边界拆开管理。对于客服系统来说，这比单纯写一段 Prompt 更接近生产要求。
我对知识库和 SOP 的拆分
这次改造里，我把知识库和 SOP 做了明确区分。
- 知识库是 RAG 检索内容，包括 FAQ、政策、业务术语、场景卡片、已整理的 SOP 文档。
- SOP是 Agent 必须遵守的处理准则，包括先查什么、怎么判断、哪些信息不能编、什么时候转人工。
换句话说，知识库告诉 Agent“知道什么”，SOP 告诉 Agent“应该怎么做”。这两个概念如果混在一起，系统很容易出现问题：Agent 可能把一段知识当成操作许可，也可能把流程规则当成事实答案。
第一阶段不追求全自动
我现在更倾向于把第一阶段定义成“员工辅助型 Agent”，而不是“全自动客服机器人”。员工在工作过程中向 Agent 提问，Agent 给出政策依据、操作步骤、风险提醒和升级建议。遇到不确定、需要系统写入、涉及退款赔付或真实订单变更的场景，必须转人工或进入确认流程。
这并不保守。恰恰相反，这是让系统能商业化落地的前提。客服场景里，回答错一个 FAQ 可能只是体验问题，但错误取消订单、错误退款、错误承诺赔付就是生产事故。第一阶段先把只读知识问答和 SOP 指导做稳，比急着接写接口更有价值。
后续怎么扩展
当第一阶段跑稳后，后续可以逐步加能力。
- 接入订单查询工具，让事实判断来自系统，而不是模型推测。
- 接入客服系统用户画像，由外部系统分流，Agent 内部只做路由。
- 增加训练模式，展示 RAG 过程、命中文档、置信度和训练师反馈入口。
- 对真实写入工具增加 dry-run、pending action、人工确认、结果复查等安全门禁。
这条路线的核心是渐进式落地：先让 Agent 成为可靠助手，再让它处理更多流程，最后才考虑局部自动化。
结语
这次迁移让我更加确定一点：客服 Agent 的关键不是“能不能聊”，而是“能不能在流程边界内稳定工作”。OpenClaw 给了我一个更适合生产治理的结构，而第一阶段最重要的工作，就是把知识问答、SOP 路由和回答边界打牢。