EvoX 蜂群模式
设计与实战验证报告

EvoX 论文的核心发现指出：同一模型、同一任务，组织方式不同，结果天差地别。当问题被拆成多个独立 slot 并行求解，再由确定性程序汇合时，准确率可达 70.7%；而让 LLM 扮演“Sub-Agent”互相传递结果，准确率跌至 38.5%；传统的单上下文模式只有 26.3%。

数据背后的关键事实：Sub-Agent 模式虽然看起来更接近“智能体协作”，却丢失了 166 个正确答案，答案保留率仅 55.5%。这意味着接近一半的可用信息在传递过程中被改写、压缩或误读。

根本原因：LLM 在传递链路上做“重新理解”

LLM 不是无损信道。当一个 Agent 把结果“总结”给下一个 Agent 时，它实际上在进行新一轮的推理与生成。这一行为会引入三层损耗：

• 语义漂移（Semantic Drift）：关键词、约束条件、数值精度在转述中被改写。
• 上下文压缩（Context Loss）：为了塞进下一段 prompt，中间结果被迫截断，细节不可逆丢失。
• 幻觉注入（Hallucination Injection）：Sub-Agent 会基于自己的理解“补全”缺失信息，产生原本不存在的结论。

因此，优化的首要目标不是让 LLM 更好地“传递”，而是把 LLM 从传递链路中移除。

在动手写代码之前，先确立三条不可再约的公理和一条奥卡姆剃刀。

• 公理 A：LLM 是推理 + 生成引擎，不是传递 + 汇总引擎。它的价值在“第一次思考”时最大；让它反复搬运中间结果，只会放大误差。
• 公理 B：上下文窗口稀缺，污染不可逆。每引入一段非必要上下文，都会稀释有效信号；一旦污染，无法通过后续 prompt 完全洗回。

奥卡姆剃刀

切掉 LLM 在传递链路中的位置。能由程序搬运的数据，绝不经过 LLM；能由文件系统承载的状态，绝不塞进 prompt。

三条工程约束

1. 原子化 + 稳定 ID：每个 slot 只负责一个最小可交付单元，拥有全局唯一、可重入的 slot_id。
2. 执行隔离：slot 之间只通过文件/JSON 交换数据，Worker 进程互不阻塞，失败可独立重试。
3. 程序化汇合：最终组装必须是确定性程序（Python Collector），而非让 LLM 再次“读一遍然后写一遍”。

整体数据流

Claude Code 只负责“拆解”与生成 task_map.json；Hermes 只负责按依赖调度；每个 Worker 只写自己的 slot 文件；Collector 按顺序拼接并校验；最终验证程序确认完整性。

task_map.json schema

{
  "project": "pmo-platform-report",
  "slots": [
    {
      "slot_id": "css-base",
      "file_path": "parts/css-base.html",
      "dependencies": [],
      "parallel_group": "wave-1",
      "description": "CSS variables + base typography"
    },
    {
      "slot_id": "css-components",
      "file_path": "parts/css-components.html",
      "dependencies": [],
      "parallel_group": "wave-1",
      "description": "Component CSS + responsive rules"
    },
    {
      "slot_id": "assembly",
      "file_path": "index.html",
      "dependencies": ["css-base", "css-components", "..."],
      "parallel_group": "wave-5",
      "description": "Deterministic full assembly"
    }
  ],
  "max_parallel_workers": 3,
  "collector": "scripts/assemble.py"
}

与 project-blueprint 的关系

在既有 project-blueprint 工作流中，本架构替换的是阶段三“实现”。原本由单一长上下文 LLM 逐步编码的阶段，被替换为：

1. 阶段 3a：拆解 → Claude Code 输出 task_map.json 与 slot 清单。
2. 阶段 3b：蜂群执行 → Hermes + Worker swarm 并行完成所有 slot。
3. 阶段 3c：程序化汇合 → Python Collector 组装、验证、输出最终产物。

文件位置：~/.hermes/skills/software-development/swarm-execution/SKILL.md

该 skill 把蜂群模式封装成可复用的执行协议。它不关心业务逻辑，只关心“如何把一个大任务切小、并行执行、再安全地拼回来”。

5 步执行流程

1. 环境准备：创建 parts/ 目录，校验目标路径，初始化状态文件。
2. 拆解（Decompose）：Claude Code 读取完整需求，输出 task_map.json 与每个 slot 的规格。
3. 确认闸门（Approval Gate）：人类确认 slot 清单、依赖与并行分组； skill 只在通过后才启动 Worker。
4. Worker 执行：Hermes 按 wave 与 max_parallel_workers 调度 Claude Code Worker，每个 Worker 只写自己的 slot 文件。
5. 汇合与验证：Collector 拼接所有 slot，验证大小、标签、结构，输出最终产物。

关键特性

目标

将一个 61 KB 的单文件 HTML 报告，按功能边界拆成 11 个独立 slot，通过蜂群模式并行重建，最终由 Collector 组装为完整页面。

拆解方案

执行时间线

验证不是为了证明“没有 bug”，而是主动寻找“哪里可能丢失信息”。以下 10 项验证覆盖了结构、内容、运行时、安全性四个维度。