探秘 Claude Code,搞懂 Agent Harness|对谈来新璐

AITNT-国内领先的一站式人工智能新闻资讯网站
# 热门搜索 #
探秘 Claude Code,搞懂 Agent Harness|对谈来新璐
6061点击    2026-05-13 15:25

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


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


🚥 不久前,Claude Code 源代码泄露,许多 Agent Harness 的关键模块得以完整呈现,成了一份极佳的教学标本。而在技术高速变化的红利期,主动理解新技术往往能带来很高的认知增量。


因此,本周「十字路口」邀请到来新璐,一起聊聊 Agent Harness。新璐是 ShareAI 开源社区发起人,他撰写维护的《Learn Claude Code》教程在 GitHub 上获得超过 50k Star。


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


在本期内容中,我们把 Agent Harness 从概念词拆解成工程语言,介绍它的三层框架:会跑(执行层)→ 跑久(状态层)→ 跑稳(治理层)。


同时,我们也梳理了 Claude Code 中值得借鉴的多个机制:更多 context、更少 control 的思路、“零上下文管理”的哲学、长程任务的接力式交接策略,以及让 Agent 越用越聪明的“做梦”式记忆维护与迭代机制等


新璐作为典型的一人公司,刚完成数百万美金融资;他也分享了自己对 OPC 的独特观点,甚至认为“未来只有 0 人公司,没有 1 人公司”,颇具启发。


微信收听播客:


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


小宇宙收听播客:


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


🎬 视频播客已同步上线于 @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 的相关工作。


模型以外都是 Harness


机甲、大脑、机器人、智商120——Harness 到底是什么


👦🏻 Koji


如果今天你要用一句话向一个都没听说过 Harness 的人介绍它,你会怎么说?


👨🏻‍💻 来新璐


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


👦🏻 Koji


“Agent 的上限来自 Harness 的设计”,你认可这句话吗?为什么 Agent 的上限不是来自模型智能的提升?


👨🏻‍💻 来新璐


我赞成一半。Agent 智力的上限提升,肯定还是源于模型层面的发展。Agent 就是一个模型,模型越聪明,它当然越好。


现在大部分模型的智力都比较够用了,把模型比作人,智商在 120-170之间,但我们可以通过健身、学舞蹈、修习武术,甚至穿上机甲,来让自己更强大。


👦🏻 Koji


这个比喻挺有意思,机甲是 Harness?


👨🏻‍💻 来新璐


它极大地扩大了模型的能力。


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


GitHub 50k star,是怎么来的?


这个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” 这样的范式,会越来越清晰,被更多人采用。


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 就行,但今天本质上是如何把技术进步的红利应用到某个场景。所以你应该同时懂两者:一个是场景需求和痛点,另一个是技术上到底在变什么。


Harness 三层拆解


用两周时间、多 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 的第一层,模型因此才能写代码、创建和修改文件。


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


第二层是上下文和状态。模型需要知道它在什么样的环境中工作,路径是什么,装了哪些依赖,已有的文件夹结构是什么,Git 信息等等。一个 C 编译器工程量很大,不可能在一个上下文窗口内完成。


它需要有上下文卸载策略。窗口满了以后,下一个 Agent 接手时,要去读取当前的环境信息、代码进度,然后继续工作,并在自己这一轮生命周期结束时,写下文档,把当前状态交接给再下一个 Agent。这个过程需要上下文环境的支持。


第三层是编排和治理。如何指导这些 Agent 之间传递和委托?写代码的 Agent 和测试的 Agent 是什么关系?任务中的环节一定是串行的吗?很多模块是不是可以并行编写,让多个 Agent 同时工作?它们如何协调?这涉及到编排。


另外,不同 Agent 的权限也需要治理。做测试的 Agent,应该只有测试环境和工具的权限,它不应该在测试时顺手修改代码来 “hack” 测试结果。这里面有很多权限治理和上层协调的问题。


👦🏻 Koji


所以过去做 Agent,这三层都得手搓。现在有哪些已经封装得很好,哪些还需要手搓?


👨🏻‍💻 来新璐


这三层到目前为止,我都没觉得有封装得非常好的。


范式变化太快了,从 22 年底 ChatGPT 发布,到现在这种能够完成长程任务的智能体模型出现,也就最近半年的事。


开源社区我观察了很多,没有看到太让我满意的,这也是我们自己动手做的原因。


KB 的 K 系列Agent工具链


他们公司叫 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 和过去经验的提取与自迭代,可以理解为“穷人版的强化学习”。


vs. AWS AgentCore、阿里云 AgentBay


云服务厂商当然也想做这一层


👦🏻 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 的角色紧密绑定,限制它对底层计算机的操作能力。


Memory 的流派


👦🏻 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


你们在面向未来?


👨🏻‍💻 来新璐


我们在面向终极。


Claude Code 源码泄露:最大的惊喜是什么


让所有人看到了一件事:这家公司在"上下文管理"上做了多少别人没有做的工程工作


👦🏻 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 的“悄悄做梦”记忆机制,具体是怎么帮助记忆的?


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


👨🏻‍💻 来新璐


它有两个记忆更新机制。


一是在每次交互后,会触发一个 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 等高级语言。


现在我们有了一个新的底层 —— 模型,我们要在上层利用它的智能性,来做新的工程最佳实践。


如果你从模型的训练和运行视角出发,会发现现在很多所谓的最佳实践都非常自然,符合常识和直觉。


好 Harness 的标准


👦🏻 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。


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


👦🏻 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 是“加速世界升级”。在当前阶段,这件事情是不是对世界最大的有效加速?也许下个阶段是造更好的火箭,或者更好的核聚变。


探秘 Claude Code,搞懂 Agent Harness|对谈来新璐


但当前这个技术阶段,我们看到的是如何让地球上充满 Agents,让它们成为社会基础设施,尤其是让 Coding Agent 成为一种 Infra。


未来星球上可能有比人类多几百倍的 Agents,你如何去服务它们,支撑它们开发、创建和 Fork Agent?那是一个非常 crazy 的世界。我们就在思考和支撑这样一件事。


Agent 未来暴论


"我觉得以后很多的公司都是理财产品 —— 由有经验的人类 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"。

AITNT-国内领先的一站式人工智能新闻资讯网站
AITNT资源拓展
根据文章内容,系统为您匹配了更有价值的资源信息。内容由AI生成,仅供参考
1
OWL

【开源免费】OWL是一个完全开源免费的通用智能体项目。它可以远程开Ubuntu容器、自动挂载数据、做规划、执行任务,堪称「云端超级打工人」而且做到了开源界GAIA性能天花板,达到了57.7%,超越Huggingface 提出的Open Deep Research 55.15%的表现。

项目地址:GitHub:https://github.com/camel-ai/owl

2
OpenManus

【开源免费】OpenManus 目前支持在你的电脑上完成很多任务,包括网页浏览,文件操作,写代码等。OpenManus 使用了传统的 ReAct 的模式,这样的优势是基于当前的状态进行决策,上下文和记忆方便管理,无需单独处理。需要注意,Manus 有使用 Plan 进行规划。

项目地址:https://github.com/mannaandpoem/OpenManus


3
AI代理

【开源免费】Browser-use 是一个用户AI代理直接可以控制浏览器的工具。它能够让AI 自动执行浏览器中的各种任务,如比较价格、添加购物车、回复各种社交媒体等。

项目地址:https://github.com/browser-use/browser-use


4
智能体

【开源免费】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

5
知识库

【开源免费】FASTGPT是基于LLM的知识库开源项目,提供开箱即用的数据处理、模型调用等能力。整体功能和“Dify”“RAGFlow”项目类似。很多接入微信,飞书的AI项目都基于该项目二次开发。

项目地址:https://github.com/labring/FastGPT

6
RAG

【开源免费】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

7
prompt

【开源免费】LangGPT 是一个通过结构化和模板化的方法,编写高质量的AI提示词的开源项目。它可以让任何非专业的用户轻松创建高水平的提示词,进而高质量的帮助用户通过AI解决问题。

项目地址:https://github.com/langgptai/LangGPT/blob/main/README_zh.md

在线使用:https://kimi.moonshot.cn/kimiplus/conpg00t7lagbbsfqkq0