转载 Why I'm Betting Against AI Agents in 2025 (Despite Building Them)
我已经构建了 12 套以上的 AI Agent 生产系统，覆盖开发、DevOps 和数据操作等场景。以下是我认为当前对“自治 Agent”的热潮在数学上是不可能实现的原因，以及什么才是真正在生产环境中有效的方式。
每个人都说 2025 是 AI Agent 的元年
标题随处可见：
- “自治 AI 将重塑工作方式”
- “Agent 是下一个前沿”
- “未来属于 Agent 模式”
与此同时，我过去一年花了大量时间实际构建了许多真正能在生产环境中运行的 Agent 系统。这也正是我为何对当前的 Agent 热潮持保留态度的原因。
我不是那种站在场外写批评文章的 AI 怀疑论者。过去一年，我构建了十几个应用于整个软件开发生命周期的生产级 Agent 系统：
- 开发类 Agent：UI 生成器（能将自然语言转换为 React 组件）、代码重构 Agent（现代化遗留代码）、文档生成器（自动维护 API 文档）、函数生成器（将规格说明转为函数实现）。
- 数据和基础设施 Agent：数据库操作 Agent（执行复杂查询与迁移）、DevOps 自动化 Agent（管理多云平台的基础设施即代码）。
- 质量与流程 Agent：AI 驱动的 CI/CD 管道（修复 lint 问题、生成测试用例、自动代码审查、生成完整的 PR 描述）。
这些系统是有效的，它们创造了真实价值，每天节省大量人工操作。而这恰恰是我不看好当前“2025 是 Agent 元年”的原因。
三个关于 AI Agent 的残酷现实（TL;DR）
构建了超过 12 个系统之后，我总结出三个关键事实：
- 错误率在多步骤流程中呈指数级上升：每步 95% 成功率 = 20 步只有 36% 成功率。生产要求是 99.9% 以上。
- 上下文窗口导致 token 成本呈二次增长：长对话在规模化后成本高得离谱。
- 挑战不在于 AI 能力，而在于工具与反馈系统的设计：Agent 需要可用的环境来工作。
没人愿意面对的数学现实：错误叠加
这里有一个大家不愿公开谈论的残酷真相：多步自治 Agent 流程在数学上无法实现生产级别的稳定性。
让我们来做个简单计算。如果每个步骤成功率是 95%（这已经是对当前 LLM 乐观的估计），那么：
- 5 步成功率 = 77%
- 10 步成功率 = 59%
- 20 步成功率 = 36%
而生产系统的需求是 99.9%+ 成功率。即使你每步成功率达到惊人的 99%，20 步下来也只有 82% 的成功率。
这不是提示工程问题，不是模型能力问题，是数学问题。
我构建的 DevOps Agent 成功的原因在于：它并不是一个 20 步的自治流程，而是 3-5 个可以独立验证的操作，每一步都有显式的回滚点和人工确认机制。
真正能用的 Agent 系统都遵循相同模式：
- 有限上下文
- 可验证的操作
- 在关键点引入人工决策（有时）
一旦你试图串联超过几步操作，数学就会让整个系统崩溃。
Token 经济学也行不通
另一个不被正视的现实是：上下文窗口的存在导致对话类 Agent 的成本呈二次增长，这让它在经济上根本无法规模化。
“聊天式 Agent”看似诱人，但现实是：
- 每一步都要重新处理整个上下文
- Token 成本随着轮次指数增长
- 100 轮对话可能花费 100
- 成千上万用户并发使用时，成本无法承受
我在做数据库对话 Agent 原型时就被狠狠“上了一课”。前几轮查询还好，到第 50 条时，每个回答就要花几美元，远远高于它创造的价值。
而我构建的函数生成 Agent 为什么成功？
因为它是完全无状态的：
说明 → 函数 → 结束。
不需要维护对话，不需要追踪上下文，也没有成本爆炸。
现实是：成功的 Agent 根本不是“聊天式”的，而是智能、有边界、专注完成单一任务的“工具”。
工具工程才是真正的墙
即便你解决了数学问题，你也会撞上另一堵墙：构建生产级 Agent 所需的工具体系是一门完全不同的工程学科，而多数团队对此完全低估。
如今 AI 的工具调用（tool call）已经相当准确，但问题在于工具的设计。
好的工具需要回答：
- Agent 如何判断操作是否“部分成功”？
- 如何在不浪费 token 的前提下表达复杂状态变化？
- 工具失败时，Agent 如何恢复？提供太少信息就卡住，太多又会淹没上下文。
- 工具间如何互相影响？比如事务、锁、资源依赖等。
我做的数据库 Agent 之所以有效，是因为我花了几周时间设计了能与 AI 高效交流的工具接口，每个工具都返回结构化反馈，而不是裸 API 响应。
而那些宣传“连上你的 API，我们的 Agent 就能搞定”的公司，根本没做这个工程工作。他们把工具当成给人类用的界面，而不是 AI 用的界面。最终的结果是：虽然 API 调用成功了，但工作流程完全失败。
所有生产级 Agent 系统的秘密是：AI 只完成了 30% 的工作，另外 70% 是工具工程：
- 反馈接口的设计
- 上下文管理
- 部分失败处理
- AI 能理解的恢复机制
现实世界的集成问题
就算你解决了稳定性和成本问题，你还得集成真实世界的系统，而这才是最大的噩梦。
企业系统不是干净的 API，而是：
- 充满奇怪 bug 的遗留系统
- 不可预期的身份认证流程
- 动态变化的限流策略
- 合规需求无法用 prompt 表达
我构建的数据库 Agent 并不是“自主执行 SQL”。它还需要：
- 处理连接池
- 管理事务与回滚
- 遵守只读副本策略
- 控制查询超时
- 生成审计日志
AI 只负责生成 SQL，其他都是传统系统工程的活。
那些声称“我们的 Agent 能整合整个技术栈”的公司，要么太天真，要么根本没做过大规模系统。现实世界的集成问题，才是 AI Agent 死亡的真正战场。
什么方式才真正有效？
我构建过十几个 Agent 系统，涵盖整个开发生命周期，最终发现成功者都遵循一个清晰模式：
- UI 生成 Agent 有效，因为每个界面都由人类最终审核，AI 只是将自然语言转化为 React。
- 数据库 Agent 有效，因为每一个破坏性操作都要确认。AI 翻译业务需求 → SQL，最终由人类控制数据完整性。
- 函数生成 Agent 有效，因为它工作在清晰边界内：输入规格 → 输出函数，无副作用、无状态管理、无集成复杂性。
- DevOps 自动化 Agent 有效，因为它生成的是基础设施代码（可审阅、可版本化、可回滚）。
- CI/CD Agent 有效，因为每一步都有明确的成功标准与回滚机制，AI 做质量分析和修复建议，管控还是在流水线里。
清晰的规律是：AI 负责复杂性，人类负责控制，可靠性靠传统软件工程保障。
我的预测：谁会在 2025 年“撞墙”？
谁会出问题：
- 拿 VC 钱搞“全自治 Agent”的创业公司会先撞上经济学那堵墙。Demo 没问题，但客户想要的 20+ 步流程会直接失败，烧钱试图解决“无解的数学问题”。
- 把 AI Agent 强行嫁接到旧系统的企业软件公司也会增长停滞——它们的 Agent 集成能力根本不够用。
谁会赢：
- 构建受限领域的、边界明确的工具型 Agent 团队。AI 用来解决难点，人类负责最终控制。不是“自治一切”，而是“能力极强的助手”。
最终市场会学会分辨什么是“演示效果好”，什么是“真正能用”。而这个教育过程，将是很多公司的“学费”。
正确的 Agent 构建原则
如果你现在正准备构建 Agent 系统，请牢记以下几点：
- 定义清晰边界：Agent 负责什么？哪里需要人接管？
- 为失败设计：出错时怎么办？有没有回滚机制？
- 解决经济问题：每次调用成本是多少？怎么扩展？无状态通常优于有状态。
- 稳定性优先于自治性：用户更信任稳定运行的工具，而不是偶尔成功的“魔法”。
- 打好传统工程基础：AI 负责理解意图与内容生成，关键执行、状态管理、错误处理交给传统工程。
最终结语：来自实战的一课
从“能 demo”到“能规模化上线”之间的鸿沟巨大，而整个行业还在摸索中。
如果你也在做类似的事情，我非常愿意继续交流。Agent 的可靠性、成本优化和集成复杂性，都是极具挑战性的工程问题，没有标准答案。
我经常给团队或公司做相关顾问工作——从架构设计到避坑经验。如果你在考虑 build vs buy、Agent 上线困难、或想知道怎么做好，可以随时联系我。
让更多构建真实系统的人分享实战经验，我们就能更快搞清楚，什么真的有效。
