Fugu 式 Agent 分层架构计划书
目标：Manas（总指挥）+ Alaya（中层）+ Hermes 子 agent（弹性工人）+ Windows Extra 参考：SakanaAI/fugu 的 LLM pool 与动态协调思路。下面的 Coordinator/Thinker/Worker/Verifier 是本地角色设计，不是官方固定四角色架构。 2026-10-09：官方 README 介绍 TRINITY（协调器逐轮委派三类角色）与 Conductor（强化学习训练的协调器）。本文是 Hermes 分层提案；原有“已完成”是当时记录，本次未验证 NATS 注册、广播或递归调度已部署。
一、角色体系（本地设计参考 Fugu）
| Fugu 角色 | 咱们的映射 | 职责 |
|---|---|---|
| Coordinator | Manas | 分解任务、判断路由、合并结果、全局决策 |
| Thinker | delegate_task 子 agent（推理型） | 制定方案、分析问题、研究调研 |
| Worker | delegate_task 子 agent（执行型） | 编码、文件操作、脚本执行 |
| Verifier | delegate_task 子 agent（审计型） | 审核结果、查错、质量把关 |
| 中层管理 | Alaya | WSL 运维、gbrain 记忆、协调子 agent |
| 外部 Worker | Mano/Anchor | Windows 桌面操作、进程监控（可选 extra） |
| LLM Pool | OpenCode Go + DeepSeek + 其他 | 按任务类型选模型 |
二、Agent 层级树
┌────────────────────────────┐
│ User/你 │
└────────────┬───────────────┘
│ Discord / API
▼
┌──────────────────────────────────────────────────────────┐
│ Layer 1: Manas（Coordinator） │
│ ┌────────────────────────────────────────────────────┐ │
│ │ 内置能力： │ │
│ │ - 任务分解（拆成子任务） │ │
│ │ - 路由决策（自己做 / Alaya / 子 agent） │ │
│ │ - 结果合并与去重 │ │
│ │ - 全局状态追踪 │ │
│ │ - 自省（发现不对就重做） │ │
│ └────────────────────────────────────────────────────┘ │
└────────────────────────┬─────────────────────────────────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌──────────┐ ┌──────────────┐
│ Layer 2: Alaya │ │ Hermes │ │ Windows Extra│
│ 中层管理 │ │ 子 agent │ │ (可选) │
│ │ │ (弹性) │ │ │
│ WSL 运维巡检 │ │ Thinker │ │ Mano │
│ gbrain 记忆 │ │ Worker │ │ Anchor │
│ cron 调度 │ │ Verifier │ │ │
│ 也可派子agent │ │ │ │ NATS 通信 │
└────────────────┘ └──────────┘ └──────────────┘
关键特性：每层都能派子 agent
- Manas 可以派子 agent：研究、编码、验证
- Alaya 也可以派子 agent：运维脚本、记忆分析
- Mano/Anchor 如果有能力也可以
- 这是本方案希望实现的递归委派能力；不能仅凭 Fugu 引用证明每个 Hermes agent 已具备这种能力
三、任务生命周期（本地提案流程）
用户请求
│
▼
┌──────────────────────────────────────────────────────────┐
│ Phase 1: 分解（Manas） │
│ "这个任务需要：研究A + 编码B + 验证C" │
│ 判断：哪些自己做？哪些给 Alaya？哪些派子 agent？ │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ Phase 2: 分配 │
│ ├─ 给 Alaya → Alaya 自己决定怎么干（可再分解） │
│ ├─ 给子 agent（Thinker → 先出方案） │
│ ├─ 给子 agent（Worker → 执行方案） │
│ └─ 给 Windows Extra（Mano/Anchor） │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ Phase 3: 执行（各层级并行） │
│ - Manas 追踪所有子任务的进度 │
│ - 超时/失败 → 重试或换人 │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ Phase 4: 验证（Verifier） │
│ - 每个子任务结果出来后，先审计再合并 │
│ - 发现错误 → 打回重做 │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ Phase 5: 合并（Manas） │
│ - 去重、排序、结构化 │
│ - 输出最终结果给用户 │
└──────────────────────────────────────────────────────────┘
四、如何增加新 Agent
路径 A：核心 Agent（WSL/Linux 层）
加入 Layer 2，归 Alaya 管或并列：
新 Agent 加入条件：
- 有独立 Hermes gateway（持续运行）
- 连接 NATS（agent.dm.{agent_id}）
- 遵循自治协议（ACK/重试/升级链）
- 注册到 Alaya 的管辖列表
示例：加入一个 search-agent 专门做搜索调研
注册流程：
1. 启动 gateway → NATS 上线
2. Alaya 检测到新 agent → 确认身份
3. 给搜索 agent 第一个任务 → 验证能力
4. 正式加入 agent_registry
路径 B：Extra Agent（Windows 或其他平台）
加入 Windows Extra 层，归 Mano 管或独立：
1. 通过 NATS 连接核心架构
2. 声明自己的能力标签（tags: [windows, file, browser]）
3. 核心架构按需调用
4. 不依赖核心架构的可用性
路径 C：临时子 agent（Hermes delegate_task）
不持久，用完即销毁：
Manas 调用 delegate_task():
- goal: "研究 X 技术"
- toolsets: [web, terminal]
- 这就是一个临时的 Thinker
或：
- goal: "写一个 Python 脚本做 Y"
- toolsets: [terminal, file]
- 这就是一个临时的 Worker
五、LLM Pool 策略（本地设计参考 Fugu）
Fugu 有一个 LLM 池，根据任务类型选模型。我们也应该做：
任务类型 → 推荐模型 → 理由
────────────────────────────────────────────────
简单查询/回复 → deepseek-v4-flash → 快、便宜
复杂推理/分析 → deepseek-v4 → 更强推理能力
编码/执行 → deepseek-v4-flash → 够用且快
审计/验证 → deepseek-v4 → 需要严格
研究/调研 → 同上 + web 工具 → 需要联网
创意/生成 → 按需 → 需要时再选
每个 agent 在派子 agent 时应该显式指定模型：
delegate_task(
goal="...",
model="deepseek-v4-flash", # 显式选模型
toolsets=[...]
)
六、实施步骤
Phase 1：地基（本周）
| # | 事项 | 谁做 |
|---|---|---|
| 1 | Agent 自治协议广播 & 落地 | Manas 已完成 ✅ |
| 2 | NATS Platform Plugin（即时响应） | Manas 在建中 |
| 3 | 2m NATS 消息 cron（临时方案） | Manas 已完成 ✅ |
Phase 2：Fugu 化（接下来）
| # | 事项 | 说明 |
|---|---|---|
| 4 | 任务分解标准化 | Manas 派活前先走 Thinker→Worker→Verifier 流程 |
| 5 | Verifier 角色建立 | 子 agent 结果出来后先审计再给你 |
| 6 | Alaya 升级为中层管理 | 授权 Alaya 可以派自己的子 agent |
| 7 | LLM Pool 策略 | 按任务类型选模型 |
| 8 | 结果合并协议 | 多子任务结果去重、结构化输出 |
Phase 3：扩展
| # | 事项 | 说明 |
|---|---|---|
| 9 | 新 Agent 加入流程 | 标准化的注册/验证/上线流程 |
| 10 | Windows Extra 解耦 | Mano/Anchor 作为可选模块接入 |
| 11 | 递归能力 | 任何 agent 在需要时都可以派子 agent |
七、不做的（边界）
- ❌ 不做一个完整的 Fugu 重实现（我们用的是 Hermes，不是 Fugu）
- ❌ 不引入分布式共识算法（Paxos/Raft）
- ❌ 不改变现有的 NATS 基础设施
- ❌ 不让用户直接调用子 agent（所有请求走 Manas → 层级路由）