今天咱们抛开那些"一人抵一军团"的夸张比喻，踏踏实实从技术角度聊聊彼得·斯坦伯格（@steipete，龙虾之父）是怎么用OpenClaw和AI代理把开发效率拉到极致的。他不是魔法师，而是一个极致务实的工程师：从PDF工具老兵转战AI代理领域，用并行代理+自建元工具，实现了传统团队级别的产出——1月6600多次commit，token消耗高达25万美元，却几乎不碰IDE，主要在终端里指挥。
先简单背景：彼得曾创办PSPDFKit，花13年带70人团队做PDF渲染。退休后，2025年11月一个晚上，他因为"缺一个真正能干活儿的AI助理"而花1小时prompt出Clawdbot原型。项目快速迭代为Moltbot，最终开源为OpenClaw，成为GitHub历史上增长最快的项目之一（几个月内星星破20万）。现在他加入OpenAI推动个人代理方向，OpenClaw则由独立基金会维护，继续开源演进。核心不是产品炫技，而是他的agentic engineering工作流——用AI代理做实现，自己专注架构和结果。
核心机制：并行运行4-10个AI编码代理
彼得的工作流起点非常简单：终端驱动的多代理并行执行。
每天早上，他打开终端，不急着写代码，而是像调度任务一样启动4-10个AI代理（基于Claude、Codex或其他模型，通过OpenClaw的Pi架构运行）。每个代理分配独立任务或不同repo，最长跑2小时。代理不是聊天机器人，而是具备工具调用、文件操作、shell执行能力的自治单元。
为什么并行？ 单个代理容易卡在上下文或循环中，多代理可以同时推进不同模块：一个负责新功能实现，一个修复bug，一个生成测试和文档，一个优化性能或重构。OpenClaw的Lane Queue并发模型和heartbeat引擎确保它们不会互相踩踏，还能通过子代理工作流实现链式协作。
执行闭环：代理会自动checkout代码、编辑、编译、运行本地测试、生成diff，最后提PR或直接commit。他很少用GitHub远程CI，而是本地跑测试（受DHH启发），main分支始终保持shippable状态。问题出现？不revert，直接让代理"fix forward"——继续迭代直到结果满意。这避免了回滚浪费的时间。
他几乎不碰传统IDE（如Xcode或VS Code），主要在终端通过walkie-talkie式对话指挥代理："let’s discuss"而不是死板的plan mode。默认用Codex处理大代码库（它在大数据集上错误少，不需要过多手持），Opus偶尔用来脑暴个性部分。提示也不追求完美——他更喜欢对话式澄清，代理会自己问问题或用工具探索。
结果？commit记录像整个工程团队在干活：一天500+次提交很常见。1月份他一个人就干了6600+次，大部分代码他"ship but don’t read"（尤其是纯数据转换、格式shuffle的部分）。只在触及数据库 schema、核心架构或安全敏感处才亲自review。社区PR他会看代码防恶意，但内部代理产出主要靠结果导向。
元工具构建：解决代理痛点的"自举"循环
彼得工作流最亮眼的地方不是代理本身，而是他遇到瓶颈就立刻自建工具，让代理能力持续进化。这不是一次性hack，而是系统性"AI农场"建设。
典型例子：
- Peekaboo：代理无法直观测试macOS UI？建一个屏幕截图+UI元素读取工具。命令如
peekaboo capture抓图，peekaboo see描述界面元素，甚至支持点击自动化。代理现在能"看"屏幕，像人一样操作GUI。 - Poltergeist：构建时间太慢拖累迭代？做一个AI友好的universal build watcher，自动检测Swift、Rust、Node.js、CMake等项目，热重载变更。构建秒级反馈，代理不再干等。
- Oracle：代理陷入循环或输出可疑？扔给另一个模型做独立review。CLI工具打包prompt+相关文件，调用第二AI（API或浏览器模式）给出debug、refactor或设计建议。
- 外部集成CLI：代理需要访问真实世界？直接写命令行工具对接iMessage、WhatsApp、Gmail、Telegram等。代理执行
help就能学会用法，不需要复杂MCP（multi-call protocols），CLI足够。
这些工具都是他边跑代理边迭代出来的。代理卡壳 → 识别局限 → prompt新工具 → 集成进OpenClaw的工具集 → 代理能力升级。整个过程形成正反馈：代理越强，彼得越能放手，产出越快。
OpenClaw底层架构也为此优化：Pi架构（两层内存系统：短期工作记忆+长期知识库）、Lane Queue并发调度、heartbeat保活机制。代理能自我感知自身源码、文档和运行环境，甚至prompt自己修改自身软件（self-modifying）。彼得说：“我只是prompt它存在，然后它就自己改代码了。” 这不是科幻，而是他实际跑通的闭环。
日常流程：从规划到ship的极简循环
一个典型工作日大概这样（基于他的公开分享和Lex Fridman访谈）：
-
早晨规划（高层次架构）：喝咖啡时，在终端列出今日任务队列。定义每个代理的scope、优先级和退出条件。重点在系统设计：模块如何扩展？API该怎么抽象？数据库变更影响几何？他强调"outcome maniac"——不纠结中间代码细节，聚焦可交付结果和可扩展性。
-
启动代理swarm：并行launch 5-10个实例。每个跑独立目录或repo，避免上下文污染。OpenClaw支持插件市场（最近还加了Codex App Server集成），代理能动态加载工具。
-
监控与干预：大部分时间他"放养"。偶尔扫一眼输出、tweak prompt，或让代理互review。需要澄清时用对话模式。终端命令如切换目录他自己敲（更快），复杂任务全交给代理。
-
审查与merge：代理产出PR或直接commit后，他看diff（尤其是架构部分）。本地CI通过就push to main。没有develop分支，目标是main永远可部署。release时额外稳定测试。
-
迭代与记录：晚上复盘token消耗、成功率，调整模型选择或工具。整个过程保持flow状态：不是被细节折磨，而是像玩乐高——搭框架，让代理填肉。
他还提到一些反"最佳实践"的点：
- 不用严格plan mode，直接"let’s discuss"对话。
- 大部分MCP换成CLI，代理自己parse help。
- 信任本地执行多过远程CI。
- YOLO式前进：问题出现就fix，不回滚重来。
这些听起来"粗放"，但在他模块化、强调扩展性的代码库设计下，实际运行稳定。OpenClaw本身就是用这套流开发的：邮件处理、日历同步、家居控制、浏览器自动化、插件系统……几天就上线。
成本与规模：一人 vs 传统团队
token烧25万美元/月，听着吓人，但对比一个资深工程师年薪+招聘+办公室成本，其实高效。10倍速度意味着更快验证idea、更快响应用户。更重要的是，他证明了solo founder + AI swarm的可行性：从退休状态复出，1小时原型就迭代出能管理真实生活的代理系统。
挑战也有：代理有时产出"slop"（低质代码），需要强架构约束；多代理跟踪需自定义workflow；澄清中断flow时仍需人工介入。但通过元工具和经验迭代，这些在逐步缓解。
给开发者的实用启发
想部分复制这套技术流？不用全盘照搬，从小步开始：
- 起步：用OpenClaw或类似框架（如Claude Code）跑单个代理，从简单任务练手。重点建本地工具集。
- 并行试验：试跑2-3个代理，分模块任务。观察并发瓶颈，再加Lane Queue式调度。
- 自建元工具：遇到痛点立刻CLI化。例如，屏幕操作就学Peekaboo，review就做Oracle。
- 心态调整：从"写完美prompt"转向"对话+结果导向"。少读全量代码，多看架构diff和测试通过率。main永远shippable。
- 监控成本：本地跑+聪明模型选择（Codex大库，Opus脑暴），逐步优化token效率。
彼得的工作流本质是把AI当可编程基础设施：不是取代编码，而是放大架构师的生产力。传统开发像手工砌墙，现在是指挥机器人军团，你只管蓝图和质量门。
当然，这套流适合有强系统设计背景的人。新手先从单代理+工具集成练起。OpenClaw完全开源，去GitHub fork他的repo，跑起来试试peekaboo和poltergeist，你会立刻感受到效率跃升。
龙虾之父的技术故事不是终点，而是AI代理时代的开端。它提醒我们：未来开发不是更快敲键盘，而是更好设计代理能自主执行的系统。想深入？推荐看他Lex Fridman访谈，或直接clone OpenClaw，终端里启动你的第一个swarm。
代码在流动，龙虾在挥钳。冲！
延伸阅读：