Context Engineering：Agent 真正的核心竞争力

别再只研究 Prompt 了，决定 AI Agent 能否完成复杂任务的，可能是它看到了什么、记住了什么，以及忽略了什么。

一、同一个模型，为什么不同 Agent 的表现差距如此大？

假设我们使用同一个大语言模型，开发两个 AI 编程助手。

第一个 Agent 接到任务：

“修复订单服务中的支付超时问题。”

它首先读取整个代码仓库，将几十个文件、历史对话、执行日志和各种工具说明一股脑塞进上下文窗口。

然后，它开始分析代码。

结果却并不理想。

它可能忽略了项目中的关键约束，重复修改已经验证过的代码，甚至忘记用户一开始要求不能修改数据库结构。

第二个 Agent 使用完全相同的模型，但执行方式不同。

它首先读取项目目录和架构说明，定位订单服务，搜索支付超时相关代码，再根据实际需要加载具体文件。

执行过程中，它只保留当前任务目标、关键约束、已经验证的结论，以及下一步行动计划。

当上下文逐渐变长时，它会压缩冗余日志，把已经确认的决策保存到结构化任务记录中。

最终，第二个 Agent 可能更快、更稳定地完成任务。

两个 Agent 的模型相同，差别在于它们如何组织和使用上下文。

这正是 Context Engineering 要解决的问题。

过去，我们习惯通过修改 Prompt 让模型表现得更好。

但当 Agent 开始执行长任务、调用工具、访问文件系统和使用外部知识时，单纯优化提示词已经不够了。

我们需要管理整个模型推理过程中的信息环境。

二、什么是 Context Engineering？

2025 年 9 月，Anthropic 发表了《Effective context engineering for AI agents》，系统性讨论了上下文工程。

它提出的一个重要思想是：

Context Engineering 不只是把 Prompt 写得更好，而是为模型的每一次推理，组织最有价值的上下文信息。

我们可以这样理解：

Prompt Engineering 解决的是：如何表达指令。

Context Engineering 解决的是：模型在做决定时，应该掌握哪些信息。

一个 Agent 的上下文可能包含：

• System Prompt：系统级规则和行为约束。

• User Input：用户当前的任务与要求。

• Conversation History：历史对话。

• Tools：工具定义和调用结果。

• Memory：长期记忆与历史经验。

• RAG：从外部知识库检索的信息。

• Task State：任务进度、计划和中间状态。

• Environment：代码仓库、文件、浏览器状态和运行环境。

这些信息并不是始终全部放在模型上下文中。

真正的工程挑战，是在每一次模型调用前，决定哪些内容应该进入上下文、哪些需要更新、哪些可以删除，以及哪些应该暂时保存在外部。

可以将这一过程抽象为：

                 用户任务
                    │
                    ▼
             Context Manager
                    │
       ┌────────────┼────────────┐
       │            │            │
       ▼            ▼            ▼
   Instructions   Memory       Retrieval
       │            │            │
       └────────────┼────────────┘
                    │
                    ▼
             Context Builder
                    │
           ┌────────┴────────┐
           │  Select         │
           │  Rank           │
           │  Compress       │
           │  Validate       │
           │  Budget         │
           └────────┬────────┘
                    │
                    ▼
                   LLM
                    │
                    ▼
              Tool Execution
                    │
                    ▼
               New Evidence
                    │
                    └──────► 下一轮上下文

这里的核心不再是一次性构造一个巨大的 Prompt，而是建立动态的上下文管理机制。

Context Engineering 本质上是一种信息调度系统。

三、上下文窗口越大，Agent 就越聪明吗？

过去几年，大语言模型的上下文窗口不断增长。

从数千 Token 到数万、数十万，部分模型甚至支持百万级上下文。

这很容易让开发者产生一种错觉：

既然上下文窗口足够大，为什么不把所有信息都放进去？

但大上下文窗口并不意味着模型能够同等可靠地使用其中的每一个信息片段。

Anthropic 在 Context Engineering 文章中讨论了 Context Rot，也就是随着上下文增长，模型对其中信息的利用能力可能下降的现象。

这个现象在长任务中尤其值得警惕。

1. 信息越多，噪声可能越多

假设 Agent 需要修复一个 Python 函数。

实际相关的内容可能只有：

• 当前函数代码。

• 对应测试。

• 上游调用关系。

• 项目编码规范。

如果同时加载整个仓库的几千个文件，模型可能需要在大量无关信息中识别关键线索。

结果不仅增加 Token 成本，还可能分散注意力。

2. 不同阶段需要不同的信息

Agent 开始执行任务时，需要理解目标和环境。

修改代码时，需要相关文件与依赖关系。

执行测试失败后，需要错误日志与当前修改。

生成最终报告时，需要修改摘要和验证结果。

这些阶段所需的上下文并不相同。

因此，上下文不能只在任务开始时构建一次。

3. 历史信息可能变成错误信息

假设 Agent 最初认为支付超时是数据库连接导致的。

随后，实际测试表明问题来自 HTTP 连接池配置。

如果旧假设始终占据上下文，却没有被标记为已经否定，模型可能继续沿着错误方向推理。

这属于上下文中的信息冲突。

好的 Context Engineering 不仅要保存信息，还要管理信息的可信度、时效性和状态。

上下文窗口是容量限制，而不是必须填满的目标。

对于 Agent，我们真正需要优化的是有效信息密度。

可以用一个概念性指标表达：

有效上下文密度 = 对当前决策有帮助的信息量 / 上下文总量

这不是业界统一的正式评测指标，但很适合指导工程设计。

四、Context Engineering 的五大核心技术

1. Context Selection：只选择当前真正需要的信息

选择信息，是上下文工程的第一步。

例如，对于一个 Coding Agent：

用户要求修复支付超时问题。

不应该立刻读取整个项目，而应该先定位。

用户任务
   │
   ▼
识别任务涉及的模块
   │
   ▼
检索相关文件
   │
   ▼
识别关键依赖
   │
   ▼
按需读取源码
   │
   ▼
构建当前上下文

这体现了一种重要思想：

Just-in-Time Context，按需获取上下文。

Anthropic 的工程实践也强调，不必在任务开始时预加载所有信息。

Agent 可以先掌握文件路径、资源标识或搜索结果，在真正需要时再通过工具读取内容。

这同时引出了 Progressive Disclosure，即渐进式信息披露。

第一层只提供概要。

第二层提供相关文件。

第三层再提供具体函数、日志和历史记录。

一个好的 Agent，不是预先知道所有信息，而是知道如何逐步找到需要的信息。

2. Context Compression：压缩冗余，而不是简单截断

长任务 Agent 最大的问题之一，就是上下文会不断增长。

例如：

第1轮：理解任务
第2轮：读取文件
第3轮：执行搜索
第4轮：修改代码
第5轮：运行测试
第6轮：测试失败
第7轮：继续修复
...
第50轮：上下文接近上限

最简单的解决方法是删除最早的历史消息。

但这样容易丢掉重要信息。

比如用户最初提出的限制、之前失败的尝试，以及已经确认的架构决策。

因此，更合理的方案是 Compaction。

Compaction 不是简单删除，而是把历史上下文转换成更紧凑、仍然能够支持后续任务的信息表示。

例如：

原始上下文：

用户要求修复支付超时
读取订单模块
读取支付模块
检查数据库
运行测试失败
重新检查数据库
发现数据库正常
检查HTTP连接池
发现连接池耗尽
修改连接池参数
运行部分测试通过

压缩后的上下文：

任务：修复支付超时

已确认：
- 数据库连接正常
- 根因与HTTP连接池耗尽有关

已完成：
- 调整连接池配置
- 部分测试通过

待完成：
- 运行完整回归测试
- 验证高并发场景

限制：
- 不修改数据库结构

压缩后的信息更容易用于下一步决策。

不过，Compaction 也有风险。

如果过度压缩，可能丢失只有在后续任务中才显现价值的细节。

因此，关键决策、用户约束、外部副作用和未解决问题，通常需要优先保留。

OpenAI 的 Codex 技术文档与 Anthropic 的 Claude Code 实践，都介绍了长任务上下文压缩相关机制。

但这些机制的具体实现并不完全相同，也不意味着所有长任务都能无损恢复。

3. Memory：让 Agent 跨越上下文窗口

Context 和 Memory 经常被混为一谈。

但它们不是同一个概念。

Context 是模型本次推理直接看到的信息。

Memory 是可以在上下文之外持久化保存，并在需要时重新取出的信息。

举个例子。

用户告诉 Agent：

“这个项目统一使用 PostgreSQL，不要引入 MongoDB。”

这个约束应该如何处理？

在当前任务中，它属于上下文。

如果这个约束在未来多个任务中都有效，就可以存入项目长期记忆。

当 Agent 下次设计数据库功能时，再根据项目标识检索这条记忆并注入上下文。

这里有几个关键动作：

产生信息
   ↓
判断是否值得记住
   ↓
结构化存储
   ↓
索引与版本管理
   ↓
未来任务检索
   ↓
验证有效性
   ↓
注入当前上下文

Memory 的难点并不是保存数据。

真正困难的是：

• 哪些信息值得长期保存？

• 旧信息什么时候应该失效？

• 不同来源发生冲突时怎么办？

• 错误记忆如何纠正？

• 如何确保不同用户之间的数据隔离？

如果 Agent 只会记住，却不会更新和遗忘，长期记忆反而可能成为新的错误来源。

4. RAG：上下文工程的信息获取能力

RAG 是 Retrieval-Augmented Generation，即检索增强生成。

它主要解决模型如何获得外部知识的问题。

例如，企业 Agent 需要回答：

“公司最新的差旅报销标准是什么？”

系统可以从企业知识库检索相关政策，再将结果提供给模型。

但传统 RAG 经常采用一次检索、一次生成的方式。

对于复杂任务，Agent 往往需要多轮检索。

例如：

检索差旅政策
    ↓
发现政策存在2025版和2026版
    ↓
确认生效时间
    ↓
检索员工所在地区
    ↓
确定适用规则
    ↓
生成带来源的回答

这里 RAG 已经不只是一个搜索组件，而是 Agent 动态获取上下文的组成部分。

需要特别强调：

检索到的信息不一定真实、最新或适用于当前用户。

Context Engineering 必须考虑来源、时间、权限、版本以及内容可信度。

5. Context Isolation：把复杂任务拆成独立上下文

有些任务非常复杂，即使不断压缩上下文，也很难让一个 Agent 处理所有细节。

例如：

“分析过去24小时全球AI行业的重要变化，输出一份技术研究报告。”

这个任务包含：

• 搜索新闻

• 阅读官方公告

• 提取事实

• 判断重要性

• 比较历史变化

• 撰写报告

• 核实引用

如果所有操作都由同一个 Agent 完成，搜索过程产生的大量网页内容可能占据上下文。

一种解决方式是使用 Sub-Agent。

                Main Agent
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
  Research Agent  Analysis Agent  Review Agent
       │            │            │
  独立搜索上下文   独立分析上下文   独立核查上下文
       │            │            │
       └────────────┼────────────┘
                    ▼
               精简结果
                    │
                    ▼
                 Main Agent
                    │
                    ▼
                 最终报告

每个 Sub-Agent 只处理局部任务，并向主 Agent 返回结构化结论。

这种设计的优势不仅是并行执行。

更重要的是上下文隔离。

一个子任务产生的大量中间日志，不必全部进入主 Agent 的上下文。

但是，多 Agent 并不总是更优。

它会增加模型调用次数、状态协调和错误传播成本。

只有在任务确实能够有效拆分、隔离上下文能带来收益时，这种架构才值得引入。

五、Codex 和 Claude Code 如何实践 Context Engineering？

1. Codex：给 Agent 一张地图，而不是一本百科全书

OpenAI 在2026年2月发表的《Harness engineering: leveraging Codex in an agent-first world》中，分享了非常有代表性的工程经验。

团队最初尝试将大量开发规则写进一个巨大的 AGENTS.md。

这种方法没有达到预期效果。

原因在于：大量规则占用了上下文空间，同时降低了真正重要的信息的可见性。

后来，团队转向更清晰的知识组织方式。

让 Agent 首先获得项目地图，再根据任务访问相关文档、架构规范和代码。

这体现了一个重要的设计原则：

不要把所有知识直接复制到 Agent 的上下文里，而要让知识变得容易发现和按需读取。

例如，一个项目可以采用：

project/
├── AGENTS.md
├── docs/
│   ├── architecture.md
│   ├── database.md
│   ├── api-design.md
│   └── testing.md
├── services/
│   ├── order/
│   └── payment/
└── tests/

AGENTS.md 只保存简短、关键的入口信息。

当 Agent 修改数据库时，再读取数据库规范。

当 Agent 修改 API 时，再读取 API 设计规范。

相比一次性把所有规则塞进系统提示词，这种结构更容易维护和扩展。

OpenAI 在2026年8月进一步公开 Codex Harness 的平台化设计，并介绍了推理状态保留与上下文压缩对特定评测结果的显著影响。

这也说明 Context Engineering 并不是单纯的提示词技巧，而是运行时系统的重要组成部分。

2. Claude Code：压缩、笔记和子任务隔离

Anthropic 在《Effective context engineering for AI agents》中介绍了 Claude Code 的上下文管理思路。

其中几个策略非常值得借鉴。

Compaction： 将长历史中的关键决策、未解决问题和实现细节保留下来，清除冗余工具输出。

Structured Note-taking： 把任务计划和进度保存在上下文窗口之外，需要时重新读取。

Sub-Agent： 让不同子任务拥有独立上下文，仅返回完成主任务所需的结果。

这些策略分别解决不同问题：

技术	解决的问题
Compaction	当前对话太长
Structured Memory	重要信息需要跨轮次保存
Just-in-Time Retrieval	外部知识太多
Sub-Agent	一个任务包含太多不同细节
Context Selection	当前信息噪声过大

因此，Context Engineering 没有一种万能方法。

合理的系统往往需要组合使用这些技术。

六、如何自己实现一个 Context Manager？

如果我们从零开发 Agent，不建议一开始就引入复杂的多Agent系统。

可以先实现一个简单的 Context Manager。

它的目标只有三个：

1. 给不同信息分配优先级。

2. 在预算内选择高价值信息。

3. 确保关键约束不会被普通历史记录挤掉。

下面给出一个只依赖 Python 标准库的简化示例。

from dataclasses import dataclass
from typing import List


@dataclass
class ContextItem:
    name: str
    content: str
    priority: int
    tokens: int
    required: bool = False


class ContextManager:
    def __init__(self, token_budget: int):
        self.token_budget = token_budget
        self.items: List[ContextItem] = []

    def add(self, item: ContextItem):
        self.items.append(item)

    def build(self):
        selected = []
        used = 0

        # 先确保关键约束有空间
        required_items = [
            item for item in self.items
            if item.required
        ]

        if sum(i.tokens for i in required_items) > self.token_budget:
            raise ValueError(
                "Required context exceeds token budget"
            )

        for item in required_items:
            selected.append(item)
            used += item.tokens

        # 普通信息按优先级选择
        optional_items = sorted(
            (i for i in self.items if not i.required),
            key=lambda x: x.priority,
            reverse=True
        )

        for item in optional_items:
            if used + item.tokens <= self.token_budget:
                selected.append(item)
                used += item.tokens

        return {
            "items": selected,
            "used_tokens": used,
            "remaining_tokens": self.token_budget - used
        }


manager = ContextManager(token_budget=1200)

manager.add(ContextItem(
    name="user_constraint",
    content="不能修改数据库结构",
    priority=100,
    tokens=50,
    required=True
))

manager.add(ContextItem(
    name="task",
    content="修复订单服务支付超时问题",
    priority=100,
    tokens=80,
    required=True
))

manager.add(ContextItem(
    name="relevant_code",
    content="支付服务相关代码",
    priority=90,
    tokens=500
))

manager.add(ContextItem(
    name="test_failure",
    content="HTTP连接池耗尽错误日志",
    priority=95,
    tokens=300
))

manager.add(ContextItem(
    name="old_logs",
    content="历史调试日志",
    priority=20,
    tokens=900
))

result = manager.build()

print([item.name for item in result["items"]])
print(result["used_tokens"])

预期输出：

['user_constraint', 'task', 'test_failure', 'relevant_code']
930

这个示例只实现了最基础的优先级选择，不是真正完整的 Agent Context Manager。

其中 Token 数量是预设值，实际项目需要使用对应模型的 Token 计数工具。

同时，这种贪心选择策略也没有处理语义去重、信息依赖、来源验证和缓存优化。

但它体现了一个重要设计：

上下文不能简单按照时间顺序追加，而应该根据当前任务的重要性进行组织。

生产级 Context Manager 还需要什么？

真正投入生产时，我建议至少增加以下能力。

Token Budget： 为系统规则、当前任务、检索结果和工具输出分别预留预算。

Relevance Ranking： 根据当前任务的相关程度排序。

Deduplication： 删除重复内容，避免反复注入相同信息。

Compaction： 对长期历史和大型工具输出进行压缩。

Memory Retrieval： 按任务检索长期记忆。

Source Tracking： 保存信息来源和更新时间。

Conflict Detection： 识别互相矛盾的历史结论。

Permission Filtering： 防止检索出当前用户无权访问的内容。

Evaluation： 评估压缩或筛选后是否损失关键事实。

这里的一个重要安全原则是：

来自网页、文档和工具返回内容的指令，不应因为被注入上下文，就自动拥有系统级权限。

信息可以用于推理，但不能自动提升为授权。

七、Context Engineering 应该如何评测？

如果我们改变了上下文组织方式，如何证明新版本真的更好？

不能只看 Token 是否减少。

一个简单的压缩策略可能减少了50%的上下文，却恰好删除了关键约束，导致任务失败。

因此，需要同时关注效果与成本。

我建议至少设计六个指标。

指标	关注点
Task Success Rate	最终任务是否完成
Context Recall	关键事实和约束是否保留
Context Precision	注入的信息中有多少真正有用
Token Efficiency	单位任务成功所需Token
Recovery Rate	长任务压缩后能否继续
Constraint Violation Rate	是否违反用户或系统约束

例如，针对 Coding Agent，可以设计一组任务：

• 修复需要阅读多个文件的Bug。

• 执行超过50轮工具调用的任务。

• 在历史对话中保留禁止修改的文件。

• 中途推翻错误假设。

• 压缩上下文后继续执行。

• 从已有任务状态恢复。

然后比较三种方案：

A：完整保留历史，直到窗口不足。

B：简单截断较早历史。

C：基于任务状态、结构化记忆和关键事实的Compaction。

通过相同模型、相同任务、相同工具权限和尽量一致的评测条件，比较任务成功率、成本和约束遵守情况。

这比单纯比较上下文长度更有价值。

需要注意，模型推理具有一定随机性，最好对同一任务进行多次运行，避免从个别结果得出过度结论。

八、未来 Agent 的竞争，会转向 Context Engineering 吗？

我的判断是：Context Engineering 会成为越来越重要的差异化能力，但它不会单独取代模型能力、工具能力和 Harness Engineering。

原因很简单。

当多个产品都能够调用高能力模型时，产品之间的差距越来越可能来自它们的工作环境。

例如：

一个编程 Agent，是否能准确找到相关文件？

一个研究 Agent，是否能区分真实来源和过期新闻？

一个数据分析 Agent，是否能保留关键的业务指标定义？

一个企业 Agent，是否能根据用户权限检索正确的数据？

一个长期运行的 Agent，是否能在几百次工具调用后仍然记住最初的目标？

这些都属于上下文工程的问题。

而且不同领域需要不同的上下文策略。

Coding Agent 需要代码结构、依赖关系和测试状态。

Research Agent 需要来源、证据、时间与结论。

Data Agent 需要数据Schema、指标定义、查询结果和计算过程。

Business Agent 需要业务规则、用户权限、审批状态和操作历史。

因此，真正高质量的 Agent 产品，需要围绕领域任务建立自己的上下文组织机制。

通用的 Context Manager 可以提供基础能力，但难以代替领域化的信息选择规则。

九、从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering

回顾 Agent 工程的发展，可以看到三个彼此关联的设计层次。

Prompt Engineering

重点是表达。

让模型清楚理解我们希望它做什么，以及应该如何输出。

Context Engineering

重点是信息。

让模型在每一次推理中拿到正确、相关、及时且可信的信息。

Harness Engineering

重点是执行。

让模型能够在工具、状态、权限和验证机制的支持下，可靠地完成任务。

它们之间并不是简单的替代关系。

更合理的理解是：

       ┌─────────────────────┐
       │ Harness Engineering │
       │                     │
       │  ┌───────────────┐  │
       │  │    Context    │  │
       │  │  Engineering  │  │
       │  │               │  │
       │  │ Prompt Design │  │
       │  └───────────────┘  │
       │                     │
       │ Tools / State /     │
       │ Sandbox / Evals     │
       └─────────────────────┘

Prompt 是上下文的一部分。

Context Engineering 是 Harness 中的重要能力。

Harness 则负责把模型的推理结果转化为有边界、可验证的行动。

三者相互依赖。

一个拥有优秀 Harness、但上下文组织混乱的 Agent，仍然可能反复犯错。

一个上下文组织优秀、却没有安全执行机制的 Agent，也很难投入生产。

因此，不应该把三者看成相互竞争的流行术语。

它们共同构成现代 Agent 工程体系。

十、给 Agent 开发者的五条建议

如果今天重新设计一个 Agent，我会把下面五件事情列为优先事项。

第一，不要默认把所有信息塞给模型

优先采用按需检索、渐进式读取和结构化上下文。

第二，区分事实、假设和已失效的信息

特别是在复杂任务中，不要让已经被否定的推理结论继续作为当前事实。

第三，为关键约束保留明确位置

用户禁止事项、权限范围、任务目标和验收标准，不应被普通日志挤出上下文。

第四，尽早建立 Compaction 和 Memory 机制

当任务开始跨越几十轮执行时，再临时补充上下文管理往往会增加架构成本。

第五，把上下文质量纳入 Agent Evals

不要只问模型有没有完成任务，还要知道它是否使用了正确的信息，以及是否因为遗漏关键上下文而失败。

结语：最好的 Agent，不是知道最多，而是知道此刻什么最重要

过去，我们曾经认为，让 AI 变得更强大的核心是更大的模型、更多参数和更长的上下文窗口。

这些能力当然重要。

但当 AI Agent 开始承担真实的软件开发、企业运营、数据分析和研究任务时，我们逐渐发现：

拥有信息，不等于能够有效使用信息。

一个 Agent 可能读取了整个代码仓库，却依然找不到真正的Bug。

它可能拥有上百轮历史记录，却忘记最重要的用户约束。

它可能检索了大量网页，却无法区分最新事实和过时内容。

这些问题，并不能只通过增加上下文窗口来解决。

我们需要设计信息的生命周期。

让 Agent 知道什么时候检索、什么时候记忆、什么时候压缩、什么时候验证，以及什么时候丢弃已经不再有价值的内容。

如果上一篇 Harness Engineering 讨论的是如何为 Agent 构建可靠的执行系统，那么 Context Engineering 讨论的就是：

如何让 Agent 在每一次行动之前，拥有足够正确的信息。

未来优秀的 Agent，不一定是能一次性读取最多信息的 Agent。

而是能够在正确的时间，找到正确的信息，并据此做出正确行动的 Agent。

模型决定 Agent 能思考什么，Context 决定 Agent 根据什么思考，Harness 决定 Agent 如何将思考转化为行动。

这也许就是 AI Agent 从 Demo 走向生产级系统，最值得关注的工程方向之一。