Agent 设计模式
从 Prompt 工程到上下文工程
当我们从单轮对话走向多步 Agent，仅仅优化 Prompt 已经远远不够。真正的挑战是：如何策展每一轮推理时送给模型的全部 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 模拟器
1K Token -- 一段对话
注意力集中，检索准确
检索准确率
注意力密度
高注意力 低注意力
理解注意力的代价
Transformer 的自注意力机制中，每个 Token 都要和其他所有 Token 计算关联度：
Attention Complexity = O(n^2)
这意味着：把上下文从 50K 扩展到 100K Token，注意力计算量会变为原来的 4 倍，远超翻倍。上下文不是免费的：每多塞一个无关 Token，都在浪费其他 Token 能获得的注意力。
高效上下文的三个原则
System Prompt 的合适高度
太模糊（「你是一个有用的助手」）= 模型缺乏方向感，输出泛泛而谈。
太具体（列举 50 种边界情况）= 模型被过度约束，无法灵活处理新情况。
最佳实践：给出明确的角色定位和核心原则（5-10 条），然后信任模型在此框架下自主判断。像好的管理者一样，给方向，不给每一步的指令。
太具体（列举 50 种边界情况）= 模型被过度约束，无法灵活处理新情况。
最佳实践：给出明确的角色定位和核心原则（5-10 条），然后信任模型在此框架下自主判断。像好的管理者一样，给方向，不给每一步的指令。
System Prompt 的高度要找到中间的甜蜜点
工具集要精简
生产实践验证：如果人类都分不清该用哪个工具，AI 也分不清。
给 Agent 10 个功能相似但描述模糊的工具，不如给 5 个职责清晰、命名精准的工具。每个工具的 description 要像好的 API 文档一样，让调用者（模型）一看就知道什么时候用、怎么用。
给 Agent 10 个功能相似但描述模糊的工具，不如给 5 个职责清晰、命名精准的工具。每个工具的 description 要像好的 API 文档一样，让调用者（模型）一看就知道什么时候用、怎么用。
Few-shot 精选典型，不要堆砌
Few-shot 示例是上下文中 ROI 最高的部分，但前提是选对了。
正确做法：精选 2-3 个最能代表目标行为的典型例子，覆盖最常见的输入模式。
错误做法：堆砌 10+ 个边界 case 的例子，不仅浪费 Token，还让模型过度关注异常情况而忽略主线。
正确做法：精选 2-3 个最能代表目标行为的典型例子，覆盖最常见的输入模式。
错误做法：堆砌 10+ 个边界 case 的例子，不仅浪费 Token，还让模型过度关注异常情况而忽略主线。
上下文是稀缺资源。你的目标是找到最小的高信号 Token 集合。每一个 Token 都必须为模型的推理做出贡献，能放多少就放多少的思路行不通。像编辑精修文章一样精修你的上下文：每个多余的词都是噪音。