Hermes 下启动 Sub Agent 失败的痛苦教训

Hermes 下启动 Sub Agent 失败的痛苦教训

我以为 subagent 可以帮我并行搜索、整理资料、写好文件、一气呵成。

结果它跑了 9 分钟,中途超时,什么都没写完。


事情经过

任务很简单:搜索国产大模型(DeepSeek V4、Kimi K2.6、GLM 5.1、Qwen3、MiniMax M2.7)的最新数据,整理成 context.md,供主线程写文章用。

我用了 delegate_task,给 subagent 分配了 ["web", "file"] 工具集,让它自己跑。

python 复制代码
delegate_task(
    goal="搜索以下方向资料,整理成结构化 context.md 保存到 ~/.hermes/tmp/...",
    toolsets=["web", "file"]
)

subagent 开始工作了,开始搜索了,搜了很多页面,extract 了很多内容......

然后,9 分钟后:

yaml 复制代码
status: interrupted
Operation interrupted: waiting for model response (293.1s elapsed)
input_tokens: 205,776

文件没写,任务中断,一切归零。


为什么这么慢?四个核心原因

1. 冷启动:每个 subagent 都是全新 Session

subagent 没有任何上下文继承。它需要:

  • 重新加载完整 system prompt
  • 重新初始化工具列表
  • 从零开始理解任务

光初始化就要十几秒。这是固定成本,无论任务多简单都省不掉。

2. 工具调用是串行的,每步都要等 LLM

subagent 的执行模式是:

复制代码
web_search → 等模型推理 → web_search → 等模型推理 → web_extract → 等模型推理 → write_file

每一步都是一次完整的 LLM 推理 + 网络 RTT。如果搜 8 个方向,每步间隔 10 秒,叠起来就是好几分钟。

这不是并发,是串行 IO 密集型任务------偏偏 subagent 最不擅长这个。

3. Token 雪球:上下文越大,越慢

那次 subagent 的 token 消耗:

makefile 复制代码
input_tokens: 205,776

原因是每次 web_extract 返回几千字,全部追加到对话历史里,下一轮推理时要把所有历史重新带上。

上下文越大,Attention 计算越慢(接近二次方级别)。到了 200k tokens,每次推理可能要 20-30 秒。任务越多,滚雪球越快,最终超时崩掉。

4. Provider 共享配额

主线程和 subagent 用的是同一个 provider(Copilot / claude-sonnet-4.6)。subagent 跑重任务时,主线程也在等------配额可能排队,进一步放大了延迟。


根本误区:把 subagent 当成"更强的自己"

很多人(包括我)会这样想:

"这个任务我做要 10 步,subagent 帮我做,我可以去干别的。"

这个思路本身没错。但问题在于:subagent 做这 10 步,每步都比你慢------因为它需要额外的上下文重建、推理等待、token 积累。

subagent 的价值在于隔离 和并行,不在于加速串行任务。

diff 复制代码
✅ 适合 subagent 的任务:
- 真正相互独立、可并行的任务(3 个子任务同时跑)
- 推理密集、计算量大的单次任务(代码审查、文档分析)
- 需要上下文隔离的任务(避免污染主线程)

❌ 不适合 subagent 的任务:
- 多轮搜索 + 整理(串行 IO 密集)
- 需要频繁读写文件的流程(每步都要等 LLM 确认)
- 任务链条长、中间依赖多的(5步以上、每步依赖上一步结果)

教训和改法

教训一:搜索 + 整理,主线程自己做更快

像"搜新闻整理成文章"这种任务,本质是 IO 密集 + 串行依赖。

我自己直接做:搜索(几秒)→ 处理(本地)→ 写作(一次推理),全程不到 2 分钟。

subagent 做:初始化(15 秒)→ 多轮搜索(每轮 10 秒)→ 上下文膨胀(越来越慢)→ 超时(9 分钟后中断)。

结论:串行 IO 任务,主线程直接做。

教训二:给 subagent 的任务要"自包含"

好的 subagent 任务长这样:

python 复制代码
# ✅ 好:自包含,单次推理可完成
delegate_task(
    goal="分析这段代码的安全漏洞,返回风险列表",
    context="代码内容:[具体代码]"
)

# ❌ 坏:需要多轮 IO,依赖外部搜索
delegate_task(
    goal="搜索 10 个方向的资料,整理成 context.md,然后写文章"
)

一个 subagent,一件事,一次返回。

教训三:用 execute_code 替代轻量 subagent

如果只是需要"搜索 + 处理数据",用 execute_code 调 web_search + web_extract 效率远高于 subagent:

  • 无冷启动
  • 脚本化控制,不需要 LLM 每步决策
  • 输出直接进入主线程,无跨 session 开销
python 复制代码
# execute_code 里直接批量搜索
from hermes_tools import web_search, web_extract
results = web_search("DeepSeek V4 benchmark", limit=5)
# 立刻拿到结果,无等待

一句话总结

subagent 是放大器,不是加速器。

它能让你同时做多件事,但不能让每件事本身变快。用对了是翅膀,用错了是 9 分钟后的一条超时报错。

相关推荐
陈陈CHENCHEN7 小时前
【Kubernetes】纯 IPv6 K8s 用 socat 打通 IPv4 服务
云原生·容器·kubernetes
CCblandy8 小时前
HTTP 长连接 3 类故障实测:[WinError 10053]、99 个 TIME_WAIT、69 次多余握手,4 种对策怎么选
后端·python·网络协议·http·云原生·性能优化·架构
阿里云云原生9 小时前
阿里云 AgentCore 产品负责人解读产品全景
云原生·agent
阿里云云原生9 小时前
告别手动补索引:SLS 支持索引自动发现,让数据开箱即用、自由分析
云原生
阿里云云原生10 小时前
从 HTTP 200 到第一个有效输出:AI SSE 拨测如何量化流式体验
云原生
分布式存储与RustFS10 小时前
rclone 与 mc mirror:S3 对象存储同步,限速、过滤、断点续传实测对比
运维·云原生·开源·对象存储·分布式存储·s3·性能基准
阿里云云原生11 小时前
Kitta:Code Review Agent,提升代码审查质量
云原生
wzq11_66617 小时前
Kubernetes集群——网络管理
云原生·容器·kubernetes
做一个AK梦17 小时前
云原生服务网格
云原生
阿里云云原生1 天前
AI 语音一直“正在连接”?用 RUM 排查 WebSocket 建连问题
云原生