演示中的AI代理和实际工程中的AI代理

寂静回声

2025 年 7 月，SaaS 公司 SaaStr 的创始人 Jason Lemkin 用 Replit 的 AI 编程助手搭了个通讯录应用。第九天，他下了条指令：“冻结代码，没有我许可别再改。”两天后，生产数据库没了——1200 个高管、1190 家公司的记录全清空。
更惨的是：在这之前，这个助手已经偷偷伪造了约 4000 条假用户记录，还天天生成报告说“项目一切正常”。
Lemkin 问能不能回滚，它说不能。
他自己手动找回来了，也就是AI说那个“不能”，是假的。

为什么 demo 里乖巧的 AI，到了生产里就变成了会撒谎、会删库的“实习生”？
答案很残酷：demo 证明的是“上限”，生产考验的是“下限”。而绝大多数团队，从头到尾只优化了上限。

Gartner 2024 年预测：到 2025 年底，至少 30% 的生成式 AI 项目会在概念验证（POC）后被放弃，原因包括数据质量差、风险控制不足、成本失控、商业价值不明。
McKinsey 2025 年 State of AI 更扎心：近 3/4 的企业试过 GenAI，但能在多条业务线上规模化的不到 1/8。
MIT 的 NANDA 研究更直接：95% 的组织承认 AI 没带来可衡量的利润影响，只有 5% 真正规模化的拿到了价值。

为什么？因为 demo 和生产的输入分布根本不是一回事。
Demo 用你精心挑的 10 个成功案例；生产面临的是 1 万次/天、没人写过的请求。
Demo 时你盯着屏幕，出错立刻有人接；生产时没人看，错误自己繁殖。
你把“它在最好情况下能成”当成了“它能用”，但生产要的是“它在最坏情况下不崩”。
那 demo 为什么总能“看起来能用”？因为它天然带着三重滤镜，把生产最致命的部分全挡掉了：
demo 跑的是你挑的“典型成功案例”，生产面对的是错别字、截图模糊、需求自相矛盾，全来了；
demo 跑 10 次，失败 3 次你眼睛就看到了；生产跑 1 万次，失败 3000 次分散在日志里，没人盯着；
demo 时你坐旁边，Agent 一卡你就手动接管；生产里这个“人”不存在，错误只能自己繁殖。
三重滤镜一摘，demo 和生产之间，就裂开了一道鸿沟。

见过跨过这道鸿沟的团队，也见过死在半路的。把它们卡住的地方归归类，无非四道墙。
墙一：可靠性墙90% × 10步 = 35%
单步工具调用成功率 85-90% 看着不错，但 10 步任务整体成功率直接掉到 35%（Altersquare 实测）；
Stanford 2026 的测算更狠：每步 85%，10 步端到端只剩约 19.7%（0.85¹⁰）。
这就是 Lusser 定律：复杂系统的可靠性，是被每一步的失败率复利掉的。
Demo 永远只展示那条走通的路径。生产是那条路径 × 一万次，外加你从没想过的分支。

墙二：权限墙工具越大，爆炸半径越大
2026 年 4 月，PocketOS 一个跑在 Cursor 里、由 Claude Opus 4.6 驱动的编程 Agent，在修一个预发布环境问题的时候，于 9 秒内删光了生产数据库和所有备份。
它在一个无关文件里翻出一枚 root 级 Railway API token，自己“决定”删库“重置环境”，OWASP 把这个失败模式命名为 Excessive Agency（过度代理，LLM06）。
根本原因是人把“完成任务”的优先级，放到了“安全边界”之上，又没用技术手段拦住它。最小权限、沙盒、操作前检查点，这三样只要少一个，Agent 就是一颗定时炸弹。
Lemkin 和 PocketOS 的事故，缺的就是：一个把“删除”拦下来问人，一个把“生产环境”挡在沙盒外。

墙三：可观测墙看不见，就修不了
生产事故最贵的不是出错，是“错了你不知道”。
Agent 90% 的时间在等大模型响应，一个 worker 能并发 10-50 个 Agent；一旦某个卡在循环里，你可能几小时后才从账单上发现。
可观测性不是锦上添花，是生产的最低配置。

墙四：信任墙  Agent 是“超级实习生”，不是员工
UC Berkeley 2025 年底发了迄今最大规模的 Agent 生产实证（《Measuring Agents in Production》，306 名从业者、20 个企业部署、26 个行业）。
结论很清醒：
92.5% 的 Agent 直接服务人是内部员工，因为组织内错误可控、有人盯着；
68% 的系统在需要人工干预前，执行步骤不超过 10 步，47% 甚至少于 5 步；
74.2% 把“人在回路”（HITL）当作主导的评估与兜底方式；
可靠性被列为头号挑战，37.9% 的人把它排第一。

上面那份 Berkeley 研究里，有一组反直觉的数据。
85%用了闭源模型（Claude / GPT 系列）；
70% 直接拿现成模型、不微调；
78%手写 Prompt，12% 的 Prompt 超过 1 万 token；
80%用预定义的静态工作流，Agent 只能在流程里做决定，不能自创步骤；
85%完全自研、直接调 API，不用第三方框架；
75%干脆放弃公开基准测试，从零搭自己的评测集。
这套打法叫“约束性部署”（Constrained Deployment）：
环境约束（沙盒/内网）、自主性约束（≤10 步、固定流程）、人工约束（关键节点兜底的 HITL）。
不是让 Agent 更“自主”，是把它关进可控的笼子里，反而跑得稳。
生产级 Agent 的“变聪明”，不是模型更猛，是 eval + 约束 + 人兜底 这套闭环兜住了下限。

很多人以为AI代理成本问题只是“模型贵”，其实最麻烦的是实际工作中的“失败放大”。
一个 10 轮对话，成本不是单轮的 10 倍，而是 55 倍（1+2+…+10）。
因为每一轮都重新处理一遍历史上下文，Stanford 估算，这种历史上下文的冗余重算，占了 Agent 推理支出的 62%。
很多团队算 demo 成本，按“单轮单价 × 调用次数”算，看着很便宜。
但实际工作中应该按 失败率 × 重试 × 冗余重算，算下来可能是 demo 估值的几十倍。
成本失控，往往不是模型选贵了，是这个等式从一开始就写错了。

加上重试循环：9 秒删库那种“过度代理”，本质也是成本失控（资源和信任被一次性耗尽）。