十个 Agent 的频道怎么盯，两个脚本把二十分钟压成三十秒

十个 Agent 分散在十个 Discord 频道里，情报、微信、小红书、研发、运维，各自值各自的班，七乘二十四小时不停。听起来很美，直到你想回答一个简单的问题，它们现在到底在不在干活。

没工具的时候，答案是打开 Discord 客户端，等它加载完，一个频道一个频道点进去翻。翻到第三个，前两个讲了什么已经记不清了。十个频道翻完，二十分钟没了，结论是好像都正常。

好像。这两个字在运维里等于没说。更要命的是这种排查没法外包，你总不能让团队每个人都翻二十分钟频道，就为了确认一夜平安。

后来我写了两个脚本，加起来不到两百行，discord-read.sh 读频道消息，discord-send.sh 往频道发消息。现在哪个 Agent 出了状况，别的 Agent 会自己调脚本去读频道、发测试指令，十秒定位问题，不用我动手。每天早上我的巡检就是四行命令，扫完四个频道，咖啡还烫嘴。

这篇把这两百行背后的设计掰开，排查为什么不能先看日志、脚本为什么要分两个、怎么让脚本自己认机器、Agent 名字怎么变频道号，全是能直接搬回去用的做法。

排查第一步，不是翻日志

Agent 出问题，很多人的第一反应是翻日志。我以前也这样，凌晨出了事，本能地想做看起来最专业的事，开终端、grep 错误码、翻堆栈。后来想明白了，这是焦虑驱动的确认偏误，人在慌的时候倾向于做看起来有用的事，不是真正有效的事。

日志当然有用，但它是系统视角，一堆时间戳、JSON、错误码，你得在脑子里把它们翻译成到底发生了什么。频道消息是业务视角，Agent 说了什么、干了什么、回了谁、有没有报错，一眼扫完。打个比方，日志像病历本，专业，但要医生解读。频道消息像病人自己开口，我头疼，昨晚没睡好。先听病人说话，再翻病历，效率翻倍。

所以我的排查顺序是固定的。读频道消息，看它最近说了什么、有没有报错。发一条测试消息，确认通道通不通。这两步都捞不出线索，才带着假设去翻日志，这时候下铲子，一挖一个准。

先看消息再看日志，六个字，省掉八成排查时间。

一个脚本只干一件事

read 负责读，给它一个 Agent 名字，它去对应频道把最近的消息拉回来，时间、作者、内容排得整整齐齐。send 负责发，给它名字和一段文字，消息就进频道了。

有个细节容易误会，send 是用 Bot 身份发的，不会触发 Agent。OpenClaw 只响应真人账号的消息，Bot 消息纯粹是通知和标记，你可以放心拿它留言、打时间戳，不会惊动任何一个正在干活的 Agent。

为什么不合成一个脚本，我试过。合在一起之后参数解析一团乱，出了问题分不清是读坏了还是发坏了。分开之后，哪个坏了修哪个，三十秒定位。老雷给企业做交付时反复念这条，每层只做一件事，问题在哪一层，一眼就知道。

让脚本认机器，让手敲人话

前两条讲的是排查思路，这一节讲顺手，工具不顺手，思路再对也坚持不了三天。

我的运行环境是双机，一台主力机一台服务器，两台机器的 Bot 凭证不同，代理配置也不同，主力机访问 Discord 要走 Surge 代理，服务器有外网直连。

最早的蠢办法是维护两份脚本，主力机一份服务器一份，九成代码一样。改一个 bug 得改两遍，有一次只改了主力机忘了服务器，排查一个小时才发现两台机器跑的不是同一个版本。两份代码做同一件事，这本身就是 bug 的温床。

后来在脚本开头加了个机关，自动读主机名，名字里带 228 就认定自己在主力机，用主力机的 Token、走代理，否则按服务器处理，直连。用现在流行的话说叫环境感知，让脚本认环境，而不是让人每次告诉脚本它在哪。同一份脚本拷到哪台都能跑，不用改任何配置，这才叫工具。

另一件不顺手的事是频道号。Discord 的接口认 Channel ID，一串十八位的数字。但人排查的时候，脑子里想的是微信部怎么了、研发部在干嘛，不是那串数字。

所以脚本里放了一张映射表，Agent 名字翻频道号。十个名字对应十个频道，main 是总部，admin 是行政部，archive 是运维部，wechat 是微信部，xhs 是小红书部，youtube 是油管部，twitter 是推特部，course 是课程部，rnd 是研发部，intel 是情报部。敲 wechat 就是微信部，敲 rnd 就是研发部，脑子里想的是什么，手上敲的就是什么。

踩过的坑得说。有天凌晨排查问题，心里想着微信部，手上敲的是一串数字，敲错了一位，查了半个小时，一条消息都没有，以为 Agent 全挂了，兜兜转转才发现查的是个不相干的频道。半小时的焦虑，全浪费在一位数字上。

实现上有个妥协，macOS 自带的 Bash 是 3.2，不支持关联数组，映射用 case 语句写，兼容性拉满，任何 Mac 拿来就能跑。另外直接传一串纯数字它也认，跳过映射当频道号用，给临时要查表外频道的人留个后门。

三十秒早巡检，send 的三个场景

read 的输出长这样，时间、作者、内容，一行一条，最早的在上最新的在下，跟 Discord 里看到的顺序一致。消息里带 Embed 卡片的，把标题和描述也抠出来，这样 Bridge 通知的执行结果也能看到。原始 JSON 里那些消息 ID、头像地址一概不输出，排查只关心三件事，谁说的、什么时候说的、说了什么。条数也随调，默认十条，想看一整晚就传五十。

我现在每天早上的固定动作，依次读总部、微信部、小红书部、研发部四个频道，十秒扫完。第一次用它的那个早上，三秒就看到微信部凌晨三点报了 API 超时。搁以前，这个问题要在客户端里翻二十分钟才撞得见。

send 我用得最多的三个场景。一个是维护通知，重启网关之前先往总部频道发一条「系统即将重启」，Agent 不理它，但事后回看记录，这个时间点发生过什么清清楚楚。一个是调试标记，有次研发部的 Agent 突然重复执行同一个任务，我在频道里发了「调试开始 14 点 32 分」，手动触发一次任务，两分钟后发「调试结束」，两条标记之间的消息就是问题现场，不用在几百条消息里猜时间段。一个是自动化集成，Cron 备份脚本每天凌晨跑完，自动往运维部频道发一条「备份完成，耗时 47 秒」，第二天扫一眼频道就知道备份有没有出事。

read 是眼睛，send 是手，眼睛看到安静，手就去贴一张便利贴。

复刻提示词，照抄就能跑

复制这段给 Claude Code，两个脚本一次生成。

「帮我写两个 Discord 调试脚本，Bash 3.2 兼容，不用关联数组，映射用 case 语句。discord-read.sh，传入 Agent 名字和条数，默认十条，自动映射 Channel ID 调 Discord API，按时间顺序输出时间、作者、内容，提取 Embed 的标题和描述。discord-send.sh，传入 Agent 名字和内容，Bot 身份发消息，成功返回消息 ID，JSON 安全转义。自动机器检测，读主机名，带 228 判断为主力机，用主力机 Token 并走 HTTP 代理，否则用服务器 Token 直连，Token 分别从本机的凭证文件读取。支持直接传十八位纯数字跳过映射。Token 缺失、未知名字、接口报错都给明确提示。环境是 macOS 加 curl 加 python3 做 JSON 解析。」

验收三步。read 一个活跃频道，看输出格式对不对。send 给测试频道发一条，看有没有返回消息 ID。把主机名判断的两个分支各跑一遍，确认两台机器都认得自己。

两个坑提前交代。Token 文件路径写错的时候，脚本不会报错，只会安安静静发不出东西，记得先手动 curl 一次，验证 Token 本身有效再怪脚本。代理没配好的时候，报错会伪装成网络超时，先确认代理端口通不通，再去怀疑 Discord。

这套做法未必是全网最优解，我只是把每天要重复几十次的动作磨快了。这俩脚本没什么技术难度，curl 调接口谁都会写，它们解决的是入口问题。九成的排查时间，浪费在不知道从哪看起。企业里上多 Agent 也是一样，老雷见过太多团队把预算砸在监控大盘上，到头来每天被用的只有两条几十行的命令。决定效率的不是工具的能力上限，是你触达它的路径长度。今晚就把读消息那条命令写出来，明天早上你就能多睡二十分钟。