lhk229
0ab887c157
Project CI / Repository checks (pull_request) Failing after 15s
Project CI / Backend tests (pull_request) Failing after 15s
Project CI / Frontend tests (pull_request) Successful in 3m16s
Project CI / Native shell tests (pull_request) Successful in 15m31s
file.read observation 自带 sourceActionId，plan 根砍掉 agent.action_history
run 20 已经把裸计划更新那 5 轮清零（14 → 10 轮），但 agent.action_history 连调
四次：不带筛选拿到 4 条，带 tool=file.read 筛选拿到 1 条，然后又查全量、又筛一次。
GDD 只有 134 行、一页读完，本来就只有一个 actionId，它反复确认了四遍。
查过了，这些结果一直在它上下文里：观察逐轮累积进 prompt，agent.action_history 的
detail 还有 8000 字符的专属额度（context_window.rs 的 sanitize 分支），run 20 全程
compaction=0、上下文从 30507 涨到 33820。所以它不是失明，是对"全部分页"这个词较真
——拿到 1 条怀疑漏了分页，拿到全量又怀疑混进别的工具。这种"不敢信"加 prompt 约束
没用，得把取 id 这件事从工具变成事实。
command.exec 早就是这么做的：durable observation 直接返回可复用的 sourceActionId，
合同里明写「不要为取得它额外查询动作历史」。这里把同一条路铺给 file.read——成功读
取时在 detail 首行末尾追加 sourceActionId，然后把 agent.action_history 从 plan 根的
工具面整个拿掉。
追加是安全的：agent_runtime_action_receipt_safe_detail 解析 file.read 时只取前三个
`·` 字段（path / sha256 / lines），多出来的字段不参与，durable receipt 与 §13.0 的
取证解析都不受影响。
plan 根现在是五个工具：agent.goal_contract / agent.delegate / file.read /
agent.acceptance_update / agent.run_status，其中 run_status 只在 Delegated 阶段开放，
供审批返工时按原 delegationId 取回权威委派合同。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 08:54:14 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-21 08:54:14 +00:00
2026-08-05 19:15:46 +08:00
2026-07-17 16:56:46 +08:00
2026-08-17 12:42:29 +08:00