273 篇博文 含有标签「llm」

一个团队使用 Claude 构建了一个 AI 研究助手。他们对 Prompt 进行了三周的迭代，向利益相关者演示了该助手，并满怀信心肠发布了它。两个月后，他们发现该助手在大约 30% 的输出中悄悄地产生虚假引用（幻觉）—— 这种失败模式之前没有人测试过，因为评估套件是在 Prompt 在演示中“感觉对了”之后才建立的。

这种模式是常态，而非例外。LLM 开发行业在很大程度上采用了测试驱动开发（TDD）的词汇 —— 评估（Evals）、回归套件、黄金数据集、LLM-as-judge —— 却忽略了 TDD 建立的最重要规则：在实现之前编写测试，而不是在实现之后。

以下是如何正确执行此操作的方法，以及 TDD 类比在哪些地方失效得非常严重，以至于字面上照搬它会让你的系统变得更糟。

2025 年中，一个构建多智能体（multi-agent）财务助手的团队发现其 API 开支从每周 127 美元飙升至 4.7 万美元。一个智能体循环——智能体 A 向智能体 B 寻求澄清，智能体 B 反过来询问智能体 A，以此类推——已经递归运行了 11 天。没有熔断机制（circuit breaker）拦截它，也没有及时触发预算报警。重试逻辑尽职地在每次超时后不断重试，使每一环节的失控成本不断叠加。

这不是一个关于模型质量的故事。这是一个关于分布式系统工程的故事——特别是关于大多数 LLM 应用开发者跳过的那部分，因为他们假设供应商会处理好这些。

事实上，他们并不会。

大多数在 LLM 上构建应用的工程师都将延迟视为一个单一的刻度盘。他们调整一些参数——批处理大小（batch size）、量化级别（quantization level）或实例类型（instance type）——观察“它是否变快了”，然后就收工了。这在上线生产环境之前一直有效，直到你发现 p50 TTFT 看起来不错，而 p99 却超过了 3 秒，或者发现让吞吐量翻倍的优化不知为何却让单个用户感觉系统变慢了。

TTFT 和吞吐量（throughput）并不是同一个滑块的两端。它们是由根本不同的物理特性引起的，受不同瓶颈的影响，并由不同的技术修复。将它们视为可互换的是我在生产环境中看到的大多数 LLM 推理事故的根本原因。

你在合成数据上微调的模型在内部评估中得分 95%。然后你部署了它，它却自信地编造出不存在的药物相互作用，引用了案件编号错误的法律先例，并幻觉出名称听起来很合理的 API 端点。模型的流畅度没有退化——它以一种流畅度指标完全无法察觉的方式变得更糟。研究人员称之为知识崩溃 (knowledge collapse)：事实准确性下降，而表面连贯性完好无损。这是合成数据训练中较为隐蔽的失败模式之一，通常发生在工程师构建流水线却未考虑到这一点时。

对于在特定领域微调 LLM 的团队来说，合成数据生成已变得不可避免。大规模的人工标注不仅昂贵、缓慢，且对于需要专业知识的任务来说是不可能的。由能力强的教师模型生成的合成数据可以廉价地填补这一空白。但流水线并不只是“向 GPT-4 索要示例，然后训练你的模型”那么简单。细节决定了你得到的是一个在特定领域表现优于通用模型的专业系统，还是一个流畅但事实漏洞百出的系统。

大多数基于 LLM 的应用中都潜伏着一个隐形 Bug。它不会出现在单元测试中。在前一千次请求中也不会触发。它会一直潜伏，直到用户输入了带有引号的内容，或者模型出于某种莫名其妙的原因决定将其 JSON 响应包裹在 Markdown 代码块中，再或者将 "count" 字段作为字符串 "three" 而非整数 3 返回。这时，你的生产流水线就会崩溃。

“LLM 是文本生成器”与“我的应用需要结构化数据”之间的鸿沟，是大多数可靠性问题产生的原因。弥补这一鸿沟并非 Prompt 工程问题，而是一个基础设施问题。在 2026 年，我们终于拥有了能够正确解决这一问题的工具。

Manus 团队在不到一年的时间里重建了四次他们的智能体（agent）框架。这并非因为模型发生了变化 —— 底层 LLM 在稳步提升。他们之所以重建，是因为不断发现了更好的方式来塑造进入上下文窗口（context window）的内容。

他们将这一过程称为“随机研究生下降”（Stochastic Graduate Descent）：手动的架构搜索、提示词微调和经验性猜想。这是对构建生产级智能体真实面貌的坦率描述。在经历了数百万次真实用户会话后，他们总结出了六种具体的技术，这些技术决定了一个长周期智能体（long-horizon agent）是会取得成功，还是会陷入混乱。

核心洞察说起来简单，内化却很难：“上下文工程（Context engineering）是一门微妙的艺术与科学，即用恰到好处的信息填充上下文窗口，以支持下一步操作。”一个典型的 Manus 任务运行约 50 次工具调用，输入与输出的 token 比例高达 100:1。在这样的规模下，你在上下文中放入了什么 —— 以及你是如何放入的 —— 决定了一切。

生产环境中的智能体存在一种失效模式，大多数工程师都是通过惨痛的教训才发现的：你的智能体在最初的几步表现良好，但在任务执行到一半时开始出现幻觉，遗漏了开头明确给出的细节，或者发出了一个与二十步前的指令相矛盾的工具调用。模型没有变。任务没有变难。上下文变了。

长时间运行的智能体积累历史记录的方式就像浏览器标签页消耗内存一样——无声无息、永不停歇，直到崩溃。每一个工具响应、观察结果和中间推理轨迹都会被追加到窗口中。模型会看到这一切，这意味着它在后续的每一步都必须对所有内容进行推理。随着上下文的增长，精度会下降，推理能力会减弱，模型会遗漏本应捕获的信息。这就是“上下文腐烂”（context rot），也是生产级智能体最常见的失效模式之一。

大多数生产环境中的 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 发生漂移之前应用它们的实际策略。

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 框架所支持的功能。