AI虚拟团队自动化进化：从“人盯人“到“自愈系统“

一句话总结前三篇讲了架构、踩坑、通信。这篇讲实战进化——系统怎么从人工调度一步步变成能自动发现问题、自动修复、自动重试的自愈系统。核心是一个字闭环。 前情回顾第一篇我用4个AI搭了一个虚拟开发团队——架构overview第二篇AI虚拟团队跑了一个月我踩了这些坑——Agent撒谎、Gateway崩溃、任务卡死第三篇AI虚拟团队的神经系统——消息总线、心跳检测、自动派发这一篇讲从第三篇的能跑到真正好用之间我做了哪些进化。 问题一心跳在跑但超时任务没人管现象心跳每分钟跑一次检测到任务超时5分钟报告里写着⏰ 小虾/FIX-xxx 超时11分钟——然后呢什么也没发生。报告发给我看了但系统不会自动处理。我还是得手动去唤醒小虾、取消旧任务、重新派发。根因心跳脚本的超时处理只做了诊断没做修复# 旧代码只ping一下然后重发消息defdiagnose_and_fix_timeout(agent,task_id,elapsed):resultsubprocess.run([openclaw,agent,--agent,agent_id,-m,ping,--timeout,15000])ifresult.returncode0:# 重新发消息...但没清理旧状态subprocess.run([openclaw,agent,--agent,agent_id,-m,content,--timeout,120000])returnTrue,重新派发任务问题没取消DB里的旧任务记录status还是pending没清理inbox里的旧文件新消息和旧消息混在一起没通过正式流程重新派发直接发消息不写DBAgent可能根本没收到消息堆积在inbox里修复4步完整流程defdiagnose_and_fix_timeout(agent,task_id,elapsed):诊断超时原因并自动修复取消旧任务 → 清理inbox → 重新派发 → 唤醒Agent# Step 1: 取消旧DB记录dbsqlite3.connect(TASKS_DB,timeout5)db.execute(UPDATE tasks SET statuscancelled WHERE task_id? AND statuspending,(task_id,))db.commit()db.close()# Step 2: 清理旧inbox文件保留.doneinbox_dirf{SYNC_DIR}/inbox/{agent_id}forfinos.listdir(inbox_dir):iftask_idinfandf.endswith(.json)andnotf.endswith(.done):os.remove(os.path.join(inbox_dir,f))# Step 3: 重新派发通过send_task.py正式流程subprocess.run([sys.executable,send_task.py,小密,agent,task_id,1,f超时重派:{task_id}])# Step 4: 唤醒Agentsubprocess.run([openclaw,agent,--agent,agent_id,-m,ping,--timeout,15000])关键变化从诊断重发消息变成取消→清理→正式派发→唤醒。每一步都有副作用但每一步都是必要的。 问题二Agent完成了但测试没自动派发现象小虾完成开发任务.done文件有了但小牛没收到测试任务。我得手动写测试MD、手动派发。根因自动派发逻辑auto_dispatch_tests_for_completed_dev()本身没问题——它会扫描小虾inbox的.done文件检查小牛inbox有没有对应的TEST-{task_id}文件没有就自动派发。问题出在触发时机我直接用openclaw agent --agent main -m 执行任务唤醒小虾小虾执行完创建了.done文件但心跳没运行或者在grace period内自动派发逻辑没机会执行为什么心跳没运行心跳有个grace period机制——每次唤醒Agent后180秒内跳过某些操作避免重复。但这个机制太粗暴把自动派发也一起跳过了。而且更根本的问题是我绕过了心跳流程。直接openclaw agent执行任务心跳根本不知道发生了什么。教训自动化系统的每条路径都必须经过同一个中枢。不能有后门——即使你是管理员。否则中枢的自动逻辑就形同虚设。 问题三报告格式说一套做一套现象心跳报告显示✅ 所有任务已完成但下面还有一堆注意事项。或者报告里有 自动创建测试待办: TEST-xxx这行字但不在注意事项区域而是单独出现在报告上方。根因两个独立的bug逻辑矛盾当有notes时报告仍然显示✅ 所有任务已完成输出位置错误ensure_test_todos_exist()直接print()到stdout显示在报告上方而非注意事项区域内修复# 修复1有notes时不显示全部完成iftotaldoneandnotnotesandnottimeout_tasks:lines.append(✅ 所有任务已完成)# 修复2把print改成返回notes列表defensure_test_todos_exist(replies):msgs[]forreplyinreplies:# ... 检查逻辑 ...msgs.append(f 自动创建测试待办: TEST-{task_id})returnmsgs# 返回列表由heartbeat收集到notes# heartbeat中notes.extend(auto_pipeline.ensure_test_todos_exist(replies))notes.extend(auto_pipeline.ensure_fix_todos_exist(replies))关键原则所有用户可见的信息必须经过同一个格式化函数。不能有旁路输出。 闭环设计的核心模式经过这几轮迭代我总结出一个自愈闭环的标准模式┌─────────────────────────────────────────────────┐ │ 心跳中枢 │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ 检测状态 │→│ 自动决策 │→│ 执行动作 │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ ↑ ↓ │ │ ┌──────────┐ ┌──────────┐ │ │ │ 收集结果 │←────────────────│ 通知用户 │ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────────────────────────┘4个必要环节环节作用缺失后果检测状态扫描inbox、DB、.done文件不知道发生了什么自动决策判断该做什么重试/派测试/归档检测到了但不处理执行动作取消旧任务、派发新任务、唤醒Agent决策了但没执行通知用户汇报结果和异常执行了但用户不知道每个环节的常见坑环节坑解法检测检测到但被grace period跳过grace只跳过唤醒不跳过核心逻辑决策决策正确但走了旁路直接print所有输出必须经过统一的format函数执行执行了但状态没同步DB和inbox不一致每个操作都有对应的状态清理通知通知了但信息矛盾已完成和有警告同时出现互斥信息不能同时显示 进化前后的对比指标v1 手动调度v2 基础心跳v3 自愈闭环超时处理手动唤醒报告超时自动取消重派测试派发手动写MD派发手动自动检测补派报告准确性N/A偶尔矛盾严格一致人工干预频率每个任务2-3次偶尔~30%极少~5%系统死的概率高中低 给想做类似系统的人的建议闭环必须完整检测→决策→执行→通知缺一不可。缺了执行就是空谈缺了通知就是黑盒。不要有旁路所有操作必须经过同一个中枢。你手动操作一次就可能绕过自动逻辑一次。状态必须一致DB里的状态、inbox里的文件、.done标记三者必须同步。任何一个不一致都会导致幽灵任务。报告不能自相矛盾用户看到的每一行信息都必须是真实状态的反映。已完成和有警告不能同时出现。grace period要精细不能一刀切跳过所有操作。应该只跳过重复唤醒不跳过核心逻辑。自动化的代价是复杂度每加一个自动逻辑就多一个可能出bug的地方。但不出bug的自动化不叫自动化叫脚本。如果这篇文章对你有帮助欢迎点赞收藏。有问题可以在评论区交流。