mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-11-01 14:57:38 +00:00
## 缺陷(2026-10-17 生产日志实测) `toolcall.go` 里写死 `time.After(60 * time.Second)`,与工具自己的超时 **互相矛盾**且让内层形同虚设: 23:13:38 执行 cmd_run(agent 传了 timeout="130" 级参数) 23:14:38 ★ 内核 60s 硬超时掐断 → 「执行超时(60秒)」 同一份日志里 healthcheck 声明默认 120s ⇒ 被砍掉一半,天生跑不完。 ## 改动 1. `ToolDef.Timeout` / `BuiltinToolDef.Timeout`:工具自己声明单次上限。 留空 = 沿用 60s(存量插件**一行不改,行为逐字不变**)。 2. 内核取 `max(声明值, 调用参数 timeout)`,再夹到硬上限 10m: · 声明修好固定时长的工具(healthcheck 5m) · 参数推导修好时长可变的工具(cmd_run 的 timeout 参数) · 硬上限防插件声明成 0/无限把队列堵死 3. 非法声明("130" 少单位、0s、负数)**回退默认并记日志**,不静默接受。 写错单位是最容易犯的错,默默变成 60s 会让人以为"声明没生效"却查不出。 4. healthcheck 声明 5m(它的 llm_timeout 默认就是 120s)。 ★ 没有把 timeout 放进 `ToSchema()`:那份 map 是**发给模型**的 function schema。把内核的执行参数混进去,模型会以为需要自己传 timeout 参数。 ## 判据(6 条) 未声明→60s / 声明生效 / 参数参与取 max / 参数比声明小用声明 / 非法回退 / 超上限夹住。变异全部咬住。 ## 附:这条路只治「工具真的需要更久」 向开发线投递(output_send__*)的两次 60s 超时**不是这个原因** —— 那是 commondev 把"投递"实现成了"同步等任务完成",已在 SDK 仓修成异步。 这里没有给 output_send 放大超时:投递应该瞬时返回,慢是 bug 不是需求。