🧑💻 面试官：让 Agent 排查订单接口变慢，你会要求它先列计划吗？
🙋♂️ 我：多步骤排查时会让它先明确要验证什么，比如看监控、看慢查询、核对发布记录。但这个计划只是工作假设，不是必须按顺序执行到底的脚本。
🧑💻 面试官：如果第一步监控发现数据库很正常呢？
🙋♂️ 我：就不能机械地继续查慢 SQL。应该根据新证据改查上游依赖或网络耗时，并记录为什么改了方向。
🧑💻 面试官：那 Agent 每拿到一点结果就重写一份计划，不会更灵活吗？
🙋♂️ 我：未必。频繁重规划会增加模型调用，还可能忘记原目标、反复查同样的东西。要区分“按现有计划继续”与“关键假设被推翻，确实需要改路”。
Agent 的计划不是预测未来每一步，而是给当前行动一个可检查、可修订的依据。
面试速答（60 秒版）
Agent 做计划，是为了把复杂任务拆成可验证的阶段，避免拿到一个工具结果就漫无目的地调用下一个工具。计划里应有当前假设、下一步要取的证据和完成条件。
但计划不能锁死执行路径。比如原本怀疑数据库慢，监控却显示数据库正常，就该根据新证据改查上游服务或网络。重规划通常发生在关键假设被推翻、工具不可用、任务约束变化，或现有路线无法继续时；不必每一轮都重写全部计划。
工程上要把目标和边界留在运行器里，记录每次改计划的原因，并限制轮次、工具预算和重复查询。判断计划好不好，不是看它写得多完整，而是看它能否帮助 Agent 更快取得证据、正确收尾。
知识点详解：计划管方向，工具反馈管修正
没有计划，Agent 容易变成“看到什么查什么”
排查订单接口变慢时，Agent 的目标不是“调用尽可能多的监控工具”，而是给出有证据支持的原因和处理建议。一个有用的初始计划可以写成：确认慢在哪里，找出可能的变化点，交叉验证，最后给出可执行建议。
这些是阶段，不是四条绝对固定的工具调用。每个阶段都要知道“下一步要验证什么”。如果没有这个约束，Agent 可能一会儿查日志、一会儿查代码、又回去查同一张监控图，最后把一堆材料拼成看似完整的结论。
新证据出现时，改的是路径，不是目标
假设第一步发现数据库响应时间正常，但订单接口调用的库存服务耗时陡增。原计划中的“查慢 SQL”就失去优先级。Agent 应说明这个证据如何推翻旧假设，然后改查库存服务的错误率、依赖和最近发布。
目标仍是解释订单接口为什么变慢。变化的是当前假设和后续动作。把目标、权限、预算与当前计划分开保存，可以降低重规划时“连任务本身都改了”的风险。
什么时候不要重规划
一个工具暂时返回空结果，不一定值得把整份计划推倒。先判断这是信息不足、查询范围不对，还是关键假设真的被推翻。对局部小偏差，可只调整下一步；对方向性变化，再更新计划。
运行器还需要监测重复工具调用、无效改计划和总成本。某个 Agent 总是先写一份长计划、每步又重新写一份，可能比直接稳妥执行更慢。计划是提高完成率的工具，不是必须展示给用户的表演。
面试官继续追问
计划做得很细，是否就变成 Workflow？
不一定。关键看运行时是否允许模型根据证据选择或改变下一步。若所有分支和动作都由代码提前固定，才更接近 Workflow。
怎么知道 Agent 是合理重规划，而不是跑偏？
保留原目标、当前假设、触发改计划的新证据和新动作，检查它们之间是否有因果关系；再看最终任务是否完成。
需要让用户看见每一步计划吗？
不一定。用户更需要知道当前进度、重要改动和需要确认的动作。内部详细计划可以在 Trace 中保留，避免把冗长过程当成结果。
面试速记卡
- 计划：拆出阶段、证据与完成条件。
- 定位：计划是工作假设，不是固定剧本。
- 重规划：关键假设、工具或任务约束发生变化时改路。
- 约束：目标、权限和预算不随计划任意漂移。
- 评估：看完成率、重复调用、成本和改路理由。
