面向智能体落地的上下文工程实践指南

在大模型应用从“演示可用”走向“生产可靠”的过程中，团队往往会发现一个反直觉的现象：模型能力并非唯一瓶颈，真正决定智能体表现上限的，是它在每一步推理时“看到了什么”。这就是上下文工程（Context Engineering）要解决的问题。它不同于传统提示词优化，不是雕琢一句指令的措辞，而是系统性地设计信息的筛选、组织、压缩、注入与更新机制。

一、为什么上下文成为智能体的核心变量

智能体的每一次决策，都依赖当前上下文窗口中的全部信息：系统指令、历史对话、工具返回结果、检索到的文档、中间推理状态等。上下文的质量直接决定三件事：

• 任务成功率：关键信息缺失会导致模型“凭空猜测”，产生幻觉或错误调用。
• 推理成本：上下文越长，输入 token 越多，费用与首 token 时延同步上升。
• 行为稳定性：无关信息会稀释注意力，使同一任务在不同轮次表现波动明显。

因此，上下文工程的目标可以概括为一句话：在有限的窗口预算内，让模型在正确的时间看到正确粒度的正确信息。

二、上下文的分层结构设计

一个可维护的上下文方案，通常需要把信息按“变更频率”和“重要性”分层，而非全部平铺。常见分层如下：

1. 静态层：系统角色设定、安全边界、输出格式约束。这部分几乎不变，适合放在窗口前部并保持稳定。
2. 策略层：当前任务的执行规则、可用工具清单、决策优先级。随任务类型切换而变。
3. 状态层：任务进度、已完成的子目标、待办事项、关键变量。需要每轮更新。
4. 证据层：检索文档、工具返回、外部数据。体量大、时效性强，是最需要压缩的部分。
5. 交互层：用户最近的输入与短期对话历史。

分层的好处在于：当窗口紧张时，可以按层设定淘汰优先级。例如优先保留静态层与状态层，对证据层做摘要或按需加载，而不是简单截断最早的消息。

三、上下文的写入策略：什么该进、什么不该进

上下文膨胀往往源于“能塞就塞”。更合理的做法是建立准入判断：

• 相关性判断：该信息是否直接影响当前子任务的决策？与当前目标无关的背景应留在外部存储。
• 时效性判断：旧版本的工具返回是否已被新结果覆盖？过期信息应替换而非叠加。
• 冗余度判断：多条信息是否表达同一事实？保留信息量最高的一条即可。
• 可信度判断：低置信度的推测不应与确定事实混在同一层级，避免模型误判。

一个实用的工程习惯是：为每条进入上下文的信息打上元数据标签，例如来源、时间戳、置信度、所属子任务。这样在压缩和淘汰时才有依据。

四、上下文压缩与检索协同

当证据层体量过大时，纯靠截断会丢失关键信息。常见做法是压缩与检索协同：

压缩策略：

• 抽取式压缩：保留原文关键句，去除修饰与重复。
• 生成式摘要：用模型把长文档压缩成结构化要点，但需注意摘要可能引入偏差，应保留回查原文的引用。
• 结构化转换：把自由文本转成表格、键值对或清单，提升信息密度。

检索策略：

• 按需检索：不要一次性把所有文档塞入，而是在需要时按子任务检索。
• 分层召回：先粗召回候选片段，再精排，只把高相关片段注入上下文。
• 引用回链：上下文中保留简短引用标识，需要细节时再回查原始来源。

示意性伪代码如下：

def build_context(task, state, budget):
    ctx = []
    ctx += static_layer()          # 固定系统约束
    ctx += policy_layer(task.type) # 任务规则与工具
    ctx += state_layer(state)      # 进度与变量
    evidence = retrieve(task.query, top_k=20)
    evidence = rerank(evidence)[:5]
    ctx += compress(evidence, max_tokens=budget * 0.4)
    ctx += recent_turns(state.history, n=3)
    return trim_to_budget(ctx, budget)

五、状态管理与长任务连续性

长任务中，上下文窗口无法容纳全部历史，必须依赖外部状态。常见模式是：

• 显式任务状态：把目标、子任务、完成情况写入外部存储，每轮只把精简状态注入上下文。
• 检查点机制：在关键节点保存上下文快照，失败时可从最近检查点恢复，而不是从头重放。
• 滚动摘要：对久远历史做分层摘要，近期保留原文，远期只保留结论与引用。

这样既控制了窗口占用，又保证了任务的可追溯与可恢复。

六、评估与迭代：让上下文可观测

上下文工程不是一次性设计，而是持续调优。建议建立以下观测维度：

• 信息命中率：完成任务所需的关键信息，有多少比例确实出现在上下文中。
• 窗口利用率：有效信息 token 占总 token 的比例，过低说明冗余严重。
• 上下文变更影响：调整分层或压缩策略后，任务成功率与成本的变化。
• 失败归因：区分失败是源于信息缺失、信息冲突，还是信息过载。

通过离线评测集与线上灰度结合，逐步沉淀出适配自身业务场景的上下文模板。

七、实践建议小结

1. 先分层，再压缩，最后才考虑截断。
2. 每条信息都应有来源与时效标注，便于淘汰。
3. 检索与压缩协同，避免一次性灌入全部证据。
4. 长任务依赖外部状态与检查点，而非无限扩张窗口。
5. 把上下文质量纳入可观测指标，持续迭代。

上下文工程本质上是一种信息架构能力：它要求开发者像设计数据库索引一样设计上下文，既不过度冗余，也不遗漏关键。随着智能体承担的任务越来越复杂，谁能把上下文管好，谁就能在效果、成本与稳定性之间取得更好的平衡。