情境工程：提示前的工作

spinny:~/writing $ vim context-engineering-agents.md

1~
2在人工智能代理的小世界里，当下最流行的词是上下文工程。
3~
4这似乎又是一个为了销售我们已经做过的东西而发明的品牌。部分是这样。然而，正如经常发生的那样，这个标签之所以流行，是因为它给真正的痛苦起了一个名字。
5~
6痛苦在于：模型不会仅仅因为“不思考”而失败。他们经常失败，因为我们派他们去错误的房间工作。
7~
8我们给他们旧的指示。我们向他隐藏了重要文件。我们向他们传递的文件太长，而且没有说明什么是重要的。我们向他们展示日志，没有优先顺序。我们给了他们十种工具，但没有解释何时使用它们。然后，如果特工的动作就像一个在未知公寓中醒来的人一样，我们会感到惊讶。
9~
10提示是您对它说的短语。背景是你围绕它准备的世界。
11~
12## 从即时工程到情境工程
13~
14即时工程通常被认为是写作。选择正确的词语，以正确的方式提问，添加示例，指定格式。
15~
16情境工程更接近于建筑。
17~
18您不只是问“我如何提出请求？”。它问：
19~
20- 真正需要什么信息？
21- 什么是噪音？
22- 什么需要即时恢复？
23- 应该记住什么？
24- 哪些工具应该公开？
25- 哪些指令是稳定的，哪些取决于任务？
26- 如何让代理人明白什么是权威？
27~
28这是一个微妙但巨大的变化。因为当您使用代理时，上下文不是静态块。每一步都会发生变化。
29~
30代理打开文件、学习某些内容、运行测试、接收错误、更新计划、调用工具、发现依赖项。每跑一圈，他都必须决定要带什么、不带什么。
31~
32这是工程学。
33~
34## 上下文不是垃圾填埋场
35~
36具有大上下文窗口的模板给了我们一个诱惑：让我们把所有东西都放进去。
37~
38这是可以理解的。如果我有一百万个代币，我为什么要选择？
39~
40因为即使你可以把所有东西都放进去，也不意味着所有东西都有帮助。事实上，噪音是有代价的。它需要代币、需要注意力、需要延迟、需要质量。就像我们一样，当我们打开二十个选项卡并且不再记得原因时，模型可能会迷失在不相关的细节中。
41~
42良好的上下文具有层次结构：
43~
441. 系统指令和政策；2.具体目标；3.现状；4.相关数据；
452. 限制因素；6.可用的工具；
463. 跟踪已经做出的决定。
47~
48没有必要把所有事情都放在同一水平上对待。用户命令比旧注释更有价值。现在，一次失败的测试比三个月前的审美偏好更有价值。安全策略比生产捷径更有价值。
49~
50上下文工程还意味着赋予权重，而不仅仅是数据。
51~
52## 记忆力：记得少，记得好
53~
54代理的记忆是最棘手的话题之一。
55~
56作为用户，您希望代理了解您。你希望他记住语气、计划、约定以及已经决定的事情。作为一名工程师，您知道每一个持久记忆也是一种风险：它可能是错误的、陈旧的、过于个人化的、过于通用的、无法验证的。
57~
58一个有用的记忆至少应该具备三个品质：
59~
60- 出处：这些信息从哪里来？
61- 日期：什么时候是真的？
62- 目的：它应该用于什么类型的任务？
63~
64没有这三件事，记忆就变成了迷信。
65~
66我喜欢将主体记忆视为一本练习册，而不是一个神奇的头脑。有临时注释、已确认的决定、风格偏好、技术限制、来源链接。有些东西会过期。有些需要重写。有些必须被消除，因为特工错误地推断了它们。
67~
68一个好的系统必须让这种维护变得常态化。不英雄。
69~
70## 检索和工具不是一回事
71~
72当我们谈论背景时，我们通常会立即提到 RAG。嵌入、矢量数据库、分块、重新排名。
73~
74都很有用。但检索只是将信息引入模型的一种方法。他不是唯一一个。
75~
76代理可以通过读取文件、查询 API、调用 MCP 服务器、打开浏览器、运行测试、搜索 Slack、查看仪表板、询问人员来获取上下文。
77~
78有趣的部分是决定使用哪条路线以及何时使用。
79~
80如果智能体需要回答历史问题，也许仅仅检索就足够了。如果他必须修复错误，他就必须阅读真实的代码。如果他需要了解部署失败的原因，他需要查看新日志。如果您需要写信给客户，则需要检索票证的语气、历史记录和状态。如果他必须对生产采取行动，他必须征求许可。
81~
82上下文不是数据库。这是一个工作流程。
83~
84## 好的代理也懂得如何忽略
85~
86代理人成熟的标志是能够说：我不需要这些信息。
87~
88看似微不足道，实则非常困难。许多代理系统不断积累。每个工具调用都会添加文本。每个错误都保留在缓冲区中。每个读取的文件都会添加到堆栈中。最后这个模型已经有很长的历史了，而且没有地图。
89~
90需要压缩。需要中间体合成。它需要结构化。
91~
92不是“这就是发生的一切”，而是：
93~
94- 目标仍然有效；
95- 当前的假设；
96- 已检查的文件；
97- 做出的决定；
98- 公开风险；
99- 下一步行动。
100~
101这使得代理不那么夸张，而且更有帮助。不是因为他看起来更聪明，而是因为他在一张整洁的办公桌上工作。
102~
103## 上下文工程是针对团队的，而不是针对即兴艺术家的
104~
105这个话题让我感兴趣的原因是它将责任从个人转移到了系统上。
106~
107在即时工程中，最能与模型对话的人往往会获胜。在上下文工程中，最好组织工作的团队会获胜：文档、约定、问题、日志、测试、所有权、命名、来源。
108~
109干净的存储库会成为更好的环境。写得好的问题会成为更好的燃料。更新的操作手册可以节省代币和焦虑。清晰的变更日志可以减少幻觉。
110~
111这是个好消息，但有些令人不安。美丽是因为它奖励良好的实践。不方便是因为你无法通过巧妙的提示解决所有问题。
112~
113这些特工增强了他们发现的系统的卫生状况。
114~
115## 明天我将如何应用它
116~
117如果我要将上下文工程引入到一个真实的项目中，我会从小事开始：
118~
119- 简短且维护的项目指导文件；
120- 预期产出的好例子；
121- 可用工具和使用它们的案例列表；
122- 以可引用方式编写的架构决策；
123- 最低限度强制性背景的问题；
124- 易于检索日志和测试；
125- 人类可修改的持久记忆。
126~
127然后我会衡量一个简单的事情：代理需要澄清多少次或走错方向？
128~
129如果这种情况经常发生，我不会立即添加更大的模型。我会看看上下文。
130~
131## 我的阅读
132~
133是的，上下文工程这个词有点臃肿。但这个概念是合理的。
134~
135它提醒我们，智能体的智能不仅仅存在于模型中。它在于我们为他准备的环境：他看到什么，他记得什么，他能做什么，他被禁止做什么，他认为哪些来源是真实的。
136~
137人的部分是这样的：充分准备环境是一种关怀形式。它告诉经纪人，也告诉团队，“我不想让你猜测，我希望你拥有你需要的东西。”
138~
139魔法少一点。房间更干净。代理商和我们一样需要它。
140~
141## 来源
142~
143- [LangChain博客：上下文工程的兴起](https://blog.langchain.com/the-rise-of-context-engineering/)
144- [西蒙·威利森：情境工程](https://simonwillison.net/2025/Jun/27/context-engineering/)
145- [模型上下文协议：简介](https://modelcontextprotocol.io/introduction)
146- [Anthropic：构建有效的代理](https://www.anthropic.com/engineering/building- effective-agents)
147- [OpenAI：构建代理的新工具](https://openai.com/index/new-tools-for-building-agents/)
148~

NORMAL · context-engineering-agents.md [readonly]148 lines · :q to close

2在人工智能代理的小世界里，当下最流行的词是上下文工程。

4这似乎又是一个为了销售我们已经做过的东西而发明的品牌。部分是这样。然而，正如经常发生的那样，这个标签之所以流行，是因为它给真正的痛苦起了一个名字。

6痛苦在于：模型不会仅仅因为“不思考”而失败。他们经常失败，因为我们派他们去错误的房间工作。

8我们给他们旧的指示。我们向他隐藏了重要文件。我们向他们传递的文件太长，而且没有说明什么是重要的。我们向他们展示日志，没有优先顺序。我们给了他们十种工具，但没有解释何时使用它们。然后，如果特工的动作就像一个在未知公寓中醒来的人一样，我们会感到惊讶。

10提示是您对它说的短语。背景是你围绕它准备的世界。

11~

12## 从即时工程到情境工程

13~

14即时工程通常被认为是写作。选择正确的词语，以正确的方式提问，添加示例，指定格式。

15~

16情境工程更接近于建筑。

17~

18您不只是问“我如何提出请求？”。它问：

19~

20- 真正需要什么信息？

21- 什么是噪音？

22- 什么需要即时恢复？

23- 应该记住什么？

24- 哪些工具应该公开？

25- 哪些指令是稳定的，哪些取决于任务？

26- 如何让代理人明白什么是权威？

27~

28这是一个微妙但巨大的变化。因为当您使用代理时，上下文不是静态块。每一步都会发生变化。

29~

30代理打开文件、学习某些内容、运行测试、接收错误、更新计划、调用工具、发现依赖项。每跑一圈，他都必须决定要带什么、不带什么。

31~

32这是工程学。

33~

34## 上下文不是垃圾填埋场

35~

36具有大上下文窗口的模板给了我们一个诱惑：让我们把所有东西都放进去。

37~

38这是可以理解的。如果我有一百万个代币，我为什么要选择？

39~

40因为即使你可以把所有东西都放进去，也不意味着所有东西都有帮助。事实上，噪音是有代价的。它需要代币、需要注意力、需要延迟、需要质量。就像我们一样，当我们打开二十个选项卡并且不再记得原因时，模型可能会迷失在不相关的细节中。

41~

42良好的上下文具有层次结构：

43~

441. 系统指令和政策；2.具体目标；3.现状；4.相关数据；

452. 限制因素；6.可用的工具；

463. 跟踪已经做出的决定。

47~

48没有必要把所有事情都放在同一水平上对待。用户命令比旧注释更有价值。现在，一次失败的测试比三个月前的审美偏好更有价值。安全策略比生产捷径更有价值。

49~

50上下文工程还意味着赋予权重，而不仅仅是数据。

51~

52## 记忆力：记得少，记得好

53~

54代理的记忆是最棘手的话题之一。

55~

56作为用户，您希望代理了解您。你希望他记住语气、计划、约定以及已经决定的事情。作为一名工程师，您知道每一个持久记忆也是一种风险：它可能是错误的、陈旧的、过于个人化的、过于通用的、无法验证的。

57~

58一个有用的记忆至少应该具备三个品质：

59~

60- 出处：这些信息从哪里来？

61- 日期：什么时候是真的？

62- 目的：它应该用于什么类型的任务？

63~

64没有这三件事，记忆就变成了迷信。

65~

66我喜欢将主体记忆视为一本练习册，而不是一个神奇的头脑。有临时注释、已确认的决定、风格偏好、技术限制、来源链接。有些东西会过期。有些需要重写。有些必须被消除，因为特工错误地推断了它们。

67~

68一个好的系统必须让这种维护变得常态化。不英雄。

69~

70## 检索和工具不是一回事

71~

72当我们谈论背景时，我们通常会立即提到 RAG。嵌入、矢量数据库、分块、重新排名。

73~

74都很有用。但检索只是将信息引入模型的一种方法。他不是唯一一个。

75~

76代理可以通过读取文件、查询 API、调用 MCP 服务器、打开浏览器、运行测试、搜索 Slack、查看仪表板、询问人员来获取上下文。

77~

78有趣的部分是决定使用哪条路线以及何时使用。

79~

80如果智能体需要回答历史问题，也许仅仅检索就足够了。如果他必须修复错误，他就必须阅读真实的代码。如果他需要了解部署失败的原因，他需要查看新日志。如果您需要写信给客户，则需要检索票证的语气、历史记录和状态。如果他必须对生产采取行动，他必须征求许可。

81~

82上下文不是数据库。这是一个工作流程。

83~

84## 好的代理也懂得如何忽略

85~

86代理人成熟的标志是能够说：我不需要这些信息。

87~

88看似微不足道，实则非常困难。许多代理系统不断积累。每个工具调用都会添加文本。每个错误都保留在缓冲区中。每个读取的文件都会添加到堆栈中。最后这个模型已经有很长的历史了，而且没有地图。

89~

90需要压缩。需要中间体合成。它需要结构化。

91~

92不是“这就是发生的一切”，而是：

93~

94- 目标仍然有效；

95- 当前的假设；

96- 已检查的文件；

97- 做出的决定；

98- 公开风险；

99- 下一步行动。

100~

101这使得代理不那么夸张，而且更有帮助。不是因为他看起来更聪明，而是因为他在一张整洁的办公桌上工作。

102~

103## 上下文工程是针对团队的，而不是针对即兴艺术家的

104~

105这个话题让我感兴趣的原因是它将责任从个人转移到了系统上。

106~

107在即时工程中，最能与模型对话的人往往会获胜。在上下文工程中，最好组织工作的团队会获胜：文档、约定、问题、日志、测试、所有权、命名、来源。

108~

109干净的存储库会成为更好的环境。写得好的问题会成为更好的燃料。更新的操作手册可以节省代币和焦虑。清晰的变更日志可以减少幻觉。

110~

111这是个好消息，但有些令人不安。美丽是因为它奖励良好的实践。不方便是因为你无法通过巧妙的提示解决所有问题。

112~

113这些特工增强了他们发现的系统的卫生状况。

114~

115## 明天我将如何应用它

116~

117如果我要将上下文工程引入到一个真实的项目中，我会从小事开始：

118~

119- 简短且维护的项目指导文件；

120- 预期产出的好例子；

121- 可用工具和使用它们的案例列表；

122- 以可引用方式编写的架构决策；

123- 最低限度强制性背景的问题；

124- 易于检索日志和测试；

125- 人类可修改的持久记忆。

126~

127然后我会衡量一个简单的事情：代理需要澄清多少次或走错方向？

128~

129如果这种情况经常发生，我不会立即添加更大的模型。我会看看上下文。

130~

131## 我的阅读

132~

133是的，上下文工程这个词有点臃肿。但这个概念是合理的。

134~

135它提醒我们，智能体的智能不仅仅存在于模型中。它在于我们为他准备的环境：他看到什么，他记得什么，他能做什么，他被禁止做什么，他认为哪些来源是真实的。

136~

137人的部分是这样的：充分准备环境是一种关怀形式。它告诉经纪人，也告诉团队，“我不想让你猜测，我希望你拥有你需要的东西。”

138~

139魔法少一点。房间更干净。代理商和我们一样需要它。

140~

141## 来源

142~

143- [LangChain博客：上下文工程的兴起](https://blog.langchain.com/the-rise-of-context-engineering/)

144- [西蒙·威利森：情境工程](https://simonwillison.net/2025/Jun/27/context-engineering/)

145- [模型上下文协议：简介](https://modelcontextprotocol.io/introduction)

146- [Anthropic：构建有效的代理](https://www.anthropic.com/engineering/building- effective-agents)

147- [OpenAI：构建代理的新工具](https://openai.com/index/new-tools-for-building-agents/)

148~