问题描述

当Agent需要执行多个子任务时，当前行为模式倾向于先全部执行完毕，再统一提交所有 complete_step，导致 todo_write 的 verifyTodoCompletionTransitions 校验失败：

5 todos are newly completed but have no matching successful complete_step receipts in this turn

复现步骤

1. 通过 plan 设置 3+ 个子任务
2. 逐个执行所有子任务（安装、配置等操作全部完成）
3. 最后一次性调用 todo_write 将所有子任务标记为 completed
4. 触发错误：todo_write 检测到多个 todo 从 pending/completed 但没有对应的 complete_step 记录

预期行为

串行模式：做完一个、提交一个、再做下一个

计划 -> 执行子任务1 -> complete_step(子任务1) -> todo_write(标记1完成, 设置2为in_progress)
     -> 执行子任务2 -> complete_step(子任务2) -> todo_write(标记2完成, 设置3为in_progress)
     -> ... -> 全部完成

根因分析

1. 提示词层面

• controller.go 中 planApprovedMessage 虽然提到 one in_progress at a time 和 Sign off each finished sub-step，但没有明确指出 必须先 complete_step 再 todo_write 的循环模式
• 模型倾向于将可用工具并行化，而 complete_step 和 todo_write 被设计为顺序依赖（partitionToolCalls 中将它们标记为不可并行）
• 缺少对 batch completion is an error 的明确约束

2. 工具校验层面

• todo.go 中 verifyTodoCompletionTransitions() 会检查本次 todo_write 中新增的 completed 项是否有对应 complete_step 记录
• completestep.go 中 verifyStepEvidence() 要求证据在当前 turn 的 ledger 中有对应记录
• 模型批量提交时，过渡校验会发现缺少正确的 complete_step 序列

修复建议

方案 A：增强提示词（推荐，低风险）

在 planApprovedMessage 和 executor handoff 指令中明确加入串行工作流约束。涉及文件：

• internal/control/controller.go -> planApprovedMessage 常量
• internal/agent/coordinator.go -> DefaultPlannerPrompt / formatHandoff

方案 B：代码增强加固

在 todo_write 的校验中，当检测到批量 completion 时，返回更清晰的错误消息帮助模型自我纠正。

相关代码：

• completestep.go
• todo.go
• agent.go partitionToolCalls
• controller.go planApprovedMessage