备选标题（按吸引力排序）
- 同时跑5个AI Agent，我是怎么知道哪个已经悄悄崩了的
- 多Agent并行开发踩坑：不加状态监控，你迟早会在凌晨重跑一个早就挂掉的任务
- 给自己的AI Agent加个「心跳」，30行Python搞定最小状态看板
---
上周我同时开了四个编程Agent，分别处理不同模块的任务。过了两个小时回来一看——终端一片寂静，不知道哪个跑完了、哪个卡住了、哪个其实早就报错退出了。
我以为都在跑，结果有两个已经静默失败了将近一个小时。
这种感觉很糟糕。不是因为任务失败，而是你完全不知道发生了什么。
这个问题比你想象的更普遍
社区里有人专门做了一个叫 iterm-agents 的 iTerm2 侧边栏面板，就是为了解决「同时开几个编程Agent时，要知道哪个还在跑、哪个刚结束」这个问题——通常得来回看终端，这个面板把会话状态集中放在一起，点一下跳到对应窗格。支持 Claude Code、Codex、Cursor Agent 等主流工具。
这说明什么？说明这个痛点真实存在，而且已经有人忍不住自己动手解决了。
但 iTerm2 面板只适合 Mac 用户，而且只能看「当前终端会话」的状态。如果你的 Agent 是通过 API 调用、后台脚本或者异步任务跑的，这个方案根本帮不上忙。
我想要的其实很简单
不需要一个完整的监控系统。我只需要知道三件事：
- 这个任务现在是 running、done 还是 failed？
- 它是什么时候开始的、最后一次更新是什么时候？
- 如果失败了，错误信息是什么？
这三件事用一张 SQLite 表就能存下来。
最小可用方案：Python轮询 + SQLite记录
思路很直接：每个 Agent 任务启动时，往数据库里写一条记录，状态设为 `running`；任务结束时更新状态为 `done` 或 `failed`；中间每隔一段时间更新一次 `last_heartbeat` 字段。
表结构大概长这样：
CREATE TABLE agent_tasks (
id TEXT PRIMARY KEY,
name TEXT,
status TEXT, -- running / done / failed
started_at TEXT,
last_heartbeat TEXT,
error_msg TEXT
);然后写一个轮询脚本，每30秒检查一次：如果某个任务的 `last_heartbeat` 超过5分钟没更新，就把它标记为 `timeout`。这样即使 Agent 进程直接崩掉、没有机会写 `failed`，你也能发现它。
用Python在线运行可以快速验证这个轮询逻辑是否正常工作，不用在本地搭环境。
看板不需要花哨，能看懂就行
我最开始想做一个 Web 界面，后来发现完全没必要。直接用SQLite编辑器打开数据库文件，按 `status` 排序，一眼就能看到哪些任务还在跑、哪些已经完成、哪些超时了。
这就够了。真的够了。
几个容易忽略的细节
**心跳更新要在 Agent 内部做，不能只靠外部轮询。 ** 外部轮询只能发现「很久没更新」，但不知道任务是卡住了还是在正常处理一个耗时操作。
Agent 内部每隔一段时间主动写一次心跳，才能区分这两种情况。
**失败信息要写进去，不能只记状态。 ** 只知道「failed」没用，得知道为什么 failed。
把 exception 的 traceback 截取前500个字符写进 `error_msg`，下次排查快很多。
**不要用进程 PID 作为任务唯一标识。 ** PID 会复用，重启后可能撞上旧记录。
用 UUID 或者时间戳加任务名的组合更稳。
这套方案的边界在哪里
说真的，这不是一个「监控系统」，它是一个「让自己心里有底」的最小工具。如果你同时跑的 Agent 超过20个、任务之间有复杂依赖、需要告警推送，那就超出这套方案的范围了，得考虑更完整的任务队列方案。
但对于大多数独立开发者来说，同时跑3到8个 Agent、需要知道大概状态——这套东西完全够用，而且一个下午就能搭起来。
别等到凌晨才发现有个 Agent 两小时前就挂了。