OpenClaw「套娃自测」现场曝光!两个实例在同一沙箱互测 API,作者全程边跑边追问没停过

作者亲自确认：就是两个 OpenClaw，一个盒子，互相测

5 月 11 日下午，OpenClaw 作者 Peter Steinberger（@steipete）在 X 上发了一条让开发者圈炸锅的帖子：

“challenged codex to e2e test improvements to the OpenClaw chat completion endpoint WITH openclaw. Used /side to ask more question while it works.”

「挑战 Codex 用 OpenClaw 自己来 E2E 测试 OpenClaw 的 chat completion endpoint。测试跑着的时候，我用 /side 继续追问。」

▲ Peter Steinberger 主贴，附带完整测试拓扑图

注意关键词：WITH openclaw。

这里的 WITH 大写加粗，意思非常明确——测试工具和测试对象是同一个东西。

有人追问到底怎么跑的，Peter 直接给了最朴素的回答：

“I just said e2e test with two openclaw in crabbox”

「就是两个 OpenClaw 在 Crabbox 里跑 E2E 测试。」

▲ 作者回复：两个 OpenClaw，同一个 Crabbox，真测

没有花哨的表述。两个独立的 OpenClaw 进程，一个当服务端暴露 API 接口，一个当客户端发测试请求。套娃？对，但这次套的是真实生产级接口。

测试拓扑拆开看：tool calling 全链路，一步都没省

主贴附图里的测试架构信息量极大，值得拆开看。

OpenClaw A（被测方）：

• 跑的是当前 PR 分支代码
• 开启 Gateway，暴露 `/v1/chat/completions`
• 真实模型后端指向 OpenAI（配了 live `OPENAI_API_KEY`）
• 对外表现为一个 OpenAI 兼容的 API endpoint

OpenClaw B（测试方）：

• 在同一个 Crabbox 里独立运行
• 把 A 配置成自定义 provider：`api: “openai-completions”`，`baseUrl: “http://127.0.0.1:<A-port>/v1″`
• 发出的任务需要 tool use，触发完整的工具调用链路

E2E 验证链路：1. B 发 Chat Completions 请求（含 tools）给 A 2. A 把请求转发到真实 OpenAI 3. A 通过 `/v1/chat/completions` 返回 `tool_calls` 4. B 在本地执行工具 5. B 把 `role: “tool”` 的后续消息回送给 A 6. 最终答案包含sentinel（哨兵值），证明工具结果沿完整链路传回

最后这一步是关键。sentinel 的存在说明，作者验证的不只是「能调通」，而是「工具调用的完整往返是否端到端走通」。如果只是文本能返回，谁都能声称兼容；但 tool_calls → 本地执行 → tool result 回传 → sentinel 校验这套流程，恰恰是开发者接入时最容易出兼容性事故的路径。

官方文档已经定义了这个 endpoint——默认关闭

怕你以为这是 Peter 自己临时搭的 demo 接口，补一个官方锚点。

OpenClaw 文档页面（`docs.openclaw.ai/gateway/openai-http-api`）写得明明白白：

OpenClaw’s Gateway can serve a small OpenAI-compatible Chat Completions endpoint.

endpoint 路径就是 `POST /v1/chat/completions`，同端口还可以暴露 `/v1/models`、`/v1/embeddings`、`/v1/responses` 等兼容接口。

▲ OpenClaw 官方文档：OpenAI 兼容 Chat Completions endpoint，默认关闭

但文档同时强调了两件事：

第一，默认关闭。endpoint disabled by default，需要在 config 里显式开启。Peter 的 demo 是刻意打开这层兼容 surface 来做测试。

第二，这是高权限控制面。官方原话是 “Treat this endpoint as a full operator-access surface for the gateway instance”，并且警告不要直接暴露到公网。

所以这条 demo 展示的场景很精确：开发者在安全沙箱内显式开启高权限接口，用另一个实例去压测它。这是标准的开发阶段兼容性验证，不要理解成「OpenClaw 准备把 API 公网裸奔」。

/side 才是真正让人坐不住的东西

如果说双实例互测验证了技术链路，那 `/side` 改变的是开发者和 agent 的协作方式。

传统流程里，让 agent 去跑测试、改代码，开发者的状态要么是盯着终端干等，要么切出去做别的事情，要么不敢再输入任何东西——怕打断上下文或者搞乱执行流程。

Peter 的操作打破了这个局面：主任务在跑，人不用退出会话，用 `/side` 开一个旁路通道继续问问题、查资料、追问技术细节。

agent 当执行器的同时，还当对话伙伴。执行和追问并发了。

社区评论区的反应非常直接。

@dahulilang 说：

“Using /side to ask questions while Codex runs tests is the kind of async development workflow that actually feels like a genuine productivity leap.”

「一边让 Codex 跑测试一边用 /side 追问，这种异步开发工作流才像真正的生产力飞跃。」

@this_subhan 写了一条被大量引用的感慨：

“multitasking has evolved from ‘watching youtube while coding’ to ‘chatting with one agent while another ships tests'”

「多任务处理已经从’边写代码边看 YouTube’进化成’一个 agent 在跑测试，你跟另一个 agent 聊天’了。」

@_aashish_singh_ 则第一时间拿它和已有产品做对比：

“This seems to the identical to the /btw that is present in Claude Code”

「这跟 Claude Code 里的 /btw 功能看起来一样。」

说明开发者看到 `/side` 之后的第一反应，就是把它归类到「agent 旁路对话」这个正在成型的交互范式里。不同产品的实现各有差异，但开发者想要的东西很一致：跑长任务的时候别让我干等着，给我一个追问的窗口。

评论区最值钱的部分：技术挑战才是重点

这条帖子的评论区质量相当高，讨论没有停留在「酷」这个层面。

@ls_brd 提了一个非常关键的问题：

“did openclaw actually find the edge cases or were u guiding it the whole way?”

「OpenClaw 是自己找到了 edge case，还是你全程在引导它？」

这个问题直接指向 agent 的独立性——在这个 demo 里，agent 到底有多大程度上能自主发现兼容性问题？还是说人类已经知道问题在哪，只是借 agent 来执行？

从现有素材来看，这个问题还没有确定答案。Peter 的回复只确认了测试拓扑，没有详细说明哪些 edge case 是 agent 自主发现的。

另一条技术含量更高的追问来自 @Insignie2049：

“e2e on chat completion endpoints is the brutal one — does codex assert semantic similarity, or are you still doing exact-match on the response body?”

「chat completion 的 E2E 测试是最难的——Codex 用的是语义相似度断言，还是在做 response body 的精确匹配？」

这个问题切中了 LLM E2E 测试的核心难题：大模型的输出天然带有随机性，每次措辞都可能不同，断言策略怎么定？

而主贴附图里出现的 sentinel 方案给出了一种思路——不去断言自然语言部分的措辞，而是在工具调用结果里植入哨兵值，只要 sentinel 存在，就说明整条 tool calling 链路确实走通了。

@themccodes 给出了一条被广泛认同的评价：

“using openclaw to test openclaw is the only proof that actually means something”

「用 OpenClaw 来测 OpenClaw，才是唯一有说服力的证明。」

对于兼容层、代理层这类系统来说，纸面文档上写着「兼容 OpenAI API」往往说服力有限。真正让开发者信服的，是系统自己走过自己的那套路径，把任务跑通。这就是 dogfooding 的价值——你连自己都不用，凭什么让别人用？

背景：这位作者和这个项目

Peter Steinberger 就是 OpenClaw 的作者本人。他在个人博客里把 OpenClaw 描述为一个引发巨大反响的社区项目（playground project / community project），并强调会保持 open 和 independent，后续转入 foundation 结构。

▲ Peter Steinberger 个人博客：详细阐述 OpenClaw 的定位和发展方向

第三方评论文章（learndevrel.com）则记录了 OpenClaw 从发布到走红的速度，以及社区围绕安全和配置展开的争议。

▲ 第三方技术文章记录了 OpenClaw 的爆发速度和社区反应

也就是说，这条帖子的发布者就是项目作者本人，他展示的是自己项目演进过程中的真实开发工作流。

为什么这件事值得关注

把这条 demo 拆开看，真正有价值的信号有三层。

第一层：agent 能力边界正在从「帮我写代码」延伸到「帮我跑测试、帮我验接口」。开发者对 agent 的期待正在从代码生成转向全流程协作。Peter 的 demo 证明，至少在受控环境下，agent 已经可以参与 API 兼容性的端到端验证。

第二层：dogfooding 的标准正在提高。声称「兼容 OpenAI API」的项目越来越多，但真正用自己的产品压测自己接口的少之又少。OpenClaw 用双实例互测 tool calling 全链路，给了一个比文档承诺更可信的验证方式。

第三层：开发者和 agent 之间的交互模式正在分化。`/side` 代表的并行追问体验、Claude Code 的 `/btw`、以及其他产品中类似的旁路对话功能，都指向同一个方向——agent 执行长任务时，人不应该被迫退出交互。等待期就是协作期。

Peter Steinberger 自己在回复里还加了一条：

“it’s lobsters all the way down.”

「一路都是龙虾（OpenClaw 的吉祥物）。」

这句调侃拿了 148 个赞。递归、自引用、套娃——开发者天然喜欢这种优雅的自指结构。但优雅之下，跑通的是一条完整的 tool calling 验证链路，解决的是每一个想接入 OpenAI 兼容层的开发者都会碰到的真问题。

— END —