Multi-Agent Orchestration v0.04
架构
Alaya（指挥官 + 研究员）← 当前执行面
├── 看板 → 编排员（alaya 自营）
│ ├── Swarm（并行 Worker → Verifier → Synthesizer）✅ 已验证
│ ├── Decompose（自动拆分成子任务）✅ 支持
│ └── 单 Worker ✅ 已验证
└── 直接执行（terminal/脚本）
看板系统现状
| 组件 | 状态 | 说明 |
|---|---|---|
Board alaya-workers | ✅ | 已创建，7 个已完成任务，0 积压 |
| Dispatcher | ✅ | 内嵌在 gateway 运行，60s 轮询 |
| Swarm | ✅ | Worker→Verifier→Synthesizer 全流程成熟 |
| Decompose | ✅ | 自动分拆任务给 specialist |
| Single worker | ✅ | 16s 完成一次系统检查 |
| Human-in-loop | ✅ | 可 comment/unblock 随时介入 |
| 多 Board 隔离 | ✅ | 每个 board 独立 SQLite + workspace |
Kanban vs delegate_task 实测对比
| 维度 | delegate_task | Kanban |
|---|---|---|
| 可靠性 | ❌ 413 频发（小模型 system prompt 太大） | ✅ 全通过 |
| 持久性 | ❌ 进程消失 → 任务丢失 | ✅ SQLite 持久化 |
| 审计 | ❌ 压缩后不可回溯 | ✅ 完整事件日志 |
| 并行度 | ✅ 快（同程） | ❌ 需等待 dispatcher |
| 适合场景 | 短暂推理 | 持久化、跨 agent |
效率基准
同一任务”系统健康检查” × 不同方式
| 方式 | Provider | 耗时 | 结果 | 备注 |
|---|---|---|---|---|
| Direct terminal | N/A | 8ms | ✅ | 无推理，仅采集 |
| Kanban single worker | alaya/opencode-go | 16s | ✅ 中文分析 | 含 spawn + tools + 推理 |
| Kanban swarm（2+1+1） | alaya | ~14min | ✅ 110 行报告 | 含 verifier 验证 + 合成 |
| hermes chat -q | opencode-go/ds4f | ~30s | ✅ 中文总结 | 完整 session 加载 |
| hermes chat -q | openrouter 免费 | ❌ 413 | ❌ | 免费模型 context 太小 |
| hermes chat -q | pollinations | ❌ 413 | ❌ | 同上 |
Token 可用性
可用模型（能装下 Hermes system prompt）：
opencode-go/deepseek-v4-flash✅ 128K contextnous/tencent-hy3✅ （需通过 nous provider）
不可用（system prompt 太大）：
pollinations/openai❌ 小 contextopenrouter免费层 ❌g4f❌
结论：Kanban 编排必须用大 context 模型。
Token 优化方向
问题：kanban worker 每次 spawn 都载入完整 system prompt
- Hermes system prompt ≈ 30K+ tokens（含所有工具描述）
- 每个 kanban 任务至少消耗：30K input + 推理 output + 系统 prompt 压缩
优化策略（待实施）
| # | 策略 | 预期节省 | 复杂度 |
|---|---|---|---|
| 1 | 为 kanban worker 创建精简 profile，禁用不必要 toolset | ~70% input tokens | 低 |
| 2 | 任务分解：大任务分多个 subtask，降低每轮 context | ~50% 每轮 | 中 |
| 3 | 深度：利用 context 压缩减少旋转 | ~40% | 中 |
| 4 | 系统 prompt 最简化：去掉无关指令 | ~30% | 低 |
策略 1 实施方案
创建 alaya-worker-minimal profile：
# config.yaml
toolsets: [terminal, file, kanban_show, kanban_complete, kanban_heartbeat, kanban_comment]
# 移除：web, browser, vision, delegation, cron, etc.kanban 任务指定 --skill minimal 或通过 profile 级联。
看板深度研究笔记
Worker 生命周期
创建 → todo → (promote) → ready → (claim) → running → complete / block → archive
↑ blocked → (unblock) → ready
Dispatcher 内部流程（每 tick）
- Reclaim stale：worker 失联超期 → reclaim → ready（再次 claim）
- Reclaim crashed：PID gone + TTL expired → reclaim → ready
- Promote：todo 任务的 parent 全部 done → ready
- Claim + Spawn：ready 任务 → 原子 claim → spawn profile worker process
- Auto-block：连续
failure_limit（默认 2）次 spawn 失败 → block
Swarm 拓扑
Goal
├── Worker 1（并行）— 自由工具集
├── Worker 2（并行）— 自由工具集
├── Verifier（串行，Worker 完成后）— 交叉验证
└── Synthesizer（串行，Verifier 通过后）— 合成报告
Verifier gate：gate=pass 才允许 synthesizer 启动。
Dispatcher 性能
- 间隔：60s（config:
kanban.dispatch_interval_seconds） - spawn 开销：~5-10s（加载 profile + system prompt + tools）
- 单 worker 净运行：之后取决于任务复杂度
下一步优化
- Profile 精简：创建 minimal 的 kanban-worker profile
- 看板自动派单：cron 定时创建任务，编排员自动承接
- Decompose 实战：把复杂需求自动分解为多个 specialist 子任务
- Token 成本监控：添加 per-task token 日志到 gbrain
- Streak 追踪：记录看板任务的完成率/平均时长趋势
2026-10-09 Codex 审阅说明
HTTP 413 表示服务器或代理拒绝过大的请求内容，本身不能确定是模型上下文窗口超限。所测几条免费路由失败不能推断所有免费服务不可用；“128K 必需”应限定为当时输入规模与所选模型。收集、分析和完整流程的耗时属于不同阶段，不能直接作倍数比较；62% token 节省也需实际 usage 与同任务基线，不能由工具次数或文本长度推出。
核验依据：RFC 9110 HTTP 语义。