从 Prompt Engineering 到 Context Engineering：AI 工程师的第二次范式升级

说一个让我自己有点尴尬的事。2023 年那会儿，我在公司内部做过一场分享，题目叫《Prompt Engineering 十二招》，里面讲的全是些”你是一个资深 XX””请一步一步思考””输出格式如下”这种现在看起来挺初级的东西。当时还挺受欢迎，后来这套 slides 还被隔壁部门借去讲过两次。

到了 2025 年下半年做 Agent 项目的时候，我突然发现那套思路彻底不够用了——我可以把单次请求的 prompt 调到完美，但 Agent 跑几十轮之后照样翻车；我可以给模型写一个漂亮的 system prompt，但真正决定它表现的是每一步我塞给它的上下文。

这时候我才反应过来：过去两年大家琢磨的 “Prompt Engineering”，其实只是 “Context Engineering” 的一个子集，而且是最小的那一块。

这篇我把自己这一年半从 Prompt 调教转向 Context 工程的思路转变讲清楚，以及我现在实际在用的四个支柱：Writing、Selection、Compression、Isolation。

一、Prompt Engineering 的天花板在哪

先回到起点。Prompt Engineering 解决的问题是：同样的模型、同样的输入数据，换个问法就能让输出质量差一倍。这个观察本身没错，现在也依然成立。

但它有两个死穴：

第一个死穴：单轮视角。
Prompt Engineering 的训练场是 ChatGPT 这种对话框——我说一句，它回一句，我觉得不好，我改 prompt，再问一句。这套方法在信息已经齐全的场景下非常有效。但一旦进入 Agent、进入多轮、进入工具调用，你会发现模型表现好不好，已经不是”这句话怎么说”决定的了，而是”前面那 30 轮对话里它看到了什么“决定的。

第二个死穴：把模型当成一个黑箱说服对象。
Prompt Engineering 的潜台词是”我得用某种魔法咒语哄着模型好好干活”。但模型本质上是一个函数 f(context) -> output，它产出什么完全取决于你输入给它的 context。与其琢磨怎么把一句话说得更花，不如琢磨怎么把整个 context 组织得更好。

我自己的顿悟时刻是一次 debug——Agent 在第 25 轮突然开始胡说八道，我一开始以为是模型幻觉，仔细看日志才发现，它的 context 里已经有 180K token 了，其中 90% 是无关的旧工具调用结果，真正有用的信息被淹没在噪声里。这不是 prompt 的问题，这是 context 管理的问题。

还有一个更微妙的问题：Prompt Engineering 时代大家比的是”谁的 prompt 更巧”，结果是大家都在卷单 prompt 的极限，忽略了整个流水线的设计。真正生产级的 AI 系统，瓶颈不在于某个 prompt 能不能挤出最后 5% 的性能，而在于 context 流转的每一个环节是否稳定。这是两种完全不同的工程思维。

二、Context Engineering 的四个支柱

我现在脑子里的框架是这么四块。这不是我发明的，Anthropic 和一些国外团队的分享里反复出现过这个分类，但我想用自己的项目例子讲一遍。

支柱一：Writing（怎么写上下文）

这块是传统 Prompt Engineering 的地盘，但有几个新的工程化视角。

Context 要分层：system 层写不变的（角色、规则），tool 层写能力，user 层写本轮输入。不要把所有东西都堆在 system prompt 里——那样 Prompt Caching 都没法用。

Context 要版本化：我现在项目里的 prompt 模板都是 git 管理，每次改都要写 commit message。这听起来像废话，但你不版本化，你就没法 A/B test，就没法回滚。

Context 要分离配置和逻辑：模型叫什么名字、temperature 多少，这些是配置；”拿到用户问题后先做意图识别”这些是逻辑。两者混在一起写你会哭。

Context 要有 schema 意识：与其用自然语言让模型”输出 JSON”，不如直接定义 tool schema 或用 structured output 强约束。自然语言指令越精确，说明你越没把工程学做好。

我 Claude Code 项目里的 CLAUDE.md 就是这么组织的，具体写法我在《CLAUDE.md 写法大全》里讲。

支柱二：Selection（选什么进上下文）

这是最关键、也最被低估的一块。

思路很朴素：模型的上下文窗口是有限的，你得选最有用的信息塞进去，而不是一股脑全扔。听起来像废话，但 90% 的 Agent 项目都没做好这件事。

我现在的业务 Agent 里，Selection 层长这样：

def build_context(user_query, history, tools_available):
    # 1. 基于语义相似度从历史中召回相关轮次
    relevant_history = semantic_search(
        query=user_query, 
        corpus=history, 
        top_k=5
    )
    
    # 2. 基于意图识别选要暴露的工具（而不是全部塞进去）
    intent = classify_intent(user_query)
    tools = filter_tools_by_intent(tools_available, intent)
    
    # 3. RAG 召回相关文档
    docs = rag_retrieve(user_query, top_k=3)
    
    return {
        "history": relevant_history,
        "tools": tools,
        "docs": docs
    }

几个反直觉的经验：

工具不是越多越好。我一开始给 Agent 塞了 40 多个 tool，发现它选错的概率很高。后来做了按意图筛选，每次只暴露 5-8 个最相关的，准确率反而上升
历史不是越全越好。全量历史往里塞，模型会被早期无关的信息带偏。最近 N 轮 + 语义相关召回 K 轮，效果最好
RAG 返回的 chunk 要排序。不是按 similarity score 排，是按 “模型最容易注意到” 的顺序排——最重要的放最前或最后，中间段落会被忽视（Lost in the Middle 效应）
召回质量 > 召回数量。很多团队一上来就把 top_k 调到 20，结果噪声一堆，精度反而变差。我现在标配是 top_k=3~5，加一个 rerank 层

还有一个务实的点——Selection 需要可观测性。你得能 log 出”这一次 context 由哪些片段组成”，出问题时才有排查线索。我在项目里搞了一个 context tracer，每次构建 context 都记录下来，debug 效率提升一倍不止。

支柱三：Compression（怎么压缩）

当 Selection 做完，你可能还是有 80K 的 context 要处理。这时候需要 Compression。

我常用的三种压缩手段：

1. Summarization Cascade。
每 10 轮对话，用 Haiku 把前面的对话总结成 500 字以内的摘要，替换掉原文。这招在长对话场景里能把 context 压缩 90% 以上，信息损失在可接受范围。Haiku 做这种总结任务完全够用，不需要动 Sonnet。

2. Structured Representation。
把工具调用结果从”自然语言的一大段描述”换成结构化 JSON。同样的信息，JSON 比自然语言省 50-70% 的 token。更极端的做法是把长结果 “卸载” 到外部存储，context 里只保留一个引用 ID，下次需要再读——这是 Claude 最近出的 memory tool 的核心思路。

3. Prompt Caching。
这个严格来说不是压缩，是计费层面的压缩——固定的 context 部分命中 cache 之后，input token 成本降到 10%，等效于节省了 90% 的输入预算。Anthropic 家 cache TTL 是 5 分钟，高频 Agent 场景非常吃香。

4. 选择性遗忘。
不是所有历史都值得保留，有些中间态（比如失败的工具调用、无效的查询尝试）对后续决策毫无帮助，可以直接从 context 里删掉。我的一个 Agent 加了这个清理逻辑之后，context 平均长度降了 40%，稳定性还提升了。

支柱四：Isolation（怎么隔离上下文）

这块是我最近才开始重视的，也是 multi-agent 架构的核心。

朴素的做法是一个 Agent 一路跑到底，所有信息都在同一个 context 里。问题是：context 会越积越脏，不同子任务的中间产物会互相干扰。

Isolation 的思路是：不同职责拆成不同 sub-agent，每个 sub-agent 有自己独立的 context，主 Agent 只拿子 Agent 的最终结论，不碰它的过程。

比如我一个 research Agent 的架构：

主 Agent（规划 + 汇总）
   │
   ├── 搜索 sub-agent（专注搜索，自己的 context 里全是搜索结果）
   ├── 阅读 sub-agent（专注读长文，自己的 context 里是文档原文）
   └── 写作 sub-agent（专注组织输出，只看主 Agent 给的 brief）

每个 sub-agent 跑完之后，主 Agent 只把精炼后的结果拉回来。这样主 Agent 的 context 始终保持干净，几十轮跑下来都不会爆。

坏处是成本会增加（多次 API 调用），好处是稳定性和可观测性大幅提升——某个 sub-agent 翻车，你只调它自己的 prompt 就行，不会影响全局。

另一个隐藏收益是可以为不同 sub-agent 选不同模型。主 Agent 需要规划能力，用 Sonnet；搜索 sub-agent 做的是结构化任务，用 Haiku；写作 sub-agent 偶尔上 Opus 做深度生成。这种混合部署比单模型跑到底要划算得多。

三、这四个支柱怎么搭在一起

实际项目里这四块不是孤立的，是一个循环：

Writing（写基础 context）
   ↓
Selection（每轮动态挑）
   ↓  
Compression（太长了就压）
   ↓
Isolation（复杂任务分出去）
   ↓
新的输出又成为下一轮的 context → 回到 Selection

我的经验是：项目早期重点投 Writing 和 Selection，中后期重点投 Compression 和 Isolation。早期你 context 不会太大，关键是搭好基础结构；跑到后面规模上来了，压缩和隔离才成为瓶颈。

另一个维度的建议：投入顺序应该匹配业务规模。日活几百的 Agent 应用，Compression 和 Prompt Caching 能省下来的钱可能还不够你写这块代码的工时。日活过万之后，这些优化的 ROI 才开始体现。

四、一个常被忽视的点：Context 的”时效性”

上面讲的四个支柱都是空间维度的——怎么组织信息。但还有一个时间维度：**context 里的信息有”新鲜度”**。

举个例子：Agent 在 10 轮之前查过某用户的订单状态，当时是”已发货”。现在第 20 轮又需要这个信息，是直接从 context 里读？还是重新查？

不同场景答案不同：

用户基础信息（姓名、手机号）—— 缓存住，别重复查
订单状态、库存、价格 —— 最多用 5 分钟之前的缓存，再久就得重查
实时流数据（股价、监控指标）—— 每次都要重查

这种时效性管理不在 prompt 层，而是在你的工具调用和状态管理层。Context Engineering 不是纯 prompt 工程，它是系统工程。

五、工具和生态

这套思路背后其实已经有不少成熟工具了：

LangGraph / AutoGen 这类框架核心就是帮你做 Isolation
LlamaIndex 的 Context 管理是典型的 Selection
Anthropic Claude 家族本身 Prompt Caching 就是 Compression
MCP 协议的工具发现机制可以帮你做动态 Selection
OpenAI Assistants API 的 threads 某种程度上也是一种 Context 存储抽象

关于 MCP 的使用细节，站内 Tool与MCP 分类下有几篇专门的文章。想看国际上关于 Context Engineering 的更多一手讨论，可以看 hermes.cocoloop.cn 上整理的一些长文（那边偏英文内容聚合）。

六、一句话总结思路转变

过去我面对一个 AI 应用问题，第一反应是 “我怎么改 prompt 让模型答得对“。
现在我的第一反应是 “我要给模型看什么它才可能答得对“。

前者是说服，后者是供给。从说服到供给，这就是 Prompt Engineering 到 Context Engineering 的本质区别。

下一个范式升级是什么？我赌是 Memory Engineering——也就是怎么让模型跨会话、跨任务地积累和调用知识。这块 Anthropic 刚出的 Memory Tool 已经在铺路了，等我试得再深一点再写。

最后给一个务实建议：如果你现在还在靠一份几百字的 system prompt 撑着业务，就别继续卷 prompt 措辞了，往 Context Engineering 方向搬。工程化投入回报比那高一个数量级。

关注 AI 工程前沿范式

本站持续更新 Agent / Context / MCP 相关实战。想看海外 AI 前沿动态可访问 news.cocoloop.cn，想看 Claude Code 相关深度内容可以去 claudecode.cocoloop.cn。