.18 的核心体验升级MoA 运行时每个参考模型的推理过程以独立标签块展示你可以看到每个模型各自的想法最后再看聚合器的综合结论。实际效果示例——限流方案设计┌─ Reference: GPT-5 ─────────────────────────────────┐│ 令牌桶方案 ││ - 实现简单内存占用固定 ││ - 适合突发流量场景 ││ - 10 万 QPS 下每秒补充 10 万个令牌… ││ ││ 滑动窗口方案 ││ - 精确度更高无临界突发问题 ││ - 内存开销较大需存储每个请求时间戳… │└──────────────────────────────────────────────────────┘┌─ Reference: Claude Sonnet ──────────────────────────┐│ 从工程实践角度 ││ - 令牌桶在 Redis 中实现时批量补充令牌有原子性问题 ││ - 滑动窗口用 Redis Sorted Set10 万 QPS 下… ││ - 建议混合方案粗粒度用令牌桶细粒度用滑动窗口 │└──────────────────────────────────────────────────────┘┌─ Reference: Grok ───────────────────────────────────┐│ 另一个被忽视的角度 ││ - 分布式场景下的一致性问题 ││ - 令牌桶的「预补充」在多节点时会导致超发 ││ - 建议引入中央令牌池或 Lua 脚本保证原子性… │└──────────────────────────────────────────────────────┘▶ Aggregator (Gemini 2.5 Pro) — streaming…综合三位模型的分析以下是最终建议方案选择推荐混合架构Claude 的建议全局限流用令牌桶简单、高效精确限流用滑动窗口准确实现要点Redis Lua 脚本保证原子性Grok 的关键补充每个节点本地缓存 定期同步减少 Redis 压力性能预估令牌桶单 Redis 实例可支撑 15 万 QPS滑动窗口单实例约 8 万 QPS需分片聚合器的答案是实时流式传输的——不再是长时间等待后一次性出现而是像普通对话一样逐字输出。对比普通模式如果只用 Claude Sonnet你会得到一个「还不错」的答案。但 MoA 模式下Grok 补充了分布式一致性这个你可能没想到的角度Gemini 综合后给出了更全面的方案。5.5 高级技巧技巧 1用 reference_max_tokens 控制速度参考模型的输出越长聚合器等待时间越久。设置 reference_max_tokens 可以让参考模型给出简洁建议大幅加快响应速度moa:presets:fast:reference_max_tokens: 300 # 参考模型最多输出 300 token# 聚合器输出不受限制技巧 2按场景选预设moa:presets:deep: # 深度分析用强模型reference_models:- provider: openai-codexmodel: gpt-5.5- provider: anthropicmodel: claude-opus-4.8- provider: openroutermodel: deepseek/deepseek-v4-proaggregator:provider: anthropicmodel: claude-opus-4.8quick: # 快速任务用轻量模型 reference_models: - provider: anthropic model: claude-sonnet-4 - provider: openai model: gpt-4.1 aggregator: provider: openrouter model: anthropic/claude-opus-4.8 reference_max_tokens: 300使用时/model deep --provider moa # 复杂任务/model quick --provider moa # 简单任务/moa 简单问题 # 用默认预设技巧 3一个参考模型失败不影响整体如果某个参考模型 API 报错或超时Hermes 会跳过它用剩余的参考模型继续。不会因为一个模型挂了就整个任务失败。技巧 4MoA 和普通模式随时切换/model deep --provider moa # 切到 MoA… 使用 MoA 回答几个问题 …/model claude-sonnet-4 # 切回普通模型切换不会丢失对话历史也不会破坏 prompt 缓存。技巧 5用 save_traces 调试推理过程开启 save_traces 后每个参考模型的输入输出、聚合器的输入输出都会保存为 JSONL 文件便于事后分析哪个模型贡献了什么观点moa:save_traces: true # 全局开启presets:deep:save_traces: true # 也可按预设单独开启追踪文件保存在 ~/.hermes/sessions/ 目录下文件名包含会话 ID 和时间戳。5.6 注意事项MoA 比单模型慢需要等所有参考模型输出完才能聚合。设置 reference_max_tokens: 300~600 可以显著加快速度。MoA 比单模型贵token 开销约是单模型的 4~6 倍。建议只在复杂任务时使用简单问题用普通模型。参考模型不需要来自不同 provider可以用同一个 provider 的多个模型也可以混合使用。参考模型的视野有限能看到当前对话历史包括工具调用但看不到系统提示词和工具 schema。这是设计如此保证参考调用的轻量化。参考模型可以使用工具v0.18 起参考模型在每次用户消息或工具返回时都会被触发可以像主 agent 一样调用工具搜索、读文件等辅助推理但工具调用结果不会传递给其他参考模型。聚合器不能是另一个 MoA 预设MoA 递归调用被显式禁止防止无限嵌套。一个参考模型失败不影响整体如果某个参考模型 API 报错或超时Hermes 会跳过它用剩余的参考模型继续。MoA 和普通模式可随时切换用 /model 切换不会丢失对话历史也不会破坏 prompt 缓存。save_traces 会产生大量文件调试用的 JSONL 追踪文件会占用磁盘空间生产环境建议关闭。5.7 Delegation /Kanban /MoA 区别总结Delegation “我拆活临时工干”——轻量、临时、一次性子 Agent 干完就销毁Kanban “项目看板多人协作”——重型、持久、可审计任务有状态机支持 block/unblock、评论、依赖链MoA “多个 AI 开会讨论”——不是 Agent 协作是模型协作多个 LLM 独立推理后由聚合器综合用于提升回答质量而非完成工程任务维度 任务委派 (Delegation) Kanban MoA一句话概括 父 Agent 拆子任务子 Agent 干完汇报 多个 Profile Agent 通过看板异步协作 多个 LLM 同时回答同一问题聚合器综合输出参与的是什么 子 Agent同一进程内 spawn 的轻量实例 独立的 Profile Worker 进程各有自己的 config/session/memory 多个 LLM 模型不是 Agent是纯模型推理协调机制 父→子 直接委派结果摘要回传 SQLite 任务板 Dispatcher 调度状态机驱动 并行调用多个参考模型聚合器综合任务持久性 ❌ 无。父会话结束子 Agent 全部丢失 ✅ 有。Board 在 SQLite 中持久化跨运行可恢复 ❌ 无。就是一次推理调用人类可中途介入 ❌ 不行子 Agent 不能 clarify ✅ 可以。通过 comment 补充要求、block/unblock 任务 ❌ 不行典型场景 短平快子任务调试某段代码、调研某个问题、并行查 3 个方向 长期工程流水线拆解→并行实现→审查→汇总日报周报多账号管理 需要多角度推理的复杂问题架构决策、深度分析、多方案对比成本 中等子 Agent 有独立上下文 高每个 Worker 是独立 Profile有完整系统提示词工具 高N 个参考模型 1 个聚合器token 约 4~6 倍速度 快子 Agent 执行完立即返回 慢依赖 Dispatcher 60s 一轮扫描 Worker 异步执行 中等要等所有参考模型输出完再聚合配置复杂度 低开箱即用 高需配 kanban orchestrator profile dispatcher 中配好 MoA 预设即可类比 老板把任务分配给临时工 项目管理看板Jira/Trello多人协作 开评审会3 个专家各发表意见领导拍板总结