Demo 跑通那一下是假象：Agent 开发攒下的五个真问题

2026 年，写一个能跑的 Agent demo 已经不难了。调一个 LLM API，接几个工具，跑通"用户提问 → Agent 决策 → 工具调用 → 返回结果"这条链路，半天就能搞定。但真正要把它放到生产里，问题会一个接一个冒出来。 这些不是"模型不够聪明"的问题，而是"系统不够可靠"的问题。下面是我在 2026 年做 Agent 相关工程实践后，攒下来的五个真问题。 一、输入覆盖度：你不知道模型"没看到什么" 这是最常见、也最隐蔽的问题。假设你要让 Agent 查用户的全部持仓，API 返回了 100 条，但网络抖动或分页逻辑有问题，实际只拿到了 80 条。Agent 看到这 80 条，开始分析、给出结论——整个过程没有任何报错，日志全是"成功"。 问题在于：模型不知道自己有 20 条数据没看到。它看到的输入是"完整的"，所以它的输出也是"自信的"。但这份自信是建立在残缺数据之上的。 解决思路不是"换更强的模型"，而是先回答一个问题：我能不能证明输入是完整的？ 对于有序号、有总数的数据任务，最简单的做法是在调用工具后，先校验"返回数量 == 预期数量"，不等、不猜、不静默吞掉差异。 二、工具调用的"假成功" MCP 协议让工具接入变得标准化，但协议层面不保证"调用成功 = 交付成功"。agentstatus.dev 2026 年 9 月的实测数据显示，公开 MCP Server 中 59.4% 处于 DEGRADED 状态——能连上、能列工具，但真正调用时行为不可靠。 常见的"假成功"形态： · 返回 `isError: false`，但内容字段为空； · 返回正常结构，但关键字段缺失； · 成功返回，但实际副作用（写库、发邮件、改配置）根本没发生。 应对方法：在工具调用链路上加一层"结构化校验"——不仅看 HTTP 状态码，还要验证返回体的 schema 是否符合预期。不符合预期就视为失败，触发重试或告警，而不是把残缺数据往下传。 三、上下文膨胀与压缩的陷阱 Agent 的"记忆"本质上是上下文窗口里的对话历史。随着对话轮次增加，上下文会膨胀，模型开始"遗忘"早期的关键信息。为了控制成本，很多团队会做上下文压缩——把早期对话摘要后塞回去。 但压缩本身有风险：摘要可能丢掉关键约束条件、工具调用参数、或用户的明确否定。一个典型的案例是：用户在第一轮明确说了"不要查 A 表"，压缩后这一约束被丢掉，后续轮次 Agent 又去查了 A 表，用户完全没意识到自己被"反向操作"了。 应对方法：关键约束不走摘要流，走显式状态机；每次压缩后做"约束保留度"校验。 四、幂等性与副作用的边界 Agent 调用工具时，很多操作是不可逆的——发一封邮件、提交一个订单、修改一条配置。如果因为网络抖动触发了重试，或模型在两次推理中给出了不同结果，系统如何保证"只做一次"？ 这不是模型的问题，是系统工程的问题。解决思路是： 1、所有写操作必须带幂等键（idempotency key）； 2、高代价操作（发邮件、付款、改配置）必须经过人工确认； 3、重试策略要区分"可重试"和"不可重试"——网络超时可以重试，业务逻辑失败不应重试。 五、回归测试：每次改 prompt 都在赌 很多 Agent 项目没有回归测试。每次改 prompt、换模型、加工具，都是"跑一下看看"。这种方式在 demo 阶段够用，在生产环境就是赌博。 可靠的 Agent 系统应该像传统软件一样，有： · 一套代表性的测试用例（正常路径 + 边界 case + 对抗 case）； · 每次变更后自动跑一遍，记录通过率； · 失败时能定位是"模型变了"还是"prompt 变了"还是"工具变了"。 写在最后 Agent 开发最容易让人产生的一种错觉是："Demo 能跑通 = 系统能做生产"。但真正决定一个 Agent 项目能不能上线的，不是模型能力，而是工程可靠性——输入覆盖度的可证明性、工具调用的可验证性、上下文的可控性、副作用的可回滚性、变更的可回归性。 这些能力，才是 2026 年做 Agent 和 2024 年做 Agent 的真正分水岭。 本文事实与数据来自以下原文： · agentstatus.dev《State of MCP reliability in production》（2026-09-01） · Development Curated《How to Build Reliable MCP Agents for Production Pipelines?》