LangChain与Harness之争：为何51万行代码难被AI模型替代

最近AI工程圈有个话题热度不低。LangChain的联合创始人兼CEO Harrison Chase在X上发了一篇长文，核心观点直指Agent（智能体）发展的一个关键矛盾：记忆（Memory）与承载它的“马具”（Harness）深度捆绑。他直言，想要获得真正自主、个性化的智能体验，开放且与模型提供商无关的记忆和“马具”才是正途。这篇帖子迅速发酵，阅读量轻松突破140万，也引来了不少行业大佬的围观和讨论。

谷歌云AI总监Addy Osmani转发并评论，强调了“Agent Harness是记忆层的关键”，并认同“记忆让Agent随时间变得更聪明”。不过，另一边也有不同声音，Y Combinator总裁Garry Tan就认为，记忆和Harness的耦合未必那么深，Harness更多是读取而非拥有记忆。

那么，Harrison Chase到底抛出了哪些值得深思的观点？简单来说，他描绘了这样一个逻辑链条：Agent Harness已成为主流构建方式且会长期存在 → Harness与记忆息息相关 → 如果你不拥有Harness，就等于失去了对记忆的控制 → 而记忆，恰恰是产生用户粘性和平台锁定效应的核心。真相究竟如何？我们不妨深入看看他的论述。

Agent Harness是构建Agent的方法，且不会消失

回顾过去三年，构建Agent系统的“最佳实践”几乎每年都在变。ChatGPT刚问世时，大家玩的是简单的RAG链。随着模型能力提升，更复杂的流程编排（比如LangGraph）成为可能。再到后来，模型能力又一次飞跃，催生了一种新型的脚手架——Agent Harness。

什么是Agent Harness？你可以把它理解为一套让大模型（LLM）能稳定、高效调用工具并与外界交互的“控制系统”。像Claude Code、Deep Agents、Pi（支持OpenClaw）等都是典型的例子。它们负责协调、规划、管理工具调用，确保Agent能完成任务。

有个常见的误解是，随着模型越来越强，这些外围的脚手架功能会被模型本身“吸收”掉。但Harrison认为，这不会发生。真实情况是，2024年需要的某些脚手架可能过时了，但总会有新类型的脚手架出现，填补更复杂的交互需求。为什么？因为从定义上看，Agent就是一个需要与工具、数据源交互的LLM，只要存在交互，就需要一个系统来协调。这就是Harness存在的根本。

证据呢？当Claude Code的源代码泄露时，人们发现其代码量高达51.2万行。这些代码本质上就是Harness。即便是打造了世界顶尖模型的Anthropic，也在Harness上投入了巨资。再比如，当网络搜索等功能被集成进OpenAI或Anthropic的API时，它们并非“模型的一部分”，而是通过API背后轻量级的Harness，利用工具调用来协调模型与搜索服务的交互。

Harness与记忆息息相关

这就引出了第二个关键点：Harness与记忆密不可分。Sarah Wooders曾写过一篇精彩的博客，题为“记忆不是插件（它是Harness）”，Harrison对此深表赞同。

很多人可能觉得，记忆可以是一个独立的服务，脱离具体的Harness存在。但在现阶段，这不太现实。Harness的一个核心职责就是管理上下文，而记忆，本质上就是上下文的一种形式。

Sarah打了个生动的比方：要求把记忆插入Agent Harness，就像要求把“驾驶”功能插入汽车一样。管理上下文（包括记忆）是Harness的核心能力和职责。短期记忆（比如对话历史、大型工具调用的结果）由Harness处理；长期记忆（跨会话的记忆）也需要由Harness来读取和更新。

Harness与记忆的关联体现在方方面面：如何加载AGENTS.md这类配置文件？技能元数据如何展示给Agent？Agent能修改自己的系统指令吗？在上下文压缩时，什么被保留、什么被丢弃？交互记录是否被存储并可查询？记忆的元数据如何呈现？当前工作目录、文件系统信息暴露多少？

目前，记忆这个概念本身还处于“婴儿期”。行业共识是，长期记忆通常不是最小可行性产品（MVP）的首要考虑。你得先让Agent能跑起来，再考虑个性化问题。这意味着整个行业都还在摸索记忆的最佳实现方式，尚未形成通用、明确的抽象层。因此，独立的记忆系统或许在未来有意义，但现在还为时过早。正如Sarah所言：“归根结底，Harness如何管理上下文和通用状态，是Agent记忆的基础。”

如果你不拥有Harness，你就不拥有记忆

既然Harness与记忆深度耦合，那么一个直接的推论就是：控制Harness，就等于控制了记忆。

如果你选择使用一个封闭的Harness，尤其是那些隐藏在私有API背后的Harness，那么你实际上放弃了对记忆的所有权。这分几个层次：

中度糟糕的情况：如果你使用有状态的API（比如OpenAI的Responses API或Anthropic的服务端上下文压缩），你的对话状态就存储在他们的服务器上。一旦你想换用其他模型并恢复之前的对话线程，几乎不可能。

更糟糕的情况：如果你使用完全封闭的Harness（比如某些不开放源码的Agent SDK），它如何与记忆交互对你就是个黑盒。也许它在客户端生成了一些“产物”（Artifacts），但格式是什么？Harness如何使用它们？你一无所知，自然也就无法将记忆迁移到另一个Harness上。

最糟糕的情况：整个Harness，包括长期记忆的存储和处理，都完全隐藏在API之后。这时，你对记忆的所有权和可见性几乎为零。你不了解Harness的工作原理，更不拥有这些记忆数据。它们可能通过API部分暴露，也可能完全没有，你没有任何控制权。

当人们说“模型将吸收越来越多的Harness功能”时，其潜台词往往是：这些与记忆相关的核心部分，将被收进模型提供商自己的API内部。这极其令人担忧，因为它意味着记忆将被锁定在单一的平台和模型中。

模型提供商有巨大的动力这么做，而且已经开始行动了。Anthropic推出的Claude Managed Agents，几乎把所有东西都放到了API之后，锁死在自家平台内。即使整个Harness没有完全封闭，提供商也有动力将越来越多功能内移。例如，尽管Codex是开源的，但它生成的压缩摘要是加密的，在OpenAI生态系统外无法使用。

他们为什么这么做？因为记忆太重要了，它能产生仅靠模型本身无法实现的“锁定效应”。

记忆很重要，它会产生锁定效应

尽管记忆技术尚处早期，但其战略价值已不言而喻。正是记忆，让Agent能够随着与用户的每一次交互而变得更“聪明”，从而构建起强大的数据飞轮。它使得Agent能为每个用户提供个性化体验，并逐渐适应其独特的需求和使用习惯。

试想，如果没有记忆，任何能访问相同工具集的人，都可以轻易复制出一个功能相同的Agent。但有了记忆，你就积累起一个专有数据集——包含了用户交互历史和偏好的宝贵资产。这个数据集，正是你提供差异化、且日益智能的体验的护城河。

到目前为止，更换模型提供商还算相对容易。他们的API大同小异，调整一下提示词就能适配。但这完全建立在它们是“无状态”的基础上。一旦引入状态（即记忆），切换成本就会急剧上升。因为这些记忆至关重要，一旦离开原有平台，你可能就再也无法访问它们了。

Harrison分享了一个亲身经历：他内部使用的一个邮件助手，是基于他们自己的无代码平台Fleet中的模板构建的，平台内置了记忆功能。几个月用下来，助手积累了大量关于他偏好和习惯的记忆。几周前，这个Agent不小心被删除了。他尝试用同一个模板新建一个，但体验一落千丈——他不得不从头开始，重新教导助手所有的事情。

这次事故的唯一“好处”，是让他真切体会到记忆的强大和它带来的用户粘性。失去记忆，Agent就失去了灵魂。

开放记忆，开放Harness

基于以上逻辑，结论呼之欲出：记忆必须是开放的，应该由构建Agent体验的人真正拥有和控制。只有这样，你才能建立起一个完全属于自己、可以自由支配的专有数据集。

同样，承载记忆的Harness，也应该与模型提供商解耦。你应该拥有选择权，能够根据具体场景，自由选用最合适的模型，而不必担心被锁定。毕竟，模型提供商有足够的动机，通过记忆来构建他们的护城河。

这场关于记忆与Harness的讨论，或许正是AI Agent从“玩具”走向真正“生产力工具”过程中，必须正视和解决的关键命题之一。它关乎控制权，更关乎未来智能体验的多样性和开放性。