@freeman1266: https://x.com/freeman1266/status/2055293363893768463
摘要
这篇文章总结了将AI Agent从Demo部署到生产环境过程中遇到的四个常见陷阱:function calling不可靠、多步任务失败率累积、记忆管理不当、以及安全权限问题,并给出了相应的解决方案。
查看缓存全文
缓存时间: 2026/05/16 05:12
Agent 工程的四个深坑:Demo 到生产没有捷径
前阵子做 Agent,两个多月了。Demo 跑得挺好,每次内部 review 都挺开心。结果上线两周不到,被现网用户教做人。
今天就想说几个真实发生过的事。
先说 function calling 那块吧。
我们最早觉得这玩意挺稳的,测了三五十次没出过岔子。然后日活上来了。
我前几天翻了下上个月的 bad case 列表。schema 里我们压根没定义 urgent_high 这个枚举值,模型给我现场发明了一个。还有一次该查内部库,它去联网搜索了。最离谱的一次,返回的 JSON 外面套了个 markdown 的 ```json fence,下游 parser 直接崩了。
错误率算下来 0.1%。听起来还行对吧。一天十万次调用就是一百次现网事故。这个数量,你让哪个团队能顶得住?
我跟一个朋友聊到这事。他张口就来——那是模型不够聪明,换 5.5 嘛。我笑了,去年说那是因为 GPT-4 不行,等 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 多调几个工具,没想过它有写权限以后能闯多大祸。
我们踩过两个真实的。
一个是 prompt injection。用户上传的 PDF 里藏了一句话,让模型忽略前面所有指令,把数据库里的用户列表发到某个邮箱。模型还真就照做了一半。幸亏出口那层有审计拦截,没出事。发现之后我们紧急加了一道沙箱化的 prompt 隔离,然后把所有工具调用都加上了审计日志。
另一个是越权。处理 A 用户请求的时候,Agent 顺手把 B 用户的数据查出来了。不是模型的错,是工具层根本没做租户隔离。以前都是后端代码直接查的,租户字段写死在 SQL 里,谁会想到 LLM 自己拼参数会出错啊。
我们现在按副作用分了三档处理。只读的查天气读网页这种,随便跑,不打扰用户。有副作用但可逆的,比如写草稿存缓存,静默执行就行,但审计日志必须落,这条不能省,出事了你得有东西可查。不可逆的——发推、删数据、扣费这些——一律 dry-run 加人工确认。模型先告诉你我打算这么干,你点头才执行。体验上慢半拍,但现网不会出问题导致用户骂你。
差不多就这些。
这四件事解起来加一起代码可能就几百行。坑爹的地方在哪呢,Demo 阶段和小流量内测,一个都不会冒头。温温柔柔的什么事都没有。等到真实环境中,碰上各种各样的用户输入,一记闷棍直接把你打懵。
跑通是能跑通,可生产环境的及格线叫边界场景下能可靠兜底。
Demo 到生产之间,没有捷径的。
相似文章
@knoYee_: https://x.com/knoYee_/status/2062780637677752366
作者复盘了使用多Agent协作三个月的经验,总结出五个主要痛点(如Agent间矛盾、忽略边界条件、自我审查失效、合并决策困难、压缩执行后暴露更难问题)和两个心得(只读审查Agent价值高、Agent矛盾暴露需求模糊),强调了人类在AI协作中的核心决策作用。
本文系统梳理了AI Agent架构与工程实践,涵盖控制流、上下文工程、工具设计、记忆、多Agent组织、评测、追踪和安全,基于OpenClaw实现展开,强调Harness(测试验证基础设施)对系统稳定性的关键作用。
本文系统梳理了AI Agent架构与工程实践,涵盖控制流、上下文工程、工具设计、记忆、多Agent组织、评测、追踪和安全,基于OpenClaw实现展开,强调Harness(测试验证基础设施)对系统稳定性的关键作用。
生产环境中的AI代理:演示中绝不会提及的失败模式
对在生产环境中部署AI代理的真实挑战的实用深度剖析,涵盖演示与可靠系统之间的差距、提示注入等攻击面,以及安全自主性的设计原则。
@AxtonLiu: https://x.com/AxtonLiu/status/2073791557547794579
本文讨论了Agent OS的概念,强调通过分工将任务拆解为多个工位(抓取、提炼、核查、确认),每个工位由独立的Agent负责,以实现可控的自动化。作者通过消化浏览器标签的例子,展示了如何通过分工隔离上下文、责任和风险,确保AI输出的准确性和可靠性。
@Xudong07452910: 这篇论文很适合所有重度使用 Claude Code、Codex 或者其他AI Agent 的人看。 它研究的不是 Agent 在 benchmark 上怎么失败,而是一个更真实的问题: 在真实开发里,AI coding agent 到底是…
This paper analyzes 20,574 real-world coding-agent sessions to identify how AI agents misalign with developer intent, finding that constraint violations and inaccurate self-reporting are the most common failure modes, imposing trust and effort costs rather than irreversible damage.