上一篇写了怎么搭 AI agent 团队。团队能干活了，新问题来了：运维地狱。
4 个 agent 在 4 个频道同时工作，任务在十几个状态之间流转，CI 跑完了要有人通知 QA，QA 挂了要有人通知开发回去改。之前这些全靠 agent 之间互发消息——每发一条消息就是一次 LLM 推理，成本高、速度慢、还经常出幻觉。
于是我花了一天，造了个运维仪表盘。
核心问题
1. Agent 间通信太贵
Agent A 要通知 Agent B：发一条 Discord 消息 → Agent B 的 session 被唤醒 → 完整的 LLM 推理 → 输出一段话 → 才完成"已收到"。
一句"你的 CI 过了"就要烧掉几万 token。更糟的是，agent 有时候会在回复里加戏，浪费更多。
2. 没有全局视图
任务状态散落在 JSON 文件和 Discord 消息里。想知道"现在哪个 agent 在忙什么"，得逐个频道去翻。
3. Context Window 无形膨胀
OpenClaw 管理的 agent session 会持续累积上下文。200k 的窗口，不知不觉就用到 80%，然后响应质量开始下降。之前完全没有监控手段。
解决方案
非 LLM 任务路由
最大的改进：把所有跨 agent 通知交给一个纯机械的 Discord bot。零 AI 推理，纯状态机 + REST API。
任务状态变化 → Router 检测 → 通过 Discord REST API 发通知
它做的事：
- 自动派发：任务
new→ ping PM 频道；approved→ ping 指定开发频道 - CI 轮询：每 60 秒检查 GitHub Actions，通过了路由到 QA，失败了通知开发
- 合并检测：QA 验收通过的 PR 被 merge 后，自动关闭任务并通知
整个 router 就是一个 Node.js 模块，用 Discord bot token 调 REST API。百来行代码，替代了之前大量的 LLM-to-LLM 通信。
看板 Dashboard
React + Vite 前端，Express + SQLite 后端，Docker Compose 一键部署。
五列看板把十几种任务状态归类成人能快速扫视的分组：
| 列 | 包含状态 |
|---|---|
| Backlog | new, pending, approved |
| In Progress | dispatched, in_progress |
| Review | pr_submitted, ci_passed, ci_failed |
| QA | qa_pass, qa_fail |
| Done | done |
任务按最后更新时间排序，最新的在最上面。点进去能看到任务详情、关联的提案文档和 QA 报告——左右分栏，Markdown 渲染 + 语法高亮。
Context Window 监控
这是我用得最多的功能。每个 agent 卡片上有一根进度条：
- 绿色 <60%：健康
- 橙色 60-80%：开始满了
- 红色 >80%：该重置了
数据流：host 端 cron 每 2 分钟跑一次脚本，解析 openclaw sessions list 的输出，写成 JSON，Docker 容器挂载读取，前端 10 秒轮询一次。
一看到有 agent 飘红，点一下"Reset Sessions"，自动给所有频道发 /new。
QA 严格模式
QA agent 有硬性规则：
- 存在 P1/P2 问题 → 必须 fail
- 缺少单元测试 → 必须 fail
- 每次验收都要写 QA 报告（Markdown 文件）
当开发修完问题重新提 PR，router 检测到 CI 通过后，会给 QA 发一条 RE-VERIFICATION REQUIRED，附上之前的 QA 报告路径，让 QA 知道要复查哪些问题。
技术选型
| 层 | 技术 |
|---|---|
| 前端 | React + TypeScript + Vite + Tailwind |
| 后端 | Express + SQLite |
| 路由 | Discord REST API（纯机械） |
| 容器 | Docker Compose |
| 主题 | GitHub Dark（#06090f / #0d1117 / #238636） |
选 SQLite 是因为数据量小（几百条任务 + 活动日志），不值得上 Postgres。选 Docker 是因为想要 restart: unless-stopped，机器重启后自动恢复。
几个教训
能用状态机就别用 LLM。 任务路由本质上是 if status == X then notify channel Y。把这种逻辑交给 LLM 就像用 GPT 做加法——能做，但没必要。
监控要先于优化。 之前 agent 的 context window 悄悄涨到 80% 我完全不知道，只是觉得"最近回复质量好像差了"。有了监控条之后，问题变得可视化，解决也就 trivial 了。
Dashboard 是给人看的。 Agent 通过 API 交互，dashboard 存在的唯一目的是让我扫一眼就知道全局状态。不需要花哨的交互，信息密度高就行。
下一步
- 成本追踪：按 agent 统计每日 token 消耗和美元成本
- 自动重置：context 到 80% 自动触发
/new - Webhook 替代轮询：用 GitHub webhooks 替换 CI 轮询，反馈更即时
整套系统跑在一台机器上。4 个 agent、1 个 router、1 个 dashboard，除了 AI API 之外零云依赖。有时候最简单的架构就是最好的架构。