|
|
e273924511
|
fix(llm): 参数无法解析时给出真因，不再静默丢弃整条调用
★ 上次修复误判了成因。真实根因（本次运行日志 34/34 同形）：
{"command": "…完好的长命令…", "timeout": 20s}
command 一字节没错，只是 timeout 值少了引号 —— cmd_run 的 schema 把 timeout
声明成 string、示例写着 "10s, 1m, 30s"，模型照抄格式却忘了引号。
finish_reason=length 出现 0 次 ⇒ 上次那条"截断"分支从不生效。
旧行为把**整个参数**丢掉，模型只看到 "command is required"，看不出坏在 timeout，
只能原样重试。实测本次运行 cmd_run 失败率 35%（34 败 / 71 成），
12 分钟的任务里更是 48% 时间耗在这上面 —— 每次失败都付一次完整 LLM 往返。
三处改动：
1. repairToolArgsJSON：解析失败时先试窄修复 —— 只给"值位置上未加引号的带单位
数字"补引号，且修完必须真能解析成功才接受。不碰合法 JSON、不动正文里的 20s、
不会把真截断"修好"。
2. 修复仍失败时不再静默降级成空 map，改为带 __arg_error 交给模型，并按成因
分流文案：截断→拆小参数；JSON 写坏→提醒带单位的值要加引号。
3. 统一键名 __arg_error（原 __truncated_error 只覆盖截断，语义过窄）。
同一缺陷面不止 cmd：agentcli/healthcheck/timer 都有 string 类型却以
"5m, 1h" 作示例的参数，此修复一并覆盖。
回归测试：真实日志样本修复、保守性（不碰合法/正文/截断）、
端到端（修复后 timeout 仍能被 time.ParseDuration 接受）。
|
2026-09-19 16:49:16 +08:00 |
|
|
|
2722d76095
|
fix(llm): max_tokens 截断不再静默降级成空参数
长参数工具调用（整段脚本/大 JSON）被 core.llm.max_tokens 从中间切断时，
上游回 finish_reason=length，而旧实现把这个信号整个丢掉：残缺 JSON 解析失败
后静默降级成空 map，工具只看到参数为空并报 'path is required'。模型因此完全
看不出真因，原样重试四遍、次次撞同一堵墙（2026-09-19 实测 4 次 files_write 失败）。
注：files_read 并未失败——是写挂之后模型反复重写把读卷进同一轮，看起来像两者都报错。
改法：
- finish_reason=length 时不再静默降级，改为塞入 __truncated_error 指引，
告诉模型「参数被截断 + 请拆成多次调用/追加写 + 勿原样重试」；
- executeToolCallInner 见到该标记即短路，不拿空参数去调工具；
- 非截断的残缺 JSON 保持旧行为（避免把「厂商不回 finish_reason」误判成截断）。
回归测试 2 条钉死这两面。
|
2026-09-19 13:49:21 +08:00 |
|
|
|
f2ec46480e
|
refactor(core)!: N0 无状态化 —— 删除 Agent.currentOutputChannel，通道只跟输入事件/帧走
驻留式子 agent 设计（docs/zh/resident-subagent-design.md）的里程碑 N0。
## 问题
`a.currentOutputChannel` 是 **agent 级可变字段**，只在 prepare 段写入，而被打断任务
恢复时**不重新 prepare**（resumeTask 只 rebase 前缀）。于是中断任务 prepare 时把它
覆盖成自己的通道，被恢复的任务再把回复发到**中断任务的通道**上——两个任务串台。
后果不只是标签错：工具提示词里那句"当前输入来源通道是 X，对应输出门工具是
output_send__X"会诱导模型**把回复主动发到错误的通道**。
## 两处一起改（用户指出的两件事）
1. **内核不应持有"当前通道"**：通道是随输入事件带进来的，路由发生在**进内核之前**，
输出是 agent 的**主动调用**。删除该字段，改为一律从输入事件推导
（`outputChannelOf(evt)`）或读本任务的帧（`f.OutputChannel`）。
2. **提示词不应预设 outputch**：删掉"当前输入来源通道是 X → 用 output_send__X"那两行，
改为"不要假设当前通道是固定值；先看消息本身与上下文的来源信息，不确定时先调
output_list_channels"。
## 改动面（把通道一路显式传下去，而不是读共享状态）
- `agent.go`：删字段
- `task.go`：新增 `outputChannelOf` / `isCriticalChannel`；帧记录通道；
安全点与 setCritical 用帧/事件推导；步骤内事件标签改用 `f.OutputChannel`；
`executeToolCall(f.CurTool, f.OutputChannel)`；`callLLMWithFallback(..., f.OutputChannel)`
- `process.go`：`chatStreamWithFallback` / `accumulateStream` 增加 channel 参数
（增量事件的 channel 标签由此而来）
- `stage.go`：`runStage` 从 `ctx.Extra["output_channel"]` 读（发起方写入）
- `eventloop.go`：`emitResponse` 用 `outputChannelOf(evt)`；stageCtx 带上通道
- `spawn.go` / `toolcall.go`：`executeSpawnChild` 的 parentChannel 由调用方（帧）传入
（子任务完成通知要回到**发起这次 spawn 的那个任务**的通道）
- `distill.go`：删掉 consolidation 路径里的赋值
- `tooldefs.go`：删掉提示词里的通道预设
## 验收
- `scheduler_channel_routing_test.go`（N0 守卫）：中断任务跑过之后，被恢复任务的
输出通道仍是它自己的（改前实测为 cli，期望 qq）
- `TestCriticalSection_ConsolidationMarked`：补上推导链
「输入事件 → 通道 → isCriticalChannel → scheduler.critical」的集成断言
- 全仓 `go test ./...` 37 包 ok / 0 FAIL；`-race ./internal/agent/...` 干净
- 残留 `currentOutputChannel` 引用为 0（只剩描述历史的注释）
|
2026-09-13 08:59:15 +08:00 |
|
|
|
ddef1956b5
|
fix(agent): 流式并行 tool_call 按 JSON index 分桶，修复空参数调用
【根因】内核流式解析层丢弃了上游 SSE 分片的 OpenAI index 字段：
- openAIToolCall 结构体无 index 字段，JSON 解析即丢
- homed 的 openai.lua 转换为扁平结构时同样未透传 index
- accumulateStream 退而用 Go range slice 序号做累积桶 key，
但每个 SSE chunk 只含一个 tool_call 元素，序号恒为 0
于是并行多工具调用（index=0,1,2,3）的所有分片全部写入同一个桶：
name 相互覆盖、args 碎片混拼成非法 JSON → parseToolArgsJSON
失败返回空 map → 工具以空参数被调用（spawn_child 报'请提供 task'、
cmd_run 报'command is required'等），agent 只能串行重试自愈。
单工具场景只有一个 index 无污染，故简单请求一直正常；
pi 直连同一 llmsproxy 正常（其实现标准按 index 累积）。
【修复】
- ToolCall 增加 StreamIndex（json:stream_index），openAIToolCall
解析上游 index 并透传；openai.lua 输出 stream_index 字段
- accumulateStream 以 tc.StreamIndex 为累积 key
- flushToolCall 区分三种空参：未收到分片/碎片非合法 JSON/合法空
对象({})，分别打诊断日志，避免误报
- 回归测试 TestAccumulateStreamParallelToolCallsByIndex 模拟
4 路并行分片流验证按 index 正确分组与参数完整性
另含 spawn_child max_turns 参数、child_result 运行中状态区分、
provider 层非流式空参诊断日志。
|
2026-08-26 16:10:02 +08:00 |
|
