Agent 上下文工程 ​

本篇边界：上下文工程只负责“这一轮模型看到什么、为什么看到、以什么顺序和格式看到”。它不拥有 Run State（运行状态），不负责把信息长期写成 Memory（长期记忆），也不决定真实动作权限；这些分别属于 Runtime（运行时）、Memory / Skill（记忆与技能）和 Policy Service（策略服务）。Harness（执行外壳）负责在模型之外编排并强制执行策略门禁，但不是身份或业务规则的权威来源。这样可以防止 Context Platform（上下文平台）被误做成新的超级状态中心。

本文要解决的不是“怎样把提示词写得更长”，而是一个企业级运行问题：当任务跨越多轮、多个工具和多个数据源时，怎样稳定地把正确事实、当前状态与可用能力投影给模型，同时把过期、越权、低价值和不可恢复的信息挡在模型之外。读完本文，读者应能设计上下文流水线、诊断上下文故障，并判断什么时候需要平台化、什么时候局部实现已经足够。

本文已经接近参考手册体量，不同目标不需要从头读到尾：

附录 A 是阅读索引和快速回答，不替代正文论证；需要做设计决策时，应回到表中对应的机制章节。

一、Context Engineering 到底是什么 ​

1.1 Context Engineering 到底负责什么 ​

核心结论 ​

Context Engineering（上下文工程）解决的不是：

“怎样把更多信息塞进模型。”

而是：

在有限的 Context Window（上下文窗口）、延迟、成本和注意力预算内，让模型在每一次决策时看到“正确、相关、及时、可信、最小必要”的信息与能力。

可以把它压缩成：

Context Engineering
=
What to include
+ What to exclude
+ When to include
+ In what format
+ At what priority
+ For which model / agent / turn

从上一章 Agent Loop（智能体循环）的视角看：

Run State + External Sources
        ↓
Context Engineering
        ↓
Model-visible Context
        ↓
Decision

因此：

State 是系统知道什么；Context 是这一轮模型被允许、被选择看到什么。

整篇可以先压缩成一张母图：

这张图表达了整篇的核心：

Context Source 很多
≠
全部进入模型

Context Engineering
= 在每个 Turn 动态管理“什么进、什么不进、什么压、什么外部化、什么隔离”

本文重点聚焦 Model-visible Context（模型可见上下文）如何被构建、更新、压缩、隔离和治理，同时明确 Tool Context 与 Lifecycle Context 的接口边界。

以下内容只讲必要边界，不在本文深入：

• 企业 Knowledge Source（知识源）、Retrieval（检索）、Authority（权威等级）与 ACL（访问控制列表）：知识检索与治理架构；
• Session（会话）和 Run State 的耐久化：Runtime 与持久执行；
• 长期 Memory / Skill 学习：记忆、技能与持续学习；
• Multi-Agent（多智能体）协作：多智能体与工作流编排；
• MCP（Model Context Protocol，模型上下文协议）等跨系统协议：跨系统交互与集成治理。

Context 到底是什么 ​

先给一个最简单、最不容易误解的定义：

Context（上下文）就是“模型在这一次调用里实际能够看到、并可能影响它本次决策的全部信息”。

这里有两个关键词：

1. “这一次调用”：Context 是按每次 Model Call（模型调用）动态变化的，不是一个永久不变的资料包。
2. “实际能够看到”：系统里存在的信息，不等于模型已经看到的信息。

例如一个 Coding Agent（编码智能体）修复登录 Bug（缺陷）：

系统知道：
- 整个代码仓库
- 1000 个历史提交
- 全部测试日志
- 当前用户权限
- 过去 50 轮会话
- 20 个可用工具

这一轮模型实际看到：
- 当前修复目标
- 3 个相关文件
- 最新测试错误
- 当前 diff
- 6 个当前允许使用的工具

后面这一小部分，才是这一轮真正的 Context。

Model Context（模型上下文）通常由哪些内容组成 ​

不是所有 Agent 都必须同时包含下面所有内容。

更准确地说：

这些是“可能的 Context 组成部分”，具体是否存在，取决于任务、框架、模型和当前 Turn（回合）。

这里真正重要的是这些来源为什么拥有不同生命周期、权限和可信度：

Context 是一个“按任务动态组装的视图”，不是一套固定字段。

为什么有的 Context 是“必须的”，有的是“按需的” ​

可以分成三档：

这里的三档表示上下文必要程度，不是投资优先级或系统成熟度等级：

基础必需：没有就无法正确理解当前任务
→ Current Task / 关键 System Policy

复杂任务常需：任务跨轮次、工具或阶段后通常需要
→ Relevant State / Recent History / Tool Definitions

按需提供：只有任务命中对应事实或能力时才加载
→ Retrieval / Memory / Skill / Artifact

例如：

简单问答

Current Task
+ Basic Instruction

可能就够。

Data Agent

Task
+ Metric Definition
+ Allowed Schema
+ SQL Tool
+ Query Observation

才比较完整。

Coding Agent

Task
+ Relevant Files
+ Current Diff
+ Test Failure
+ Edit / Test Tools

Context 会完全不同。

所以：

不存在一份所有 Agent 都应该永久携带的“标准 Context 全家桶”。

广义 Agent Context 还包括什么 ​

除了“模型这次看到了什么”，工程上还有两个相关概念。

例如：

模型看到：
“查询订单 123”

但 query_order Tool 执行时还可能需要：

user_id
tenant_id
database_connection
trace_id

这些信息不一定应该暴露给模型，却是 Tool 执行所需要的。

这就是：

Model Context 和 Tool Context 不完全相同。

LangChain 当前官方也使用 Model Context、Tool Context、Life-cycle Context 来描述 Agent Context Engineering。[^langchain-context]

Context Item 需要关注哪些属性 ​

任何一条 Context Item（上下文项），至少应该回答六个问题：

这些属性不是展示标签。它们会直接参与过滤、冲突消解、排序、压缩和审计：Visibility 或 Trust 不满足时必须在相关性排序之前拒绝；Authority 和 Lifetime 决定冲突项谁胜出；Provenance 让摘要错误可以追溯；Cost 只在正确性和安全边界满足以后参与取舍。

Context 与 Session / State / Memory / Knowledge 怎样划边界 ​

这一组概念不适合靠连续文字记忆，最清楚的方式是横向对比。

可以进一步记成一句话：

Session = 历史容器
State   = 当前执行事实
Memory  = 长期保留
Knowledge = 外部事实源
Context = 从上面这些来源中选出来，真正给模型看的“当前视图”

一个具体例子：Data Agent 查询 GMV（商品交易总额） ​

用户问：

“帮我查华东区上个月 GMV 同比。”

系统中可能存在：

Session
→ 用户前面问过“只看自营业务”

Run State
→ 已经定位到销售主题域，当前还未执行 SQL

Memory
→ 用户习惯金额单位用万元

Knowledge
→ 当前最新 GMV 指标定义、表结构、区域定义

Context
→ 当前 Task
 + “只看自营业务”
 + 最新 GMV 定义
 + 相关表 Schema
 + SQL Tool

这时就能看出：

Context 是多个来源经过选择以后形成的“当前模型输入”，并不是任何一个来源本身。

1.2 Context Engineering 与相邻技术的边界 ​

与 Prompt Engineering 的区别 ​

两者有关，但关注的问题完全不同。

可以用一个 Data Agent 例子区分。

Prompt Engineering 问：

“我要怎么写 System Prompt，才能让 Agent 先确认指标口径再写 SQL？”

Context Engineering 问：

“当前最新指标口径从哪里来？旧口径是否应该过滤？哪些 Schema 用户有权限看到？SQL Result 太大时怎么进入下一轮？”

所以本文采用的工程视角是：

Prompt Engineering 主要解决 Context 最终如何表达；Context Engineering 还负责这些信息从哪里来、为什么进入、优先级是什么以及如何随运行变化。

与 RAG 的区别 ​

RAG（Retrieval-Augmented Generation，检索增强生成）也只是 Context Engineering 的一部分能力。

例如 RAG 很成功地找到了：

GMV 相关的 5 篇文档

但其中：

文档 A：2024 旧口径
文档 B：2026 新口径
Session：用户只看自营
Tool Observation：当前表缺少某分区

RAG 只解决“找到了什么”。

Context Engineering 还必须解决：

哪个更权威？
哪个已过期？
Session 条件是否要叠加？
Tool Observation 是否改变下一步？
最终给模型多少？

因此：

高质量 RAG 是高质量 Context Engineering 的重要组成部分，但不是全部。

1.3 什么时候上下文会成为独立架构问题 ​

不是所有应用都需要复杂 Context Platform。

可以用下面这个判断表：

不能用“出现任意 3～4 个信号”作为平台化阈值，因为信号的风险权重不同。更可靠的判断分成硬触发和软触发：

Risk / Governance 硬触发
→ 跨租户或敏感数据可能越权进入模型
→ 高风险决策必须证明模型当时看到了什么
→ 法规、审计或删除要求必须落实到 Context Item

Failure / Scale / Reuse 多项软触发
→ Missing / Stale / Conflict / Compaction Loss 持续造成任务失败
→ 长任务、多 Tool、多来源使组装延迟或 Token 成本失控
→ 多个 Agent 重复实现相同 Snapshot、Policy Version 与质量门

硬触发出现一个就应建立明确的 Context Contract、快照和治理责任，但不等于必须建设集中式平台；软触发需要在同一业务周期内反复出现，并且共享机制的复用收益高于迁移、值班与发布成本，才支持平台化。单个多轮 RAG 应用即使同时具备多个技术特征，也可能只需要领域内流水线；反过来，一次严重跨租户泄漏即使没有规模问题，也足以触发治理升级。

为什么会从 Prompt 技巧演进成架构能力 ​

Context Engineering 不是因为“Prompt 越来越复杂”才出现，而是 Agent 的信息环境发生了质变。

可以把演进过程理解为：

Static Prompt
→ 信息少、来源固定
→ 重点是“怎么表达”

RAG
→ 外部知识增多
→ 开始解决“从哪里找”

Tool-using Agent
→ Tool Schema / Tool Result 进入模型
→ Context 不再只是文档

Long-running Agent
→ State / History / Observation 持续增长
→ 需要 Compaction（上下文压缩）/ Externalization（上下文外部化）/ Rehydrate（上下文重建）

Multi-Agent / Multi-tenant
→ Context 出现 Scope / Isolation / Permission
→ “相关”不再等于“允许进入”

Enterprise Scale
→ Source、版本、模型、策略持续变化
→ 需要 Provenance / Freshness / Authority / Snapshot / Eval / Release

Context Control Plane
→ Context 从 Prompt 拼接升级为受治理的运行时数据管道

所以真正的架构变化是：

Prompt Engineering
→ Presentation Problem（表达问题）

RAG
→ Retrieval Problem（检索问题）

Context Engineering
→ Runtime Information Governance Problem（运行时信息治理问题）

关键结论：

Context Engineering 的独立价值，不是“更会拼 Prompt”，而是让模型每一次决策都工作在一个可选择、可验证、可治理、可复现的信息世界里。

这也是为什么 Context 最终会成为 Agent Platform 的一等基础设施，而不是某个 Prompt Utility。

二、为什么需要 Context Engineering ​

2.1 为什么更大窗口仍解决不了问题 ​

模型能力不等于 Agent 能力 ​

Agent 的每一次行为，可以粗略理解为：

Decision Quality
=
f(
  Model Capability,
  Visible Context,
  Tool / Capability Set
)

模型再强，如果看不到：

• 当前数据库 Schema；
• 最新错误日志；
• 当前用户权限；
• 最新业务指标定义；

仍然会做错。

大量所谓：

“模型 hallucination（幻觉）”

真实根因可能是：

Missing Context
Stale Context
Conflicting Context
Buried Context
Wrong Tool Context

因此 Context Quality（上下文质量）是 Agent Quality（智能体质量）的核心变量。

Context Window 大不等于问题消失 ​

更大的 Context Window 只解决：

能不能装下。

它不解决：

信息是否相关
信息是否最新
信息是否可信
不同来源是否冲突
硬约束是否被埋没
Token 是否值得花
模型注意力是否被稀释
敏感数据是否越权

甚至窗口越大，“什么都塞进去”的诱惑越强。

所以：

Context Window 变大，Context Engineering 不会消失，反而会从容量问题升级为信息质量与治理问题。

Context 为什么本质上是 Attention Budget ​

Token Budget（Token 预算）只是显性约束。

还有一个更重要但不可直接观测的资源：

Model Attention（模型注意力）。

Context 中每加入一个 Item，都可能产生两种效果：

Useful Signal
or
Noise / Conflict

因此优化目标不应该只是：

Minimize Tokens

而应该是：

Maximize Decision-relevant Information Density（决策相关信息密度）。

可以建立一个工程视角：

Context Item
├─ Must-have
├─ Helpful
├─ Nice-to-have
├─ Noise
└─ Harmful / Conflicting

成熟 Context Engine 的目标：

保留前两类，控制第三类，尽量消除后两类。

2.2 上下文为什么会随任务持续退化 ​

Context Rot（上下文腐化） ​

Context Window（上下文窗口）是容量上限，但真正需要关注的是：

Context Utilization（上下文利用能力）并不会随着 Context Length 线性增长。

Anthropic 当前把这种现象概括为 context rot：随着 Context Token 增加，模型对其中信息的精准召回和长距离关系理解会逐渐下降。[^anthropic-context]

这和 Lost in the Middle（长上下文中部信息利用下降）共同说明：

More Tokens
≠
More Usable Information

可以把 Context 的边际价值理解成：

Context Utility
↑
│        ________
│      /
│    /
│  /
│_/________________→ Context Size
        边际收益下降

因此 Context Engineering 的核心不是：

maximize context size

而是：

maximize useful context

Context Rot（上下文退化）不是一个可由单一阈值直接判定的系统状态，而是几种压力叠加后的行为结果：旧历史持续累积会稀释当前任务；相似但不同版本的事实会增加冲突；大段工具输出会把关键约束推离最近注意力区；多次摘要还可能逐步丢掉数字、因果关系和失败记录。窗口尚未装满时，这些问题就可能发生。

因此生产系统不能把“接近最大 Token 才压缩”作为唯一策略。更可靠的处理链是：先通过 Snapshot（快照）和任务评测识别 Missing、Buried、Conflict 与 Compaction Loss 等可观察症状，再选择去重、重新排序、结果外部化、结构化压缩或开启 Fresh Context（新上下文）等不同动作。处理后必须在同一任务集上比较任务成功率、关键约束保留率和成本；仅仅看到 Token 下降，不能证明退化已经被修复。

这也是为什么：

• Tool Result 要压缩；
• History 要裁剪；
• Retrieval 要排序；
• Skill 要按需加载；
• Subagent 要隔离；

这些机制都不是“为了省 Token”这么简单，而是在保护模型的 Attention Budget（注意力预算）。

Context 怎样随 Agent Loop 动态变化 ​

Context 不是启动时生成一次。

真实 Agent：

Turn 1
→ 搜索代码

Observation
→ 找到相关文件

Turn 2 Context
→ 加入相关文件

Action
→ 运行测试

Turn 3 Context
→ 加入测试失败
→ 降低旧搜索结果权重

所以 Context 是：

Agent Loop 中不断重建的动态视图。

这也是为什么 Context Engineering 更像：

Runtime Data Pipeline

而不是静态 Prompt Template。

Context Failure 为什么会累积并放大 ​

一个错误 Context Item 不一定只影响一轮。

例如：

旧业务口径
→ 错误 SQL
→ 错误 Tool Observation
→ 被写入 History
→ Compaction 把错误结论总结下来
→ 后面持续引用

这就是：

Context Contamination（上下文污染）。

它会跨 Turn 传播，甚至跨 Session 写入 Memory。

因此 Context 管理必须关心：

• Provenance（来源）；
• Freshness（新鲜度）；
• Authority（权威等级）；
• Version（版本）；
• Scope（作用域）。

2.3 高质量上下文应该满足哪些系统性质 ​

不是下面所有性质都应该“平均关注”。

更合理的方式是按质量优先级分三层。这里的 P0/P1/P2 只表示上下文质量目标的处理顺序，不表示内容必要程度、投资阶段或平台成熟度：

P0：Correctness（正确性）
→ 没有它，任务直接做错

P1：Governance（治理性）
→ 没有它，系统难以安全、稳定、可追溯

P2：Efficiency（效率性）
→ 没有它，系统能跑，但成本 / 延迟 / 利用率会很差

P0：正确性，最优先 ​

P0 包括四个性质：

这四个性质决定：

模型是不是在“正确的事实世界”里做决策。

Completeness（必要完整性） ​

不是要求“信息越全越好”。

它只要求：

当前 Decision 所必需的信息不能缺。

例如 Coding Agent 当前要修改函数：

必须：
- 当前函数代码
- 调用关系
- 最新测试失败

不一定需要：
- 3 年前全部 commit
- 整个 monorepo 文档

衡量思路：

Context Recall
= 必须信息中成功进入 Context 的比例

Relevance（相关性） ​

Context 中虽然每条信息都可能“有点关系”，但真正有价值的是：

它是否能改变当前 Decision。

例如：

用户问 auth 401

相关：
auth middleware
token refresh
failed test

弱相关：
README
unrelated payment module
historical changelog

衡量：

Context Precision
= 进入 Context 的 Item 中真正有决策价值的比例

Freshness（新鲜度） ​

很多 Context 错误不是事实本身错误，而是：

曾经正确，现在已经过期。

例如：

旧 Schema
旧 API
旧 Feature Flag
旧业务口径
旧部署状态

因此 Context Item 最好带：

created_at
valid_until
source_version
observed_at

Authority（权威性） ​

相关、最新也不代表一定可信。

例如：

用户历史聊天：
“GMV 好像包含退款”

企业 Semantic Registry：
“GMV 明确定义为不含退款”

必须知道：

哪个 Source 是 Source of Truth（权威事实源）

所以 Authority 本质上是：

当多个 Context Source 冲突时，系统如何决定谁有最终解释权。

P1：治理性，企业生产必须关注 ​

P1 主要包括：

Isolation（隔离性） ​

例如两个租户：

Tenant A 的销售数据
Tenant B 的 Agent

即使语义上高度相关，也绝不能因为 Retrieval 命中而进入 Context。

因此 Isolation 是：

relevance 之前的硬约束

Reproducibility（可复现性） ​

发生错误时必须回答：

“模型做出这个决策的那一刻，实际看到了什么？”

这就是 Context Snapshot 的价值。

否则今天重放 Session 时，底层文档已经更新，你看到的 Context 可能和当时完全不同。

Provenance（来源可追踪） ​

Context Item 最好能回答：

来自哪个系统？
哪个文档？
哪个版本？
什么时候读取？
是否经过 Summary？

没有 Provenance，Authority、Freshness、Audit 都很难成立。

P2：效率性，系统规模起来以后重点优化 ​

P2 包括：

Compactness（紧凑性） ​

目标不是“越短越好”。

而是：

在不损失 P0 Correctness 的前提下，用尽可能少的 Context 表达足够信息。

因此：

先保证正确
再优化 Token

顺序不能反。

Utilization（有效利用） ​

一个 Item 已经进入 Context，不代表模型一定有效利用。

尤其超长 Context 中可能出现：

included
but
ignored

这就是为什么还要关注 Ordering、Structure 和 Context Rot。

Cacheability（可缓存性） ​

Context 中：

System Policy
Stable Instructions
Stable Skills

通常更适合成为稳定 Prefix。

而：

Current Time
Latest Observation
Run ID

属于动态部分。

这是成本优化问题，不应优先于 P0/P1。

最终优先级 ​

如果只能记一个顺序：

P0 Correctness
Completeness → Relevance → Freshness → Authority

        ↓

P1 Governance
Isolation → Provenance → Reproducibility

        ↓

P2 Efficiency
Compactness → Utilization → Cacheability

所以 Context Optimization（上下文优化）的基本原则是：

先保证模型看到的是“对的”，再保证是“安全可追溯的”，最后才优化“便宜和快”。

为什么 Context Policy 必须 Model-aware ​

Context Engineering 不能假设所有模型拥有相同的 Context Window、输出上限、缓存机制和长上下文利用能力。

截至 2026-09，主流模型的窗口规模已经明显增大。例如 OpenAI 当前 GPT-5.6 系列公开为约 1.05M Context Window；Gemini 3 系列也支持 1M 级输入窗口。[^openai-models][^gemini-models]

但这并不意味着：

1M Context Window
=
1M Token 都应该放满

需要同时考虑：

Hard Limit
→ 模型 API 能不能装下

Usable Context
→ 模型能不能有效利用

Reserved Output
→ 还要给输出 / Reasoning 留空间

Tool Schema Budget
→ Tool 定义本身也占 Context

Provider Cache
→ 不同模型缓存机制不同

Payload Limit
→ 某些平台可能先撞到请求体大小限制

例如 Google Gemini 官方明确说明 Context Window 是输入与输出共同受限的资源；Anthropic 也持续强调长 Context 存在 Attention Budget 和 Context Rot 问题。[^gemini-token][^anthropic-context]

因此企业 Context Engine 最好引入 ModelProfile（模型配置）：

interface ModelProfile {
  modelId: string;

  maxInputTokens: number;
  maxOutputTokens: number;

  preferredContextTarget: number;
  compactionThreshold: number;

  supportsPromptCache: boolean;
  supportsToolSearch: boolean;
  supportsMultimodal: boolean;

  toolSchemaBudget?: number;
}

注意：

maxInputTokens
≠
preferredContextTarget

前者是“绝对装得下多少”，后者是：

为了质量、成本和稳定性，实际希望 Context 控制在多少。

所以成熟 Context Policy 应该是：

ContextPolicy
=
f(
  Task,
  ModelProfile,
  ContextSources,
  Risk,
  CostBudget
)

而不是：

所有模型统一 max_context = 128k

三、上下文是怎样构建的 ​

3.1 上下文流水线怎样构建输入 ​

Context Pipeline（上下文处理流水线） ​

一个完整 Context Pipeline 可以表示为：

核心动作可以压缩成：

Discover
→ Filter
→ Rank
→ Budget
→ Transform
→ Assemble
→ Snapshot

先用一张表把每一步讲清楚：

这张表非常重要，因为后面的 Debug 其实就是沿着这七步逐层排查。

四个基础策略 ​

把所有具体技术继续往上抽象，可以得到四种非常稳定的策略：

Select（选择）
→ 什么应该进入当前 Context

Compress（压缩）
→ 如何降低上下文体积，同时尽量保留任务语义

Externalize / Write（外部化 / 写出）
→ 哪些状态不应该继续留在 Context，而应该写到文件、Artifact、Memory 或 Runtime State

Isolate（隔离）
→ 哪些信息应该被限制在某个 Agent、Subtask、Tenant 或 Tool Scope 中

Anthropic 当前对长任务 Context Engineering 的实践也主要围绕 Compaction、Structured Note-taking（结构化记笔记）和 Sub-agent Isolation（子智能体隔离）展开。[^anthropic-context]

这四个策略解决的是四个不同问题：

后面的 8 类 Context Operations 是这四个策略的工程细化，而不是另一套并列模型。

3.2 上下文来源与生命周期怎样设计 ​

Context Sources（上下文来源） ​

常见来源至少包括：

Context Engine 不应该把这些 Source 当成同质文本。

它们拥有完全不同的：

• 权威等级；
• 生命周期；
• 权限；
• 新鲜度；
• Token 成本。

Context Data Model（上下文数据模型） ​

建议把 Context Item 一等对象化：

interface ContextItem {
  id: string;

  type:
    | "policy"
    | "instruction"
    | "task"
    | "state"
    | "history"
    | "retrieval"
    | "memory"
    | "observation"
    | "skill"
    | "artifact_ref";

  contentRef: string;

  sourceType: string;
  sourceId?: string;

  authority: number;
  trustLevel: string;
  sensitivity: string;

  createdAt: string;
  validUntil?: string;

  relevance?: number;
  tokenCost?: number;

  mutable: boolean;
}

关键不是字段名本身。

而是：

Context 必须从“一堆字符串”升级为“带来源、生命周期和治理语义的数据对象”。

Context Lifecycle（上下文生命周期） ​

一个 Context Item 不应该被认为“检索出来以后就永远有效”。

它通常经历：

Created
→ Discovered
→ Selected
→ Visible
→ Used
→ Stale / Superseded
→ Compressed / Externalized
→ Evicted

例如业务指标定义：

v1 GMV definition
→ used for 2 weeks
→ v2 published
→ v1 becomes stale
→ v2 becomes authoritative
→ v1 remains auditable but should no longer be injected

所以 Context Item 最好具备：

version
valid_from
valid_until
superseded_by
last_verified_at

这让 Context Engine 从：

“检索文本”

升级成：

管理信息生命周期。

3.3 上下文操作怎样处理信息 ​

如果把不同框架、不同 Domain 的实现进一步抽象，可以发现 Context Engineering 反复在做八类操作：

Select       选择什么进入
Structure    以什么结构表达
Compress     如何在保留语义的前提下降低体积
Externalize  哪些信息不再放 Prompt，而放到外部状态 / Artifact
Isolate      哪些信息只属于某个 Agent / Subtask / Tenant
Refresh      哪些信息需要重新读取、替换旧版本
Update       本轮结果如何改变后续 Context Source
Snapshot     如何记录“这一轮到底看到了什么”

这八类操作比某个具体 RAG / Compaction API 更稳定。

后文所有具体机制都可以映射回这八类操作。

Candidate Selection（候选选择）

Discover（发现）：有哪些候选信息 ​

Discover 阶段回答：

当前有哪些信息可能对这次决策有用？

方式包括：

Recent History
Keyword / Semantic Search
Repo Search
Graph Traversal
Metadata Lookup
Memory Retrieval
Skill Discovery
Tool Result Reference

这里强调的是 Candidate Recall（候选召回）。

如果 Discover 没找到关键事实：

后面 Ranking 再好也无能为力。

Filter（过滤）：什么绝不能进入 ​

Filter 不只是“相关性过滤”。

至少包含：

Permission Filter
Tenant Scope
Sensitivity
Freshness
Environment
Task Scope
Source Trust

例如：

用户无权限的表
→ 不能进入 Data Agent Context

另一个租户的 Session
→ 必须过滤

过期业务口径
→ 默认淘汰

所以：

Context Security 必须发生在模型调用之前。

Rank（排序）：什么最重要 ​

Rank 不能只看 Semantic Similarity（语义相似度）。

生产 Agent 中更合理的 Ranking 可能考虑：

Relevance
Authority
Freshness
Task Phase
Dependency / Causality
Recency
Confidence
Token Cost

可以抽象：

ContextScore =
w1 * relevance
+ w2 * authority
+ w3 * freshness
+ w4 * task_fit
- w5 * token_cost
- w6 * conflict_risk

不一定真的使用这个公式。

它表达的是：

Context 排序应该是多目标决策，不只是向量相似度。

Budget / Transform / Assemble（预算 / 变换 / 组装）

Context Budget 不是一个 max_tokens 数字 ​

生产系统最好至少区分五类预算：

Hard Limit
→ 模型 API 的绝对上限

Soft Target
→ 实际希望控制到的输入目标

Output Reserve
→ 给输出 / Reasoning 预留空间

Tool / Schema Budget
→ Tool / Capability 定义占用

Dynamic Source Budget
→ History / Retrieval / Observation 等可动态分配

可以抽象成：

usable_input_budget
=
model_context_limit
- output_reserve
- safety_headroom

然后：

usable_input_budget
=
policy_budget
+ task_state_budget
+ history_budget
+ retrieval_budget
+ observation_budget
+ tool_schema_budget

这些不是固定百分比，而应该按 Task / Model / Phase 动态调整。

超预算时的淘汰顺序必须明确 ​

推荐先定义“不可淘汰层”和“可淘汰层”。

不可淘汰层

System Policy
Current Task
Hard Constraints
Critical State
Current Permission Scope

优先保留层

Latest Observation
Authoritative Domain Context
Current Plan
High-confidence Evidence

可压缩层

Old Conversation
Low-value Retrieval
Verbose Tool Output
Duplicate Evidence
Historical Failed Detail

一个常见策略：

1. Remove duplicate / obsolete items
2. Drop low-authority / low-relevance items
3. Replace large raw outputs with summary + pointer
4. Compact old history
5. Reduce retrieval breadth
6. Only as last resort trim useful recent context

Budget 应按“任务阶段”动态变化 ​

同一个 Agent 不同阶段需要不同 Context Mix。

Coding Agent：

Explore Phase
→ Retrieval / Search Budget 高

Edit Phase
→ Relevant Files / Diff Budget 高

Verify Phase
→ Test / Build Observation Budget 高

Data Agent：

Understand Metric
→ Semantic Context 高

Query Planning
→ Schema / Table Metadata 高

Result Analysis
→ Structured Evidence 高

所以：

Context Budget 是动态资源调度，而不是静态 Token 切片。

一个可执行的参考算法 ​

def allocate_context_budget(profile, task, phase, candidates):
    hard_limit = profile.max_input_tokens
    output_reserve = profile.max_output_tokens
    safety_headroom = int(hard_limit * 0.08)

    usable = hard_limit - output_reserve - safety_headroom

    protected = select_protected_items(candidates)
    remaining = usable - tokens(protected)

    phase_weights = budget_policy(task.type, phase, profile.model_id)

    selected = protected[:]

    for source_type in priority_order(phase_weights):
        items = rank_items(candidates, source_type)
        selected += fit_within_budget(
            items,
            remaining * phase_weights[source_type],
        )

    return selected

这段伪代码的重点不是具体算法，而是说明：

Context Budget
=
Model Profile
× Task
× Phase
× Source Priority
× Protected Items

Budget（预算）：不是所有高分 Item 都能进入 ​

Context Window 是硬上限，但真正预算还包括：

Input Token Cost
Latency
Prompt Cache
Tool Schema Size
Output Reserve
Reasoning Reserve

推荐使用分区预算：

System / Policy      15%
Task / State         20%
Recent History       20%
Retrieved Context    20%
Tool Observation     15%
Tools / Schema       10%

这些比例不是固定标准，而是一种工程思路：

不允许某一类 Source 无界挤占所有上下文。

Transform（转换）：原始信息不能总是直接给模型 ​

典型转换：

Large Log
→ Error Summary + Pointer

SQL Result
→ Schema + Stats + Sample + Pointer

Long Document
→ Relevant Chunk + Source Metadata

Tool Error
→ Structured Observation

Transform 负责：

Normalize
Summarize
Structure
Redact
Annotate
Compress

这一步是 Context Engineering 与“简单 RAG”差异最大的地方之一。

Assemble（组装）：顺序、角色和结构同样重要 ​

即使 Item 一样，组装方式也会影响效果。

可以采用逻辑优先级：

1. Non-overridable Policy
2. Agent / Domain Instruction
3. Current Task / Constraints
4. Relevant Current State
5. High-authority Domain Context
6. Retrieved Evidence
7. Recent Conversation
8. Tool Observations

这不是统一 Prompt 标准，而是强调：

高权威约束不能被低可信数据覆盖。

Anthropic 当前长上下文建议也强调：长文档需要显式结构化并携带 Source Metadata（来源元数据），而不是把大量文档无结构拼在一起。[^anthropic-long-context]

3.4 上下文快照为什么是一等对象 ​

每次关键 Model Call 最好能够回答：

模型做这个决定时，究竟看到了什么？

因此可以保存：

interface ContextSnapshot {
  runId: string;
  turnId: string;
  model: string;

  itemIds: string[];
  toolIds: string[];

  totalTokens: number;
  contextVersion: string;
  compactionVersion?: string;

  hash?: string;
}

不一定永久保存所有完整文本。

可以保存：

• Item ID；
• Version；
• Artifact Pointer；
• Hash。

Context Snapshot 对：

• Debug；
• Replay；
• Eval；
• Audit；

都非常重要。

四、Context Engineering 的关键机制 ​

先不要把后面的机制当成“全部都要上”。

不同问题对应不同策略：

下面再逐类展开。

4.1 检索、冲突和新鲜度怎样保证信息正确 ​

Retrieval（检索）不只看 Top-K ​

固定：

vector search top_k = 5

只是最简单实现。

生产检索还需要考虑：

Hybrid Search
Metadata Filter
Authority
Freshness
Graph / Dependency
Task Phase
Dynamic K
Reranking

例如 Coding Agent：

Semantic Similarity
+
Symbol Reference
+
Import Graph
+
Active Build Target
+
Test Coverage

往往比单纯 Embedding Similarity 更可靠。

Prefetch（预加载）、Just-in-time（即时加载）与 Progressive Disclosure（渐进式披露） ​

Context Retrieval（上下文检索）并不只有：

任务开始前一次性 Top-K

至少有三种模式。

Prefetch（预加载）

任务开始前就加载高概率需要的信息。

优点：

• 延迟低；
• 行为稳定。

缺点：

• 容易加载过多；
• 信息可能过期；
• 很难预测长任务后续真正需要什么。

Just-in-time（即时加载）

只保留轻量 Pointer（指针）和 Metadata（元数据），让 Agent 在运行中通过 Tool 自己进一步读取。

例如 Claude Code：

先看到文件路径
→ grep / glob
→ read relevant file
→ 根据结果再继续

Anthropic 当前明确把这种模式描述为 Just-in-time Context，并强调 Agent 可以通过文件路径、URL、存储查询等轻量引用在运行中逐步加载真实内容。[^anthropic-context]

Progressive Disclosure（渐进式披露）

先给概要，再按需要逐层展开：

Repository
→ Directory
→ File
→ Function
→ Relevant Lines

或者：

Business Metric
→ Definition
→ Lineage
→ Table
→ Rows

这能让 Agent：

随着任务理解加深，再逐步支付 Context Cost。

Hybrid（混合策略）

生产系统通常最好：

High-confidence Stable Context
→ Prefetch

Large / Dynamic / Low-confidence Context
→ Just-in-time

例如：

Policy / Task
→ upfront

Repo / Database / Web
→ runtime exploration

因此 Retrieval Strategy 不应该只有：

top_k

还应该回答：

什么时候加载、加载到什么粒度、由系统加载还是由 Agent 自主探索。

Conflict Resolution（冲突消解） ​

真实 Context 经常互相冲突。

例如：

Long-term Memory:
GMV = A

Current Semantic Registry:
GMV = B

不能让模型自己猜。

需要 Source Authority（来源权威等级）。

例如 Data Agent：

Current Semantic Registry
>
Current DB Metadata
>
Verified Memory
>
Historical Session
>
Retrieved External Docs
>
Model Guess

Context Engine 应显式：

• Detect Conflict；
• Select Authority；
• 标记矛盾；
• 必要时向用户确认。

Position / Ordering（位置与顺序） ​

信息“存在于 Context”不等于模型“有效使用了它”。

经典长上下文研究 Lost in the Middle 发现，模型对相关信息的位置存在明显敏感性：信息在长 Context 中间时，表现可能显著下降。[^lost-middle]

因此 Context Engineering 不能只关心：

Did we include it?

还应该关心：

Where did we place it?
How was it structured?
Was it separated from noise?

生产建议：

• 不可覆盖 Policy 使用稳定、高优先级结构；
• Current Task / Constraints 不要被大量历史埋没；
• 多文档携带清晰 Source / Metadata；
• Tool Observation 按阶段聚合；
• 对真正关键 Evidence 可以在最终 Task 附近再次结构化呈现。

Anthropic 当前长上下文指南同样建议对多文档使用显式结构与 Source Metadata，并针对长输入优化 Query / Document 的组织方式。[^anthropic-long-context]

所以：

Context Ranking 解决“选谁”；Context Ordering 解决“选中的信息如何被模型有效注意”。

Freshness（新鲜度）与 Temporal Context（时间上下文） ​

Context Item 不只是：

相关 / 不相关

还可能：

曾经正确，但现在过期。

因此 Item 最好带：

created_at
valid_from
valid_until
observed_at
source_version

尤其：

• 数据 Schema；
• 业务口径；
• API 文档；
• Feature Flag；
• 当前部署状态；

时效性非常重要。

4.2 长任务怎样跨 Context Window 延续 ​

Compaction（上下文压缩） ​

Compaction 不是：

“让模型总结一下前面对话。”

它是一个 Lossy State Transformation（有损状态转换）问题。

四种典型损失 ​

Fact Loss
→ 数字 / ID / 文件名丢失

Constraint Loss
→ “禁止修改 X”被弱化

Causal Loss
→ 只留下结论，丢失原因

Progress Loss
→ 忘记哪些尝试失败 / 哪些步骤完成

因此不要只生成一个自由文本 Summary。

可以结构化为：

Task Summary
Constraints
Decisions
Completed Steps
Tried & Failed
Important Facts
Artifacts
Open Questions

Compaction 何时触发 ​

最简单策略：

tokens > threshold

但生产上还可以结合：

Task Phase Completed
Tool Results Accumulated
Subtask Finished
Context Relevance Dropped
Idle Time
Model Window Pressure

Pi 当前官方实现就是一个很好的工程案例：超过 contextWindow - reserveTokens 后触发压缩，向后保留一定 Recent Tokens，对更老内容生成结构化 Summary，再用 summary + retained messages 重建 Context。[^pi-compaction]

Compaction 为什么是一致性问题 ​

Compaction 会修改“未来模型看到的历史”。

因此并发环境会出现：

Run A 开始压缩旧历史
Run B 同时写入新消息
Run A 完成后覆盖历史
→ Run B 新消息丢失

OpenAI Agents SDK 当前 OpenAIResponsesCompactionSession 会序列化 add_items / pop_item / clear_session 与整个 Compaction 操作；如果压缩过程中历史已被其他 Run 改变，还会跳过 stale compaction（过期压缩）。如果替换失败，还尝试恢复旧历史。[^openai-session]

这说明：

Context Compaction 已经不是 Prompt 技巧，而是并发、一致性和恢复问题。

Tool Result 如何进入 Context ​

Tool Result 是 Agent Context 最危险的污染源之一。

例如：

Shell 20,000 lines
SQL 50,000 rows
Browser Accessibility Tree
Search 100 pages

推荐三层：

Raw Artifact
→ 完整保存

Structured Observation
→ 模型默认看到

Pointer
→ 需要时 Drill Down

例如 SQL：

Raw:
50k rows

Context:
schema
row_count
summary stats
top anomalies
20 sample rows
artifact pointer

原则：

Tool Result ≠ Model Context。

Context Externalization（上下文外部化） ​

Context Window 不应该承担所有长期工作状态。

当信息具有这些特征时，更适合 Externalize：

内容很大
可重新读取
需要长期存在
需要多人 / 多 Agent 共享
属于真实世界状态

例如 Coding Agent：

Context 中：
当前任务 + 最新错误 + 相关代码片段

外部化：
repo
git diff
test report
progress.md
artifact

然后 Context 只保留：

Pointer
+ Current Summary
+ Relevant Slice

Claude 当前长任务指南明确提到：跨多个 Context Window 时，可以利用文件、测试和 progress state 保存进展，并在新 Context 中重新读取；某些情况下 Fresh Context + External State 反而优于持续压缩旧历史。[^anthropic-long-context]

因此需要在两个策略之间权衡：

Keep in Context
vs
Externalize + Rehydrate

这也是长任务 Context Engineering 的核心设计点。

Long-horizon Context Strategy（长周期上下文策略） ​

长任务超过一个 Context Window 后，通常有三类主要策略。

Anthropic 当前长任务实践也明确把这三类视为主要技术路径。[^anthropic-context]

Compaction（上下文压缩） ​

适合：

history continuity > exact raw trace

Structured Note-taking（结构化记笔记） ​

把进展写到 Context Window 外：

progress.md
todo.json
decision.log
artifact

后续重新读取。

它的关键优势：

重要状态不依赖模型“记住”。

Subagent Isolation（子智能体隔离） ​

让子 Agent 在独立 Context 中做重工作：

Parent
→ subtask contract
→ fresh context
→ deep exploration
→ compact result
→ Parent

这里的“隔离”不是简单删除父 Agent 的历史，而是建立一份可验证的委托契约。父 Agent 负责给出子任务目标、成功条件、必要证据、允许使用的能力、数据作用域和返回结构；上下文引擎据此选择最小必要信息；子 Agent 返回结论时还要携带证据或 Artifact Pointer（产物指针），由父 Agent 决定是否接受并合入主任务状态。

如果直接复制父上下文，敏感信息和噪声会随子任务扩散，Token 成本也会随 Agent 数量增长；如果只给一句目标，又会丢失关键假设和验收标准。真正的取舍不是“上下文越少越好”，而是让委托契约完整、工作材料按需读取、结果可追溯。子任务失败或返回证据不足时，应扩大特定 Source 的访问范围或重新委托，而不是立刻把父上下文全量开放。

三者不是互斥 ​

真实系统经常：

Main Context
→ Compaction

Long-lived Progress
→ Structured Notes

Heavy Research
→ Subagent

这三类策略共同构成长任务的 Context Management（上下文管理）基础。

Rehydrate Strategy（上下文重建策略） ​

当开启一个 Fresh Context（新上下文窗口）时，系统必须决定：

如何从外部状态重新构建“足够继续工作的 Context”？

推荐 Rehydrate Pack：

Task Contract
Hard Constraints
Current Phase
Completed / Failed Steps
Key Decisions
Important Evidence
Artifact References
Open Questions
Current Capabilities

这和 Compaction Summary 的区别是：

Compaction
→ 从旧 Context 压出一个新表示

Rehydrate
→ 从真实 State / Artifact / Memory 重新构建 Context

在长任务里，后者通常更可靠。

Context Checkpoint（上下文检查点） ​

Runtime Checkpoint 保存执行状态。

Context Checkpoint 可以额外保存：

context_snapshot_id
context_policy_version
compaction_version
model_profile

Resume 时：

Runtime State
+ Context Checkpoint Metadata
→ Rehydrate
→ New Context

这样不会强依赖：

“恢复时重新播放整个历史消息。”

Fresh Context vs Continue Context（新建上下文与延续上下文） ​

Continue Context

适合：

• 最近多轮推理强依赖；
• 当前 Context 仍干净；
• Tool Observation 不多。

Fresh Context

适合：

• Context Rot 明显；
• 已完成一个阶段；
• 大量旧信息已无价值；
• 外部状态足够完整。

因此长任务不应该只有：

context full
→ compact

这一种策略。

还应该支持：

compact
or
checkpoint + fresh context + rehydrate

真正成熟的长任务通常不是选一个，而是组合：

Compaction
+
External State
+
Subagent Isolation

4.3 Context 怎样隔离并抵抗不可信内容 ​

Context Isolation（上下文隔离） ​

Subagent 不应该默认继承 Parent 的完整 Context。

否则：

Token Cost × Agent Count
Sensitive Data Spread
Noise Propagation
Failure Context Duplication

推荐：

Task Contract
+
Minimal Necessary Context
+
Capability Scope
+
Return Schema

LangChain Deep Agents 当前官方明确将 Subagent 作为 Context Isolation 机制：子 Agent 使用独立的新 Context，完成重任务后只把一个压缩结果返回主 Agent。[^deepagents-context]

Context Security（上下文安全） ​

Context 是 Prompt Injection（提示注入）传播的核心载体。

至少给 Item 标记：

system_trusted
enterprise_trusted
user
retrieved_internal
retrieved_external
tool_untrusted

关键原则：

Data
≠
Instruction

外部网页中的：

“Ignore previous instructions”

必须被当成 Data，而不是 Policy。

推荐：

• Source Trust；
• Content / Instruction Separation；
• Sensitive Scope；
• Redaction；
• Policy 不从不可信 Context 生成；
• 高风险 Action 仍由独立 Policy Service（策略服务）作授权决策，由 Harness 在模型外强制执行门禁。

这组能力必须形成一条执行链，而不能停留在标签：Source Adapter（来源适配器）先记录租户、用户、来源类型和获取时间；Policy Filter（策略过滤器）消费 Policy Service 签发或返回的可见性决策，在检索与排序之前执行作用域过滤和敏感字段处理；Assembler（组装器）把外部内容放进明确的数据区，不能提升为系统指令；模型输出的 Action Proposal（动作提议）最后交给 Policy Service 按真实身份、动作参数和目标环境作授权决策，再由 Harness 在模型之外强制门禁。Context 层只决定“哪些信息可以进入本次模型视图”，Harness 不是业务权限或身份策略的权威来源。

失败路径也要分层处理：权限元数据缺失时应默认拒绝注入；外部内容疑似提示注入时可以保留原始 Artifact 供审计，但只向模型提供隔离后的摘要或引用；若模型已经受到污染，不能依赖追加一句安全提示修复，而应废弃本轮 Context Snapshot、回到可信 Checkpoint 并重新组装。验证时至少覆盖跨租户检索、间接提示注入、敏感字段脱敏和高风险动作二次授权四类用例。

4.4 Context Policy 为什么必须因模型而异 ​

Model-specific Context Policy（模型特定上下文策略） ​

Context Policy 不应该默认与 Model 无关。

不同模型可能具有不同：

• Context Window；
• Tool Calling 行为；
• Prompt Cache；
• Long-context 使用能力；
• Multimodal 能力；
• Reasoning Token / Output Reserve。

因此更合理的是：

ContextPolicy =
f(
  model_profile,
  task,
  source,
  budget,
  risk
)

例如：

• 大窗口模型可以保留更多 Recent Evidence；
• 小模型可能需要更强结构化和更少 Noise；
• 支持强 Tool Search 的模型可以减少预暴露 Tool；
• Cache 策略也可能因 Provider 不同而不同。

所以企业 Context Engine 最好不要把：

context_size = 32k

硬编码进 Domain 逻辑。

Multimodal Context（多模态上下文） ​

Context 不再只包含 Text。

可能包括：

Image
PDF
Audio
Video
Screenshot
Chart

这会带来新的 Budget 和 Compression 问题。

例如：

• 长截图是否每轮重复发送？
• PDF 应保留原页面还是抽取文字？
• 图表应该存 Artifact + structured summary，还是直接 Vision 输入？
• Compaction 是否会把视觉 Evidence 降维成文本后丢失信息？

LangChain 当前 Summarization Middleware 也明确指出：文本 Summary 并不会压缩图像 / 音频 / 视频本身；旧的多模态消息如果被总结，视觉内容可能只剩文本描述，因此应考虑把媒体放文件 / 对象存储，再通过 URL / Pointer 引用。[^langchain-summary]

所以：

Multimodal Context 需要 Artifact-first（产物优先）的设计，而不是简单 Message-history-first。

4.5 海量数据怎样进入 Context ​

Data Agent 是 Context Engineering 最典型、也最容易踩坑的场景之一。

本节用 Data Agent 展开，是因为“数据规模远大于上下文规模”能够最清楚地暴露计算、证据与模型输入之间的边界；Query Pushdown、Result Contract、Artifact 和 Drill-down 的原则同样适用于大型日志、浏览器页面、代码仓库与批量文档。本节不讨论数仓建模或指标治理本身，只讨论大结果怎样被转换为可验证的模型证据。

用户问：

“分析过去一年 3000 万订单，告诉我 GMV 下滑的主要原因。”

错误实现可能是：

LLM 生成 SQL
→ SQL 返回 3000 万行
→ JSON stringify
→ Tool Result 塞回模型

这个架构从根上就是错的。

因为：

Data Scale
>>
Model Context Scale

真正正确的原则是：

让计算靠近数据，让模型看到“分析所需的结构化证据”，而不是原始数据全集。

4.5.1 第一层：Query Pushdown（计算下推） ​

能在数据库完成的：

Filter
Aggregate
Group By
Join
Window Function
Top-N
Percentile
Sampling

不要先把数据拉回来再交给模型。

推荐：

Natural Language
→ Semantic Understanding
→ SQL / Query Plan
→ Database Compute
→ Small Result
→ Model

而不是：

Database
→ Massive Rows
→ Model
→ Ask model to aggregate

Databricks SQL MCP 当前官方就明确建议：大型 Result Set 会被截断以避免耗尽模型上下文，应该减少 Rows / Columns，或直接在 SQL 中做 Aggregate。[^databricks-sql-mcp]

Snowflake managed MCP 对 SQL Tool Result 也有响应大小限制，超限会截断，并建议缩小查询结果。[^snowflake-mcp]

4.5.2 第二层：Result Contract（结果契约） ​

Data Tool 不应该默认返回：

[
  {"row1": "..."},
  {"row2": "..."},
  ...
]

更成熟的 Tool Result 应该分层：

Query Metadata
+
Schema
+
Statistics
+
Representative Samples
+
Anomalies
+
Result Pointer

例如：

{
  "query_id": "q_123",
  "row_count": 31284321,
  "columns": ["region", "gmv", "yoy"],
  "stats": {
    "gmv_sum": 1280000000,
    "yoy": -0.137
  },
  "top_groups": [
    {"region":"east","yoy":-0.22},
    {"region":"north","yoy":-0.09}
  ],
  "sample_rows": 20,
  "artifact_ref": "result://q_123"
}

模型默认看到：

Metadata + Summary + Sample + Pointer

真正 3000 万行仍然留在：

Warehouse / Result Store

4.5.3 第三层：Drill-down（逐层下钻） ​

模型分析大数据，不应该“一次拿完”。

应该形成：

Overview
→ Detect anomaly
→ Drill down dimension
→ Drill down subgroup
→ Inspect samples

例如：

总 GMV -13.7%
↓
按 Region 聚合
↓
East -22%
↓
按 Category 聚合
↓
Electronics -31%
↓
查看 Top SKU / Promotion / User Segment

每一步都只把：

下一步决策需要的结果

带回 Context。

这其实就是 Data 场景里的 Progressive Disclosure（渐进式披露）。

4.5.4 第四层：Artifact-first（大结果产物化） ​

超过 Context Budget 的结果必须 Artifact-first：

Parquet
CSV
Table
Temporary View
Result Set
Chart
Notebook

Context 中只放：

artifact_id
schema
row_count
summary
preview

当 Agent 真正需要细节时：

read_rows(offset, limit)
aggregate(group_by=...)
sample(...)
filter(...)

重新读取。

Databricks Genie 当前也采用类似理念：面向模型的请求会返回截断结果；如果 Agent 真正需要完整结果，可以再调用专门接口获取完整 Schema / Rows，但超大结果仍然受 Size Limit 约束。[^databricks-genie]

到这里，首次学习需要掌握的 Data Context 主链已经闭环：

计算下推
→ Result Contract（结果契约）返回结构化摘要与引用
→ 逐层下钻只读取下一步决策所需信息
→ 大结果保存为 Artifact（产物）
→ Evidence（证据）携带查询、口径、时间与来源，接受任务级验证

例如“分析 3000 万订单的 GMV 下滑原因”，模型先看到全局聚合，再定位异常区域和品类，必要时读取代表样本；完整结果始终留在结果存储中。最终结论必须能反查 SQL、指标口径、数据时间和结果产物。下面的 Search-to-Prune、抽样边界、分页、异步查询、中间物化、句柄和血缘属于这一主链的数据场景深入附录：它们解释特定规模或查询系统下怎样实现，不是每个 Context Platform 都必须内建的通用能力。

4.5 深入附录一：Search-to-Prune（先搜索剪枝，再分析） ​

对于文本型大数据，例如：

1000 万条客服记录
500 万份合同段落
海量日志

直接把 Embedding Top-K 结果给模型也未必足够。

Snowflake 当前 Analytical Search 的企业实现非常有代表性：

Layer 1:
Search to prune
→ 从完整 Corpus 缩小候选集

Layer 2:
Materialize intermediate table
→ 再用 SQL / AI Functions 深入分析

而不是让大模型扫描整个 Corpus。[^snowflake-analytical-search]

这说明大规模 Context 的一个核心模式是：

先缩小数据空间，再让模型参与推理。

4.5 深入附录二：Sampling（抽样）不能替代 Aggregation（聚合计算） ​

一个常见错误是：

几百万行太大
→ 随机抽 100 行
→ 让 LLM 得结论

Sampling 只适合：

• 查看数据形态；
• 找示例；
• Inspect异常；
• 生成假设。

不适合直接回答：

GMV 总量
转化率
占比
同比
分位数

这些应该由 Data Engine 精确计算。

所以：

Exact Metric
→ SQL / Compute Engine

Qualitative Pattern
→ Sample + LLM

Large-scale Distribution
→ Aggregate / Histogram / Stats

4.5 深入附录三：Result Pagination（结果分页）不是简单 UI 分页 ​

Agent Tool 可以支持：

get_result(query_id, offset, limit)
get_topk(query_id, order_by, k)
get_group_stats(query_id, dimensions)
sample_result(query_id, strategy)

这让 Agent 能：

主动决定下一次需要查看哪一部分数据。

而不是一次 Tool Call 把全部内容塞进 Prompt。

4.5 深入附录四：Data Context 的三级表示 ​

企业 Data Agent 可以把结果分成三级：

L0 Raw Data
→ 数据仓库 / Lake / Result Store
→ 永不默认进 Context

L1 Structured Evidence
→ Schema / Stats / Aggregation / Samples
→ 默认进入 Context

L2 Narrative Context
→ 对 L1 的短摘要
→ 用于当前推理

这样可以同时保证：

Correctness
+
Token Efficiency
+
Drill-down Ability
+
Auditability

4.5 深入附录五：Semantic Context（业务语义上下文） ​

Data Agent 真正难的并不只是“行数太多”。

还包括：

Metric Definition
Business Glossary
Table Relationship
Data Freshness
Column Meaning
Access Permission
Time Semantics

例如用户问：

“GMV”

真正需要的 Context 往往不是几百万行订单，而是：

GMV 当前口径
时间范围
退款是否计入
币种
区域定义
可访问表
最新分区

Databricks Genie Agent 当前通过一个受控的表集合 / Ontology 来限制其数据域，而不是让 Agent 理解整个 Workspace；Snowflake Cortex Analyst 则围绕 Semantic View / Model 提供业务语义。[^databricks-genie-agent][^snowflake-agent-manage]

所以企业 Data Agent 的 Context Strategy 应该是：

Semantic Context
→ small but authoritative

Raw Data
→ huge but externalized

这是 Data 场景最重要的反直觉之一。

4.5 深入附录六：Data Agent 的 Context Decision Tree（上下文决策树） ​

这张图可以概括一句：

Move computation to data; move evidence to context.（把计算推向数据，把证据带回上下文。）

Data Agent Result Architecture（数据智能体结果架构） ​

Data Agent 的 Context 设计需要进一步把“Query Result”变成一等对象，而不是 Tool 返回字符串。

建议至少有：

interface QueryResultHandle {
  queryId: string;
  status: "RUNNING" | "SUCCEEDED" | "FAILED";

  rowCount?: number;
  schema?: ColumnSchema[];

  preview?: unknown[];
  statistics?: Record<string, unknown>;

  artifactRef?: string;
  lineageRef?: string;

  expiresAt?: string;
}

这样 Tool Call 返回：

QueryResultHandle

而不是：

millions of rows

Async Query（异步查询） ​

复杂 Data Agent 查询可能运行几十秒甚至几分钟。

不应该：

Tool Call
→ 阻塞直到 3000 万行准备完

更合理：

submit_query()
→ query_id

poll_query(query_id)
→ RUNNING / SUCCEEDED

get_result_summary(query_id)
→ schema / stats / preview

drill_down(query_id, ...)
→ next evidence

这样：

• Context 不需要等待完整数据；
• Agent 可以做并行分析；
• 长查询可以取消；
• Runtime 可以恢复。

Intermediate Materialization（中间结果物化） ​

长分析经常需要：

Step 1:
过滤过去一年订单

Step 2:
按 Region 聚合

Step 3:
只看 East

Step 4:
按 Category 继续下钻

不要每次从原始大表重新执行全部逻辑。

可以：

Materialized Result / Temp View
→ result://analysis_123_stage_1

后续 Agent 使用：

aggregate(result_ref, dimension="category")

这减少：

• 重复 Compute；
• Context 重复；
• Query Plan 重建。

Result Handle 比 Row Pagination 更重要 ​

分页：

offset / limit

只适合“浏览”。

分析更需要：

aggregate
filter
top-k
sample
describe
distribution
compare

所以 Result API 更应该是：

query_result.describe()
query_result.aggregate()
query_result.filter()
query_result.sample()
query_result.topk()

而不是：

next_page()

这是一种：

Analysis-oriented Result Interface（面向分析的结果接口）。

Data Lineage（数据血缘）必须进入 Evidence ​

模型给出结论：

“East / Electronics 导致 GMV 下滑 8.3%。”

企业系统最好还能回答：

这个数字来自哪条 SQL？
用了哪个 Dataset / Table？
用了哪个 Metric Definition Version？
数据分区是什么？
查询时间是什么？

因此 Context Evidence 可以携带：

query_id
metric_version
table_version
partition
lineage_ref
computed_at

这让结果具备：

Auditable
Reproducible
Explainable

Semantic Context 与 Data Evidence 要分层 ​

推荐：

Semantic Context
→ 指标是什么、字段什么意思、业务规则是什么

Data Evidence
→ 这次查询计算出了什么

Raw Data
→ 原始事实数据，留在 Warehouse

三者不要混。

如果语义和数据结果都直接变成文本：

后续很难判断是“指标定义错”还是“数据本身异常”。

4.6 Cache、Tool Context 与质量门怎样协作 ​

Cache-aware Context Engineering（缓存感知上下文工程） ​

对于 Agent，Context Cache 不是单纯的“模型服务商价格优化”。

Agent 的典型执行形态是：

Turn 1:
Large Context → Short Action

Turn 2:
Previous Context + Observation → Short Action

Turn 3:
Even Larger Context → Short Action

所以 Agent 常常表现为：

Input Tokens
≫
Output Tokens

Manus 团队公开分享其生产 Agent 的平均 Input / Output Token Ratio 约为 100:1，因此把 KV-cache（键值缓存）命中率视为生产 Agent 非常重要的指标之一。[^manus-context]

这意味着 Context Engineering 还必须关心：

同样的信息，能否以缓存友好的形式稳定重复出现。

Stable Prefix（稳定前缀） ​

通常适合稳定放在前部：

System Policy
Agent Instruction
Stable Skill
Stable Tool Definitions

动态内容放后部：

Current Task
Latest Observation
Run-specific Retrieval
Current Time

一个非常典型的反模式：

System Prompt 开头注入精确到秒的 current_time

即使只变一个 Token，也可能让后面大量 Prefix 无法复用缓存。

Append-only（只追加）比“回头改历史”更缓存友好 ​

Manus 的生产经验强调：

Append New Action / Observation

通常比：

Rewrite Old Context

更有利于 Prefix Cache。[^manus-context]

所以如果某条旧 Observation 需要“弱化”，可以优先：

保留旧记录
+
追加新状态 / 新结论

而不是每轮重新改写整段历史。

当然这不是绝对规则。

当旧内容：

• 包含敏感数据；
• 已严重污染；
• Context Rot 明显；
• 需要强制压缩；

仍然应该重写或重建 Context。

所以这里是：

Cache Stability 与 Context Quality 的 Trade-off。

Deterministic Serialization（确定性序列化） ​

即使语义相同，如果每轮 JSON Key 顺序、空格、字段格式随机变化，也可能降低缓存复用。

例如：

{"a":1,"b":2}

和：

{"b":2,"a":1}

逻辑相同，但 Token Prefix 不一定相同。

因此 Tool Schema、Context Pack、Metadata 最好：

stable field order
stable serialization
stable template

这是非常容易被忽略的生产细节。

Dynamic Tool Set 与 Cache Stability 的冲突 ​

我们前面强调：

Tool 太多
→ 应该动态 Routing，只暴露少量 Tool

但 Manus 的生产经验指出另一面：

如果每轮频繁增删 Tool Definition，工具通常位于 Context 前部，会导致整个后续 Prefix Cache 失效；历史 Action 又可能引用一个当前已经不存在的 Tool，模型也可能困惑。[^manus-context]

所以企业系统至少有三种策略：

没有统一最优答案。

应该根据：

• Tool 数量；
• Cache 成本；
• Provider 能力；
• Agent 生命周期；
• Tool Search 能力；

选择。

OpenAI ToolOutputTrimmer：另一类 Cache / Context 优化 ​

OpenAI Agents SDK 当前提供 ToolOutputTrimmer，会在每次 Model Call 前：

• 保留最近若干 Turn 的 Tool Output 全量；
• 把更老、过大的 Tool Output 替换成 Preview；
• 可以指定哪些 Tool Output 可被裁剪。[^openai-tool-trimmer]

这是一种很典型的策略：

Recent Context
→ High Fidelity

Old Bulky Tool Output
→ Compact Preview

它体现的是：

不是所有历史都同等重要，Context Fidelity 可以随时间衰减。

Cache 指标怎么监控 ​

至少：

prefix_cache_hit_rate
cached_input_tokens
uncached_input_tokens
stable_prefix_tokens
dynamic_suffix_tokens
cache_break_frequency

但必须和：

Freshness
Task Success
Stale Context Rate

一起看。

不能为了 Cache 命中而保留错误或过期 Context。

Tool / Capability 也是 Context ​

Context Engineering 不只管理文本和历史。

模型每轮看到的：

Tool Name
Description
Parameter Schema
Examples
Return Semantics

本身也占用 Context，并直接影响 Decision。

LangChain 当前也把“可用 Tools、Model、Response Format”明确归入 Model Context。[^langchain-context]

Tool Context 有几个典型问题：

Tool 太多
→ Context 变大、选择错误上升

Tool Description 太长
→ 占用 Attention Budget

Tool 功能重叠
→ 模型难以判断应该调用哪个

Parameter Schema 含糊
→ Action Argument 错误

Anthropic 当前工具设计经验也强调：

• Tool 功能要清晰；
• 避免功能重叠；
• 返回结果要 Token-efficient（Token 高效）。[^anthropic-tools]

所以 Capability Routing（能力路由）同时是：

Harness Problem
+
Context Engineering Problem

前者决定 Agent 拥有哪些能力，后者决定这一轮模型看到哪些能力描述。

Tool Context Surface（工具上下文表面） ​

模型每轮看到 Tool 时，真正消耗 Context 的不只是 Tool Name。

还包括：

Tool Name
Tool Description
Parameter Schema
Examples
Return Schema
Usage Guidance

因此可以把 Tool 看成特殊 Context Item：

interface ToolContextItem {
  toolId: string;

  descriptionTokens: number;
  schemaTokens: number;

  riskLevel: string;
  phase: string;

  semanticOverlapGroup?: string;
}

Tool Schema Budget ​

100 个 Tool 即使都“不调用”，也可能已经占据大量 Context。

所以 Context Budget 最好独立保留：

tool_schema_budget

当 Tool 数量过多：

Registry
→ Search / Route
→ Select small visible set

而不是：

all tools → model

Tool Description 也需要治理 ​

Tool Description 常见问题：

过长
→ 消耗 Token

过短
→ 模型不知道什么时候调用

多个 Tool 描述重叠
→ 选择错误

返回结果描述含糊
→ Observation 错误理解

因此 Tool Context Eval 可以单独评估：

Tool Selection Accuracy
Schema Argument Accuracy
Description Token Cost
Overlapping Tool Confusion

Tool Result Contract ​

Tool Context 不只包含“调用前的 Schema”，还包含“调用后的 Result Contract”。

推荐定义：

preview
summary
artifact_ref
row_count
truncated
has_more
error_type

特别是 Data / Shell / Browser 场景。

如果返回：

truncated = true

模型必须知道：

当前 Observation 并不代表完整数据。

这能避免：

截断结果
→ 模型误以为完整
→ 错误结论

Quality Gate（上下文质量门） ​

Model Call 前可以运行 Preflight Check（预检）：

required_context_present?
stale_items?
conflicting_sources?
sensitive_scope_ok?
token_budget_ok?
tool_result_too_large?
authority_order_valid?

这个机制往往比：

“换更强模型”

便宜且稳定。

4.7 Context 怎样进一步塑造注意力和轨迹 ​

Context 不只是“事实集合”。

模型还会从当前 Context 中学习：

现在最重要的目标是什么
过去哪些动作失败了
当前行为模式是什么
接下来可能重复什么

因此 Context Engineering 也会影响 Agent 的行为轨迹。

Recitation（目标重述）：把全局目标重新推回最近注意力区 ​

长任务中最常见的问题之一：

Context 越来越长
→ 原始 Goal 离当前 Token 越来越远
→ Agent 开始偏离目标

Manus 在复杂任务中会持续更新 todo.md，把 Goal / Plan 重新写入最近 Context。其目的不是普通任务管理，而是通过 Recitation（重述）让全局目标重新进入模型最近的注意区域。[^manus-context]

例如：

Goal:
完成竞争对手分析

Todo:
[x] 收集 5 家产品信息
[x] 比较定价
[ ] 验证 2026 年最新数据
[ ] 形成最终结论

每次更新以后：

Current Goal / Remaining Work

重新靠近 Context 尾部。

这可以降低：

• Goal Drift（目标漂移）；
• 重复已完成步骤；
• 忘记未完成任务。

Keep Failure Evidence（保留失败证据） ​

另一个常见反模式：

Tool 失败
→ 系统自动 Retry
→ 把失败记录删掉
→ 模型只看到“成功后的干净轨迹”

这样模型可能不知道：

某个方案刚刚已经失败过。

Manus 的实践是尽量保留错误 Action 和对应 Observation，让失败证据继续影响下一轮 Decision。[^manus-context]

这和本文前面的：

Tried & Failed

必须进入结构化 Compaction，是同一原则。

当然失败历史也不能无限累积。

推荐：

Recent Failure
→ Full Fidelity

Old Repeated Failure
→ Fingerprint + Summary

Pattern Lock-in（模式锁定）：Context 也可能把 Agent“教坏” ​

如果 Context 中充满高度重复的：

Action A
→ Observation A
→ Action A
→ Observation A

模型可能开始机械模仿这种模式。

Manus 把这类风险描述为“don't get few-shotted”：上下文中过于一致的行动轨迹会让模型陷入重复行为。[^manus-context]

生产上应该注意：

• 不要保留大量无价值重复轨迹；
• 对重复 Action 做 Summary；
• Progress Detection 与 Context Compression 联动；
• 保留“为什么停止重复”的新 Evidence。

所以：

Context 不只是知识输入，也是一种 Behavior Prior（行为先验）。

五、主流上下文系统怎样设计 ​

5.1 主流实现怎样验证 Context 的关键机制 ​

先用统一维度比较 ​

统一比较时，不是看谁 Feature 多，而是回答九个机制问题：

• Context Sources（上下文来源）：模型输入来自 State、Session、Memory、文件、知识库还是 Tool Result；
• State / Session Relation（与状态 / 会话关系）：哪些内容属于真实状态，哪些只是当前可见投影；
• Selection（选择）：候选信息怎样进入当前 Context；
• Compaction（压缩）：窗口不够时什么保留、什么外部化；
• Tool Result（工具结果）：大结果怎样规范化、引用和按需展开；
• Skill / Retrieval（技能 / 检索）：程序性知识和外部知识什么时候注入；
• Subagent Isolation（子智能体隔离）：不同 Agent 是否复制全部 Parent Context；
• Persistence（持久化）：Context Snapshot / Session State 在哪里保存；
• Debuggability（可调试性）：能否解释“为什么这一轮看到了这些内容”。

这九个问题才是跨产品稳定的比较维度。

先看机制，不按产品 Feature 数量比较 ​

这张表只用于定位各实现公开呈现的差异点，不是产品能力排名。某个项目支持 Session、Compaction 或文件外部化，只能证明它提供了机制入口，不能证明它在企业数据上满足权限隔离、压缩保真、故障恢复和可替换性要求。下文因此只保留每条路线最有区分度的机制证据；选择平台时仍须用固定任务集、快照和失败注入做验证。 | Manus | Action / Observation / File System | JIT / Tool-driven | Restorable Compression | Files / Task State | File System / Sandbox | Cache-aware Production Context |

这张表要回答的是：

Context 从哪里来？
什么时候选？
怎么压？
怎么隔离？
状态保存在哪里？

而不是谁 Feature 更多。

Pi：显式 Context 文件与结构化 Compaction ​

Pi 的特点是：

AGENTS.md / CLAUDE.md
→ 启动时分层加载项目 Context

Skills
→ 按需加载

Session Tree
→ 保留分支

Compaction
→ 结构化摘要 + Recent Messages

其 Compaction 官方公开到触发公式、reserveTokens、keepRecentTokens、CompactionEntry 和 Branch Summary 等实现。[^pi-compaction][^pi-session]

最值得学习：

Context 可以显式、可定制、可观察，而不是隐藏在框架内部。

OpenAI：Session、服务端 Compaction 与 Session Compaction 是三件事 ​

OpenAI Agents SDK 当前 Session 是一个持久对话历史协议，支持 SQLite、Redis、SQLAlchemy、MongoDB、Dapr、Encrypted Session 等实现。[^openai-session-protocol]

2026 的实现需要进一步区分三层：

1. Session（会话存储）：决定历史 Item 在哪里保存、怎样读写；
2. Responses Server-side Compaction（服务端压缩）：在单次 Responses 请求的 Context Management 中，达到阈值后由 API 产生 Compaction Item；
3. OpenAIResponsesCompactionSession（会话压缩包装器）：在 Turn 之间调用 responses.compact，然后对底层 Session 做 clear-and-rewrite。

第三种模式已经不是简单 Summary。它需要处理：

并发 mutation 序列化
stale compaction 检测
失败后的历史恢复
streaming 结束等待
store=false 时的 input-based fallback

也就是说，Context Compaction 已经进入 Consistency / Recovery / Latency 的工程问题。[^openai-compaction-session][^openai-model-context]

OpenAIResponsesCompactionSession 则作为 Session Wrapper：

Underlying Session
      ↓
Compaction Wrapper
      ↓
Runner

重点不是“会总结”，而是：

• 压缩后重写 Session；
• mutation 与 compaction 序列化；
• stale compaction 跳过；
• 失败后恢复；
• streaming latency trade-off。

最值得学习：

Context 生命周期已经进入 Runtime Consistency（运行时一致性）问题。

LangChain / Deep Agents：Model、Tool 与 Lifecycle Context ​

LangChain 当前官方把 Context Engineering 分为：[^langchain-context]

Model Context
Tool Context
Life-cycle Context

同时数据来源进一步区分：

Runtime Context
State
Store

这非常值得借鉴，因为它提醒我们：

“Context”不只是 Prompt 中的一段字符串，还包括 Tool 能访问什么、生命周期 Hook 如何修改状态。

Deep Agents 又进一步把：

Context Compression
Context Isolation
Memory
Skills
Runtime Context

组合进长任务 Agent Harness。[^deepagents-context]

Claude / Claude Code：JIT 与 Progressive Disclosure ​

Anthropic 当前 Context Engineering 实践有一条很鲜明的路线：

Stable Instructions
+
Just-in-time Retrieval
+
Progressive Disclosure
+
Compaction
+
Structured Note-taking
+
Subagent Isolation

Claude Code 不会把整个文件系统预加载进 Context，而是依赖 glob / grep / read / bash 等能力逐步发现和读取需要的信息，这就是 Just-in-time Context（即时上下文）和 Progressive Disclosure（渐进式披露）的典型实现。[^anthropic-context]

对于长任务，Anthropic 还强调：当任务跨多个 Context Window 时，可以主动把进展保存到文件、测试和结构化状态中，再在新 Context 中重新发现当前状态。[^anthropic-long-context]

这带来一个重要设计思想：

不一定所有长期状态都要通过 Summary 跨窗口传递。

对于 Coding Agent：

Filesystem
Git Diff
Tests
Progress File

本身就是外部 State。

因此 Context Engineering 还包括：

什么时候把信息留在 Context，什么时候外部化为可重新读取的 Artifact / State。

Microsoft Agent Framework：为什么 Context Provider 不等于 Tool ​

Microsoft Agent Framework 当前把 Context Provider（上下文提供器）放在 Agent 调用前后：它可以在模型生成之前主动注入 Memory、User Profile 或 RAG 结果，也可以在调用后提取需要长期保留的信息。[^ms-context-provider]

这个设计专门解决一个问题：

如果知识只能通过 Tool 获取，模型必须先意识到“我缺这条信息”才会主动调用。

对于用户画像、权限相关事实、稳定业务规则或高召回要求的信息，系统往往不能把“是否想起来调用 Tool”当成唯一入口。

因此 Context 进入模型至少有两类路径：

Reactive Tool Pull
→ 模型发现自己需要信息后主动调用

Proactive Context Provider
→ 系统在 Model Call 前基于 Policy 主动注入

两者没有谁绝对更好。

• Reactive Pull 更省 Context，也更自主；
• Proactive Injection 更可控、更适合必须出现的信息；
• 企业 Context Engine 应该显式决定哪些 Source 属于哪一种路径。

OpenCode：Agent Profile 与 Compaction ​

OpenCode 的价值不在于“它有多个 Agent 名字”，而在于它把不同 Agent Profile（智能体配置）和不同 Context / Capability Policy 绑定起来。

这里需要特别标注版本差异：截至 2026-09-13，OpenCode 当前主文档列出 Build / Plan 两个 Primary Agent，以及 General / Explore / Scout 三个 Subagent；但 OpenCode V2 文档明确列出 Build / Plan、General / Explore，并写明 V2 没有内置 Scout。因此本文不把 Scout 当成跨版本稳定事实，而把它作为“版本相关的只读研究型 Profile”理解。

可以抽象理解：

这说明：

Context Policy 不应该只按“应用”配置，还可以按 Agent Role / Phase（角色 / 阶段）动态变化。

例如同一个 Coding Task：

Explore 阶段
→ 多 Search / Read Context

Edit 阶段
→ Current File + Diff + Test

Verify 阶段
→ Test Result + Completion Criteria

比“所有阶段共用同一份大 Context”更合理。

Manus：生产级 Context Engineering 经验路线 ​

Manus 的 Context Engineering 很值得单独研究，因为它不是框架 API 设计，而是面向真实 Agent 产品规模长期迭代出来的一组工程经验。团队公开说明，其 Agent Framework 曾多次重构，而 Context Engineering 是核心优化方向之一。[^manus-context]

它的主要思路可以总结为：

Design around KV-cache
Mask / constrain action space carefully
Use filesystem as external context
Recite goals
Keep useful failure traces
Avoid repetitive trajectory lock-in

文件系统作为 Context 外部层 ​

Manus 明确把 File System 视为近乎“无限”的外部 Context：

Context Window
→ 有限、昂贵、会衰减

File System
→ 大、持久、可按需读取

压缩时尽量保留可恢复 Pointer：

Web Page Content
→ 可以丢
→ URL 必须保留

Document Text
→ 可以丢
→ File Path 必须保留

这是一种很重要的设计原则：

好的 Context Compression 最好尽量可恢复，而不是永久销毁信息。

生产启示 ​

Manus 的经验不是行业统一标准，但它非常有价值，因为它揭示：

Context Engineering 不只是 Retrieval / Prompt / Compaction，而是同时影响 缓存成本、工具设计、外部状态、注意力、错误恢复和行为轨迹。

5.2 主流路线共同收敛到什么，真正分歧在哪里 ​

这里同样不是 Ranking。

企业应该根据：

• 任务长度；
• 来源数量；
• 风险；
• Token 成本；
• Domain；

选择不同策略。

主流实现共同收敛的 Context 机制 ​

跨 Pi、OpenAI、LangChain / Deep Agents、Claude Code、Microsoft Agent Framework、OpenCode 和 Manus，可以看到：

1. Context 不再等于 Prompt 字符串，而是来自多种 Source 的运行时投影；
2. 长任务必须 Compaction + Externalization，单纯扩大 Context Window 不够；
3. 按需读取成为主流，文件、Skill、历史和 Tool Result 不应全部预加载；
4. Context Isolation 成为多 Agent 的重要收益，Subagent 不应自动复制全部 Parent Context；
5. Snapshot / Trace / Eval 必须能重建 Context 决策，否则 Context 问题无法 Debug；
6. Context Policy 越来越 Model-aware / Phase-aware，不存在一套 Token 策略适配所有模型和阶段。
7. 信息进入模型有 Proactive Injection（主动注入）和 Reactive Pull（主动拉取）两条路径，不能把所有 Context 都做成 RAG Tool，也不能全部预加载。

真正的架构分歧 ​

不同实现仍然在这些维度上取舍：

• Context 主要由 Framework 隐式管理，还是显式文件 / Context Pack；
• Compaction 是摘要替换，还是尽量保留可恢复 Pointer；
• Session / State 与 Context Engine 耦合多深；
• Tool / Skill 是否由模型 JIT 主动拉取；
• Cache / Prefix Stability 是否成为设计第一约束。

所以企业更应该标准化 Context Contract、Policy、Snapshot 和 Trace，而不是复制某一家 Compaction 算法。

六、企业级上下文平台怎样设计 ​

6.1 企业上下文平台应该统一什么 ​

核心原则 ​

企业 Context Architecture 最重要的不是建设：

“万能 Prompt 拼装平台”。

而是统一：

Context Item Semantics
Source Metadata
Authority
Scope
Freshness
Budget
Snapshot
Compaction Contract

核心原则：

统一 Context Contract，不统一所有 Context 内容。

Context Architecture 不会消灭复杂度，只会重新分配复杂度 ​

Context Engineering 的很多“优化”本质上只是把复杂度搬到更适合治理的位置。

因此评审 Context 方案时不能只问：

“Token 降了多少？”

还要问：

“为了减少 Context 复杂度，我们把复杂度转移到了哪里？新的复杂度是否可观测、可恢复、可治理？”

例如：

无限 History
→ Compaction
→ 新问题变成 Summary Loss / Compaction Version / Concurrency

Raw Tool Result
→ Structured Observation + Artifact
→ 新问题变成 Artifact Lifecycle / Drill-down / Result Contract

全量 Repo
→ JIT Read
→ 新问题变成 Search Quality / Tool Latency / Exploration Cost

Context 架构升级应该由 Trigger 驱动 ​

和 00 / 01 保持一致，Context 升级统一看五类 Trigger：

Failure Trigger
→ Missing / Stale / Conflict / Buried / Compaction Loss

Scale Trigger
→ History、Tool、Source、Result Size、Agent 数量持续增长

Risk Trigger
→ 多租户、敏感数据、外部网页、权限范围复杂

Reuse Trigger
→ 多个 Agent 重复实现 Source Metadata / Ranking / Snapshot / Compaction

Governance Trigger
→ 多模型、多策略、多版本无法归因和回滚

典型演进不是：

第一天
→ 建全公司的 Context Platform

而是：

Prompt / Simple History
→ 出现多 Source / RAG

Retrieval + Metadata
→ 出现 Stale / Conflict / Authority

Context Pipeline
→ 出现长任务 / 大 Tool Result

Compaction + Externalization + Snapshot
→ 出现多 Agent / 多租户 / 多模型

Context Contract + Policy + Eval + Control Plane

统一决策格式：

Trigger
→ 当前方案为什么开始失效

Decision
→ 引入什么 Context 机制

Trade-off
→ 新增什么复杂度

Evidence
→ 用什么 Context / Task 指标证明有效

6.2 契约、引擎和策略怎样协作 ​

Context Contract（上下文契约） ​

跨 Agent 平台真正值得统一的不是“Prompt 模板”，而是 Context Contract。

建议至少定义：

interface ContextRequest {
  runId: string;
  turnId: string;

  agentId: string;
  taskType: string;

  modelProfile: string;
  tokenBudget: number;

  identity: Identity;
  requiredTypes?: string[];
}

interface ContextPack {
  items: ContextItem[];
  capabilities: CapabilityRef[];

  policyVersion: string;
  rankingVersion: string;
  compactionVersion?: string;

  totalTokens: number;
}

这样 Context Engine 输出的不只是 String，而是：

一个可版本化、可审计、可复现的 Model Context Package（模型上下文包）。

Context Engine 参考接口 ​

interface ContextEngine {
  discover(
    request: ContextRequest
  ): Promise<ContextCandidate[]>;

  filter(
    candidates: ContextCandidate[],
    policy: ContextPolicy
  ): Promise<ContextCandidate[]>;

  rank(
    candidates: ContextCandidate[],
    request: ContextRequest
  ): Promise<ContextCandidate[]>;

  budget(
    candidates: ContextCandidate[],
    budget: TokenBudget
  ): Promise<ContextCandidate[]>;

  transform(
    candidates: ContextCandidate[]
  ): Promise<ContextItem[]>;

  assemble(
    items: ContextItem[]
  ): Promise<ModelContext>;

  snapshot(
    context: ModelContext
  ): Promise<ContextSnapshot>;
}

这仍然是参考抽象，不是行业标准 API。

Context Policy（上下文策略） ​

每一类 Source 建议定义：

when_to_load
authority
trust_level
max_budget
freshness
scope
retention
compaction
subagent_visibility

例如：

source: semantic_registry
authority: 100
freshness: 5m
subagent_visibility: domain_only

source: historical_session
authority: 30
freshness: 30d

source: external_web
authority: 20
trust_level: untrusted

这比：

“所有内容进向量库”

更符合企业治理。

6.3 上下文平台与相邻系统怎样分工 ​

这几个模块在真实系统里会协作，但不能混成一个“大 Context Service”。

一句话：

Runtime
→ 保存“真实状态”

Memory
→ 保存“长期信息”

Harness
→ 控制“能做什么”

Context Engine
→ 决定“这一轮看到什么”

Context 与 Runtime 的边界 ​

Context Engine 负责：

这一轮模型看到什么

Runtime 负责：

Session / State 如何持久化、恢复、并发

例如：

Runtime
→ 存 Session History

Context Engine
→ 从 Session 中只选最近 20 条 + 相关历史

所以：

Context 不负责 Durable State；Context 消费 Runtime State，并生成模型视图。

Context 与 Memory 的边界 ​

Context Engine：

决定这一轮要不要读 Memory
决定读哪条
如何排序
如何注入

Memory System：

决定什么长期保存
如何写
如何合并
如何遗忘
如何学习

因此：

Memory
→ Context Source

Context Engineering
→ Memory Read Policy

Memory Write / Learning 留在《Agent 记忆、技能与持续学习》中深入讨论。

Context 与 Security 的边界 ​

Context Engine 应负责：

Source Trust
Data Scope
Redaction
Context Leakage Prevention

但：

模型看到某个 Tool

和：

模型被允许执行高风险 Action

不是同一件事。

真实动作授权仍由 Policy Service 作出；Harness 只负责消费授权结果，并在模型之外强制执行门禁。

即：

Context Security
≠
Action Authorization

6.4 Context 平台怎样做到可观测和可治理 ​

Context Snapshot 只能回答：

“最终进了什么？”

企业级 Debug 还需要回答：

为什么进？
为什么没进？
为什么排这么高？
为什么被压缩？
为什么被替换？

所以推荐记录 Context Decision Trace：

interface ContextDecisionTrace {
  itemId: string;

  discoveredBy?: string;
  filters: FilterDecision[];

  rankScore?: number;
  rankFeatures?: Record<string, number>;

  authority?: number;
  freshness?: number;
  tokenCost?: number;

  selected: boolean;
  selectedReason?: string;
  excludedReason?: string;

  transformHistory?: TransformRecord[];
  parentItemId?: string;
}