2026 AI智能体落地地图：从MCP到生产级Agent的10个关键问题
客服团队上线了一个工单处理 Agent。第一周表现不错，第二周运营发现它给一笔已经退过款的订单又发起了一次退款。模型没坏，提示词也没改，缺的是有人定义过这个 Agent 现在处在哪一级、下一级要补什么。
下面 10 个问题按落地顺序排列，可以当成上线前的对照表，逐条看自己项目卡在哪。
问题 1：这个 Agent 现在处于哪一级
先定级，再谈优化。同一个团队里，工程师说“我们用了多智能体”，运营说“它老是问同样的问题”，通常就是因为没有共同的分级语言。
| 等级 | 判定标准 | 常见形态 | 人的介入方式 |
|---|---|---|---|
| L0 提示词问答 | 单轮输入输出，不访问外部系统 | 系统提示词 + 模型 API | 每轮人工确认 |
| L1 单次工具调用 | 模型能选一个工具并整合结果，工具失败整轮失败 | 函数调用或单个 MCP 工具 | 处理全部异常 |
| L2 多步编排 | 连续调用两个以上工具，带重试和分支 | 状态机、工作流框架 | 审关键节点 |
| L3 有状态自主执行 | 给定目标后自主跑完，跨会话记住偏好和历史 | 记忆层 + 权限边界 + 预算控制 | 抽查和告警 |
| L4 可评测的生产系统 | 有离线评测集、线上指标、灰度发布和回滚 | L3 加上评测、可观测性、审计日志 | 只在异常时介入 |
等级不是越高越好。一天只跑十次的任务，停在 L2 加人工复核，比硬推到 L3 便宜得多。
问题 2：用 MCP 还是直接写函数调用
MCP 由 Anthropic 在 2024 年 11 月发布并开源，规范版本用日期编号，传输基于 JSON-RPC 2.0，对外暴露的原语是 tools、resources、prompts 三类，本地走 stdio，远程走 HTTP。2025 年 3 月 OpenAI 宣布支持 MCP，之后 VS Code、Cursor、Claude Desktop、Zed 这些客户端陆续接入。到 2026 年，它已经是工具接入层最通用的一种写法，但不是所有场景都该上。
| 维度 | 直接写函数调用 | 走 MCP |
|---|---|---|
| 接入成本 | 低，写一份 JSON schema | 中，要跑 server 并管进程生命周期 |
| 复用范围 | 绑在当前应用里 | 任何支持 MCP 的客户端都能接 |
| 权限控制 | 由应用自己判断 | server 侧可以独立收权 |
| 排查问题 | 翻一份日志 | 要同时看客户端和 server 两侧日志 |
| 换模型 | 要改工具描述的格式 | 基本不用动 |
例外情况有两类。一是工具要同时服务 IDE 助手和线上客服 Agent，二是团队里已经有人写过 MCP server，直接复用比重新写便宜。延迟敏感的场景慎用，多一层进程通信在高峰时段的开销是实打实的。
问题 3：工具该切多细
一条经验规则：一个工具对应一个可逆操作，或者一个查询。写操作必须带幂等键。
反面例子是 execute_sql。看起来很灵活，实际上模型要自己拼 SQL，出错率高，权限也没法收窄。正面例子是把它拆成 query_order(order_id) 和 create_refund(order_id, amount, idempotency_key)，前者只读，后者写入但带幂等键，重试不会造成二次退款。
工具数量也要控制。一个 Agent 挂三十个工具，模型选错的概率会明显上升。常用的做法是按场景分包：售后 Agent 只挂订单相关的六七个工具，售前 Agent 挂商品和库存那几个，需要跨场景时再显式路由。
问题 4：记忆存什么、存在哪、谁能删
记忆经常被当成一件事处理，实际上至少分四层，存放位置和保留策略都不一样。
| 记忆类型 | 内容举例 | 常见存放位置 | 删除方式 |
|---|---|---|---|
| 会话上下文 | 当前这轮对话的消息 | 内存或会话存储 | 会话结束后自动清 |
| 会话摘要 | 用户偏好、已解决的问题 | 数据库 | 用户请求时按用户 ID 清 |
| 长期事实 | 账号配置、历史工单标签 | 关系库 | 走账号注销流程 |
| 知识检索 | 产品文档、FAQ | 向量库（pgvector、Qdrant、Milvus 等） | 按文档 ID 重建索引 |
问题 5：上下文快满了怎么处理
与其等报错再救，不如定一个压缩顺序：
- 先去掉重复的工具返回，同一份订单数据不要在上下文里出现三次
- 把早期对话压成一段结构化摘要，保留用户 ID、订单号、已经执行过的动作
- 把参考资料外置，改成按需检索，不要预先全塞进提示词
- 给上下文留出余量，别贴着上限跑，至少留 20% 给后面的工具返回
问题 6：怎么证明改了提示词没把线上搞坏
没有评测集，改提示词就是盲改。攒评测集最省事的入口是真实失败对话：每天从线上抽 50 条出问题的会话，人工标注“正确做法应该是什么”，两周就能攒到几百条。
维度至少要覆盖这四类：
| 评测维度 | 看什么 | 怎么测 |
|---|---|---|
| 工具选择 | 该调的工具调没调，不该调的调没调 | 对比期望的工具序列 |
| 参数正确性 | 订单号、金额、日期有没有串 | 结构化字段逐一比对 |
| 最终答案 | 事实对不对，有没有编 | 标准答案比对 + 人工抽检 |
| 成本与步数 | 完成同一任务花了几步、多少 token | 从运行日志统计 |
问题 7：失败路径怎么设
生产环境里大多数事故来自异常处理，不来自模型能力。上线前逐条过：
- 每个工具声明超时时间（比如 5 秒）和最大重试次数（1 次）
- 一次运行设最大步数上限（比如 15 步），超了直接停
- 单次运行设 token 或金额预算，超了停并告警
- 工具返回空值或格式不对时，给模型一个结构化的错误对象，而不是一坨 HTML
- 幂等键写进日志，重试时复用同一个
问题 8：人工确认放在哪一步
按操作的可逆性分三档，比统一加一道审批省事得多。
- 只读查询：不介入，出问题看日志
- 可撤销的写入：执行后抽查，发现异常批量回滚
- 不可撤销或涉及资金：执行前确认，把模型的建议动作和参数摆在人面前
问题 9：跟大厂路线还是创业公司路线
2026 年这两个方向的分工已经比较清楚。
| 对比项 | 大厂托管方案 | 开源与创业公司方案 |
|---|---|---|
| 代表形态 | OpenAI 的 Agents SDK 与 Responses API、Anthropic 的 Claude 与 Agent SDK、Google 的 ADK 与 Vertex AI Agent Engine、微软的 Azure AI Foundry Agent Service 与 Copilot Studio | LangGraph、LlamaIndex、CrewAI、Dify、n8n |
| 上线速度 | 快，托管了运行、会话、追踪 | 中，要自己搭运行环境 |
| 模型绑定 | 与自家模型贴合最紧 | 换模型相对自由 |
| 数据驻留 | 看区域选项和合规条款 | 可以完全自建 |
| 深度定制 | 受平台能力边界限制 | 想改哪层改哪层 |
| 长期成本 | 用量增长后账单爬升明显 | 主要是人力和机器成本 |
选哪条，主要看两件事：数据能不能出你的机房，以及团队里有没有人能长期维护一套自建运行时。两样都不占，选托管；两样都占，自建通常更划算。
问题 10：这笔钱多久能回来
用这个算式，参数自己填，别抄别人的数字。
年节省 = 覆盖任务量 × 单任务人工耗时 × 人力时薪 × 自动化成功率
− 人工复核耗时成本
年运营成本 = 推理费用 + 基础设施 + 维护人力
回收期（月）= 一次性开发成本 ÷（年节省 − 年运营成本）× 12
三处容易被漏掉的地方：
自动化成功率要按实际线上数据填，不能按评测集分数填，两者通常差一截。人工复核成本要算进去，L2 阶段这笔开销可能比推理费还高。失败成本单独列一行，重复退款、错发通知、错误报价这些事故的赔付金额，一次就能吃掉几个月的节省。
算下来回收期超过 18 个月的项目，先降级到 L2 跑一段时间，拿到真实成功率再重新算。
下一步做什么
挑一个已经在跑的 Agent，把过去两周的失败会话导出来，做成一张三列的表：会话 ID、工具调用序列、失败发生在哪一步。不用标注得多精细，先做完这一张表，它会直接告诉你下一件该补的是评测集、记忆分层，还是权限边界。
大多数团队做完这张表会发现，问题集中在同一两个工具的返回格式上，改起来比想象中快。
延伸观看
平台的视频链接会失效或改标题，这里给关键词而不是固定地址，你可以直接站内搜索：
- B 站搜“MCP 协议 讲解”，优先挑官方文档作者或大厂技术号发布的内容。注意发布日期，2024 年 11 月之前的讲解不涉及 MCP
- 腾讯视频、优酷搜“AI Agent 生产落地”，多为技术会议演讲回放，适合看别人怎么处理异常路径
- 抖音搜“AI Agent 实战”，单条信息密度低，适合快速了解常见踩坑点