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