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

大多数生产环境中的 AI agent 失败并不是因为模型耗尽了上下文。它们发生的原因是模型在达到限制之前很久就已经发生了 漂移 (drift)。Forrester 将 “agent 漂移” 称为 AI 加速开发的隐形杀手 —— Forrester 2025 年的研究显示，近 65% 的企业级 AI 失败都可以追溯到多步推理过程中的上下文漂移或记忆丧失，而不是单纯的 token 耗尽。

这种区别至关重要。硬性的上下文限制是很清晰的：API 拒绝请求，agent 停止，你会收到一个可以处理的错误。上下文腐烂 (Context rot) 则是隐蔽的：模型继续运行，继续生成输出，但性能却在悄然下降。仅根据信息在上下文窗口中所处的位置，GPT-4 的准确率就会从 98.1% 下降到 64.1%。你不会收到错误信号 —— 你只会得到微妙的错误答案。

本文涵盖了在生产级 agent 中管理上下文的三种主要工具 —— 压缩 (compaction)、工具结果清理 (tool-result clearing) 和外部记忆 (external memory) —— 以及在你的 agent 发生漂移之前应用它们的实际策略。

你的 AI 编程助手不记得昨天发生了什么。每个会话都是冷启动的 —— 它不知道你使用的是 yarn 而不是 npm，不知道你禁用 any 类型，也不知道 src/generated/ 目录是神圣不可侵犯的，永远不应该手动编辑。因此，它会使用错误的包管理器生成代码，在你禁止的地方引入 any，偶尔还会覆盖掉那些需要你花一小时才能恢复的生成文件。你纠正了它。明天它又犯同样的错误。你再次纠正它。

这不是模型质量问题。这是一个配置问题 —— 解决方案就是一个纯 Markdown 文件。

CLAUDE.md、AGENTS.md 及其针对特定工具的同类文件，是 AI 编程助手在每个会话开始前阅读的简报。它们编码了助手原本需要重新发现或被纠正的内容：运行哪些命令、避免哪些模式、团队的工作流如何构建，以及哪些目录是禁区。它们相当于一份详尽的工程入职文档，被压缩成了一种优化过的、适合机器阅读的形式。

大多数构建 AI Agent 的团队都犯了同样的错误：在没有证据表明需要复杂架构之前就过度设计。对 47 个 Agent 部署案例的生产分析发现，68% 的案例如果使用设计良好的单 Agent 系统，会获得相同甚至更好的结果。多 Agent 税——更高的延迟、复合的故障模式、运维复杂度——往往在用户感知到收益之前就将其消耗殆尽。

这并不是在反对 Agent，而是主张以构建任何严肃生产系统的方式来构建它们：从能工作的最简单方案开始，监控一切，只有在更简单的版本明显失效时才增加复杂度。

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 做出了正确的事情”之间的差距，正是大多数调试痛苦的根源。