第 14 章 · 计划、任务状态与预算

本章目标：理解计划不是为了让回答显得有条理，而是为了管理依赖、进度、风险和停止条件。

1. 什么任务需要计划

回答一个函数含义可能只需读取一次，不必先列十步计划。跨模块功能、迁移、长时间测试和需要用户决策的任务适合显式计划。计划的价值在于把大目标分成可以验证的中间状态。

好的计划项是动作与完成条件，例如“定位认证入口并确认相关测试”，而不是“分析问题”。它还应标出依赖：没有确定接口前，不要让两个 Agent 同时实现前后端。

2. 计划是动态状态

模型在探索前不可能知道全部步骤。Runtime 可以允许 pending、in_progress、completed，并要求同一时间只有一个主步骤 in_progress。新证据出现时，Agent 可以解释原因后调整计划。

计划更新应成为事件，便于人类看到为什么路线改变。静态地展示最初计划，却不反映实际执行，会让界面产生虚假确定性。

3. 多种预算

Agent 至少有四种预算：

• Turn 预算：最多进行多少轮模型决策；
• 时间预算：任务和单个工具可以运行多久；
• Token 与费用预算：上下文和模型调用成本；
• 风险预算：允许多少次写入、网络和审批升级。

预算耗尽是一个终态，不等于业务失败。最终报告应说明完成到哪里、哪些证据已有、继续需要什么资源。

4. 模型路由

并非每一步都需要最强模型。仓库快速搜索、日志摘要和格式转换可以使用更快模型；架构取舍、复杂调试和最终审查使用更强推理。Runtime 根据任务类型、风险和剩余预算选择模型。

模型切换后，上下文格式与能力可能不同，因此 Provider adapter 和统一事件协议非常重要。路由还要避免频繁切换导致风格和计划不一致。

5. 完成标准进入计划

每个阶段应附验证：

探索完成：
- 找到入口、测试和项目规则

实现完成：
- diff 只包含目标范围

验证完成：
- 相关测试、类型检查通过

交付完成：
- 汇报变化、证据和剩余风险

模型不应仅因为所有代码已写就把计划标为完成。验证步骤必须独立存在。

6. 人类负责的逻辑

人类最重要的角色是定义目标优先级、不可接受风险和验收标准，而不是替 Agent 决定每条 shell 命令。计划界面应该让你容易修改这些高层决定，并把低层执行交给系统。