OpenClaw 技术闭门：测试将比代码更值钱，Agent Computer 会是新的硬件形态

「OpenClaw 项目每小时能收到上百个 pr，甚至很多 PR 的提交者自己都不知道这段代码是怎么来的。代码开始成为了一种负债。」

「当代码都是 AI vibe 出来的，测试其实比真实代码更值钱。」

「以前，工程师的核心能力是做 Feature Coding，但现在你会更注重整个 Platform Engineering 的事情。」

......

OpenClaw 已经持续发酵了半个多月。

在这段时间里，我们看到的一个趋势是，OpenClaw 正在从一个单纯的极客「玩具」，逐渐在各种具体业务中被实际用起来、作为一个可落地的生产力工具来提效。国内的几家基模大厂，也陆续发布了类似产品或功能。

于是，在组织了第一场闭门之后，我们决定找离 OpenClaw 最近的一群人：一线开发者、技术 founder、明星创企的核心工程师，聊聊在概念、热度之外，他们在各种实际业务中是怎么用 OpenClaw 的，以及一些真实的思考与困惑。

这场闭门分享，很硬核，我们整理了部分精彩内容。

PS：考虑到是闭门分享交流，我们对一些嘉宾进行了匿名化处理。

Vibe Coding 时代，

代码开始成为负债

「Code as Liability」

飞书 OpenClaw 插件维护者：先分享一个非常夸张的数据。大家可以想一下，现在的 OpenClaw 项目主干，平均每小时会收到多少个 PR？这个数字现在是 30 到 60 个，高峰期甚至能超过 100 个。现在随时去看它官方仓库，都可能看到 2000 多个待处理的 PR。这意味着，你的贡献能被合并进去的概率，大概是两千分之一。

回到工程视角来看。如果未来的开源项目都以这种方式维护，一个小时涌入几十个 PR，怎么可能有人 review 得过来？即使 OpenClaw 现在有几百个 contributor，但最终的 maintainer 数量也是极其有限的，这些 maintainer 的注意力非常稀缺。

为了应对这种情况，OpenClaw 社区甚至搞了一个专门的频道，限制每个人 6 小时内只能发一条消息。如果你觉得自己的 PR 特别重要，想让维护者看到，就只能在这里「排队」发言，才可能更优先地获得注意力。

整个状态，就好像一个大企业每天收到几千份内推简历，最终谁的简历能被优先看到，已经变成了一个纯粹的注意力争夺问题。

这带来了一个非常大的转变。之前的开源项目里，如果看到一个新的 PR，第一反应是积极的：有人愿意读我的代码，有人愿意参与维护，那我可以降低一点这个项目的「公交车指数」，就是万一我出门被公交车撞了，还有人能维护这个项目。

但现在，这个模式可以说被完全颠覆了。因为所有人都可以随便提交，甚至很多 PR 的提交者自己都不知道这段代码是怎么来的。维护者的心态更多地转向了「Code as Liability（代码是负债）」的角度。你每增加几百行代码，都可能引入一些意想不到的问题，让项目在未来更难维护。在这种心态下，只能尽可能避免随意合并。

开源的信任链条其实有些断裂，我们似乎又回归到了最原始的人际信任。

一方面是需要更多的人际信任来做背书，另一方面，我们需要探索自动化的 review 和测试。实际上，OpenClaw 自己已经有了一套机制，它会自己识别出来那些很低质量的、机器生成且你根本不 care 的 PR，关掉。

我的感觉是，在 OpenClaw 这种大家用 Vibe Coding 写 PR 的「恶性通胀」产能下，传统的开源信任链条是断裂的。我们合并一个 PR，不是因为我读了你所有代码，可能是信任你作为一个 engineer 的工程能力，和你对这个东西持续维护的 credit。

我们还不知道如何迎接上万个高质量 PR 的涌入

Agent 创业者：我很喜欢把代码库比作「胶水」。在 Agent 时代，我们可以重新审视代码的本质：它不就是连接逻辑的胶水吗？现在的 Coding Agent 就像手里的一把「热熔胶枪」，它可以源源不断地喷出胶水。每个人手里都拿着一把热熔胶枪，对着一个「泡泡玛特」玩具说，「诶，这个不错，我也来喷点胶水」。每个人都想按照自己的意愿把它粘成合适的形状。但最终，这个玩具是被粘得更奇怪，还是更圆润？我觉得这是一个很深的问题。

OpenClaw 这个项目其实让我看到了这个问题被推向了一个更疯狂的层面。

所以我一直在思考一个问题：未来如果过了半年或一年，GitHub 上一定会涌现出一批这样的仓库，无数的人和 Agent 都在疯狂地往里提交代码。在 OpenClaw 这个项目上，现在很多提交代码的已经不是人了，而是 Agent。未来这个情况只会推演得更加疯狂。

到了那时候，假如以小时甚至分钟为单位，都有海量高质量的 PR 被提交进来。从 review 的角度看，每一个 PR 单独拿出来，可能都有在某个角度上的合理性。那么，当这些中上水平的 PR 涌入时，会发生什么？

首先，人工测试显然已经是不太现实了。其次，也是我更关心的问题：当一分钟有上万个高质量 PR 涌入时，我们那个时代的 Git 基础设施、整个软件仓库的演进生态，以及相应的治理规范，会是什么样？这可能是我觉得目前还没有明确答案的地方。

Vibe Coding 进入到了一个「快消费」的时代

AI4S Agent 创业者：我觉得 Vibe Coding 的 Impact 我们才刚刚感知到一部分，但它对社会的长期 Impact 才刚刚开始。我写了十几年代码，也研究了两三年代码生成，现在发现 Vibe Coding 进入到了一个非常「快消费」的时代。

这种「快消费」跟传统的硬核开发，比如写 Linux Kernel、数据库 Planning，形成了鲜明对比。一边是非常快速、用后即抛的使用方式，另一边是支撑整个互联网的最基础架构，可能还是需要那 20 个人去写最核心的维护代码。

这两种情况下如何协作？如何维持两者之间的 Tension？普通人能不能去写 Linux Kernel？我觉得这非常有趣。

就像前边提到的「胶水」比喻，很早以前铸造一个东西需要做模型、找工匠，现在可能直接 3D 打印就出来了。当代码变成一个用后即抛的东西之后，它真正的价值和意义到底是什么？非常需要我们思考。

当代码都是 AI vibe 出来的，

测试变得异常重要

测试，其实比你真实的代码更值钱

Agent Infra 创业者：我们的项目——Agent 运行时的 Sandbox 基本就是 Vibe Coding 出来的，Claude Code 是我们项目的第一贡献者，它的 Commit 数量是我们剩下 4 个人加起来的总和。这个项目非常依赖测试。

但如果你放手让 Claude Code 去写测试的话，你会发现他写大量那种我们叫「瞎 Mock」的东西。他可能在一个测试里把所有外部环境全 Mock 一遍，装模作样测一下，告诉你通过了，实际上真实代码一行都没跑。这种测试是无效的。

所以我们在文档里写了非常多的 Testing 规则，还写了一些 Skill。当它开发完代码，我们会主动 @ 这些规则，让他去修改代码。

我觉得测试其实比真实代码更值钱。像 Claude 前段时间号称写了个 C 编译器，其实 C 编译器的 Test Case 这么多年已经非常完善了。你在一个快速反馈的环境下去烧 Token，是能烧出来的。但在一个比较开放的开发任务里，让 Coding Agent 去做事就非常困难。

所以我的观点是，Coding Agent 写的代码我可以不看，但他写的测试我一定会看，而且一定会严格要求他按照我们的 Pattern 去重写。

这里有一个很重要的 Mock 规则，只有第三方的库你可以 Mock，但是你所有的内部 Library、内部 Service 都不能 Mock。

在我们的通用测试框架里，除了三方的东西 Mock 之外，所有内部 Service 调用都是真实的。验证的时候，我们只验证 API 的请求和结果，不做任何手工数据库插入和读取的断言。这在以往算集成测试，但我们会把它定义成最小粒度的单元测试。

对于 UI 测试，我们有两种。一种是我们写的最多的，就是 React 的 UI 测试。我们会把整个页面渲染出来，在模拟环境中做用户界面操作，比如点击按钮，断言 UI 结果。这里面没有真实浏览器，是模拟的 DOM。

还有一类是 Playwright 那种 E2E 测试，那个测试很慢，我不太喜欢写。一般只测 Happy Pass（主流程），比如登录注册能进首页，写一两个就行。大部分还是 React Mock DOM 的测试。

飞书 OpenClaw 插件维护者：Playwright E2E 其实很重，维护成本也很高。但测试有一个黄金准则：你的测试越接近实际使用的方式，你就越能带来实际的信心，你就越确信这个东西不会坏。

我们的实践是，会更多投人力去维护 E2E 测试。因为它虽然容易坏，但真正抓到线上问题还是靠它。

但 Agent 公司的迭代速度非常快，我们就有了一个准则，我们还是用 Playwright 写很多很多的 E2E，但分类两类：

• 冒烟测试：往主干合代码时，比较激进，只跑 50 个以内的 Case，允许 Mock 后端，保证 5 分钟内能合进去。
• 巡检：面向线上的场景，低频地跑，比如半小时一次，用线上端到端的链路验证。

这里有个简单的实践技巧：给业务应用加测试时，先用一个 Skill 去扫描 UI 组件，加上 test-id。然后让 AI 写测试用例，只验证打开 UI 时 test-id 都在。以此为起点，你可以封装一些能力，这样就不需要每次都依赖多模态模型，成本低且快。

大模型就像「抽卡」，建立一个自己的 benchmark 很重要

基模公司核心工程师：测试这件事情其实很重要。现在的模型每次更新后，权重和训练数据都会变，模型公司是不对这个负责的。这跟做工程不一样，模型类似于「抽卡」。今天抽到 80 分，下次可能是 60 分，波动非常大。

比如 GPT-4o 刚发布时，很多人说缺少了 GPT-4 的「人味儿」。模型公司自己不一定测得出来，因为他们只关注自己的 Benchmark 指标。这件事情其实对 AI 从业者来说，是一个非常疲惫的事情。因为，每天都像是在跟一个新的人聊天。我今天教的东西，明天到底会不会？

所以我的一个建议是，去造一些属于你们自己的 Benchmark，验证它到底能干什么。用这件事情从概率里找到准确性，保证你的东西能持续往前走。

大众还在接受过程中，

少数人已经玩成了「超级个体」

Pro User 玩出了花，普通用户却有点恐惧

AI4S Agent 创业者：因为在湾区，我们离 OpenClaw 这边非常近，也从第一方的视角实际参与进去了。我们跟 OpenClaw 官方组织了一个用户的 Workshop，帮 50 个人配置了 OpenClaw。发现了一些很有趣的东西，在普通人和专业工程师之间，大家对于 OpenClaw 的认知差有点大。

对于工程师、PM 来说，安装 OpenClaw 可能很容易。但对于普通用户时，大部分人其实都不知道怎么弄，他们完全不知道 Terminal 是什么。而且 OpenClaw 很多代码是 Vibe Coding 出来的，有一些不太稳定的地方，在 Mac 或 Linux 上会有各种环境配置问题，所以最终跑通的成功率其实并不高。

但是，一旦跑通了，那种感觉真的有点像「Feel of AGI」。当他把 OpenClaw 跟 WhatsApp、Gmail 连起来，再去操作的时候，那个体验是非常不一样的。

还有一点，大家其实非常恐惧。印象很深，我帮一位女生装 Mac mini 上的 OpenClaw，她之前从来没有接触过编程。装 Gmail 插件时需要去 Google Cloud Console 建一个 App，把 API Key 和 Secret 复制到 Terminal 里。她当时整个人都傻了，有点像被扔到了太平洋正中间。当我离开的时候，出了问题她完全不知道该怎么继续。这个视角非常有趣。

但我跟那些所谓的 AI Native 的朋友，也就是 OpenClaw 的 Pro User 去聊，发现真正跑起来后，对某些行业的效果其实是非常好。比如当公司的 Workflow 已经数字化，且不需要太多人工审核时，整个公司都可以搬到 OpenClaw 上。

我有个 Creator 朋友，买了两三台 Mac Mini，装了 Gemini Ultra 的 Plan。他们公司不光是做内容，连互联网上的 API 调用都自动化了。比如以前他们觉得很复杂的广告投放分析、SEO 优化，现在直接跟 OpenClaw 或 Claude Code 聊，AI 会建议一个方案，人只需要去 Developer 网站把 Key 拿过来验证一下就行。

所以他们都不需要 UI 了，基于 API 把一整套业务都跑起来了，甚至连招人都是自动化的。我有个朋友的 Stack 是：在 LinkedIn 上 Reach 200 个人，收简历和 Portfolio，用 AI Review 结果，再进行 AI Monitor 的面试。从 200 人筛选到 2 人的过程完全自动化，省了大量时间。

Power User 跑起来之后，你会非常 Surprise。他们一行代码不写，纯动嘴就把我们花很多年才学会的 GitHub、前后端开发、甚至各种 Developer Tool 全都跑起来了，而且特别熟练。这个事让我觉得非常 Surprising。

文科生，一行代码都不会写，但被 merge 了 9 个 PR

金融投资从业者：我是个文科生，做金融投资出身的。到现在为止，我仍然是一行代码都不会写。算是一个 Vibe Coder。

但是这两天我开始给 OpenClaw 写代码，提交了十几个 PR，然后被通过了 9 个。所以我现在基本上已经是 OpenClaw 全球贡献者里面前 50 名了。

我发现，正是因为我没有技术背景，反而更依赖、也更天然地接受 AI 技术。传统搞技术的朋友可能更喜欢确定性，比如输入 1+1 必须等于 2。但 AI 编程很多时候是在「抽卡」，可能抽 10 次只有 2 次能用。这种路径差异，可能是很多人使用 AI 的限制。

我现在使用 AI 的方法很简单，依靠三个「AI 员工」组成的团队，部署在我的 MacBook Air 和 Mac Mini 上：

• 一个首席助理，负责安排和协调所有 Agent 的工作；
• 一个 CTO，负责实际的代码编写；
• 一个是 CMO 或者 Social Officer，在 CTO 提交完 PR 后，它会去评论区自动寻找最近活跃的、对这个 PR 感兴趣的 Maintainer，主动 @ 他们。这样可以加快我 PR 被合并的效率。

另外还有一个「需求发现师」，它会 24 小时不断在 GitHub 上寻找 Issue，分析有哪些 Issue 需要被解决，有哪些是比较重要的，有哪些是目前更可能被合并的。

大概是这样的一个工作流，Run 起来发现效果是出奇的好。

Platform Engineering，

正在成为人类工程师的核心

从 Feature Coding 到 platform engineering

飞书 OpenClaw 插件维护者：结合我现在在公司里面的角度，我发现自己做的很多工作正在逐渐往两个方向发展，所谓的「左移」和「右移」。

以前我们可能会很强调工程师的核心能力是做 Feature Coding，但现在你会更注重整个 Platform Engineering 的事情。

往左移，就是在代码合并和发布之前，你要注重比如怎么给代码一个容器化的隔离环境，怎么让 AI 在你约束的 SPEC 下面去编码。

右移部分是说，在代码合并之后，如果有问题，我要能够 Resilience，做一些可观测性的建设，有问题能够回退兜底。

因为你很难保证每天写进来的几千、几万行代码在工程上是可靠的，它可能只是「It works」。那这个时候，传统的软件开发角色就变成了一个左移和右移结合的角色，有点类似于测试开发和平台工程师。

中间的 Feature Coding 反而变得可能没那么重要了，因为它越来越能像 AI 一样能全自动生成。虽然现在无监督的 AI 开发还有点离谱，比如 Claude 号称写了个 C 编译器，但连 Hello World 都编译不了。但再过两年会变成什么样？我觉得还是有非常多工程上可以做的方式，比如从 Platform Engineering 这个角度，或者是否会有新的组织和个体去做相应的质量控制。

比如 Linux 社区就有不同的发行版：有的像 Arch Linux 非常激进，所有东西都往里合，体验最新代码；有的像 Debian 强调稳定，会人工做很多测试才发出来，这种概念可能更适合企业的场景。同时，像这样的概念是不是会得到一些商业上的机会？我觉得也是非常有可行性的。

Agent Computer，会是一种新的硬件形态

Agent 创业者：我看几位嘉宾都聊到家里有不同的小主机在部署 Agent。其实 OpenClaw 相比于 Manus、GenSpark、Happycapy，虽然产品形态类似都是在云端起 Docker 跑 Agent，但 OpenClaw 走向了反面，它是深度结合你本地的，比如联动苹果的通讯录、备忘录。

我觉得 OpenClaw 这一波带火了「个人助理」的意义，它相对于云端产品，跟本地智能结合得更紧密。

大家讨论的形态，在计算机上装 Agent，资源主要给 Agent 用，平时不插显示器——其实是一个新的产品形态。我有个朋友在做叫「Pamir AI」的项目，他们提了一个概念叫「Agent Computer」。

*Pamir AI：一个售价 250 美元、计算器大小的硬件，能 24 小时保持在线，接管重复性工作，甚至能通过物理接口，直接介入物理世界。（内容来自晚点报道）

这就好比苹果诞生于 PC 将出未出的时代。我们想，以后大家可能每天不需要对着几百个软件界面，而是每个人有 100 到 500 个 Agent 来服务他。那时，我们的硬件设备形态可能也会发生很大的改观。

Heartbeat 机制，

让 OpenClaw 更像是一位长期伙伴

OpenClaw 更像是一个「长周期、永远在线、有主动性」的陪伴型伙伴

Agent 创业者：过去一年，我们在做 Claude Code 的开源实现，从我的视角来看，OpenClaw 跟过去传统的 Claude Code 这种 Agent 到底有什么区别？

Claude Code 的设计中，其实也有任务持久化和记忆机制，但不是那么凸显。你跟它的对话很像是一种临时性的对话。打开 Terminal，聊完 Task 就结束了，Terminal 一关，很多人甚至有「上下文洁癖」，用一半就 Clear 了。

那 OpenClaw 显然走向它的反面。你跟它聊，随便聊，你也不知道上下文窗口用得有多满。它不会给你显示 Session Window 占用了多少，但你提的任务它都给你完成。这个时候显然不可能由人来手动管理上下文，它内部必须保持长周期的连续运转。

我觉得这是两个相反的设计。Claude Code 是一个更加单元型的 Agent，关心原子性任务。而 OpenClaw 其实已经不再是一个 Chatbot 或 Chat Agent，它是一个长周期、主动的陪伴，就像你身边的一个同事。

你不会说你跟 OpenClaw 临时开了一个会话，你会把它当做一个长周期的伙伴，因为它的记忆是始终 Online 的，任务是始终往前推进的。而且它有Heartbeat 机制，会周期性地提醒并唤醒自己做一些后台任务，比如做文件的整理或数据的搜集。

我觉得这是两个项目的一些核心差异。上层的产品哲学、心智还是非常不同的，我觉得这也是 OpenClaw 能引爆社区的主要原因。

现阶段，用 OpenClaw 做 SaaS 还蛮难的

开源社区负责人：OpenClaw 出来之后，我就试着让它把我过去几年的发票处理一下：我要求它分门别类，按「故事」线整理，比如这趟是北京出差，那趟是深圳出差，把发票 Group 在一起，算明白里面的税。跟它聊，给它 OCR 工具、Vision Language Model，把 API Key 给它，让它自己上网学。

结果发现它做得还不错。我当时想，是不是可以让 OpenClaw 去做一些有实际商业价值的事情？但坐下来细聊需求后，我发现用 OpenClaw 做 SaaS 还是蛮难的。

首先是成本问题。因为它实际是一个数字助理，给我个人服务很方便。但做成会计 SaaS，假设一个月收二三十块钱，如果每个人背后都绑一个 Claude 的套餐，哪怕是 Kimi，这笔账也是算不过来的。我没办法用纯 AI Native 的方式去交付这个服务。

其次是权限和安全问题。我想过把它包装成带 API 的服务，抽象一部分控制权。但权限控制很难搞。如果放在同一个 Server 上，客户文件之间的隔离很难做。更担心的是，用户跟 OpenClaw 聊着聊着，可能会诱导它改代码——因为 OpenClaw 权限太高了，甚至能改自己的代码。

这就引出了供应链安全的问题。所以我觉得供应链安全这个东西还挺难搞的。结合最近的 SEO，如果未来有人通过 SEO 污染了一个常用 Tool 的搜索结果，Agent 下载了带有恶意代码的东西，那整个安全防线就彻底崩溃了。

最后是 Consistent 的问题。它很聪明，比如说它看到我这个发票的时间点，自动把两张发票关联起来，说这是一个从 A 到 B 再到 C 的 Trip。但当我下次找它做同样的事时，它很难给我一个可复现的、非常 Consistent 的结果。

我尝试用 Prompt 控制它，效果都不太好。如果要把它变成一个 SaaS 服务交付给用户，在现阶段，那我可能还还没有办法完全相信这个 Agent。

Token 税：谁用得越多、试错越多，

谁就越能理解 AI 的「思维模式」

Claude 4.5 Opus 之后，模型开始进化到「可用」的状态了

基模公司核心工程师：直到半年之前，我觉得我还是一个「古法编程爱好者」。在那之前，其实我对模型是属于完全不信任的状态，不管是当时的 GPT-3.5 还是 4，我都试过，这东西没办法去解决在真实工程中看到的各种问题。

什么时候我的思维开始动摇了？其实是从 Claude 4.5 Opus 出来之后。在它之后，我明显地能感知到一件事情，就是模型从我的视角下的「不可用」已经进化到一个「可用」的状态了。

因为我是古法编程，我真的很地道地把 OpenClaw 当时版本下的所有的代码都读了一遍。其实 OpenClaw 整体的架构并没有超出设计的范畴，从头拆解起来其实就三个东西：模型、Loop、Tool。

业界最近在探索一种新的 Agent 使用方式，叫 Proactive Agent。我的第一反应是这东西不就是把 ReAct 变成了后端熟悉的 Cron Job，不断轮询吗？

如果真要做 Proactive Agent，我觉得最重要的因素是记忆。之前 Manus 爆火时我也猜测过它的记忆机制。后来逆向 Claude Code 发现，其实没有什么黑魔法，其实就两件事情：一是通过标注把所有代码执行一遍；二是在 Tool 上做了很多雕花工作，System Prompt，告诉它当前的执行过程。仅仅靠这点东西就形成了魔法。

这件事情其实对我本身的冲击有点大，因为它跟一个工程师的直觉是非常非常反过来的。工程师觉得我得知道一件事情到底是为什么，我才去用。但实际上这一波的模型能力迭代真的有一个分界线，可能就是 Claude 4.5 Opus 之后，模型在 Coding 领域真的从玩具的状态变成了生产级可用。

「Token 税」，是 Vibe Coding 时代的经验条

基模公司核心工程师：最近感触最大的是听了翁家翌的采访，里面有一句很重要的话：环境的稳定性，或者叫迭代的速度，直接决定了当前模型能够进化的效率。

大家觉得模型训练是黑魔法，只要有神算法和神数据就行。但实际上，真正的算法研究员 90% 的时间都在「揉数据」，揉数据决定了能产生多少高质量轨迹供模型学习。这需要快速试错，像抽卡一样，一旦抽中 SSR，就可以无限复制当前的所有轨迹。

这其实也是现在模型训练中的一个最核心的点，就是把一切可被 Scalable 的事情作为第一性原理。

我现在重新反思，如果现在再去做应用的话，可能需要牺牲掉一部分「解耦」的执念。实际上，你给模型一个完全可供自己探索的环境，让它烧 Token 去试，直到发现一条路径是模型一定能走对的时候，这条认知就变成了你自己的能力。

所以，这个时代有一个很严肃的问题，叫做「Token 税」。就是谁用的 Token 越多，谁对于这个东西感知越多，谁能更理解所谓的模型的 AI Native 思维。

包括 OpenClaw 该怎么用？我觉得这件事情其实可能会有一个无聊的废话，但是很正确的答案就是「试」，你不断地试，找到一个它真的能够帮你做哪一件事情，然后在这个过程中再去找那个轨迹，到底什么东西是对的。

文章来自于微信公众号 "Founder Park"，作者 "Founder Park"