多个 AI 编码 Agent 同时跑，进度如何一眼看清？Weatherdeck 用只读看板汇总工作状态
当 Claude Code、Codex 或自建 Agent 分别在不同终端、机器和仓库里工作时，真正麻烦的往往不是启动它们，而是确认谁还在运行、谁卡在等待人工确认、谁已经失联。挨个切换终端既打断思路，也容易把“最后一次报告的状态”误当成当前状态。
Weatherdeck 是一个自托管、只读的状态看板：多个来源把工作状态推送到你控制的主机，浏览器页面集中展示进展、待处理事项和失联来源。它不是 AI Agent，也不需要接入模型；更适合把现有工具的状态汇总到一个可查看的屏幕，而不是替代任务执行器或告警平台。
它解决的是“看见”，不是“控制”
Weatherdeck 的设计边界值得先说清楚：看板只读取状态，不会启动、暂停或修改 Agent，也不会主动发告警。每个来源通过 HTTP 推送 JSON feed；收到的推送可以用 weatherdeck received --diff 检查。来源停止上报时，条目会明确显示为静默/过期，而不是继续伪装成正常运行。对 Agent 编排系统而言，这种诚实的“未知”比一个看似绿色、实际陈旧的状态更有用。
它可以在电视或手机浏览器上打开同一页面。项目提供的演示数据是合成的，能够观察来源停止上报后的状态变化；真实环境则由你自己的工具或适配器持续推送。项目 README 将其定位为早期、未到 1.0 的业余软件，因此部署前应按自己的运行要求评估，并不要把它当作生产级监控系统。
五分钟启动：先看演示，再接入真实来源
项目要求 Python 3.9 至 3.14，不支持通过 pip install 安装；可以从仓库检出后运行。macOS/Linux 下，README 中的 weatherdeck 对应 python3 bin/weatherdeck，Windows 则使用 bin\weatherdeck.cmd。先启动合成演示：
python3 bin/weatherdeck run --demo
然后在浏览器打开 http://127.0.0.1:8787/。演示中有三个虚构来源，其中一个会停止报告，方便检查页面如何标记离线状态。确认界面符合预期后，可以在后台运行正式实例：
python3 bin/weatherdeck on python3 bin/weatherdeck status
status 会输出运行信息及数据目录；结束时执行 python3 bin/weatherdeck off。如需更换数据位置，可使用 --data DIR 或 WEATHERDECK_DATA。这些命令来自仓库 README 的 quickstart；请在仓库根目录运行，并以当前版本文档为准。
让现有工具上报一张状态卡
最简单的接入方式是在本机向默认地址提交一个 feed。下面是 README 给出的 lookout.feed 示例结构：
curl -X POST http://127.0.0.1:8787/api/ingest \
-H 'Content-Type: application/json' \
-d '{
"schema": "lookout.feed",
"schema_version": "1.0",
"source": { "id": "my-laptop" },
"items": [{
"id": "build",
"title": "Nightly build",
"state": "running"
}]
}'
这个请求把来源标识为 my-laptop，并提交一项正在运行的 Nightly build。lookout.feed 是项目保留的线上 schema 名称；虽然产品叫 Weatherdeck，接入时不要擅自把它改成 weatherdeck.feed。同一 feed 机制也可以由适配器周期性生成，让构建系统、Agent wrapper 或个人脚本把当前工作状态写进来。
若要在另一台设备查看，项目文档建议配置 hosts.bind，并为来源创建 token；一旦创建 token，推送请求就需要认证。不要为了方便把服务无保护地暴露到公网。先确认监听地址、网络边界和认证设置，再开放局域网或 VPN 访问。文档还提供配置文件及适配器说明，复杂接入应以 官方 README 和仓库内文档为准。
一个适合 Agent 团队的落地方式
可以先不改动 Agent 本身，而是在每个执行器外层加一个轻量状态上报步骤：任务开始时发 running，需要人工介入时发等待状态，完成后更新为完成；如果进程退出或心跳停止，看板则展示来源不再活跃。实际允许的状态字段应按项目 feed 规范核对，不能只凭这段示意文章推断完整 schema。
建议把状态粒度控制在“能帮助人决定下一步”的程度，例如仓库/任务名称、当前阶段、最近更新时间和是否需要人工处理。避免把提示词、源码片段、环境变量或访问令牌放进 feed。看板适合团队站立会、共享工作间或个人多 Agent 工作台：屏幕负责快速发现异常，人再跳转到原有终端和系统处理。它不负责策略执行、权限隔离、重试或通知，这些职责仍应留给现有编排和监控工具。
什么时候值得用
如果你只有一个本地 Agent，终端本身可能已经够用；如果你需要告警、指标保留、复杂查询或自动化响应，Weatherdeck 也不能代替成熟监控平台。它的吸引力在于简单：开源 MIT、Python 标准库实现、本地 SQLite 数据、浏览器页面、任意工具通过 HTTP 推送；无需模型调用，也不要求所有来源采用同一种 Agent 框架。
对并行开发来说，集中看板并不会让 Agent 自动更可靠，但能减少“我以为它还在跑”的盲区。先用演示确认失联状态呈现符合预期，再为一个低风险任务接入 feed，检查接收日志与数据暴露范围，最后才扩展到多个主机。这种渐进式接入比一开始把所有 Agent 状态和敏感上下文都汇总进去，更容易控制风险。
参考链接