公开视频里,OpenClaw 的部分穿插在早场 keynote 中。主持人把 Peter Steinberger 称为 “the claw father”。这段信息量被压在大会流程里,但它很适合拿来解释软件工厂的另一面:agent 不是孤立工具,它需要运行层。
原视频:https://www.youtube.com/watch?v=htM02KMNZnk
从聊天到运行系统
很多人第一次接触 agent,看到的是一个聊天窗口。你发任务,它回答案,最多再帮你改几个文件。OpenClaw 代表的是另一种方向:把 gateway、nodes、skills、工作区、权限、记忆、事件和外部通道放到一起,让 agent 能活在一个持续运行的系统里。
这和大会的 software factories 主题是同一件事。一个真正的软件工厂,不能把所有工具和所有文件都交给一个大模型,然后祈祷它做对。更合理的方向是把任务拆成边界清楚的工作单元,让 agent 在合适环境里行动,并留下可追踪证据。
OpenClaw 这一类系统关心的是运行结构。谁接收任务,谁路由模型,谁管理长任务,谁持久化状态,谁处理中途 steer,谁把结果发回用户。这些都不是模型权重里的能力,而是 harness 和 orchestration。
为什么单个 agent 不够
当天很多演讲都在讲同一个事实:一个 agent 不可能安全地做所有事。写代码、查资料、跑浏览器、调用内部 API、发消息、更新 ticket、部署服务,这些动作的风险完全不同。
如果把它们都塞给一个 “全能 agent”,系统表面更简单,实际更危险。它的上下文会膨胀,权限会过大,失败后也很难追责。Derek Nee 在本地笔记里有一句判断很贴切:你无法用一个拥有所有工具、所有文件、毫无责任感的巨型 agent 来运营公司。
OpenClaw 的价值就在这里。它把 agent 看作运行在系统里的 worker,而不是一个万能脑袋。worker 可以被编排、被限制、被替换,也可以和外部 coding agent 组合起来。
和 Codex 的位置不同
如果说 Codex 更像开发者工作流入口,OpenClaw 更像运行层。Codex 关心一个开发任务如何在 repo 里完成,OpenClaw 关心多个 agent 如何在持续系统里协作。
这两者不是竞争关系。未来很多团队会同时需要它们:一个负责代码库内的任务执行,一个负责跨通道、跨任务、跨时间的编排和治理。
我会把 OpenClaw 放在 software factory 的 “车间调度” 位置。模型是工人,Codex 是工位,OpenClaw 这样的系统更像调度台。真正难的不是让工人会干活,而是让他们在合适边界里干对活。
OpenClaw 讲的是“谁来调度 agent”
OpenClaw 这场如果只看工具名,很容易错过重点。它讨论的不是另一个聊天界面,而是软件工厂里非常现实的一层:任务进来以后,谁来管理 agent 的执行。
一个成熟的软件工厂不会只有“用户发一句话,模型回一段代码”。它需要接任务、分配环境、选择模型、记录状态、处理中途修改、处理失败、把结果交给人或系统。OpenClaw 的价值在这层调度,而不是单点生成。
这层能力看起来不如模型发布刺激,但它决定系统能不能长期运行。没有调度层,所有 agent 都像临时工:上下文散落、状态丢失、失败难追、权限难控。调度层把这些临时动作变成可管理的流程。
长任务和短任务不是一回事
AI coding demo 常常展示短任务:修一个 bug、写一个函数、加一个页面。真实软件工厂更多是长任务:跨仓库迁移、批量修复、持续跟进 issue、生成并验证 PR、部署后观察反馈。
长任务需要持久状态。agent 不能每次都从零开始,也不能把所有历史塞进上下文窗口。它要知道之前做过什么、为什么这么做、卡在哪里、人给过什么 steer、哪些验证通过。OpenClaw 这种系统如果能把状态管理好,就能把 agent 从“单次回答”推进到“持续工作”。
这类系统的风险也更大
调度层越强,风险也越集中。它掌握任务入口、模型路由、权限、执行日志和结果交付。如果设计不好,问题会比单个 agent 更难排查。
所以我会用两个标准看 OpenClaw 这类软件:第一,它能不能让人清楚知道 agent 在做什么;第二,它能不能在出错时留下足够证据。软件工厂的调度台不是为了制造神秘自动化,而是为了让自动化可观察、可暂停、可恢复。
来源与说明
本文基于 AI Engineer World’s Fair 2026 Day 1 主舞台视频转录、官方日程信息,以及本地 AI engineering 知识库整理。文章不是逐字稿,而是按单场分享的主线、上下文和工程启发重写。






