layout: post
title: 上下文管理
date: ‘2026-08-24 12:00:00’
permalink: /agentic-engineering/context-management/
categories:
- 智能体工程
tags: - context
- agents
site_locale: zh-CN
lang_switch: /en/agentic-engineering/context-management/
summary_en: >-
本章开头的编程智能体工作原理向你展示了智能体循环：读取上下文 → 规划 → 行动 → 观察 →
重复。这个循环的质量几乎完全取决于"读取上下文"这一步。上下文做对了，智能体能产出出色的工作；做错了，再多的提示词调整也无济于事。 How Long Contexts
Fail
超长上下文窗口并不能自动使智能体变得更聪明——如果不加以管理，额外的上下文会成为负担而非资产。
summary_zh: >-
本章开头的编程智能体工作原理向你展示了智能体循环：读取上下文 → 规划 → 行动 → 观察 →
重复。这个循环的质量几乎完全取决于"读取上下文"这一步。上下文做对了，智能体能产出出色的工作；做错了，再多的提示词调整也无济于事。 How Long Contexts
Fail
超长上下文窗口并不能自动使智能体变得更聪明——如果不加以管理，额外的上下文会成为负担而非资产。
topic_cluster: agentic-engineering
confidentiality_safe: true
series_id: agentic-engineering
content_id: context-management
series_mode: full
book_url: https://xinheliu.github.io/Coding-with-Agents/zh-cn/02-anatomy/context-management.html
canonical_url: https://xinheliu.github.io/Coding-with-Agents/zh-cn/02-anatomy/context-management.html
上下文管理
Last updated: 2026-07-27
本章开头的编程智能体工作原理向你展示了智能体循环：读取上下文 → 规划 → 行动 → 观察 → 重复。这个循环的质量几乎完全取决于"读取上下文"这一步。上下文做对了，智能体能产出出色的工作；做错了，再多的提示词调整也无济于事。
长上下文为何会失效
超长上下文窗口并不能自动使智能体变得更聪明——如果不加以管理，额外的上下文会成为负担而非资产。
- 超大上下文窗口（最多 100 万 token）让人很想"把所有东西都塞进去"。
- 在实践中，随着上下文增长，智能体的表现往往下降，而非提升。
- 真正的挑战是有效的上下文管理，而非单纯增大窗口大小。
失效模式：
1. 上下文污染：错误变成"真相"
一个幻觉或错误事实进入上下文，在摘要和计划中被反复引用，智能体就此陷入不可能或无关的目标——无法在没有干预的情况下自我恢复。
2. 上下文干扰：过度拟合历史记录
随着上下文增长，模型开始过度关注过去的 token，而忽视其预训练知识。Gemini 2.5 在超过约 10 万 token 后开始重复动作而非创新。Databricks 发现准确率在达到最大窗口之前就已下降，尤其是对小模型。长上下文最适合摘要和检索——而非无边界的智能体推理。
3. 上下文混乱：工具过多或信息无关带来的过载
暴露所有可能的工具（MCP 风格）可能适得其反。所有模型在上下文中有大量工具时性能都会下降，甚至可能在不需要工具时也调用工具。例如：Llama 3.1 8B 在有 46 个工具时失败，但在 19 个工具时成功——即使两者都在上下文范围内。凡是在提示词中的内容，模型都必须处理——嘈杂的工具定义和无用的上下文会主动降低性能。
4. 上下文冲突：多轮次与多来源之间的矛盾
多轮次的"碎片化"提示词比单个精心组织的提示词表现差得多（平均性能下降约 39%；即使是 o3 也从 98.1% 降至 64.1%）。一旦模型"确定"了一条错误路径，它往往会过度依赖过去的输出，无法自我纠正。智能体尤其脆弱，因为它们聚合了多个工具、文档和子模型——每个都可能引入潜在冲突。
对智能体设计的启示：
最脆弱的配置恰恰是我们最关心的那种：在漫长历史记录上运行的多步骤、多工具、多来源智能体。缓解措施包括动态或选择性工具加载、“上下文隔离区"以隔离不可靠的内容，以及更严格的上下文管理，而非"把所有东西都倒进去”。
研究 → 规划 → 实现工作流
如果说有一个概念能将有效的 AI 辅助开发与令人沮丧的提示词乱按区分开来，那就是上下文工程——这是一种刻意构建模型所见内容以获得更好结果的实践。
Thoughtworks 的 Birgitta Böckeler 对此的简洁定义是：策划模型所见内容，以获得更好的结果。 对于编程智能体而言，这涵盖了从项目级配置文件（CLAUDE.md、.cursorrules）到单个提示词结构的一切。
新兴的最佳实践遵循三个阶段：
研究 — 让智能体先探索代码库。理解架构、识别相关文件，并构建一份包含文件路径、函数签名和系统关系的精简研究文档。
规划 — 在写任何代码之前，创建一份智能体（和你）可以审阅的分步实现计划。这是早期发现误解的关键。
实现 — 按计划逐步执行，随着任务完成压缩并更新上下文。保持上下文窗口精简——实践者建议将利用率保持在 40% 以下以获得最佳效果。
flowchart LR
Research[研究] --> Plan[规划] --> Implement[实现] --> Compact[压缩与更新] --> Research这个工作流正是上下文策略的落地——完整的智能体循环见编程智能体的工作原理。
核心洞见：你编写的提示词、规格说明和计划本身就是产品。代码只是输出。正如一位实践者所说：“CLAUDE.md > 提示词 > 研究 > 计划 > 实现”。将人的精力集中在流水线中杠杆效应最高的部分。
上下文管理原则
Good Context Leads to Good Code: How We Built an AI-Native Eng Culture
核心洞见：高质量软件不仅仅关乎编写代码——它关乎在整个开发生命周期中系统性地在人类与 AI 智能体之间构建和共享上下文。没有明确的、结构化的上下文，即使是强大的 AI 工具也会犯错或产出低质量的结果。
1. 将代码库视为共享的上下文工作区
将代码、文档和智能体指引组织在一个 monorepo 中，使人类和 AI 都能访问相同的上下文。自然语言文档是供 AI 消费的一等制品。上下文制品包括：高层设计文档（“为什么"和"是什么”）、实现计划（“如何”）、API/工具的指南与教程，以及 schema 定义和本地化的 README。
2. 分层构建上下文
逐步建构上下文的过程：
- 设计 — 人类定义需求和约束
- 规划 — 智能体将其转化为可操作的任务
- 实现 — 智能体生成大部分代码；人类审查
- 兜底 — 测试和安全机制锚定上下文，防止回归
- 审查 — 人类 + 智能体根据上下文验证工作
- 更新与优化 — 为未来工作更新文档和上下文制品
3. 始终在富含上下文的流程中使用智能体
智能体贯穿使用——用于提交信息、文档、规划、测试和调试——但从不脱离上下文或监督。智能体应增强人的意图，而非取代它。上下文成为人类专业知识与智能体能力之间的共同语言。
4. 使用工具来扩展和暴露上下文
使用 MCP 服务器和命令行工具，让智能体能够访问和更新外部真实来源，如 Notion / 任务跟踪器（如 Linear）、数据库状态和日志，以及 git 历史和 PR 元数据。这将上下文从静态文档扩展到实时系统和项目数据。
5. 上下文使 AI + 人类审查的组合成为可能
与其依赖单一智能体或单一人类审查者，不如使用多个模型（Claude、Gemini、o3 等）来交叉验证输出。共享的上下文仓库让这些模型能够一致且连贯地运作。
核心原则总结：
| 应该做 | 不应该做 |
|---|---|
| 在代码库中明确存储上下文（文档、计划、schema） | 让智能体在过时或不完整的上下文中运行 |
| 在实现之前设计上下文 | 只把上下文放在自己脑子里 |
| 随每次变更更新上下文 | 假设智能体会推断出未明说的约束 |
| 使用工具将外部项目信息纳入上下文 | 不经审查就信任智能体的输出 |