为什么我押注反对2025年的AI代理（尽管我在构建它们）
我在开发、DevOps和数据操作领域构建了12个以上的生产AI代理系统。以下是为什么当前关于自主代理的炒作在数学上不可能实现，以及在实际生产中真正有效的方法。
三个关于AI代理的残酷真相
在构建了12个以上生产系统后，我学到了以下内容：
- 错误率在多步工作流中呈指数级累积。每步95%的可靠性意味着20步后成功率仅为36%。生产系统需要99.9%以上的可靠性
- 上下文窗口导致二次令牌成本增长。长对话在大规模使用时变得极其昂贵
- 真正的挑战不是AI能力，而是设计代理能够有效使用的工具和反馈系统
无人谈论的数学现实
每个AI代理公司都在回避这个令人不安的事实：错误累积使得自主多步工作流在生产规模上数学上不可能实现。
AI代理工作流中的错误累积
让我们计算一下：如果代理工作流中的每一步都有95%的可靠性（对当前LLM来说已经很乐观了），那么：
- 5步 = 77%成功率
- 10步 = 59%成功率
- 20步 = 36%成功率
生产系统需要99.9%以上的可靠性。即使你神奇地达到每步99%的可靠性（目前无人做到），20步后也只有82%的成功率。这不是提示工程问题，也不是模型能力问题，这是数学现实。
我的DevOps代理之所以有效，正是因为它实际上不是一个20步的自主工作流。它是3-5个离散的、可独立验证的操作，具有明确的回滚点和人工确认点。“代理"处理生成基础设施代码的复杂性，但系统是围绕可靠性的数学约束构建的。
不划算的令牌经济学
代理布道者方便地忽略了另一个数学现实：上下文窗口产生二次成本扩展，使得对话代理在经济上不可行。
构建"对话式"代理时实际发生的情况：
- 每个新交互都需要处理所有先前上下文
- 令牌成本随对话长度呈二次方增长
- 100轮对话仅令牌成本就达50-100美元
- 乘以数千用户，经济性就不可持续
我的函数生成代理之所以成功，是因为它是完全无状态的：描述→函数→完成。无需维护上下文，无需跟踪对话，没有二次成本爆炸。这不是"与代码聊天"的体验，而是一个专注于高效解决特定问题的工具。
工具工程现实墙
即使你解决了数学问题，你还会遇到另一种障碍：为代理构建生产级工具是一个完全不同的工程学科，大多数团队都低估了这一点。
工具调用本身现在相当精确。真正的挑战是工具设计。每个工具都需要精心设计，以提供正确的反馈而不会压垮上下文窗口。你需要考虑：
- 代理如何知道操作部分成功？如何在不消耗令牌的情况下传达复杂状态变化？
- 当工具失败时，代理需要什么信息来恢复？太少会卡住，太多会浪费上下文
- 如何处理相互影响的操作？数据库事务、文件锁、资源依赖
每个生产代理系统的肮脏秘密是：AI可能只做了30%的工作。另外70%是工具工程：设计反馈接口、高效管理上下文、处理部分故障，以及构建AI能够真正理解和使用的恢复机制。
集成现实检查
但假设你解决了可靠性和经济性问题。你仍然需要与现实世界集成，而现实世界是一团糟。
企业系统不是等待AI代理编排的干净API。它们是具有怪癖的传统系统，具有部分故障模式、无通知更改的身份验证流程、随时间变化的速率限制，以及不适合提示模板的合规要求。
承诺"与整个技术栈集成的自主代理"的公司要么过于乐观，要么没有真正尝试过大规模构建生产系统。集成是AI代理的葬身之地。
真正有效的方法（及原因）
在构建了十几个不同的代理系统后，我了解到成功的系统都有一个模式：
- 我的UI生成代理有效是因为人类在部署前审查每个生成的界面
- 我的数据库代理有效是因为它在执行前确认每个破坏性操作
- 我的函数生成代理有效是因为它在明确定义的边界内操作
- 我的DevOps自动化有效是因为它生成可以审查、版本控制和回滚的基础设施即代码
- 我的CI/CD代理有效是因为每个阶段都有明确的成功标准和回滚机制
模式很明确：AI处理复杂性，人类保持控制，传统软件工程处理可靠性。
我的预测
我对2025年将遇到困难的公司的具体预测：
- 风险投资支持的"完全自主代理"初创公司将首先遇到经济墙
- 将"AI代理"附加到现有产品的企业软件公司将看到采用停滞
- 获胜者将是构建受限的、特定领域工具的团队，这些工具使用AI处理困难部分，同时在关键决策上保持人类控制或严格边界
市场将学会区分演示良好的AI和可靠交付的AI。这种教育对许多公司来说将是昂贵的。
正确构建方法
如果你正在考虑使用AI代理构建，请从以下原则开始：
- 定义清晰的边界
- 为失败而设计
- 解决经济性问题
- 优先考虑可靠性而非自主性
- 建立在坚实的基础上
代理革命即将到来。只是它看起来不会像2025年每个人承诺的那样。而这正是它会成功的原因。
实战经验教训
“演示有效"和"大规模有效"之间的差距是巨大的，大多数行业仍在摸索这一点。
如果你正在处理类似问题，我很愿意继续这场对话。关于代理可靠性、成本优化和集成复杂性的挑战是迷人的工程问题，目前还没有明显的解决方案。