Agent 设计模式 从 Prompt 工程到上下文工程 当我们从单轮对话走向多步 Agent，仅仅优化 Prompt 已经远远不够。真正的挑战是：如何策展每一轮推理时送给模型的全部 Token。 一句话速览 在每一轮推理时策展最优的 Token 组合，写好提示词只是其中一环 概念演进

过去 Prompt Engineering 优化提示词的写法：措辞、结构、Few-shot 示例

现在 Context Engineering 策展每一轮推理时送给模型的 全部 Token ：System Prompt、工具定义、MCP 描述、对话历史、外部检索数据...

Prompt 工程关注的是怎么写指令，而上下文工程关注的是一个更大的问题： 模型的输入窗口里放什么、怎么放、放多少 。当你的系统有 System Prompt、工具描述、历史消息、RAG 检索结果、用户偏好…这些加起来可能占满大半个上下文窗口。如何管理这些 Token，就是上下文工程。

上下文窗口里有什么

System Prompt — 角色定义、规则、约束

Tool Definitions — 工具名称、参数、描述

Conversation History — 多轮对话历史

Retrieved Data — RAG 检索结果、文件内容

User State — 用户偏好、会话状态、环境信息

所有这些加在一起 = 模型每次推理时看到的全部信息

为什么上下文工程重要

Context Rot 上下文越长，模型对信息的检索准确率越低。关键信息被淹没在海量 Token 中。

注意力预算有限 每个 Token 都在消耗模型的注意力预算。无关 Token 占位 = 有用信息被稀释。

n-squared 复杂度 n 个 Token 产生 n x n 个注意力关系。上下文翻倍，计算量四倍增长。

动手试试：Context Rot 模拟器

上下文 Token 数量

1K Token

1K Token -- 一段对话 注意力集中，检索准确

检索准确率

95%

0% 50% 100%

注意力密度

高注意力 低注意力

理解注意力的代价

Transformer 的自注意力机制中，每个 Token 都要和其他所有 Token 计算关联度： Attention Complexity = O(n^2) 这意味着：把上下文从 50K 扩展到 100K Token，注意力计算量会变为原来的 4 倍，远超翻倍。 上下文不是免费的 ：每多塞一个无关 Token，都在浪费其他 Token 能获得的注意力。

高效上下文的三个原则

System Prompt 的合适高度

太模糊（「你是一个有用的助手」）= 模型缺乏方向感，输出泛泛而谈。 太具体（列举 50 种边界情况）= 模型被过度约束，无法灵活处理新情况。 最佳实践： 给出明确的角色定位和核心原则（5-10 条），然后信任模型在此框架下自主判断。像好的管理者一样，给方向，不给每一步的指令。

太低 太模糊 「你是助手」

刚好 合适高度 角色+原则+边界

太高 太具体 50条规则+100个case

System Prompt 的高度要找到中间的甜蜜点

工具集要精简

生产实践验证： 如果人类都分不清该用哪个工具，AI 也分不清。 给 Agent 10 个功能相似但描述模糊的工具，不如给 5 个职责清晰、命名精准的工具。每个工具的 description 要像好的 API 文档一样，让调用者（模型）一看就知道什么时候用、怎么用。

Few-shot 精选典型，不要堆砌

Few-shot 示例是上下文中 ROI 最高的部分，但前提是选对了。 正确做法： 精选 2-3 个最能代表目标行为的典型例子，覆盖最常见的输入模式。 错误做法： 堆砌 10+ 个边界 case 的例子，不仅浪费 Token，还让模型过度关注异常情况而忽略主线。

上下文是稀缺资源。你的目标是找到最小的高信号 Token 集合。 每一个 Token 都必须为模型的推理做出贡献，能放多少就放多少的思路行不通。像编辑精修文章一样精修你的上下文：每个多余的词都是噪音。