当一个AI不够用的时候，就让五个AI组队。IfAI v0.4.1 正式发布多智能体协作系统——从数据模型到前端可视化，166个文件变更，48000行新增代码，12项核心Bug修复。
这个版本解决了什么问题
用过AI编程工具的开发者大概都经历过这个场景：你让AI"审查并优化这个模块"，它读了一遍代码，给了你一段建议，然后——就没了。
没有逐步分析，没有多角度审视，没有把问题拆解成可执行的任务。一个AI，一次思考，一份输出。这对简单需求够用，但面对真实的工程问题，单点思考的质量天花板很明显。
v0.4.1 的核心目标就是打破这个天花板：构建一个完整的多智能体协作系统，让不同专长的AI智能体像真正的开发团队一样接力工作。
先看整体架构：
┌─────────────────────────────────────────────────────────────────┐
│ IfAI v0.4.1 系统架构 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Tab A │ │ Tab B │ │ Tab C │ │ Tab D │ ... │
│ │ Session │ │ Session │ │ Session │ │ Session │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ ─────┴──────────────┴──────────────┴──────────────┴──── P4 隔离 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 消息队列 (双队列 + 优先级调度) │ │
│ │ ┌─────────────────┐ ┌─────────────────────┐ │ │
│ │ │ HIGH 工作流消息 │ │ NORMAL 普通聊天消息 │ │ │
│ │ └────────┬────────┘ └──────────┬──────────┘ │ │
│ └───────────┼────────────────────────┼────────────────┘ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ DAG 工作流引擎 (Rust / Tokio) │ │
│ │ │ │
│ │ ┌───────────┐ ┌───────────┐ ┌────────────┐ │ │
│ │ │ Explorer │───▶│ Reviewer │───▶│ Refactor │ │ │
│ │ │ (S/R/W) │ │ (A) │ │ (W) │ │ │
│ │ └───────────┘ └─────┬─────┘ └────────────┘ │ │
│ │ │ │ │
│ │ ┌──────▼──────┐ │ │
│ │ │TaskBreakdown│ │ │
│ │ └──────┬──────┘ │ │
│ │ │ │ │
│ │ ┌──────▼───────────┐ │ │
│ │ │ProposalGenerator │ │ │
│ │ └──────────────────┘ │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
│ ──────── 消息总线 ──────┼─────── P2 通信 ────────────────────── │
│ │ │
│ ┌───────────┐ ┌───────▼───────┐ ┌───────────┐ │
│ │ 点对点 │ │ 发布/订阅 │ │ 广播 │ │
│ │ P2P Direct│ │ Pub / Sub │ │ Broadcast │ │
│ └───────────┘ └───────────────┘ └───────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ WorkflowInlineMonitor (P3 前端) │ │
│ │ 内嵌聊天流 · SVG DAG图 · 节点状态实时更新 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 数据层 (P0 模型) │ │
│ │ Agent · Workflow · Message · Session · Node │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
亮点一：7130行代码浇筑的多智能体协作系统
整个协作系统分五个阶段逐步交付，每个阶段解决一层工程问题：
| 阶段 | 解决什么 | 规模 |
|---|---|---|
| P0 数据模型 | 定义智能体、工作流、消息的数据结构 | 1,200 行 / 20 测试 |
| P1 工作流引擎 | DAG调度、拓扑排序、并行执行 | 2,700 行 / 29 测试 |
| P2 通信系统 | 智能体间点对点、广播、发布订阅通信 | 1,720 行 / 21 测试 |
| P3 前端集成 | 聊天流内嵌监控器、DAG可视化 | 1,310 行 / 5 测试 |
| P4 标签页隔离 | 多Tab工作流完全隔离 | 200 行 / 4 测试 |
工作流引擎：DAG驱动的任务编排
核心是一个纯Rust实现的DAG工作流引擎。每个智能体是图中的一个节点，节点之间的边代表数据依赖关系。引擎通过拓扑排序确定执行顺序，无依赖的节点自动并行执行。
一次完整的 DAG 工作流执行过程如下：
用户输入: "审查 auth 模块性能"
│
▼
┌─────────────────────┐
│ WorkflowParser │
│ 解析为 DAG 图 │
└─────────┬───────────┘
│
▼
┌───────────────────────────────┐
│ 拓扑排序 · 识别可并行节点 │
└───────────────┬───────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Explorer │ │ Explorer │ │(无依赖 │
│ 扫描文件 │ │ 扫描依赖 │ │ 可并行) │
│ 结构 │ │ 关系 │ │ │
└────┬─────┘ └────┬─────┘ └──────────┘
│ │
└──────┬───────┘
▼ (上游全部完成，唤醒下游)
┌──────────────┐
│ Reviewer │
│ 代码审查 │
└──────┬───────┘
│
┌─────┴─────┐
▼ ▼
┌──────────┐ ┌──────────┐
│TaskBreak │ │(等待中) │
│down 拆解 │ │ │
└────┬─────┘ └──────────┘
│
▼
┌──────────┐
│Proposal │
│Generator │
└────┬─────┘
│
▼
┌──────────┐
│ Refactor │
│ 执行修改 │
└────┬─────┘
│
▼
┌───────────────┐
│ 汇总输出结果 │
│ 推送至消息总线 │
└───────────────┘
调度伪代码：
// 工作流调度核心逻辑
async fn execute_workflow(workflow: Workflow) -> Result<Output> {
let mut ready = topo_sort_ready(&workflow.dag);
while let Some(node) = ready.pop() {
// 所有上游依赖完成后才执行
if !deps_completed(&node) { continue; }
let input = collect_upstream_outputs(&node);
let result = agents[node.id].execute(input).await;
// 通过消息总线通知下游节点
message_bus.emit(node.id, result).await;
}
}
三种通信模式
智能体之间不是简单的"一问一答"，而是支持三种通信模式：
- 点对点：Reviewer 直接向 Explorer 请求代码分析结果
- 广播：工作流引擎向所有智能体发送状态变更通知
- 发布/订阅：智能体订阅感兴趣的主题（如 "security_audit"），相关消息自动推送
消息分为三类：数据消息（传递执行结果）、控制消息（暂停、恢复、终止）、状态消息（心跳、进度上报）。
亮点二：工作流内嵌监控器
工作流在后台跑，用户怎么知道执行到哪了？我们设计了 WorkflowInlineMonitor——直接内嵌在聊天消息流中的实时监控器：
- 每个智能体节点有独立的可视化标识（S=搜索 / R=读取 / W=写入 / A=智能体）
- 节点状态实时更新（等待中 → 执行中 → 已完成）
- DAG图用SVG渲染，支持流动动画展示数据流向
- 执行完成后3秒自动收起，不干扰后续对话
这意味着用户不需要切换到任何额外面板，在聊天窗口里就能看到整个智能体团队的工作过程。
亮点三：消息队列系统
在单智能体时代，消息处理很简单——用户发一条，AI回一条。但多智能体协作引入了一个新问题：当一条消息触发工作流执行时，后续消息怎么办？
v0.4.1 实现了双队列优先级调度系统：
用户消息输入
│
▼
┌─────────────┐ ┌─────────────────────────┐
│ 消息分类器 │ │ │
│ │──────▶│ 判断消息类型 │
└─────────────┘ └───────────┬─────────────┘
│
┌──────────────┼──────────────┐
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ HIGH PRIORITY │ │ NORMAL PRIORITY │
│ ┌──┐ ┌──┐ ┌──┐ │ │ ┌──┐ ┌──┐ ┌──┐ │
│ │W1│ │W2│ │ │ │ │ │M1│ │M2│ │M3│ │
│ └──┘ └──┘ └──┘ │ │ └──┘ └──┘ └──┘ │
│ 工作流消息队列 │ │ 普通聊天消息队列 │
└────────┬─────────┘ └────────┬─────────┘
│ │
│ ┌────────────────┐ │
└───▶│ 调度器 Dequeue │◀───────┘
│ │
│ HIGH 非空? │
│ ├─ YES → 取W1 │
│ └─ NO → 取M1 │
└───────┬────────┘
│
▼
┌─────────────────────┐
│ WorkflowEngine │
│ 或 ChatHandler │
│ 处理消息 │
└─────────────────────┘
调度伪代码：
// 消息优先级调度
interface MessageQueue {
highPriority: Queue; // 工作流消息 - 立即处理
normalPriority: Queue; // 普通聊天消息 - 排队等待
}
// 调度策略：高优先级队列清空后才处理普通队列
function dequeue(): Message | null {
if (highPriority.isNotEmpty()) {
return highPriority.pop();
}
return normalPriority.pop();
}
前端配套了 QueueIndicator 组件，实时显示队列状态——"处理中"、"2条等待"，高优先级消息用紫色主题和闪电图标区分。
亮点四：12项核心Bug修复
大功能之外，这个版本修复了12个影响日常使用的核心问题。其中最值得说的是消息持久化和线程隔离：
Tab消息隔离——一个折磨人的Bug
之前版本中，用户在Tab A对话，切到Tab B再切回来，发现Tab B的消息出现在了Tab A里。排查下来，根本原因是 switchThread 没有正确清空和加载消息，加上 Zustand 在 Vite 开发模式下会产生多个 store 实例，导致状态更新无法触发组件重渲染。
修复方案涉及四层：
- 重写
switchThread，添加isSameThread检查 - 修复 IndexedDB 版本冲突，移除硬编码
DB_VERSION - 自定义 Zustand persist 的
merge函数，防止 localStorage 覆盖内存数据 - 在
switchThread中同步更新 CoreStoreProxy 实例状态
工作流消息阻塞——一个架构级Bug
更棘手的是工作流处理期间的消息阻塞问题。一条消息进入工作流后，整个消息管道被占满，后续所有消息都无法处理——用户发什么都石沉大海。
消息队列系统的引入彻底解决了这个问题。工作流消息走高优先级通道，普通消息在低优先级队列排队，两者互不阻塞。
测试覆盖
44个E2E测试场景全部通过，覆盖率100%。其中新增的两个测试套件：
- tab-message-isolation.spec.ts：6个场景覆盖消息隔离——基础隔离、空线程清空、DOM一致性验证、快速连续切换、5次往返稳定性测试
- message-queue-indicator.spec.ts：5个场景覆盖队列UI——状态显示、排队计数、优先级标识、内容预览截断
数据全貌
| 指标 | 数值 |
|---|---|
| 变更文件 | 166 个 |
| 新增代码 | ~48,000 行 |
| 协作系统核心 | ~7,130 行 |
| 测试用例 | 79 个 |
| E2E通过率 | 44/44 (100%) |
| Bug修复 | 12 项 |
| 新功能 | 8 项 |
写在最后
v0.4.1 是 IfAI 从"单智能体编辑器"进化为"多智能体协作平台"的关键一步。7130行协作系统代码、12项核心修复、8项新功能——这个版本的每个数字背后都是大量工程决策和取舍。
下一步我们会开放工作流YAML自定义能力，让用户可以定义自己的智能体编排逻辑。多智能体协作的潜力远未被完全释放。
- GitHub: github.com/peterfei/if…
- Windows 下载: Microsoft Store
欢迎 Star、Issue 和 PR，一起推动 AI 编程工具的进化。
关键词：AI编辑器、多智能体协作、DAG工作流、消息队列、Tauri、Rust
