Context Engineering

Context 是运行时视图，不是数据仓库

模型一次推理能看到的全部 Token——系统指令、Tool 描述、消息、状态、检索片段、Memory 和环境观察——共同构成 Context。Anthropic 在 2025 年的工程文章中把 Context Engineering 定义为：从不断演化的候选信息中，为有限 Context Window 策划最有用的 Token 集合。这比“写好一段 Prompt”更接近生产 Agent 的真实问题。

信息已经存在，不代表它应该进入当前请求。把完整会话、所有工具和全部企业文档都塞入模型，会同时扩大延迟、成本、注意力竞争、Prompt Injection 面和数据泄露面。反过来，过度裁剪会让模型缺少完成条件、事实或失败历史。目标不是 Token 最少，而是在目标质量和风险约束下，边际效用最高。

建立上下文来源清单

架构师首先需要一张来源登记表，而不是一个巨大的字符串模板。每个来源至少记录 Owner、作用域、权威等级、时效、敏感级别、估算成本、注入风险和失效策略。这样才能在故障时回答：“答案引用的规则来自哪里，当时版本是什么？”

稳定指令

系统政策、Agent 身份、输出契约和 Tool Contract 通常跨步骤稳定，但“稳定”不等于永久复制。它们应被版本化，并区分必须每次显式出现的安全不变量与可以按需发现的工具说明。工具太多时，先按能力元数据检索候选，再向模型暴露最小集合。

会话与运行状态

消息历史回答“用户和系统说过什么”，Run 状态回答“系统已经做了什么、下一步等待什么”。二者不能互相替代：把模型曾说“订单已取消”的消息当成业务状态，会制造假完成；只保留结构化状态而删除用户纠正，又会丢失决策原因。

检索和记忆

企业知识是带来源版本的组织事实候选；Memory 是从历史交互提炼的偏好或经验候选。它们进入 Context 前都需要当前身份过滤与新鲜度判断。Memory 不应凌驾于实时业务数据，RAG 片段也不能仅凭向量相似度获得“可信”身份。

外部观察

Tool 返回、网页、文件和其他 Agent 输出是环境数据，不自动具有指令权。最安全的处理是使用结构化信封携带 source、observedAt、trust、content，并在系统指令中明确外部内容不得改变权限或目标。

组装是一条有策略的流水线

把 Context Builder 设计成可测试的纯函数边界：输入是任务、身份、Run 快照和候选来源；输出是模型消息、来源清单、预算报告和丢弃原因。模型 Provider 的消息格式只应出现在最后的 Adapter 中。

// 简化但可执行的 TypeScript：先做授权，再做效用选择
type Candidate = {
  id: string; text: string; tokens: number
  scope: { tenantId: string; userId?: string }
  authority: 0 | 1 | 2 | 3; freshness: number; relevance: number
  mandatory?: boolean
}

export function selectContext(
  candidates: Candidate[],
  request: { tenantId: string; userId: string; budget: number }
) {
  const visible = candidates.filter(item =>
    item.scope.tenantId === request.tenantId &&
    (!item.scope.userId || item.scope.userId === request.userId)
  )
  const ranked = visible.sort((a, b) =>
    Number(b.mandatory) - Number(a.mandatory) ||
    (b.authority * .4 + b.freshness * .25 + b.relevance * .35) -
    (a.authority * .4 + a.freshness * .25 + a.relevance * .35)
  )
  const selected: Candidate[] = []
  let used = 0
  for (const item of ranked) {
    if (used + item.tokens > request.budget && !item.mandatory) continue
    if (used + item.tokens > request.budget) throw new Error('mandatory context exceeds budget')
    selected.push(item); used += item.tokens
  }
  return { selected, used, dropped: visible.length - selected.length }
}

生产实现还需要语义去重、冲突分组、引用映射和序列化，但顺序不能颠倒：先鉴权、后召回；先去重、后压缩；最后才序列化。否则不可见内容即使最终没返回，也可能进入 Reranker、摘要模型或 Trace。

预算不只看总 Token

总窗口应拆成输入、推理、输出和 Tool 往返的预算。输入内部再按不可丢失的约束、当前任务状态、证据和补充上下文分配软硬额度。硬额度用于安全政策、输出 Schema、当前对象 ID 等不变量；软额度允许检索证据根据边际收益竞争。

位置同样是架构变量。Lost in the Middle 的研究表明，相关信息位于长输入中间时性能可能下降。工程上不能把它简化成“重要信息永远放开头”：消息角色、模型家族和任务不同。更可靠的做法是把关键约束靠近决策点、删除重复噪声，并对同一内容做位置扰动实验。

压缩必须显式管理信息损失

裁剪、抽取、摘要、结构化归并和 Artifact 引用具有不同损失函数。日志可以抽取异常窗口，重复 Tool 输出可以归并，长文档可以保留标题路径并引用原文；但金额、日期、身份、否定条件、未完成动作和批准记录不能让模型自由改写。

建立压缩账本。每个派生摘要保存原始对象 ID、源版本、压缩策略、生成模型/规则版本、创建时间和受保护字段校验值。摘要多次滚动会累积漂移，因此到达轮次、时间或冲突阈值后，必须回到原始记录重建，而不是继续摘要摘要。

优先引用 Artifact，而不是复制大对象。代码、报表、图片和完整 Tool 结果保存在受控 Artifact Store 中，Context 只放摘要、定位符和按需读取工具。这减少 Token，并让原始证据保持可审计。前提是模型能可靠发现和读取 Artifact；否则“指针化”会变成隐形信息缺失。

Context 污染与冲突处理

污染不是只有恶意 Prompt Injection。陈旧状态、错误 Memory、跨任务残留、重复证据和互相矛盾的政策都会改变模型行为；外部检索内容还可能携带 间接 Prompt Injection。冲突处理应在组装层显式完成：先按权限淘汰不可见来源，再按业务权威、版本和时间排序；无法决定时把冲突本身交给用户或人工，而不是让模型挑一个“更像真的”。

用消融和扰动验证上下文价值

只观察最终正确率无法判断 Context 是否有效。记录每个候选的入选原因、Token、来源版本和模型引用情况，然后对固定任务集执行四类实验：移除某个来源看质量是否下降；替换为陈旧版本看系统能否识别；改变位置看性能方差；加入高相似干扰项看模型是否被污染。

评测至少同时看任务成功、事实/引用正确、延迟、输入 Token、失败方差和越权率。某类 Context 平均提升很小但显著降低严重错误，仍可能值得保留；相反，平均质量提升却引入跨租户泄露，不可接受。