夜雨聆风
OpenClaw:别了GUI,AI Agent正终结软件时代
|
|
我们曾以为自动化只是把重复点击串成流程图，直到 OpenClaw 这类“瓶中精灵”出现：你只说出一个意图，它发现没有现成插件，竟会当场写代码、自我扩展，传统 RPA 瞬间像提线木偶。可超能力的代价同样惊人：为了帮你安排行程，它可能顺手索要公司邮箱的全局访问权。另一边，互联网巨头还在用验证码和停留时长守住旧世界，Agent 却已试图绕开界面，直达任务本身。这已不只是效率竞赛，而是一次关于权限、边界与交互入口的重构。当前方界面开始消隐，我们迎来的，究竟是生产力解放，还是更难收回的风险？
【读书笔记】
1.OpenClaw 的核心竞争力在于其“自我扩展”的递归特性，与传统 RPA（机器人流程自动化，用软件模拟人工操作）不同，OpenClaw 可以代表用户通过临时编写新集成来扩展自己；Joel 提到，这是他见过第一个可以直接对它说“我想要某个集成”，然后它会启动 coding assistant 来自行“拼”一个出来的系统；它还能利用 MCP（模型与工具交互的标准协议）层连接 1Password 或各种长尾工具
2.Agent 的安全挑战在于现有的权限模型过于粗放（All or Nothing），Joel指出，在配置 Gmail 时，系统建议给予带有 domain-wide scope 的 token；这意味着 Agent 不仅能访问自己的邮箱，还能访问公司里每一个人的邮箱。Google 目前缺乏针对具体场景的细粒度授权；Guido 认为，安全控制点必须从矛尖（前端 bot 检测）后移到后端系统（Redoubt 堡垒防御概念）
3.Agent 正在倒逼安全实践从“人类懒惰”中解放，实现真正的最小权限原则，人类因为怕麻烦而拒绝复杂的安全机制（如 PKI 或频繁轮换密码），但 Agent 对复杂性免疫；Guido 提出，Agent 可以处理那些人类觉得太痛苦的隐藏式 PKI 或自动化的 token 轮换；这意味着 Agent 时代反而可能是修复人类遗留安全债务的契机
4.现有的 Web 环境对 Agent 存在天然的商业与技术敌意， 像 DoorDash、Amazon 这样的消费网站没有为 Agent 准备 API，且布满了 CAPTCHA（验证码）和复杂的真人验证谜题（如连续解 6 道题）；这是因为大型 Incumbent（既得利益巨头）的商业模式依赖于交叉销售和用户在 UI 上的停留时间，而 Agent 直接完成交易会终结这种逻辑
5.Agent 的普及将使传统图形用户界面（GUI）走向消失， Guido 认为，我们正经历从重新思考产品体验到 UI “消失”的过程；未来用户不再需要关心 cron job（定时任务）或复杂的菜单，只需要在更高抽象层定义任务；Agent 将作为 LLM UI 统一编排系统，人类只需要在关键的“价值分岔点”参与决策（Human-in-the-loop）
本文编译自发布于2026年3月19日发布于a16z的合伙人Yoko Li、Guido Appenzeller 和 Joel de la Garza的访谈，原链接：
https://podcasts.apple.com/us/podcast/openclaw-why-the-internet-isnt-built-for-ai-agents/id1740178076?i=1000756118803
以下是原文的全文翻译，enjoy!
注：正文中标蓝部分为读书笔记的对应原文。
Yoko Li：a16z合伙人
Guido Appenzeller：a16z合伙人
Joel de la Garza：a16z合伙人
【正文】
Yoko Li：作为开发者，这东西我完全能做出来。我不会把所有那些长尾集成全都做完。
Guido Appenzeller：光是我们要经历这样一次过程，从根本上重新思考这类产品的体验该是什么样，就已经让人无比兴奋了。现在，你只需要用自然语言表达自己想要什么，机器就会替你完成。
Yoko Li：我更好奇的是，这个 UI 层未来会长成什么样？
那些大型 incumbent 会不会追上来，开始为 agent 提供这些能力？还是说，我们实际上需要一些专门为 agent 服务的新公司？
Guido Appenzeller：安全始终是一场纵深防御的游戏。你前面遇到 CAPTCHA、前端 bot 检测这些东西，其实只是矛尖最前端的那一层。防御里有个概念叫 redoubt，就是你会退回到内层堡垒。我觉得，面对 agent，很多这类边界控制最终都得更多地后移到后端系统里去。
Joel de la Garza：我觉得特别有意思的一点是，这是少数几次我面对一项技术时，它能做什么并不是受限于能力本身，而是受限于我该怎么把它做得安全、怎么阻止它去做某些事。我们像是拿到了一个被装进瓶子里的精灵，厉害得惊人，问题是我该怎么把它关在里面。
OpenClaw 是一个开源的个人 AI 助手，它可以代表你发消息、查看你的日历、管理你的邮件，还能通过临时编写新的集成来自我扩展。配置 Gmail 集成要花7个小时。这个 agent 还会要求获得你公司里每一个邮箱账号的 domain-wide access。像 DoorDash 和 Amazon 这样的消费网站又没有给 agent 准备 API；如果你不够小心，就可能做出一个会被社会工程利用、从而获取它本不该拥有访问权限的系统。这是一种限制因素不在于能力，而在于约束能力的技术。精灵已经在瓶子里了，问题是如何让它继续待在那里。
Joel de la Garza：大家好，今天我们来聊 OpenClaw。它现在可能是 Silicon Valley 最火、最有争议、最有意思、也最危险的技术之一。你要不要先开个场，说说它到底是什么？
Yoko Li：OpenClaw，到底什么是 OpenClaw？它是一个很酷的开源个人助手，底层构建在另一个也很酷的 coding agent——Pi——之上。我记得那个 repo 叫 Pi。它本质上是一个非常精简、但扩展性很强的 coding agent，能自己跑 loop，也能更新自己的配置。OpenClaw 则是在此基础上，加上了 Pi 的 session state 管理，同时补上了一大堆长尾集成。所以现在你可以通过 WhatsApp、Telegram，甚至一个电话号码、iMessage，以及你能想到的几乎任何方式跟你的个人助手交流。还能接 1Password。它还不能在 DoorDash 上下单，不过这个我们后面再讲。总之，整个生态现在正快速热起来。
我们还能把一个长期运行的 agent 放在沙箱里，所以大家都做出了一些有意思的用例。我最早探索的一个用例是：能不能让 OpenClaw 持续通过 AirTag API 检查我家猫的位置？因为 AirTag 的位置只有在浏览器里的用户会话处于活跃状态时才会更新，所以这其实挺有用的。我很好奇你们最近都拿它做了什么。
Joel de la Garza：所以你肯定是爱死这玩意儿了。
Guido Appenzeller：我现在其实就在用，也已经用了一段时间了。我觉得它非常棒，因为它能让你看到未来的大致轮廓。这是我们第一次真正看见这些 agent 会去做什么。
我们这家机构一直是围绕 Mark 那篇著名的《software is eating the world》建立起来的。而这是第一次你真的能看到这些 agent 正在“吃掉这个世界”——它们是真正能在现实世界里做事的 agent。所以我一开始做的几个用例当然都非常偏安全方向。我特别喜欢折腾这些东西，试着先把它跑起来。正如你们知道的、也都体验过的那样，这并不简单。我之所以作为 CISO 目前还没有特别担心大家会广泛用它，部分原因就在于，真正能把这东西跑起来的人其实还非常少，只有很小一撮人能做到。
Joel de la Garza：这很像典型的工具问题：太难用了。
Guido Appenzeller：这在这里反而是个功能。没错。现在还有人问我们 Homebrew 是什么。等哪天它真的能轻松装到电脑上了，那我们就得开始担心了。但你已经能看到，一旦这些东西变得更消费级、更容易用，它们就会彻底起飞。这会是一波非常巨大的浪潮。而构建这些工具的过程也真的非常有趣。
Yoko Li：我挺好奇的。像我们这种普通人，会拿它查猫的位置、看日历、做笔记。那安全方面的用例是什么？
Guido Appenzeller：这跟模型有关，不同模型的能力差异非常大。所以我最开始做的第一件事，就是给它一些不可能完成的任务。比如我说：我需要你做成这件事，但你只有两个工具可用。有些模型会直接放弃，说对不起，做不到，或者类似这样。有些会尝试写点代码，做一些挺有意思的事。但有些更先进的模型，真的开始用一些“黑客式”的手段，比如它会说：“嘿，我在你设备上发现了一个 AWS key，也许我可以试试它。”所以最初的一批用例基本就是这样：先把它跑起来，先给它加一些基础工具和任务，然后开始让它做不可能完成的事情，看看它会往哪里走。你很快就会发现，这类东西是怎么一步步失控的。它们很有意思，但也非常复杂。
Joel de la Garza：OpenClaw 在安全这一面，真的让我觉得疯狂。我把它接上 Gmail，前前后后花了大概7个小时。到现在还是离谱地难。你得折腾账号配置、授权模型、轮询机制，还得做一堆调试。
Guido Appenzeller：与此同时，Telegram 却是开箱即用的。
Joel de la Garza：对，但那个过程里最有意思的是：当我问它“我们该怎么把这个配起来”时，它就开始自己写代码、开始自己实现。一开始没弄对，第二次才弄成。后来某个时刻它说：“好，现在我需要一个 authentication token。”然后它给了我一套配置说明，基本上是在说：去创建一个 service account，然后给我一个带 domain-wide scope 的 token。你当时就会愣一下：等等，domain-wide scope？这到底是什么意思？因为它建议我给它的 token，不是只针对它自己的邮箱账号。通常运行 OpenClaw 的正确方式，是尽量把它跟你其他东西隔离开来：给它单独的邮箱账号、单独的 Apple 账号，如果你真要给它信用卡或借记卡，那也应该是单独的一张。
我们其实也看到一些创业公司把它放到一台完全独立的机器上，这事挺好笑的——就是独立硬件，对吧？
Guido Appenzeller：没错。
Joel de la Garza：但它真正建议我做的，是给它一个 token，让它能访问公司里每一个邮箱账号的全部内容。这权限简直疯狂。
Guido Appenzeller：而且它还真能跑通，对吧？
Joel de la Garza：对，问题就在这里：只要你顺着它的建议走，它就会拿到所有权限。
Guido Appenzeller：因为它就是不想再来烦你。
Joel de la Garza：对。所以真正理解这件事、再去仔细研究，才会发现 Google 在邮件上的安全模型真的很糟糕。对于 service account，目前你能给的基本就是 domain-wide access，而你显然不想这么做。你真正想要的是面向具体软件、具体场景的更细粒度授权，但一走到那一步事情就会变得很复杂。可正是经历这一切之后，你才会更强烈地意识到：这东西太强大了。它可以自我扩展，也可能被社会工程利用。我觉得这是一个全新的问题——我们以前从没遇到过一种复杂软件系统，你可以通过社会工程、提示注入之类的方式把它往错误方向带。即便只是一个稍微有点经验的用户，也非常容易把它配置成一个足以造成巨大破坏的系统。
Yoko Li：我想抛给大家一个问题：我们其实已经看这个模式看了很久了——把一个长期运行的 agent 放进沙箱里。我想大概从六个月到一年以前就已经有人这么干了。那为什么偏偏是 OpenClaw 爆了？它到底特别在哪？
Guido Appenzeller：我觉得它相对来说算容易上手、容易跑起来，而且文档和支持也足够好，所以我不用花7个小时就能做一个 Telegram 用例并开始玩起来。然后自然就会延伸到别的用例。直到最后我被卡住，因为我没有7个小时去搞清楚怎么把账号权限正确地配出来。我觉得关键就在于：它给了那些不是天天泡在代码里的人一个可达的入口。你们大概每天写代码的时间比我多得多，而我大概是世界上最差的 coder 之一，但这东西对我来说还是可接近的。我有基本技术理解，懂一些核心原理，我电脑上也装了 Homebrew，所以勉强能把东西跑起来。但其他 agent framework 通常都很难用，也特别 flaky，我真的不想花大量时间去 debug 别人的东西。所以我觉得这是一大原因。
Joel de la Garza：还有一个非常重要的点是，它能够自我扩展。我觉得这是我见过第一个可以让我直接说“我想要某个集成”的 agent。以前我从没见过这个东西，也没有现成 package 可用，但它会说：让我试试看能不能拼一个出来。它会启动一个 coding assistant，甚至启动两次，来扩展自己。我觉得这点很新。
Yoko Li：长期运行这一点确实也很关键。你把它放在那里跑一整晚，对它说“在完成之前一直干下去”。Cursor 理论上也能这样，但我觉得区别在于，OpenClaw 给终端用户提供了可见性。你可以在手机上、或者在 dashboard 里随时去看它的状态。前提是你能把这些信息安全地暴露出来，比如它生成了多少 token、任务完成速度如何。所以这种可见性很有意思。另一个有意思的点，是它有更多面向消费者的集成。作为开发者，我自己当然能搭一个出来，但我不会去做所有那些长尾集成。我不会去连 Gmail，也不想去碰 1Password CLI，更不想为了给它接 MCP 去折腾那些东西。所以 MCP 层在这里也非常关键。
大家实际怎么用它也很有意思。比如 Guido 你之前说过一个用例，你在尝试把它接到你的 3D 打印机上？
Joel de la Garza：现在其实还没跑通，但我觉得这个周末应该能搞定。我们想弄清楚它现在到底能接到哪些边界上，因为它可以自我扩展，这是个很新的性质。你可以把更复杂的系统接给它。如果互联网上某个地方有文档，或者某个系统有 API，它大概率就能自己摸索出点东西来。问题只是在于：哪些集成是真有用的，哪些没用。
Yoko Li：那这其实引出了另一个好问题：你们日常到底在 OpenClaw 上用哪些集成？
Joel de la Garza：说实话，我现在还处在实验阶段。
Guido Appenzeller：我并不是每天都在用它。我不会让它无人看管，也不会让它整夜跑着。我是坐在旁边盯着它的。
Yoko Li：我倒是探索了几个用例，因为我真的很想把它放到 Mac mini 上自由运行，然后长时间不去盯它。
第一个集成其实是这样的：我们有一家 portfolio company 叫 Quiver，他们做 SVG 生成。我当时很好奇：如果我把 API 直接交给 OpenClaw，让它跑一整晚，帮我生成一批游戏资产，而且要限定成某种风格，会怎样？然后再让 LLM 去帮我做 QA。所以我做的事情是：我把 Quiver 的 API 交给 OpenClaw，没跟它解释原理，只说你先给我搭一个东西，先把 Quiver 的 MCP 搭出来，再在 OpenCode 和 Cursor 里测试，确保这个 MCP 实例是能跑通的。等它能跑通以后，再给我生成100个游戏资产。
我自己业余在做一个游戏，SVG 恰好是很适合组合复用的一层。它真的干完了，第二天早上发给我一个很大的 zip 包。我打开一看，有些资产不怎么样，但大概有60%其实是非常可用的。真的很酷。然后我就想，这种任务虽然简单，但我完全不想亲手去做。可一旦你有一个能长期运行、能中断恢复的系统，它在盒子里就很适合干这种事。
Joel de la Garza：我自己现在其实还是用得不多，说实话，它还不是我日常工作流的一部分。但有几个场景我挺喜欢的。
比如，你收到一封邮件，想去查跟这封邮件相关的内容，那它就很好用。举个例子，有人给我发邮件说：“Guido，我们能不能在 XYZ 见面？”那我就可以直接把邮件转给它，说：你帮我查一下，在对方提议的那个时间点，开车过去大概要多久。然后它就会给我结果。或者甚至更简单一点，比如有人约在某家咖啡馆见面，你可以直接让 OpenClaw 去查“这地方在哪”，或者“给我附一个地图链接”。所以对我来说，一旦我们把安全性再往上提一点，邮件会是第一个 killer use case。你可以直接说：帮我看看我的邮箱，把所有垃圾邮件删掉；把我下周 conference 相关的所有会议都放进日历里，或者核对它们是不是都已经在日历里；再帮我看看有没有冲突，或者直接告诉我冲突在哪里。能把这些事情自动过一遍，力量非常大。
Yoko Li：我昨天其实就收到了 Guido 的 OpenClaw 发来的邮件。
Joel de la Garza：是的。
Yoko Li：最搞笑的是，它问我：“你要不要点奶茶？如果你想点 boba tea，就 ping Guido，他会帮你下单。”
Guido Appenzeller：我们还在努力让 automation 别再制造更多工作——这刚好是 automation 最不该干的事。
Joel de la Garza：但自动化这部分依然很难。
Yoko Li：对，真的太难了。对了，在录这期播客前，我们还想现场试试看能不能点 Philz 并且让它实时送来。结果发现 Uber Eats 和 DoorDash 如果你事先没有给 OpenClaw 准备好账号，就会遇到 bot detection。即便你给它 guest checkout link，下单体验有时也会失败。所以这就引出了我想问大家的下一个问题：你们觉得，OpenClaw 下一波 adoption 的真正解锁点会是什么？它还缺什么？
Joel de la Garza：一个能双击安装、直接跑起来的版本。
Guido Appenzeller：对。我觉得，对那种普通家庭用户来说，首先得让它能真正“装上就能用”。
Joel de la Garza：但那样的话，它还会保留这种自我扩展性吗？
Guido Appenzeller：会吧。我的意思主要是，先让大家能跑起来。现在这条安装路径，我知道已经有人在做优化了，但我觉得还需要一个真正封装得很 slick 的软件包，最好是那种我爸都能下载并装起来的级别。
Joel de la Garza：那你是不是干脆就该把它做成一个服务？
Guido Appenzeller：也许是。
Joel de la Garza：也就是把它做成 Claw as a Service。
Guido Appenzeller：可能吧。而那样也确实会解决很多安全问题，因为你可以把它隔离在服务端。
Joel de la Garza：我觉得如果要面向大众，确实得把它做成 SaaS 服务，但那就必须彻底改安全模型。而我现在其实也不太确定该怎么改。
Yoko Li：这才是最难的问题。
我的意思是，账号管理范式本身就不对。我们俩都花了好几个小时，只是为了给 OpenClaw 配各种账号。可这些账号设计出来的时候，默认使用者是“人”，并没有“agent”这个概念。
Joel de la Garza：对，就是这个问题。
Yoko Li：那未来这会长成什么样？Joel，你在 Okta 这类世界里算是专家了，你们当年把很多东西带进 SaaS 世界的时候，也经历过类似问题吧。
Guido Appenzeller：我觉得是的。安全总是落后一步的，它永远是反应式的，而不是先于问题而存在。OpenClaw 本身就是最好的例子。安全从来都不是一开始就被认真考虑进去的。所以你不得不开始认真思考：在这个世界里，identity 到底意味着什么？按你的说法，它其实变成了一整个相互配合的 identity 星座。你有操控 OpenClaw 的那个用户的身份；你有它所能访问的所有服务的身份；然后你还有它自己启动出来的那些 agent 的身份。我觉得最终我们会进入这样一个世界，而这也是我对很多安全问题最终能被解决感到乐观的原因。
Guido Appenzeller：想想看，我们光是让普通用户去用两步验证都已经有多难了。我之前在 Yubico 做过这类事情。真的是，你跟别人说：“这东西可以防癌”，他们都还会说：“癌症也没那么糟吧。”人类对这种麻烦事的容忍度真的极低。
Joel de la Garza：但 phishing 攻击会被降到0，而且还能自动化部署。
Guido Appenzeller：对，问题就在这儿：人类对麻烦的忍耐阈值非常低，但这些 agent 根本不在乎。所以这反而是一个机会：我们终于可以把那些会让人类烦到拒绝使用的机制引入进来，而人类过去一直不用它们，并不是因为原则不对，而只是因为他们懒得受苦。agent 不会抱怨。所以你就可以开始考虑，某些以前觉得太麻烦的东西，也许终于有了实际应用场景。比如我现在说 PKI 可能会被请出房间，但也许 PKI 终于找到了一个适用场景。
Joel de la Garza：这就是被精心打磨过的隐藏式 PKI。
Guido Appenzeller：对，让 agent 去处理这些东西，而不是暴露给人。像这样很多原本不现实的东西，现在都突然变得有意义了。你也许终于能让人们真正开始使用 vaulting；你也可以彻底摆脱那些必须可记忆的密码；你可以走到这样一个状态：身份可以按需升降授权范围。最终你会进入一个世界，在那里我们过去一直从第一性原理强调“你必须这么做”的那些安全实践，之所以一直推不动，只是被人类的懒惰卡住了。而 agent 让这种阻力消失了。所以我觉得，也许我们真的能把很多事修好。
Joel de la Garza：身份认证和 identity 问题当然很大，但我觉得还有另外两个问题：一个是授权边界和监控，另一个是一些现有网站的商业模式。先说授权。真正我想要的，并不是给这个 agent 访问我所有邮件的权限，因为 blast radius 太大了。如果这东西被攻破，那我做过的一切几乎都会暴露。所以我真正想要的是更细粒度的权限。比如说，它只允许访问我的 inbox，这其实就已经很有用了。
Guido Appenzeller：或者只能访问我 inbox 里、带某个 label 的邮件。
Joel de la Garza：对，完全没错。但现在 Google 几乎没有这种细粒度访问控制。真的基本没有。甚至直到去年，在 Drive 里你连 folder 级的细粒度权限控制都不太行。以前你拿到的 token 基本上就是整个 Drive 的访问权限，这在某种程度上简直荒唐。现在虽然有了一些 service account，可以拿来共享目录，但对 agent 来说，你可能需要比这更细很多的粒度，尤其是在邮件场景里。然后再往前一步，比如在 Amazon 上，我希望能设定消费上限、规定它可以买什么不能买什么。这里面的需求空间非常大。
Guido Appenzeller：而安全一向是这么演化的：第一步通常总是先出现某种 proxy，所以几乎可以确定，未来会先出现一层代理或 broker，专门替 agent 去拿这些访问权限。再往后，服务提供商自己也许会补上一部分能力。但这中间会有很长的尾巴，所以很可能会出现一套专门给 agent 提供代理访问的基础设施。
Joel de la Garza：我有两个观察。第一，我觉得这里对创业公司来说是巨大机会。如果今天有人给我一个安全版 Gmail——哪怕只是某种 agent 友好的 Gmail 代理——我都会立刻采用。第二，我觉得这其实已经涉及到商业模式问题了。因为今天很多网站的大部分收入、尤其是大部分利润，都来自 cross-sell。如果未来这些网站主要只是被 agent 使用，那这套逻辑就不成立了。它们等于是在走向自己的商业模式终结。比如今天 Amazon 至少在消费者侧没有真正的 agent API，DoorDash 也没有。很多大型消费网站其实都在说：不，我们不希望 agent 进来。它们想要的是“你要不要顺手再买点别的”“给你推荐这个那个”这种体验，而不是 agent 直接替用户完成交易。所以我觉得一个很有意思的问题是：这些 incumbent 最终会不会追上来，给 agent 提供功能？还是说我们真的需要一批专门面向 agent 重新设计的新公司？
你可能会说，Guido 这也太疯狂了吧。为什么 Amazon 不会顺理成章地成为最大的 agent vendor 呢？但你看看 agent search 这个方向，你原本会觉得：Google 本来就是最大的搜索引擎，那在 agent 时代它当然也会继续是最大搜索引擎。可今天显然不是这样。我甚至不觉得他们现在还有一个明确的 agent search 项目。反而是 Exa、Brave 以及其他一些公司在做这些事。所以问题就来了：我们是不是得把 SaaS、电子商务、在线服务里的很多基础模块都为 agent 重做一遍？
Yoko Li：那你们觉得，哪些领域最需要那种“昨天就该做出来”的、专门为 agent 设计的服务？
Joel de la Garza：没错。或者换个说法，为什么 Google 现在没有一个明确的 agent search？也许这就是创新者窘境，我不知道。
Guido Appenzeller：但这确实挺有意思的。
Joel de la Garza：听起来真的很像创新者窘境。因为你的商业模式已经深度绑定在服务的某种使用方式上了，所以你没法跳到一种全新的交互模式。
Guido Appenzeller：还有一种可能，是之前大家被“browser use”这个方向带偏了。很多人以为这些东西只要能用浏览器，就能像人类一样浏览整个互联网。
Yoko Li：今天它们在某种程度上确实能做到。但整个网站环境对 bot 其实是充满敌意的。最近我还碰到一些 vendor，干脆把 bot detection 关了。
Joel de la Garza：这其实很合理。
Yoko Li：对，这当然合理。但与此同时，也等于把大门给滥用者打开了。
Joel de la Garza：你应该更关注 enablement。
Yoko Li：你想想看，现在我去 DoorDash，有时候它甚至会直接问我：“你是 bot 吗？”作为一个真人，你还得做一堆极其复杂的谜题。我之前帮 OpenClaw 在 GitHub 上注册一个全新账号，就遇到过这种情况——我被要求连续解6道题。真的很难。
Guido Appenzeller：对，还有那种拖拽式的题。
Yoko Li：对，拖来拖去那种。现在的问题就更进一步了：如果我今天打开 OpenClaw，对它说“去给我弄5个账号，不需要人工介入，这是我能给你的唯一一组凭证”，那整个系统该长成什么样？如果我根本不想再花几个小时，去把它接进所有这些账号，那又该怎么办？
Guido Appenzeller：我觉得，对很多公司来说，正如 Guido 说的那样，商业模式会逼着它们重新思考整套架构。安全本来就是纵深防御。前端的 CAPTCHA 和 bot detection 只是矛尖的最外层。之后它们必须像防御工事里“退回内墙”那样，把真正的控制点往后端迁移。你得构建一种更复杂的业务理解，才能在系统内部发现 abuse、exploitation、fraud 这些真正的问题。因为你其实会希望 bot 能注册、能登录、能使用 agent。真正要保护的，是系统内部那些可能被滥用的高风险环节，而不是一味地挡住所有 bot。
Joel de la Garza：对。与其做 bot detection，我更希望网站直接挂一个“bot 欢迎横幅”。如果你是 bot，请点这里。
Guido Appenzeller：然后这边就是 API。
对，就写着：这里是 API，请你作为 bot 注册。甚至注册时你还可以说明“你的主人是谁”之类的信息。
Guido Appenzeller：没错，100% 应该做注册。
Joel de la Garza：再把它的公钥之类的东西也登记上去。
Yoko Li：其实已经有一个只读场景是这么做的，而且做得很好。比如某些网站如果检测到访问者是 coding agent，它不会让 agent 去渲染整个网页、看按钮和边框，而是直接提供一段 line-delimited text，因为对 agent 来说，网页结构太慢了，它真正想要的是一段紧凑的文本块，好回传给模型。那只是只读场景而已。所以我很好奇，未来 agent 在 Web 上的“可写”场景会长成什么样。它不一定只是 API，或者说它也许是 API，但 agent 不止需要 account identity 和 API 本身，也许需要的是某种介于 CLI 和 API 之间的东西。
Joel de la Garza：为什么不直接就是 API 呢？
Yoko Li：它可以是 API，只是你首先得发 token。可发 token 之前，你得有账号；要有账号，你又需要人类先介入。我不想把人圈进这个 loop 里。
Joel de la Garza：我的意思是，假设我给它一个邮箱地址、Telegram 账号之类的，某种形式的账号总归还是有的。那网站可以说：你好，bot，你需要用某种账号注册；但注册以后，你就要被绑定到某个 identity 上。
Yoko Li：而不是像 GitHub 现在这样问你：“你是不是 bot？来解这些题吧。”
Joel de la Garza：对，我的意思就是，网站首页直接写“bots welcome, click here”。或者这里是 bot API，这里是 register bot 的函数；等你拿到 token 以后，这边就是所有给 bot 用的功能。
Yoko Li：那确实说得通。某种 bot UI，的确有意义。再往后看，OpenClaw 已经把自动化 UI 演化了一些。以前我记得用 RPA 工具的时候，一堆都是拖拽，你把这个框连到那个框。现在完全变成了描述结果：你告诉 bot 你想要什么，然后让它一直转、一直试，直到把事情做对，最大化地利用 test-time compute。我根本不在乎它到底吐了多少 token。所以我真正好奇的是，未来这一层 UI 到底会长成什么样？
我们未来到底会怎么和这些 RPA 工具交互？它最后会不会就是个人助手这个形态？还是会变成别的东西？
Guido Appenzeller：这恰恰是最让人兴奋的地方。一般来说你不该向 CISO 寻求产品建议——我们大概是最差的产品思考者——但光是想到我们即将经历一次对这类产品体验的彻底重构，就已经非常激动人心了。你会看到一种思维方式的转变：从过去那种 RPA 的拖拉拽拽，从 pseudo-code，从各种流程图式的东西，转向今天这种“我用自然语言表达目标，机器替我完成”的模式。这会彻底改写用户体验，甚至让传统意义上的用户界面慢慢消失。所以，是的，我也不知道最终会怎样，但我可能也是最不适合回答这个问题的人。
Yoko Li：消失？
Guido Appenzeller：我确实觉得会这样。
Joel de la Garza：我觉得任务层级肯定会更高，你会在更高抽象层上定义任务。但我还是希望自己能被留在 loop 里，知道任务是怎么执行的。因为通常当我描述一个任务时，精度永远不够高，不可能把所有 trade-off、所有设计选择都提前说清楚。所以一旦这些选择出现，要么系统应该来问我：“Guido，这里我该怎么做？”要么至少告诉我：“Guido，我决定这么做了。”所以你大概率还是会需要某种 UI。它会很不一样，这点我同意，但不会彻底没有。
Guido Appenzeller：我觉得你可能站在用户分布最右边那一端。你更像那种“我要一步步参与架构决策”的用户。但很多用户可能只是完全 vibe coding 一下，说“给我一个 app，帮我规划婚礼”，然后就让它直接干。这里面有很长的一条光谱。我觉得大多数人会落在中间位置。大概只有当事情特别重要，或者某些东西失败了，你才会想被 ping。至于过程中的进度本身，我不确定大家是不是都想看。就像我说的，我可能并不是问产品问题的最佳人选。
Joel de la Garza：好吧，进度本身我确实不想看，直接给我答案就行。但如果中间有真正有意义的选择分岔，那我还是想知道。
Guido Appenzeller：是啊，不过在那种情况下，系统大概也会给你更合理的中间反馈。
Joel de la Garza：你想想，“帮我规划婚礼”这种 app，本身也会涉及旅行、预算之类的复杂因素。
Guido Appenzeller：所以你最后大概还是会有一些交互流程。
Joel de la Garza：对，那就是 UI。也许是 flow chart，也许是某种概念图。总之我觉得还是会有那一层。也许全都变成带图片的文本，我不知道。
Yoko Li：我觉得 OpenClaw 已经稍微演化了一点 UI。比如在它的 app 里，你会发现它把“jobs”这层抽象掉了一些。作为开发者，我以前总得自己去写 cron job schedule，而且老得查语法。
Joel de la Garza：cron job。
Yoko Li：对，就是 schedule 还是按那套方式定义，但你现在已经不怎么关心它了。比如我之前追问 OpenClaw：“为什么你5分钟前没有提醒我那件事？”它就会说：“我来看看。好的，这是我的 cron job。它的工作方式是：它会先唤醒我，我醒来以后检查有没有要处理的东西，然后我再来 ping 你。”所以现在整个系统是这样运作的：我不再需要在系统层面去关心 schedule 到底什么时候醒来；更像是有一个 LLM 在帮我统一照看和编排这些系统。
Joel de la Garza：我觉得这点很有意思。在某种程度上，OpenClaw 做的，是把过去软件开发里的软件自治能力，往系统层推进了一点。它不再只关心代码本身，也开始处理围绕代码的一整圈东西：集成、cron job、操作系统、端口这些。
Yoko Li：你仔细想想，email 是人类的 queue infra，而 cron job 是 agent 的 queue infra。现在你可以把这些都抽象掉，把所有 queue 都交给 agent，让它自己去处理。当然，有时它还是需要醒过来，然后调用一个非常昂贵的 function——也就是请求一个人类去做事。比如请 Guido 去帮忙下个单。
Joel de la Garza：未来它们会有 token budget，也会有人类交互预算。
Guido Appenzeller：我们人类也得想办法搞明白，自己的 token threshold 到底是什么。
Yoko Li：说回 OpenClaw，你们最期待、但现在还不存在的扩展是什么？或者说，你最想看到哪些系统层改进？
Joel de la Garza：我排第一的还是那些消费网站。现在要接它们真的太难了。
Yoko Li：面向消费者的网站。
Joel de la Garza：对，像 DoorDash、旅行预订这类网站，我们现在太需要更好的、面向 AI 的接口了。换句话说，不是给人用的 user interface，而是给 Claw 和 agent 用的等价层。现在你基本只能通过 browser use 的方式硬接，而 browser use 通常特别脆弱，根本不好用。
Guido Appenzeller：作为安全 nerd，我最期待的是安全工具。它和 password manager 的集成已经挺酷了，而且实际运行效果也出奇地好。很有意思，因为 password manager 这种东西，虽然不一定是最理想的安全最佳实践，但绝对比大多数人现在的做法好，所以整体上是净改进。
也许你现在还做不到“饮食加运动”那种完美方案，但如果先把“饮食”搞对，至少也会有帮助。所以当这些 agent 开始接入安全工具之后，你实际上就拥有了一类可以在你身后盯着、提醒你别犯蠢的助手。这些 frontier model 在识别 phishing 和 fraud 上已经非常强了。也许将来它们在帮你处理邮箱的时候，就能替你筛掉、标记掉很多传统规则系统抓不准的东西。再比如你写代码、用服务、搭基础设施时，它们也许能帮你避免 overprovision，或者避免权限开错。比如我作为家庭用户不可能跑 Wiz，但也许我确实需要某个东西来提醒我：别把 S3 bucket 权限设错。所以这类能力会非常强大。当然，我自己本身也是站在用户分布另一端的人。
Yoko Li：那会不会最终出现一个专门给 agent 用的 vault？我以前在 Vault 这类体系里工作过，那种东西太有用了，尤其擅长生成和界定权限。现在问题变成，workload 已经不一样了。对于 OpenClaw 这样的世界，是否会出现 agent-specific vault？它会长得不一样吗？
Joel de la Garza：我基本上是直接用 1Password。1Password 有很多缺陷，我对它的安全模型其实并不满意，也未必会推荐。但你确实可以在里面单独建一个 vault，生成一个 token，交给 agent，然后 agent 就只能访问那个特定 vault 里的内容。
Yoko Li：然后再去轮换 token，这正是 Vault 很擅长做的。
Joel de la Garza：理论上可以，是的。但如果你说的是用来访问 vault 本身的那个 token，轮换它到底能带来多少收益，我其实不确定。
Guido Appenzeller：至少在 breach 的场景下，这肯定会有帮助。
Joel de la Garza：是，但你可以监控访问 vault 的来源。所以也许吧。可我觉得更重要的是 vault 里面那些 token——我真正想定期轮换的是它们，因为那些你往往根本监控不到。问题在于，这些 token 经常对应的是消费网站，而消费网站几乎没有任何真正的 token rotation 能力，除了让你回到一个糟糕的 UI 里手工操作。
Yoko Li：从某种意义上说，浏览器里的 cookie 也是一种 token rotation，因为它会隔一段时间刷新一次。现在很多 agent 的做法，就是拿 cookie token 来用，然后不时把它刷新一下，继续维持读取能力。
Guido Appenzeller：说起来，我的 agent 干的第一件很 hacky、也有点 sketchy 的事，就是开始到处找 cookie。我当时直接愣住了。
Yoko Li：我根本没让你这么干。我只是想让它在 DoorDash 上给我点 Philz。结果因为过不了 bot detection，它就开始说：“那你不能把用户名和密码给我吗？我不推荐，但肯定能成。”
Joel de la Garza：所以为什么不给它一个单独的账号？
Yoko Li：可以给，我只是还得先创建那个账号。
Joel de la Garza：而对我来说，这点非常关键：未来 agent 应该拥有完全独立的身份，不应该和你的主账号共享。你应该保持一个独立 trust domain。当然账号之间可以做关联，但给它的应该是虚拟 API keys、虚拟信用卡。也就是说，最终所有东西中间都应该有一层抽象和保护，可以在背后盯着它。
Yoko Li：我对 OpenClaw 的愿望清单其实更多是多线程模型。现在它基本还是单线程的，这对单个任务很好，也可以开新 session。但当你同时跑5个任务时——而这对个人助手类 agent 来说其实非常常见——它就会出问题。比如我想一边让它在线程A里生成游戏资产，另一边再让它帮我写点代码、用一些 coding tools。结果它就会变得非常慢，或者在任务之间来回切换。所以 session 之间的上下文现在还没有被很好地管理，而且整体很慢。我也不确定这是模型慢，还是 UI 本身就比我单独用其他工具慢很多。
Joel de la Garza：是的，它确实会经常卡住。而且我第一次装的时候，默认 memory 就是坏的。第一次我让它去用 iMessage，它也莫名其妙没有调用自带的 blue bubbles 集成，反而试图从零开始自己写一套。我当时一边觉得离谱，一边又有点喜欢它这股劲。然后我就问它：“你为什么要这么做？”它又像突然想起来一样说：“啊对，我们其实也可以直接用标准集成，那会更快。”然后才停下手工重造轮子的过程。
Yoko Li：所以我就在想，agent 在“build 还是 buy”这件事上的选择，会不会跟模型本身的偏好分布有关？比如，如果你 prompt Codex，它是不是也会倾向于什么都自己造？还是说 OpenClaw 之所以总想自己造东西，只是因为某种 system engineering 的默认设置？
Joel de la Garza：这个问题挺公平的。
Yoko Li：我们应该做个 benchmark。
Guido Appenzeller：我猜它大概会像典型企业一样，很多时候决定都很随意。你问“为什么要自己造？”答案可能只是：“因为我们就这么做了。”
Joel de la Garza：靠掷硬币。
Yoko Li：对，掷硬币。那接下来你们打算围绕 OpenClaw 继续做哪些实验？
Guido Appenzeller：我觉得，对很多 IT 组织和很多公司来说，真正的大问题是：你到底该怎么运行这些东西？
Guido Appenzeller：一开始我还以为，放进容器里跑不就好了，起个 container，装进去，然后执行。后来发现，这些东西会写代码，而且很聪明，它们很可能能逃出 container。于是又开始想，也许该放进 VM。结果想了一圈之后，你会觉得，既然都已经做到这一步了，不如干脆买台 Mac mini。所以现在一种默认的想法就是：那就让它们跑在 Mac mini 上吧。只是现在想买到 Mac mini 都不容易。但总之，它已经变成一种需要专用硬件的东西了。所以我脑子里真正的问题是：你最终执行这类东西的那一整套 stack 会是什么样？你怎么把它安全地带到员工桌面上，而不把整家公司置于风险之中？这些都是非常难的、尚未解决的问题。
Joel de la Garza：我仍然不确定它离成为我日常主线工作的一部分还有多远。现在它还更像边缘工具。我偶尔能捡起几个任务来做，比如替 Jason Horowitz 处理点事，但要到什么程度我才会说“好，给它访问我们 preterm due diligence folder 吧”？这对我来说是个非常大的跨越，我觉得我们离那一步还很远。即便是更温和一点的场景，比如我转发一封邮件给它，说你帮我做点分析，看看里面的数据之类的，也还没到那种完全放心的程度。
Guido Appenzeller：甚至就算是一些很简单的用例，比如给团队会议点个奶茶，我觉得在企业 IT 环境里想把它安全地跑通，除非你给它专用硬件，否则现在也还是很难。
Joel de la Garza：对。
Guido Appenzeller：你想想。
Yoko Li：所以我们办公室里大概真的会摆一堆专门跑 OpenClaw 的 Mac mini。
Guido Appenzeller：我觉得真会变成这样。但问题是，这种方案不 scale。你要是有600人，或者1000人、2000人，总不能真去买1000台 Mac mini。
Joel de la Garza：我觉得从技术上说我们还是可以用 VM，把它托管起来。比如一打员工对应一打专属 VM，这样 blast radius 也许还是可控的。但问题依然在：如果它下载了某个它在某个 OpenClaw 论坛或者 bulletin board 上找到的最新集成，而那个东西被投毒了呢？
所以你还是得想办法限制 blast radius。我自己想过一种方式：能不能让它只能访问某些指定文档、某些指定邮件，而且这个授权是显式给出的。比如我可以说“你今天只可以访问我的 inbox”，然后到了每天午夜，这个权限自动重置。这样心理上会舒服很多，至少即使出问题，也只是暴露一天的内容。
Guido Appenzeller：这其实和我们在 Kubernetes、container infrastructure 里干的事很像。对，就是重启它。
Joel de la Garza：没错。偶尔重置状态，会让事情变得更容易接受一点。再加上所有东西都用独立账号，我真的觉得不应该让它用我的主账号去干任何事。它应该始终是一个独立身份。
Guido Appenzeller：而且它大概率也不该在你的本地机器上直接运行。
Joel de la Garza：对。
Yoko Li：就今天这个阶段来说，我觉得它特别适合那种“cron job 醒来，看一眼，做个判断，然后不保留记忆”的任务。比如每小时醒来一次，看一下我的日历；如果今晚我没法回家吃饭，就告诉我丈夫。对这种用例，我其实还挺放心的。你仔细看一下个人电脑上 app 的使用分布，其实高频的无非就是那么几个：Slack，我们一直在上面沟通；email，大量时间都耗在邮件里；然后是 coding tools；再就是日历。如果它能把邮件和日历里的一部分任务流顺下来，那对个人助手来说已经是巨大价值了。剩下那些长尾工具，比如我可能会把东西写在 Notion 里，但对 agent 来说，本质上就是 markdown，然后持久化下来，具体长成什么样其实不那么重要。真正让我好奇的是，未来 agent 的 note-taking 会是什么形态。今天我们默认用 markdown，但 markdown 显然太受限了。也许未来会有一种 Markdown++，agent 可以把它沿途记下的，不只是文字，还有可执行的内容、代码块、图表之类的东西都放进去。
Joel de la Garza：你其实可以在 markdown 里画图，比如 Mermaid 之类的。
Yoko Li：我是说那种真的能运行的图表，不只是静态图。
Joel de la Garza：哦，明白。
Yoko Li：对，就是那种可运行、可执行的东西，而且它还能成为你做笔记时的一部分 source of truth。因为那不只是文字，还包括你一路生成出来的程序。
Joel de la Garza：现在似乎确实有一个趋势，就是把图和结构都表达成代码。把这些放在一起看，我觉得最迷人的地方在于：这是少数几个时刻之一，我们面对一项技术，它的能力边界不是由“它做不到”决定的，而是由“我怎么让它安全、怎么限制它不要乱来”决定的。我们手里有一个超级厉害的瓶中精灵，真正的问题是怎么约束它。以前发生过这种情况吗？
Guido Appenzeller：我觉得安全一向都在最后才出现。只是现在，我们已经把“写代码”这一面大致解决了，所以剩下的问题更多变成 systems engineering 问题。它们本质上都是系统架构和工程问题，不一定纯粹是安全问题。社会工程在某种程度上确实算安全问题，但更大的问题是：你把不同 trust domain 的风险混在了一起。你同时有基础模型本身的 trust and safety、alignment 问题；有 OpenClaw 在本地机器上的系统架构和执行方式问题；还有传统意义上的黑客问题，比如 prompt injection，以及人们试图拿它去做坏事。
Joel de la Garza：而且我们周围这些服务本身也存在权限粒度不够的问题。即使一切都完美，你也未必希望某些信息在不同上下文之间发生泄漏。
Guido Appenzeller：你等于是在一个原本为人类构建的世界里，继承了所有遗留下来的尖锐边角。
Joel de la Garza：对人类来说某种程度上还说得过去。
Guido Appenzeller：因为人类搞砸了你还可以把他开掉。agent 搞砸了可不一样。
Yoko Li：如果我用最 VC 的方式，把这件事放进一个2×2坐标：一边是低安全风险、高安全风险；另一边是低价值任务、高价值任务。那你们觉得，什么属于低安全风险、但高价值的任务？
Guido Appenzeller：告诉你丈夫你今晚会晚回家。
Yoko Li：确实。
Joel de la Garza：再把猫也放进去。
Yoko Li：对，也算。
Guido Appenzeller：问题始终在于，这些东西的风险通常来自权限升级，以及它们逃离原有环境。一旦跨出去，它就可能跳到真正高风险的领域。
Joel de la Garza：我觉得还有一类任务也属于这个象限：你其实可以把 OpenClaw 当作一个非常聪明的 LLM UI。也就是说，不要 memory，不要长期 state，给它一个任务，任务一完成，立刻清掉所有状态。这样会安全得多。
比如现在假设我在邮件里收到一个 PDF，想让 LLM 看一眼。今天这个流程还是很笨重：我得先把 PDF 下载下来，再把它上传到某个 LLM 里分析，然后再导出结果。要是我可以直接说：“嘿，Claw，看看这个文件，给我做个分析。”然后它回给我一封带分析结果的邮件，做完之后再把所有状态全部丢弃。我觉得这种形态很快就能实现。
Yoko Li：我其实很期待把 OpenClaw 用在报税上。
Guido Appenzeller：还有公司薪酬对标之类的事。
Joel de la Garza：希望 IRS 暂时别听到这段。
Yoko Li：IRS 也许也会有自己的 OpenClaw，谁知道呢。那如果换到公司场景，有什么属于高安全风险、但又极高价值、你恨不得昨天就自动化的任务？
Joel de la Garza：税务。
Guido Appenzeller：任何跟财务有关的企业流程都算。accounts payable、vendor review、third-party assessment……这些场景里，我们现在有大量真人在做重复验证：确认 vendor 真实存在，确认打款指令没错，确认 PO 没被人通过社会工程篡改。企业里围绕 vendor management 有太多工作了，而这类解决方案本来可以极大提升效率；但如果它们出错了，你就是在往错误的人账户里打钱。
Joel de la Garza：那要不要再把风险拉满一点，比如再加上 Bitcoin？
Guido Appenzeller：我觉得差不多已经拉满了。
Joel de la Garza：对，差不多是最大风险了。
Yoko Li：那对于那些对 OpenClaw 感兴趣的企业管理者和高管，你们会给什么建议？Joel 的意思我理解大概是——
Guido Appenzeller：我一直非常相信一件事：如果你没有感到不舒服，你就没有在成长。而这正是那种会让你很不舒服的时刻。但你必须迎上去。我也赞同 Guido 以及我们前面所有人的观点：我看不出这类东西会带来别的结果，除了创造更多工作。因为会有更多东西需要建设、需要管理。你如果想站在浪潮里，就得走进去。Cloud 当年来的时候也是一样。我记得那时我还在一家大公司上班，心里想：五年后这里一半的人都会没了，基础设施会变成 commodity，会被服务抽象掉，我们不会再需要那么多技术人员。结果10年、20年过去，IT 组织不但没有变小，反而比以前更大、花的钱更多。所以我觉得，这里面有巨大的机会。你就是得接受不舒服，学会在不舒服中前进，并承担聪明的风险。
Joel de la Garza：我觉得一个很好的类比，其实是 Web 和互联网早期。那时候有些公司直接禁止员工用浏览器，觉得“浏览器不安全”。浏览器确实不安全，但错过整个互联网革命的风险要大得多。你要是一味回避，最后就会变成 Barnes & Noble 那样。
Guido Appenzeller：Citigroup 当年的第一版 cloud security policy 基本就是：“不得使用 cloud services。”你看现在呢？这些技术浪潮其实总是高度相似。
Joel de la Garza：试图无视新技术，等着它自己消失，通常都不会有好结果。
Guido Appenzeller：如果你想提前退休，那倒是个不错的策略。
长按 & 扫码
获取更多报告
免费产品试用
现在微信的推送机制改了，后台很多读者反馈说看不到更新，有时候还需要点到公众号主页才能看到更新的文章，大家可以点击公众号主页右上角“…”设为星标。我们每周二三五日下午四点半会准时发文。有感兴趣的问题也都欢迎直接联系我们或者在文末留言，期待和各位的交流。
【更多内容，点击下方关注】
* * *
关于久谦资本
成立于2009年，服务于关注新兴领域的企业与一线投资机构；我们相信科学与技术能够改变专业服务；希望带给市场多一分理性、少一分似是而非；我们认为与众不同的研究与分析，是我们荣誉的唯一来源。