红杉对话LangChain创始人：2026年AI告别对话框，步入Long-Horizon Agents元年
编译：Arlene、Haina
Sequoia Capital在2026: This is AGI这篇文章中断言AGI就是把事情搞定（Figure things out）的能力。
如果说过去的AI是Talkers的时代，那么2026年则是Doers的元年。转变的核心载体正是Long Horizon Agents（长程智能体）。这类Agent不再满足于对上下文的即时回复，而是具备了自主规划、长时间运行以及目标导向的专家级特征。从Coding到Excel自动化，原本在特定垂直领域爆发的Agent能力，正在向所有复杂任务流扩散。
作为LangChain的创始人，Harrison Chase一直处于这场变革的最前沿。本文编译了Sequoia Capital Sonya Huang & Pat Grady访谈Harrison Chase的最新播客。作为站在Agent基础设施最前沿的先行者，Harrison揭示了为什么Agent正迎来其爆发的“第三个拐点”。
核心Insight提炼：
• Long Horizon Agents价值在于为复杂任务提供高质量初稿；
• Agent的突破需要围绕模型构建的、有主见的（Opinionated）软件外壳（Harness），文件系统权限将成为所有Agent的标配；
• 通用Agent可能就是一个Coding Agent；
• Traces成为新的 “Source of Truth”；
• 相比于通用模型，一个经过长时间磨合、内化了特定任务模式与背景记忆的Agent，将形成极高的moat；
• 理想的Agent交互是异步管理和同步协作的统一。
01.
Long-Horizon Agents的爆发
Sonya Huang： 你怎么看Long Horizon Agents ？对于红杉最新的文章，哪些观点是你同意的，哪些你不同意？
Harrison Chase： 我同意它们终于开始真正work了。让LLM在一个循环中运行并自主决策，这一直是Agent的核心理念。AutoGPT就是这样，它之所以能激发人们的想象力，是因为LLM在循环中能自主决定下一步做什么。
问题在于，当时的模型不够好，周围的Scaffolding和Harness也不够好。 现在模型变强了，我们在过去几年也学到了什么是好的Harness，所以它们开始真正起作用了。 我们最先在Coding领域看到这一点 ，这也是最快起飞的地方，并正在向其他领域扩散。
AutoGPT是2023年爆火的开源自主AI agent框架（最早的“让GPT自己思考、规划、执行”的经典实现），通过让LLM反复自我提示（think → plan → act → observe的循环）来完成复杂多步任务。
Scaffolding指围绕语言模型构建的辅助性代码结构或框架，用于引导模型输出、管理流程或处理输入输出，但不具备复杂的自主规划能力。
Harness即包裹模型、管理Context、处理文件I/O并执行工具调用的软件环境，通常包含预设的规划工具、环境交互能力和最佳实践，旨在让模型更稳定、高效地执行复杂任务。
虽然你仍需给Agent下达指令、提供合适的工具，但它能运行的时间越来越长。所以Long Horizon这个说法非常贴切。
Sonya Huang： 你最喜欢哪些Long Horizon Agents的例子？
Harrison Chase： Coding领域的例子最多，我也用得最多。 除此之外，AI SREs是个很好的例子。比如Sequoia投资的Traversal，他们的AI SRE可以处理长时程任务，深入挖掘日志。 Research也是个很好的场景，因为它最终产出的是初稿。
AI SREs，AI站点可靠性工程师，利用人工智能技术自动监控、诊断和修复软件系统故障的智能体，能处理日志分析和系统维护等任务。
Traversal一家专注于打造AI SRE的初创公司，旨在利用AI自主解决复杂的软件工程和运维问题。
Agent的问题在于达不到99.9%的Reliability ，但能做大量工作，并且能在更长的时间跨度上工作。 需长时间运行，产出某项任务初稿的场景 ，就是Long Horizon Agents的杀手级应用。
Coding是个典型。你通常提交一个PR（Pull Request），而不是直接推送到生产环境，除非用户在Vibe Coding。这方面变得越来越好。AI SREs也是同理，通常是把结果提交给人审查。 生成报告也是，没人会直接发给所有粉丝，总得自己先看一遍、改一改。
我们在金融领域已经看到了很多这类应用，这里潜藏着巨大的机会。以前Agent只做一线回复，现在有了像Klarna这样的新案例，走的是人机协作路线。当一线AI搞不定要转人工时，系统不会直接把烂摊子丢给人，而是有一个在后台运行的Long Horizon Agent生成一份前因后果的总结报告，再移交给人工。
Klarna是一家提供先买后付的支付公司。
所以，核心用例就是这些围绕初稿概念的场景。
02.
从通用框架到Harness架构
Sonya Huang： 关于Why now，多大程度上是因为模型本身变得足够强大，又有多少归功于在Harness方面做了巧妙的工程设计？深入探讨前，简单界定一下你眼中的Harness和模型的区别，以及Agent的具体构成。
Harrison Chase： 好的，我得先引入Framework这个概念。早期我们就是这样定义LangChain的，它本质上是Agent Framework。但进入Deep Agents时代后，我更愿意称之为Agent Harness。
Deep Agents是LangChain推出的下一代自主Agent架构，基于LangGraph，内置Planning、文件系统、Sub-agent生成能力。
LangGraph是LangChain团队推出的一个低级、可控的图状工作流框架。
常有人问这三者的区别：
• 模型：显然就是LLMs，输入Token，输出Token。
• Framework：围绕模型建立的抽象层，让切换模型、添加工具、Vector Store和Memory变得容易。它是Unopinionated（无预设）的，价值在于抽象。
• Harness：更像是开箱即用的。谈到Deep Agents时，Harness默认内置了Planning tool，它非常Opinionated（强预设），认为这就是做事的正确方式。
我们需要做压缩。Long Horizon Agent运行时间很长，虽然Context Window变大了，但终究有限。到某个时间点，必须对Context进行压缩。问题是，怎么压？这方面有很多前沿研究。 我们提供给Agent的另一套关键能力是文件系统交互 ，无论是直接读写还是通过Bash脚本。
其实很难单纯归功于Harness或模型，因为现在的模型本身也是在大量此类数据（代码、CLI）上训练出来的。 这是一种共同进化 。若回到两年前，我不认为我们能预知基于文件系统的Harness会是终极方案，因为那时的模型还没针对这些场景充分训练。
所以这是多因素叠加：模型确实变强了，特别是Reasoning Models功不可没；但同时也因为我们搞清楚了围绕压缩、Planning及文件系统工具的一系列Primitives（原语）。是这两者的结合带来了突破。
Sonya Huang： 记得在我们第一期播客里，你把LangGraph形容为Agent的认知架构。这是否是理解Harness的正确方式？
Harrison Chase： 没错。我们在LangGraph之上构建Deep Agents。它是LangGraph的一个特定实例，但非常有主见，也更通用。
早期我们讨论过通用vs专用架构。现在的趋势是，以前那些为了约束模型而写在LangGraph里的特异性，正转移到工具和Instructions中。复杂度没有消失，只是变成了自然语言。因此，Prompting、编辑Prompt甚至自动优化Prompt成了核心，而Harness本身的结构保持得相对固定。
Sonya Huang： Harness层面最难攻克的是什么？你认为个别公司真的能在Harness Engineering上建立壁垒吗？在这方面你欣赏谁？
Harrison Chase： 说实话，目前Harness Engineering做得最好的都是Coding公司。这是技术腾飞的领域。比如Claude Code，它之所以如此火爆，很大一部分原因在于它的Harness设计。
Pat Grady： 这是否意味着Harness更适合由基础模型厂商自己构建，而不是第三方创业公司？
Harrison Chase： 很难说。我想提到的另一家公司是Factory，还有Amp，它们都是Coding类公司，并且都有非常出色的Harness。
Factory是一家专注于构建全栈AI软件工程师的公司，能自动完成从需求到上线完整SaaS应用的开发，强调agent的自主性和生产级代码质量。构建的名为Droid的Agent位居Terminal-Bench 2.0榜首。
Amp Code是一家主打下一代AI编码体验的公司，提供极致智能的代码补全、编辑和生成能力，在代码理解和多文件编辑上表现突出。
这事各有利弊。Harness某些部分确实与模型，或者说与模型家族，深度绑定。比如Anthropic的模型在某些特定工具上有过Fine Tuning ，而OpenAI则在另一些工具上微调过。就像不同的模型需要与Prompt适配，现在Harness也是同理，针对不同模型家族需要微调。但 共性依然存在，比如都基于文件系统。
这其实是个很有趣的现象。现在几乎每个AI Coding公司都在造自己的Harness。目前主流Coding Benchmark，如Terminal-Bench 2.0，会将经过Harness的Agent与模型分开列出。同一个模型的性能波动巨大，Claude Code在榜单上也未必总是第一。这说明模型厂商未必天生更擅长此道。 只要深刻理解模型原理，第三方开发者完全能在Harness层面挖掘出巨大性能提升。
https://www.tbench.ai/leaderboard/terminal-bench/2.0
Terminal-Bench 2.0是目前AI agent终端/命令行能力的最硬核开源基准榜单，由tbench.ai团队维护，包含89个精心挑选的真实终端任务（涉及编译代码、训练模型、搭建服务器、生物/安全/游戏等领域复杂多步操作），专用来严苛评估AI agent在真实沙箱终端环境下的端到端问题解决能力、工具使用和长期自主性。
Sonya Huang： 你认为让Harness高效运转的关键是什么？榜单头部玩家做对了什么？
Harrison Chase： 首先是对模型训练数据的深刻理解。OpenAI的模型在Bash命令行上训练得极多，而Anthropic似乎针对文件编辑工具做过专门训练。顺应模型的特性非常重要。
其次是压缩。当任务周期变长、Context Window满载时，如何取舍是巨大的挑战，也是Harness的核心价值。再者是Skills、MCPs和Sub-agents的运用。目前模型本身并未内化太多Sub-agents能力，主要靠Harness调度。比如在我们的Harness中，主模型调用Sub-agent时，需传递完整信息，并指示Sub-Agent何时输出最终结果。
我们见过一些失败案例：Sub-agent做了一堆工作，最后只回一句“见上文”，主模型没有收到任何有效信息。协调组件工作的Prompting至关重要。看看现在的开源Harness，System Prompt动辄几百行，就是为了解决协同问题。
Pat Grady： 聊聊演变路径。你一直处在让模型落地现实世界的配套基建最前沿。
若简化看过去五年的拐点，一是Pre-training （ChatGPT）；二是Reasoning （OpenAI o1）；最近伴随Claude Code和Opus 4.5级别模型，迎来了Long Horizon Agents的第三个拐点。
在你构建的世界里，拐点是否不同？从认知架构到Framework再到Agent Harness，核心跃迁是什么？
Harrison Chase： 我认为可以分为三个时代：
第一阶段是早期，即LangChain刚起步时。模型还是原始的Text-in/Text-out，甚至没有Chat模式，没有Tool Calling，没有推理能力。大家能做的就是简单的Prompt或链式调用。
第二阶段是模型实验室开始引入Tool Calling，试图让模型学会思考和规划。虽然当时的效果不如今天，但已经足以做决策了。这时自定义认知架构开始流行，你需要显式地写代码问模型：“现在该做什么？”，然后按分支走。这更像是在模型外面搭Scaffolding 。
第三阶段的拐点，大概发生在2025年六七月份。Claude Code、Deep Research、Manus集中爆发。底层架构其实一样，把LLM放在循环里运行。但它们巧妙地运用了Context Engineering ，包括围绕压缩、Sub-Agent、Context Skills的一切。核心算法没变，但Context Engineering变了。这让我们意识到“这和以前不一样了”，于是我们开始做Deep Agents。
对Coding社区来说，随着Opus 4.5发布或大家寒假狂用Claude Code，这种感觉尤为强烈。11、12月发生了巨大的Vibe Shift。大家意识到，把难题扔进去，Long Horizon Agent真的能搞定。那一刻，模型足够好了，我们从Scaffolds时代正式迈入Harness时代。
03.
Coding Agent是通用AI的终局形态吗
Pat Grady： 接下来会怎么发展？
Harrison Chase： 我也想知道。但我确信， “让LLM在循环中运行并自我编排的算法，让它自己决定把什么拉入Context ” 这一极简且通用的Agent核心理念，终于实现了。
未来的手工Scaffolds会越来越少。目前像压缩这类操作还很依赖Harness作者的手动设计。Anthropic正尝试让模型自主决定何时压缩，虽然还没普及，但这可能是方向。
另一个重点是Memory。在长时程任务中，Memory其实就是长周期的Context Engineering。核心算法很简单：Run LLM in a loop。接下来的竞争点在于围绕它的Context Engineering技巧，或是像Anthropic那样把工程本身交给LLM，又或是引入新型Context数据。
我现在最大的疑问是，目前成功的Harness大多针对Coding。即使是非编程任务，你也可以辩称“写代码”本身就是极好的通用手段。
Pat Grady： 这正是我要问的。Coding Agents到底是一个子类别，还是说所有Agent本质上都应该是Coding Agents？因为Agent的工作就是让计算机干活，而代码是最好的指令方式。
Harrison Chase： 这是个大问题。我深信，构建Long Horizon Agent必须给它文件系统权限。
文件系统在Context管理上太有用了。比如压缩时，把原始消息存进文件，只留摘要在Context里，模型需要时再去查阅；或者返回巨大的Tool Call结果时，不要全塞给模型。把它存进文件系统，让它自己去查。其实这不一定需要真正的文件系统，也不需要它写代码。
我们有个虚拟文件系统的概念，底层由Redis等支持，稳定性更好。但显然，代码能做很多虚拟文件系统做不到的事。你没法在虚拟文件系统里运行代码，这时候写Script就非常有用了。
所有Agent是否最终都是Coding Agent也是我们目前思考的最多的问题之一。
04.
构建Long Horizon Agent vs构建软件
Sonya Huang： 构建Long Horizon Agent与构建传统软件有何不同？你在X上写了一篇很很好的文章，能否总结并描述当今的数据与代码开发栈？
Harrison Chase： 这值得深思。大家都说构建Agent不同于构建软件，但本质区别在哪？
几点看似显而易见，却很重要：
构建软件时，逻辑全写在代码里，可见可控。构建Agent时，逻辑不全在代码里，很大一部分来自模型。这意味着 你不能只看代码就推断Agent在特定场景下的行为，必须实际运行。 这就是最大区别。我们引入了非确定性黑盒系统，且它置于代码之外。
这对开发者意味着，想知道App干了什么，看代码没用，必须看它在现实中的行为。这也是为何LangSmith的Tracing最受欢迎。Tracing能复现Agent内部每一步。
LangSmith是LangChain生态的可观测性平台。
这与传统软件的Traces不同。软件通常只在报错时查日志。但在Agent开发中，人们从第一天起就用Trace。因为Agent循环运行，你根本不知道第14步的Context是什么，因为前13步可能拉取了任意东西。这又回到了Context Engineering。Trace揭示了Context内容，这至关重要。
软件的Source of Truth（单一事实来源）是代码；Agent的Source of Truth是代码 + Tracing。这意味着Trace成了你思考Testing的地方。 你更需要Online Testing，因为行为只有在遇到真实世界输入时才会涌现。
Trace正成为团队协作的支点。出问题时，大家不是说“去GitHub看代码”，而是说“看看Trace”。开源社区也是，用户反馈Deep Agents跑偏，我们会要LangSmith Trace而非代码。
还有一点，构建Agent更加Iterative。 软件是你设定好目标再迭代，发布前行为已知。 Agent在发布前行为未知。你有个大概，但没十足把握。为了让它达标、通过概念上的Unit Test，你需要更多迭代。
这也是为何Memory重要。Memory是从交互中学习。如果系统能自我学习，就减少了开发者手动修改System Prompt的频率。
Pat Grady： 我也很好奇。现有软件公司能活下来吗？类比当年本地转云部署，鲜有成功者。你认为这次能跨越吗？年轻创始人似乎更有白板优势。
Harrison Chase： 我们确实看到很多Agent团队成员更Junior，没有思维定势。
但在公司层面，数据仍然非常有价值。 如果你想Harness包含什么，就是Prompt、Instructions和工具。现有软件公司拥有所有数据和API。接入Agent，价值巨大。但另一部分是，关于如何处理这些数据的Instructions。这部分可能是全新的。以前这是人做的，你只提供工具，没尝试自动化。
像Rogo这样的垂直初创公司之所以有效，是因为很多Agent是由Knowledge驱动的。不是通用知识，而是关于如何执行Specific Patterns的知识。
Rogo是2025年爆火的Wall Street AI工具，一家专注于金融行业的安全生成式AI平台，能自动生成pitch deck、财务模型、IPO文件草稿、实时研究报告和洞察，目标是大幅取代/辅助junior banker的重复性手动工作。
所以，构建软件的人是构建Agent的合适人选吗？很多非常资深的开发者也采用了Agentic Coding，所以人才上是心态问题，同时可能确实有年轻化偏差；但公司层面，取决于数据。
05.
从人类判断到LLM-as-a-Judge
Sonya Huang： Trace是Agent开发的核心产物。还有其他的吗？特别是Eval方面。
Harrison Chase： 不算产物，应该叫组件。构建软件和Agent的另一个本质区别在于Eval。传统软件依赖程序化断言，但Agent做的是人做的事，评判需引入Human Judgment。这也是我们在LangSmith试图解决的：如何把人类判断带入Traces？
一种是直接引入人，比如Data Labeling公司，或者在LangSmith中也有Annotation Queues。人直接去标注Traces，比如给出自然语言反馈，包括“这很好”“这很坏”“这里应该这样做”等；有时人做的是纠正，把正确的步骤列出来。这取决于具体用例，模型公司做RL和应用公司构建Agent的需求可能不太一样。
另一种是建立人类判断的Proxies，即LLM-as-a-Judge 。 关键在于确保它与人类判断对齐。如果不对齐，评分器就是垃圾。 LangSmith有Aligned Evals，即先让人类标注一些Trace，系统基于这些标注构建一个LLM-as-a-Judge，进行针对性校准。LLM-as-a-Judge包含了几个不同层面。 大多数人在Evals中用它来给Trace打分，比如0到1分，或者0到10分。这是通用的做法。因为有些判断不需要Ground Truth，做法有离线做也有在线。
但另一个被忽视的领域是，在Coding Agents本身就能看到这一点。 Coding Agent工作过程遇到Error，随即纠正这个Error。这实际是在评判自己之前的工作。 我们在Memory中也看到了，Memory很大一部分就是反思Trace然后更新东西。
所以，无论是对自己的还是之前的会话，LLM有充分的能力反思Trace。我们在Evals、自动纠错、Memory中都看到了这一点。本质上，它们是同一回事。
Sonya Huang： 既然有了Trace和Eval，这个Eval是RL的Reward Signal？还是给工程师改进Harness的反馈？
Harrison Chase： 其实是给Agent工程师改进Harness的。我们有LangSmith MCP和LangSmith Fetch（一个CLI命令行工具）。这是大趋势。Coding Agents擅长用CLI。把CLI交给Agent，它就可以拉取Trace，诊断问题，自己修复代码。 这绝对是我们看好并支持的模式。 对于应用类公司，我对这个模式比对RL更看好。
Sonya Huang： 这听起来像是真正的Recursive Self-improvement。
Harrison Chase： 是的，但仍有Human-in-the-loop。如前所述，最理想的状态是Agent产出初稿，如修改了Prompt，然后人类进行审核，确保它不跑偏。
举个例子，我们推出了构建Agent的无代码工具， LangSmith Agent Builder。其有个很酷的功能是Memory。 目前它的工作方式是：当你与Agent交互时，如果说“你应该做Y而不是X”，它会修改它自己的Instructions，即编辑文件。 这就是自我改进。我们正计划增加每晚运行、查看当天Trace并更新自身状态的功能，即Sleep time compute。
LangSmith Agent Builder是LangChain团队在2025年底推出的无代码AI agent构建工具，目前已公测。它允许任何人只需用自然语言聊天描述需求（比如“帮我建一个能读Gmail、自动分类邮件并草拟回复的助手”），它就会自动生成、配置、连接工具、添加记忆和提示的完整agent，还支持从预置模板一键启动、快速迭代反馈、部署上线。
06.
未来的交互与生产形态
Sonya Huang： 未来呢？你谈了很多Memory。
Harrison Chase： 我非常看好Memory。让Agent自我改进很酷，但并非全场景适用。ChatGPT加了Memory，但我没怎么用，也没增加粘性，因为我去ChatGPT都是做One-off任务，如问代码、问美食、问旅行，彼此之间没关联。
但在Agent Builder里，你构建的是特定工作流。比如我的Email Agent，之前积累了很多Memory。后来我想迁移进Agent Builder，结果丢了旧Memory。哪怕Prompt和工具完全相同，新Agent体验也远不如旧的。如果不经长时间磨合，很难好用。
这就是为何我认为Memory是真正的Moat。我们到了LLM可以查看Traces并修改代码/指令的节点。问题在于如何安全、用户可接受地落地。在垂直场景下这绝对是大势所趋。
Sonya Huang： 你认为Long Horizon Agents的UI会如何演变？
Harrison Chase： 我认为需要Sync mode（同步模式） 和Async mode（异步模式）的结合。 Long Horizon Agent运行时间长，默认应该是Async的。像Linear、Jira和Kanban看板这类工具，甚至包括Email，对于构思如何管理这些Agent很有参考价值。
但对于大多数Agent来说，在某个节点，你一定会想切换到同步沟通模式。因为当Agent输出一份研究报告，你需要针对其中的错误给出反馈。
唯一要补充的是，现在的Agent不只是在说话，它们是在修改State，比如文件系统里的文件。你必须有办法可视化这些State，就像程序员离不开IDE里看代码。即便我用Claude Code跑完了任务，我依然会打开IDE去检查它到底改了什么。
Anthropic的Cowork做了一个极好的范式。你设置一个目录作为它的Workspace。这建立了一种非常清晰的心理模型：我们在一个Shared State（无论是本地文件、Google Drive还是Notion）上协作。
Hybrid Mode未来的交互形态就是这种Hybird Mode ：你异步管理一堆后台运行的Agent，但在关键时刻，你进入Sync Mode与它Chat，同时你们都在盯着同一个State看。
Sonya Huang： 这完全验证了你之前的Agent Inbox理念，要实现Sync Mode，Agent必须有一个能随时触达到你的入口。
Harrison Chase： 没错。一年前，我们发布了Agent Inbox第一版，当时的主打概念是Ambient Agents。Agents在后台运行，偶尔Ping你一下。
最初的版本没有Sync Mode，它Ping你，你回一句，然后只能干等它下次Ping你。这种体验非常破碎。因为很多时候，比如回邮件，用户需要的是极短时间的高频交互，而非切出去干等。
后来我们做了一个巨大的转向。用户点开Inbox时，会直接进入Chat界面。Chat本质上就是Synchronous的。我的判断是： Pure Async（纯异步）在目前是跑不通的。除非模型进化到完全不需要Human-in-the-loop纠错的程度。 否则我们注定要在Async和Sync之间来回切换。
Sonya Huang： 你怎么看Code Sandboxes？每个Agent都要有沙箱、CLI或Browser访问权限吗？
Harrison Chase： 好问题。 目前Code Execution显然比Browser Use更有用、更落地。
• 关于文件系统，我是坚定的 “File System Pilled”。我认为某种形式上，所有Agent都应该能访问文件系统。
• 关于Coding，我大概90%确信这是标配。对于Long Tail的复杂用例，Coding能力是无可替代的。
• 关于Browser Use， 目前的模型还不够好。虽然有一些很酷的尝试（比如给Coding Agent一个CLI来操作浏览器），但尚未成熟。
所以，Code Sandboxes绝对是未来的核心组件。