OpenClaw × Claude Code：Agent 自动调 Skill 实战教程

翔宇工作流第 17 期：OpenClaw 自动化

如果你也在折腾 AI 自动化——不是聊天那种，是真的让 AI 替你干活——你大概率踩过这个坑。

一边是 Claude Code——搭配订阅套餐使用 Claude 模型，手动用起来效率很高，稳定可靠。

另一边是 OpenClaw（AI Agent 编排框架）——10 个 AI Agent 各就各位，情报、研发、运维、小红书、微信、公众号、视频、课程、行政，团队齐了。

但这两边接不上。

OpenClaw 的 Agent 能调用 Claude Code，但调用之后呢？参数传对了吗？进程超时了谁来管？崩溃了 Agent 知道吗？跑了一夜的任务，第二天早上发现全挂了——能调用不等于能可靠地调用。

你有没有过这种经历？明明 Agent 启动了，结果什么都没跑出来？

翔宇在搭建一人公司系统的时候，也在这一步卡了整整两周。

直到翔宇写了一个东西：Bridge。

现在这套系统每天自动执行 Skill 调用，从笔记到配图到 SEO 报告，全程无人值守。

读完这篇，你将获得：

1. 一个核心认知：理解 Agent 和 Claude Code 之间为什么需要一座「桥」
2. 一套三层架构设计：从进程管理到 SDK 调用，怎么让自动化既灵活又可靠
3. 一个完整的源码项目：课程中附带脱敏源码，clone 下来直接部署

目录

• 一、为什么用 Claude Code，而不是直接调 API
• 二、Bridge 的核心设计：三层架构
• 三、两种模式：等快递 vs 寄快递
• 四、三层保险：任务绝不「失踪」
• 五、半夜没人回答怎么办
• 六、干完了，自动汇报
• 七、写在最后

1. 为什么用 Claude Code，而不是直接调 API

搞 Agent 自动化的人，迟早都会碰到这个前置问题：Agent 要干活，凭什么非得通过 Claude Code？直接调 API 不行吗？

行。但贵，而且不稳。

OpenClaw 的 Agent 每天要执行大量 Skill——写文章、做配图、跑 SEO 分析、生成视频脚本。每个 Skill 动辄消耗几十万甚至上百万 token，走 API 按量计费，一个月下来光 API 费就是一笔不小的开支。而且 API 有速率限制，高峰期排队，Agent 在那干等。

Claude Code 搭配订阅套餐（Pro/Max），用订阅额度跑 Claude 模型。 不按 token 计费，模型稳定，响应快。翔宇实测下来，这是现阶段让 Agent 高频自动化运行稳定性非常好的方案之一。

说人话
API 像出租车——按里程计费，跑得越多越贵。Claude Code + 订阅套餐像包月专车——每月固定价。一人公司的 Agent 每天要反复「出车」，你说选哪个？

关于合规
Anthropic 的消费者条款对 Agent SDK 搭配订阅套餐的使用有过争议。官方文档曾写明「不被允许」，但 Anthropic 员工随后公开澄清：个人本地使用目前没有问题。不过政策随时可能调整——如果你是商业用途或大规模部署，建议走 API Key 更稳妥。翔宇会持续关注政策变化，有更新第一时间同步。

搞清楚了「为什么用 CC」，接下来的问题是：怎么让这个调用稳定可靠？

OpenClaw 的 Agent 可以调用 Claude Code，这不难。难的是：Skill 跑到一半崩了怎么办？超时了谁来杀进程？参数不全 CC 停下来问你了怎么办——凌晨 3 点没人回答。

Skill 的可靠执行需要什么？启动一个独立的 CC 进程，传入参数，监控全程，处理异常，拿到结果，通知 Agent。这一整套「稳定保障」，需要一个专门的中间层来做。

打个比方
Agent 是老板，Claude Code 是工程师。老板会决策，工程师会干活。但老板不能直接钻进车间操作机器——他需要一个秘书。秘书接到老板的指令，去车间找到对应的工程师，盯着工程师干完，再把结果带回来汇报。Bridge，就是这个秘书。

翔宇自己踩过的坑：最开始没有 Bridge，让 Agent 直接调 CC。连续三天，每天早上起来发现——进程启动了但参数传错了、超时了没人管、崩溃了 Agent 完全不知道。Agent 以为任务还在跑，其实进程早就死了。

那种「以为在干活其实已经挂了」的感觉，只有经历过的人才懂。

2. Bridge 的核心设计：三层架构

Bridge 解决的不只是「调用」的问题，更是「可靠调用」的问题。

翔宇把 Bridge 设计成三层，每层只做一件事：

第一层：调度室（bridge-runner.sh）

接单、登记、安排。Agent 直接调用的就是这一层。它创建运行目录，写入初始状态，决定用同步还是异步模式启动任务。如果任务挂了，它负责善后。

第二层：门卫（bridge.sh）

检查环境是否就绪——Python 虚拟环境有没有、依赖装了没有。通过就放行，不通过就报错告诉你怎么修。

第三层：执行间（bridge.py）

真正干活的地方。使用 Claude Agent SDK 的 query() 函数，启动一个 Claude Code 进程，把 Skill 和参数丢进去，然后逐条处理返回的消息流——文本输出、工具调用、最终结果。

说人话
三层就像一家工厂的接单流程。客户下单到前台（Runner），前台登记编号、检查付款，然后交给车间主管（Shell），车间主管确认设备就绪，最后交给工人（Python）实际生产。每一层出了问题都有兜底，不会让客户的订单无声消失。

为什么不做成一层？因为翔宇试过。500 行的大脚本，凌晨崩了——日志里全是错误，但你分不清是 Python 的问题还是 Shell 的问题还是网络的问题。排查到天亮，发现是虚拟环境没激活。

一个凌晨的教训换来一条原则：每层只做一件事，问题在哪一层，一眼就知道。

3. 两种模式：等快递 vs 寄快递

Bridge 支持两种执行模式，适用于完全不同的场景：

同步模式——等快递。

Agent 发出指令后，一直等到 Skill 执行完才继续。适合短任务，比如查个数据、发条消息。缺点是 Agent 在等待期间什么都不能做。

异步模式——寄快递。

Agent 发出指令后立即返回，拿到一个「快递单号」（状态文件路径）。Skill 在后台运行，完成后自动通知 Agent。适合长任务，比如写一篇文章、剪一个视频。

翔宇自己的系统里，90% 的调用用异步模式。因为大多数 Skill——写笔记、做配图、生成视频——都需要 3 分钟到 30 分钟不等。让 Agent 傻等？不可能的。

同步是单线程人生，异步才是一人公司。

（文末有完整的一键复刻提示词，可以直接让 CC 帮你搭建一套。）

记住这个
异步模式的核心不是「快」，是「不阻塞」。Agent 派出任务后可以继续处理其他消息，完成后再回来看结果。这才是一人公司能运转的关键——10 个 Agent 并行干活，而不是排队等。

那怎么知道任务跑到哪了？状态文件。

每次执行都会生成一个 state.json，记录当前状态、PID（Process ID，进程标识符）、启动时间、最后心跳。Agent 随时可以查。更聪明的是，Bridge 还会检测进程是否真的还活着——如果进程已经死了但状态还写着「running」，它会自动修正为「killed」。

连被 SIGKILL（操作系统强制终止信号）强杀的场景都能检测到。 这是翔宇被坑了无数次之后才加上的。

4. 三层保险：任务绝不「失踪」

翔宇跑了两个月自动化之后，总结了一条血泪教训：

任务最可怕的不是失败，是失踪。

想想看，你有多少次以为自动化在跑，其实早就挂了？

失败没关系，至少你知道出了什么问题。但失踪呢？任务挂了，没有任何通知，Agent 以为还在跑——你第二天早上才发现，昨晚安排的活儿全部石沉大海。

所以翔宇给 Bridge 买了三份保险：

第一份：自动善后

不管任务怎么结束——正常完成、中途崩溃、被系统杀掉——Bridge 都会自动记录「发生了什么」，写进状态文件。不会出现「任务消失了但没人知道」的情况。

第二份：万能兜底

即使是最意外的崩溃——比如系统内存不够直接把进程踢掉——Bridge 也能捕获到，做三件事：记录状态、写下错误原因、通知 Agent。

第三份：看门狗

Bridge 会给每个任务设一个闹钟。如果一个任务超过设定时间还没完成（可能卡死了），看门狗直接终止它，然后把「超时了」写进记录。

打个比方
就像你派了一个快递员出去送货。第一份保险：快递员到了就自动签到。第二份保险：快递员出了车祸，保险公司自动通知你。第三份保险：快递员超过 2 小时没回来，调度中心自动联系他。三层保险叠在一起——你永远不会不知道快递员去哪了。

塔勒布说过一个概念叫「反脆弱」——好的系统不是不会出错，而是每次出错都会变得更强。Bridge 的三层保险就是这个思路：不追求不出错，追求出了错一定被发现。 当每个失败都被记录、被通知、被修复，系统就会越跑越稳。

5. 半夜没人回答怎么办

Claude Code 在干活的时候，有时会停下来问你：「请问目标语言是什么？」「请提供文件路径。」

你坐在电脑前，打个字就行了。但 Bridge 是凌晨 3 点在后台跑的——没有人坐在电脑前。

怎么办呢？

Bridge 的做法是：提前把所有答案打包好。 在派任务的时候，Agent 把所有可能需要的信息——参数、配置、可能被问到的问题的答案——一次性塞给 Bridge。CC 需要什么，自己去里面找。

如果实在还缺了什么，Bridge 不会傻等，而是直接停下来，告诉 Agent「CC 问了这个问题，你补上再来」。Agent 补完信息，重新派单。

打个比方
去政务大厅办事，材料不全工作人员会让你回去补。Bridge 的做法是：提前把所有材料准备齐，一次性提交。万一还缺了什么，工作人员会明确告诉你缺什么——你补完再来，而不是在窗口前傻站着。

翔宇最开始没做这一步，结果呢？半夜跑的 Skill 经常卡在「请输入……」那里，一等就是一整夜。第二天早上才发现，什么都没跑成。

自动化最大的敌人不是技术难度，是「意外的人工干预」。

6. 干完了，自动汇报

最后一步：任务跑完了，怎么告诉 Agent？

Bridge 会自动把结果「送」到指定 Agent 手里。更聪明的是，它还知道这个 Agent 在哪个 Discord 频道——结果一出来，Agent 直接在对应的频道里回复。

你在 Discord 说一句话 → Agent 接到任务 → Bridge 调用 CC 干活 → 干完了 → Bridge 通知 Agent → Agent 在 Discord 回复你。

一个完整的闭环。

而你作为老板，需要做什么？

什么都不用做。 早上端着咖啡打开 Discord，昨晚的笔记写了、配图做了、SEO 报告跑了、字幕翻译完了。10 个 Agent 各自汇报完毕，等你一句「收到」。

那一杯咖啡的时间，就是一人公司和传统团队的差距。

那一刻翔宇才意识到——这不是「用 AI」，这是「AI 在替你上班」。

你可能会问
「如果 Bridge 自己挂了怎么办？」好问题。三层保险确保了即使 Bridge 崩溃，状态记录也会被更新。Agent 下次查看时会发现异常，可以选择重试。这就是「可靠」的含义——不是永远不出错，是出了错一定能被发现、能被修复。

写在最后

回顾一下这篇文章的核心：

1. CC + 订阅套餐是当前稳定性很好的方案——用订阅额度跑 Claude 模型，稳定高效（注意关注 Anthropic 政策变化）
2. 能调用不等于能可靠调用——Agent 能调 CC，但进程管理、异常兜底、超时处理这些稳定性保障需要 Bridge
3. 三层架构各司其职——前台管接单、门卫管环境、车间管执行，问题出在哪一层一目了然
4. 异步模式是一人公司的命脉——10 个 Agent 并行干活，而不是排队等
5. 三层保险让任务不会失踪——自动善后、万能兜底、看门狗超时，任务永远不会无声消失
6. 半夜没人也能跑——所有答案提前打包，CC 不会卡在「请输入……」上

翔宇在做一人公司这件事上，最大的体会是：

搭建 Agent 是 10%，让 Agent 可靠地干活是 90%。

Bridge 就是那 90% 里最关键的一块拼图。它不炫酷、不性感，但没有它，10 个 Agent 就是一群坐在办公室里的空气。

大多数人还在问「AI 能聊天吗」，而我们已经在解决「AI 怎么替我上班」。这就是差距。

如果你也是那种不满足于让 AI 只是聊天，而想让 AI 真正替你干活的人——恭喜你，我们是同一类人。

这套 Bridge 系统只是「OpenClaw 一人公司」系列的一个核心组件。在课程中，你还会学到 Agent Workspace 设计、多 Agent 协作编排、Cron 定时任务、Discord / 飞书集成、自我进化系统。如果你想获取完整源码、系统学习 AI Agent 自动化工作流，欢迎加入翔宇工作流：AI 编程实操课。

你搭 Agent 系统的时候，踩过最深的坑是什么？留言区聊聊。

觉得有用，收藏备查，点个在看，让更多搞自动化的人看到。

一键复刻

复制这段提示词给 Claude Code，从零搭建 OpenClaw Bridge 系统：

「请帮我搭建 OpenClaw Bridge 系统，实现 OpenClaw Agent 自动调用 Claude Code 执行 Skill 的能力。

技术要求：

1. 使用 claude_agent_sdk 的 query() 函数调用 CC，支持同步和异步两种模式
2. 三层架构：bridge-runner.sh（进程管理 + 状态追踪）→ bridge.sh（venv 激活）→ bridge.py（SDK 调用 + 消息处理）
3. 状态管理：每次执行创建独立运行目录，state.json 记录状态（starting / running / done / error / killed），支持 PID 存活检测
4. 三层防御：Shell EXIT trap 兜底非正常退出、Python BaseException 捕获所有异常、Watchdog 超时强杀
5. AskUserQuestion 拦截：通过 PreToolUse hook 拦截交互请求，参数不全时停止执行并报告缺失字段
6. 通知回调：完成后通过 openclaw agent --deliver 通知调用方 Agent，支持动态解析 Discord 频道 ID
7. 通信协议：stdout 标记格式 [BRIDGE:STATUS] / [BRIDGE:DONE] / [BRIDGE:ERROR]
8. 配置集中管理：模型、超时、心跳间隔、Skill 目录等常量统一在 config.py
9. 原子状态写入：tmp + rename 防止读到半截 JSON
10. 安全规则注入：禁止全盘搜索、禁止访问敏感目录、强制先读 SKILL.md

依赖：Python 3.12+、uv 包管理器、claude-agent-sdk、OpenClaw CLI

请按以上规格实现完整项目，包含所有文件：bridge-runner.sh、bridge.sh、bridge.py、config.py、state.py、protocol.py。」