Hermes 开始给失控 subagent 加硬边界
Hermes PR #22820 把一个常见的多 Agent 失败模式变成了明确控制项。报告描述了一个 delegated subagent 偏离任务范围：运行 175 秒、上下文从约 33K 膨胀到 72K+ tokens、发起 10+ 次 API 调用，最后只能手动中断。拟议修复加入最大 child context、输出/输入增长比例、wall-clock timeout 三类配置，一旦越界就把 child 标记为 `resource_limit_exceeded`。PR #22944 处理另一个相邻可靠性问题：反复 context re-compression 后，agent 的 `## Active Task` 字段可能被 `[N/A]`、过期任务或幻觉内容覆盖。
影响观察中 来源2 对象operator · developer · team
多 Agent 系统真正危险的不是子任务失败，而是子任务一直循环、膨胀上下文或忘掉目标。这里的价值在于，Hermes 正从“派出去然后祈祷”走向 bounded delegation：能停止、能解释、能审计失败原因。
- PR #22820 给出具体失控案例：175 秒、从 33K 初始上下文涨到 72K+ tokens、10+ API calls，并最终手动中断
- 该 PR 增加 `delegation.max_context_tokens`、`delegation.context_growth_ratio`、`delegation.timeout_seconds`，越界时 child result 会标记为 `resource_limit_exceeded`
- PR #22944 指出 iterative re-compression 中 active-task corruption 的两个原因，并改为由代码保留该字段，而不是让 summarizer 重写
- PR #12436 加入 DAG TaskGraph、delegate bridge、in-process agent-to-agent bus 和 reflex hints，说明 Hermes 的 orchestration 仍在扩张，同时需要配套资源边界
- 核心改动仍是 open PR，操作者不能假设它已经进入 release 行为
- 硬限制可以防 runaway cost，但默认值过紧也可能误伤真实长任务
- DAG orchestration 会进一步提高对每个 child 的权限、预算和可观察性要求