【十字路口】探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐【视频播客】

嗨 ， 我是科杰 。 那最近大家都在讨论 Agent Harness，Agent 的上限是由 Harness 去决定的 。 可是当我们聊到 Harness 的时候 ， 我们到底在聊什么 ？ 不久之前呢 ，Claude Code 的源代码被泄露 ， 啊 ， 所以许多 Agent Harness 的关键模块也被完整地呈现了出来 ， 成为了非常好的一个教学样本 。 那今天呢 ， 我们请到的嘉宾是新璐 ， 新璐是 ShareAI 的创始人 ， 然后他们做了一个教程 Learn Claude

Code， 啊 ， 这是一个在 GitHub 上面现在已经有超过五万颗星的教程 。 呃 ， 你好 ， 新璐 ， 欢迎来到狮子路口 。

Hello， 感谢科杰老师的邀请 。

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

二十三 。

毕业院校 。

河南工业大学 。

然后 MBTI 和星座 。

INTP， 啊星座我不太关注 。

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

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

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

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

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

我们刚 close 了三百多万美金 。

目前的团队规模 。

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

收入和利润呢 ？

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

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

呃 ， 我是在一些大厂和研究院做一些 AI infra 的相关工作 。

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

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

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

我对这个话赞成一半吧 。 首先 Agent 的智力的上限提升肯定还是模型层面的发展嘛 ， 因为 Agent 其实是一个模型 ， 那模型越聪明肯定它越好 。 我们看到现在其实大部分模型智力也都比较够用了 ， 把模型比成人的话 ， 我们智商在一百二到一百七之间 ， 啊 ， 但是我们可以通过去健身 ， 去学舞蹈 ， 然后去修习武术 ， 去穿上这个机甲来

作业 ， 来让我们自己更加强大 。

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

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

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

呃 ， 其实应该有九个月前了吧 。

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

我们当时的想法就是 Claude Code 是非常强大的 ， 呃 ， 那你只要把 Claude Code 套一个网页 ， 对吧 ， 你其实应该会得到一个非常强大的一个 Agent 产品 。 所以我们就可以做给开发者用的工具链 。 但是开发者可能比较熟悉过去像 LangGraph、LangChain 这种 ， 呃 ， 这种一些基于 prompt、 基于 node 和这种 flow 的方法的 ， 就是有点像派系之争吧 。 每次我在大家跟说这一条的时候 ，

然后很多人可能不太相信 Harness， 当时其实还不叫 Harness， 就是可能叫 Agent 框架 ， 对吧 ，Agent runtime 这样的词 。

嗯 。

呃 ， 就觉得很多地方我可能不太好控制 ， 那他们更喜欢加上很多 prompt 节点 ， 然后自己可以流转和控制 ， 然后成本又低又可控 。 所以我觉得这是一个 ， 呃 ， 思想范式争论 。 所以我们当时做了这个资料 ， 然后放出去 ， 其实也是知道我们构建 Claude Agent 的心法 。

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

像 prompt flow 就是基 ， 基于 prompt 提示词节点做流转和控制那一套方法论 ， 可能就是未来的 Agent 开发过程中越来越不适用了 。 然后呢 ， 这种基于 CC 这种 Agent-native 的 ， 就是 Agent 集模型 、 模型集 Agent 的这种方法和思想去做事情 ， 包括 by 师父造由你的这种范式会越来越清晰 ， 会被更多人去采用 。

嗯 ， 然后在我们录播客的前几天啊 ，Claude 正好推出了这个 Managed Agents， 然后也就是把它自己做 Agent Harness 的这一套给开发出来给大家用了 。 啊岂不说这个更早之前它的源代码也泄露了嘛 。 那既然现在比如说我要开发一个 Agent， 我就可以直接用 Claude Managed Agents。 啊那大家还有必要自己去搭 Harness 吗 ？ 甚至还有必要去了解 Harness 的细节吗 ？

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

但这个就像云服务器一样吧 ， 云服务刚出来的时候 ， 可能工程师也会说 ， 哎呀 ， 不能直接就调它的 API 呀 ， 我们也要去搞明白这个服务器的这个方方面面的 infra。 但到后面你发现其实百分之九十九的工程项目根本就不需要 。 所以我想这个会不会在 Agent Harness 这个层面也是一样呢 ？ 我们今天虽然这一期播客还没开始聊 ， 我们要讨论 Harness，

要让大家学习 Harness， 但会不会有一天其实根本就不需要学了 ， 大家直接用 Claude Managed Agents 的服务就够了 。

如果从整个推演角度来看 ， 肯定未来会有那么一天 ， 就像大家今天去比如开发很多这种全站的这种 Web 应用 ， 都有 NextJS 这个框架 ， 但你不会知道 NextJS 里面怎么设计和工作 ， 它的原理是什么 。 大部分人可能不 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， 你是面对一百个 agent， 就像你一人公司有一百号员工 ， 你怎么去组

织他们协调起来 ， 按照某种组织架构 、 某种协作方式和传递顺序去把一个复杂的一个事情给解决掉 。 那第二层呢 ， 就是说你针对这一百个人 ， 对吧 ， 他每个人有不同的岗位的访问权限 ， 其实也会有很多这种关于权限治理 ， 关于信息的提供和隔离 ， 很多这种就是治理的方面问题 。

啊 ， 所以这三层一个是执行能力层 ， 然后一个是上下文的这个环境层 ， 还有一个是治理 、 编排 ， 就管理这一层 。 那我们要不要用一个例子来串一串这三层啊 ， 就一个具体的 agent 的任务 ， 它的背后 harness 的三层是怎么发挥作用的 。

之前有一个知名的例子 ， 就是说 ， 啊 ， 就是用两周去协调大量的 agents， 从零到一构建了一个 CPA 器 ， 它通过这个非常多的 agents 交替完成任务 ， 自迭代就把这个任务给完成了 。 那我觉得这是一个很好的 case。 那首先 ， 呃 ， 我们说首先 agent 的最底层是一个模型 ， 对吧 ？ 模型就像大脑和心脏一样 ， 它要去驱动整个任务的 ， 呃 ， 这个完成 ， 那

它要有 action 能力 ， 所以说你至少要给它配置这个类似于文件的增 、 删 、 读 、 写 、 搜索啊等等这样一些 ， 呃 ， 这样对应的工具能力 ， 就是 action 能力 ， 就是我说的 harness 的第一层 ， 你给模型提供的能力 ， 那么模型才有机会去写代码 、 去创建文件 ， 修改它前面创建过的文件 。 那第二层呢 ， 就是上下文状态这一层 。OK， 那我模型是不是要知

道我现在是在一个什么样的环境中去工作 ， 然后呢 ， 我的路径是什么 ， 我这上面装有哪些依赖 ， 对吧 ？ 然后我已经写的文件夹的结构是什么 ， 对吧 ？ 然后包括了我的 Git 信息 ， 以及 ， 呃 ， 就是那它的模型上下文窗口非常满 ， 因为我们知道一个 CPA 器是一个很大很大的工程量 ， 它不可能在一个模型的上下文窗口中去直接去做

完 ， 就是而不装满 ， 它要有一些上下文的这个卸载啊 、 策略 ， 包括就是说我们刚刚说的上下文窗口满以后 ， 下一个 agent 再去工作 ， 它要去 ， 呃 ， 重新去读一下 ， 哎 ， 我当时环境信息是什么 ， 哎 ， 前面已经写了代码 ， 写到哪了 ， 接下来我要进行什么 。 在我这一轮的生命周期里 ， 做到某个阶段 ， 我再会写类似的这个文档 ， 去

委托我当前的上下文状态 ， 再交给下一个 agent 它 。 这样一次的接力呢 ， 最后呢 ， 呃 ， 去把这个整个 CPA 器给写完 。 它不是一个单纯的 action 能力层就能完成了 ， 它还是需要上下文环境的 。 对 ， 然后第三层呢 ， 就是这个编排和治理层嘛 ， 如何去指导这些 agent 之间去做一个传递和委托 ， 包括我的写代码 agent 和测试 agent 之间的关系 ， 包括这

个任务中难道一定每个环节都是串行的关系吗 ？ 我只能有一个 agent 接着一个 agent 就完成吗 ？ 我是不是有很多模块我是可以并行的去写的 ， 可以同一时间有多 agent 去做这个任务 ， 它们之间的协调关系是什么 ？ 啊 ， 就是这会涉及到编排的一个问题 ， 以及就是说那不同的 agent 它的权限怎么样 ， 我去做测试的 agent 是不是应该有这个测试环

境 ， 包括测试工具 ， 它对应的权限 ， 它不应该在测试的时候对着我的这个代码 ， 它一边测一边修改 ， 说 ， 哎 ， 我测不过 ， 我把那儿修改一下就好了 ， 然后它一直在 hack 这种 pass， 对吧 ？ 所以说这里边会有很多的这种 ， 呃 ， 权限的治理 ， 包括上层的这种协调关系的编排的一些问题 ， 这属于第三层 。

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

这三层到目前我并没有觉得有封装得非常好的 ， 因为我们觉得这个范式变化太快了 。 从二二年底 ChatGPT 的发布 ， 再到现在类似于 CC 这一套背后这种 agent 智能体模型的这一套范式 ， 模型被训练了完成长程任务 ， 也就是最近半年左右才开始出现 。 呃 ， 所以开源社区我其实也观察了很多吧 ， 就是没有看到太让我满意的这一层 ， 所以

也是我们自己在做这一层的原因吧 。

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

我们在做这一层呢 ， 围绕刚刚说的 agent 的三个层面 ， 我们去提供了一个完整的工具链 。 啊 ， 首先我们最底层是一个叫 Computer 的一个工具链 ， 就是它是取 Computer 那个 C 的那个字母变成 K， 叫 Computer， 它是一个我们在 ， 呃 ， 数据结构上实现的一台 Unix 计算机 。 啊 ， 就是你可以理解为我们在内存中实现了一台虚拟的计算机 ， 它给我们像小龙虾 ， 包

括 Claude Code 等等这种下一代的一种主动式的 agent， 它有它的自迭代性 、 成长性 ， 我们要给这种 agent 配一个它的执行环境 ， 去让它在那个环境里去生活和工作 。 啊 ， 然后呢 ， 这是我们提出的 ， 我们认为 Unix 的计算机可能就是对它最好的居住和生活的环境 。

所以 ——

我们做的第一层是这个 ， 对 。 然后我们上层呢 ， 会有一个叫 KRuntime 的东西 ， 它是一个 Agent Runtime 这一层 ， 我们会相当于提供了给开发者去开发 Agent 对象的非常多的接口 ， 语法糖上的一个封装 。 除了这一层呢 ， 我们还会有其他可能跟大家正交的层面 ， 比如说像啊 KWatch， 对吧 ， 就是我的观测 ， 比如说过去半个月 ， 我的 Agent， 它们分别在任务完成

， 在什么情况下遇到卡点了 ， 对吧 ， 它这样就可以指导我去观测 ， 诶 ， 是不是我的 CLM 没有设计好 ， 还是我的 Skill 没有提供到位 ， 还是说我用的模型不太行 。OK， 一个时候观测层就很重要了 。 呃 ， 以及我们基于观测层的话 ， 可以对数据做导出 。 导出以后呢 ， 我们会有一个叫 KL 的一个工具链 ， 你可以把这个数据拿来强化学习去训

练你的模型 ， 或者说你说 OK， 我不想练我自己的模型 ， 我就想用一个标准的模型的 API 去请求那个积木 ， 我们也可以对你做这个上下文层面 ， 比如关于 memory 啊 ， 关于 skills 呀 ， 关于过去的一些经验的提取和自底带的一个 ， 就是你可以理解为穷人版的强化学习 。

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

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

进一个 Linux 的 ， 对吧 ？ 你的微信小程序一个 package 可能也才几兆的大小 。 我们希望就是说在所有的能跑 JS 的场景 ， 无差别地给你提供一个类似于上个时代 Voe Rack 的那一层的一个工具链框架 ， 你就 import 它就直接用好了 ， 就是它的 ， 呃 ， 就是心智非常的统一和简洁优雅 ， 然后它背后的性能占有也非常极致 ， 就是 ， 呃 ， 就只有 1KB 那么大

小的一个 Unix 的 computer， 然后给你的 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 这种的 ， 就是一个语言解释器层 ， 啊 ， 我觉得这是 ， 呃 ， 大部分情况下 ， 你配好这些工具 ， 它应该就是可以满足我们可能百分之九十五以上的这个 Agent 的任务了 。

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

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

是这样的话 ， 会有很多的这种中间的 trade-off， 就是你的 Agent 的工具链的设计要紧密地跟 Agent 的角色绑定 ， 去 limit 它 ， 调它底层对这台 Unix 的计算机的操作能力 。

那我们刚才说到这个第二层上下文与状态层 ， 在环境层的时候 ，memory 就记忆是非常重要的 。

嗯 。

然后现在也可以看到有不同的这个记忆 ， 不管是这个 ， 呃 ， 模型厂原生也有一些记忆的功能 ， 对吧 ？ 然后也有三方的一些开源的一些插件 ， 它会给记忆的解决方案 。 然后可不可以给大家讲一讲 ， 现在你认为 Agent harness 的 memory 这一层有哪些就是主要的解决方案 。

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

成不同节点的表示 ， 然后它们之间再做关联 ， 然后检索和扩展 ， 那这种方式是非常结构化信息规则式做法的 。 啊 ， 当然我个人其实不太喜欢这种做法 ， 然后我更喜欢的是像后者这种半规则式的 ， 就是可能我底层是一个 Unix 的 files， 我就是通过大量的 Markdown 的方式来存储这种 ， 呃 ， 资料信息 。 其实 Claude Code 也是这样做的 ， 小龙虾其实里

面也是这样做的 ， 它可以通过一些类似于其他的空间关系 ， 比如说像迷宫这种走势 ， 这是最近生化危机的那个女主最近做得特别红的那个 AI 项目 。 这种其实就是底层找一种大家都公认的非常清晰的文档 、 文件夹的方式 ， 我有房间和空间位置关系 ， 就是 ， 呃 ， 人也很容易懂 ， 这个 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 Gary Tan 也把他自己的个人的记忆开源出来了 。

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

成了 。 所以我觉得所有目前关于 skill 这一波子代代自进化也好 ， 它最早的起源就是在 Claude Code 里边 Insight 那个特性 ， 包括最近像 Hermes Agent 也非常火嘛 ， 它有点更像是类似于 memory 层面的一个里边的迭代和进化 ， 这个关键词背后有很多它们交集的区域 ， 中间那个地带你很难说得清楚 ， 它属于是经验 ， 就偏 memory 那一部分 ， 还是偏标准化了 ， 可传

播 、 可分享 skill、SOP 那一部分 ， 中间交集其实还蛮大的空间 。 对 ， 但总体来说其实可以理解为它们都是上下文的层面 。

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

们的想象力 ， 甚至会限制我们团队对自己的想象力 。 我觉得刚才我们在讲说 ， 我们现在聊到的一些这个 harness 的实践 ， 它到底应该算 memory 还是算 skill， 可能聊这个定义没那么重要吧 ， 可能我们更重要的是 agent 怎么可以这个不断地自己学习 、 进化 ， 就这个实践本身实现它的目标是重要的 。

对 ， 标签没那么重要 。

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

共识可能就是说我们现在说 batch 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。 我觉得它对上下文做了很多工作 ， 记忆里边它做的其实也非常多工作 ， 包括 AutoDream 呀 ， 包括 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 computer 可能算是这个领域 ， 或者会 ， 会是一个大的进展 ， 对 。

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

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

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

我们当然做了一些 trade-off， 我们上面没有办法真实地像运行一些 GCC 编译器 ， 真的在我们这台虚拟计算机里跑这个浏览器 ， 对吧 ？ 有很多的需要依赖真实的这个 ， 呃 ， 做这个代码执行和编译的我们是做不了的 。 但是我们提供的最小化的 Unix 的这个 file system， 以及最小化的这个 Unix 的 Bash 的这样的一个 command 能力的一个闭集 ， 类似于它的局域网的

文件夹 、 共享磁盘 ， 它的这个基于 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 中也不会被一开始就加载这个 ， 这个 Markdown 的全文 ， 它也是先读取各个文件名和 description， 然

后呢 ， 它去判断 ， 相当于跟你实时地交互的这个过程中去更新记忆嘛 。 那第二层呢 ， 就是它有一个 auto dream 的机制 ， 每隔一天差不多 ， 然后它会有一个判断条件 ， 至少大约五个 section， 它开始去进行这套机制 ， 去做一个更深层的记忆整理 ， 那就是对最近的 section 做一个回顾 ， 用户都跟我的 agent 去 ， 呃 ， 聊了什么 ， 它就会综合地去看这些

最近的 section 呢 ， 去提取 ， 进一步榨干利用这些信息 ， 纠正记忆中有些错误的事实 ， 或者说 ， 呃 ， 不及时的需要更新的事实 ， 为记忆做一些合并和整理 。 你可以理解为它每隔天定时地开启一个后台 agent 呢 ， 对最近的会话信息做一遍重放 ， 就像我们做梦一样 ， 做重放 ， 做信息整理 ， 就是这么两套的 agent 的机制 。 对 。

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

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

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

这可以展开讲讲吗 ？

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

还是要继续干 ， 你怎么给我腾出更多的空间 ， 或者想个办法让我接着把这个任务给完成 。 这个时候咱们看这个上下文有什么啊 ， 可能垃圾或者不必要信息 ， 我们把它给上文窗口能踢掉 ， 可能又腾出来几十 K 空间 ， 我就可以再干点事情了嘛 。 这是一种典型的策略 。 那另外一种呢 ， 就是这个阈值上限 ， 比如说乘以零点八 ，

对吧 ， 它留下了百分之二十的上限 ， 这时候我们交代一下吧 ， 对吧 ， 我们把我们这个任务干到什么情况 ， 接下来还要干什么 ， 啊 ， 总体上用户是希望我们干一个什么样的任务 ， 我们写一个文档 ， 啊 ， 写一下我们现在的整体的一个进展 ， 然后让下一个 agent 开始干工作的时候呢 ，OK， 他先读一下这个文档 ， 然后去接着工作 ， 这相

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

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

对 。

因为 Manus 其实写过蛮多的文章 ， 他们在分享怎么做这个 context management， 他们发布的时候也在讲 ， 比如说 less control，more context 等等等等 。 听起来我们今天聊 harness 的时候 ， 还是在聊这一套 。

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

Python、Node.js， 才有机会诞生出来 ， 这些比如说你要开发一个全栈的项目 ， 上面的最佳实践是什么 ， 它应该用的框架是什么 ， 其实我们每一层的技术的最佳实践就是叠戴在曾经已有的诞生的基础上 ， 现在是诞生了一个新的底层的运行层 ， 就是这个模型 ， 那我们很难修改它的参数 。 在这种情况下 ， 我们如何围绕着上层 ， 在利用它这种

智能进行来做我们工程上的最佳实践 。 其实我觉得反而就是现在分享的很多东西吧 ， 都是如果你从模型的视角来出发 ， 它都是非常自然的 ， 非常符合常识和直觉的 。 但是如果说原来你只做前后端代码开发 ， 非常做那些 raw base 的东西 ， 反而你会认为 ， 哦 ， 这些最佳实践好像 ， 它为什么是这样的 ？ 没道理啊 ， 它只是告诉你它

是这样做的 ， 你不知道它背后的 reason 是什么 。 但是如果你去稍微思考一下 transformer 模型 ， 就是自回归的怎么在运行 ， 它的推理是怎么样 ，agent 模型到底怎么工作 ， 你再结合这个来思考所有的那个 agent 的最佳实践的工程范式 ， 包括之前 Manus 讲的那些东西 ， 你就觉得 ， 哎 ， 非常 make sense， 我上层代码调的时候就应该符合它的工作逻辑 。

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

上下文管理那一块 ， 就是不好的上下文管理 ， 就是它会随便去做一些中间的裁剪 ， 去扔掉一些前面的轮子 ， 或者说随意的修改关键词提词 ， 会导致这个 prompt 的 catching 的失效 。 因为过去一到两年 ， 我发现很多开发者非常关心上下文管理的这个问题 ， 其实最好的管理就是不要做管理 ， 因为你做管理真的会导致 K 开始失效的 ， 对吧

， 就导致它要重新算一遍 。 那这是我觉得这是不好的做法 ， 就是跟模型的运行不自洽的 。 那好的 harness 的设计就是跟模型的运行是自洽的 ， 跟模型未来的能力的进步是正交的 。 比如说有一些 harness 的机制 ， 就可能我这一步让模型干什么 ， 下一步让模型干什么 ， 那是因为当时的模型能力非常弱 ， 只能做简单的问答 ， 或者说做一些

简单几层的工具调用就停下来了 。 那这个时候你必须基于大量的这种一个 node， 一个 node 做这种 graph 的做法 ， 但是这个东西随着模型的进步呢 ， 这个东西就必须拆掉了 ， 要不然你就限制了这个模型的能力 。 好的 harness 首先要符合模型本身在运行上的逻辑 ， 是符合模型未来能力进步的逻辑 ， 只要跟这两个点不 match 的都是不好的 harness。

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

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

的范式 。 所以到目前为止 ， 我认为还是处于 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。 当然很多 developer 今天不太 buy in 这个观点 ， 但是我自己是非常信这个观点的 ， 我认为 Agent 从始到终都是一个模型 ， 啊 。 然后呢 ， 所以说模型是我会排重要性第一位的 ， 就是说如果你的 Agent 任务表现不好 ， 换一个更强的模型就好了 ， 就大

概率就能提升很多 。 然后 ， 呃 ， 其次我觉得上下文其实是一个非常开放的概念 ， 比如说它工作在什么样的文件夹里 ， 或者它是工作在 Windows 上还是 Linux 上 ， 对吧 ？ 然后呢 ， 包括它能够用哪些工具 ， 这些工具是 CLI 的形式给它的 ， 还是用 MCP 形式给它的 ， 这个也属于执行层面能力上下文嘛 。 然后呢 ， 包括 skills， 包括 memory， 啊 ， 包括上 ， 上一

轮那个 Agent 干完干满了 ， 它要传一个接力棒交给下一个 Agent 继续干 。 所以我觉得上下文是一个 ， 呃 ， 也是非常重要的部分吧 。

第二重要 。

对 ， 第二重要的部分 。 其实对用户视角来说 ， 上下文才是最重要的 。 但是其实因为模型 ， 我们大部分人没有上千卡的集群嘛 ， 所以我们做不了这个模型参数的修改 ， 我们能做的空间呢就更多在上下文这一层面 。 然后第三个就是这个工具 ， 如果你给它配一些 powerful 的工具 ， 它真的可以完成很多更多的事情了 。25 年的三月份的时

候呢 ， 那个时候我去关注到了 GitHub 是有它的这个 ， 呃 ，MCP 的 ， 我发现我很多的这个工作就是解放了 ， 你知道吗 ？ 就我不用真的自己再去打开 GitHub， 然后每次忍受我的那个页面三秒加载一次 ， 完全把我之前很费劲 、 很花时间能做的工作自动化了 。 然后后面呢 ， 我发现 GitHub 是有它的那个 CLI 的 ， 我也发现 GH 的 CLI 调的时候 ， 很多能力啊 、

任务的成功率会比用 MCP 高很多 ， 所以后面我就 ， 呃 ， 又把那个 GitHub MCP 给卸载掉 ， 不用了 。 后面我就在思考这件事为什么 ， 我觉得就是 Linux 这种命令在预训练的时候出现可能有几十亿条 ， 它的训练是非常鲁棒和充分的 。 啊 ， 那 MCP 呢 ， 是最近两年才提出的概念 ， 它是一个全新的协议和抽象层 ， 此前网络预训练的时候语料占比非

常少 ， 可能都不到百分之零点一 。

FeatCode CLI 最近也很火嘛 。

对 。

你用下来感觉怎么样 ？ 比起 MCP 是不是也要好一大截 ？

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

义和抽象 ， 但是 Unix 这个东西一九七一年就出现了 ， 那也许我们今天不应该再造更多的轮子 ， 我们不应该再做更多的协议 ， 我们就回到 Unix 操 ，zsh 之学中 ， 然后它的训练语料又是最多最充分的 。

返璞归真 。

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

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

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

可能有我们的 MacBook 笔记本电脑 ， 有我的 Mac mini， 我的路由器 ， 有我的 NAS， 有我的闲置的手机 ， 而它们不一定都是有公网 IP 地址的 ， 然后它有很多的混合组网的问题 ， 那以前我们可能会用 FRP、 内网穿透等等很多方案 ， 但我觉得那个不太可以 scale。 然后呢 ， 其实我这方面就非常喜欢一个 ， 呃 ， 一个工具叫做 Tail Scale。 啊 ，Tail Scale 它是一个 ， 就是不管

你是云上的还是边上的 ， 它的组网方式就非常的简洁 ， 全部都统一组局域网 。 这种混合组网方案我觉得在 Agent 的时代非常需要 ， 但 Tail Scale 其实不太 Agent native， 它的 CLI 上有很多的调用能力都没有 。 这个赛道可能对 Agent 来说可能需要一个全新的混合组网形态 ， 尤其很多时候需要高通量的上下文交换 ， 这个交换不是说我发一个 mail， 我发一个

IM 消息就完成了 。

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

对 ， 对 。

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

我们思考啊 ， 就是今天是今天 ， 就是说 Agent 这个模型在一个 baby， 我们回到十年后 ， 啊 ， 我们到十年后 ， 就是说难道每个人都是在发一个 API 请求 ， 在调一个相同模型 ID 的基模吗 ？ 那个世界也太无趣了 ， 每个人都在用 Kimi 15.0，Claude Opus 点零几点几的版本 ， 我觉得那就很无聊 。 所以我在想 ， 那类似于 TCard 的这种方案可能就很需要 ， 就是它把大

量的卡然后集中在一起 ， 做这种高速互联经营的集群 ， 然后呢 ， 通过这种集约化的设计 ， 导致我们去 ， 可以去 ， 呃 ， 用更低的成本和资源的开销去做这种 ， 呃 ，PFT 的训练 ， 然后就是这种高效低成本的训练 ， 就每个人都可以得到自己的个性化训练好的模型 。 包括其实今天光训好也还不太有用 ， 你还要推 。 啊 ， 就是比如说我

推的时候 ， 我可能需要一个基座模型 ， 加上我个性化的模型参数那一部分 ， 那今天一个典型代表就是 LoRA 嘛 ， 那我能不能就是说我的 API 请求的过去的时候 ， 我的 header 信息中是带有我的一个 LoRA 的一个信息的 ， 那我可以 reference 它 ， 然后我还是像我发 API 请求给基模一样 ， 但是它会获取我用户是 ， 是哪个 LoRA 信息 ， 可以瞬间挂上去做一个

集约化推理 ， 那这样对大家来说推的成本可能也很降低了 ， 因为我挂一个 LoRA 上去推 ， 那我可能多支付百分之五的成本 ， 其实也不高 ， 但我获得了一个 ， 一个可以修改模型这个参数层的一个更加个性化的体验 ， 所以我会非常 care 这个方向的进展吧 。

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

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

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

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

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

我们比较占这个 Unix 以及 Shell 这一派 ， 来给它提供一个 Unix computer 这个派系上 ， 然后多虚拟 ， 把性能做到极致 ， 然后做到数据结构上 ， 做到源头层脸 ， 而不是 share 到原来的 Docker 等等很多 sandbox 层面 。 但是我觉得可能有一些其他派系说 OK，TS 也走你的 ， 对吧 ？ 他们走 typesuit， 然后去做这种严格的计划控制 ， 这可能会是另外的派系 ， 可能 maybe 派系不会太多

。

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

嗯 。

还是要做这个事情呢 ？

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

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

社会上 ， 整个星球上可能有比人类多几百倍的这个 agents 运行在这个地球上 ， 那你怎么去 serving 他们 ， 支撑他们 ， 支撑他们自己去开发 agent 的 ， 创联 agent 的 ， 去 fork agent 的 ， 那是一个非常 crazy 的世界 。 支撑他们的 infra 和工具链到底是怎么样子的 ？ 我们其实在思考和支撑做这样的一件事情嘛 。 啊 ， 所以就回到我们的这个 slogan， 加速世界升级 ， 这也

是我们的做事情的发心和这个人最初的愿景 。

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

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

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

运行 ， 那我觉得以后的公司其实更多意义上是一种理财产品 ， 公司不是由人组成的公司 ， 因为所谓的公司不就是这个公司要做一件事情 ， 它有它的输入和输出 ， 那它中间里边是怎么运行的 ， 大部分客户并不会天天跑你公司的那个 office 里盯着你干 ， 所以说公司内部是一个黑盒 ， 那我觉得 agent 以后可以完全组成 agent 公司 ， 以后就

是零人公司 。 我从来不觉得一人公司是本质的事情 ， 我认为真正 make sense 的是零人公司 。

真格和十字路口最近发起那个 Token Grant 嘛 。

啊 。

然后我们最近 grant 了一个项目叫 uUagent， 我觉得它也可以认为是一个零人公司 ， 因为它的这个创作者把它这个 agent 做出来之后 ， 就把它丢进汪洋大海了 ， 就从此不再改它一行代码 ， 也不给它一分钱 ， 它要自己去进化 ， 要自己去想办法搞到钱来 ， 这个给自己买 token。 然后它有一个目标 ， 这个目标就是有一天超越 Claude Code， 然后它不断地进化自

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

济体系越来越发达 ， 可能大家投资的标的就不再是一个一个的这个今天的人类造成的公司 ， 而是一个一个的 agent。

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

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

开个玩笑 。

好呀 ，OK， 好 ， 今天谢谢新璐 。

好呀 。

十字路口 。 嗯 ， 好 ， 谢谢 。 嗯 ， 好 ， 拜拜 。

拜拜 。