📝 本期播客简介

本期我们邀请到了 LangChain 的核心开发者 Lance Martin，为我们系统性地拆解了当下 AI Agent 开发中最棘手的难题之一：“上下文工程”（Context Engineering）。当我们将简单的聊天机器人升级为能调用工具、执行复杂任务的智能体时，如何管理和优化不断膨胀的上下文，成为了决定成本、性能和稳定性的关键。Lance 从“卸载”、“隔离”、“检索”、“缩减”和“缓存”五个方面，深入剖析了最前沿的上下文管理技术，并分享了来自 Anthropic、Cognition、Manis 等顶尖团队的不同实现路径。此外，他还将经典的“苦涩的教训”理论应用到 AI 工程中，分享了他如何在实践中不断“拆解”自己的系统以拥抱更强的模型能力。这期节目是所有 AI 开发者不容错过的实战指南，带你跳出简单的工具调用循环，真正构建出高效、可扩展的 AI 智能体。

👨‍⚕️ 本期嘉宾

Lance Martin，LangChain 核心开发者，LangGraph 等多个知名开源项目的贡献者。他在 AI 智能体、多智能体系统和LLM应用开发领域拥有丰富的实践经验，并通过多门课程和技术文章，为社区贡献了大量关于构建复杂AI系统的宝贵知识。

📒 文字版精华

见微信公众号（点击跳转）

🌟 精彩内容

💡 上下文工程：远超提示词工程的新挑战

Lance 指出，当从简单的聊天交互转向智能体时，上下文的来源从单一的用户输入，扩展到了无数次工具调用的结果。如何为大模型的下一步行动精准提供“恰到好处”的上下文，而不是粗暴地全部塞入，是决定智能体成败的关键，这正是“上下文工程”要解决的核心问题。

“构建一个智能体，你不仅要管理好系统指令和用户指令，还必须处理好智能体在每一步、经过大量工具调用后涌入的所有上下文信息。”

🛠️ 告别复杂RAG？用“LM-text”文件进行极简检索

在检索策略上，除了经典的向量数据库方案，Lance 分享了一种更简单高效的方法：创建一个包含所有文档URL和高质量描述的 `LM-text` 文件，并将其与一个简单的抓取工具交给代码智能体。实验证明，这种“智能体式搜索”效果出奇地好，也印证了 Claude Code 等前沿工具“不索引代码，只用工具搜索”的思路。

“我个人其实不怎么做向量存储索引，我实际上用的是 LM-text 配合一个简单的搜索工具，再加上 Claude Code，这成了我的首选组合。”

🚀 “苦涩的教训”在AI工程中的体现

Lance 将机器学习领域的“苦涩的教训”（通用方法+海量算力 > 精巧的领域知识）应用到AI工程。他以重构自己研究智能体的亲身经历说明，随着底层模型能力呈指数级提升，今天为弥补模型缺点而设计的复杂结构，明天就可能成为限制其发挥的瓶颈。AI开发者必须准备好不断“移除结构”，拥抱更强的模型。

“虽然在 2024 年初，那个（结构化的）工作流比构建一个智能体更可靠，但随着大模型变得越来越好，情况很快就反转了。”

🧠 多智能体的正确用法：分离“读”与“写”

针对业界对多智能体架构的争论，Lance 提出了一个清晰的指导原则：在任务可以清晰、轻易并行化的情况下使用多智能体，比如并行的“读”任务（收集资料）。但要避免让多个子智能体同时进行“写”任务（如编写最终方案的不同部分），因为它们之间难以协调，容易产生决策冲突。

“把多智能体应用在那些容易并行化的问题上，比如只读任务，像为深度研究收集上下文，然后在最后完成所谓的‘写’操作。”

⛓️ LangGraph 的哲学：拥抱编排，警惕抽象

面对“反框架”的思潮，Lance 明确区分了两种“框架”：应拥抱的是提供底层节点、边、状态等组件的“编排框架”（如 LangGraph），它灵活且易于拆解；而需要警惕的是 `from framework import agent` 这种高层“智能体抽象”，它隐藏了底层实现，让你在模型升级时难以调整，可能违背“苦涩的教训”。

“我非常同情对框架的那部分批评。但我不讨厌底层的编排框架，它们只提供节点、边，你可以用任何你想要的方式重新组合它们。”

🌐 播客信息补充

翻译克隆自：Context Engineering for Agents - Lance Martin, LangChain

本播客采用原有人声声线进行播客音频制作，也可能会有一些地方听起来怪怪的

使用 AI 进行翻译，因此可能会有一些地方不通顺；

如果有后续想要听中文版的其他外文播客，也欢迎联系微信：iEvenight