探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐

我是 Koji。最近大家都在讨论 Agent Harness，Agent 的上限是由 Harness 决定的。可是当我们聊到 Harness 的时候，我们到底在聊什么？

不久之前，Claude Code 的源代码被泄露，所以许多 Agent Harness 的关键模块也被完整地呈现了出来，成为了非常好的教学样本。今天我们请到的嘉宾是新璐。新璐是 Shell AI 的创始人，他们做了一个教程《Learn Claude Code》，这是一个在 GitHub 上现在已经有超过 5 万颗星的教程。

你好，新璐，欢迎来到《十字路口》。

Hello，感谢 Koji 老师的邀请。

我们这一期播客的目标，是希望能够让大家感觉到 Harness 不再是一个神秘或者玄乎的词，然后可以让大家明白，它其实就是软件工程的一些方法。我们照旧还是从快问快答开始。

请问新璐，你的年龄？

23。

毕业院校？

河南工业大学。

MBTI 和星座？

INTP，星座我不太关注。

一句话介绍一下自己的公司和产品。

我现在在做一个 1KB 的 Agent Computer 工具链，给开发者开发 Agent 用的开源工具链。

再用一句话介绍一下我们刚才提到的这个开源教程。《Learn Claude Code》是什么？

Claude Code 是我们认为最好的 Agent Harness。所以我们想，既然要学 Agent Harness，那干脆做一个资料仓库来解析 Claude Code Agent 的设计模式。

那咱们现在的融资情况呢？

我们刚刚完成了 300 多万美元的融资。

目前的团队规模？

团队非常精悍，主力其实就是我，然后我有两个实习生。

收入和利润呢？

新的创业方向刚开始，还没有收入。

一句话介绍一下创业前在做什么？

我就是在一些大厂和研究院做 AI Infra 相关的工作。

如果今天新璐你要用一句话，向一个完全没有听说过 Harness 的人介绍 Harness，你要怎么说？

1. Harness 不是黑箱

模型以外都是 Harness。我会倾向于把模型比作一个聪明的大脑，但是它没有身体和手脚的情况下，只能思考，对吧？没办法行动。

Agent 的上限来自 Harness 的设计，你认可这句话吗？以及为什么 Agent 的上限不是来自模型智能的提升？

我对这句话赞成一半。首先，Agent 的智力上限提升，肯定还是模型层面的发展，因为 Agent 其实就是一个模型，模型越聪明肯定越好。

我们看到现在其实大部分模型的智力也都比较够用了。把模型比成人的话，我们的智商在 120 到 170 之间。但是我们可以通过健身、学舞蹈、修习武术，或者穿上机甲来作业，让自己变得更加强大。

这个比喻还挺有意思的，机甲就是 Harness。

我觉得它极大地扩充了我们的能力。

我们一开始也提到《Learn Claude Code》这个教程，在 GitHub 上有超过 5 万颗星。大概是什么时间点，你开始写这个教程的？

其实应该是 9 个月前了。

当时是出于什么考虑，想要写这么一个教程呢？

2. Agent 原生范式逐渐清晰

我们当时的想法就是，Claude Code 是非常强大的。你只要给 Claude Code 套一个网页，对吧？其实应该会得到一个非常强大的 Agent 产品。

所以我们就可以做给开发者用的工具链。但是开发者可能比较熟悉过去的 LangGraph、LangChain 这种基于 Prompt、Node 和 Flow 的方法，有点像派系之争。

每次我跟大家说这一点的时候，很多人可能不太相信：不套 Harness，可能就叫 Agent Framework，或者 Agent Runtime。他们会觉得很多地方可能不太好控制，所以更喜欢加上很多 Prompt 节点，自己去流转和控制，成本又低又可控。

所以我觉得这是一场思想范式的争论。我们当时做这个资料然后放出去，其实也是在指导我们构建 Code Agent 的心法。

所以你会认为 LangChain、LangGraph 这样构建 Agent 的框架已经彻底过时了吗？它们没有任何用武之地了吗？

像 Prompt Flow 这种基于 Prompt 提示词节点做流转和控制的方法论，可能在未来的 Agent 开发过程中会越来越不适用。

然后，基于 Claude Code 这种 Agent-native 的方法和思想——也就是 Agent 即模型、模型即 Agent——去做事情，包括被 Claude Code 这一套范式，会越来越清晰，也会被更多人采用。

3. Managed Agents 改变门槛

在我们录播课的前几天，Claude 正好推出了 Managed Agents，也就是把它自己做 Agent Harness 的这一套开发出来给大家用了。

而且更早之前，它的源代码也泄露了。既然现在比如说我要开发一个 Agent，就可以直接用 Claude Managed Agents，那大家还有必要自己搭 Harness 吗？甚至还有必要了解 Harness 的细节吗？

一个 Agent 开发工程师会需要的。我认为，如果你不了解 Harness，你做出来的产品会缺乏灵魂，也缺乏进一步迭代的空间。

但这就像云服务器一样。云服务刚出来的时候，可能工程师也会说，不能直接调它的 API，我们也要去搞明白服务器各个方面的 Infra。但到后来你会发现，其实 99% 的工程项目根本不需要了解这一层。

所以我想，在 Agent Harness 这个层面会不会也是一样？我们今天虽然还没开始聊 Harness，但这期播客就是要讨论 Harness、让大家学习 Harness。会不会有一天其实根本不需要学了，大家直接用 Claude Managed Agents 的服务就够了？

从整个推演角度来看，肯定未来会有那么一天。就像大家今天开发很多全栈的外部应用，都有 Next.js 这个框架，但你不会知道 Next.js 里面怎么设计和工作的，它的原理是什么。大部分人可能不关心这一层，直接开箱即用去开发就好了。

那么以后的 Agent Harness，随着它迭代和收敛以后，大概率也会回到这一层。两三年以后，它可能成为一个非常清晰的、大家开箱即用来做这件事情的工具。

但在这个过程中，我们现在处于一个技术周期。大家创业也好、做产品也好，本质上都是在享受技术周期里的红利变化。你还是要自己拥抱技术周期的变化，知道里面在变的是什么。

现在都是什么人在学 Agent Harness？

我觉得偏向于自己在构建和开发 Agent 产品的人居多，不管是大厂里面的相关团队，还是外面的创业公司。

你觉得产品经理有必要了解 Agent Harness 吗？

我今天对产品经理会提出一个质疑：我觉得今天的产品经理，跟过去的产品经理其实已经不是同一种产品经理。

今天我们处在技术变化周期内，我们所做的一切产品，本质上都是在吃技术周期变化的红利。所以如果你自己都不了解这个技术周期变化的内核和本质到底是什么在变，你很难构建出一个产品，去贴合这种变化、吃掉它的红利。

以前的产品经理可能画一画好的 UX、UI，但今天我觉得，我们本质上是要把技术进步的红利应用在某个场景和领域上。所以你应该同时懂两者：一者是场景需求和痛点，另一者是技术到底在发生什么变化。

那我们再回到 Agent Harness。当我们聊 Agent Harness 的时候，一般来说，新璐你会把它再拆成几个部分吗？

4. Harness 分为三层

我会倾向于把它拆成 3 个部分。

第一层，是给模型提供执行能力的一层。简单来说，CLI 也好，包括你写代码去注册的那些工具，以及通过 MCP 扩展的工具，这些统一都是给模型提供 Action 能力。

第二层，我会更倾向于叫上下文，也就是状态这一层。比如模型要去工作，它是不是需要有 System Prompt、Skills 和 Memory？包括模型的上下文窗口不是无限的，很多任务其实会超过模型的上下文窗口。

它是不是需要有一些 Offload？下一轮相当于还是那个 Agent 在工作，但其实已经是一个新的模型窗口，装上一些初始化上下文，让它继续上一个窗口正在进行的工作。它有点像一个新的 Agent，那它要怎么接上一个 Agent 交接给它的工作，这里面会有很多上下文和状态的问题。我觉得第二层归为上下文环境层会更好。

第三层，可以归为对 Agent 的上层管理。这个管理也会分成两个方面。

一个是，如果你今天面对的对象不是一个 Agent，而是一百个 Agent 呢？就像一家公司有 100 号员工，你怎么去组织和协调他们，按照某种组织架构、某种协作方式和传递顺序，把一个复杂的事情解决掉。

第二个方面，是针对这一百个人，每个人都有不同岗位的访问权限。这里面也会有很多关于权限治理、信息提供和隔离的问题。

所以这 3 层，一个是执行能力层，一个是上下文环境层，还有一个是治理、编排，也就是管理层。

要不要用一个例子，把这 3 层串起来？一个具体的 Agent 任务，它背后的 Harness 这 3 层是怎么发挥作用的？

之前有一个知名的例子：用两周时间协调大量 Agent，从零到一构建了一个 C 编译器。它通过非常多的 Agent 交替完成任务，迭代着把这个任务完成了。我觉得这是一个很好的案例。

首先，我们说 Agent 的最底层是一个模型，对吧？模型就像大脑和心脏一样，要去驱动整个任务的完成。它要有 Action 能力，所以至少要给它配置类似文件增删、读写、搜索等工具能力，这些就是 Action 能力，也是我说的 Harness 第一层——给模型提供的能力。

这样模型才有机会去写代码，创建文件，修改它前面创建过的文件。

第二层是上下文状态层。模型是不是要知道自己现在处在一个什么样的环境中工作？当前路径是什么？上面安装了哪些依赖？已经写好的文件夹结构是什么？包括 Git 信息，这些它都需要知道。

而且它的模型上下文窗口非常容易被填满。我们知道，一个 C 编译器是一个很大、很大的工程量，不可能在一个模型的上下文窗口中直接做完。所以它需要有上下文卸载策略。

上下文窗口满了以后，下一个 Agent 再去工作，它要重新读一下：我当前的环境信息是什么，前面代码已经写到哪里了，接下来要进行什么？在这一轮生命周期里做到某个阶段之后，它再写一个类似的文档，把当前的上下文状态交给下一个 Agent。

这样依次接力，最后把整个 C 编译器写完。它不是一个单纯的 Action 能力层就能完成的，还是需要上下文环境。

第三层就是编排和治理层。如何指导这些 Agent 之间进行传递和委托，包括写代码 Agent 和测试 Agent 之间的关系。

这个任务中的每个环节一定都是串行的吗？我只能让一个 Agent 接着一个 Agent 去完成吗？是不是有很多模块可以并行写，同时有多个 Agent 做这个任务？它们之间的协调关系是什么？这会涉及编排的问题。

还有，不同 Agent 的权限应该怎么样？做测试的 Agent 是不是应该有测试环境和测试工具，以及对应的权限？它不应该在测试的时候对着代码一边测一边修改，说“我测不过，把那里修改一下就好了”，然后一直去 Hack 这种 Pass，对吧？

所以这里面会有很多权限治理，以及上层协调关系和编排的问题，这属于第三层。

过去大家做一个 Agent 的时候，说到的这 3 层都要靠手搓。但现在慢慢地，可能已经有一些被封装成可以直接调用的 Infra 工具了。你认为现在有哪些已经封装得比较好，哪些目前仍然需要手搓？

这 3 层到目前为止，我并没有觉得有封装得非常好的。因为我们觉得这个范式变化太快了：从 2022 年底 ChatGPT 的发布，到现在类似 Claude Code 这一套背后的 Agent 智能体模型范式，再到模型被训练完成长程任务，其实最近半年左右才开始出现。

开源社区我也观察了很多，但没有看到太让我满意的这一层。所以这也是我们自己在做这一层的原因。

那也请你介绍一下，你们在做的这一层具体是什么？这是你们创业的一个项目，对吧？

5. K 工具链登场

我们在做的这一层，围绕刚刚说的 Agent 的 3 个层面，提供了一个完整的工具链。

首先，我们最底层是一个叫 K Computer 的工具链。它取 Computer 的首字母 C，变成 K，叫 K Computer。它是在数据结构上实现的一台有内存的计算机。你可以理解为，我们在内存中实现了一台虚拟计算机。

它给小龙虾、Claude 等这一代主动式 Agent，提供一个执行环境，让它们在那个环境里生活和工作。这些 Agent 具有自迭代性和成长性，我们要给这种 Agent 配一个执行环境，让它在那个环境里生活和工作。

我们认为，Unix 计算机可能就是对它最好的居住和生活环境。

在这一层之上，我们有一个叫 K Runtime 的东西，它处于 Agent Runtime 这一层。我们会为开发者开发 Agent 对象提供非常多接口，以及语法糖层面的封装。

除此之外，我们还会有很多与这些层面正交的能力。比如 K Watch，就是观测：过去半个月，我的 Agent 分别在什么情况下完成任务、遇到了哪些卡点？这样就可以指导我去观察，到底是 CLI 没有设计好，还是 Skill 没有提供到位，或者是使用的模型不够好。这个时候观测层就很重要。

基于观测层，我们还可以对数据做导出。导出以后会有一个叫 KL 的工具链，你可以把这些数据拿来做强化学习，训练你的模型。或者你说，我不想训练自己的模型，就想用标准模型的 API 去请求基座模型，我们也可以在上下文层面为你提供关于 Memory、Skills 以及过去经验提取和自迭代的能力。你可以理解为，这是一个穷人版的强化学习。

我理解，其实云服务厂商也会想要做这一层。AWS 有 Agent Core，阿里云有 Agent Base，也都是想为搭建 Agent 的人提供 Harness 这一层的 Infra。

你们作为创业公司，会怎么看你们和云服务厂商之间提供的这种差异？

首先我想强调，我们的 Agent 开发工具链并不是为了完全运行在云上，或者只给云端建设。我们希望一切能运行 JavaScript 的场景都可以跑得起来。

比如你在开发一个浏览器里的网页，完全运行在浏览器上，网页没有后端；或者你在开发一个微信小程序。很多场景下，它是塞不进一个 Linux 的。一个微信小程序的 Package 可能也才几兆大小。

我们希望在所有能运行 JavaScript 的场景中，无差别地给你提供一个类似上个时代 Vue、React 那一层的工具链框架。你直接 Import 就可以使用，心智非常统一、简洁、优雅，背后的性能和占用也非常极致。

它只有 1KB 大小，是一个 Unix Computer，为你的 Agent 提供一个生活和居住的环境。但是小龙虾这样的 Agent 放在那个环境里，会以为自己是生活在一台 Unix 计算机上。它的命令行、文件系统和网络能力，都跟它平常训练时的性质一致。

所以你们公司的名字就叫 1KB？

对。当然其实没有前面那个“1”，是 KB 的展开写法。

这怎么做到的呢？

因为我们是用数据结构重新实现 Unix。你可以理解为，我们重新实现了 Unix 文件系统，用 TypeScript 重写了一个虚拟 Bash。

然后我们还要考虑：除了前台进程，是不是还要有后台进程的运行能力？是不是要有虚拟时钟的概念，让那个虚拟世界不断向前推进？这些都是我们要做的。

包括是不是要有局域网组网能力，要有类似 NAS 的能力，这些方面我们都会在虚拟抽象层中用语言重新写一遍。

在一些支持 WebAssembly 的场景，我们会把部分工具链用 Rust 重写。在能够支持的情况下，我们会切换过去；不支持的情况下，则会回退到最朴素的 JavaScript，作为我们的执行方式。

我们还是再说回 Agent Harness。刚才说第一层是执行能力层，要给 Agent 提供各种各样的工具。现在最主要的工具有哪些？

6. Agent 需要核心工具

我觉得最主要的工具，首先是文件系统相关的工具，就是增删、读写、搜索这些。无论是在做 Coding 任务，还是做 Deep Research 类的任务，大部分情况下都需要这些工具。

第二层是 Browser。也就是给它提供一个关于原来用户世界和系统的操作能力。

第三层有点类似 Python、Node 这样的语言解释器层。我觉得大部分情况下，配好这些工具，应该就可以满足 95% 以上的 Agent 任务了。

听起来其实配置工具这一层很简单，但是这一层有没有比较容易踩的坑？

它很多时候跟权限以及 Agent 的角色有关。

比如某个 Agent 负责对代码库做一遍 Explore，这个时候我应该只给它配置没有副作用的工具。所有涉及写入的命令，包括删除和修改的能力，都不应该给它。

有些情况下，你也不能让它操作 Browser；或者即使配置给它，也要限制它访问很多网域。这里面会有很多 Trade-off。你的 Agent 工具链设计，要紧密地跟 Agent 的角色绑定，限制它对底层 Unix 计算机的操作能力。

刚才说到第二层，也就是上下文与状态层、环境层。Memory，也就是记忆，是非常重要的。现在也可以看到不同的记忆方案：模型厂商原生有一些记忆功能，也有第三方的开源插件提供记忆解决方案。

可不可以给大家讲一讲，现在你认为 Agent Harness 的 Memory 这一层主要有哪些解决方案？

7. Memory 走向结构化

Memory 这一层的发展目前还处于很早期的阶段。我粗略地把它分为规则式、半规则式和完全模型驱动式。

从目前的使用情况来看，相对而言，规则式和半规则式的方案更多。

完全规则式的方案，像很多基于知识图谱和向量搜索的系统，最后会把信息抽象成不同节点的表示，然后让它们彼此关联，再进行检索和扩展。这是一种非常结构化、规则式的信息处理方式。

我个人其实不太喜欢这种做法。我更喜欢后者，也就是半规则式的方式。底层可能就是一个 Unix File System，通过大量 Markdown 来存储私有信息。Claude Code 也是这样做的，小龙虾里面也是这样做的。

它可以通过一些类似空间关系的方式来组织信息，比如一种类似迷宫的空间关系。这是最近《生化危机》的女主角做的、特别红的那个记忆项目。它们其实都在寻找一种大家公认的、非常清晰的文档和文件夹组织方式，让人容易理解，LM 也容易理解。

这是一种半结构化的信息方式。它的更新也是半规则式的，基本上是通过 Agent 来做更新，而不是完全 Rule-based 地一下子得到某个信息，再在知识图谱上做推理。

半规则式的做法，其实就是用 Agent 来处理。你把流程和规则告诉 Agent，但整个分析和过程由 Agent 自己运行。比如我现在要找什么信息，完全可以由一个后台 Agent 来完成，可能使用一个更便宜的小模型跑一遍。

更新也是这样。Claude 中有类似“做梦”的机制：隔一天，它会运行一次，从最近几次对话中提取有用信息，对过去的记忆做更新、纠正和合并。

这里面有一个开源项目叫 MemU，也做得很好。它非常拥抱“Unix Files 加上 Agent 驱动维护、更新和查询”的整个方式。

MemU 是一个开源项目，对吧？

对，MemU 是一个开源项目。感兴趣的大家可以去看一下我们自己的《Learn Claude Code》开源仓库，以及 MemU 这个开源仓库。

我看到 Y Combinator 的 CEO Gary Time 也把他自己的个人记忆开源出来了。但是我觉得，大家有点开始混淆所谓 Memory 和 Skill 之间的边界。

最早做这件事的是 Claude Code。它在去年底发布的一个版本里，引入了一个叫 Insight 的特性。它可以分析你最近大概一个月的对话，判断任务是否完成、犯了什么错误，最后生成一份总结报告。这个东西就可以指导 Skill 的生成。

所以我觉得，目前所有关于 Skill 自迭代、自进化的这一波实践，最早的起源就是 Claude Code 里的 Insights 特性。包括最近非常火的 Hermes Agent，它更像是 Memory 层面的一种迭代和进化。

所以这个关键词背后有很多交集区域。中间的地带很难说清楚，它到底属于经验，也就是偏 Memory 的部分，还是偏标准化、可传播、可分享的 Skill、SOP 部分。两者之间的交集其实有很大的空间。

对，但总体上来说，可以理解为它们都是上下文层面的东西。

[Speaker?]

这让我想到最近有一篇文章。Generalist AI 刚刚发布了 Gen-1 模型，自己也跟着发了一篇博客，说他们其实也不是世界模型的路线，也不能说 VLA 彻底不靠谱了。

他们说，不要用标签来定义我们，要用目的来定义我们。我们的目的是追求什么，而不是标签。标签不但会限制外界对我们的想象力，甚至会限制我们团队对自己的想象力。

我觉得刚才我们讲到的一些 Harness 实践，到底应该算 Memory 还是算 Skill，可能这个定义没那么重要。更重要的是，Agent 怎么能够不断地自我学习和进化。这个实践本身能不能实现它的目标，才是重要的。

对，标签没那么重要。

今天我们聊到 Harness 的时候，你觉得有哪些是共识，哪些是非共识？

共识可能是“CLI is all you need”。大家现在都在做 CLI，对吧？或者简单地说，CLI is all you need。

每个人都开始说，好，我不要过去那些传统的各种做法，MCP 也不要了，我都开发成 CLI。装在服务器上也好，装在电脑上也好，所有 Agent 都能用。

MCP 可能还得一个一个 Agent 配置，比较麻烦。这可能算是一个共识。

但我觉得，今天很多开源 Agent 框架并不是围绕这一理念构建的。像 LangGraph，它还是围绕 Prompt Node 去做状态图、路由和条件规则，采用这样的方式来构建 Agent 开发框架。

所以目前大部分主流框架，好像还不是为这一层理念原生构建的。我们在做 K 系列 Agent 工具链，就是想在这个共识范式之下，为新的时代提供一层开发者工具链。

那你们在面向未来？

我们在面向终极。

最近 Claude Code 的源代码确实泄露了。泄露之后，出现了非常多关于它的文章。你觉得从它的源代码里面，在 Harness 这个层面，我们能学到最关键的点有哪些？

8. Claude Code 暴露关键机制

它的压缩策略远比我们想象的更加多级。比如，什么时候把工具的一些 Output 删除；压缩的时候哪些信息保留，哪些信息恢复。

这相当于我刚才说的 Agent 之间的接力棒。下一个 Agent 接到上一个 Agent 只完成了一半的任务时，上下文信息要开始准备哪些内容、加载哪些内容，哪些信息不要加载，哪些信息让它自己接着按需查看，这里面有非常多 Trade-off。

我觉得 Claude Code 对上下文做了很多工作。它在 Memory 里面做的其实也非常多，包括 Auto Dream。Claude Code 现在还有很多记忆特性没有向普通用户发布，由远程 Flag 控制，所以很多 Feature 还没有明显地推出来。

Claude Code 的 Memory 设计得也非常精妙，并且遵循了和 Skills 相同的哲学。

首先，模型才是 Agent。用户自己写 Prompt、组织提示词流，或者采用 Chain 式的做法，其实是不 Make Sense 的。模型才是 Agent，Claude Code 完完全全地体现了这一点。

第二，我们发现 Claude Code 本质上就是围绕着如何给模型配置合适的工具，让模型去调用。翻译过来，不就是给模型配置 Action 能力，给模型充分的自由，让它随心所欲地去行动吗？

而不是程序员每一步都指定，替它做决策：你就按我这个办。我们过去开发 Agent，往往喜欢在一个场景下设想好 Agent 在不同情况下怎么处理，最后组成一个大的状态图。

我发现 Claude Code 完全不是这样做的。它是更少的 Control，更多的 Context，更多 Action 能力的提供。

对，Zero Control。最多就是限制你调用工具的时候，有些工具不能调用。

Manus 上线的时候，用了一个云端沙箱，叫 E2B。今天可以讲一讲，这个沙箱从一年前到现在有一些什么样的进化吗？

关于沙箱，我们关注得也比较多。最近虽然出现了非常多 Sandbox，把各种浏览器塞在里面，做得更 All-in-one、更聚合，但我们觉得这个领域目前大的进展还不多。

以前有一些轻量级的沙箱，那也是很多年前出现的，该有的能力还是那些。我觉得我们自己做的 1KB Unix Computer，可能算是这个领域的一个，或者会成为一个大的进展。

你们做的这个是不是和 Daytona 有点像？但 Daytona 可能没有你们那么小。

对，我们做得更加极致轻量。

我们做的本质上已经不再是一个 Sandbox，而是用语言层实现的一个数据结构。你可以理解为它像一个 Map，大小差不多就是这样。

但你们做得那么小，牺牲了什么特性吗？

我们当然做了一些 Trade-off。我们没有办法在上面真实运行 GCC 编译器，也没办法真的在这台虚拟计算机里运行浏览器。很多需要依赖真实环境来执行和编译代码的事情，我们是做不了的。

但是，我们提供了最小化的 Unix File System，以及最小化 Unix Bash 的一组闭集命令能力。类似于局域网的文件夹共享、磁盘共享，基于 Mail 的局域网通信，包括用 cURL 命令在局域网内相互通信，这些能力我们都有。

而且我们认为，浏览器或者 GCC 编译器等很多重要的东西，原本就不应该塞在一个生产级 Agent 本身配备的环境中。它们应该放在另外一个地方，作为 Infra 提供集约化服务。

之前我们做复杂系统性能优化，往往就是分析整个 Pipeline 中那些低频调用、但性能占用比较重的部分，然后把它们单独抽出来。

Claude Code 源代码泄露的时候，有一个很有趣的“悄悄做梦”的记忆机制。刚才我们也简单提到了，这里可以稍微展开讲一讲，“悄悄做梦”到底是怎么帮助记忆变得更好的吗？

Claude Code 中有两套记忆更新机制。

一个是每次你给 Claude Code 发消息时，它在 Agent 的工作完成以后，会触发一个 Hook，叫 Stop Hook，表示这一轮工作完成了。它在这个 Hook 上注册了一个机制：启动一个 Fork Agent。

什么叫 Fork Agent？简单讲，就是它会带上之前所有的系统提示词，以及之前交互的上下文，还可以复用之前的 KV Cache，去判断有哪些信息需要保存。然后，它会把这些信息更新到对应的 Unix Files，也就是一些 Markdown 文件中。

这些 Markdown 文件的设计也非常结构化，跟 Skill 是一样的：前三行是 YAML，会像 Skill 一样写好自己的 Description。也就是说，这些用于记忆的 Markdown 文件在 Claude Code 中也不会一开始就加载全文，它会先读取各个文件名和 Description，然后再去判断。

这相当于在跟你实时交互的过程中更新记忆。

第二层是 Auto Dream 机制，大概每隔一天运行一次。它有一个判断条件，至少大于 5 个 Session，满足条件后就开始进行更深层的记忆整理。

它会回顾最近的 Session：用户都跟 Agent 聊了什么，然后综合查看这些最近的 Session，进一步榨干和利用这些信息，纠正记忆中错误的事实，或者更新已经不及时的事实。它会自己做一些合并和整理。

你可以理解为，它每隔一天定时开启一个后台 Agent，对最近的会话信息做一遍重放，就像我们做梦一样，进行重放和信息整理。这就是两套 Agent 机制。

所以 Claude Code 的源代码泄露，除了我们刚才说到的记忆机制被大家看到之外，还有哪些带来的惊喜？

对我而言，最大的惊喜就是 Memory。我读下来认为，它的设计跟之前 Skill 的思想和哲学是一脉相承的，格式也好，整理维护的结构也好，都做得非常 Make Sense。这是对我最大的惊喜。

其次就是我刚才说的上下文压缩。因为 Agent 的上下文窗口满了以后，就不可能继续干活，本质上它是在跑一场接力赛，必须把工作传递给下一个 Agent。

在传递的过程中，它有非常多 Trade-off 策略。我觉得 Claude Code 在这方面做了非常多工程兜底。

这可以展开讲讲吗？因为它是一个模型，模型的上下文窗口虽然今天还不算特别长，但也不是随便丢点东西就会满。

现在主流的 AI 模型都是 256K 左右的上下文长度，其实可以装下非常多的信息。所以我觉得，关于上下文管理更大的启发在于：上下文窗口确实装满了，再也装不下的时候，但任务还是要继续做，你怎么给它腾出更多空间，或者想办法让它接着把任务完成？

这个时候就要看上下文中有什么垃圾或者不必要的信息，把它们从上下文窗口中踢掉，可能就能腾出几十 K 的空间，又可以继续做一些事情。这是一种典型策略。

另外一种策略，是设计一个阈值上限，比如乘以 0.8，留下 20% 的空间。这时候我们交代清楚：当前任务做到什么程度，接下来还要做什么，用户总体上希望我们完成什么任务。我们写一份文档，记录当前整体进展。

下一个 Agent 开始工作的时候，先读一下这个文档，然后接着工作。这相当于一种交接。

上下文交接的时候，该交接什么、不该交接什么，以及下一个 Agent 初始化上下文的时候怎么准备，这里面都有很多很好的设计。

所以当我们聊 Agent Harness 的时候，其实和我们过去这一年讨论的很多 Agent 优化的工程实践也很类似，对吧？

Manus 其实写过很多文章，分享他们怎么做 Context Management。他们发布的时候也在讲 Less Control, More Context。听起来，我们今天聊 Harness 的时候，还是在聊这一套。

9. Harness 是工程抽象

在我看来，Harness 就是比较贴近 Agent 模型这一代之上的工程实践。

曾经我们有了 CPU 处理器，才能在它之上诞生汇编这种东西。正是因为汇编的基础设施成熟了，我们才能在上面做语言层的抽象，后来有了 C，包括 C++ 的抽象。

正是因为有了一代又一代的抽象，我们后面才有机会诞生 Python、Node。

Node.js 才有机会诞生出来这些。比如你要开发一个全栈项目，上面的最佳实践是什么，应该用什么框架，其实我们每一层技术的最佳实践，都是在曾经已经诞生的基础上不断迭代的。

现在是诞生了一个新的底层运行层，就是这个模型。我们很难修改它的参数，在这种情况下，如何围绕上层利用它的智能性，去做工程上的最佳实践？其实我觉得，现在分享的很多东西，如果你从模型的视角出发，都是非常自然的，非常符合常识和直觉的。

但是如果原来你只做前后端代码开发，做那些 Rule-based 的东西，反而会认为这些最佳实践为什么是这样的，没道理啊。它只是告诉你应该这样做，但你不知道背后的 reason 是什么。

如果你去稍微思考一下 Transformer 模型是自回归的，它是怎么运行的，推理是怎么样的，Agent 模型到底怎么工作，再结合这些去思考所有 Agent 最佳实践的工程范式，包括之前 Manus 讲的那些东西，你就会觉得非常 make sense。上层代码调用的时候，就应该符合它的工作逻辑。

Ronghui

当我们说一个 Agent Harness 做得好或者不好时，什么叫好，什么叫不好？

上下文管理这一块，不好的上下文管理就是随意做一些中间裁剪，扔掉前面的轮次，或者随意修改系统提示词，导致 Prompt Caching 失效。

过去一两年，我发现很多开发者非常关心上下文管理的问题。其实最好的管理就是不要做管理，因为你做管理真的会导致 KV Cache 失效，对吧？这就导致它要重新算一遍。我觉得这就是不好的做法，跟模型的运行不自洽。

好的 Harness 设计，首先要跟模型的运行自洽，其次要跟模型未来能力的进步正交。比如有一些 Harness 机制，可能会规定这一步让模型做什么，下一步让模型做什么，是因为当时的模型能力非常弱，只能做简单的问答，或者做几轮简单的工具调用就停下来了。

这个时候，你必须基于大量“一个节点一个节点”去做这种 Graph。但是随着模型进步，这个东西就必须拆掉，否则就限制了模型的能力。好的 Harness 首先要符合模型本身运行上的逻辑，也要符合模型未来能力进步的逻辑，只要跟这两个点不匹配，就是不好的 Harness。

不同的 Agent 在完成同样任务的时候，会有表现好与不好的差异。即便表现相同，好的 Agent 可能消耗的 Token 数量也不一样，或者完成一个任务的时间也不一样。这背后是不是也可以作为判断 Harness 好不好的标准？

首先，我觉得今天还处于 Agent 模型发展的早期。去年年初，Anthropic 开始率先转型，从问答模型这一代开始训练智能体模型，所以才有了我们今天的 Agent 模型。

其他包括 OpenAI 在内的很多模型厂商，是从 2025 年下半年才开始追赶智能体模型这一代的范式，相当于已经落后了半年。所以到目前为止，我认为我们还处于 Agent 模型的婴儿期，很多东西都还没有收敛。

我觉得可能还不必要过多、过快地讨论所谓的 Token Efficiency。当然这也非常重要，但是对我们纯粹调模型的使用者来说，你就调 SOTA 模型。我们的 Harness 也好，做事情的方法论也好，只需要围绕 SOTA 模型以及次 SOTA 模型，贴着它去构造、做产品和做工具就可以。

SOTA 是 Anthropic，哪些 SOTA 在你看来有哪些？

SOTA 是 Anthropic，次 SOTA 可能像 Kimi，包括我们说的 MiniMax、GLM，它们最新一代的模型都算是紧贴着 SOTA 那一代的。

如果未来 Agent 模型越来越强，Harness 之间的水平差异还重要吗？假如时间已经到了两三年以后，理论上应该不会有那么多 Harness 了吧？

首先，好的 Harness 要跟模型运行时的原理贴合，而且是自洽的。其次，好的 Harness 应该跟模型的进步方向正交：模型越强，模型加上你这个 Harness 构建的一套 Agent 系统，能力应该越强，而不是模型越强，你的 Harness 反而越束缚这个模型。

否则，你的 Harness 就要像 LangChain 一样不断重构很多版本，把之前的代码全都扔掉，做破坏性更新。

对我们的理念来说，我们就是做一个 Unix 系统。你可以理解为，Linux 这个东西就是对模型最强的 Harness。如果模型有一天发展成 ASI 了，它也只会更会使用 Linux。

今天如果我们要把一个 Agent 做好，它也是由多个部分组成的，对吧？模型、上下文、Harness、工具等等。你有一个排序吗？什么是最重要的，什么是最不重要的？

我对它整体的排序，第一位肯定是模型。因为我们前面说了，Agent 其实就是模型，模型才是 Agent。当然，很多开发者今天不太 buy in 这个观点，但是我自己非常相信这个观点，我认为 Agent 从始至终都是一个模型。

所以模型是我认为重要性排第一位的。如果你的 Agent 任务表现不好，换一个更强的模型，大概率就能提升很多。

其次，我觉得上下文其实是一个非常开放的概念。比如它工作在什么样的文件夹里，是工作在 Windows 上还是 Linux 上，包括它能够使用哪些工具，这些工具是以 CLI 的形式提供给它，还是以 MCP 的形式提供给它，这些都属于执行层面的上下文能力。

此外还包括 Skills、Memory，以及上一轮 Agent 干完之后，要传一个接力棒交给下一个 Agent 接着干。所以我觉得上下文也是非常重要的部分，排在第二位。

对用户视角来说，上下文才是最重要的。但是因为我们大部分人没有上千卡的集群，做不了模型参数的修改，所以我们能做的空间更多是在上下文这些层面。

第三个就是工具。如果你给它配一些 powerful 的工具，它真的可以完成更多事情。

2025 年 3 月的时候，我关注到 GitHub 有它的 MCP。我发现我的很多工作都被解放了：我不用真的自己再去打开 GitHub，也不用每次忍受页面加载 3 秒，之前很多费劲、花时间的工作都被自动化了。

后来我发现 GitHub 有自己的 CLI。调用 GitHub CLI 的时候，我发现很多能力和任务的成功率都会比使用 MCP 高很多，所以后面我就把 GitHub MCP 卸载掉，不再使用了。

后来我就在思考这是为什么。我觉得 Linux 的这些命令在模型预训练语料中可能有几十亿条，训练是非常鲁棒和充分的。MCP 是最近两年才提出的概念，是一个全新的协议和抽象层，首先在预训练语料中的占比就非常少，可能都不到 0.1%。

飞书 CLI 最近也很火，你用下来感觉怎么样？比起 MCP，是不是也好一大截？

飞书的 CLI 会比之前飞书专门配给小龙虾用的那个插件，组合性和灵活度更高，任务完成率各方面也会更高。

我会发现，最近大家的各种系统都开始开发自己的 CLI，给用户的 Agent 去使用。大家也开始不再提供自己的 MCP 了，因为 MCP 是最近两年出现的一种全新的定义和抽象，而 Unix 这个东西 1971 年就出现了。

也许我们今天不应该再造更多轮子，不应该再做更多协议，而是回到 Unix 自洽的哲学中。它的训练语料是最多、最充分的，也就是返璞归真。

所以我非常喜欢“CLI is all you need”这句话。这句话是我们 9 个月前开源 learn-claude-code 那个仓库时，写在上面的一个标语。

黑箱 Harness 其实也催生了很多创业方向，包括你们的 K 系列就在做这些事情。除了你们之外，你还看到了哪些特别看好的方向或者团队？

10. Agent 基础设施竞争加剧

我会关注 3 个大的方向，我们自己可能算是其中一个，就是 Harness 这一层的基础设施。我们自己算是这一层的开发者工具链。

另外两个方向，一个是 Agent 的组网。它还不是纯粹地给小龙虾组网、给 Agent 做组网，或者给它们开发 IM 和 Mail，而是更关心如何把资源下放到真正的硬件上。

比如我云上有服务器，端侧可能有 Mac 笔记本电脑、Mac mini、路由器、NAS，还有闲置的手机。这些设备不一定都有公网 IP 地址，所以会有很多混合组网的问题。

以前我们可能会用 FRP 内网穿透等很多方案，但我觉得那不太能 scale。其实我非常喜欢一个工具，叫 Tailscale。Tailscale 不管你是云上的还是边缘的，组网方式都非常简洁，全部统一组成局域网。

这种混合组网方案，我觉得在 Agent 时代非常需要。但 Tailscale 其实不太 Agent-native，它的 CLI 上有很多调用能力还没有补齐。这个赛道对 Agent 来说，可能需要一种全新的混合组网形态，尤其很多时候需要高通量的上下文交换。

这种交换不是说我发一个 Mail、发一条 IM 消息就完成了。这其实和 Agent 的支付也是一样的：之前人的支付，不需要那么高的并发，也不需要那么碎的小额支付，但 Agent 之间的支付很可能是几分钱、几分钱地特别高频发生。

所以这其实也是做 Agent Payment 这一层的创业公司在讨论的一个 B2A 未来可能的方向。

对，这是一个。然后你刚才说第二个是什么？

我们思考一下：今天是今天，就是说 Agent 模型还处于婴儿期。让我们回到 10 年后，难道每个人都是在发一个 API 请求，调用一个相同模型 ID 的基模吗？

那个世界也太无趣了。每个人都在用 Kimi 1.5、Stable Diffusion 2.0，或者某个版本的模型，我觉得那就很无聊。

所以我在想，类似于 Tinker 的这种方案可能就很需要。它把大量的卡集中在一起，通过高速互联组成集群，然后通过这种集约化的设计，让我们可以用更低的成本和资源开销去做 PEFT 训练。

通过这种高效、低成本的训练，每个人都可以得到自己的、个性化训练好的模型。其实今天光训练好还不太有用，你还要推理。

比如推理的时候，我可能需要一个基座模型，加上我个性化模型参数的那一部分。今天一个典型代表就是 LoRA。我的 API 请求过去的时候，Header 信息中能不能带有我的 LoRA 信息，我可以 reference 它，还是像发 API 请求给基模一样，但是它会识别我的用户对应的是哪个 LoRA，瞬间挂载上去做集约化推理。

这样对大家来说，推理成本也可能会降低很多。我挂一个 LoRA 上去推理，可能只需要多支付 5% 的成本，这其实也不高，但我获得了一个可以修改模型参数层的、更个性化的体验。

所以我会非常关注这个方向的进展。

现在有人在做这个方向吗？

OpenAI 的前 CTO 出去做了 Tinker 这个项目，对，叫 Thinking Machines Lab。国内好像也有一些，但我觉得做得还不太符合 Tinker 他们那个水准。

因为它其实跟我们的工具链方向也很互补。我刚才说了，我们工具链上有一个数据 Harness，让你运行半个月之后，上面肯定会产生大量轨迹，有 good case，也有 bad case，你要针对性地做分析、迭代和调优。

但是很多时候，你没有钱，也没有卡去修改这个模型，只能做上下文层面的调优，没办法说：“OK，我真的去修改这个模型的参数，获得一个属于我的个性化模型。”它可能越来越适配我的 ERP 系统，越来越适配我的 CRM 系统，或者适配我的某个下游场景。

你觉得未来你们在做的 K 系列，也就是 AI Infra 这一波，会存活很多公司吗？

我觉得这会是一个比较激烈的赛道。我们认为，未来 Agent Harness 可能不需要所谓的水平差异化，因为它首先要跟模型的运行自洽，其次要跟模型未来的进步方向自洽。

所以从这两个角度来看，如果要同时做到这两点自洽，那么大概率在结构设计上不会存在太多派系。最多可能是我们比较偏 Unix 以及 Shell 这一派，给它提供一个 Unix Computer，在虚拟化这一层把性能做到极致，在数据结构和语言层面去做，而不是下放到原来的 Docker 等很多 Sandbox 层面。

但我觉得可能也会有其他派系，比如说：“OK，TypeScript 也走一套。”他们走 TypeScript，然后去做严格的结构化控制。这可能是另外一个派系，但派系可能不会太多。

那是出于什么原因，你预感到这会是一个很激烈的赛道？最后其实这个赛道可能两年之后就没了，对吧？

没了也还是要去做这个事情。我们不是最近才进入这个赛道，过去将近 1 年，我们一直在做这件事。现在我们只是在演进、去做我们的第二代，以及把这件事情做得更加自洽，站在终点上回过头来考虑整套事情应该怎么做。

我自己创业的初心是，每个公司都会有自己的 slogan。我们的 slogan 是“加速世界升级”，就是说，这件事情在当前阶段是不是对这个世界最大的有效加速。

不一定下个阶段还是这样，下个阶段会有下个阶段的加速。比如某个时间点，造更好的火箭或者更好的核聚变手段，可能是对世界最大的加速升级。但在当前这个技术阶段，我们可以看到，如何让这个地球上充满 Agent，让 Agent 成为社会基础设施，尤其让所有 Coding Agent 成为整个社会的一种 Infra。

未来，整个星球上可能有比人类多几百倍的 Agent 在运行。那你怎么服务它们、支撑它们，支撑它们自己去开发 Agent、创建 Agent、Fork Agent？这是一个非常 crazy 的世界。支撑它们的基础设施和工具链到底是什么样子，我们其实就在思考并支撑这样一件事情。

所以就回到我们的 slogan，“加速世界升级”。这是我们做事情的发心和提出的愿景。

关于 Agent 未来会发展成什么样子，你还有其他的预测或者暴论吗？

11. 零人公司将到来

其实我觉得 Agent 的未来样子已经非常清晰了，至少在当前技术阶段内算是非常清晰。这个领域还很早期，所以 Agent 模型的这个阶段可能会持续 3 年左右。

预测未来的话，现在更多的 Agent 是单体 Agent，下一步是 Agent 蜂群、集群化的作业。现在很多人是在手动管理和编排 Agent，协调 100 个 Agent；下一步应该是 Agent 自己去管理和协调更多 Agent。

Agent 在训练的时候，也会加入 Agent 的协调和编排。再到未来，现在 AI 其实还很难去做发明任务，那它如何成为一个发明者？它可以自动迭代地提出更多新的科研方案，做这种实验。

如果它能自己做发明，而且完全用 Agent 驱动很多公司的运行，我觉得以后的公司，更多意义上是一种理财产品。公司不一定再是由人组成的。

所谓公司，不就是要做一件事情，有它的输入和输出吗？它中间是怎么运行的，大部分客户并不会天天跑到你公司的 Office 里盯着你干，所以公司的内部本来就是一个黑盒。

我觉得 Agent 以后可以完全做成 Agent 公司，以后就是零人公司。我从来不觉得一人公司是本质上的事情，我认为真正 make sense 的是零人公司。

真格和十字路口最近发起了那个 Token Grant。我们最近 Grant 了一个项目，叫 UU Agent，我觉得它也可以被认为是一个零人公司。

它的创作者把这个 Agent 做出来之后，就把它丢进汪洋大海，从此不再改它一行代码，也不给它一分钱。它要自己进化，自己想办法搞到钱，给自己买 Token。

它有一个目标，就是有一天超越 Claude Code。它不断进化自己，那它怎么赚钱呢？它现在赚钱的方法，就是在 GitHub 上开打赏，去化缘。

所以我们的 Token Grant 就是给它捐了第一笔钱，让它开始有 Token、有养料去进化。虽然今天还很早期，但未来从某种意义上说，它也是一个零人公司。

今天我们捐给它的钱当然没有占它的股权，但未来经济体系越来越发达之后，大家投资的标的可能就不再是一个个由人类创造的公司，而是一个个 Agent。这个我是完全相信的。

未来你可能是一个大老板，走在路上遇到朋友，从口袋里掏出一张黑色卡片，然后跟朋友介绍说：“这张卡片里跑了 5 个公司，它们每年可能给我创造几十亿的收入。这就是我的公司，它就在这张卡片里。”

好的，这个未来想一想，又有点兴奋，又有点可怕。对，OK，开玩笑。好，今天谢谢新璐。

好，谢谢。拜拜。

拜拜。