OpenClaw 之后，我只想未来 3-6 个月的事情｜对谈 Sheet0 创始人王文锋

好，我们很开心又请到了 Sheet0 的创始人王文锋。

谢谢曲老师。

跟上次录节目也过去快一年了，差不多正好 1 年，准确来说是 10 个月。

我们刚刚还在聊，这一波跟去年那一波其实很像。去年是 Agent 刚起来，我们聊的是整个 Agent；那一波其实是 Manus 带起来的，大家也都开始关注 Agent。今天是 OpenClaw 又带起来一波，最近大家又开始看 Agent 了。你感觉现在跟去年的区别是什么？

1. OpenClaw释放Coding能力

其实我没觉得有本质上的区别。我觉得 Manus 跟 OpenClaw 有一个共同点，就是它们都证明了一类新形态的产品。

Manus 刚出来的时候，主打的场景其实是深度研究。这个场景解锁的核心来源，是推理模型带来的推理能力和思维链能力。那这一波 OpenClaw，我觉得它本质上起来的原因是 coding 能力的释放。

很多人分析 OpenClaw 为什么火起来，有人会说，它可以在你的即时通信工具里面，比如 Telegram、Discord 里很方便地使用；有些人会把原因归结到这里。但从我的视角来讲，本质上 OpenClaw 可能是第 1 个真正把现在最新模型的 coding 能力压榨到极限的一种形态。

在这种情况下，以前大家没想到这个事情能跑通，能达到这样的效果，但是 OpenClaw 把它做出来之后，大家发现，原来可以这么厉害。所以我觉得，去年我们一整年很多人也都在关注 proactive agent。之前其实我们都不知道 proactive agent 长什么样子，大家只知道它的主动性，以及 Agent 的自我迭代、自我进化。

这个话题其实已经被关注、讨论了很久，但是没有东西真的跑出来。OpenClaw 把这个东西跑出来了，所以它跟 Manus 的共同点就是，都证明了新一代 Agent 的形态是成立的。

对，我觉得这是一个非常显著的信号。我记得去年我们那期播客里，你说过一句让我印象特别深的话：“AI coding 是大模型的零售端。”

对。

那其实今天我们看到，这个事情已经被证明了。所以这里面有一个结论：从现在开始，以及到将来，我觉得最终所有的 Agent 都会是 coding agent。

对。其实这一次 OpenClaw 虽然有很多组件、很多模块，但它最核心的东西，叫作 Pi Agent。Pi Agent 本质上就是一个极简、设计得非常好的 coding agent。

简单来说，OpenClaw 可能就是 Pi 的这个 Agent，只不过它在里面解决了 memory 的问题，也解决了不同 channel 的集成问题，比如 Slack、Discord、Telegram 的集成。

另外一个点是，去年大家讨论得更多的是环境：我怎么去做 RL？当时大家的一个观点是，我可能需要针对不同的应用场景去构建不同的环境，然后针对这个场景定制一些策略。比如 Lovable 这样的产品，它有特殊的交互。

但实际上到今天为止，我觉得这个事情已经被统一了。基本上通过 terminal 加 skill，能够做到任何事情。以前我们可能在一些垂直领域里有垂直 know-how 或经验，这个东西没有办法 scale，也没有办法复制，所以只能针对这些场景定制一个所谓的垂直 Agent。

但今天，基本上加上一个 coding agent，再加上对应的 skill，没有一个场景是做不到的。所以现在事实上来看，coding agent 已经成为最核心的部分。

这里有一个变化：基模的 coding 能力跟 coding agent 是两码事。我们需要 coding agent 这个东西去把基模的 coding 能力释放出来。所以今天相对于去年我们说“零售端”的结论，更进一步的是，接下来所有的 Agent，都是围绕 coding agent 去套壳也好，研发也好。

我觉得今年可能所有的 Agent 都会发现，最后本质上又变成了一个 coding agent 的套壳。

去年 Manus 刚出来的时候，大家都吐槽，说这个东西就是一个套壳，有什么好做的？

对，其实 Manus 是模型 API 时代极致套壳的表现。在目前这个阶段，OpenClaw 是针对 coding agent 套壳的最好表现。是不是极致的表现，现在还没有办法判断，但我觉得今年可能另外一个很大的机会就是，谁能把 coding agent 的壳套得很好。

如果我们回到 1 年前，拿今天跟 1 年前做一些对标。大家做 Agent 已经跑了 1 年，当时是 Manus 先起来，然后 Jasper 是最快跟上的，之后又有一些小的产品跟上。

中间大家还衍生出了很多分歧和选择：有人说我要做通用 Agent，比如做一个 Agent 平台，提供一些基础能力，大家可以在上面各自建立自己的 Agent；也有人去做各种垂直 Agent。现在回头来看，在这些路径选择里面，会不会有什么对错标准？

2. 垂直Agent失去优势

虽然我很不愿意承认，但事实上，垂直 Agent 这条路可能需要被高度怀疑。刚才我们已经讲了，现在 coding agent 加 skill，基本上都能实现以前垂直 Agent 的效果，而且不只是垂直 Agent，可能会把整个 SaaS 都打趴。

Anthropic 前段时间发布了一份报告，介绍大家现在是怎么使用 Claude Code 的。从绝大多数人的理解来讲，Copilot 也好，带着“Code”的产品也好，很多人会觉得它们就是给工程师使用的工具，用来做软件开发。

但实际上，在那份报告里，只有 49.7% 的使用场景是 software engineering，也就是大家拿它去写代码。剩下超过 50% 的场景，都是我们看起来非 coding 的场景，比如办公自动化、数据分析、marketing，或者文案编写、copywriting。

所以这个东西已经不是我们推演它怎么样，而是事实上 Claude Code 已经能做所有的事情了。在这种情况下，如果我们还在强调垂直应用，我觉得更多可能是为了避免跟 Claude Code 这样的通用产品竞争，而给自己树立的一种心理安全感。

所以我觉得，从事实来看，垂直应用的逻辑是有问题的。

今天我们群里新明还说了一句话，我觉得挺有意思。我们回头来看，抖音应该是内容时代的王者，基本上也是一站式平台，所有内容都在往它上面靠。

但 To B 领域过去都是垂直的。你看美国市场，可能有一堆百亿美元的各种 To B SaaS 公司。未来 To B 里面会不会也有一家类似抖音，或者类似字节这种形态的公司一家独大？这家公司有没有可能就是 OpenAI、Anthropic 之类的？

3. 通用Agent重写SaaS

说实话，我现在很难预判。但是我们可以分析一下，为什么在 SaaS 时代出现了这么多垂直 SaaS。

为什么大家觉得软件这个商业模式很好？核心是，软件解决了一个本质问题：在没有软件以前，大家想把一个专家的经验和决策能力分发出去，需要培训和学习，这个时间周期很长。

软件的出现，第一次让专家能力能够快速规模化复制。以前我需要学习，但现在我使用这个软件，可能学一个下午就知道怎么用了。按照软件的操作方式，我可能也获得了一个类似专家的能力。

所以当时 SaaS 大家强调行业属性。你要复制专家能力，就需要针对某个行业、某个具体问题或领域，设计一套独特的交互，通过不同的交互，把专家的工作流变成一个 UI。

现在为什么包括 Copilot 出来以后，美股的软件股跌了很多？很多人会觉得，以前的软件要花很多时间去做，但现在有了新的工具，实现它的成本和时间都变快了。

但我觉得这可能只是比较表层的因素。更深层的因素是，软件在过去的核心地位，是规模化复制专家能力的一个载体。现在有了 Agent 以后，我想获得一个专家能力变得更容易了。

以前我还要打开网页、打开 SaaS，学习怎么跟它交互。现在有了 Agent，我直接告诉 Agent 我的目的，它自己就会提出方案、解决问题，然后进行自我迭代。

而且以前的 SaaS 其实是一个通用的专家。不管怎么样，你都用这一套东西。以前 SaaS 和 To B 强调的是 best practice，也就是最佳实践，大家复制这个最佳实践就可以了。

但确实每一家的情况都不一样。AI 相当于给每家公司一个定制化的专家，这个专家还能随着你的情况随时变化。

所以回到刚才的问题，未来会不会有一个类似企业版抖音的东西？

过去我们讲 best practice，我觉得 AI 时代可能没有那么重要。Best practice 的本质是，很多企业的需求我们没有办法很好地解决，所以需要让大家把做一件事情的方法和共识收敛到 best practice 上，因为这个时候 ROI 是够的。

但今天，你的 best practice 和不是 best practice 的东西，让 AI 去执行的话，对 AI 来讲其实都一样，没什么区别。

所以如果通用 Agent 的逻辑成立，最后我觉得可能会有一个统一的东西，去解决绝大多数的问题和需求。至于这个东西是不是 OpenAI，是不是 Anthropic，现在还不确定，但肯定会有一个统一的东西出现。

我们刚才讲了两点。第 1 点，大家会觉得 AI coding 颠覆了 To B 这么多年的积累，因为大家觉得软件本质上就是一堆 coding。

但我同意你讲的另一套类比逻辑：如果软件的壁垒和价值在 coding，那美国的 SaaS 公司早就被所有中国公司取代了，因为中国工程师便宜。如果这个逻辑成立，早就应该是中国 SaaS 起来了，但至少现在还没有看到。

另外就是 know-how。Skill 现在其实还是非常简单的，它真的能取代那么复杂的一套 SaaS know-how 吗？最近 Anthropic 只要出一篇文章，给出一套 skill，对应行业的 SaaS 就大跌。Skill 真的是这么简单的替代方案吗？

4. Skill复刻SaaS工作流

我现在倾向于是。Skill 刚出来的时候，去年 10 月我就在极客公园发了一个动态，我说大家低估了 skill 这个东西。

现在大家质疑 skill 能不能很好地复现原来 SaaS 上的工作流，本质上还是对当前模型能力的怀疑。如果模型能力持续提升，那有什么理由它不能按照工作说明把工作完成？

你给一个真实的人一份工作说明，他能够按照这份说明把工作完成吗？我觉得是可以的。只不过说明里可能有一些工具，这些工具他需要先学习一下。

现在的情况是，我们不是还需要等模型达到像人一样的程度，我觉得今天它已经到了像人一样的地步。现在最大的问题已经不在于模型能不能完全替代 SaaS，这件事我觉得已经被证明了。

所以我插一句，你是非常认可 AI 和 Agent 会颠覆 SaaS 的？

对。SaaS 的逻辑本质上是一套标准的 SOP 或者工作流。以前你只能通过交互约束大家的操作和行为，进而得到一个结果。这个结果可能是 SaaS 里的一张表单、一个 dashboard，或者一条记录。

今天用 Agent 去做，也一样能得到表单、dashboard 或者记录。从效果上来讲，我觉得它是一样的。从使用体验上来讲，如果 Agent 的使用门槛能够进一步降低，对于绝大多数人来说，我想不出为什么还要用 SaaS。

5. Agent能力突破极限

另外一个点是，现在很多人其实不知道 Agent 已经强到了什么程度。OpenClaw 给我最大的震撼不在于产品本身，而在于它的作者。我去看了一下 GitHub 的提交记录，在 OpenClaw 还没有火起来之前，他 1 月份几乎天天在那里 coding，一天最多的 commit 次数达到 1,600 次。

你给不懂技术的人解释一下，1,600 次大概是什么概念？

基本上相当于一个小型工程团队，三四个人这么一个技术小组 1 年的工作量，他 1 天就能干完。

这件事震撼我的原因是，我之前压根没有想到 AI 能做到这个地步。今天 Agent 的问题已经不再是到底能解决多么复杂的问题。一个例子就是刚才提到的 OpenClaw 作者，另外一个例子是，1 月份 Cursor 内部用 Agent 花 1 周做出了一个浏览器，300 万行代码。

另外，Anthropic 官方也用 Agent 断断续续地实现了一个 C 语言编译器。这些都是非常复杂的软件工程。我们在真实世界里，很少能够找到比这还复杂的问题。

这几个例子证明，现在 coding agent 对于长程复杂任务的解决能力，从能力天花板来讲，已经够到这个界限了。但问题是，很多人不知道现在 AI 已经到了这个地步。

如果举一个不太恰当的比喻，顶级的 Agent 使用者，比如一个月能消耗 2 万到 3 万美元 token 的人，假设他们的水平是 90 分，那今天绝大多数人对 Agent 的使用可能还停留在 10 分左右。

这不是简单的 80 分差距，中间的分数差距是非线性的。一个把 AI 用得好的人，可能有 1,000 倍的效率；而一个用得不好的人，要么在做错误的事情，要么只做一些简单的编程任务。

所以第 1 个问题，是让大家知道现在的 coding agent 已经非常厉害了。第 2 个问题是，在知道它很厉害的情况下，怎么让自己也能够把 Agent 用好。

OpenClaw 是一个具体案例，它证明 coding agent 已经厉害到这种程度。现在大家诟病的一个问题，是它整体的配置和使用比较麻烦。这个其实是第 2 个问题：怎么把 coding agent 用起来、用好。我觉得这是今天的一个瓶颈。

但这是不是很多产品化的问题？

对，产品化是一个很重要的事情。但 OpenClaw 这个形态是不是一个好的形态，我现在也在思考，还没有答案。

有人把 OpenClaw 比作 Linux。原生 Linux 好像也没有人直接用，大家用的都是 Linux 的发行版，比如 Red Hat、CentOS、Ubuntu。

如果现在 OpenClaw 是一个 Linux 内核，接下来可能大家可以做对应的发行版。我觉得这个事情可能会有类似的规律，但不一定是简单复制。

现在围绕 OpenClaw，我相信全球至少有 1,000 个团队，甚至不止 1,000 个团队在做这件事。我的观察是，做 OpenClaw 的大概有几类。

第 1 类是把 OpenClaw 简单地做 host，给它提供一个虚拟机环境，让它能够跑起来。这部分用户可能更多还是工程师。真正需要考虑的是，怎么让普通人用起来：比如以前做运营、做销售的人，怎么让他们也能用起来。

我觉得这是接下来最需要考虑的一点。我们团队一直鼓励非技术同事使用 OpenClaw，但事实上，他们确实很难把这个东西配置好。所以这又回到前面讨论的问题：怎么把 coding agent 的壳套好，让普通人也能够用得很好。

我觉得这可能是类似去年 Manus 的一件事情。

对，我觉得这一定是今年的主线。我跟很多人讨论过，OpenClaw 现在的数据大概是 200 多万个 Agent，但里面有很多可能是一个人搞了一堆账号。Manus 应该是几十万用户的量级，Cursor 我估计也是百万级。

这些数据我其实没有特别关注。我主要关注 Claude Code 和 Codex 的数据。现在 Claude Code 的活跃用户已经达到 100 万。对应市场份额来讲，Codex 可能是它的 3 到 5 倍。

这两个加起来，活跃用户应该也有 500 万了。但这 500 万更多还是工程师群体。所以我想说，大家能不能有一个 vision，看到未来有 10 亿用户。我觉得这是一定会发生的。

从渗透率来讲，现在连 1% 都还没到。它未来一定会成为基础设施。

现在提到 OpenClaw，经常会提到几个点。第 1 个是长程任务，第 2 个是 proactive，也就是你刚才提到的主动性，第 3 个是它能不能自我进化。我们可以分开讲。

首先，长程任务这件事，你能给大家解释一下吗？

6. 长程任务突破千步

最直观的表现是，如果大家去用 Manus、Claude Code 或者 Codex，会发现它们在工作的过程中，会把中间每一步在做什么、调用哪些工具显示出来。

基本上，我们可以用它有多少个 step 来描述一个任务的复杂度。任务越复杂，step 就越多。现在我们看到的很多任务，还是集中在几十个 step，比如读文件、访问 API、调用工具。

今年我们可能会看到，它的长程扩展能力能够达到几百甚至上千步。这里面核心需要的是对问题的拆解能力。

但我记得去年我们聊的时候，提出过一个问题：步骤增多以后会有不确定性，准确率会下降。哪怕每一步的正确率都是 90%，串联下来最后的正确率也会非常低，而且中间容易产生闭环空转、死循环。

这些问题现在仍然存在吗？还是已经被解决了？

我觉得这个问题应该已经解决了。去年那个时候的逻辑是，我把 Agent 做成一个状态机，状态存在内存里，第一步、第二步、第三步是不可逆的。

但今天的最佳实践，已经把状态落到了文件上。这样，如果前面有几个步骤做错了，Agent 自己具备修复问题的能力。比如它发现 memory 或 progress 文件改错了，就可以直接把文件改回来，把这个错误修复掉。

所以错误修复现在已经不是一个问题了。所有东西 file system 化以后，Agent 能够明确看到问题在哪里，也有了自己修复问题的能力。

这能不能理解为，长程任务、自我修复能力等等，其实是模型能力提升带来的？

模型能力是一方面，另外一个方面是大家发现，把模型跟文件系统结合在一起是最好的。

除了模型能力本身提高以外，我觉得还有一个很重要的东西，就是围绕模型 API 演化出来的一整套工程方法论：我们怎么基于文件系统，或者怎么给模型配一台 computer，让它能够自己组织数据、组织逻辑。这些东西是共同决定的。

这其实就是去年我们当时聊的 context。现在我们找到了一条路径：context 就是给它一台电脑、给它一个文件夹，这可能是最好的 context。

去年那个时候的逻辑还在于人去控制 context。今天我们会发现，最有效的方式不是人去控制 context，而是让 Agent 自己去维护 context。

这最终还是回到 Manus 当时 Hikaru 讲的那句话：less structure, more intelligence。我们回头看，可能人家一直就是对的。

在这件事上，有些人不相信，有些人可能相信，但觉得自己要做一些差异化出来。可实际上，做这种差异化可能只是一些雕花工作，不一定 work。

长程任务讲完了，那主动性这个事情怎么理解？

7. 主动Agent开始管理AI

长程任务跟主动性是非常接近的一件事。比如我们现在使用 AI 产品，很多时候是一次性的任务：给我一个报告，帮我写一个小程序，或者写一个小网站。今天做完，任务就结束了，这次会话也就回收了。

Proactive 我觉得分两类。第 1 类是这个任务是不是需要重复、持续地执行。最简单的例子是，每天早上 8 点给我发昨天的工作总结和工作纪要，或者每天晚上 10 点把今天群里讨论的问题、哪些事情还没有办完，写成当天的日报发到群里。

这些事情不需要我主动 prompt，它能够基于过去跟我的交互，知道我现在需要什么，然后主动把这些东西提供给我。在这个过程中，它还能够不断优化自己的工作流。

但你刚才举的例子其实有两种情况。一种是我告诉它每天 8 点发给我，它每次都发。这个好像不是非常主动，仍然是被动触发的主动。

另外一种是我没有告诉它，但我突然发现，今天它多做了一件事，明天又多做了一件事，相当于给我提供了一些惊喜。我们讲的主动，应该更偏第 2 种。

我觉得这确实是第 1 步和第 2 步的区别。设定一个定时任务，是一种主动方式；更主动的方式是，我不把它设定成任务，而是在日积月累的过程中，它更了解我的业务、性格、角色和工作内容。

这就像一个同事，有一天主动告诉你：“我发现我们有一个问题，还有一个比较好的方案，你看我们这么做行不行？”

这其实就是字节讲的 context, not control。给它足够的 context，让它知道我要做什么，也懂我。遇到一个情况，它就会自己主动处理。

这里面的核心是，Agent 能不能主动探索，然后自己进行反思、总结和迭代。如果一定要定义真正的 proactive，我觉得可能就是这种情况。

现在 OpenClaw，包括整个 Agent，做到哪一步了？你自己日常使用时，有没有遇到过这类案例？

这里面还是会有一个 setup 的过程，这是一个典型的先有鸡还是先有蛋的问题。它想了解你，你必须先跟它产生一些连接。

我一直在研究大家怎么使用 OpenClaw。我觉得现在一个新的范式，或者说我们讲的 product agent，其实还是比较抽象的。真正的 product agent 可能是一个产品形态问题。

最早我们是 chat。后来 MCP 出来以后，大家发现这个东西可以断断续续地把应用解决掉。总体来讲，现在还是一个人与 AI 的关系。

我觉得 OpenClaw 更大的作用是 AI 管 AI。所以如果一定要定义一个点，我觉得 product agent 就是一个 AI 管 AI 的 Agent。

以前你需要自己管理一大堆 Agent：管理 Manus、Jasper、ChatGPT、Claude Code。你直接管理这些 Agent 的时候，相当于所有事情都是你主动提出来的。

接下来，如果你想让 Agent 主动帮你做事情，这个需求就不应该由人提出来。既然不是人提出来，那应该由谁提出来？应该由 AI 自己提出来。

AI 自己提出任务以后，能不能把任务完成，能不能形成闭环？自然而然，这就是 proactive。但这肯定不是单个 Agent 能够做到的，因为现在 Agent 虽然能力很强，还是需要 setup 的过程。

所以我们能不能有一个 meta-agent，让它能够 setup 出一些特定的 Agent，专门解决一个个特定的问题？问题解决之后，我可以把成功经验记录下来，然后把这个 Agent 释放掉。

所以在这个里面，我觉得 proactive agent 可能就是一个管 AI 的 Agent。

聊到这里，AI 管 AI 跟 Agent 的自我进化也相关。这个事情你怎么看？如果它足够主动、足够智能，现在大家讲一个人的效率提升 10 倍、100 倍，替代一些基层工作的人，那未来它是不是可以替代所有人？

我们回过头看，AI 最早的落地场景，其实是客服领域。当时我们看到，一个原本可能有 10 个客服的团队，有了 AI 之后，可能把 10 个客服变成 1 个客服。

所以在 productivity agent 的情况下，我觉得可能也是类似的。比如我现在团队里有 10 个工程师，可能只需要留下 2 个。为什么还要留 2 个？因为大家讲的 taste，我觉得这个东西很难被 AI 替代。

我们看真实的人与人之间的交流。如果在团队里，我需要把一件事给你讲清楚，你才能理解这是什么、应该怎么做，我觉得这种情况很危险。因为把事情给你讲清楚的功夫，我已经给 AI 讲完了，AI 可能马上就做出来了。

现在我们需要的是，我可能点一下，你就知道我在想什么、在做什么。为什么我点一下，你就知道我在说什么、想要什么？可能是因为我们之间有默契，而这种默契是在平时的工作和生活中培养出来的。

它其实是一种先天自带的 context，也可以说是一种悟性。所谓悟性，可能就来自之前的 context：比如这个人之前在字节做过几年，所以我点一句，他就知道了。

但这里也带来一个问题。现在包括 NotebookLM 之类的产品，大家也在讲 AI 跟 AI 交流，把自己的 OpenClaw 放出去，跟其他 Agent 学习。这件事到底有多大作用，能不能实现？

比如今天你的 Agent 在你这里做了很多事情，学会了这一套东西，出去之后能不能教另外一个新的 Agent：“这套东西应该这么做”？然后那家公司的人可能只说两句话，它就能把这套东西做出来？

我觉得可以。从目前实际的 Agent 能力来讲，我觉得这件事是能做到的。只不过这里面的问题是，有多少东西值得这样分发和复制。

不同企业有不同流程，业务也不一样。这就像招聘一样，本质上这个人是有能力的，但招进来之后，还是需要让他适应公司内部的流程和大家的工作方法，需要一个磨合周期。

Skill 能够积累经验和工作方法论，我觉得这些东西是可以复制的。但比如我们公司内部的 coding agent，针对我们的代码仓库、工作流程优化了一个 Agent，我把它放给另外一家公司，可能对那家公司没有太大价值。

所以还是回到那句话：我怎么根据公司内部的实际特点，搭建一套 proactive agent 体系？至少在现在这个阶段，它不是一个自然而然就能发生的事情。

比如现在有一个产品，我购买或安装之后，它就能够非常自动地探索，查看我的各种文档并吸收这些内容。我觉得至少目前，这件事还有一定距离。

明白。你自己使用 OpenClaw，包括研究大家怎么使用的时候，有没有遇到过什么 aha moment？

8. AI接管工程流程

我说一下我们现在日常的工作流。我们收集用户反馈和需求，会在 Linear 这个平台上管理，它类似于一个项目管理软件。然后每天在例会上把任务分发给工程师，工程师拿到需求之后，用 Claude Code 这些工具开发，开发完测试，测试完提 PR，再合并。

现在我们把 Linear、GitHub 和日常聊天工具 Slack 的权限都开放给 AI。我们发现，AI 收到一个 Linear 任务之后，就能够直接把任务做完、测试，然后提交到 GitHub。

以前中间还需要我们把任务分发给人，再由人指挥 AI。现在变成了 AI 监控工程师，绝大多数任务它都能直接做完。

所以工程师从原先的 AI 指挥者，变成了最后的质检员。他最后看一下 PR 有没有问题，PR 里面还会带上测试结果。如果是前端相关的修改，还可能带一些前端截图。

这件事是我在春节前做的，当时让我非常震撼。我们下意识会觉得它现在还做不到，但实际上只用 1 周时间，这套东西就完全跑通了。

所以你们现在实际的效率，你觉得涨了多少？

我个人觉得，我的效率至少比去年这个时候涨了 10 倍。

如果这么讲，大家一般默认以前开发一个产品，可能需要几个人的团队做 1 年。效率提升 10 倍，是不是意味着今天一个新公司，以前需要 1 年才能发布的产品，现在 2 个月就可以发布？

我觉得 2 个月都太慢了，现在可能 2 周就够了。之所以现在的瓶颈不在生产效率，是因为生产效率已经没有瓶颈了。

现在核心的瓶颈是做什么、做成什么样，这个东西最难。大家都讲 idea is cheap，但现在我觉得 idea is not cheap，idea 其实很重要。当生产能力无限扩张的时候，一个有意思的东西反而很难得。

这也是刚才我们聊 OpenClaw 时，我觉得另外一个奇怪的点。OpenClaw 1 月份出来，到现在大家围绕 OpenClaw 还在做二次开发，或者简单地把 OpenClaw 做 host，并没有一个全新的 OpenClaw。

因为 OpenClaw 代表了一种产品形态：AI 管 AI，释放了 coding agent 的能力。但现在还没有一个同样是 AI 管 AI、释放 coding agent 能力的新形态产品出来。

所以问题一定不在构建能力上。本质上，我觉得可能是产品定义和产品形态比大家想象的还要难。

今年除了刚才聊的这些 Agent 变化，你还觉得有哪些值得期待的发展？

我现在比较期待 Agent Harness。去年我们其实在讲 context engineering，但 context engineering 是一个很抽象的概念。它的作用是让大家意识到，有一个东西对 Agent 的成功与失败至关重要，但这个东西到底长什么样，大家还不知道。

Agent Harness 是去年 9 月左右在硅谷出现的一个概念，现在可能还只是在小范围流行。我觉得 Agent Harness 的核心作用，就好比人要骑马得有马鞍一样。

马很狂野，尤其是好马。人要骑它，就需要想办法约束和驾驭它。Agent 也是一样的。如果把 Agent 比作一匹绝世好马，人怎么控制好 Agent 的行为？这时候就需要 Agent Harness。

Agent Harness 有意思的地方在于，它不像以前的 SaaS。以前的 SaaS 有明显的分层结构：最下面是 infra 层，中间是 SaaS，最上面是终端用户，也就是 end user。

Agent Harness 更像是一个面向 end user 的脚手架。针对不同人的特点，比如身高、体重；对公司来讲，就是团队的业务，以及团队内部同事的特点，把这些结合起来，构建出一套符合公司情况的脚手架，让业务能够在公司的环境里快速跑起来。

这是我今年比较期待、也希望能看到进展的事情。它跟 infra 又不太一样，因为 infra 更多是面向 developer 的东西。我觉得 Agent Harness 有一点 infra 的属性，但它又是一个比较面向 end user 的东西。

既然提到 infra，你觉得新一波 Agent 还会有什么新的 infra 机会？Container 本身已经在被 infra 化了。今天 Claude Code、Codex 本身是直接给程序员设计的，不是为了让 AI 管 AI 而设计的。

我们已经看到，Agent 会套 coding agent，把 coding agent 作为自己的智能引擎和内核去做产品。那会不会有更好的 infra？比如 OpenClaw 里的 Pi coding agent，我觉得它就是一种 infra。

至少目前我还没有看到特别明显的东西。如果一定要说，可能有一部分用法是大家使用 Obsidian 这类产品，作为自己的上下文管理工具。但这件事能不能成为一门生意，我觉得不好说。

Andrej Karpathy 最近也在推特上反复讲，现在大家缺的不是 MCP，也不是 API，缺的是一个让模型或者科研人员更好工作的 CLI。

CLI 的全称是 Command-Line Interface，也就是命令行工具。Claude Code 本身其实就是一个 CLI，OpenClaw 也非常依赖 CLI。

Andrej Karpathy 做的一件事，是把一些 MCP 变成 CLI。如果一定要说 infra，我觉得 CLI 这块是一个 infra。另外一个可能是权限管理。

我想到一个问题。之前大家都觉得 AI coding 主要是前端能力很强，后端还是比较弱。现在怎么样？

其实我觉得不弱。

你是觉得它当时就不弱，还是现在变得不弱了？

当时可能没有想到它有那么弱。今天我觉得，它跟前端相比已经没有明显的弱势。

之前大家觉得 coding agent 的前端能力很强，是因为它能够看到自己写完代码之后前端变成什么样，有一个可验证、及时的反馈。

大家以前说后端能力弱，有两个原因。第 1 个是它见过的后端代码没有那么多，因为没有办法提供反馈。第 2 个是后端修改之后的逻辑，可能都在程序内存或者数据库里，AI 没有办法直接访问内存和数据库的数据。

但今天，针对自己的程序，比如我们 Sheet0 已经做了一套相关工具。它改完代码之后，相当于代码里有一个专门给 AI 开放的接口，AI 可以直接访问内存状态，我们也把数据库权限开放给它。

这时它发现数据跟预期不一致，就知道出错了；出错之后，它还可以继续迭代代码。所以现在后端能力并不弱，关键在于你有没有为 AI 提供反馈和访问数据的工具。

但大家经常提到幻觉和安全性的问题怎么解决？比如数据库权限都开放给它。

你可以只给它 read-only 权限。关键还是设定好权限，不会让它突然有一天把数据库全部删掉。

整个权限管理，我觉得也是一个 infra 机会。机会是有，但能不能被产品化，是一个挑战。

我觉得 Agent 这件事已经聊得挺全面了。接下来聊聊你们自己。这一年 Agent 变化这么大，尤其是 OpenClaw 出来之后，Sheet0 现在在做什么？有什么改变？

我们这期播客上线的时候，你们应该已经发布，或者马上要发布一个新版本了。给大家讲讲这个新版本是什么，大概做什么？

9. Sheet0转向AI管AI

新版本就是把刚才讲的、我们内部 Linear 那套流程产品化。

是给 engineer、developer 用的吗？

对。

所以你们是大转型了？

对。现在的思路是，我们要做 AI 管 AI。

我觉得今天做一个更聪明的 Agent，或者做一个更好的 Agent，已经没有太大价值了。现在基本上，coding agent 已经足够聪明了。经过精心配置之后，我觉得没有什么事情是它做不到的。

但问题是配置过程太难，门槛太高。所以我需要一个 AI，能够更好地管理和配置这些 Agent。相当于以前我有 5 个人，自己管不过来，现在需要雇一个专门管理这些 AI 的 AI。

去年我自己的一个问题是太依赖预判，总想讲一个不一样的东西。但今年我们的策略是，预判为辅，跟随为主。

我聊过很多创业者，我觉得你这句话有一种非常成熟的创业者的感觉。我们之前放了一期跟艾普特录的节目，里面有一个很重要的点，就是要优化胜率，而不是赔率。

对，务实地把一件确定性高的事情做好。

当时我们内部讨论过一件事。我问大家：“假如回到 2025 年 3 月底，你们做不做 Genspark？”3 月初 Manus 出来，3 月底、4 月初 Genspark 出来，我们团队只有 1.5 个人说要做 Genspark。

所以你们团队比较有梦想。

对，大家都是技术和产品理想主义者。本质上其实是在优化赔率，而不是优化胜率。

所以今年我们的策略就是跟随为主。产品上要做到一种能够快速修正产品方向和重点的产品形态。

我们的策略就是 AI 管 AI。以前程序开发需要程序员驱动 Claude Code，现在 AI 能不能直接驱动 Claude Code？

之所以选择 coding 这个场景，是因为我觉得现在 AI coding 进入了一个新的阶段。第 1 个阶段是 Copilot，靠补全；接下来是 Claude Code 和 coding agent 的范式，本质上还是程序员主动 prompt，它是 reactive 的。

虽然它能够有很好的端到端表现，但需求输入还是人来输入。现在进入第 3 个阶段，就是 AI 指挥 AI 去实现代码。这个时候，需求输入从人输入变成 AI 自己输入。AI 可能还需要去澄清需求，但这正是我们团队现在迫切需要的东西。

我觉得这个方向很好，因为我发现很多做得很好的公司和产品都有一个特点：他们自己本身就是用户。你们做的这个产品，本身也是你们自己的用户，所以它是一个正向循环。

对。我们解决的问题是，我觉得现在大家使用 AI 的水平差距真的太大了。我们做的其实也是一种平权：怎么把现在使用 AI 只有 10 分的人，拉到 60 分以上。

我们团队上个月 AI coding 的支出是 2 万美元。我觉得现在大家都很需要让自己变成 10 倍、100 倍的团队，但对于怎么做到 10 倍、100 倍，大家其实还不知道。

所以我们先在 coding 这个场景上做。一方面我们自己能用，另一方面 coding 的需求已经被验证了，它是一个 1.5 步范围之内的需求。

现在正好发生了一个变化。以前在整个软件工程链路里，业务方提出需求，需要工程师分发，工程师再驱动 AI 干活。现在的范式变成，业务方提出需求，AI 自己把活干完，程序员最后变成质检员。

我刚才有个小问题。像 CodeRabbit，做的就是你说的 code review。那质检这一步为什么不能也用 AI？相当于最后代码合并那一步。

这个地方不是 code review。质检其实就是由人点一下合并按钮。

因为点合并按钮的时候，人需要扫一眼。相当于良品率可能有 99%，但流水线上还是需要最后有一个人贴合格证。

明白，其实就是审核员审核上线。

那你们的用户画像大概是怎么样的？

从画像上来看，一半是 founder，剩下的四分之一是超级产品经理，还有四分之一是超级 builder。

这些人的典型特点是想法特别多、思路非常清晰、有很强的 ownership，而且擅长同时处理多个领域，比如设计、产品，研发可能次之。总体来讲，大家都是复合型、知识面很广的人才。

所以你面向的第 1 波用户，可能是消耗 1 亿 token 的人。那后面，或者最终，你觉得你的用户是还不会用 coding agent、可以用你们的产品，还是已经在用但没有用好，或者是只有用得很好的人才能把你们用好？

这可能会像 SaaS 时代的不同商业模式：你是 To Enterprise 还是 To SMB？Agent 时代可能也会有类似划分，但不是按照组织人数，而是按照 token 消耗量来划分。

SaaS 时代有一个观点，是要服务世界 500 强用户。那我们服务这些超过 1 亿 token 的用户，就好比过去 SaaS 时代服务世界 500 强。

这个逻辑就是，我们把 C 端也分成中大 C、小 C。我们可以先做中大 C。

核心逻辑是，当一个用户或者一个主体 1 年可以给我贡献 10 万美元的时候，我为什么要去区分它是一个人、一个团队还是一家公司？

如果我能服务 1,000 个这样的用户，1 年是不是就是 1 亿美元的 ARR？这是今天最大的变化。以前不可能从一个人手里收到 10 万美元，但现在可以。

几万美元这种体量的用户，应该就是创始人了。因为他肯定是做这个事情最后能够很快赚钱的人，不可能是一个打工人，拿着工资还自己花这么多钱。

所以我刚才讲，我那个投资俱乐部里一般是创始人，其中绝大多数是 AI-native 的 founder。还有一类是公司里非常核心的骨干。

我知道有些已经成立了 10 年的公司，内部专门成立了 Agent 测试小组，把全公司 token 消耗前 10 的人聚在一起，直接汇报给 CEO 和 CTO。

组织其实也在做这方面的调整，最后一定是报销的。未来可能人跟公司不会再有那么明确的分界。

对。为什么现在可以从一个人或者一个小组织，也就是我们以前定义的 SMB 手里收到 10 万美元？因为这 10 万美元可能就是他招聘工程师的预算。

在硅谷招一个工程师要 15 万美元。招几个人就是上百万美元，但现在可能只需要 10 万、20 万美元，就能达到一样的效果。

我在想，如果效率这么高，最终会怎么样？当下失业的人会焦虑，会学习，其中一定有人能够学会，再赶上来。这些人自然而然可能会变成 1,000 万 token 或者 1 亿 token 的消耗者。

但如果效率真的这么高，最终是不是一个产品和需求供给的问题？世界上需不需要这么多产品？

如果每个人都是所谓的“一人独角兽”，那独角兽的容量会不会变？比如现在全球可能有 1,000 家独角兽公司，最后人人都是独角兽公司，那需求从哪里来？

10. 只看未来三到六个月

我的观点是，这可能是一个负反馈循环，而不是正反馈循环。

现在整个市场里的需求是一层套一层的。我把工资发给员工，员工再去消费，通过这种正向循环，需求的盘子越来越大。

但很多人失业以后，就没有消费需求了。依赖这些工资收入进行消费的企业需求萎缩，而这些企业的需求又进一步传递到上游，于是就成了一个负反馈循环。

所以我只考虑未来 3 到 6 个月的事情，因为你不知道将来会变成什么样。

它有点像以前说的各种平台打掉中间商。现在劳动力市场里的中间商，就是实际做事的人。

对。所谓一人独角兽公司，本质上就是把员工都打掉了，AI 在某个层面上扮演了这个角色，把中间的人打掉。

如果这个事情发展得非常快，我觉得社会稳定可能会出现很大的问题。

这个问题就交给聪明人去解决吧。我觉得这是一个非常复杂的社会问题。

在这种情况下，你们团队受到的影响是什么？

我们招人非常谨慎，也非常苛刻。按照以前的标准，我们现在团队可能已经有十几到 20 个人，但现在只有 7 个人。

这 7 个人的产出速度和效率，我觉得可能相当于原先 30 到 50 个人团队的效率。

你觉得这些人在使用 AI coding 的时候，是能够培养和训练出来的，还是需要他们一开始就具备这种能力？

我觉得可以培养和训练，但前提是组织愿意给他们提供不受限的 token 消耗额度。

这也是一个问题：最后怎么评判和衡量产出？比如你刚才说，你们最多一天花 4,000 美元。这个是一个人，还是整个团队？

假设今天有一个人 1 天花了 1,000 美元 token，你怎么评判他的产出？

这是下一步的事情。现在要做的是先让大家跟上，谁跟不上就淘汰谁。

衡量产出这件事，可能还是要靠人来判断。作为 CEO，你要看账单：这个人今天消耗了 2,000 美元 token，或者这周消耗了七八千美元 token，那你就要看他这周的产出是不是跟消耗匹配。

如果不匹配，说明这个人有问题。你可能要么解决问题，要么解决这个人。

我觉得我们这期标题就可以叫《我只解决未来 3 到 6 个月的事情》。

可以。事实上就是这个样子。

去年你解决的是多长时间维度的问题？

去年我解决的是 5 到 10 年以后的问题。Sheet0 终局的目标，是做到 100% 的可信。

我一个很大的体会是，不要去尝试解决那些人们还没有遇到瓶颈的问题。像去年 Sheet0 的理念，是要做到 100% 可解释、100% 准确。这件事非常正确，也很有价值。

你问每个人需不需要，每个人都会说需要。但你真正去解决这个问题时，首先模型做不到；其次，人们在这个阶段其实也没有那么敏感。大家的瓶颈并不是“因为不能 100% 准确，所以我就不能用了”。

这个阶段，模型可以带来更多其他方面的好处。没有必要因为一个点，就否定模型的价值。

现在工程师的注意力已经被十几个 terminal 窗口约束住了，他们确实在这里遇到了瓶颈。所以我觉得应该顺着他的瓶颈，顺势解决问题，而不是在那里试图说服他“你现在应该这么做”。

我只是把大家都遇到的问题总结出来，做一个产品，然后顺着他们的需求多做半步。

所以今年你们是跟随为主。但你为什么觉得这是跟随？我觉得好像也没有人在做这件事。

它更多是逻辑层面的跟随。可以理解为，我们跟随的是一个正确的大方向，或者一个明确的趋势。

以前我的预判可能能管半年，但现在 AI 发展太快了，一个预判最多只能管 1 到 2 个月。既然这样，我就不预判了。

因为预判会带来一个问题：你会在自己的预判上下注。压对了当然没问题，但如果压错了，转向和反应的成本就会变高，速度也会变慢。

尤其是 AI coding 带来了效率提升。你判断一个东西，可能 1 个月就做完了，其实也就可以了。

对。所以这件事更多是解放我们团队的思维。真正把心里的 ego 放下，其实很难。

回到 2025 年 3 月底，要不要做 Genspark？现在 1 年过去了，我们已经看到 Genspark 非常成功，最近新融了好像 1.5 亿美元。你想，当时大家的第 1 反应是不做，这件事其实很离谱。

从商业逻辑来讲，它确实很离谱。但本质上，现在创业的人为了讲差异化，往往会过度放大自己的 ego。

所以我们讲跟随，不是说抄，而是要迅速认识到自己哪些地方没做对，客观地看待这件事。

现在我觉得最大的机会就是 OpenClaw。OpenClaw 本质上是 AI 管 AI。AI 管 AI 的产品到底该怎么做、怎么发展，我觉得这是今年最值得期待的一件事。

挺好，非常期待你们的新产品。

谢谢曲老师。