伴随模型能力持续跃迁，简单调用 LLM API、套一层提示词就能做产品的时代，已经走到尽头。
AI 应用正在从“单次生成”，迈向“持续执行”。下一代软件系统，不再只是把大模型接进工作流，而是围绕一层全新的 agent orchestration 架构展开：它负责让智能体自主规划、调用工具、编写代码、管理文件、压缩上下文、调度子智能体，并在长时程任务中保持连贯行动。
这也意味着：简单封装 AI 的时代正式结束，整个软件基础设施层，正在被重新书写。
刚刚完成 1.25 亿美元新融资的 LangChain，正是这场浪潮的定义者之一。其创始人 Harrison Chase 在最新一期播客中围绕 “到底是模型吞噬框架，还是框架吞噬模型” 的行业争论，直接指出“框架才是未来，模型终将走向商品化”。
在这场对话里，他首次清晰定义出现代智能体的四大核心组件：系统提示词、规划工具、子智能体、文件系统，这是目前业界最统一的 “标准架构”。
面对未来趋势是超强单智能体还是专业多智能体协作，他认为 最有价值的永远是指令和工具本身。
他自曝当初创建 LangChain，正是看准了 LLM 循环调用工具的巨大潜力。从早期开源框架，到 LangGraph、Deep Agents、LangSmith 再到 Agent Builder，LangChain 自身也完成了从 “实验玩具” 到 “生产级智能体运行时” 的蜕变。
Harrison Chase 透露，LangChain 接下来的核心方向很明确：一边押注商业化表现最强的可观测性，一边补齐部署与无代码能力，朝完整的智能体工程平台继续推进。
这期访谈，几乎把智能体的底层逻辑讲透：
以下是访谈全文，经 InfoQ 翻译整理。
长时程智能体，最后都是编码智能体
主持人：我感觉在去年 12 月到 1 月假期前后，出现了一个关键转折点 —— 所有人几乎同时意识到，短短几个月内，智能体的能力已经突飞猛进。你能帮我们对比一下，第一代智能体和现在的智能体有什么区别？
Harrison Chase：如今智能体背后的很多理念，其实在早期就已经出现了。区别在于，当时的模型根本跑不起来。LangChain 大概比 ChatGPT 早一两个月推出，我们一开始加入的核心功能之一，就是让 LLM 在循环中运行并调用工具。当时有一篇非常重要的论文叫 ReAct，核心思路就是这个。它在维基百科问答这类数据集上有效，但在真实场景里完全不行。到了 3 月，AutoGPT 问世，本质也是一样：循环运行、调用工具，在很多方面可以说是 OpenDevin 的前身。
我对智能体发展轨迹的总结是：最开始只有一个非常简单的核心理念 —— 让 LLM 循环运行、调用工具，给它提示词、指令和一堆工具，但效果并不好。于是人们开始围绕模型搭建 脚手架，让它们的行为更可预测、更可靠。这也是我们在 LangChain 推出 LangGraph 的原因：它是另一个框架，专门面向图结构工作流，提供更强的结构化能力，适合需要超高可靠性的场景。
但大概在 11、12 月，随着最新一批云模型发布，模型能力变得极强，大家发现它们真的可以直接在循环里跑起来。这不仅仅是模型本身的进步，还有围绕模型的 框架。如果你回看一年前的产品，比如 Claude Code、Manis、Deep Research，它们都采用了同样的模式：让模型循环运行、调用工具、编写代码、读写文件。
所以我认为两件事同时发生：
模型本身变得更强；
我们开始发现一套基础的框架原语，能真正让模型发挥最佳效果。大家在假期前后基本都意识到了这一点，于是我们看到，开发者开始爆发式地用这些核心原语构建各种智能体。
主持人：我们说的是编码智能体吗？我记得你好像说过，每个智能体都应该是编码智能体。
Harrison Chase：我们看到市场上出现了两类不同的智能体：一类是 对话式智能体，比如客服、聊天机器人。它们需要极低延迟，通常以语音为交互媒介，很少调用工具，可能只会一两次，太多就会太慢。另一类是红杉资本提出的 长时程智能体，我很喜欢这个定义。它们可以长时间运行、做规划、保持连贯性。而这类智能体，最终大多表现得像 编码智能体。
原因有几点：第一，代码通用性极强。你可以用代码解析文本、批量处理文件，与其调用 100 次不同工具，不如写一个脚本循环完成。第二，模型本身就是在代码上训练的。所有大模型厂商都在让模型学习代码、Bash 命令、文件编辑，这些是模型最擅长的事情。
所以我们看到智能体分成两大方向：长时程智能体 vs 对话智能体。而长时程期智能体里，编码智能体或类编码智能体效果最好。
主持人：你认为随着对话智能体往技术栈深处走，它们也会变成编码智能体吗？
Harrison Chase：这是个好问题。我们内部也经常讨论，是否要为对话智能体做一套专门的框架。我认为未来会出现 融合：当智能体能可靠地启动并管理其他长时程智能体时，两类形态就会合并。我们在编码场景里看到一个趋势：用户希望一边和主智能体聊天，一边让它在后台启动一批子智能体干活。这在某种意义上和对话智能体非常像。未来语音智能体显然也需要做更多长时程任务，实现方式大概率是：一个对话智能体在前台，后台启动异步运行的子智能体。最终所有形态会收敛到同一个框架里，支持后台异步长时智能体作为工具。
是模型吞噬框架？还是框架吞噬模型？
主持人：你刚才提到，智能体加速的部分原因是模型变强。这让我好奇：最终谁会赢？你认为是模型最终吞噬框架层，还是框架和基础设施层吞噬模型，让底层模型彻底商品化？
Harrison Chase：我认为 框架才是最重要的。我不知道未来会怎样，但 Manis 就是一个绝佳例子：它是一个终端产品，但它的框架是真正的核心秘诀，而且能兼容底层任何模型。再看 Claude Code，云模型固然很强，但真正让它跑起来的是框架。Claude Code 也不只是框架，还包含 UI。我现在认为，框架和上层 UI 之间耦合非常紧密，差别很小。
再看 CodeLlama、Claude Code、Manis、各类深度研究产品，都是框架 + UI 的有趣组合。所以我坚信，框架极其重要。
另外一个有意思的点：很多做框架的人，同时也在做模型。从逻辑上讲，既然做了框架又做了模型，就应该用 RL 让模型专门适配这个框架。但你看 Claude Code 使用的工具，其实并不是模型里通过 RL 学到的那套工具。Anthropic 模型内置了文件编辑工具，但实际框架里用的是另一套完全不同的工具。我问过他们好几次，都没有得到明确答复。但我能确定的是：框架真的非常关键。
主持人：用通俗的话讲，到底什么是框架？
Harrison Chase：简单说，框架就是模型与环境交互的整套方式。它是一套通用工具集。有些专用工具我不认为属于框架，但能和通用环境交互的能力，就是框架的一部分。
比如编码智能体：
如果你在通用框架上再加一个专门对接 Slack 的工具，那是在框架之上做定制。我们认为，绝大多数智能体都应该这么构建：拿一个通用框架，给它指令、工具，就能用。
如今大部分框架还内置了 子智能体（sub-agents）和技能（skills），你可以配置这些能力，这种技能抽象、子智能体抽象，本身就是框架的一部分。框架还会做提示缓存、上下文压缩 —— 当上下文太长时自动压缩。这些都是通用能力，适用于各类应用。
作为应用开发者，你不需要关心底层这些细节，只需要用不同提示词、工具、技能、子智能体去配置，就能打造出面向终端用户的专属智能体。
智能体架构核心组件：提示词、规划工具、子智能体、文件系统
主持人：这些都非常有意思。现在我想深入拆解你刚才提到的各个部分。我们先从系统提示词开始，我认为它是核心架构的一部分。一个详细的系统提示词，到底起什么作用？
Harrison Chase：它驱动智能体，告诉它该做什么。我有时会这么理解：系统提示词就像是给人用的 标准作业流程。智能体一启动就会加载它，直接指导行为。
主持人：它存在于哪里？
Harrison Chase：取决于你怎么创建智能体。比如 Claude Code 这类编码智能体，有一部分系统提示词是内置在框架里的，告诉它如何使用通用工具；另一部分则由用户补充 —— 比如你提供的 claude.md 文件、技能、子智能体，都会被插入到整体系统提示词中。所以实际使用中，系统提示词是多部分内容的合并：一部分内置在框架，一部分由定制者添加。
主持人：你提到了工具。我知道还有规划工具的概念，它是做什么的？
Harrison Chase：工具有很多种。有些是框架内置的基础工具，比如我们和其他很多框架都提供的规划工具。它可以生成计划，写入文件，支持后续编辑，也可以只是让智能体调用这个工具。价值在于：计划会被放进智能体的上下文窗口，相当于给它一个 思维草稿本。
大多数规划工具输出的是任务列表，每个任务包含描述、状态（待办、执行中、已完成）。但大多数框架并不会强制智能体严格按计划执行，只是把计划放进去，让它用来指导行动。早期模型能力不强时，我们会设计显式的规划步骤：先规划，再执行第一步，再第二步。但现在模型更强了，这种硬编码流程太繁琐，遇到中途调整计划就会出问题。现在的主流方式是：把计划存在文本文件里，主智能体参考它行动，但不做严格步骤拆分。
主持人：那子智能体（sub-agents）呢？
Harrison Chase：子智能体的好处是可以 隔离上下文。主智能体在循环中不断积累上下文，信息多是优势，但也会撑爆上下文窗口。子智能体的工作方式是：主智能体给它一个任务、一段字符串，子智能体启动一个全新的上下文窗口，从零开始执行一堆工作，然后只把结果返回给主智能体。这样不同任务之间就有了很好的隔离。
缺点也正是隔离本身：因为隔离，智能体之间必须通信。通信一旦出问题，整个流程就会失效。我们经常看到这种情况：主智能体启动子智能体，子智能体做了大量工作，关键信息都在中间过程，但最后只返回一句 “完成”。主智能体完全不知道它干了什么。这就是子智能体没有收到清晰指令，没有在最终消息里返回结果。
顺便说一句，沟通是人生中最难的事：创业最难、人际关系最难，和智能体协作最难的也是让它们好好沟通。子智能体很强大，但确实增加了一层通信复杂度。
主持人：系统怎么知道什么时候要创建子智能体？
Harrison Chase：完全靠提示词。这就是这类智能体框架的美妙之处。早些年我们用 LangGraph 时，大家会问：我怎么加一个步骤确保智能体在 X 之前做 Y？怎么强制执行顺序？不管好坏，现在的方式就是：你直接告诉它做什么。好处是极度灵活，坏处是无法做到 100% 可靠。
这也是为什么 LangGraph 在强监管行业依然有很高使用率 —— 那里需要极强的可控性、精度和可靠性。即便编码智能体再强，行为依然不可预测，没有任何保证。这也是它迷人的地方：你说什么它做什么；但同时，这也是缺点。
主持人：另一个部分是你提到的文件系统。为什么智能体需要文件系统？
Harrison Chase： 我的理解是，一切都回到 上下文工程，LLM 能看到什么。文件系统本质上是让 LLM自己管理上下文窗口：
我们在 Deep Agents 里用文件系统来卸载超大工具调用结果。比如一个工具返回 6 万个 token，我们不会全部塞给 LLM，而是存进文件，只给它看前 1000 个 token，剩下的告诉它去读文件。我们也用它做摘要：当上下文快溢出时，执行摘要，把原始消息存进文件系统，方便后续回溯。
总的主题就是：让 LLM 自己管理上下文。越来越自主的智能体，趋势就是让 LLM 做越来越多的事，管理自己上下文就是比单纯调用工具更进一步的体现。
主持人：文件系统就是字面意义的文件系统吗？不是数据库？
Harrison Chase：它可以是任何东西。关键是：以文件系统的接口暴露给 LLM，因为 LLM 最擅长和文件系统打交道。在 Deep Agents 里，文件系统可以是磁盘上真实文件系统、Daytona 沙盒，也可以是上层套了文件系统接口的数据库。不是所有东西都得是文件系统，比如 SQL 表就让它写 SQL。但处理大量文本时，即便存在 SQL 里，给它文件接口通常更友好。
主持人：所以，详细系统提示词、规划工具、子智能体、文件系统 —— 这四个就是现代智能体架构的核心组件？
Harrison Chase： 对，就是这四个。我们推出 Deep Agents 时，观察到 Manis、Claude Code、Deep Research 全都具备这四点，于是我们把它们封装进一个 Python 包，让开发者能轻松构建同类产品。这四个至今依然是核心。
其他常用组件还有：
主持人：你能解释一下什么是技能吗？
Harrison Chase：技能本质上就是一堆文件，通常有一个 skill.md，里面是如何完成某件事的指令，也可以包含可执行脚本。它不会直接加载进系统提示词，而是在系统提示词里被引用。你告诉智能体：你拥有代码编写技能、文档编写技能，当它需要时，就会 按需读取 这些文件。
这叫做 渐进式披露：只在 LLM 需要知道时，才告诉它需要知道的内容。这也是让它自己管理上下文窗口的关键方式。 这是 Deep Agents 和大多数框架都支持的核心能力。
我们还在重点研究 异步子智能体，目前大多数框架做得还不够好，Claude Code 虽然支持，但触发逻辑不透明，也难以观测和管理。但我们认为这会越来越重要。
压缩上下文与语义记忆、情景记忆、程序记忆
主持人：你能聊聊上下文压缩吗？我们在子智能体那部分稍微提到过。它是什么？为什么需要？怎么实现？
Harrison Chase： 当你积累了大量上下文，想把它精简缩小时，就会用到压缩。原因很简单：大多数模型无法处理无限上下文，即便能支持百万级 token，你也不想传给它那么多。
在 Deep Agents 里，我们的做法是：
保留最近 N 条消息（比如最近 10 条），保证智能体不中断当前流程；
把更早的所有消息进行精简，提取核心目标、关键信息、重要文件，生成摘要放进上下文窗口；
同时把原始完整消息存进文件系统。
摘要不可能完美，大概能覆盖 80%–95% 的场景，但万一有只能从原始历史里拿到的关键信息，智能体还能去文件里读。
我们还有一个即将发布的新功能：让智能体自己触发压缩。现在几乎所有框架都是硬阈值触发（比如上下文用到 80% 就压缩）。但本着让模型更自主的理念，我们会给它一个工具，让它自己决定什么时候压缩。比如你让它先做任务 A，用到 60% 上下文，接着让它做完全无关的任务 B，它就应该主动压缩，避免无关历史干扰、浪费成本。
主持人：我们再聊聊记忆。你之前提到过语义记忆、情景记忆、程序记忆。能展开讲讲吗？
Harrison Chase： 我把记忆分成三类：
语义记忆：关于世界的事实，比如 “巴黎是法国首都”。我们很擅长做这个，就是 RAG；
情景记忆：过去的交互、对话记录，也很成熟，让智能体查历史对话就行；
程序记忆：最有意思，是 “如何做某事” 的指令。我认为这本质就是智能体的配置：系统提示词、技能、工具，都是程序记忆。
在 Deep Agents 里，我们把这些都表示为文件，智能体可以在运行中更新它们。所以当我们说 “Deep Agents 可以学习”，真正意思是：它可以修改以文件形式存在的程序记忆。
超强单智能体 Vs 专业多智能体
主持人：随着每个智能体积累更多记忆、更多上下文，你认为最终会出现一个全能超级智能体，还是成千上万的智能体和子智能体协同工作？
Harrison Chase：好问题。我确实认为 记忆定义了一个智能体。有趣的是，你可以把定义一个智能体的记忆，作为一项技能暴露给一个超级智能体。
企业里经常遇到这种需求：20 个不同部门，每个部门都要做自己的智能体，但希望用统一界面管控。答案还不固定：
是一个大智能体 + 20 个部门技能？
还是 20 个子智能体？
还是 20 套完全自定义的工作流？
但我坚信一点：最有价值的永远是指令和工具本身。不管它们被打包成技能、子智能体，还是独立智能体，指令和工具的价值不会变。
我认为未来会走向这种模式：前台是一个同步对话智能体，后台启动一批长时间运行的异步智能体。看起来是一个智能体，实际上是不同记忆模块驱动不同子智能体。组合方式会快速变化，脚手架也会快速迭代，但 循环运行、调用工具、文件系统、写代码 这套框架核心是稳定的。框架功能每周都在加，但指令和工具永远有价值。我给企业的首要建议就是：专注打磨指令和工具。
主持人：生态里还有哪些足够稳定、值得投入的部分？比如 MCP，大家已经把它当成标准了吗？
Harrison Chase：MCP 很好，它是一种以标准格式暴露 API 的方式，还有引导等功能，只是客户端支持还不多。核心的 “标准化暴露 API” 非常有用。
我认为更稳定的是偏底层的东西：
可观测性：不管智能体长什么样，你都想知道内部发生了什么；
评估：不管智能体长什么样，你都需要某种方式度量它；
沙盒：非常好的例子，底层基础设施。如果智能体不写代码，沙盒没用；但趋势是，所有智能体最终都会写代码；
部署：智能体一定是长时间运行、有状态的，支持长时有状态应用的部署平台永远有用。
我们内部很清楚：LangChain、LangGraph、Deep Agents 这三个开源项目同时存在，本身就说明这个领域变化极快。但除了开源之外，我们构建的所有东西，都尽量保证是底层通用能力，无论上层脚手架怎么变都有用，并且能兼容任何智能体框架。
主持人：既然你提到了沙盒，我们现在又在 Daytona Compute 大会现场，Daytona 又是沙盒领域的领先者，我们聊一下智能体的计算层。简单来说，为什么智能体需要沙盒？
Harrison Chase：在我看来，主要原因就是：编写并运行代码。我想区分一下文件系统和沙盒：文件系统只是接口，沙盒则提供代码执行环境。
如果智能体要写代码、运行代码，就必须用沙盒：
云端智能体对应的，就是 Daytona 这类沙盒。
主持人：从 LangChain 角度，你们和沙盒的交互方式是什么？
Harrison Chase： 有两种主流方式，各占 50% 左右：
启动沙盒，把智能体装进去，在沙盒内运行；
智能体在沙盒外运行，把沙盒当作工具调用。
Cloud Code 这类产品更偏向第一种：设计初衷就是在本地系统运行，所以大家通常启动沙盒再装进去。而全新设计的框架会更灵活。
主持人：这涉及安全问题吗？比如提示词注入，沙盒是防御手段吗？
Harrison Chase： 确实有安全价值。比如 Daytona 支持的一个关键点：代理模式。如果你在沙盒里放 API 密钥，LLM 能看到，就极容易被提示注入攻击 —— 攻击者可以让它忽略之前指令，把 API key 发出去。而沙盒外的代理层，可以在调用时自动注入 API key，沙盒内的智能体永远看不到密钥。这是安全与沙盒结合的一个非常重要的设计。
LangChain 生态：从开源工具到完整平台
主持人：接下来我们深入聊聊你们真正提供的产品和构建的东西。你能简单讲讲你的背景，以及最初为什么创办 LangChain，关键洞察是什么？
Harrison Chase：我的背景是统计和计算机科学。在这之前我待过两家创业公司：第一家是金融科技公司 Kensho，我在机器学习团队。那是我第一份工作，工程文化极强，我学到了太多东西。团队里有谷歌老兵、MIT 和哈佛物理博士，人才密度极高。第二家是 Robust Intelligence，我是二号员工。我们最早做对抗性机器学习，后来转向 MLOps 平台，专注 ML 模型的测试与验证。
2022 年夏秋，我打算离开，还没想好做什么。我参加了很多线下活动，当时 Stable Diffusion 很火，但有一小群人在用早期 LLM 做疯狂的事情。我发现了很多 通用模式。我一直喜欢做工具帮别人提高效率：在 Kensho 后期我做内部 MLOps，Robust 本身就是 MLOps 公司。
我当时并没打算创业，还在 Robust 上班，计划几个月后离职，花时间思考下一步。但我想：这是了解这个领域的好办法。我把这些通用模式放进一个 Python 包并开源，这就是 LangChain。大概一两个月后，我明显看到巨大机会，于是和联合创始人 Enkos 更紧密地合作，离职正式创办公司。我们继续做开源，同时开始做商业化产品 LangSmith，思路来自 Robust 做的测试与验证 —— 我们意识到，这对机器学习很重要，对智能体会更加重要、也完全不同，所以我们必须做。
主持人：我们来梳理一下现在的平台和各个组件。你刚开始做的 LangChain 是 0.0 版本，现在是 1.x 版本，两者有什么区别？再和 LangGraph、Deep Agents 对比一下。
Harrison Chase：早期 LangChain 本质是 抽象层：对语言模型、检索器、各类组件做抽象，再加上把它们拼起来的流程手册。比如 RAG 链，五行代码就能跑，极大降低入门门槛。但我们很快发现：要上线生产环境，用户需要更多内部可控性。模板化提示词、固定假设，在快速变化的领域里不够灵活。
于是我们做了 LangGraph：
我们把 LangGraph 看作智能体运行时。当用户从探索走向生产，我们越来越推荐基于 LangGraph 构建。
LangChain 最早的理念就是 “让 LLM 循环运行 + 调用工具”，但早期不好用。2025 年我们发现这个模式越来越可靠，于是 LangChain 1.0 彻底聚焦于此，在 LangGraph 之上重构，只保留 create_agent 核心函数：循环运行 LLM、调用工具，极度中立、可高度配置。
Deep Agents 则是 开箱即用的完整框架：内置规划工具、文件系统、全套能力。如果你想自己造框架，用 LangChain 和 create_agent；如果你想直接用成熟框架，用 Deep Agents。
主持人：那 LangSmith 呢？主要专注可观测性吗？
Harrison Chase：LangSmith 的核心是 可观测性增强版。构建智能体和传统软件最大的不同是：运行之前，你根本不知道它会做什么。原因有两个：
智能体输入极广，理论上无限；传统软件只有按钮等限定输入；
LLM 是非确定性的，对提示词微小变化极度敏感。
这使得可观测性比传统软件重要得多，也不同得多：它和生命周期其他环节深度绑定。运行轨迹可以变成测试用例，支撑在线评估、分析等。
LangSmith 里最大的部分就是 observability++，围绕：
run：单次 LLM 调用
trace：一组 run 的集合
thread：多轮会话整体
除此之外，我们还有应用部署平台，以及最近推出的无代码平台，可以无代码创建智能体，但核心依然是 observability++。
主持人：评估这个话题很有意思。现在有一个趋势，比如 Co-Work 里，终端用户可以评估系统并提供反馈。你怎么看待为企业构建合适框架，让智能体能按用户维度持续进化？
Harrison Chase： 评估、记忆、提示词优化之间有非常有趣的关联。它们的逻辑都很像：智能体做某事 → 有奖励 / 评估函数 → 更新某种配置 / 参数。
目前这三件事还相对独立，但未来会深度融合。我们在无代码智能体里内置了记忆，并且很兴奋把记忆和评估绑定：当记忆修改内容时，自动添加评估用例，防止未来退化。
主持人：无代码平台让任何人都能构建智能体，同时也要支持极专业用户做高精度定制。你怎么把握合适的抽象层次？
Harrison Chase：Deep Agents 框架的妙处在于：配置框架本质就是写提示词、加工具、加技能 —— 这些都可以无代码完成。工具确实需要写成代码并通过 MCP 暴露，但一旦有了 MCP 服务器，剩下都能无代码操作。所以从框架到无代码的跃迁并不大。你还可以加中间件做深度定制，但影响最大的部分 —— 提示词、工具、技能 —— 都能在 UI 里完成。
主持人：你们刚刚完成 1.25 亿美元新融资。接下来要做什么？愿景和产品路线图是什么？
Harrison Chase： 说实话，在这个领域我们甚至没有一年期路线图，能看清一个月就不错了。重点方向很明确：
可观测性增强版是核心支柱，我们要做到业界顶尖，同时打造完整平台。
主持人：如果框架不断收敛，每个智能体都具备代码执行、文件系统、子智能体、MCP，模型也越来越强，那么对于 AI 开发者来说，差异化到底在哪里？
Harrison Chase： 我认为 绝大多数差异化，在于指令、工具和技能。也就是你把行业流程知识编码成自然语言，交给智能体，再配上它可以调用的工具与技能。
作为 AI 构建者，你当然应该学习框架、技能这些东西，但不必过度绑定 —— 因为构建方式会变。但 领域知识、专属工具、业务流程指令，这些是不会变的，这才是真正的壁垒。
参考链接：
https://www.youtube.com/watch?v=rSKh6bVuVZI
