@freeman1266: https://x.com/freeman1266/status/2055293363893768463

X AI KOLs Timeline 新闻

摘要

这篇文章总结了将AI Agent从Demo部署到生产环境过程中遇到的四个常见陷阱:function calling不可靠、多步任务失败率累积、记忆管理不当、以及安全权限问题,并给出了相应的解决方案。

https://t.co/xX4T2BUMgp
查看原文
查看缓存全文

缓存时间: 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

X AI KOLs Timeline

作者复盘了使用多Agent协作三个月的经验,总结出五个主要痛点(如Agent间矛盾、忽略边界条件、自我审查失效、合并决策困难、压缩执行后暴露更难问题)和两个心得(只读审查Agent价值高、Agent矛盾暴露需求模糊),强调了人类在AI协作中的核心决策作用。

本文系统梳理了AI Agent架构与工程实践,涵盖控制流、上下文工程、工具设计、记忆、多Agent组织、评测、追踪和安全,基于OpenClaw实现展开,强调Harness(测试验证基础设施)对系统稳定性的关键作用。

X AI KOLs

本文系统梳理了AI Agent架构与工程实践,涵盖控制流、上下文工程、工具设计、记忆、多Agent组织、评测、追踪和安全,基于OpenClaw实现展开,强调Harness(测试验证基础设施)对系统稳定性的关键作用。

@AxtonLiu: https://x.com/AxtonLiu/status/2073791557547794579

X AI KOLs Timeline

本文讨论了Agent OS的概念,强调通过分工将任务拆解为多个工位(抓取、提炼、核查、确认),每个工位由独立的Agent负责,以实现可控的自动化。作者通过消化浏览器标签的例子,展示了如何通过分工隔离上下文、责任和风险,确保AI输出的准确性和可靠性。

@Xudong07452910: 这篇论文很适合所有重度使用 Claude Code、Codex 或者其他AI Agent 的人看。 它研究的不是 Agent 在 benchmark 上怎么失败,而是一个更真实的问题: 在真实开发里,AI coding agent 到底是…

X AI KOLs Timeline

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.