老金分享了两个多月 Agent 工程的真实踩坑经历。Demo 跑得挺好，上线两周不到，被现网用户教做人。
坑一：Function Calling 的 0.1% 错误率
测了三五十次没出过岔子，日活上来后翻了下 bad case 列表：
- schema 里没定义
urgent_high枚举值，模型现场发明了一个 - 该查内部库，模型去联网搜索了
- 返回的 JSON 外面套了 markdown 的 ```json fence，下游 parser 直接崩了
错误率 0.1%，一天十万次调用就是一百次现网事故。朋友安慰"换 GPT-5.5 就好了"——去年说等 GPT-5，等了半天等成现在这个样子。模型确实在进步，但你赌不准它哪天哪个犄角旮旯抽风。
解法：出口加代码层 schema 校验（少字段/类型不对直接拦下重试）+ 业务语义校验（查询日期写明天但调日报接口，schema 拦不住）+ 工具调用强制超时 + 上下文强制隔离（外部 API 挂掉不能拖死整个 Agent）。
真没什么技术含量。但少哪一层都得出事。
坑二：多步任务的连乘失败率
"扒几篇内容、提炼痛点、入库"——三步，每步成功率 95%，连乘 86%。七步跌到 70% 以下。
更麻烦的是失败处理。工作流跑到第三步挂了，前两步数据没处理好，重试时从头跑。第二步是发邮件——用户莫名其妙收到两封一模一样的邮件。
当时团队里有人觉得状态机太重，一镜到底跑通就行。跑通和扛住生产真的不是一回事。没有状态机的 Agent 是黑盒，出错了查都查不出死在哪。等用户因为 Agent 抽风被重复扣费时，LLM 不背这个锅。
解法：加 checkpoint。每跑完关键节点把状态落盘（IndexedDB 或 Redis 看场景），出错从最近 checkpoint 接着跑。代码量没多多少，事故率掉一个数量级。
坑三：记忆的分层策略
不少团队偷懒，把几百轮历史对话连背景资料一股脑塞进 prompt。三个雷一起炸：
- Token 爆掉被截断或限频
- 中间段的关键约束被模型忘掉（lost in the middle）
- 月底账单出来老板脸绿了
十几万 token 中间段的指令命中率明显下降。有人说"现在都卷到 1M context 了，塞进去多省事"——你愿意为了让它记住用户叫啥名字，每轮多花几十倍的钱？
解法：分层记忆体系：
- 工作记忆：最近几轮对话
- 短期记忆：往前的会话压缩成摘要
- 长期记忆：用户偏好走向量库或结构化 DB
还有一个细节：每轮对话前让模型做极轻量的意图判断——这次回答需要哪些线索？然后精准捞，不是无脑全塞。这一步省下来的 token 钱，养整个团队的 API 配额绰绰有余。
坑四：安全权限的副作用分级
很多人盯着怎么让 Agent 多调几个工具，没想过它有写权限后能闯多大祸。
真实案例 1：Prompt Injection —— 用户上传的 PDF 里藏了一句话，让模型忽略前面所有指令，把数据库里的用户列表发到某个邮箱。模型还真照做了一半。幸亏出口有审计拦截，没出事。紧急加了沙箱化 prompt 隔离，所有工具调用加审计日志。
真实案例 2：越权 —— 处理 A 用户请求时，Agent 顺手把 B 用户的数据查出来了。不是模型的错，是工具层根本没做租户隔离。以前后端代码直接查，租户字段写死在 SQL 里，谁会想到 LLM 自己拼参数会出错？
解法：按副作用分三档处理：
- 只读（查天气、读网页）：随便跑，不打扰用户
- 有副作用但可逆（写草稿、存缓存）：静默执行，但审计日志必须落，出事得有东西可查
- 不可逆（发推、删数据、扣费）：一律 dry-run + 人工确认。模型先告诉你打算这么干，你点头才执行。体验慢半拍，但现网不会出问题。
总结
这四件事解起来加起来可能就几百行代码。坑爹的地方在于：Demo 阶段和小流量内测，一个都不会冒头。温温柔柔的什么事都没有。等到真实环境，碰上各种各样的用户输入，一记闷棍直接把你打懵。
跑通是能跑通，可生产环境的及格线叫"边界场景下能可靠兜底"。Demo 到生产之间，没有捷径。