OpenClaw 一人公司：管 10 个 Agent，我只靠两个脚本

翔宇手下有 10 个 AI Agent，分布在 10 个 Discord 频道里，7×24 小时干活。

问题是——怎么知道它们到底在不在干活？

打开 Discord 客户端，等加载，一个个频道点进去翻。翻到第三个频道，前两个看了什么已经记不清了。翻完 10 个频道，20 分钟过去，结论是「好像都正常」。好像。

翔宇受不了这个「好像」，写了两个脚本，总共不到 200 行。现在哪个 Agent 出了问题，其他 Agent 会自动调用这两个脚本——读频道消息、发测试指令，10 秒定位问题在哪，不需要翔宇动手。

这篇文章讲的就是这 200 行背后的设计。

读完这篇，你将获得：

1. 一套调试思路：理解为什么「先看消息再看日志」是 Agent 排查的正确顺序
2. 一对即用脚本：discord-read.sh 读消息、discord-send.sh 发消息，一行命令搞定
3. 一个完整的源码项目：课程中附带脱敏源码，clone 下来填上你的配置直接用

目录

• 一、排查 Agent，第一步不是看日志
• 二、两个脚本，各做一件事
• 三、自动识别你在哪台机器
• 四、Agent 名字变频道号：一张映射表
• 五、读消息：看穿频道里发生了什么
• 六、发消息：给 Agent 频道塞通知
• 七、写在最后

1. 排查 Agent，第一步不是看日志

翔宇踩过一个认知偏差：Agent 出问题，第一反应是翻日志。

为什么？因为焦虑。凌晨出了事，你本能地想做「看起来最专业」的事——打开终端、grep 错误码、翻 stack trace（堆栈追踪）。这在心理学上叫确认偏误：人在焦虑时，倾向于做「看起来有用」的事，而不是「真正有效」的事。

日志当然有用。但日志是系统视角——一堆时间戳、JSON、错误码，你得在脑子里把它们翻译成「到底发生了什么」。

而 Discord 频道消息是业务视角——Agent 说了什么、干了什么、回复了谁、有没有报错——一目了然。

说人话
日志像病历本——专业但需要医生解读。频道消息像病人自己说的话——「我头疼，昨晚没睡好」。先听病人说，再看病历，排查效率翻倍。

翔宇现在的排查顺序是固定的：

第一步：读频道消息 —— 看 Agent 最近说了什么、有没有报错

第二步：发测试消息 —— 确认通道是否通畅

第三步：才看日志 —— 带着假设去翻，效率完全不同

这个顺序，是被无数次「在日志里大海捞针」的教训逼出来的。

先看消息再看日志——这六个字，能帮你省掉 80% 的排查时间。

你排查 Agent 问题时，第一步做的是什么？

读到这里，先做一件事：打开你的终端，试试能不能 curl 访问 discord.com。如果能通，说明你的网络环境已经准备好了。

（文末有完整的一键复刻提示词，可以直接让 CC（Claude Code）帮你部署。）

2. 两个脚本，各做一件事

翔宇的设计哲学：一个脚本只做一件事。

discord-read.sh —— 读消息。

给它一个 Agent 名字（比如 wechat），它自动去对应的 Discord 频道拉最近的消息，格式化输出。时间、作者、内容，一眼扫完。

discord-send.sh —— 发消息。

给它一个 Agent 名字和一段文字，它把消息发到对应频道。注意：这是 Bot（机器人）身份发的消息，不会触发 Agent——纯粹用来做通知和标记。

打个比方
read 是对讲机的「收听」按钮，send 是「发话」按钮。两个按钮，两个脚本，不混在一起。为什么不合成一个？因为翔宇试过——合在一起之后，参数解析一团乱，出了 bug 分不清是读的问题还是发的问题。分开之后，哪个坏了修哪个，30 秒定位。

这就是翔宇反复强调的原则：每层只做一件事，问题在哪一层，一眼就知道。

3. 自动识别你在哪台机器

翔宇跑 OpenClaw 的环境是双机架构——主力机（.228）和服务器（.167）。两台机器的 Discord Bot 不同、代理配置不同、频道 ID 也不同。

如果每次用脚本还得手动切配置，那和没有脚本有什么区别？

所以翔宇在脚本里加了一个小机关：自动检测当前是哪台机器。

脚本启动时读取主机名。如果包含「xiaoyu」或「228」，就知道自己在主力机上——用主力机的 Bot Token（身份凭证），走 Surge proxy（因为国内访问 Discord 需要代理）。否则就是服务器——用服务器的 Bot Token，直连（服务器有外网）。

记住这个
双机架构下，脚本必须「知道自己在哪」。这个自动检测的设计让同一份脚本在两台机器上都能直接跑，不需要改任何配置。翔宇把这个叫做「环境感知」——脚本感知环境，而不是让人告诉脚本环境。

如果你也是那种在两台机器之间切来切去、被配置差异折磨过的人，你一定懂这种设计的价值。

翔宇之前的做法是：主力机一份脚本，服务器一份脚本。两份代码 90% 一样，改一个 bug 得改两遍。有一次改了主力机忘了改服务器，排查了一个小时才发现。

两份代码做同一件事——这本身就是 bug 的温床。

好的工具让你忘记环境差异。真正的「环境感知」不是让你选择环境，而是让环境这个概念从你的脑子里消失。

4. Agent 名字变频道号：一张映射表

Discord 的 API 需要 Channel ID（频道编号）——一串 18 位数字。但翔宇排查问题的时候，脑子里想的是「微信部怎么了」「研发部在干嘛」，不是「1477147705196154964 怎么了」。

所以脚本内部维护了一张映射表：Agent 名字 → Channel ID。

你输入 wechat，脚本自动翻译成对应的频道编号。你输入 main，就是总部频道。输入 rnd，就是研发部。

翔宇有一次凌晨排查问题，脑子里想的是「微信部」，手上敲的是一串 18 位数字。结果敲错了一个数字——查了半个小时，一条消息都没有，以为 Agent 挂了。最后才发现查的是另一个频道。半小时的焦虑，全浪费在一个数字上。

有了映射表之后，你永远不需要记那串数字。脑子里想的是什么，手上敲的就是什么。

10 个 Agent，10 个频道，一一对应：

main（总部）、admin（行政部）、archive（运维部）、wechat（微信部）、xhs（小红书部）、youtube（油管部）、twitter（推特部）、course（课程部）、rnd（研发部）、intel（情报部）

你可能会问
「为什么不用关联数组（Associative Array）？」好问题。因为 macOS 自带的 Bash 是 3.2 版本，不支持关联数组。翔宇用 case 语句替代，兼容性拉满——任何 Mac 拿来就能跑，不需要额外安装新版 Bash。

而且，如果你直接传一个 18 位数字，脚本也认——直接当 Channel ID 用，跳过映射。这是给高级用户留的后门：万一你临时要查一个不在映射表里的频道，直接传 ID 就行。

好的工具，不是在人和机器之间加一层翻译，而是让翻译这件事消失。

你有没有过类似的经历——明明知道自己要查什么，却卡在了一个编号、一个路径、一个配置项上？

5. 读消息：看穿频道里发生了什么

discord-read.sh 的用法极简：

读微信部最近 5 条消息：传入 wechat 和 5

读总部最近 10 条（默认）：只传 main

输出是这样的：

时间 作者名：
消息内容

时间 另一个作者：
另一条消息

时间倒序排列，最早的在上面，最新的在下面——和你在 Discord 里看到的顺序一样。

设计洞见
为什么不直接输出 API 返回的原始 JSON？因为 JSON 里有一堆你不关心的字段——消息 ID、头像 URL、角色信息、权限标记。排查问题的时候，你只关心三件事：谁说的、什么时候说的、说了什么。脚本把 JSON 解析成人话，让你 3 秒扫完 10 条消息。

还有一个细节：如果消息里包含 Embed（嵌入式卡片，比如 Bot 发的结构化通知），脚本也会提取标题和描述。这样 Bridge（桥接服务）通知的执行结果也能看到。

翔宇实测，这个脚本每天至少用 5 次。早上起来第一件事：

依次读 main、wechat、xhs、rnd —— 10 秒扫完四个频道，比打开 Discord 客户端还快。

翔宇记得第一次用这个脚本的那个早上。跑完四个频道，3 秒就发现 wechat 频道凌晨 3 点报了一个 API 超时。如果不是脚本，翔宇可能打开 Discord 客户端，一个个频道点进去翻，20 分钟才发现同一个问题。3 秒 vs 20 分钟——这就是入口选对的力量。

如果你也是那种宁愿在终端里操作、也不想在 GUI 上点来点去的人，你会爱上这个脚本。

调试效率的本质不是技术能力，是入口选择。选对了入口，菜鸟也比专家快。

6. 发消息：给 Agent 频道塞通知

discord-send.sh 的用法同样极简：

给研发部发一条消息：传入 rnd 和你的消息内容

发送成功，脚本返回消息 ID 作为确认。失败则返回 Discord API 的错误信息。

记住这个
Bot 发的消息不会触发 Agent。OpenClaw 只响应真人用户在频道里发的消息。Bot 消息纯粹是通知和标记用途——比如在频道里留一条「系统维护中」的提示，或者给某个事件打个时间戳标记。

翔宇用这个脚本最多的场景：

场景一：维护通知。 要重启 Gateway（网关）之前，先给总部频道发一条「系统即将重启」。Agent 看到这条消息不会执行任何操作，但你事后回看频道记录时，能清楚知道这个时间点发生了什么。

场景二：调试标记。 有一次翔宇排查研发部 Agent 的异常行为——它突然开始重复执行同一个任务。翔宇在频道里发了一条「=调试开始 14:32=」，然后手动触发了一次任务，观察 Agent 的响应。两分钟后发了「=调试结束 14:34=」。事后回看频道记录，两条标记之间的消息就是问题现场——不需要在几百条消息里猜「大概是哪个时间段」。

场景三：自动化脚本集成。 把 discord-send.sh 嵌入其他脚本——比如定时任务跑完之后，自动给对应频道发一条完成通知。翔宇的 Cron（定时任务）备份脚本每天凌晨跑完后，会自动给运维部频道发一条「备份完成，耗时 47 秒」。第二天早上扫频道时，一眼就知道备份有没有出问题。

打个比方
discord-read.sh 是你的眼睛，discord-send.sh 是你的手。眼睛看到「频道安静」，手就伸进去贴一张便利贴——「我来看过了，一切正常」或者「发现问题，正在排查」。下次再看，一目了然。

好的调试习惯不是天生的，是工具养成的。

你现在的调试流程里，有没有「标记时间点」这个动作？

写在最后

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

1. 排查 Agent，先看消息再看日志——频道消息是业务视角，日志是系统视角，先听病人说话再看病历
2. 一个脚本只做一件事——read 读、send 发，分开设计，出了问题 30 秒定位
3. 环境感知——脚本自动检测主力机还是服务器，同一份代码双机通用
4. Agent 名字映射 Channel ID——脑子里想的是「微信部」，手上敲的也是「wechat」
5. Bot 消息不触发 Agent——纯通知、纯标记、纯调试，不会干扰 Agent 正常工作

翔宇在调试 OpenClaw 这件事上，最大的体会是：

90% 的排查时间，浪费在「不知道从哪看起」。

这两个脚本解决的不是技术难题——curl 调 Discord API，谁都会写。它们解决的是调试入口的问题：让「第一步看什么」变成一行命令的事。

当第一步变快了，后面每一步都会变快。

翔宇现在的早晨是这样的：起床，打开终端，四行命令扫完四个频道，端着咖啡看完结果——整个过程不超过 30 秒。这 30 秒，替代了过去每天早上 20 分钟的焦虑排查。这就是工具的力量——不是让你变强，是让焦虑消失。

大多数人在工具上的投入方向是错的——他们追求更强大的工具，却忽略了一个事实：决定效率的不是工具的能力上限，而是你触达工具的路径长度。一个 10 秒能用上的简单脚本，永远比一个需要 5 分钟打开的强大平台更有效。

如果你也是那种不满足于在 Dashboard 上点来点去，而想用命令行掌控一切的人——恭喜你，我们是同一类人。

你调试 Agent 的时候，最头疼的是什么？留言区聊聊。

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

一键复刻

复制这段提示词给 Claude Code，从零搭建 OpenClaw Discord 调试脚本：

「请帮我搭建 OpenClaw Discord 调试脚本，实现一行命令读写 Agent 频道消息的能力。

技术要求：

1. 两个独立脚本：discord-read.sh（读取频道消息）和 discord-send.sh（发送消息到频道）
2. 自动机器检测：通过 hostname 判断当前机器，自动选择对应的 Bot Token 和代理配置
3. Agent 名字映射：支持 main/admin/archive/微信/小红书/youtube/twitter/course/rnd/intel 十个 Agent，自动映射到对应 Channel ID
4. 兼容 macOS Bash 3.2+：不使用 declare -A（关联数组），用 case 语句替代
5. 代理支持：主力机走 HTTP proxy（Surge），服务器直连
6. Bot Token 从凭证文件读取：路径为 ~/.claude/知识库/凭证/discord.md（主力机）和 discord-server.md（服务器）
7. 读消息支持自定义条数（默认 10 条），时间倒序输出，提取 Embed 标题和描述
8. 发消息返回消息 ID 确认，JSON 安全转义
9. 支持直接传 Channel ID（纯数字）跳过映射
10. 错误处理：Token 缺失、未知 Agent、API 错误均有明确提示

环境：macOS + Bash 3.2+ + curl + python3（仅用于 JSON 解析）

请按以上规格实现两个完整脚本。」

这套调试脚本只是「OpenClaw 一人公司」系列的一个实用工具。在课程中，你还会学到 Agent Workspace 设计、Bridge 自动化调用、Cron 定时任务、安全重启机制、多 Agent 协作编排。如果你想获取完整源码、系统学习 AI Agent 自动化工作流，欢迎加入翔宇工作流：AI 编程实操课。