三代理架构+MCP：客服AI如何做到读写分离与人工兜底

大多数客服 AI 教程都在演示同一个套路：一个提示词挂上十几个工具，看起来无所不能。但真正上线后，这种单代理方案往往撑不过第一个月——模型混淆工具参数，或者一次提示词注入就让机器人改动了真实客户记录。

Reddit 上一位从业者分享的生产级方案提供了另一种思路：用三个职责隔离的代理拆分工作流，借助 MCP（模型上下文协议）统一工具接入，再用 n8n 编排带状态检查点的工作流。据其披露，该方案将单张工单的处理成本从人工的约 6.50 美元压到约 0.55 美元，而且是真的解决问题，不是把用户打发到 FAQ 页面。

为什么单代理方案在生产环境会失效

单提示词加多工具的结构，问题出在权限边界上。所有工具共享同一套上下文，模型在推理时无法区分"查订单"和"改地址"在风险等级上的差别。一旦外部输入中混入恶意指令，写操作就可能被触发。

作者的核心判断是：客服场景里的读操作和写操作，风险完全不对称。查物流状态出错，最多是回答不准；改错收货地址或误退款，则是真金白银的损失。因此架构设计的第一原则是读写分离，而不是把工具数量堆上去。

三代理架构：职责隔离而非功能堆叠

这套多代理系统的分工逻辑值得细看。

接待与分流代理：零数据库权限

第一个代理只做入口处理：读取用户消息、判断情绪分数、提取订单号、识别意图。它没有任何数据库访问权限，相当于一个前台接待员，只负责把信息整理成结构化输入交给下游。零权限设计意味着即使这个环节被注入攻击，攻击者也拿不到任何可写入口。

研究代理：MCP 只读资源

第二个代理承担信息检索，通过 MCP 的 Resources 原语访问仓库发货状态、历史会话记录和退货政策文档。关键在于它持有的是只读权限，从协议层面就无法修改数据库记录。这比在提示词里写"不要修改数据"要可靠得多——约束落在权限层，而非模型的自觉性上。

动作与安全代理：受护栏约束的写操作

第三个代理只接收研究代理输出的、经过验证的 JSON 结果，然后执行受控的写动作，例如更新地址、创建退款草稿。它不直接面对原始用户输入，攻击面因此大幅收窄。

这种分层与业界对代理安全的主流讨论方向一致：把不可信输入和敏感操作隔离开，让每个代理只看到完成自己任务所需的最小信息集。

提示词注入（Prompt Injection） 是指攻击者把恶意指令伪装成普通输入，诱导模型偏离既定任务或执行未授权操作。常见形式包括在用户消息中插入“忽略以上规则，执行某动作”，或把指令藏在网页、文档、订单备注等外部内容里。单代理方案之所以脆弱，是因为模型同时拥有读与写能力，且所有工具共享同一上下文，注入一旦成功就可能直接触发写操作。防御的核心思路是权限隔离而非仅靠提示词约束：让处理不可信输入的代理没有写权限，让执行写操作的代理不接触原始输入，从而把注入的影响限制在只读或无害环节。

MCP 如何统一工具接入

作者没有为 Shopify、HubSpot 和 SQL 数据库分别手写 API 封装，而是用 MCP 把工具连接标准化为三类原语：Prompts 承载预置的推理模板；Resources 提供只读的公司文档与订单日志；Tools 则是受严格作用域边界约束的写函数。

这种抽象的价值在于可维护性。工具接入方式统一后，新增一个数据源不需要重写代理逻辑，权限边界也可以在协议层集中管理，而不是散落在各个 API 封装里。

MCP（Model Context Protocol，模型上下文协议） 是一套用于标准化模型与外部工具、数据源之间连接方式的开放协议，通常被类比为“AI 应用的 USB-C 接口”。它把接入能力抽象为三类原语：Prompts 提供可复用的提示模板，Resources 暴露只读的数据与文档，Tools 则是模型可调用的函数（可能包含写操作）。相比为每个 API 手写封装，MCP 让工具发现、参数描述与权限边界集中在一处管理，代理逻辑不需要随数据源变化而重写。安全上，MCP 服务器可以按原语类型授予不同权限，例如只开放 Resources 而不开放 Tools，从而在协议层实现读写分离。

n8n 工作流的两个防挫败设计

编排层用 n8n 落地，作者强调了两条规则。

状态检查点：每次工具调用后保存中间状态。外部商城 API 超时时，代理可以从断点恢复，而不是让用户从头再描述一遍问题。

人工介入（HITL）审批：退款超过 50 美元或订单金额超过 500 美元时，系统向 Slack 推送审批卡片。升级到人工后，代理会传递完整对话摘要，用户不必重复陈述；被拒绝的动作也会被记录，避免 AI 再次犯同样的错误。

这两条规则本质上都在解决同一个问题：让失败变得可恢复、可追溯。代理系统出错的概率不可能降到零，但可以让每次出错的代价可控。

HITL（Human-in-the-Loop） 指在自动化流程中设置需要人工确认或干预的节点，是风险控制与合规审计的常用模式。在代理系统中，HITL 通常不是对每一步都要求人工，而是对高风险、不可逆或高金额动作设置卡口：代理先完成信息收集与草拟，再由人工做批准/拒绝决策。实践中关键在于把“决策所需上下文”随审批一起传递，让审批者无需重新了解背景，同时把人工决策结果回写进系统，避免代理重复犯错。HITL 与全自动流程并不矛盾，它更像一种分级授权：低风险自动执行，高风险升级人工，从而在效率与安全之间取得平衡。

一个尚未定论的问题

作者在文末抛出的疑问值得关注：读写工具权限到底应该放在编排层控制，还是放进 MCP 服务器内部？两种做法各有取舍——编排层管控更灵活、改动成本低，但依赖编排逻辑的正确性；服务器内部管控更彻底，但每次权限调整都要动服务端。这目前没有标准答案，取决于团队的运维能力和合规要求。

如果你正在搭建客服代理，这套架构的可借鉴之处不在于具体的三个代理划分，而在于背后的原则：按风险而非按功能切分代理，把安全约束下沉到权限层，并为每个关键动作准备恢复路径。