720 篇博文 含有标签「llm」

你的团队花了三周时间构建了一个严谨的评估套件。它涵盖了各种边缘情况，包括对抗性示例。LLM 作为评测员（LLM-as-judge）在所有维度上的得分都达到了 92%。你发布了产品。

接着，客服工单接踵而至。用户反馈 AI “听不懂他们在问什么”。会话放弃率上升了 30%。满意度得分仅为 41%。

这种差距 —— 即评估表现与现实世界结果之间的鸿沟 —— 是当今生产级 AI 系统最常见的失败模式。这不是模型问题，而是衡量标准的问题。

一个自信地推荐已经缺货六个月产品的智能体；一个告诉用户查不到 20 分钟前下单记录的客服机器人；一个针对两年前已废弃的库 API 生成可正常运行代码的编程助手。这些并不是传统意义上的“幻觉”——模型只是在回忆曾经准确的信息。这是一种完全不同的失效模式，而且大多数团队还没有准备好如何检测或防御它。

这种区分至关重要，因为缓解措施根本不同。你无法通过提示词工程解决时效性问题。你也无法通过微调来解决——对过时的知识进行微调只会让问题变得更糟，而不是更好，因为模型会以更高的权威感表达过时的信息。随着模型在表达上变得越来越流利和自信，它们那些自信且错误的陈旧答案对用户来说变得更难察觉，而不是更简单。

一个团队在客服提示词中增加了三个词，为了让它“更具对话感”。几小时内，结构化输出错误率激增，一条创收流水线停滞。工程师们花了将近一整天的时间调试基础设施和代码，才有人想到去检查提示词。没有版本历史。没有回滚机制。这三个词的修改是由一位产品经理直接在配置文件中内联完成的，他完全没理由认为这会有风险。

这是一个典型的生产环境提示词事故。类似的戏码在各种规模的公司中上演，其根源几乎总是一样的：提示词被视作临时配置，而不是软件。

一个团队使用 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）。