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字段：

python 复制代码

# 报告后设置reported=1
db.execute('''UPDATE tasks SET reported=1 
    WHERE msg_type='new_task' 
    AND reported=0 
    AND status IN ('verified','completed')''')

报告只显示reported=0的任务。完成后标记为1，不再重复显示。

问题4：空闲时"瞎忙"

现象

没有任务的时候，报告还是每分钟发一次空报告。飞书被空消息刷屏。

原因

没有"空闲暂停"机制。不管有没有任务，都按时生成报告。

就像冰箱里的便签纸，不管你有没有看，每小时自动换一张新的。

修复

添加空闲检测：

python 复制代码

def check_idle_and_pause():
    # 检查是否有活跃任务
    active = db.execute('''SELECT COUNT(*) FROM tasks 
        WHERE status NOT IN ('archived', 'cancelled', 'verified')
    ''').fetchone()[0]
    
    if active == 0:
        # 空闲超过30分钟，暂停
        if idle_seconds >= 30 * 60:
            return True  # 暂停
    return False  # 继续

没有任务时，30分钟后自动暂停报告。

问题5：结论"撒谎"

现象

报告说"共6个任务，2个失败"，但我明明只看到2个DEV任务在表格里。

原因

结论统计包含了TEST/RETEST任务，但表格只显示DEV任务。数字对不上。

就像超市小票显示"共10件商品"，但袋子里只有2件------另外8件是赠品小样。

修复

结论只统计DEV任务：

python 复制代码

# 只统计DEV任务
if not tid.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，不再重复显示
空闲暂停：没有任务时自动暂停，避免空消息刷屏
结论要对得上数字：统计范围要和表格显示范围一致
规范驱动开发：先定义规范，再实现，最后对标检查