Learn By Doing With Steven 数能生智

在 AI Agent 的演示视频里，它们完美地订机票、写报告、爬数据、调 API，流畅得像魔法。然后你把它部署到生产环境，第一周，它删掉了错误的文件。第二周，它在一个死循环里狂烧了 $300 的 API 费用。这，就是 AI Agent 的"最后一公里"问题。

演示的幻觉

2025 年，AI Agent 演示的质量到达了一个新高度。Devin（Cognition AI）在演示中独立完成了整个软件工程项目。OpenAI 的 Operator 演示了在真实网页上自动完成购物流程。Google 的 Project Mariner 在浏览器里自动操作，无需人工干预。

每一个演示都完美无瑕。每一个演示背后，都有经过精心选择的任务、反复排练的场景、以及你在视频里看不到的那些失败的尝试。

这不是欺骗。这是演示文化的本质。但它造成了一个巨大的期待鸿沟。

一、Agent 在生产环境中失败的五大根本原因

原因一：任务边界模糊——Agent 不知道"够了"在哪里

人类在执行任务时，有一种天然的"常识边界感"。当你让同事"整理一下这个文件夹"，他知道这意味着整理，不意味着删除，更不意味着重组整个目录结构。

AI Agent 没有这种内置的边界感。它会用字面意思最大化地理解你的指令——这在 Happy Path 上看起来很高效，在 Edge Case 上则可能造成灾难。

"帮我清理一下数据库里的旧记录"，可能导致 Agent 删除了你以为还有用的历史数据。"帮我优化这段代码"，可能导致 Agent 重构了你不想动的核心模块。

原因二：错误传播——一个小失误引发的链式反应

Agent 的本质是链式操作（Chained Actions）。第 1 步的输出，是第 2 步的输入。

在演示场景中，每一步都是预先验证过的，链路很短（通常 3-5 步）。在生产场景中，链路可能有 20-50 步，而且第 1 步的数据来自真实世界（API 返回值、数据库查询结果、用户输入），充满不确定性。

第 1 步的一个微小错误，可能在第 15 步累积成不可逆转的损害。

原因三：幻觉在 Agent 场景中的放大效应

在普通的问答场景中，LLM 的幻觉（Hallucination）顶多给你一个错误的答案，你可以验证并纠正。

在 Agent 场景中，幻觉可能直接触发真实世界的操作：

• Agent 幻觉出一个不存在的 API 端点 → 发出无效请求 → 消耗配额
• Agent 幻觉出一个错误的文件路径 → 覆盖了错误的文件
• Agent 幻觉出一个错误的 SQL 条件 → 更新了错误的数据库记录

幻觉 + 执行权限 = 真实损害

原因四：上下文窗口的衰退——Agent 的"失忆"问题

长任务（超过 20-50 步的 Agent Loop）会遇到一个技术问题：随着上下文累积，早期的关键信息被"推出"了模型的有效注意力范围。

Agent 开始忘记最初的任务目标。它可能开始重复已经完成的步骤，或者在一个小细节上反复尝试而忽略了更大的目标。

这不是模型不够聪明——这是当前 Transformer 架构的固有局限。

原因五：人机交互的缺失——谁来拍板"继续"？

在演示中，Agent 全程自主。在生产中，许多关键决策节点需要人类的判断：

• "这个 API 调用会花费 $50，你确认吗？"
• "我找到了 3 个可能的解决方案，你想要哪个？"
• "这个操作是不可逆的，你确定吗？"

缺乏优雅的 Human-in-the-Loop（人在回路）设计，是当前大多数 Agent 框架的共同弱点。

二、正在浮现的解决方案

解决方案一：结构化工具调用 + 严格的权限模型

最有效的 Agent 安全机制，是从工具设计层面入手：

# ❌ 危险的工具设计defexecute_command(cmd: str):"""执行任意 shell 命令"""return subprocess.run(cmd, shell=True)# ✅ 安全的工具设计defdelete_file(path: str, confirm: bool = False):"""删除指定文件（需要明确确认）"""ifnot confirm:returnf"将删除 {path}，请设置 confirm=True 以确认"ifnot path.startswith(ALLOWED_DIRS):returnf"错误：{path} 不在允许的目录范围内"    os.remove(path)returnf"已删除 {path}"

工具的设计，决定了 Agent 可能造成的最大损害边界。

解决方案二：Agent 评估（Evals）系统

成熟的 Agent 产品，需要一套自动化的 Evals 流水线：

• 任务完成率
  Agent 在多少百分比的任务中完成了正确目标？
• 幻觉检测
  Agent 有多少次调用了不存在的工具或参数？
• 安全边界测试
  Agent 在面对边界情况时是否会越权？
• 成本效率
  完成同一任务的平均 API 消耗，是否在可控范围内？

没有系统性的 Evals，你对 Agent 在生产中的真实表现，只是在盲飞。

解决方案三：分层 Agent 架构（Orchestrator + Subagent）

复杂任务的最佳架构，不是一个强大的单体 Agent，而是一个 Orchestrator 协调多个专注的 Subagent：

[用户请求]    ↓[Orchestrator Agent]（负责任务分解和决策）    ├── [Research Subagent]（负责信息搜集）    ├── [Code Subagent]（负责代码生成和执行）    └── [Review Subagent]（负责检验输出质量）

这种分层结构，让每个 Subagent 的上下文保持简洁，减少幻觉，同时提高整体可靠性。

三、"最后一公里"的真实成本

让我们量化一下 Agent 在生产中失败的代价：

这些成本，在演示阶段完全不可见。这正是为什么**"Demo 成功"和"Production 可用"之间，存在一道深深的鸿沟**。

Agentic AI 的成熟之路

AI Agent 不会消失。它代表的，是 AI 从"工具"到"协作者"的范式跃迁。但这个跃迁，需要时间和工程积累。

今天，我们处于 Agentic AI 的"早期混乱期"——像 2010 年的移动应用生态，充满了无法真正使用的 App。成熟期的标志，是那些经历了真实生产考验、建立了完整 Evals 体系、设计了严谨权限模型的 Agent 框架和产品。

等待那个成熟期，不是悲观——而是工程师应有的清醒。

你有过 AI Agent 在生产环境翻车的经历吗？那次失败教会了你什么？欢迎在留言区分享。

Learn By Doing With Steven 数能生智All my links: https://linktr.ee/learnbydoingwithsteven