企业AI的上下文管理实战

MIT 在 2025 年发布了一项令人震惊的数据：95% 的企业 AI 项目从未真正上线。不是模型不够强，不是算力不够多，而是——AI 拿到的”上下文”是错的。

模型回答了正确的问题，但回答的是错误的问题。因为没人告诉它，你们公司说的”收入”指的是确认收入而非毛预订量，没人告诉它 EMEA 区域有特殊的业务规则，也没人告诉它那个数据字段在三月就已经废弃了。

一、什么是 Agent 上下文管理？

先说清楚一件事：上下文管理不等于 Prompt Engineering。

Prompt Engineering 是每次对话前组装信息——你手动拼凑一段提示词塞给模型。这在单次交互中有效，但在企业级场景下会立刻崩溃：

• 每个团队各自维护自己的”上下文”，导致全公司有 20 个版本的”收入定义”
• 没有审计轨迹——当 AI 给出错误建议时，无法追溯用了什么信息
• 无法规模化——靠人手拼 prompt，根本覆盖不了上百个业务系统

真正的上下文管理（Context Engineering）是一套持久化基础设施：它将企业的业务定义、数据血缘、治理策略、组织知识，以机器可读的方式持续维护、统一治理、随时可被任何 AI Agent 调用。

二、四层上下文架构：大多数公司只做了第一层

在企业环境中，AI Agent 需要的上下文分为四个层级，每一层都建立在前一层之上：

残酷的现实是：绝大多数企业只做到了第 1 层（数据目录），而 AI Agent 真正产生商业价值的，恰恰是第 2、3、4 层。

三、企业级实践：五条可落地的策略

四、长对话场景：三个关键技术方案

在企业实际运行中，Agent 往往需要处理跨越数十轮甚至数百轮的长对话。这时单纯靠扩展上下文窗口是不够的，需要更精细的策略：

策略一：上下文压缩（Compaction）

当对话接近窗口上限时，将已完成的对话压缩为结构化摘要，用摘要重新初始化新窗口。保留架构决策、未解决的 Bug、关键实现细节；丢弃冗余工具输出和原始中间结果。Anthropic 官方的建议是从最大化召回开始，再逐步提升精度。

策略二：结构化笔记（Structured Note-taking）

让 Agent 定期将笔记持久化到外部存储（如 MEMORY.md），需要时按需拉回。适合有清晰里程碑的迭代开发场景——维护待办清单、跨会话追踪进度、维持复杂的任务依赖关系。

策略三：子代理架构（Sub-agent Architecture）

主代理负责高层协调和结果合成，子代理执行具体任务并返回蒸馏后的摘要（控制在 1000-2000 tokens）。这是复杂研究和分析场景的最佳选择——每个子代理专注一个小领域，主代理做全局整合。

五、如何判断你的上下文管理是否达标？

四个自检问题，任何一个回答”No”都说明你还停留在”战术”层面，而非”基础设施”层面：

1. 任意 Agent 团队是否都能直接查询同一套上下文
   
   ，无需各自构建检索管线？
2. 底层业务数据变化时，上下文是否自动更新？
3. 每条上下文断言是否有完整的审计追踪？
4. 能否为任意一次 AI 输出证明其合规性？

Gartner 预测到 2027 年，40% 的 Agentic AI 项目将被取消——原因正是成本失控和商业价值不明。而成本失控的根源，往往是每支团队都在重复建设上下文基础设施。

写在最后

上下文管理不是一个性感的技术话题。它不像大模型的参数量那样引人注目，也不像 RAG 那样自带光环。但它是决定你的 AI Agent 是”能用的玩具”还是”生产级的同事”的分水岭。

如果你正在推进企业级 AI 落地，我的建议是：别急着选模型，先把上下文的四层架构搭起来。模型会越来越便宜，但“你的业务怎么运转”这件事，只有你能教会 AI。

— 全文完 —