多 Agent 并行任务编排：拆分、汇总与边界

背景

单线程 Agent 适合「读一点、改一点、再验证」的短闭环。一旦需求变成「同时改前端与后端契约」「一边写迁移一边补 E2E」「多模块并行调研」，串行等待会明显拖慢吞吐。行业里常见的做法是：把总目标拆成可并行的子任务，每个子任务绑定独立工作区或独立上下文，最后由编排层汇总状态与产物。

这不是「多开几个聊天窗口」这么简单。并行带来的工程问题包括：文件冲突、重复劳动、权限漂移、以及子任务空转烧 token。0xKEV 这类静态站本身不跑 Agent，但本地工具（JSON、Diff、Markdown）正好用来整理任务清单与合并结果，再交给你的编排器。

要点

维度	建议	反模式
任务图	显式 DAG：依赖边、产物路径、完成条件	口头「大家一起改」
权限	每线程最小特权；写路径白名单	共享同一生产凭证
进度	结构化状态（queued / running / done / failed）	只靠聊天滚动条
用量	子任务预算、超时、禁止无限重试	失败即重启到烧光配额

并行的价值在于 独立 I/O 与独立上下文；若子任务频繁抢同一文件或同一锁，收益会迅速被冲突成本吃掉。

怎么做

1. 写清拆分规格：每个子任务一份短文档：目标、输入路径、允许修改的路径、禁止触碰的路径、验收命令（测试 / 构建 / lint）。
2. 隔离工作区：能用 git worktree / 独立目录就用；至少保证并行写不落到同一热点文件。
3. 进度汇总协议：约定 JSON 状态文件或看板字段，例如 {"id":"t3","status":"done","artifacts":["a.diff"]}，由编排器轮询合并。
4. 冲突策略：同一文件只允许一个写者；只读共享目录给调研线程；合并阶段再开 Diff 评审。
5. 用量控制：单任务最大步数 / 最大 token；失败计入 failed 并人工介入，而不是自动无限分叉。

伪流程：

总规格 → 拆成 N 个子任务规格 → 并行执行（各有路径白名单）→
状态 JSON 汇总 → Diff/评审 → 合并主线 → 跑总验收

规则文件（如仓库级 agent 指南）应写明：并行默认只读外网、禁止发生产请求、敏感路径需审批。这样编排层才能在工具调用前拦截，而不是事后补救。

和本站工具

• JSON 格式化：整理任务状态与工具返回。
• 文本 Diff：合并前对比子任务产物。
• Markdown 预览：审阅拆分规格与验收清单。
• UUID：给子任务生成稳定 id，避免文件名撞车。

入口：Tools 首页。数据默认在浏览器本地处理，适合粘贴脱敏后的状态片段。

再补一层工程习惯：把「编排器」与「执行器」分开配置。编排器只负责拆任务、收状态、触发合并；执行器拿最小工具集。这样即使某个执行器被过度授权，也不会自动获得创建子任务或改总规格的能力。进度面板用只读视图给人类看，写操作仍走 Git 与代码评审。

用量方面，建议每周导出一次会话级统计：任务数、平均步数、失败原因分布。若「搜索无果后重启」占比过高，优先改规格与检索策略，而不是加并行度。并行是放大器——放大的是好流程，也是坏流程。

小结

多 Agent 编排的核心是 可合并的并行：显式任务图、路径级权限、结构化进度、预算上限。先把规格与边界写清楚，再用本站本地工具整理 JSON / Diff，最后才谈模型选型和花哨调度。