Skip to content

AI Agent 生产环境实践:挑战与解决方案

原作者: Utkarsh Kanwat
发布时间: 2025年7月19日
阅读时间: 10分钟
来源: https://utkarshkanwat.com


概述

本文基于作者在开发、DevOps 和数据运维领域构建 12+ 个生产级 AI Agent 系统的实战经验,深入分析了当前自主 Agent 架构面临的核心挑战,以及在生产环境中真正有效的方法。


核心观点速览

人人都说 2025 年是人工智能 Agent 元年。各种标题铺天盖地:"自主人工智能将改变工作"、"Agent 是下一个前沿领域"、"未来属于 Agent"。与此同时,作者过去一年都在构建各种不同的 Agent 系统,而且它们都已在生产环境中实际运行。正因如此,才对目前的炒作持怀疑态度。

实战案例:12+ 个生产级 Agent 系统

🔧 开发 Agent

  • UI 生成器:从自然语言创建功能性 React 组件
  • 代码重构 Agent:使遗留代码库现代化
  • 文档生成器:自动维护 API 文档
  • 函数生成器:将规范转换为可运行的实现

💾 数据和基础设施 Agent

  • 数据库操作 Agent:处理复杂的查询和迁移
  • DevOps 自动化 AI 系统:管理跨多个云提供商的基础设施即代码

✅ 质量和流程 Agent

  • AI 驱动的 CI/CD 管道:修复代码检查问题
  • 生成全面的测试套件
  • 执行自动化代码审查
  • 创建带有适当描述的详细拉取请求

这些系统行之有效,它们能带来实实在在的价值,每天节省大量人工时间。正因如此,许多关于 2025 年是"Agent 元年"的说法都忽略了关键的现实。


三个残酷真相

在构建这么多 AI 系统之后,总结出以下核心发现:

1. 错误率呈指数级复合

在多步骤工作流程中,错误率会呈指数级增长。每一步 95% 的可靠性,20 步下来只有 36% 的成功率。而生产环境需要 99.9% 以上的可靠性。

2. 上下文窗口导致成本二次方增长

上下文窗口会导致 token 成本呈二次方增长。大规模对话时,长时间对话的成本会变得极其高昂。

3. 真正的挑战在于工具设计

真正的挑战不在于人工智能的能力,而在于设计出 Agent 能够真正有效使用的工具和反馈系统。


一、无人提及的数学现实

这是每个 AI Agent 公司都在回避的一个令人不安的事实:误差累积使得自主多步骤工作流程在生产规模上从数学上成为不可能。

Error Compounding in AI Agent Workflows

图1:AI Agent 工作流程中的错误累积

可靠性数学

如果 Agent 工作流程中的每一步都有 95% 的可靠性(这对于当前的 LLM 来说已经算是乐观的估计),那么:

步骤数成功率
5 步77%
10 步59%
20 步36%

生产系统需要 99.9% 以上的可靠性。 即使你奇迹般地实现了每一步 99% 的可靠性(目前没人能做到),20 步下来也只有 82% 的成功率。

这不是一个 prompt 工程问题,也不是一个模型能力问题,而是数学上的现实。

解决方案:限制步骤数

成功的 DevOps Agent 之所以有效,恰恰是因为它并非一个包含 20 个步骤的自动化工作流程。它由 3-5 个独立的、可独立验证的操作组成,并设有明确的回滚点和人工确认环节。

成功 Agent 系统的共同模式:

  • ✅ 限定的上下文
  • ✅ 可验证的操作
  • ✅ 在关键节点引入人类决策点

一旦你试图自主地串联超过几个操作,数学计算就会让你崩溃。


二、Token 经济学中存在的缺陷

Agent 拥护者们有意忽略了另一个数学现实:上下文窗口会造成二次成本增长,这使得对话 Agent 在经济上不可行。

对话式 Agent 的成本陷阱

实际发生的情况如下:

  • 每一次新的交互都需要处理所有先前的上下文
  • Token 成本与对话长度呈二次方关系增长
  • 一场 100 回合的对话仅 token 就要花费50-100 美元
  • 用户数量达到数千时,这种模式就难以持续

Token Cost Scaling in Conversational Agents

图2:对话 Agent 中的 token 成本扩展

实战教训

在开发对话式数据库 Agent 原型时,付出了惨痛的代价。最初几次交互成本很低。但到了会话中的第 50 次查询时,每次响应的成本都高达数美元——远远超过了它所提供的价值

成功的秘诀:无状态设计

函数生成 Agent 之所以成功,是因为它完全无状态

描述 → 函数 → 完成

无需维护上下文,无需跟踪对话,也不会出现二次方级的成本爆炸。它不是"与代码聊天"的体验,而是一个专注于高效解决特定问题的工具。

核心发现:生产环境中最为成功的"Agent"根本不具备对话能力。它们是智能的、功能有限的工具,只做好一件事,然后就置身事外。


三、工具工程现实墙

即使你解决了数学问题,你也会遇到另一种障碍:为 Agent 构建生产级工具是一个完全不同的工程学科,大多数团队都低估了它。

工具设计的核心挑战

工具调用本身现在其实相当精确。真正的挑战在于工具设计。每个工具都需要精心打造,既要提供恰当的反馈,又不能让上下文窗口显得过于拥挤。

四大核心问题

❓ 状态反馈问题
Agent 如何知道操作是否部分成功?如何在不消耗 token 的情况下传达复杂的状态变化?

❓ 信息抽象问题
数据库查询可能会返回 10,000 行数据,但 Agent 只需要知道"查询成功,返回 10,000 条结果,以下是前 5 条"。设计这些抽象概念是一门艺术。

❓ 错误恢复问题
当工具发生故障时,Agent 需要哪些信息才能恢复?信息太少,Agent 会卡住;信息太多,则会浪费上下文信息。

❓ 依赖管理问题
如何处理相互影响的操作?例如数据库事务、文件锁和资源依赖关系。

核心发现

数据库 Agent 之所以能正常工作,并非因为工具调用本身,而是因为花了数周时间设计能够与人工智能有效通信的工具。每个工具都会返回结构化的反馈,Agent 可以利用这些反馈做出决策,而不仅仅是原始的 API 响应。

那些承诺"只需连接您的 API,我们的 Agent 就会自动处理"的公司并没有进行必要的工程开发。他们把工具当作人机交互界面,而不是人工智能界面。

不为人知的秘密

所有生产 Agent 系统都隐藏着一个秘密:人工智能可能只完成了 30% 的工作。

剩下的 70% 是工具工程:

  • 设计反馈接口
  • 高效管理上下文
  • 处理部分故障
  • 构建 AI 能够真正理解和使用的恢复机制

四、系统集成的现实检验

但假设你解决了可靠性问题和经济性问题,你仍然需要与现实世界相融合,而现实世界却是一团糟。

企业系统的真实面貌

企业系统并非等待人工智能 Agent 来协调使用的简洁 API。它们是存在以下问题的遗留系统:

  • 各种怪癖和特殊情况
  • 部分故障模式
  • 随时可能变更的身份验证流程
  • 随时间变化的速率限制
  • 无法完全套用模板的合规性要求

真实案例

数据库 Agent 并非只是"自主执行查询"。它还要:

  • ✅ 管理连接池
  • ✅ 处理事务回滚
  • ✅ 维护只读副本
  • ✅ 管理查询超时
  • ✅ 记录所有操作以进行审计跟踪

AI 负责生成查询;其他一切都由传统的系统编程完成。

那些承诺提供"可与你的整个技术栈集成的自主 Agent"的公司,要么过于乐观,要么根本没有尝试过大规模构建生产系统。集成是人工智能 Agent 的末路。


五、什么真正有效(以及原因)

在整个软件开发生命周期中构建了十几个不同的 Agent 系统之后,发现成功的 Agent 系统都具有一个共同的模式:

成功案例分析

1️⃣ UI 生成 Agent

✅ 人类审核每个生成的界面
✅ AI 翻译自然语言 → React 组件
✅ 人类掌握最终用户体验决策权

2️⃣ 数据库 Agent

✅ 确认每个破坏性操作
✅ AI 翻译业务需求 → SQL
✅ 人类把控数据完整性

3️⃣ 函数生成 Agent

✅ 清晰定义的边界
✅ 输入规范 → 输出函数
✅ 无副作用、无状态管理

4️⃣ DevOps 自动化

✅ 生成可审查、可版本控制的 IaC
✅ AI 翻译需求 → Terraform
✅ 部署流水线维护安全机制

5️⃣ CI/CD Agent

✅ 每个阶段有明确成功标准
✅ AI 分析代码质量并生成修复
✅ 流水线控制最终合并内容

核心模式

模式很明确:AI 处理复杂性,人类保持控制,传统软件工程处理可靠性。


六、对 2025 年的预测

以下是基于实战经验对 2025 年的具体预测:

💔 将要面临困境的

风投支持的"全自主 Agent"初创公司

  • 演示在 5 步工作流程下运行良好
  • 客户要求 20+ 步流程,数学上行不通
  • 资金消耗速度飙升

简单集成"AI Agent"的企业软件公司

  • Agent 无法深度集成
  • 难以处理实际工作流程
  • 用户增长停滞

🏆 获胜者将是

那些开发受限的、特定领域工具的团队:

  • ✅ 利用 AI 处理困难部分
  • ✅ 保持人类对关键决策的控制
  • ✅ 设置严格的边界

与其说是"完全自主",不如说是"功能强大但界限清晰的助手"。

市场终将学会区分演示效果出色的 AI 和真正可靠、可稳定部署的 AI。对许多公司而言,这种学习过程将代价高昂。

核心观点:并非不看好 AI,而是不看好当前的 Agent 架构方式。AI 的未来价值将远超目前的炒作。


七、以正确的方式构建 Agent

如果您正在考虑使用人工智能 Agent 进行开发,请从以下原则入手:

🎯 五大核心原则

1. 明确界定边界

你的 Agent 究竟能做什么,又将哪些任务交给人类或确定性系统处理?

2. 做好应对失败的准备

如何处理 AI 出错的 20-40% 的情况?你们的回滚机制是什么?

3. 解决经济效益问题

每次交互的成本是多少?成本如何随使用量变化?无状态架构通常优于有状态架构。

4. 可靠性比自主性更重要

用户更信任运行稳定的工具,而不是偶尔能带来奇效的系统。

5. 建立在坚实的基础上

  • 利用 AI 处理困难的部分(理解意图、生成内容)
  • 依靠传统软件工程处理关键部分(执行、错误处理、状态管理)

总结

Agent 革命即将到来。只是它不会像大家在 2025 年所承诺的那样发展。而这恰恰是它将会成功的原因。

"演示版有效"和"大规模应用版有效"之间的差距巨大,业内大多数企业仍在努力解决这个问题。

Agent 可靠性、成本优化和集成复杂性等方面的挑战都是引人入胜的工程问题,目前还没有显而易见的解决方案。

越多的人构建真实的系统并分享真实的经验,我们就能越快地找到真正有效的方法。


关键要点回顾

  1. 数学现实:误差累积使得长流程 Agent 在生产环境中不可行(95% 可靠性 × 20 步 = 36% 成功率)
  2. 成本问题:对话式 Agent 的 token 成本呈二次方增长,经济上不可持续
  3. 工具工程:70% 的工作是设计 AI 友好的工具接口,而非 AI 本身
  4. 集成挑战:企业系统的复杂性远超 Agent 的处理能力
  5. 成功模式:限制范围、保持人类控制、依靠传统工程保证可靠性

参考资源


相关阅读

Released under the MIT License.