「Agent Harness」是「套壳」的另一种说法。

🚥 不久前,Claude Code 源代码泄露,许多 Agent Harness 的关键模块得以完整呈现,成了一份极佳的教学标本。而在技术高速变化的红利期,主动理解新技术往往能带来很高的认知增量。
因此,本周「十字路口」邀请到来新璐,一起聊聊 Agent Harness。新璐是 ShareAI 开源社区发起人,他撰写维护的《Learn Claude Code》教程在 GitHub 上获得超过 50k Star。

在本期内容中,我们把 Agent Harness 从概念词拆解成工程语言,介绍它的三层框架:会跑(执行层)→ 跑久(状态层)→ 跑稳(治理层)。
同时,我们也梳理了 Claude Code 中值得借鉴的多个机制:更多 context、更少 control 的思路、“零上下文管理”的哲学、长程任务的接力式交接策略,以及让 Agent 越用越聪明的“做梦”式记忆维护与迭代机制等
新璐作为典型的一人公司,刚完成数百万美金融资;他也分享了自己对 OPC 的独特观点,甚至认为“未来只有 0 人公司,没有 1 人公司”,颇具启发。
微信收听播客:

小宇宙收听播客:




🎬 视频播客已同步上线于 @Koji杨远骋 的视频号、小红书、哔哩哔哩、Youtube 等平台
👦🏻 Koji
我们照旧还是从快问快答开始。请问新璐你的年龄。
👨🏻💻 来新璐
23。
👦🏻 Koji
毕业院校。
👨🏻💻 来新璐
河南工业大学。
👦🏻 Koji
MBTI 和星座。
👨🏻💻 来新璐
INTP,星座我不太关注。
👦🏻 Koji
一句话介绍一下自己的公司和产品。
👨🏻💻 来新璐
我现在在做一个 KB 级的 Agent Komputer 工具链,是给开发者开发 Agent 用的开源工具链。
👦🏻 Koji
再用一句话介绍一下《Learn Claude Code》这个教程是什么?
👨🏻💻 来新璐
我们认为 Claude Code 是最好的 Agent Harness。所以我们想,要学 Agent Harness,那干脆就做一个资料仓库来解析 Claude Code Agent 的设计模式。
👦🏻 Koji
目前的团队规模?
👨🏻💻 来新璐
团队非常精悍,主力就是我,然后我有两个实习生。
👦🏻 Koji
收入和利润呢?
👨🏻💻 来新璐
新的创业方向,刚开始还没有收入。
👦🏻 Koji
创业前在做什么?
👨🏻💻 来新璐
在一些大厂和研究院做 AI Infra 的相关工作。
机甲、大脑、机器人、智商120——Harness 到底是什么
👦🏻 Koji
如果今天你要用一句话向一个都没听说过 Harness 的人介绍它,你会怎么说?
👨🏻💻 来新璐
模型以外,都是 Harness。我倾向于把模型比作一个聪明的大脑,但它没有身体和手脚,只能思考,没办法行动。
👦🏻 Koji
“Agent 的上限来自 Harness 的设计”,你认可这句话吗?为什么 Agent 的上限不是来自模型智能的提升?
👨🏻💻 来新璐
我赞成一半。Agent 智力的上限提升,肯定还是源于模型层面的发展。Agent 就是一个模型,模型越聪明,它当然越好。
现在大部分模型的智力都比较够用了,把模型比作人,智商在 120-170之间,但我们可以通过健身、学舞蹈、修习武术,甚至穿上机甲,来让自己更强大。
👦🏻 Koji
这个比喻挺有意思,机甲是 Harness?
👨🏻💻 来新璐
它极大地扩大了模型的能力。

这个Agent教程,其实不只是写给别人看的——它本来是新璐自己整理的"造 Agent 心法"。
👦🏻 Koji
你们的教程《Learn Claude Code》在 GitHub 上有超过 5 万颗星,大概是什么时候开始写的?
👨🏻💻 来新璐
应该有 9 个月前了。
👦🏻 Koji
当时是出于什么考虑?
👨🏻💻 来新璐
我们当时的想法是,Claude Code 非常强大,只要给它套一个网页,就能得到一个很强的 Agent 产品。所以我们开始为开发者做工具链。但当时,开发者更熟悉 LangGraph、LangChain 这类基于 Prompt 和 Flow 的方法。
这有点像派系之争。每次我讲我们的思路,很多人会觉得不好控制——当时还不叫 Harness,叫 Agent 框架或 Runtime。
他们更喜欢加上很多 Prompt 节点,自己流转和控制,成本又低又可控。我觉得这是一个思想范式的争论,所以我们做了这个资料库放出去,也用来指导我们自己构建 Agent 的心法。
👦🏻 Koji
所以你认为 LangChain 和 LangGraph 这类框架已经彻底过时了吗?
👨🏻💻 来新璐
像 Prompt Flow 这种基于提示词节点做流转和控制的方法论,在未来的 Agent 开发过程中可能会越来越不适用。
而基于 Claude Code 的 Agent Native 思想——“Agent 即模型,模型即 Agent”,包括 “Bash is all you need” 这样的范式,会越来越清晰,被更多人采用。
Claude 推出 Manager Agents 之后,大家还需要自己搭 Harness 吗?
👦🏻 Koji
在我们录播客前几天,Claude 推出了 Managed Agents,把他们做 Agent Harness 的方案开放给大家用了。那既然可以直接用 Claude 的服务,大家还有必要自己去搭 Harness,甚至去了解它的细节吗?
👨🏻💻 来新璐
作为一个 Agent 开发工程师,这是需要的。我认为如果你不了解,做出来的产品会缺乏灵魂和迭代的空间。
👦🏻 Koji
但这就像云服务器,刚出来的时候工程师也说要去搞懂底层,但后来发现 99% 的项目根本不需要。Agent Harness 会不会也一样?
👨🏻💻 来新璐
从长远来看,肯定会有那么一天。就像今天大家用 Node.js 开发全栈应用,大部分人不会关心它的底层原理,开箱即用就好。Agent Harness 随着迭代和收敛,两三年后大概率也会到这一步。
但在此过程中,现在是技术周期,创业和做产品,本质上都是在吃技术周期变化的红利。你还是要拥抱技术周期的变化,知道里面到底在变什么。
👦🏻 Koji
现在都是什么人在学 Agent Harness?
👨🏻💻 来新璐
偏向于自己在构建和开发 Agent 产品的居多吧,不管是大厂里的相关团队,还是外面的创业公司。
👦🏻 Koji
你觉得产品经理有必要了解 Agent Harness 吗?
👨🏻💻 来新璐
我对今天的产品经理有一个质疑:今天的产品经理和过去不是同一种。现在是技术变化周期,我们做的所有产品都是在吃技术变化的红利。如果你不了解这个技术周期变化的内核,就很难构建一个能吃掉红利的产品。
以前的产品经理画好 UX UI 就行,但今天本质上是如何把技术进步的红利应用到某个场景。所以你应该同时懂两者:一个是场景需求和痛点,另一个是技术上到底在变什么。
用两周时间、多 Agent 协作,从零写出一个 C 编译器——这个经典案例背后,到底走了哪三层?
👦🏻 Koji
当你聊 Agent Harness 的时候,通常会把它拆成几个部分?
👨🏻💻 来新璐
我倾向于把它拆成三个部分。
第一层是给模型提供执行能力的层。比如 CLI、代码编写、工具注册,包括从 MCP 扩展的工具,这些都统一为模型提供 action 的能力。
第二层我称之为上下文,也就是状态层面。比如,模型工作需要 system prompt、skills 和 memory。模型的上下文窗口是有限的,很多任务会超出窗口,就需要 offload。下一轮,看似还是同一个 Agent 在工作,实际已经是一个新的模型窗口,需要装载初始化上下文,接替上一个窗口的工作。这里面有很多上下文和状态的问题,我把它归为上下文环境层。
第三层是对 Agent 的上层管理。这又分两个方面:一是如何组织和协调多个 Agent。如果你面对的是 100 个 Agent,就像管理 100 个员工,需要组织架构和协作方式来解决复杂问题。二是对这 100 个 Agent 的治理,比如不同岗位的访问权限,信息的提供和隔离。
👦🏻 Koji
我们用一个例子来串一下这三层吧。一个具体的 Agent 任务,背后 Harness 的三层是怎么发挥作用的?
👨🏻💻 来新璐
之前有个知名的例子,用两周时间协调大量 Agent,从 0 到 1 构建了一个 C 编译器。这是一个很好的 case。
首先,Agent 的最底层是模型,像大脑和心脏,驱动整个任务。它需要 action 能力,所以你至少要给它配置文件的增删读写、搜索等工具。这就是 Harness 的第一层,模型因此才能写代码、创建和修改文件。

第二层是上下文和状态。模型需要知道它在什么样的环境中工作,路径是什么,装了哪些依赖,已有的文件夹结构是什么,Git 信息等等。一个 C 编译器工程量很大,不可能在一个上下文窗口内完成。
它需要有上下文卸载策略。窗口满了以后,下一个 Agent 接手时,要去读取当前的环境信息、代码进度,然后继续工作,并在自己这一轮生命周期结束时,写下文档,把当前状态交接给再下一个 Agent。这个过程需要上下文环境的支持。
第三层是编排和治理。如何指导这些 Agent 之间传递和委托?写代码的 Agent 和测试的 Agent 是什么关系?任务中的环节一定是串行的吗?很多模块是不是可以并行编写,让多个 Agent 同时工作?它们如何协调?这涉及到编排。
另外,不同 Agent 的权限也需要治理。做测试的 Agent,应该只有测试环境和工具的权限,它不应该在测试时顺手修改代码来 “hack” 测试结果。这里面有很多权限治理和上层协调的问题。
👦🏻 Koji
所以过去做 Agent,这三层都得手搓。现在有哪些已经封装得很好,哪些还需要手搓?
👨🏻💻 来新璐
这三层到目前为止,我都没觉得有封装得非常好的。
范式变化太快了,从 22 年底 ChatGPT 发布,到现在这种能够完成长程任务的智能体模型出现,也就最近半年的事。
开源社区我观察了很多,没有看到太让我满意的,这也是我们自己动手做的原因。
他们公司叫 Komputer Blue,代号KB,目标是构建By Agents & For Agents的整套开源Infra
👦🏻 Koji
介绍一下你们在做的项目吧?
👨🏻💻 来新璐
我们围绕 Agent 的三个层面,提供了一个完整的工具链。
最底层是一个叫 Komputer 的工具链——Computer 的 C 换成 K。
它是一个我们在数据结构上实现的 Unix 计算机,可以理解为内存中的一台虚拟计算机。它为像小龙虾、Claude Code 这类下一代主动式 Agent 提供一个执行环境,让它们在里面生活和工作。我们认为,Unix 计算机是对它们最好的环境。
上层有一个叫 Kruntime 的东西,是一个 Agent runtime,提供了大量开发 Agent 对象的接口和语法糖封装。此外,我们还有其他正交的层面,比如 Kwatch,用于观测。
你可以看到过去半个月 Agent 在什么情况下卡住了,从而判断是 CLI 设计问题,还是 skill 没提供到位,或是模型不行。基于观测层,我们还可以导出数据。
我们有一个叫 KRL 的工具链,你可以把导出的数据拿去做强化学习,训练自己的模型。如果你不想训模型,只想调用标准 API,我们也可以在上下文层面,帮你做 memory、skills 和过去经验的提取与自迭代,可以理解为“穷人版的强化学习”。
云服务厂商当然也想做这一层
👦🏻 Koji
云服务厂商也在做这一层,比如 AWS 的 Agent Core 和阿里云的 AgentBase。你们作为创业公司,和它们有什么不同?
👨🏻💻 来新璐
首先,我们的 Agent 开发工具链不只是为云环境设计的,我们希望它能在任何能跑 JS 的场景下运行。比如浏览器里的网页、微信小程序。
很多场景是塞不下一个 Linux 的,微信小程序一个 package 可能就几兆。我们希望在所有能跑 JS 的场景,无差别地提供一个类似上个时代 Vue、React 那样的工具链框架,import 就能用。
它的心智模型统一、简洁、优雅,性能占用也极致,只有一个 KB 级大小的 Unix Komputer,为 Agent 提供生活环境。但像小龙虾这样的 Agent 在这个环境里,会以为自己真的生活在一台 Unix 计算机上,它的命令行、文件系统、网络能力,都和它训练时的心智是一致的。
👦🏻 Koji
所以你们公司叫 1KB?
👨🏻💻 来新璐
对,当然没有前面那个 “1”,是 KB 的展开写法。
👦🏻 Koji
这是怎么做到的?
👨🏻💻 来新璐
我们用数据结构重新实现了一个纯虚拟的 Unix 给Agent 作为生活和工作的环境。你可以理解为,我们用 TS 重写了虚拟的 bash,虚拟磁盘文件系统,前、后台进程的运行能力,虚拟时钟,局域网组网、共享资源如nas 挂载等能力,这些我们都在虚拟抽象层用语言重写了一遍。
以及在支持 WebAssembly 的场景,我们还会把一些工具链部分用 Rust 替换,如果不支持,就 fallback 到最朴素的 JS。
👦🏻 Koji
回到 Agent Harness,第一层执行能力,现在最主要的工具有哪些?
👨🏻💻 来新璐
最主要的首先是文件系统的工具:增删读写、搜索。大部分 Agent,无论是做 Coding 还是 Deep Research,都需要这些。
第二层是 Browser,给它访问用户互联网世界系统的能力
第三层是语言解释器,像 Python、Node。
配好这些,基本能满足 95% 以上的任务了。
👦🏻 Koji
配工具这一层有什么容易踩的坑吗?
👨🏻💻 来新璐
这和权限及 Agent 角色密切相关。比如,一个 Agent 只负责 explore 代码库,那我就只给它配没有副作用的工具,所有写和改的命令都不能给。有些 Agent 不能让它操作 Browser,或者要限制它访问的网域。
这里有很多 trade-off,工具链的设计要和 Agent 的角色紧密绑定,限制它对底层计算机的操作能力。
👦🏻 Koji
第二层上下文与状态层,记忆很重要。现在主流的记忆解决方案有哪些?
👨🏻💻 来新璐
Memory 这一层还处于很早期的阶段。我把它粗略分为规则式、半规则式和完全模型驱动式。目前用得比较多的是前两种。
完全规则式是基于知识图谱和向量搜索,把信息抽象成节点再做关联和检索。我个人不太喜欢这种做法。
我更喜欢半规则式,如底层是一个 Unix file system,通过大量 Markdown 存储信息,Claude Code 和小龙虾都是这么做的。也可以通过空间关系,比如迷宫走势来组织信息,人和 LLM 都容易理解。
它的更新也是半规则式的,由 Agent 去跑流程,而不是完全 Rule-based。比如,像 Claude Code 里有“做梦”机制,隔天跑一下最近的对话,提取信息,更新和纠正记忆。
开源项目 memU 也做得很好,拥抱“Unix file system + Agent 驱动”的方式。
👦🏻 Koji
Y Combinator CEO Gary Tan 也开源了他个人的记忆。
👨🏻💻 来新璐
我觉得大家都有点混淆了 Memory 和 Skill 的边界。最早做这件事的是 Claude Code,去年底它有个叫 Insights 的特性,可以分析你近一个月的对话,总结错误,然后指导 skill 的生成。最近很火的 Harness Agent,更像是偏经验类 Memory 层面的迭代(因为很难共享给别人直接用)。
你很难分清一个东西到底是经验类 Memory,还是标准化的 Skill SOP。
但总体上,它们都属于上下文层面。
👦🏻 Koji
这让我想到最近 Generalist AI 发了一篇博客说,不要用标签定义我们,要用目的定义我们。标签不但会限制外界对我们的想象力,甚至会限制我们团队对自己的想象力。也许我们讨论一个实践算 memory 还是 skill 没那么重要,重要的是 Agent 如何自我学习和进化。
👨🏻💻 来新璐
对,标签没那么重要。
👦🏻 Koji
今天聊 Harness,有哪些是共识,有哪些是非共识?
👨🏻💻 来新璐
“Bash is all you need” 算是一个共识,大家都在做 CLI。或者说 “CLI is all you need”。很多人开始开发自己的 CLI,而不是 MCP,因为 CLI Agent 都能用,更方便。
但很多开源的 Agent 框架,像 LangGraph,并不是围绕这个理念构建的,它们还是基于 Prompt Node 去做状态图和路由。我们做的 k系列工具链,就是想在这个共识范式下,提供新时代需要的开发工具。
👦🏻 Koji
你们在面向未来?
👨🏻💻 来新璐
我们在面向终极。
让所有人看到了一件事:这家公司在"上下文管理"上做了多少别人没有做的工程工作
👦🏻 Koji
Claude Code 源码泄露,从 Harness 层面,你觉得能学到最关键的点是什么?
👨🏻💻 来新璐
它的压缩策略比我们想的要多级。比如什么时候删除工具的 output,压缩时保留和恢复哪些信息。Agent 之间是接力赛,下一个 Agent 接手时,上下文如何准备,哪些加载、哪些不要、哪些按需查看,这里面有很多 trade-off。
它在上下文和记忆上做了很多工作,包括 Autodream。很多记忆特性还没对普通用户开放。Claude Code 的记忆设计非常精妙,和它的 skills 机制遵循同一套哲学。
最关键的有两点。
第一,模型才是 Agent。用户写的 prompt、组的提示词流,那种链条式的做法是不 make sense 的。Claude Code 完全体现了这一点。
第二,Claude Code 的本质是围绕如何给模型配备合适的工具,让模型去调用。也就是给模型 action 的能力和充分的自由,让它随心所欲,而不是程序员为它规划好每一步。
👦🏻 Koji
更多的 Context,更少的 Control?
👨🏻💻 来新璐
更多 Context,更多 action 能力,以及 Zero Control。最多只是限制你不能调用某些工具。
👦🏻 Koji
Manus 上线时用了一个云端沙箱叫 E2B,从一年前到现在,这个沙箱有什么样的进化吗?
👨🏻💻 来新璐
我们关注沙箱比较多,最近也出来很多 Sandbox,但我们觉得这个领域目前大的进展还不多。我们自己做的 KB 级 Unix Komputer,可能算是这个领域一个大的进展。
👦🏻 Koji
你们做的和 Daytona 有点像?但 Daytona 可能没有你们那么小。
👨🏻💻 来新璐
我们做的更极致、轻量,本质上它不再是一个 Sandbox,而是我们用语言层实现的一个数据结构,像一个 map 差不多大。
当然我们也做了一些 trade-off,上面没法真的运行 GCC 编译器或浏览器。但我们提供了最小化的 Unix file system 和 bash command,以及局域网通信能力。
而且我们认为,像浏览器、编译器这种重的东西,原本就不应该塞到所有 Agent 的环境里,而应该抽出来作为一个集约的服务。
👦🏻 Koji
Claude Code 的“悄悄做梦”记忆机制,具体是怎么帮助记忆的?

👨🏻💻 来新璐
它有两个记忆更新机制。
一是在每次交互后,会触发一个 turn stop hook,fork 一个 Agent,带上所有的上下文(复用 KV Cache),判断有什么信息需要保存,然后更新到对应的 Markdown 文件里。这些文件都有结构化的 description,不会一开始就加载全文。
二是 auto-dream 机制。大概每隔一天,如果 session 数量超过 5 个,它就会启动一个更深层的记忆整理。回顾最近的 session,榨干信息,纠正错误,合并整理 Memory。
就像定时开启一个后台 Agent,对最近的会话做一遍重放,像我们做梦一样。
👦🏻 Koji
我们聊 Harness,其实和过去一年讨论的 Agent 优化工程实践很像?
👨🏻💻 来新璐
对,Harness 就是 Agent 模型这一代之上的工程实践。
就像有了 CPU 才有了汇编,有了汇编才有了上层的各种 C、Python、JS 等高级语言。
现在我们有了一个新的底层 —— 模型,我们要在上层利用它的智能性,来做新的工程最佳实践。
如果你从模型的训练和运行视角出发,会发现现在很多所谓的最佳实践都非常自然,符合常识和直觉。
👦🏻 Koji
如何判断一个 Harness 做得好不好?
👨🏻💻 来新璐
不好的上下文管理会随便裁剪,导致 Prompt Caching 失效。
最好的管理就是不管理,因为你做的任何管理都可能导致 KV cache 失效,需要重新计算。不好的做法就是和模型的运行不自洽。
好的 Harness 设计要和模型的运行自洽,和模型未来的能力进步正交。有些 Harness 机制是为能力弱的模型(如问答时代的模型)设计的,随着模型进步,这些机制反而会成为束缚,必须拆掉。
好的 Harness 应该符合模型本身的运行逻辑,并且随着模型变强,整个 Agent 系统的能力也越强。
👦🏻 Koji
不同 Agent 完成同样任务,表现有好有坏。即便表现相同,好的 Agent 消耗的 Token 数量和完成时间也可能不同。这背后是不是也是判断 Harness 好坏的标准?
👨🏻💻 来新璐
我觉得今天还处于 Agent 模型发展的早期,Anthropic 去年初才率先开始训练智能体模型,其他厂商其实落后了半年。
所以目前还是 Agent 模型的婴儿期,很多东西没有收敛,可能还不必过快地去讨论所谓的 Token efficiency。
当然它很重要,但对我们使用者来说,只要调 SOTA 的模型,然后围绕它去构造 Harness 和产品就可以。
👦🏻 Koji
所以 SOTA 是 Anthropic,那次 SOTA 在你看来有哪些?
👨🏻💻 来新璐
SOTA 是 Anthropic。次 SOTA 可能像 Kimi,包括 Minimax、GLM 他们最新一代的模型,都算是紧贴着 SOTA 在做。
👦🏻 Koji
如果未来 Agent 模型越来越强,Harness 之间的水平差异还重要吗?
👨🏻💻 来新璐
两三年后,理论上不应该有那么多 Harness。
好的 Harness 要跟模型的运行原理自洽,跟模型的进步方向正交。
从这两点看,它的结构设计上不会存在太多派系。我们就是做一个 Unix 系统,你可以理解为 Linux 就是对模型最强的 Harness。
如果模型有一天发展成 ASI,它只会更会用 Linux。

👦🏻 Koji
如果今天要做一个好的 Agent,它由模型、上下文、Harness、工具等多个部分组成,你有一个重要性的排序吗?
👨🏻💻 来新璐
第一位肯定是模型,因为 Agent 就是模型,模型才是 Agent。如果你的 Agent 表现不好,换一个更强的模型,大概率就能提升很多。
其次是上下文,这是一个非常开放的概念,包括它工作在什么环境,能用哪些工具,skills、memory,以及 Agent 之间的交接棒。对我们开发者来说,能做的空间更多在上下文层面。
第三个是工具。如果你给它配上 powerful 的工具,它能完成更多事情。
关于工具,我之前用 GitHub 的 MCP,后来发现GitHub的 CLI 调用成功率更高,就把它的 MCP 卸载了
我思考为什么,觉得 Linux 命令在预训练时出现了几十亿条,训练得非常鲁棒。而 MCP 是最近两年才提出的新协议,预训练语料占比可能不到 0.1%。最近飞书也出了 CLI,它的组合性和任务完成率也比之前的插件更高。
大家都不再提供 MCP,而是回到 Unix 这个自洽的哲学中,它的训练语料最充分。
所以我非常喜欢 “Bash is all you need” 这句话。
👦🏻 Koji
Agent Harness 催生了很多创业方向,除了你们,你还看好哪些?
👨🏻💻 来新璐
我关注三个大方向。我们自己是 Harness 这一层的 Infra 和开发者工具链。
另外两个,一个是 Agent 的组网方向。我关心的是底层的硬件资源,云上的服务器、端侧的电脑、路由器、NAS、手机等等。它们不一定有公网 IP,存在混合组网问题。
我非常喜欢 Tailscale 这个工具,它的组网方式非常简洁。但在 Agent 时代,可能需要一个全新的、更 Agent Native 的混合组网形态。
👦🏻 Koji
这其实和 Agent 的支付也是一样的。人的支付不需要那么高的并发和那么碎的小额支付,但 Agent 之间的支付很可能是几分钱,并且特别高频地发生。
👨🏻💻 来新璐
还有一个方向。我想,10 年后,难道每个人还在调用同一个模型 ID 的基模吗?那太无趣了。所以,像 Tinker 那样的方案可能就很需要。它把大量算力卡集中做成高速互联集群,用更低的成本去做 PEFT 训练。
这样,每个人都可以拥有自己个性化训练的模型。推理时,也可以在 API 请求中带上自己的 LoRA 信息,实现低成本的个性化推理。我会非常关注这个方向的进展。
👦🏻 Koji
Agent Infra 这一波会存活很多公司吗?
👨🏻💻 来新璐
会是一个比较激烈的赛道。我们认为未来 Agent Harness 不需要所谓的水平差异化,因为它要跟模型的运行和未来进步方向自洽。
从这两个角度看,它的结构设计上不会存在太多派系。我们比较站 Unix 和 Shell 这一派,给它提供一个虚拟的 Unix Komputer,把性能做到极致。
可能也会有其他派系,比如走 TypeScript,做严格的结构化控制,但派系不会太多。
👦🏻 Koji
你预感到这个赛道很激烈,而且可能两年后就没了,为什么还要做?
👨🏻💻 来新璐
我们不是最近才进入这个赛道,我们已经做了一年了。现在只是在演进,做第二代,把事情做得更自洽,更站在终点来思考。
我们公司的 Slogan 是“加速世界升级”。在当前阶段,这件事情是不是对世界最大的有效加速?也许下个阶段是造更好的火箭,或者更好的核聚变。

但当前这个技术阶段,我们看到的是如何让地球上充满 Agents,让它们成为社会基础设施,尤其是让 Coding Agent 成为一种 Infra。
未来星球上可能有比人类多几百倍的 Agents,你如何去服务它们,支撑它们开发、创建和 Fork Agent?那是一个非常 crazy 的世界。我们就在思考和支撑这样一件事。
"我觉得以后很多的公司都是理财产品 —— 由有经验的人类 Team搭建这些公司、甚至由AI直接生成公司,然后自运转"
👦🏻 Koji
关于 Agent 的未来你还有什么预测或暴论吗?
👨🏻💻 来新璐
我觉得 Agent 未来的样子已经非常清晰了。这个领域还很早期,模型这个阶段可能会持续 3 年左右。
现在更多是单体 Agent,下一步是 Agent 蜂群的集群化作业。现在是人手动编排 Agent,未来应该是 Agent 自己去管理和协调更多 Agent。
再往后,是 AI 做发明任务。如果 AI 能自迭代地提出新方案、做实验,完全由 Agent 驱动公司运行,那未来的公司更像一种理财产品,而不是由人组成。
公司内部是个黑盒,客户不关心。Agent 完全可以组成“0 人公司”。我从来不觉得一人公司是本质,真正 make sense 的是 0 人公司。
👦🏻 Koji
真格和我们最近 Grant 的一个项目叫 YoYo Agent,也可以算一个 0 人公司。
它的创作者把它做出来后就完全放手了,不改代码也不给钱。它要自己进化,想办法赚钱买 Token,目标是有一天超越 Claude Code。
它现在通过在 GitHub 上接受打赏来赚钱。未来,大家投资的标的可能不再是人类公司,而是一个个 Agent。
👨🏻💻 来新璐
我完全相信。未来你可能是一个大老板,见到朋友时,从口袋里掏出一张黑色的卡片,说:“这张卡片里跑了 5 个公司,每年给我创造几十亿的收入。这是我的公司,就在这张卡片里。”
👦🏻 Koji
这个未来,想一想又兴奋又可怕。
👨🏻💻 来新璐
哈哈哈,开个玩笑。
👦🏻 Koji
好的,今天谢谢新璐。
👨🏻💻 来新璐
好,谢谢。
🚥
文章来自于"十字路口Crossing",作者 "Koji"。
【开源免费】OWL是一个完全开源免费的通用智能体项目。它可以远程开Ubuntu容器、自动挂载数据、做规划、执行任务,堪称「云端超级打工人」而且做到了开源界GAIA性能天花板,达到了57.7%,超越Huggingface 提出的Open Deep Research 55.15%的表现。
项目地址:GitHub:https://github.com/camel-ai/owl
【开源免费】OpenManus 目前支持在你的电脑上完成很多任务,包括网页浏览,文件操作,写代码等。OpenManus 使用了传统的 ReAct 的模式,这样的优势是基于当前的状态进行决策,上下文和记忆方便管理,无需单独处理。需要注意,Manus 有使用 Plan 进行规划。
项目地址:https://github.com/mannaandpoem/OpenManus
【开源免费】Browser-use 是一个用户AI代理直接可以控制浏览器的工具。它能够让AI 自动执行浏览器中的各种任务,如比较价格、添加购物车、回复各种社交媒体等。
项目地址:https://github.com/browser-use/browser-use
【开源免费】AutoGPT是一个允许用户创建和运行智能体的(AI Agents)项目。用户创建的智能体能够自动执行各种任务,从而让AI有步骤的去解决实际问题。
项目地址:https://github.com/Significant-Gravitas/AutoGPT
【开源免费】MetaGPT是一个“软件开发公司”的智能体项目,只需要输入一句话的老板需求,MetaGPT即可输出用户故事 / 竞品分析 / 需求 / 数据结构 / APIs / 文件等软件开发的相关内容。MetaGPT内置了各种AI角色,包括产品经理 / 架构师 / 项目经理 / 工程师,MetaGPT提供了一个精心调配的软件公司研发全过程的SOP。
项目地址:https://github.com/geekan/MetaGPT/blob/main/docs/README_CN.md
【开源免费】FASTGPT是基于LLM的知识库开源项目,提供开箱即用的数据处理、模型调用等能力。整体功能和“Dify”“RAGFlow”项目类似。很多接入微信,飞书的AI项目都基于该项目二次开发。
项目地址:https://github.com/labring/FastGPT
【开源免费】graphrag是微软推出的RAG项目,与传统的通过 RAG 方法使用向量相似性作为搜索技术不同,GraphRAG是使用知识图谱在推理复杂信息时大幅提高问答性能。
项目地址:https://github.com/microsoft/graphrag
【开源免费】Dify是最早一批实现RAG,Agent,模型管理等一站式AI开发的工具平台,并且项目方一直持续维护。其中在任务编排方面相对领先对手,可以帮助研发实现像字节扣子那样的功能。
项目地址:https://github.com/langgenius/dify
【开源免费】RAGFlow是和Dify类似的开源项目,该项目在大文件解析方面做的更出色,拓展编排方面相对弱一些。
项目地址:https://github.com/infiniflow/ragflow/tree/main
【开源免费】phidata是一个可以实现将数据转化成向量存储,并通过AI实现RAG功能的项目
项目地址:https://github.com/phidatahq/phidata
【开源免费】TaskingAI 是一个提供RAG,Agent,大模型管理等AI项目开发的工具平台,比LangChain更强大的中间件AI平台工具。
项目地址:https://github.com/TaskingAI/TaskingAI
【开源免费】LangGPT 是一个通过结构化和模板化的方法,编写高质量的AI提示词的开源项目。它可以让任何非专业的用户轻松创建高水平的提示词,进而高质量的帮助用户通过AI解决问题。
项目地址:https://github.com/langgptai/LangGPT/blob/main/README_zh.md
在线使用:https://kimi.moonshot.cn/kimiplus/conpg00t7lagbbsfqkq0