Agent 落地最大的坑——我全踩了一遍，这是绕过的方法

2026.07.09 · 约 3000 字

五个坑我全踩过。不是听说来的，是每踩一个付出了真金白银和时间的代价换来的。

一、PoC 顺风顺水，上线一地鸡毛

我的星辉广告系统的同步引擎 V2，PoC 阶段跑了三天，数据准确、性能稳定。信心满满部署到生产。上线第一天，一个上游供应商的 API 格式变了（文档说是 JSON，实际返回的是带 BOM 头的 JSON），同步引擎直接崩溃，当天的收入数据全部没入库。

我踩的： 测试数据只有我自己构造的"完美数据"。真正的生产数据有你想象不到的问题——BOM 头、空值、编码不一致、超长字段、特殊字符。每个问题单独发生的概率可能只有 1%，但 10 个这样的 1% 叠加起来，一上线就会碰到。

怎么绕过的： 现在我的 PoC 流程里强制加一步"用三个月的历史生产数据回测"。不是构造数据，是真实的历史数据。跑完回测再看上线后的错误率，从上线第一周就出问题降到了几乎不出问题。

ReAct 循环的成本我是在月底收到账单时才真正理解的。一个任务走了 12 轮循环，累计消耗 8 万 Token——成本是正常执行的 6 倍。不是模型出了问题，是我没给它设停止条件。

我的监控数据后来显示：相同 Skill 在不同日期的 Token 消耗波动幅度可以达到 2-3 倍。模型版本更新、输入长度变化、甚至一天中的不同时段都会影响。

我踩的： 以为 Agent 任务的成本 ≈ 一次 API 调用的成本。实际上一个 5 步 ReAct 循环，因为每轮都要携带历史上下文，Token 消耗是 1 步直答的 8-12 倍。

怎么绕过的：

技术落地的最大障碍往往不是技术。

我踩的： 不是员工抵制 AI 的案例——是我自己搭建的内容生产流水线。我设计了研究→写作→审计→发布四个 Agent，看起来很美。但运行一周后发现一个尴尬的事实：我花了更多时间在"告诉 Agent 它做得不对"上，比我自己写还累。

问题不是 Agent 能力不够，是我的角色变了——从"干活的人"变成了"审核的人"。审核比干活更累，因为你要检查别人（即使是 AI）的每一个细节，而你的标准比它高。

怎么绕过的： 降低预期——Agent 产出 80 分的内容，我只需要花 10 分钟把它改到 90 分，而不是要求它直接出 90 分。验证闭环不是用来"挑刺"的，是用来"兜底"的。改了心态之后，流水线才真正跑起来。

工作中推进 Agent 也一样——不是 Agent 能不能干的问题，是"人愿不愿意放手"的问题。这需要组织层面的调整，不是技术能解决的。

我改了一个 Prompt，感觉"好像变好了"，但没有数据支撑。改回来又觉得"好像原来的更好"——全是感觉，没有测量。

我踩的： 在 LangGraph 实战中，我改了检索 Agent 的提示词，自我感觉良好。跑了一次测试——修复了一个问题，但让另一个场景的准确率从 85% 掉到了 60%。因为没有评估集，我花了整整一天才发现。

怎么绕过的： 建一个覆盖所有典型场景的评估集。不需要很大——30-50 条标注好的问题就够。每次修改跑一次完整的回归测试。自动化这个流程，让评估成为修改的"门禁"——评估不过不部署。

我踩的： 早期的同步引擎 V1，上游返回的数据直接入库，没有任何校验。某天一个上游返回了负数收入，系统照常入库，客户的报表上显示了"负收入"。不是恶意攻击，是上游的一个 bug，但因为我没有加输出验证，bug 一路传导到了客户面板。

这件事直接推动我设计了三层验证（格式→语义→安全）。不是因为我知道安全很重要，是因为我被安全问题打疼了。

怎么绕过的： 验证闭环不是可选项，是必选项。三层防线：

每一层都在 Harness 的四个维度里有对应的工程实现。

一句话： 这五个坑有一个共性——把 Agent 当普通软件在开发。 Agent 不是 CRUD——它是推理系统、是概率系统、是有行为能力的系统。开发 Agent 需要的是建系统的思路，而不是叠功能的思路。你每绕过其中一个坑，就比大多数团队前进了一大截。