320 篇博文 含有标签「ai-agents」

2025 年，近 65% 的企业级 AI 失败归因于多步推理过程中的上下文偏移（context drift）或记忆丢失 —— 而非模型能力问题。如果你的智能体（agent）在执行长任务时决策失误或失去连贯性，最可能的原因不是模型，而是上下文窗口（context window）中的内容。

“上下文工程”（context engineering）一词正在迅速普及，但其背后的学科内容是具体明确的：即在智能体运行轨迹的每一个推理步骤中，主动、刻意地管理进入和离开 LLM 上下文窗口的内容。它不是一段提示词（prompt），而是一个由工程师设计、供智能体遍历的动态信息架构。上下文窗口的作用类似于 RAM —— 有限、昂贵，且如果你不进行刻意管理，就会出现抖动（thrashing）。

你的 Agent 正在返回 HTTP 200 状态码。延迟在 SLA 范围内。错误率平稳。仪表板上的一切都显示为绿色 —— 但你的用户却得到了言之凿凿的错误答案。

这是 AI 系统中核心的可观测性差距：传统上标志系统健康状况的指标，与你的 Agent 是否真正胜任工作几乎完全无关。一个 Agent 可以流利地产生幻觉、跳过必需的工具、使用陈旧的检索结果，或者陷入逻辑自相矛盾 —— 而此时你的监控却显示零异常。服务可观测性的标准手册并不适用于 Agent 系统，不理解这一差距的团队会发布他们无法信任、调试或改进的 Agent。

一个团队在采用 AI 编程智能体（AI coding agents）后，交付的拉取请求（PR）增加了 98%。这听起来像是一个成功的故事——直到你注意到评审时间增长了 91%，PR 的规模膨胀了 154%。代码交付的速度超过了任何人的验证能力。

这就是 80% 问题。AI 编程智能体非常擅长生成看起来似懂非懂（plausible-looking）的代码。当剩下的 20% 需要架构判断、边缘情况意识或任何比“编译通过了吗？”更复杂的反馈循环时，它们就会陷入停滞或悄然失败。在编程智能体上取得成功的团队，并不是那些提示词（prompt）写得最激进的团队，而是那些构建了更好的反馈循环、更短的上下文窗口（context windows）和更严谨的工作流的团队。

当 AI Agent 在生产环境中失败时，你很少能准确知道它是何时出错的。你看到的只是最终输出——一个幻觉答案、一个跳过的步骤，或者一个参数错误的工具调用——但实际的失败可能发生在三个步骤之前。这是软件工程尚未解决的核心调试问题：Agent 以一系列决策的形式执行，当你意识到出问题时，证据已经埋藏在交织的 LLM 调用、工具调用和状态变更的长轨迹中。

传统的调试假设确定性。你可以重现 bug，设置断点，检查状态。Agent 调试同时打破了这三个假设。相同的输入可以产生不同的执行路径。重现失败需要捕获发生那一刻的精确上下文、模型温度和外部状态。而且在实时推理循环中“设置断点”甚至不是大多数 Agent 框架所支持的功能。

大多数运行 AI 编程智能体（AI coding agents）的团队都在优化错误的变量。他们过度痴迷于模型选择 —— Claude vs. GPT vs. Gemini —— 却将周围的脚手架视为次要的配套工作。但基准测试数据和生产环境的实战经验告诉我们一个不同的故事：一个在演示中令人惊叹的模型与一个能够可靠交付生产代码的模型之间的差距，几乎完全取决于其周围的控制环（harness），而不是模型本身。

这个公式看似简单：智能体 = 模型 + 控制环 (Harness)。控制环是除此之外的一切 —— 工具 schema、权限模型、上下文生命周期管理、反馈循环、沙箱环境、文档基础设施、架构不变性。如果控制环搞错了，即使是最前沿的模型也会生成虚构的文件路径，在会话进行到 20 轮时破坏自身的约定，甚至在没写任何测试之前就宣称功能已完成。

大多数构建 AI Agent 的团队在第一个月都在追求性能：更好的提示词、更智能的路由、更快的检索。接下来的六个月，你则会忙于补救之前忽略的东西——治理（governance）。无法被审计的 Agent 会被法务部门叫停。没有权限边界的 Agent 会在预发布环境中造成混乱。没有人工升级路径的 Agent 则会在规模化运行时悄无声息地犯下严重的后续错误。

一个令人不安的事实是，大多数 Agent 部署之所以失败，并不是因为模型性能不足，而是因为围绕它的脚手架（scaffolding）缺乏结构。近三分之二的企业正在尝试 Agent；但只有不到四分之一的企业成功实现了生产规模化。差距不在于模型质量，而在于治理。

大多数构建 LLM 系统的人最初几周都会沉迷于优化提示词。他们进行 A/B 测试，争论该使用 XML 标签还是 JSON，并不断迭代系统提示词，直到模型输出看起来正确的内容。然而，一旦进入生产环境，加入真实数据、记忆和工具调用——模型就会开始出现各种提示词调优无法解决的异常行为。问题从来都不在提示词上。

生产级 LLM 系统的真实瓶颈在于上下文——即模型输入中包含什么信息、以何种顺序排列、信息量有多少，以及这些信息是否与模型即将做出的决策相关。上下文工程是将该输入空间作为系统首要关注点进行设计和管理的学科。它包含了提示工程，就像软件架构包含了变量命名一样：较小的技能依然重要，但它并不能大规模地决定最终成果。

这是一个在采用 AI 编程智能体的团队中不断上演的模式：一位开发者发现 Claude 违反了某条规则，于是他们在 CLAUDE.md 中添加了一个更清晰的版本。Claude 违反了另一条不同的规则，于是他们也把那条加上。几周后，这个文件达到了 400 行，而 Claude 忽略的规则比以往任何时候都多。解决方案反而让问题变得更糟。

发生这种情况是因为指令文件的一个基本属性，而大多数开发者从未将其内化：超过一定规模后，添加更多指令会导致模型遵循的指令变少。 正确编写指令文件与其说是追求完整性，不如说是进行无情的筛选 —— 知道该包含什么、该删除什么，以及如何构建其余部分。

你的 Datadog 仪表板显示零错误。延迟正常。所有服务都返回 HTTP 200。与此同时，你的 AI agent 刚刚在错误的时区预订了一个会议，幻觉了一个客户的订单历史，并为此烧掉了 4 美元的 token。

这正是让 agent 可观测性变得异常困难的原因：你现有的指标几乎无法告诉你 agent 是否真的在正常工作。

传统的分布式追踪建立在关于软件如何失效的一系列假设之上。LLM agent 违反了所有这些假设，而“我的基础设施是健康的”与“我的 agent 做出了正确的事情”之间的差距，正是大多数调试痛苦的根源。

一个 Shopify 规模的商户助手，每天处理 1,000 万次对话，在不进行优化的前提下每月成本高达 210 万美元 —— 而经过优化后，成本仅需 45 万美元。这 78% 的差距并非源于算法上的突破，而是来自缓存、路由以及一些大多数团队在收到账单前都会忽略的工程规范。

AI Agent 并不只是多了几个步骤的聊天机器人。单次用户请求会触发规划、工具选择、执行、验证，通常还有重试循环 —— 消耗的 token 数量大约是直接对话交互的 5 倍。一个运行 10 个周期的 ReAct 循环，其 token 消耗量可能是单次交互的 50 倍。在顶级模型的价格体系下，这种计算开销很快就会变成一项财务负担。

这篇文章将涵盖 Agent 成本的来源机制，以及能够真正产生影响的具体技术（附带数据支持）。

1969 年，Volker Strassen 发表了一种算法，使用比朴素方法更少的标量乘法来计算 4×4 矩阵。在 56 年的时间里，没有人做得更好。然后一个 AI 编程智能体重写了它——在生产环境中，部署在 Google 的全球基础设施上——并不是通过比人类数学家更聪明，而是通过运行一个循环：生成变体，评估它，保留有效的，重复。

这个循环才是重点。LLM 只是其中一个环节。其周围的架构才是让 AlphaEvolve 奏效的原因，理解这个架构能告诉你 AI 辅助工程正在走向何方。

你构建的一个智能体在最终输出评估中获得了 82% 的分数。你发布了它。两周后，你的支持队列里塞满了用户的投诉，抱怨智能体获取了错误的数据，使用了错误的参数调用 API，并且在错误的中期工作基础上生成了听起来很自信的回复。你回头查看追踪记录（traces）—— 发现智能体在 40% 的查询中路由都是错误的。最终输出评估从未捕捉到这一点，因为智能体往往还是误打误撞地得到了正确答案。

这是智能体评估中的核心陷阱：仅衡量最后输出的结果，无法告诉你智能体是如何到达那里的，而“到达那里”的过程正是大多数失败发生的地方。