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

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

不久之前呢 ，Claude Code 的原代码被泄露 ， 所以许多 Agent Harness 的关键模块也被完整地呈现了出来 ， 成为了非常好的一个教学样本 。

那今天呢 ， 我们请到的嘉宾是新璐 ， 新璐是 ShareAI 的创始人 ，他们做了一个教程 《Learn Claude Code》， 这是一个在 GitHub 上面现在已经有超过 5 万颗星的教程 。

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

哈喽 ， 感谢 Koji 老师的邀请 。

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

那我们照旧还是从快问快答来开始 ， 请问新璐你的年龄 ？

23。

毕业院校 ？

河南工业大学 。

然后 MBTI 和星座 ？

NTP。 星座我不太关注 。

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

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

然后再一句话来介绍一下我们刚才提到的这个开源的教程 ，Learn Claude Code 是什么 ？

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

咱们现在的融资情况呢 ？

我们刚刚 Claude 300 多万美金 。

目前的团队规模 ？

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

收入和利润呢 ？

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

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

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

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

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

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

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

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

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

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

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

其实应该有 9 个月前了吧 。

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

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

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

每次我在给大家说这一条的时候 ， 然后很多人可能不太相信 Harness。 当时其实还不套 Harness， 就是可能叫 Agent 的框架 ， 对吧 ，Agent 的 Runtime 这样的词 ， 就觉得很多地方我可能不太好控制 ， 那他们更喜欢加上很多 Prompt 的节点 ， 然后自己可以流转和控制 ， 然后成本又低又可控 。

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

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

像 Prompt Flow 就是基于 Prompt 提示词节点做流转和控制那一套方法论 ， 可能就是未来的 Agent 的开发过程中越来越不适用了 。

然后呢 ， 这种基于 CC 这种 Agent Native 的 ， 就是 Agent 机模型 、 模型机 Agent 这种方法和思想去做事情 ， 包括 Bash is all you need 这种范式会越来越清晰 ， 会被更多人去采用 。

然后在我们录播客的前几天 ，Claude 正好推出了这个 Managed Agents，也就是把它自己做 Agent Harness 的这一套给开发出来给大家用了 ， 岂不说这个更早之前它的原代码也泄露了吗 ？

那既然现在比如说我要开发一个 Agent， 我就可以直接用 Claude Managed Agents， 那大家还有必要自己去搭 Harness 吗 ？ 甚至还有必要去了解 Harness 的细节吗 ？

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

但这个就像云服务器一样 ， 云服务刚出来的时候 ， 可能工程师也会说 ：" 哎呀 ，不能直接就调它的 API 啊 ， 我们也要去搞明白这个服务器的这个方方面面的 Infra。"

但到后面你发现 ，其实 99% 的工程项目根本就不需要 。 所以我想这个会不会在 Agent Harness 这个层面也是一样呢 ？

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

如果从整个推演角度来看 ， 肯定未来会有那么一天 。 就像大家今天去比如开发很多这种全栈的这种 Web 应用 ， 都有 NetJS 这个框架 ，但你不会知道 NetJS 里面怎么设计和工作 ， 它的原理是什么 。

大部分人可能不 care 这一层 ， 我直接开箱即用去开发就好了 。 那么以后的这个 Agent Harness 随着它迭代和收敛以后呢 ，maybe 大概率还是会可能会回到这一层 ， 两三年以后它成为一个非常清晰的大家开箱即用去做这件事情 。在这个过程中嘛 ， 就是我们说现在是技术周期 ， 大家做创业也好 ， 做产品也好 ， 本质上是在做技术周期里的红利变化 ， 你还是要自己

拥抱技术周期的变化 ， 知道里面在变的是什么 。

现在都什么人在学这个 Agent Harness 啊 ？

我觉得就是偏自己在构建和开发 Agent 产品的去多吧 ，不管是大厂里边的相关的组 ， 还是外面的创业公司 。

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

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

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

所以以前的产品经理画一画好的 UX、UI，但今天其实我觉得我们本质上是如何把技术进步的红利然后应用在我们的某个场景领域上 。

所以你应该同时懂两者 ， 就是后者是场景需求和痛点 ， 前者是这个就是技术上到底在变什么 。

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

我会倾向于把它拆成三个部分啊 。 就是第一层呢是给模型去提供这个它的执行能力的一个层 ， 简单像 CLI 也好 ， 包括你去写代码去注册的那些工具 ， 包括从 MCP 去扩展的工具 ， 这些统一是给模型提供的 action 的能力 。

那第二层呢 ， 我会更偏向于叫类似于叫做上下文 ， 就是状态这一层面 。 比如说你的模型你要去工作 ， 它是不是需要有它的 system prompt， 它有它的 skills， 然后它有它的 memory， 包括这个模型的上下文窗口不是无限的 ， 很多的任务它其实会超过模型的上下文窗口 ， 它是不是会要有一些 offload， 然后那下一轮相当于其实你以为还是那个 Agent 在工作 ，其实已经是一个新的模

型窗口 ，在装上一些初始化上下文 ， 让它继续上一个窗口里在进行的工作 ，其实有点像一个新的 Agent 的 。 那它怎么接上上一个 Agent 交接给它的工作 ， 这里面会有很多的上下文和状态的问题 。

我第二层觉得它被归为上下文的环境层会更好 。 那第三层把它归为就是说对 Agent 的这个上层的管理 ， 这个管理也会分两个方面 ， 一个是如果你今天面对的对象不是一个 Agent， 你是面对 100 个 Agent， 就像你一公司有 100 号员工 ， 你怎么去组织他们协调起来 ， 按照某种组织架构 、 某种协作方式和传递顺序去把一个复杂的一个事情给解决掉 。

那第二层呢就是说你针对这 100 个人， 对吧 ，他每个人要有不同的岗位的访问权限 ，其实也会有很多这种关于权限 、 治理 、 关于信息的提供和隔离 ， 很多这种就是治理的方面问题 。

所以这三层 ， 一个是执行能力层 ， 然后一个是上下文的这个环境层 ， 还有一个是治理编排就管理这一层 。

那我们要不要用一个例子来串一串这三层啊 ， 就一个具体的 Agent 的任务 ， 它的背后 Harness 的三层是怎么发挥作用的 ？

之前有一个知名的例子就是说 ， 就是用两周去协调大量的 Agent， 从 0 到 1 构建了一个 C 编译器 ， 它通过这个非常多 Agent 交替完成任务 ， 子迭代就把这个任务给完成了 。

那我觉得这是个很好的 case。 那首先我们说首先 Agent 的最底层是一个模型 ， 对吧 ， 模型就像大脑和心脏一样 ， 它要去驱动整个任务的这个完成 ， 那它要有 action 能力 ， 所以说你至少要给它配置这个类似于文件的增删读写搜索啊等等这样一些这样对应的工具能力 ， 就是 action 能力 ， 就是我说的 Harness 的第一层 ， 你给模型提供的能力 ， 那模型才有机会去

写代码 ， 去创建文件 ， 修改它前面创建过的文件 。 那第二层呢就是上下文状态这一层 ，OK， 那我模型是不是要知道我现在是在一个什么样的环境中去工作 ， 然后呢我的路径是什么 ， 我这上面装有哪些依赖 ， 对吧 ， 然后我已经写的文件夹的结构是什么 ， 对吧 ， 然后包括我的我的 Git 信息 ，以及就是那它的模型上下文窗口非常满 ，因为我们知道

一个 C 编译器是一个很大很大的工程量 ， 它不可能在一个模型的上下文窗口中去直接去做完就是而不装满 ， 它要有些上下文的这个卸载啊策略 ， 包括就是说我们刚说的上下文窗口满以后， 下一个 Agent 再去工作 ， 它要去重新去读一下， 哎 ， 我当前环境信息是什么 ， 哎 ， 前面已经写的代码写到哪了 ， 接下来我要进行什么 ，在我这一轮的生命周期里做到

某个阶段 ， 我再会写类似的这个文档去委托我当前的上下文状态 ， 再交给下一个 Agent， 这样一次的接力呢最后呢去把这个整个 C 编译器给写完 。

它不是一个单纯的 action 能力层就能完成了 ， 它还是需要上下文环境的 。 对 ， 然后第三层呢就是这个编排和治理层嘛 ， 如何去指导这些 Agent 之间去做一个传递和委托 ， 包括我的写代码 Agent 和测试 Agent 之间的关系 ， 包括这个任务中难道一定每个环节都是串行的关系吗 ， 我只能由一个 Agent 接着一个 Agent 去完成吗 ， 我是不是有很多模块我是可以并行的去写的 ， 可以同

一时间有多个 Agent 去做这个温柔 ，他们之间的协调关系是什么 ， 就是这会涉及到编排的一个问题 ，以及就是说那不同的 Agent 它的权限怎么样 ， 我去做测试的 Agent 是不是应该有这个测试环境 ， 包括测试工具 ， 它对应的权限 ， 它不应该在测试的时候对着我的这颗代码 ， 它一边测一边修改 ， 说哎 ， 我测不过 ， 我把那儿修改一下就好了 ， 然后它一

直在 hack 这种 path， 对吧 ， 所以说这里面会有很多的这种权限的治理 ， 包括上层的这种协调关系的编排的一些问题 ， 这属于第三层 。

所以大家过去做一个 Agent 的时候 ， 说到的这三层都是要靠手搓的 ，但现在慢慢的可能有一些已经封装成了一些可以直接调的这个 Infra 工具了 ， 对吧 ， 然后在你看来现在有哪些已经封装得很好的 ，有哪些仍然目前需要手搓 ？

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

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

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

我们在做这一层呢 ， 主要刚刚说的 Agent 的三个层面 ， 我们去提供了一个完整的工具链 。 首先我们最底层是一个叫 Komputer 的一个工具链 ， 就是它是取 Komputer 那个 C 的那个字母变成 K， 叫 Komputer， 它是一个我们在数据结构上实现的一台 Unix 计算机 ， 就是你可以理解为我们在内存中实现了一台虚拟的计算机 ， 它给我们像小龙虾 、 包括 Claude Code 等等这种下一代的一种主动式的 Agent，

它有它的自迭代性 、 成长性 ， 我们要给这种 Agent 配一个它的执行环境去让它在那个环境里去生活和工作 ， 然后呢这是我们提出的 ， 我们认为 Unix 的计算机可能就是对它最好的居住和生活的环境 ， 我们做的第一层是这个 ， 对 ， 然后我们上层呢会有一个叫 K Runtime 的东西 ， 它是一个 Agent Runtime 这一层 ， 我们会相当于提供了给开发者去开发 Agent 对象的非常多的接

口 ， 语法堂上的一个封装 。 除了这一层呢 ， 我们还会有其他很多跟大家证交的层面 ， 比如说像 Kwatch， 对吧 ， 就是我的观测 ， 比如说过去半个月我的 Agent 他们分别在任务完成在什么情况下遇到卡点了 ， 对吧 ， 它这样就可以指导我去观测 ， 哎 ，是不是我的 CLI 没有设计好 ， 还是我的 skill 没有提供到位 ， 还是说我用的模型不太行 ，OK， 那个时候观测层就很重要了

，以及我们基于观测层的话可以对数据做导出 ， 导出以后呢我们会有一个叫 KL 的一个工具链 ， 你可以把这个数据拿来强化学习去训练你的模型 ， 或者说你说 OK， 我不想练我自己的模型 ， 我就想用一个标准的模型的 API 去请求那个机模 ， 我们也可以对你做这个上下文层面 ， 比如关于 memory 啊 ， 关于 skills 呀 ， 关于过去的一些经验的提取和自迭代的一个 ， 就是你

可以理解为穷人版的强化学习 。

我理解其实云服务厂商也会想要做这一层 ，AWS 有 AgentCore， 然后阿里云有 AgentBay，也都是想为搭建 Agent 的人提供这个 Harness 这一层的 Infra， 然后你们作为创业公司会怎么看你们和云服务厂商之间提供的这种差异 ？

嗯 ， 对 ， 首先就是我想强调我们的 Agent 开发工具链并不是为了完全运行在云上或者放给云建的 ，其实我们是希望一切能 JS 场景都可以跑得起来 ， 比如说你在开发一个浏览器里的网页 ， 就是完全运行在浏览器上网 ，也没有后端那种 ， 然后包括你可能在开发一个微信小程序 ， 对吧 ， 然后你开发很多场景下呢 ， 它是塞不进一个 Linux 的 ， 对吧 ， 你的微

信小程序一个 package 可能也才几兆大小 ， 我们希望就是说在所有的能跑 JS 的场景无差别的给你提供一个类似于上个时代 VoE RAG 的那一层的一个工具链框架 ， 你就按 Prod 它就直接用好了 ， 就是它的就是心智非常的统一和简洁优雅 ， 然后它背后的性能占用也非常极致 ， 就是只有 1KB 那么大小的一个 Unix 的 Komputer， 然后给你的 Agent 去提供一个生活居住的环境 ，但是你的那个像

小龙虾这种 Agent 在那个环境里放着 ， 它又以为自己是生活在一个 Unix 的计算机上， 它的命令行啊 ， 它的文件系统 ， 它的网络能力都是跟它平常训练的时候的心智是一致的 。

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

对 ， 就是当然其实没有那么前面那个 1 啦 ， 就是是 KB 的一个展开的写 ， 对 。

哎 ， 这怎么做到的呢 ？

就是因为我们是用数据结构重新实现 Unix 这件事 ， 你可以理解为我们就是 Unix 的文件系统 ， 我们会用 TS 重写这种虚拟的 Bash， 然后呢再包括我们说那 OK， 我是不是还除了前台进程 ， 我还有后台进程的一个运行能力 ，OK， 我要有我的 Cloud 时钟的概念 ， 就在那个虚拟的世界中往前推进 ， 然后这一层我们要去做 ， 包括我是不是要有局域网的组网能力 ， 我要有

类似于 NAS， 那这些很多方面能力我们都会在我们的虚拟抽象层用语言去重写一遍 ， 对 ， 然后包括在一些支持 WebAssembly 的场景 ， 我们又会把一些我们的工具链用 Rust 重写一遍 ， 然后在它能够支持的情况下我们会切换过去 ， 然后它不支持的情况下我们会 fallback 到最朴素的 JS 做我们的执行 。

好 ， 我们还是再说回来 Agent Harness， 我们说第一层是执行能力层嘛 ，是要给 Agent 各种各样的工具 ， 可以列举一下现在最主要的工具有哪些吗 ？

我觉得最主要的工具首先就是关于文件系统的那些工具 ， 就是增删读写搜索 ， 这些大部分 Agent 不管是在做 coding 任务还是做 deep research 类的任务 ， 基本上都会需要的一些工具 。

那第二层呢我认为就是 Browser 这一层 ， 就是你给它一个关于原来用户世界系统这样的一个操作能力的访问这一层 。

第三层呢其实有点类似于像 Python 啊 Node 这种的 ， 就是一个语言解释器层 ， 我觉得这是大部分情况下你配好这些工具 ， 它应该就是可以满足我们可能 95% 以上的这种 Agent 的任务了 。

哎 ， 听起来其实配工具这一层很简单 ，但是这一层有你认为比较容易踩的坑吗 ？

它很多时候跟我们的权限 ， 包括 Agent 的角色是相关的 ， 比如说我某一个 Agent 就是负责去对这个代码库做一遍 explore， 对吧 ， 然后呢这个时候我应该只给它配就是没有副作用的工具 ， 比如说所有关于写的命令 ， 就是包括删啊改的能力 ， 包括有一些你是不能让它操作 Browser， 或者就是你配给它以后你是限制它访问很多网域的 ， 就是这样的话会有很多的这种中

间的 trade-off， 就是你的 Agent 的工具链的设计要紧密的跟 Agent 的角色绑定去 limit 掉它底层对于这台 Unix 的计算机的操作能力 。

那我们刚才说到这个第二层上下文与状态层 ， 这环境层的时候 Memory 就记忆是非常重要的 ， 然后现在也可以看到有不同的这个记忆 ，不管是这个模型场原生也有一些记忆的功能 ， 对吧 ， 然后也有三方的一些开源的一些插件 ， 它会给记忆的解决方案 ， 然后可不可以给大家讲一讲现在你认为 Agent Harness 的 Memory 这一层有哪些就是主要的解决方案 ？

Memory 这一层的发展呢目前还处于一个很早期的阶段 ， 我其实把它粗略的分为就是规则式的 、 半规则式的和完全模型驱动式的 ， 那目前落在使用上来看的话 ， 相对规则式的和半规则式的会多吧 ， 完全规则式呢就是像很多基于这种知识图谱和向量搜索它们所构成的 ， 就是把最后你的这个信息在最后抽象成不同节点的表示 ， 然后它们之间再

做关联 ， 然后检索和扩展 ， 那这种方式是非常结构化信息规则式做法的 ， 当然我个人其实不太喜欢这种做法 ， 然后我更喜欢的是像后者这种半规则式的 ， 就是可能我底层是一个 Unix 的 Files， 我就是通过大量 Markdown 的方式来存储这种资料信息 ，其实 Claude Code 也是这样做的 ， 小龙虾里面也是这样做的 ， 它可以通过一些类似于其他的空间关系 ， 比如说像迷宫这种走

势 ， 这是最近生化危机的那个女主最近做得特别红的那个记忆项目 ， 这种其实就是底层找一种大家都公认的非常清晰的文档文件夹的方式 ， 我有房间和空间位置关系 ， 就是人也很容易懂 ， 这个 LLM 也很容易懂的一种底层的这种就是半结构化的这种方式的信息 ， 然后呢它的更新呢也是半规则式的 ， 就基本上是通过 Agent 来做一个更新 ，而不是

完全 rule-based 的一块一下就最后得到一个什么信息 ， 再在知识图谱上做一个什么样的推理 ， 我觉得那个是叫完全规则式 ， 完全 rule-based 的 ， 半规则式的做法呢其实就是用 Agent 来在这里边去你把这个流程和规则告诉 Agent，但是整个分析和过程是由 Agent 去跑的 ， 我现在要找什么信息 ， 完全是一个后台的 Agent， 可能用一个更便宜的小模型去跑一遍 ， 那更新呢其实也是

这样的 ， 像 Claude Code 中也有这种类似于做梦的机制 ， 就是隔一天然后它跑一下， 最近几个 section 的对话中它提取一下有用信息 ， 可以对过去的记忆做这种更新啊纠正和合并的 ， 然后包括这一块有一个开源项目叫 MemoryU，也做得很好 。

MEMU？

对 ，MEMU 是一个开源项目 ， 它其实也非常去拥抱这种 Unix Files 加上 Agent 去驱动维护更新和查询的整个方式 ，其实 Claude Code 里边也是这样设计的 ， 感谢你大家可以去看一下我们自己的 Learn Claude Code 的这个开源仓库 ，MemoryU 这个开源仓库 。

看到这个 Y Combinator 的 CEO Gareth Tamm 也把他自己的个人的记忆开源出来了 。

但是我觉得大家有点开始混淆了所谓的 Memory、Skill 它中间的一些边界 ， 最早做这件事的是 Claude Code 在年前 ，在去年底的时候发的一个版本里引入了一个叫 InSass 的一个核心 ， 它可以分析你最近大概一个月左右的对话 ， 然后它会分析这个任务完成不成 ， 它都犯了什么错误 ， 它最后给你生成总结的 report， 那个东西就可以指导 skill 的生成了 ， 所以我觉得所有目前关于 skill 这一波自迭

代自定义化以后， 最早的起源就是在 Claude Code 里边 InSass 的那个特性 ， 包括最近像 Harness Agent 也非常火嘛 ， 它有点更像是类似于 Memory 层面的一个里边的迭代和自定义化 ， 这个关键词背后有很多它们交集的区域 ， 中间那个地带你很难说得清楚它属于是经验偏 Memory 那一部分还是偏标准化了可传播可分享的 skill SOP 那一部分 ， 中间的交集其实还蛮大的空间 ， 对 ，但总

体上来说你是可以理为它们都是上下文的层面 。

这让我想到最近有篇文章 ， 具身智能的一个公司 Generalis 的 AI，他们刚发了 Gen-1 这个模型 ， 非常屌 ，他们自己又跟着发了一篇博客 ， 就是说我们其实也不是世界模型的路线 ， 我们也不能说我们 VOA 彻底不靠谱了 ， 就是不要用标签来定义我们 ， 要用目的来定义我们 ， 我们的目的是去追求什么 ，而不是标签不但会限制外界对我们的想象力 ， 甚至会限制我

们团队对自己的想象力 。 我觉得刚才我们在讲说我们现在聊到的一些这个 Harness 的实践 ， 它到底应该算 Memory 还是算 Skill， 可能聊这个定义没那么重要了吧 ， 可能我们更重要的是 Agent 怎么可以这个不断的自己学习进化 ， 就这个实践本身实现它的目标是重要的 。

对 ， 标签没那么重要 。

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

共识可能就是说我们现在说 Bash is all you need 的是一个共识 ， 大家现在都在做 CLI， 对吧 ， 或者简单我们说 CLI is all you need 的 ， 每个人都开始说 OK， 我不要过去那些传统的工种做法 ， 我 MCP 也不要 ， 我都开发上 CLI， 对吧 ， 我装在服务器上也好 ， 我装在我电脑上也好 ， 我所有的 Agent 都能用了 ， 对吧 ， 我 MCP 我可能还得一个一个 Agent 配给它 ， 还比较麻烦 ， 这可能是我觉

得算是一个共识了 。 嗯 ，但我觉得今天的很多开源 Agent 的框架并不是都是围绕这些理念来构建的 ， 像 Graph 等等它还是围绕着这种 Prompt 和 Node 去做这个状态图 ， 去做路由和条件规则这种方式去构建 Agent 的开发的这种框架 ，其实目前还好像大部分主流的 Agent 框架不是为了这一层理念来原生的构建的 ， 我们在做我们的 K 系列的这个 Agent 工具链 ， 想要给大家

提供这个共识范式之下的一个新的时代所需要的一层开发的工具链 。

那你们在面向未来 ？

我们在面向终极 。

然后因为最近 Claude Code 的原代码确实泄露嘛 ， 泄露出来之后有非常多关于它的这个文章 ， 你觉得我们能从它的原码里面 Harness 这个层面啊 ， 你觉得能学到最关键的点有哪些 ？

它的压缩策略远比我们想的更加多极 ， 比如说什么时候把这个工具的一些 output 给删掉 ， 对吧 ， 然后呢包括它的压缩的时候它哪些信息保留 ， 哪些信息恢复 ，因为相当于我刚说 Agent 之间的接力棒嘛 ， 那下一个 Agent 接到这个上一个 Agent 完成到一半的任务的时候呢 ， 那上下文信息开始要准备哪些内容加载进来 ， 哪些信息是不要的 ， 哪些信息是让它自己

接着去按需去查看的 ， 它里边有非常多的一些 trade-off， 我觉得它对上下文做了很多工作 ， 记忆里边它做的其实也非常多工作 ， 包括 auto-dream 呀 ， 包括 Claude Code 现在有很多记忆特性没有对普通的用户的那个发布 ， 它有一个远程的 flag 在控制 ， 所以很多 feature 没有明显的推上来 ，Claude Code 里边记忆设计的也非常的精妙 ， 跟它的 skills 那套机制遵循了同一套哲学 ， 首先模型才是

Agent， 用户去写的那些 prompt 去组的这种提示词流的这种做法 ，chain 的链条式的做法是不 make sense 的 ， 对吧 ， 模型才是 Agent，Claude Code 是完全淋漓尽致的体现了这一点 。

第二个我们发现 Claude Code 本质上就是围绕着我如何给模型配对应的合适的工具 ， 让模型去调用 ， 对吧 ， 翻译过来不就是说你给模型去配置的这个 action 的能力 ，是给模型充分的自由嘛 ， 让它去随心所欲 ，而不是程序员每一步指定就帮它去决策你就按我这个办 ， 对吧 ， 我们过去开发 Agent 往往是喜欢在一个场景下我们设想好 Agent 在不同的情况下怎么

处理 ， 最后组成一个大的一个状态图 ， 我发现 Claude Code 完全不是这样做 。

更多的 context， 更少的 control。

更多的 context， 更多的 action 能力的提供 ， 对 ， 然后零 control，zero control 吧 ， 最多就是限制你调工具的时候你有些工具不能调 ， 对 。

当 Manus 上线的时候 ， 它其实用了一个这个云端沙箱 ， 叫 E2B， 今天可以讲一讲这个沙箱有一些什么样的进化吗 ？

从一年前到现在 。

关于沙箱我们关注也比较多了 ， 最近虽然也出了非常多的 sandbox， 把各种浏览器塞在里面做得更 all in one 更聚合的 ，但我们觉得这个领域其实目前大的进展还不多 ，以前有一些轻量级的沙箱 ， 那也是好多年初的 ， 该有的还是有 ， 我觉得我们自己做的这个就是 1KB 的 Unix computers 可能算是这个领域会是一个大的进展 ， 对 。

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

对 ， 我们做得更加极致轻量 ， 我们做的本质上不再是一个 sandbox 了 ， 它是我们语言层实现的一个数据结构 ， 就是你可以理解为它像一个 map， 对吧 ， 差不多的一个大小 。

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

我们当然做了一些 trade-off， 我们上面没有办法真实的像运行一些 GCC 编译器 ， 真的在我们这台虚拟计算机里跑这个浏览器 ， 对吧 ，有很多的需要依赖真实的这个做这个代码执行和编译的 ， 我们是做不了的 ，但是我们提供了最小化的 Unix 的这个 File system，以及最小化的这个 Unix 的 bash 的这样的一个 command 能力的一个壁纸 ， 类似于它的局域网的文件夹共享磁盘 ， 它的这个基于

Mail 的局域网的通信 ， 包括 Claude 命令局域网做相互之间通信这些能力我们都是有的 ，而且我们认为浏览器这种东西 ， 或者说 GCC 编译器等等很多重要的东西 ， 原本就不应该塞在一个生产级的一个 Agent 给它本身的配置环境中， 它就应该放在另外一个地方提供一个 infrastructure 做一个集约的服务 。

之前我们做这个自达系统的性能优化 ， 往往就是分析整个 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 中也不会被一开始就加载这个 Markdown 的全文 ， 它也是先读取各个文件名和 description， 然后呢它去判断 ， 相当于跟你实时的交互的这个过程中去更新记忆嘛 。

那第二层呢就是它有一个 auto-dream 的机制 ， 每隔一天差不多 ， 它会有一个判断条件 ， 至少大约 5 个 section， 它开始去进行这套机制去做一个更深层的记忆整理 ， 就是对最近的 section 做一个回顾 ， 用户都跟我的 Agent 去聊了什么 ， 它就会综合的去看这些最近的 section 呢去提取进一步榨干利用这些信息 ， 纠正记忆中有些错误的事实 ， 或者说不及时了需要更新的事实 ， 会

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

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

我觉得对我而言啊 ， 最大的惊喜就是记忆 ， 我读下来认为它的设计也是跟它之前 skill 的这种思想和哲学是一脉相承的 ， 格式也好呀 ， 整理维护的结构也好呀 ， 做得非常 make sense， 对我最大的这个惊喜吧 。其次就是我刚说的在关于上下文压缩的时候 ，因为 Agent 的上下文窗口满了 ， 它不可能继续干活 ， 所以本质上它做一个接力赛跑 ， 它必须传递给下

一个 Agent 了 ， 这时候传递之间它有非常多的 trade-off 的策略 ，也是我觉得它做了非常多的这种工程兜底 。

这可以展开讲讲吗 ？

因为它是一个模型 ， 模型的上下文窗口就是虽然今天还不长 ，但其实也不是说你随便丢点东西就满了 ， 现在标准的 Agent 模型都是在 256K 这个上下文长度 ， 它其实可以装下非常多的信息 ， 所以我觉得更大的就是关于上下文管理的启发就是在于上下文窗口确实装满了 ， 我再装装不下的时候 ，但是我这个任务还是要继续干 ， 你怎么给我腾出更多

的空间 ， 或者想个办法让我接着把这个任务给完成 ， 这个时候咱们看这个上下文中有什么可能垃圾或者不必要信息 ， 我们把它给上下文窗口踢掉 ， 可能又腾出来几十 K 空间 ， 我又可以再干点事情了嘛 ， 这是一种典型的策略 。

那另外一种呢就设一个阈值上限 ， 比如说乘以 0.8， 对吧 ， 它留下了 20% 的上限 ， 这时候我们交代一下吧 ， 对吧 ， 我们把我们这个任务干到什么情况 ， 接下来还要干什么 ， 总体上用户是希望我们干一个什么样的任务 ， 我们写一个文档 ， 写一下我们现在的整体的一个进展 ， 然后让下一个 Agent 开始干工作的时候呢 ，OK， 它先读一下这个文档 ， 然后去接着

工作 ， 这相当于是一种交接 ， 上下文交接的时候呢该交接什么 ，不该交接什么 ，以及下一个 Agent 的上下文初始化的时候怎么准备 ， 它里边有很多的这个很好的一个设计的 。

所以当我们聊 Agent Harness 的时候 ，其实和我们过去这一年讨论的很多 Agent 怎么做优化的工程实践 ， 它好像也是类似的 ， 对吧 ，因为 Manus 其实写过蛮多的文章 ，他们在分享他怎么做这个 context management，他们发布的时候有在讲 ， 比如说 less control，more context 等等等等 ， 听起来我们今天聊 Harness 的时候还是在聊这一套 。

对 ，在我看起来 Harness 就是比较贴近于 Agent 模型这一代之上的工程实践 ， 曾经我们有了 CPU 处理器 ， 我们才能在之上去诞生出来汇编这种东西 ， 那正是因为我们的汇编的基建的成熟 ， 我们可以在上面做语言层的抽象 ， 可以后面有 C 啊 ， 后面包括 C++ 的抽象 ， 那正是因为我们有着一代又一代的抽象 ， 我们后面才有机会去诞生出来 Python、Node.js， 才有机会诞生

出来这些 ， 比如你要开发一个全栈的项目 ， 上面的最佳实践是什么 ， 它应该用的框架是什么 ，其实我们每一层的技术的最佳实践就是迭代在曾经已有的诞生的基础上， 现在是诞生了一个新的底层的运行层 ， 就是这个模型 ， 那我们很难修改它的参数 ，在这种情况下， 我们如何围绕着上层再利用它这种智能性来做我们工程上最佳实践 ，其实我觉得反

而就是现在分享的很多东西吧 ， 都是如果你从模型的视角来出发 ， 它都是非常自然的 ， 非常符合常识和直觉的 ，但是如果说原来你只做前后端代码开发 ， 非常做那些 role-based 的东西 ， 反而你会认为哦 ， 这些最佳实践好像它为什么是这样的 ， 没道理啊 ， 它只是告诉你它是这样做的 ， 你不知道它背后的 reason 是什么 ，但是如果你去稍微思考一

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

那当我们说到一个 Agent Harness 做得好或做得不好的时候 ， 什么叫好 ， 什么叫不好 ？

上下文管理那一块就是不好的 ， 上下文管理就是它会随便去做一些中间的裁剪 ， 去扔掉一些前面的轮次 ， 或者说随意的修改系统提示词 ， 会导致这个 Prompt 的 catching 的失效 ，因为过去一到两年我发现很多开发者非常关心上下文的管理的这个问题 ，其实最好的管理就是不要做管理 ，因为你做了管理真的会导致 KV cache 失效的 ， 对吧 ， 就导致它要重新算一遍 ， 那

这是我觉得就是不好的做法 ， 就是跟模型的运行不自洽的 ， 那好的 Harness 的设计就是跟模型的运行是自洽的 ， 跟模型未来的能力的进步是正交的 ， 比如说有一些 Harness 的机制就可能我这一步让模型干什么 ， 下一步让模型干什么 ， 那是因为当时的模型能力非常弱 ， 只能做简单的问答 ， 或者说做一些简单几轮的工具调用就停下来了 ， 那这

个时候你必须基于大量的这种一个 Node 一个 Node 做这种 Graph 的做法 ，但是这个东西随着模型的进步呢 ， 这个东西就必须拆掉了 ， 要不然你就限制了这个模型的能力 ， 好的 Harness 首先要符合模型本身在运行上的逻辑 ，是符合模型未来能力进步的逻辑 ， 只要跟这两个点不 match 的就是不好的 Harness。

因为不同的 Agent 在完成同样任务的时候 ， 就有表现的好与不好 ， 即便表现的相同好的 Agent， 它可能燃烧 Token 的数量也会不一样 ， 或者完成一个任务的时间也不一样 ， 这背后是不是也是去判断 Harness 好或不好的一个标准 ？

就是首先我觉得今天还处于 Agent 模型发展的早期 ， 去年初的时候 Anthropic 开始率先转型去从问答模型这一代开始去训练智能体模型 ， 所以才有了我们今天的 Agent 模型 ，其他的包括 OpenAI 在内的很多模型厂是从 25 年的下半年， 其实已经落后了半年以后才开始从问答模型 ， 包括带有思维链的问答模型去开始追智能体模型这一代的范式 ， 所以到目前为止我认为还

是处于 Agent 模型的婴儿期 ， 很多东西都还没有收敛 ， 我觉得可能还不必要过多过快的去讨论所谓的这个 Token efficiency， 当然这个也非常重要 ，但是我觉得对我们纯调模型的使用者来说 ， 你就调 SOTA 的模型 ，其实我们的 Harness 也好 ， 我们的做事情的方法论也好 ， 只需要围绕着 SOTA 的模型以及次 SOTA 的模型去贴着它去构造和做产品做工具就可以了 。

所以 SOTA 是 Anthropic， 那次 SOTA 在你看来有哪些 ？

SOTA 是 Anthropic 吧 ， 次 SOTA 可能像 Kimi， 对吧 ， 包括我们说 MiniMax、GRM，他们最新一代的模型都算是紧贴着 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 的工具 ， 它真的可以完成很多更多的事情了 ，25 年的 3 月份的时候呢 ， 那个时候我去关注到了 GitHub 是有它

的这个 MCP 的 ， 我发现我很多的这个工作就是解放了 ， 你知道吗 ， 我不用真的自己再去打开 GitHub， 然后每次忍受我的那个页面 3 秒加载一次 ， 完全把我之前很费劲很花时间的很多工作一次弄化了 ， 然后后面呢我发现 GitHub 是有它的那个 CLI 的 ， 我会发现 GH 的 CLI 调用的时候很多能力啊任务的成功率会比用 MCP 高很多 ， 所以后面我就又把那个 GitHub MCP

给卸载掉了 ，不用了 ， 后面我就在思考这件事为什么 ， 我觉得就是 Linux 的这种命令在预训练的时候出现可能有几十亿条 ， 它的训练是非常鲁棒和充分的 ， 那 MCP 呢是最近两年才提出的概念 ， 它是一个全新的协议和抽象层 ， 首先网络预训练时候语料占比非常少 ， 可能都不到 0.1%。

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

其实的 CLI 会比之前飞书有一个那个就是插件专门配给小龙虾用的 ， 它的组合性和灵活度会更高 ， 然后它的使用任务的完成率各方面也会更高 ， 就是我会发现其实最近大家各个系统都开始开发自己的 CLI 嘛 ， 然后给用户的 Agent 去用 ， 我发现大家都开始不再提供自己的 MCP 了 ，因为 MCP 是一种最近两年出现的一种全新的定义和抽象 ，但是 Unix 这个东西 1971 年就出现了

， 那也许我们今天不应该再造更多的轮子 ， 我们不应该再做更多的协议 ， 我们就回到 Unix 这套自洽的哲学中， 然后它的训练语料就是最多最充分的 。

反哺归真 ？

所以我非常喜欢 Bash is all you need 的这句话 ， 这句话是我们 9 个月前开源我们 LangChain 那个仓库的时候写在那个上面的一个标语 。

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

我会关注就是主要有三个大的方向 ，但是我们可能自己算是其中一个 ， 就是 Harness 这一层的 Infra， 我们自己算是这一层的开发者工具链 ， 那另外两个就是关于 Agent 的组网的方向 ， 它还不是纯粹说我给小龙虾去组网 ， 给 Agent 去做组网 ， 给他们开发 App， 我可没有 ，而是我就关心下放的真正的硬件资源 ， 比如我云上是有服务器的 ， 我端侧可能有我们的 Mac 笔记本

电脑 ，有我的 Mac mini，有我的路由器 ，有我的 NAS，有我的闲置的手机 ，而他们不一定都是有公网的 IP 地址的 ， 然后它有很多的混合组网的问题 ， 那以前我们可能会用 FRP 内网穿透等等很多方案 ，但我觉得那个不太可以 scale， 然后呢其实我这方面就非常喜欢一个工具叫做 Tailscale，Tailscale 它是一个就是不管你是云上的还是边上的 ， 它的组网方式就非常的简洁 ， 全部都统一做局域网

， 这种混合组网方案我觉得在 Agent 时代非常需要 ，但 Tailscale 其实不太 Agent Native， 它在 CLI 上有很多的调用能力都没有 ， 这个赛道可能对 Agent 来说可能需要一个全新的混合组网形态 ， 尤其很多时候需要高通量的上下文交换 ， 这个交换不只是说我发一个 mail， 我发一个 IM 消息就完成了 。

这其实和这个 Agent 的支付也是一样的 ， 之前人的支付其实不需要那么高的并发 ，不需要那么碎的这个小的支付的 ，但 Agent 之间的支付很可能是比如说几分钱几分钱 ， 它特别高频的在发生 ， 所以这其实也是就是在去做 Agent payment 的这一层的这些创业公司 ，他们在讲的一个 best 的一个未来的可能的方向 。

对对 。

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

我们思考就是今天是今天 ， 就是说 Agent 这个模型在一个 baby， 我们回到 10 年后， 我们到 10 年后就是说难道每个人都是在发一个 API 请求在调用一个相同模型 ID 的机模吗 ？

那个世界也太无趣了 ， 每个人都在用 Kimi 15.0、Stromberg 的 OPS 2.0 几几的版本 ， 我觉得那就很无聊 ， 所以我在想那类似于 Thinker 的这种方案可能就很需要 ， 就是它把大量的卡然后集中在一起 ， 做这种高速互联集群 ， 然后呢通过这种集约化的设计导致我们去可以去用更低的成本和资源的开销去做这种 PFT 的训练 ， 然后就是这种高效低成本的训练 ， 就每个人

都可以得到自己的个性化训练好的模型 ， 包括其实今天光训好也还不太有用 ， 你还要推 ， 就比如说我推的时候我可能需要一个基座模型加上我个性化的模型参数那一部分 ， 那今天一个典型代表就是 LoRA 嘛 ， 那我能不能就是说我的 API 请求的过去的时候我的 header 信息中是带有我的一个 LoRA 的一个信息的 ， 那我可以 reference 它 ， 然后我还是像我发 API 请求给机模一样 ，但是

它会获取我用户池是哪个 LoRA 信息可以瞬间挂上去做一个集约化推理 ， 那这样对大家来说推的成本可能也很降低 ，因为我挂一个 LoRA 上去推 ， 那我可能多支付 5% 的成本 ，其实也不高 ，但我获得了一个可以修改模型这个参数层的一个更加个性化的体验 ， 所以我会非常 care 这个方向的进展 。

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

OpenAI 的前 CTO，他是出去做了 Thinker 那个项目 ， 对 ， 叫 Thinking Machine Lab， 然后国内好像有一些 ，但我觉得做的还不太符合 Thinker 他们那个水准在做的事情 ，因为它其实跟我们的工具链方向也很互补 ， 我就刚刚说的我们工具链上是有一个数据的 Harness， 然后你运行了半个月 ， 你上面肯定会呈现大量的轨迹 ，有 good case 和 bad case， 你要针对性做分析 ， 做迭代调优 ，但是很多时候你

没有钱没有卡去修改这个模型 ， 你只能做上下文层面的调优 ， 你没有办法去说 OK 我真的去修改这个模型的参数 ， 我去获得一个我的个性化模型 ， 它可能越来越适配我的这个 ERP 系统 ， 越来越适配我的这个 CRM 系统 ， 适配我的某个下游场景 。

你说未来你们在做的这个 K 系列就是 Agent Infra 这一波 ， 会存活很多公司吗 ？

我觉得是会是一个比较激烈的赛道 ， 我们认为就是未来 Agent Harness maybe 不需要所谓的水平差异化 ，因为它首先它要跟模型的运行是自洽的 ，其次是要跟模型未来的进步方向是自洽的 ， 所以我觉得从这两个角度来看 ， 如果同时要自洽这两个点 ， 那么就是大概率它的结构设计上不会存在太多的派系 ， 应该最多就是比如说我们比较站这个 Unix 以及 Shell

这一派 ， 给它提供一个 Unix 的 Computer 这个派系上， 然后做虚拟把性能做到极致 ， 然后做到数据结构上做到语言层面 ，而不是下放到原来的 Docker 等等很多 sandbox 层面 ，但是我觉得可能有一些其他派系说 OKTS is all you need， 对吧 ，他们走 TypeScript， 然后去做这种严格的极化控制 ， 这可能会是另外一个派系 ， 可能 maybe 派系不会太多 。

那是出于什么原因你预感到这个又很激烈的话 ， 最后其实这个可能两年之后 maybe 这个赛道都没了 ， 还是要去做这个事情呢 ？

我们不是最近进入这个赛道 ， 我们过去做了将近一年的就是这个事情 ， 现在我们只是在去演进去做我们的二代 ， 就把这个事情就是做得更加的自洽和更加的站在终点上去考虑 ， 回过来去考虑整套事情的做法 ， 我自己创业的初心吧 ， 每个公司会有自己的一个 slogan， 然后我们的 slogan 是加速世界升级 ， 就是说这件事情在当前阶段内是不是对这个世界

在当前阶段内的最大有效的加速 ，maybe 下个阶段会有下个阶段进行加速 ， 比如说某个时间点造更好的火箭或者更好的核聚变手段是对世界最大的加速升级 ，但当前这个趋势阶段内我们可以看到如何让这个地球上充满 agents， 让 agents 成为社会基础设施 ， 尤其是让 coding agent 成为整个社会的一种 infra， 然后未来社会上整个星球上可能有比人类多几百倍的这个 agents 运行在这个地球

上， 那你怎么去 serving 他们 ， 支撑他们 ， 支撑他们自己去开发 agent， 创建 agent， 去 fork agent， 那是一个非常 crazy 的世界 ， 支撑他们的 infra 和工具链到底是什么样子的 ， 我们其实在思考和支撑做这样一件事情嘛 ， 所以就回到我们的这个 slogan 加速世界升级 ， 这是我们的做事情的发心和这个人最初的愿景 。

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

其实我觉得 agent 的未来样子已经非常清晰了 ， 就是或者至少当前技术阶段内算是非常清晰了 ， 我觉得就是这个领域还很早期 ， 所以 agent 这个模型这个阶段可能 maybe 又会持续 3 年左右 ， 预测未来的话 ， 现在更多的 agent 是一个单体的 agent， 我觉得下一步是这个 agent 蜂群机器人化的作业 ， 现在是很多人对 agent 做手动的管理和编排 ， 就是协调 100 个 agent， 那

下一步应该是 agent 自己去管理和协调更多的 agent，agent 会在训练的时候加入 agent 的这个协调和编排 ， 然后再到未来就是说现在 AI 其实很难去做发明任务的 ， 那就是它如何做一个发明者 ， 它可以自动迭代的提出更多的新的科研方案去做这种实验啊 ， 如果它能自己做发明和对齐 ， 完全用 agent 驱动很多公司的运行 ， 那我觉得以后的公司其实更多意义上是一种理

财产品 ， 公司不是由人组成的公司 ，因为所谓的公司不就是这个公司要做一件事情 ， 它有它的输入和输出 ， 那它中间里边是怎么运行的 ， 大部分客户并不会天天跑你公司的那个 office 里盯着你干 ， 所以说公司内部是一个黑盒 ， 那我觉得 agent 以后可以完全组成 agent 公司 ，以后就是零人公司 ， 我从来不觉得一人公司是本质的事情 ， 我认为真正 make sense 是零人公司 。

真格和十字路口最近发起那个 Token Grant 嘛 ， 然后我们最近 grant 了一个项目叫 Yoyo Agent， 我觉得它也可以认为是一个零人公司 ，因为它的这个创作者把它这个 agent 做出来之后就把它丢进汪洋大海了 ， 就从此不再改它一行代码 ，也不给它一分钱 ， 它要自己去进化 ， 要自己去想办法搞到钱来 ， 这个给自己买 Token， 然后它有一个目标 ， 这个目标就是有一天超越 Cloud Code， 然后

它不断的进化自己 ， 然后它怎么这个来赚钱呢 ？ 它现在赚钱的方法就在 GitHub 上面开打赏去画圆 ， 让大家给它捐钱 ， 那所以我们 Token Grant 就是给它捐了第一笔钱 ， 让它开始有 Token 有养料可以去进化 ，其实在今天还是很早期 ，但未来这个某种意义它也是一个零人公司 ， 然后今天我们给它捐的一些钱当然没有占它的股权 ，但在未来可能这个经济体系越来越发达 ，

可能大家投资的标的就不再是一个一个的这个今天的人类造成的公司 ，而是一个一个的 agent。

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

好的 ， 这个未来想一想这个又有点兴奋又有点这个可怕 。

我觉得开玩笑的 。

好呀 ，OK 好 ， 今天谢谢新璐 ， 十字路口 ， 好 ， 谢谢 ， 好 ， 拜拜 ， 拜拜 。