AI多Agent协作系统实战（二十二）：从6列到12列——任务监控报告的进化之路
系列第22篇 | 当你发现"能看到进度"和"能处理异常"是两回事
背景
我们的AI Agent多系统协作平台，每天都在跑任务。小虾写代码、小牛测试、小密复核。看起来很完美，但有一个致命问题——我看不到任务卡在哪里了。
最早的报告长这样：
| 任务ID | 完善内容 | 开发 | 测试 | 复核 | |--------|----------|------|------|------| | DEV-001 | 修复xxx | ✅ | ⏳ | - |6列，简洁明了。但用了一天就发现：测试卡了2小时，我完全不知道。
问题1：超时是"黑箱"
现象
小牛测试一个任务，我等了2小时没动静。打开报告一看：
| DEV-001 | 修复xxx | ✅ | ⏳ | - |只显示"⏳进行中"，不知道卡了多久。
原因
报告只记录了状态（进行中/已完成），没有记录时间维度。就像看外卖APP只显示"配送中"，但看不到骑手离你还有多远。
修复
给每个阶段加上超时时间：
| 开发状态 | 开发超时 | 测试状态 | 测试超时 | 复核状态 | 复核超时 | |----------|----------|----------|----------|----------|----------| | ✅ | - | ⏳ | 120分钟 | - | - |现在一眼就能看到：测试已经卡了120分钟。
问题2：重试次数是"黑洞"
现象
任务复核不通过，系统自动重试。但我不知道重试了几次，也不知道还能重试几次。
就像打客服电话，只告诉你"正在转接"，但不知道转了几轮、还要转多久。
原因
没有记录retry_count。系统默默重试，用户一无所知。
修复
给每个阶段加上重来次数：
| 测试状态 | 测试超时 | 测试重来 | 复核状态 | 复核超时 | 复核重来 | |----------|----------|----------|----------|----------|----------| | ⏳ | 120分钟 | 2 | ❌ | - | 1 |现在能看到：测试重试了2次，复核失败1次。
问题3：报告"刷屏"
现象
任务完成后，报告每分钟都在发同一条消息。飞书被刷屏了。
【小密统筹报告 07-22 14:00】✅ 共1个任务全部通过 【小密统筹报告 07-22 14:01】✅ 共1个任务全部通过 【小密统筹报告 07-22 14:02】✅ 共1个任务全部通过 ...连续发了3小时原因
没有"报告标志"机制。每次生成报告都显示所有任务，包括已完成的。
就像快递APP每5分钟通知你"您的包裹已签收"，签收了100次。
修复
添加reported字段：
# 报告后设置reported=1db.execute('''UPDATE tasks SET reported=1 WHERE msg_type='new_task' AND reported=0 AND status IN ('verified','completed')''')报告只显示reported=0的任务。完成后标记为1，不再重复显示。
问题4：空闲时"瞎忙"
现象
没有任务的时候，报告还是每分钟发一次空报告。飞书被空消息刷屏。
原因
没有"空闲暂停"机制。不管有没有任务，都按时生成报告。
就像冰箱里的便签纸，不管你有没有看，每小时自动换一张新的。
修复
添加空闲检测：
defcheck_idle_and_pause():# 检查是否有活跃任务active=db.execute('''SELECT COUNT(*) FROM tasks WHERE status NOT IN ('archived', 'cancelled', 'verified') ''').fetchone()[0]ifactive==0:# 空闲超过30分钟，暂停ifidle_seconds>=30*60:returnTrue# 暂停returnFalse# 继续没有任务时，30分钟后自动暂停报告。
问题5：结论"撒谎"
现象
报告说"共6个任务，2个失败"，但我明明只看到2个DEV任务在表格里。
原因
结论统计包含了TEST/RETEST任务，但表格只显示DEV任务。数字对不上。
就像超市小票显示"共10件商品"，但袋子里只有2件——另外8件是赠品小样。
修复
结论只统计DEV任务：
# 只统计DEV任务ifnottid.startswith(('FIX-','DEV-','REDEV-')):continue现在结论和表格一致。
最终形态
从6列进化到12列：
| # | 任务ID | 完善内容 | 开发状态 | 开发超时 | 开发重来 | 测试状态 | 测试超时 | 测试重来 | 复核状态 | 复核超时 | 复核重来 | |---|--------|----------|----------|----------|----------|----------|----------|----------|----------|----------|----------| | 1 | DEV-001 | 修复xxx | ✅ | - | - | ⏳ | 120分钟 | 2 | ❌ | - | 1 |每个阶段都有：状态（做什么）+超时（卡了多久）+重来（重试了几次）。
一眼就能看出：任务卡在测试阶段，已经120分钟，重试了2次还没过。
规范驱动
这个进化不是拍脑袋想的，而是来自用户定义的规范文件：
/vol1/1000/workspace/file/规范/ ├── agent工作内容.jpeg # 谁做什么 ├── 统筹内容要求.jpeg # 报告要包含什么 ├── 统筹报告格式.jpeg # 报告长什么样 └── 脚本编制要求.jpeg # 脚本怎么写用户说"对标规范"，我就去查这些文件，然后对照当前实现纠偏。
规范是权威来源，不是参考意见。
经验总结
- 状态≠进度：只知道"进行中"不够，还要知道"卡了多久"
- 记录时间维度：每个阶段都要记录超时时间和重试次数
- 报告标志防刷屏：已完成的任务标记reported=1，不再重复显示
- 空闲暂停：没有任务时自动暂停，避免空消息刷屏
- 结论要对得上数字：统计范围要和表格显示范围一致
- 规范驱动开发：先定义规范，再实现，最后对标检查