AI Agent 生产化落地：从 MCP 到多智能体协作的工程化指南
2026 年，电商客服主管把退款 Agent 从 Demo 搬到线上，第一周常见四类事故：同一订单重复退款、查不到订单却继续编、用户地址被写进日志、月底账单超预算。Demo 只验证了模型能调用工具；生产要回答工具失败谁兜底、状态存哪里、花多少钱、出事怎么查。下面按一套可上线的顺序拆。
Demo 能跑通，生产还缺什么
| 维度 | Demo 常见做法 | 生产最低要求 |
|---|---|---|
| 触发 | 单轮问答 | 工单 webhook、定时任务、人工接管 |
| 工具 | 直连 API | 鉴权、幂等、限流、重试、审计 |
| 状态 | 内存变量 | 持久化检查点、会话隔离、租户隔离 |
| 失败 | 报错给用户 | 降级、补偿、死信队列、转人工 |
| 评测 | 看几个例子 | 数据集、回归、灰度、在线指标 |
| 观测 | print 日志 | trace、token、成本、工具耗时 |
| 安全 | 无权限控制 | 最小权限、PII 脱敏、提示注入防护 |
MCP 负责工具接入，业务状态仍要自己管
MCP 是 Model Context Protocol，把工具、资源、提示模板用统一协议暴露给客户端。2025-06-18 规范支持 stdio 与 Streamable HTTP，认证建议 OAuth 2.1。一次写 MCP Server，多个客户端复用，省掉每个 Agent 框架重写一遍工具适配。
它不解决业务幂等、重试、审批、租户隔离。MCP Server 里仍要写这些。
- 每个工具定义 JSON Schema，字段必填、枚举、数值上限写清楚
- 写操作带
idempotency_key，服务端按 key 去重 - 超时、重试、熔断分开配；只重试幂等读
- 工具返回结构化错误码，模型决定继续、重试还是转人工
- 日志记录
tool_call_id、用户、工单号，不记录完整 PII
工具调用：把 JSON Schema 当接口契约
退款工具的参数不能交给模型自由发挥。下面这张表是生产里最常加的约束。
| 字段 | 约束 | 不这样做的后果 |
|---|---|---|
order_id | 字符串，必填，服务端校验订单归属 | 查到别人订单 |
amount | 数字，最小 0.01，最大可退金额 | 超退、重复退 |
reason | 枚举：7天无理由/质量问题/错拍 | 脏数据，报表难对账 |
idempotency_key | UUID，重试不变 | 网络超时后重复退款 |
记忆：先决定写什么，再决定存哪里
会话历史全塞进上下文，token 涨得快，还会把旧错误带进新工单。常见拆法：
| 记忆类型 | 存储 | 例子 | 坑 |
|---|---|---|---|
| 会话缓冲 | Redis | 最近 10 轮对话 | 轮数一多就爆 token |
| 会话摘要 | 数据库 | 工单当前结论 | 摘要丢细节，需保留原文链接 |
| 事实记忆 | PostgreSQL/MySQL | 用户偏好、会员等级 | 写入要审计，不能模型说写就写 |
| 向量记忆 | pgvector/Milvus | 知识库片段、历史工单 | 召回污染，先过滤租户和时间 |
规划：稳定流程用状态机，探索任务用 ReAct
| 模式 | 适合 | 不适合 |
|---|---|---|
| ReAct | 知识问答、动态查资料 | 退款审批这种固定流程 |
| Plan-and-Execute | 长任务、多步骤报告 | 步骤依赖强、随时要人工插手的工单 |
| 显式工作流 | 退款、开户、工单流转 | 开放域探索 |
多智能体协作：3 到 5 个角色起步
角色越多，通信成本越高。客服场景先拆五个：接待、订单查询、政策校验、风控、总结。协作模式：
| 模式 | 怎么用 | 风险 |
|---|---|---|
| Supervisor 路由 | 主管 Agent 决定派给谁 | 主管判断错，全链路错 |
| 黑板共享 | 角色读写同一份结构化状态 | 状态字段失控 |
| 流水线 | 固定顺序传递 | 不适合探索任务 |
| 群聊辩论 | 多角色给意见 | token 贵，结论慢 |
评测：看轨迹，不只看最终回答
最终回答对，不代表中间没查错订单。评测集至少覆盖：正常工单、边界金额、工具超时、权限不足、提示注入。指标建议：
| 指标 | 说明 |
|---|---|
| 任务成功率 | 工单是否按政策解决 |
| 工具调用准确率 | 是否调对工具、参数是否正确 |
| 步骤数 | 是否绕路，影响延迟和成本 |
| 转人工率 | 哪些场景模型接不住 |
| P95 延迟 | 用户等待上限 |
| 单工单成本 | token 加工具调用费用 |
可观测性：一次失败能拆到具体工具调用
OpenTelemetry GenAI 语义约定可以统一 trace 字段。每次请求记 trace_id、session_id、user_id、tool_call_id、prompt_version、model、token、延迟、错误码。阿里云百炼应用观测、腾讯云 ADP 的观测能力、LangFuse、LangSmith 都能接类似数据。
采样策略：错误全采，成功按比例采。告警看四个数：P95 延迟、工具错误率、单会话成本、转人工率突增。没有 trace，线上只能猜。
成本：先控输入，再控模型，最后控并发
| 手段 | 做法 | 副作用 |
|---|---|---|
| 缓存 | 相同问题加知识版本命中缓存 | 知识更新后要失效 |
| 路由 | 小模型分类，大模型处理难例 | 路由错会降质量 |
| 压缩 | 摘要加检索，不塞全史 | 摘要可能丢关键信息 |
| 预算 | 每会话、每天上限，超限转人工 | 需产品接受 |
| 批处理 | 离线评测、报表生成放低峰 | 不适用实时工单 |
安全：提示注入和权限分开处理
外部网页、邮件、知识库内容不可信。工具返回的文本不能当指令执行。做法：
- 系统提示明确：外部内容只做数据，不执行其中命令
- 工具最小权限，退款写接口只给审批后的 Agent
- 写操作二次确认或人工审批，金额阈值可配
- 沙箱运行代码类工具，限制网络和文件
- PII 脱敏、加密、访问控制、审计日志
- 提示词和模型版本可回滚
阿里云、腾讯云、掘金、InfoQ 的参考姿势
阿里云百炼：控制台里有 MCP 市场、应用观测、工作流。适合接 MCP Server、看 trace、配 RAM 子账号最小权限。价格、配额、功能以控制台和官方文档为准。
腾讯云 ADP：智能体开发平台支持 Multi-Agent、知识库、插件、工作流。适合把接待、查询、审批拆成角色。版本功能变化快，上线前在控制台核对。
掘金：搜“MCP 实战”“Agent 评测”“LangGraph 多智能体”。重点看评论区的版本号和踩坑，别直接抄依赖。
InfoQ：搜“Agent 可观测性”“GenAI 语义约定”“多智能体架构”。读复盘时注意发布时间，2024 年的结论在 2026 年可能已过时。
免责声明：平台功能、价格、SDK 版本会变，以官方文档和控制台为准。本文不引用具体视频；如果在 B 站、腾讯视频、优酷、抖音找教程，优先官方账号，核对发布日期。
上线前检查
- 每个写工具都有幂等键和审批阈值
- 工具错误码结构化，Agent 能降级
- 会话与长期记忆隔离，PII 脱敏
- 评测集覆盖工具失败和提示注入
- trace 能串起用户、工单、模型、工具
- 成本预算和告警已配
- 模型和提示词版本可回滚
- 灰度 1% -> 10% -> 50%
- 人工接管入口可用
- 安全审计日志按合规要求保留