90% 的人用 Hermes，还停留在助手阶段：把所有需求塞进一个 Prompt，然后看着它串行执行。
这种用法在多 Agent 并发场景下有三个隐性代价：
•Token 浪费：子 Agent 继承冗余历史信息。
•指令稀释：长上下文中关键指令权重衰减。
•控制循环失控：缺乏显式执行预算，容易进入低效循环。
今天直接进深水区，教你用 Hermes 三个核心机制，把单体 Agent 升级为工程级调度系统。
技巧 1：用 Stateless Ephemeral Unit 实现真并行
每次调用 delegate_task，Hermes 都会实例化一个新的 AIAgent。通过 skip_memory=True 和 skip_context_files=True，子 Agent 拥有完全独立的上下文，互不干扰。本质：每个子 Agent = 一次性无状态执行单元。
实测命令（并行读取本地日志并汇总，可以根据自己需要更改）：
hermes chat -q "使用 delegate_task 工具并行执行以下 3 个任务（toolsets 均为 terminal,file）：
task 1: 尝试读取 /var/log/syslog（若无权限或不存在则跳过并说明原因）
task 2: 读取 /var/log/auth.log 的最后 10 行并总结
task 3: 读取 /var/log/dpkg.log 的最后 10 行并总结
最终汇总为一份系统运行状态报告，包含每个任务的执行耗时" --toolsets delegation,terminal,file --yolo
技巧 2：触发 LLM-Driven Replan 处理故障
Hermes 的故障处理在两个不同层级运作：
•Layer 1（Infra 层，自动）：在 LLM API 调用层处理 HTTP 503/429/timeout，自动重试，对上层完全透明。
•Layer 2（编排层，LLM 驱动）：子 Agent 失败时，返回包含 status、exit_reason、tool_trace 的结构体。
高级玩法：利用 Layer 2 返回的 status 和 tool_trace，引导父 Agent 自主判断是否调整策略，而不是盲目重跑。
实测命令：
hermes chat -q "使用 del