|
|
5a3a8f484b
|
fix(agent): 工具超时不再一刀切 60s，支持工具自声明与按参数推导
## 缺陷（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 不是需求。
|
2026-10-18 06:38:51 +08:00 |
|
