你给 Hermes 派了一批活：8 个子任务，6 个是翻文档、读日志、改格式这种轻活，2 个是啃并发、理架构这种硬活。可你只能给所有子代理定一个模型——定贵的，6 个轻活白烧钱；定便宜的，2 个硬活糊弄你。这个二选一，从 2026 年 10 月 22 日合入的 PR #142563 起不再必答。

以前的规矩：一个 delegation.model 管所有子代理

delegate_task 的模型是在 config.yaml 里全局钉死的：delegation.model、delegation.provider、delegation.base_url。默认策略下 delegate_task 没有“每个任务用什么模型”这个参数，所以一次批量里的每个子代理都跑在同一条路由上。官方文档写得很直白：想要按子任务质量分流，要么这次会话干脆不设 delegation.model，要么把活交给 kanban 板（那边支持 per-task 模型覆盖）。

结果就是大家心照不宣地做妥协：把委派模型定在中档，然后忍着。

现在：delegation.backend 决定“活怎么派”

这次改动的核心一句话：委派变成了一个可插拔的 provider 类别，和 TTS、图像生成、终端后端是同一个套路。delegation.backend 选策略，default 就是上面那套旧行为——官方明确写了，未设置或设为 default 时，delegate_task 的 schema 和每个 hermes-cli 工具定义与改动前逐字节一致。

另外两条策略来自官方插件 advanced-delegation：

• model_map：你列几个带标题的模型档位（fast、deep……），每个写一句话描述 + provider + model，模型自己按任务挑一档；
• profile_routes：每个子任务以某个 Hermes Profile 的身份跑，用它自己的模型、凭据、技能和人格。

delegation:
  backend: model_map
  backends:
    model_map:
      options:
        - name: fast
          description: Cheap and quick; lookups, summaries, simple edits.
          provider: openrouter
          model: google/gemini-3-flash-preview
        - name: deep
          description: Slow and careful; hard debugging and design work.
          provider: anthropic
          model: claude-opus-5
          reasoning_effort: high
          service_tier: fast      # 可选；这条路由没有 fast 档时会在启动阶段被拒
      default: fast                # 可选：没指定档位的任务走这里
    profile_routes:                # backend: profile_routes 时读这一段
      profiles:
        - name: coder
          description: Writes and refactors code; runs tests.

注意“档位描述”不是装饰：模型能看到的只有你写的名字和描述，provider、model、key 这些字段它一个字都看不到。所以你写“Cheap and quick; lookups, summaries”就是在教它什么时候该省钱，写“Slow and careful; hard debugging”就是在教它什么时候该花。

每个任务的结果多了 route 回执

一个走后端路由的任务，结果里会带 route：哪个后端、选了哪一档（或哪个 Profile）、子代理实际跑在哪个 provider / model / reasoning effort / speed tier 上；如果中途切到了 fallback provider，还会有 fallback_activated: true。

这条比看起来重要。以前你只能凭“我设了 delegation.model”推断子代理用了什么，现在它自己报账——排查“为什么这批任务突然贵了”时，直接看回执就行。

失败要吵出来，不许悄悄降级

官方这次把“安静降级”这条路彻底堵上了：

• 选中的后端没装、被禁用、或自报不可用时，delegate_task 直接返回工具错误，说明是哪个后端、怎么修（装/启用插件、/delegation default、或 hermes config set delegation.backend default），不会悄悄用默认路由把子代理跑起来；
• 批量里某个任务路由不了（档位名不存在、参数当前后端不支持、Profile 不存在、路由没有这个 service_tier、reasoning_effort 不认识、凭据缺失），只拒这一个：它的结果里 status: "error"、写明原因、带 route.refused: true，其他任务照跑；
• 只有当整批任务全被拒时，这次调用才算工具错误；
• 模型路由没自带 fallback_providers 就继承 delegation.fallback_providers，在路由上写 fallback_providers: [] 表示这条路由不兜底；Profile 路由则用那个 Profile 自己的兜底链。

顺带一个边界：model_map 或 profile_routes 生效期间，delegation.model 和 delegation.provider 是失效的——路由说了算。别一边配了档位，一边疑惑为什么 delegation.model 没反应。

怎么切、怎么切回来

两条策略和 /delegation 斜杠命令、hermes delegation config（增删改模型路由、挑 Profile）都来自官方插件，先装：

hermes plugins search advanced-delegation
hermes plugins install advanced-delegation
hermes plugins enable advanced-delegation

装好之后，切后端不必改文件：

/delegation model_map               # 只切当前会话
/delegation profile_routes --global # 写进 config.yaml，沿用 /model 的约定
/delegation default                 # 切回默认策略

这里有个容易踩的坑，官方文档专门点出来了：会话内切换只改路由，不改工具清单。delegate_task 的每任务参数（档位名、Profile 名）是缓存提示词的一部分，跟着 config.yaml 走，要到下一次会话才更新。所以在切换之后、新会话之前，模型还可能按老习惯发上一个后端的参数（比如切到 profile_routes 后还发 option: fast）——这种任务会被单独拒绝，并告诉你修法：/delegation <backend> --global 然后 /new（因为 /new 从保存的后端启动），或者 /delegation <saved backend> 切回去。它绝不会拿新后端的默认路由凑合跑。

没装插件、又想把配置复位，用 hermes config set delegation.backend default。

两种策略该挑哪个

• model_map：同一套凭据，按难度分钱。轻活给便宜模型，硬活给强模型，适合“批量任务但子任务难度差得远”的场景，比如一次修 10 个 issue、一次跑 20 条调研。
• profile_routes：子代理直接换身份。每个 Profile 有自己的模型、凭据池、SOUL.md 和终端策略。适合“这帮子代理该用另一套权限”的场景，比如让代码任务在受限终端策略下跑。

profile_routes 有句话必须抄下来：列出某个 Profile，等于把这个 Profile 的凭据、凭据池、SOUL.md 和终端策略交给本 Profile 的子代理使用。只列你愿意让 agent 拿去用的那些。

目前的状态

PR #142563 于 2026 年 10 月 22 日合入 main，紧随其后的 #142564 把默认策略本身也移进随包插件，桌面端的委派设置界面（档位选择、模型路由编辑、Profile 路由）由 #143126 补上。最近一次正式发布是 10 月 21 日的 v0.22.4，所以这些能力现在只在 main 上，会随下一个版本到稳定通道。想马上用就从 main 通道更新；写脚本依赖这些字段之前，先确认你的安装已经在包含它们的提交上。

如果你还没用过子代理的实时控制（list/steer/stop），可以先看 子代理实时编排指南；想搞清楚 delegation 这一节的完整字段，hermes config 命令参考比翻源码快。多档位模型切换的另一半故事在 model_overrides 配置指南；装插件的完整流程见 插件目录指南。