ARTICLE SIGNAL

探秘 Claude Code,搞懂 Agent Harn...

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

type
status
date
slug
summary
tags
category
icon
password
网址
notion image
「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 的相关工作。
模型以外都是 Harness
机甲、大脑、机器人、智商120——Harness 到底是什么
👦🏻 Koji
如果今天你要用一句话向一个都没听说过 Harness 的人介绍它,你会怎么说?
👨🏻‍💻 来新璐
模型以外,都是 Harness。我倾向于把模型比作一个聪明的大脑,但它没有身体和手脚,只能思考,没办法行动。
👦🏻 Koji
“Agent 的上限来自 Harness 的设计”,你认可这句话吗?为什么 Agent 的上限不是来自模型智能的提升?
👨🏻‍💻 来新璐
我赞成一半。Agent 智力的上限提升,肯定还是源于模型层面的发展。Agent 就是一个模型,模型越聪明,它当然越好。
现在大部分模型的智力都比较够用了,把模型比作人,智商在 120-170之间,但我们可以通过健身、学舞蹈、修习武术,甚至穿上机甲,来让自己更强大。
👦🏻 Koji
这个比喻挺有意思,机甲是 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 的第一层,模型因此才能写代码、创建和修改文件。
第二层是上下文和状态。模型需要知道它在什么样的环境中工作,路径是什么,装了哪些依赖,已有的文件夹结构是什么,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 级 Un...
Loading...

没有找到文章