以上下文工程走向长程代理：LangChain Harrison Chase 访谈
摘要
Harrison Chase，LangChain 的联合创始人兼 CEO，在本期 Training Data 节目中深入探讨了长程代理（Long Horizon Agents）的兴起及其底层驱动力——上下文工程（Context Engineering）。他指出，过去一年代理领域经历了一次重大拐点：从定制化认知架构（cognitive architectures）转向更为通用的代理基座（agent harness），其核心算法极其简单——将大语言模型（Large Language Model, LLM）放入循环中运行，关键在于围绕它的上下文管理策略。Harrison 详细阐述了构建代理与传统软件开发的本质差异：在代理中，应用逻辑不再完全体现在代码中，大部分来自模型的黑箱决策，因此追踪（traces）取代代码成为真相之源（source of truth）。他讨论了内存（memory）作为上下文工程在更长时间尺度上的延伸，以及自我改进代理的愿景——代理在夜间回顾当日追踪记录并自动调整自身指令。最后，Harrison 分享了关于代理评估（eval）、人类判断在评估体系中的角色，以及异步/同步双模交互（async/sync mode）如何塑造下一代代理工作界面的前瞻思考。
正文
长程代理的拐点时刻
Harrison 将代理的发展划分为三个时代。第一个时代是 LangChain 初创时期，模型还处于原始文本输入输出的阶段，没有工具调用（tool calling）、内容块（content blocks）或推理能力——人们只能做简单的单次提示或链式调用（chains）。
第二个时代始于各大模型实验室开始在训练中引入工具调用。模型学会了决策下一步行动，但可靠性不足。开发者通过定制化的认知架构来弥补这一缺陷，显式地询问模型"这里该做什么"，然后走一个分支，再问"接下来做什么"。这些架构为模型增加了大量脚手架（scaffolding）。
关键的拐点出现在 2025 年夏秋之际。Harrison 观察到 Claude Code 迅速崛起，Deep Research 和 Manus 也开始起飞。它们底层使用相同的核心算法——LLM 在循环中运行——但通过精巧的上下文工程策略取得了突破性进展：压缩（compaction）、子代理（sub-agents）、技能（skills）、上下文管理。Harrison 指出："我们看到它们用着相同的基础算法，但仅仅通过改进上下文工程就获得了显著提升。这很有意思，跟之前完全不同。"正是这个洞察促使 LangChain 推出了 Deep Agents 这一代理基座产品。
模型 vs 框架 vs 基座
Harrison 将代理技术栈清晰地划分为三层。模型（model）是 LLM 本身—— tokens 进、tokens 出。框架（framework）提供模型切换、工具、向量存储、内存等抽象层，但保持"不表态"（unopinionated）——LangChain 最初就定位为代理框架。而基座（harness）则是"开箱即用"（batteries included）的方案：Deep Agents 默认内置规划工具（planning tool），这本身就是一个强烈的设计声明。基座还包括压缩策略，因为长程代理长时间运行，上下文窗口并非无限。
Harrison 认为，模型与基座之间存在共演化（co-evolution）的关系："如果回到两年前，我们不可能知道基于文件系统的基座是最优选择，因为当时的模型没有接受过这方面的训练。而现在，模型和基座在共同进化。"推理模型（reasoning models）的进步无疑至关重要，但围绕压缩、规划以及文件系统工具这些原语（primitives）的理解也在同步深化。
关于谁应该构建基座，Harrison 保持谨慎。他指出，基座与模型家族之间存在某种绑定关系——Anthropic 微调针对特定工具，OpenAI 则针对不同的工具集。但所有基座都共享一个特征：文件系统交互。在 Terminal Bench 2 等编码基准测试中，基座+模型的组合排名揭示了性能差异，但这并不意味着模型厂商必然做得更好，而是说明理解模型如何工作的人可以在基座层面获得性能优势。
代理 vs 软件：本质差异
Harrison 认为，"构建代理不同于构建软件"这句话虽然已近陈词滥调，但其中确有深刻真理。核心差异在于：传统软件的所有逻辑都存在于代码中，你可以通过阅读代码完全理解其行为；而在代理中，应用逻辑的很大一部分来自模型——一个黑箱、非确定性系统。
这意味着：
- 真相之源从代码转向追踪：要理解代理在特定场景下的行为，不能只看代码，必须实际运行它并查看追踪。LangSmith 的追踪功能之所以受欢迎，正是因为它在每一步揭示了代理内部发生的事情。
- 追踪成为协作的媒介：当代理出现问题时，开发团队不再说"去看看 GitHub 上的代码"，而是"发一个 LangTrace 给我们"。这在开源社区中已成为标准做法。
- 评估需要人类判断：软件可以通过程序化断言进行测试，但代理所做的很多工作原本是由人类完成的，因此需要引入人类判断来评估其质量。LangSmith 的标注队列（annotation queues）和基于 LLM 的评判（LLM-as-judge）功能正是为此设计。
Harrison 还指出，代理开发比软件开发更具迭代性。在软件中，你发布前就知道产品会做什么；但在代理中，你只有想法，并不知道代理真正会做什么，直到它开始运行。这使得"概念性单元测试"变得更为重要，也解释了为什么内存（memory）如此关键——如果系统能从交互中学习，就能减少开发者需要手动迭代的轮次。
文件系统、编码沙箱与浏览器使用
在工具生态方面，Harrison 明确表态："我完全被文件系统说服了（file system pilled）。"他认为任何代理都应该以某种形式访问文件系统。文件系统在上下文管理中扮演核心角色：一种压缩策略是将完整消息存储在文件系统中供代理按需检索；另一种策略是将大型工具调用结果放入文件系统而非直接传递给模型。
关于编码执行（code sandboxes），Harrison 表示"大约 90% 被说服了"。他指出编码代理可能是通用代理的最佳路径——代码是让计算机执行有用任务的极佳方式。但他也强调，并非所有文件系统操作都需要真实编码能力：LangChain 提供了虚拟文件系统（virtual file system）的概念，由 Postgres 等后端支持，更具可扩展性。
对于浏览器使用（browser use），Harrison 持保留态度："从我们目前看到的情况来看，模型在这方面还不够好。"他认为可以给编码代理一个命令行接口（CLI）来近似实现浏览器使用，但目前编码执行远优于浏览器操作。
内存：上下文工程的时间维度
内存是 Harrison 当前最兴奋的领域。他将内存视为上下文工程在更长时间尺度上的延伸——不仅仅是单次会话内的上下文管理，而是跨会话的学习和改进。LangChain 的 Agent Builder 中已实现了一种形式的内存：当用户说"你应该做 Y 而不是 X"时，代理会编辑自己的指令文件，下次遇到类似场景时行为就会改变。
更具雄心的愿景是"睡眠时间计算"（sleep time compute）——代理在夜间回顾当天的所有追踪记录，自动更新自身指令。Harrison 坦言："这绝对是某种递归的自我改进（recursive self-improvement）。"
但他也承认内存并非万能药。以 ChatGPT 的内存功能为例，Harrison 个人很少使用它，因为他每次与 ChatGPT 的交互都是一次性的不同主题。内存在重复性工作流中才真正有效。他分享了一个个人经历：他的邮件代理在迁移到 Agent Builder 后失去了所有记忆，即使拥有相同的初始提示和工具，体验依然大打折扣。这让他深刻体会到记忆可以成为真正的护城河（moat）。
代理评估与人类判断
评估是代理开发中最具挑战性的环节之一。Harrison 指出，核心难题在于代理的许多输出需要人类判断——你需要"人类评判"来校准"LLM 评判"。LangSmith 的 Align Evals 功能正是解决这一问题的尝试：人类先标注一批追踪记录，然后基于这些标注构建一个经过校准的 LLM 评判器。
一个正在兴起的模式是代理利用追踪进行自我诊断和改进。通过 LangSmith MCP 或 LangSmith Fetch CLI，编码代理可以拉取自己的追踪记录，诊断出问题所在，然后将追踪带入代码库进行修复。Harrison 对此模式格外看好："这比强化学习（reinforcement learning）对当前的代理应用公司更为实用。"
下一代代理交互界面
关于长程代理的用户界面，Harrison 认为需要异步（async）和同步（sync）双模式。代理运行数小时甚至一整天时，用户不可能持续等待——需要类似 Linear、Jira 或看板的任务管理视图来异步监控进度。但当代理完成研究工作并返回报告时，用户需要切换到同步交互模式进行反馈和修正。
他观察到，当前许多代理都在修改文件系统中的文件，因此能够查看代理修改的状态变得至关重要。这一点在编码领域已经成熟——IDE 仍然是手动编辑代码的入口。Anthropic 的 Claude Co-Work 通过让用户指定工作目录来划定代理的"工作环境"，Harrison 认为这是一个很好的心理框架。
在他早期的"代理收件箱"（Agent Inbox）概念中，第一个版本只有异步模式——代理完成任务后弹出一条通知，用户回复，然后继续等待。但实际使用中，用户往往希望立即进入深度对话。因此他们增加了同步聊天模式："现在当你打开收件箱，你会直接进入聊天界面——这是一种非常同步的体验——这实际上是一个很大的解锁。"
正文
Harrison 提到越来越多的年轻开发者涌入代理工程团队，他们没有传统软件开发的预设观念，对代理开发范式更加适应。但他也强调，数据仍然是老牌软件公司的核心优势——如果一家公司拥有高质量的数据和 API，接入代理基座后将如虎添翼。
最后，Harrison 展望了未来。他认为代理基座将走向标准化——大多数公司不会自建基座，因为它远比框架更难构建，他们会选择 LangChain 或其它供应商的现成基座。真正的差异化将体现在提示词、指令和连接的特定工具上。而"将上下文工程交给 LLM 自己决定"——正如 Anthropic 正在尝试的让模型自行决定何时压缩上下文——可能是下一个重要方向。
在编码工具方面，Harrison 认为编码代理可能是通用代理的前身，但也承认当前编码代理在编码任务上进行了深度优化。这让 LangChain 团队正在积极思考一个核心问题：所有代理最终都会是编码代理吗？编码是否是代理与世界交互的最通用语言？