亲手做了12个AI Agent，我并不看好2025年的智能体

文章摘要

一线工程师构建12个生产级AI Agent系统后指出，AI Agent热潮的数学限制如错误累积和高成本导致全自主系统不可行；实际可行方案需结合边界清晰任务、人工决策和传统工程支撑；预测全自动初创公司将失败，领域专用工具将主导市场。

• 错误累积：多步流程可靠率指数级下降，20步成功率仅36%。

• 成本爆炸：长上下文对话导致token开销二次增长，经济不可持续。

• 工具设计难题：AI工具需精心设计反馈接口才能有效运行。

• 现实集成挑战：Agent难以对接复杂企业遗留系统和法规限制。

• 可行Agent模式：采用有边界任务并嵌入人类决策节点以确保稳定。

• 市场预测：全自主Agent初创公司将受挫，受限领域工具团队胜出。

很多人说，“2025 年是 AI agent 元年”。各种新闻文章标题都这么写：

• “AI agent 会彻底改变工作方式”；

• “Agent 是 AI 的下一个风口”；

• “未来属于 Agent”。

而我却刚刚花了一年时间搞清楚哪些 Agent 在生产环境里真正能用，也正因此，我才不看好这股风潮。

一、我不是唱反调的人，我是真干过的

过去一年，我做了十几个上线的 Agent 系统，覆盖整个软件开发流程，比如：

• 开发类 Agent：自然语言生成 React 组件、重构老代码、自动维护 API 文档、根据说明生成函数。

• 数据和基础设施类 Agent：自动执行复杂 SQL、搞定数据库迁移、用 AI 管理基础设施代码（IaC）并支持多云。

• 质量和流程类 Agent：AI 驱动的 CI/CD 流水线，自动修复 lint、生成测试、做代码审查、写 PR 描述。

这些系统确实能用，也确实创造了实际价值，每天都能帮人省下好几个小时的手动操作。也正因如此，我才认为，外界把 2025 年称作 “AI Agent 元年” 的说法，忽略了很多关键现实。

二、要点速览：关于 AI Agent 的三个残酷现实

在构建了 12 套以上的生产级系统之后，我得出了以下几点结论：

• 多步骤流程中的错误率会呈指数级放大。即便每一步的成功率有 95%，到第 20 步时整体成功率也只剩 36%。而生产环境的要求是 99.9% 起步。

• 上下文窗口带来的 token 成本是二次增长的。对话越长，成本越高，规模化后开销惊人。

• 最大的难题不是 AI 本身的能力，而是如何设计 Agent 真正能用上的工具和反馈系统。

三、一个没人愿意面对的数学现实

所有做 AI Agent 的公司都在回避一个难以接受的事实：在生产级别的多步骤任务中，错误的累积让“全自动智能体”在数学上根本行不通。

AI Agent流程中的错误累积

咱们算算账。如果一个 Agent 流程中每一步的可靠率是 95%（这对现在的大模型来说已经很乐观了），那么整体成功率就是：

• 5 步流程：成功率约为 77%；

• 10 步流程：成功率约为 59%；

• 20 步流程：成功率仅剩 36%。

而生产环境要求的可靠率通常要达到 99.9% 以上。即使你奇迹般地让每步的成功率达到 99%（目前没人做到），20 步的整体成功率也只有 82%。这不是提示词设计的问题，也不是模型能力的问题，而是数学上的现实。

我做的 DevOps Agent 能用，原因正在于它根本不是一个 20 步的全自动流程。它被拆分成 3~5 个独立的、可以单独验证的操作，有明确的回滚点和人工确认环节。Agent 负责生成复杂的基础设施代码，但整个系统架构都是基于可靠性这个数学限制来设计的。

我做过的每一个成功的 Sgent 系统都有相同的规律：有边界清晰的上下文、可验证的操作步骤，以及关键节点上的人工决策点。一旦你试图让智能体自主串联起超过几个步骤的复杂操作，数学就会让你吃瘪。

四、长对话意味着成本爆炸

还有一个数学现实是很多 AI agent 支持者故意忽略的：长上下文窗口会导致 token 成本呈二次方增长，这让基于对话的 Agent 在经济上根本不划算。

具体来说，做一个“会聊天”的 Agent 会遇到这样的问题：

• 每次新交互都得处理之前所有的上下文；

• token 消耗随着对话长度成二次方增长；

• 一场 100 轮的对话，仅 token 成本就可能高达 50 到 100 美元；

• 用户一多，一旦达到成千上万级别，这种成本就完全无法承受。

我自己在做一个会话型数据库 Agent 的原型时就深有体会。

刚开始几次的交互成本还算低，但到第 50 次请求时，每条回复的花费已经达到几美元，远超它能带来的价值。在绝大多数场景下，这种经济模型根本行不通。

我做的函数生成 Agent 之所以成功，是因为它完全无状态：输入描述-输出函数-过程结束。没有需要维护的上下文，也不用追踪对话，这就避免了成本的爆炸。它不是“和代码聊天”的体验，而是专注解决具体问题的工具。

实际上，生产环境中最成功的 Agent 往往根本不依赖对话。他们是聪明而有边界的工具，专注于做好一件事，然后干净利落地退出，不拖泥带水。

五、最大难题不是模型能力，而是工具设计

你就算搞定了上面两个数学问题，还得面对一个现实：AI 想用好工具，必须有合适的接口和反馈系统。但现在很多团队都严重低估了这个挑战。

现在的工具调用其实已经相当精准了，真正的难点在于工具设计。每个工具都必须经过精心打磨，既能给出合适的反馈，又不能让上下文窗口被信息淹没。你需要考虑：

• Agent 怎么知道某个操作只是部分成功？怎么在不浪费大量 token 的情况下传达复杂的状态变化？

• 比如数据库查询可能返回 1 万条数据，但 Agent 只需要知道“查询成功，1 万条结果，这里是前 5 条”，设计这种抽象表达是一门艺术。

• 当工具失败时，Agent 需要哪些信息来恢复？信息太少它会卡住，太多又浪费上下文资源。

• 怎么处理相互影响的操作？比如数据库事务、文件锁、资源依赖关系。

我做的数据库 Agent 能用，不是因为工具调用不出错，而是因为我花了几周时间设计了能和 AI 有效沟通的工具接口。每个工具都会返回结构化的反馈，Agent 能真正用来做决策，而不是单纯拿到一堆原始的 API 响应。

那些号称“接上 API，Agent 就能搞定一切”的公司根本没做过这方面的工程工作。他们把工具当成人机交互界面设计，而不是针对 AI 做设计。结果就是，虽然 Agent 在表面上能成功调用 API，却无法真正完成复杂的流程，因为它根本没弄懂发生了什么。

每个生产环境中的 Agent 系统背后都有个不为人知的真相：AI 可能只做了 30% 的工作，其余 70% 是工具工程——设计反馈接口、高效管理上下文、处理部分失败，以及构建 AI 能理解和利用的恢复机制。

六、整合现实考验

假设你已经解决了可靠性和经济性问题，接下来还得面对一个更大的挑战——和现实世界系统的集成，而现实往往很复杂糟糕。

企业系统并不是一套干净利落的 API，等着 AI agent 去协调。它们大多是遗留系统，有各种怪癖、存在各种故障模式、随时可能变动的认证流程、按时间变化的访问频率限制，还有一些合规要求，根本套不进简单的提示模板里。

我的数据库 Agent 不只是“自动执行查询”。它还得处理连接池管理、事务回滚、只读副本、查询超时，并且记录所有操作以备审计。AI 负责生成查询语句，其他一切都靠传统系统编程。

那些吹嘘“全自动 Agent 能无缝集成你整个技术栈”的公司，要么太乐观，要么根本没真正在大规模生产环境试过。在现实中，集成现实场景往往是 AI Agent 的坟墓。

七、什么才是真正可行的，以及原因

做过十几个覆盖整个软件开发生命周期的 Agent 系统后，我发现，成功的项目都有以下这些共同特点：

• 我的 UI 生成 Agent 之所以能用，是因为每个界面都要经过人工审查才能上线。AI 负责将自然语言转成可用的 React 组件，最终用户体验由人来把关。

• 我的数据库 Agent 之所以可靠，是因为每次有破坏性的操作都会先确认。AI 负责把业务需求转成 SQL，但数据完整性由人来保证。

• 我的函数生成 Agent 只在明确的边界内工作：给它一个规范，它输出一个函数。没有副作用，没有状态管理，也没有复杂集成。

• 我的 DevOps 自动化 Agent 通过生成基础设施，即代码（IaC）来工作，这些代码可以审查、版本控制、回滚。AI 负责把需求转成 Terraform 代码，但部署流程有我们多年积累的安全机制。

• 我的 CI/CD Agent 有明确的成功标准和回滚机制。AI 负责分析代码质量、生成修复建议，但最后合并与否由流水线控制。

总结成一句话就是：

AI 负责处理复杂问题，人工负责掌控关键决策，传统软件工程保障系统稳定可靠。

八、我的预测

以下是我对 2025 年哪些人将陷入困境的具体预测与判断：

• 那些靠风险投资撑腰、打着“完全自主 Agent”旗号的初创公司，会最先碰到经济瓶颈。他们的 Demo 在五步以内的流程还挺顺，但客户真正需要的是 20 步以上的复杂流程，这从数学上根本撑不住。为了解决这种不可能解决的可靠性问题，烧钱速度会飙升。

• 那些在已有企业软件产品上硬塞“AI agent”的公司，用户接受度会停滞不前。因为他们的 Agent 根本无法深入集成，处理不了真正的工作流程。

• 胜出者会是那些打造受限、面向特定领域的工具团队。这些工具用 AI 处理难点，同时在人类控制或关键决策上保持严格边界。换句话说，不是“全自动一切”，而是“能力超强且边界清晰的助手”。

• 市场最终会学会区分“演示效果好”的 AI 和“真正稳定可用”的 AI，而这个过程对许多公司来说代价会很高。

我并不是不看好 AI，而是不看好当前的 Agent 架构的做法。但我相信，未来会远比现在的炒作更有价值。

九、正确的构建方式

如果你打算做 AI agent，先从这些原则开始：

• 明确界限：你的 Agent 到底能做什么，哪些部分需要交给人或确定性系统处理？

• 设计容错：AI 出错的情况可能占 20%~40%，你该怎么应对？有没有回滚机制？

• 解决经济问题：每次交互花多少钱，随着用户增长，成本怎么扩展？无状态设计往往比有状态划算。

• 把可靠性放在自治前面：用户更信赖稳定好用的工具，而不是偶尔能搞出神操作的系统。

• 打好基础：AI 负责难点（理解意图、内容生成），关键环节（执行、错误处理、状态管理）仍靠传统软件工程。

Agent 革命迟早会来，只是它绝不会像 2025 年宣传得那样光鲜炫目，正因如此，它才更可能成功。

文章来自于微信公众号“CSDN”，作者是“Utkarsh Kanwat”。