计划与进度

一句话理解：好的计划与进度设计，要让用户在任意时刻用 5 秒回答三个问题：它打算做什么？现在做到哪了？接下来需不需要我？

用户把一个任务交给 Agent 之后，最先产生的情绪不是期待，而是不确定：它理解对了吗？它会不会去做我没让它做的事？已经跑了两分钟了，是在认真干活还是卡住了？

如果界面只显示一个转圈图标和“正在思考…”，用户只有两种选择：干等，或者中断重来。如果界面把每一次工具调用的原始 JSON 都刷到屏幕上，用户同样无法判断进展。这一课讲如何设计计划与进度，让 Agent 的工作过程可预期、可理解、可纠正。

先给计划，再执行

对于耗时长、成本高或涉及写操作的任务，在执行前展示计划，是纠错成本最低的时机。用户花 10 秒看一眼计划，可能避免 Agent 花 10 分钟做错事。

以 SEO 诊断 Agent 为例，用户输入“帮我看看官网为什么最近自然流量下降”，Agent 先给出：

我的理解：找出 example.com 近 4 周自然搜索流量下降的主要原因，并给出修复建议。

计划（预计 6–8 分钟，不会修改网站上的任何内容）：
  1. 拉取搜索平台近 8 周的点击与展示数据，定位下降集中在哪些页面和关键词
  2. 检查下降页面的抓取与索引状态
  3. 对比这些页面近期的内容与技术改动（标题、canonical、页面速度）
  4. 抽查 3 个主要竞品在相同关键词上的排名变化
  5. 汇总原因，按影响大小排序，输出诊断报告

需要你确认：
  · 时间范围按“近 4 周对比前 4 周”可以吗？
  · 是否包含博客子目录 /blog？

[开始执行]  [修改计划]

这份计划有几个值得学习的细节：

先复述理解。 让用户第一时间发现目标理解上的偏差。
每一步是“动词 + 对象 + 目的”。 用户能判断这一步有没有必要，而不是看到“调用 search_console_api”。
说明边界。 “不会修改网站上的任何内容”直接回应了用户最大的顾虑。
把模糊点变成问题。 与其让 Agent 自己猜时间范围，不如在计划阶段问清楚。
给出预期耗时。 让用户决定是等着还是先去做别的事。

不是所有任务都需要计划确认。简单的查询类任务直接执行即可；Coding Agent 等产品通常提供单独的计划模式，由用户决定何时先审计划。规划本身的机制见规划与任务拆解。

进度的三层信息

进度信息要分层，不同的人在不同时刻看不同的层：

层级	内容	谁看、何时看	默认
摘要层	当前状态、已完成几步、是否需要我	所有用户，随时	始终显示
步骤层	每个计划步骤的状态、关键发现、耗时	想了解进展的用户	展开显示当前步骤
记录层	每次工具调用的参数与结果、模型的中间输出	排查问题的用户或工程师	折叠，点击进入

记录层本质上就是面向用户的 Tracing 视图，需要注意敏感信息的展示权限。

图 1 把三层信息叠在一起看：

图 1 · 进度分三层：越往下越细，默认只展开到当前步骤

步骤层的关键是 把工具调用翻译成人话，并附上关键发现：

原始工具调用	用户看到的步骤描述
`get_search_metrics(site="example.com", weeks=8)`	拉取近 8 周的搜索数据 ✓ 下降集中在 18 个核心页面
`check_index(url="/pricing")`	检查页面的索引状态 ✓ 发现 3 月 12 日后返回 301 跳转
`get_change_log(site="example.com", since="03-01")`	查找近期的网站改动 ✓ 找到 1 条重定向规则变更
`check_index` 连续失败 3 次	检查页面的索引状态 ⚠ 搜索平台接口暂时不可用，已跳过，结论可能不完整

最后一行尤其重要：进度不只报喜，也要报忧。 步骤被跳过、数据不完整，需要在进度里直接说明，而不是等到最终报告里才暴露。

诚实的进度指示

Agent 的步数通常无法预知，传统的百分比进度条很容易变成“假进度”：卡在 90% 半天不动，比没有进度条更让人焦虑。更诚实的做法：

用可数的单位。 “已检查 23 / 50 个页面”比“46%”更可信，前提是总数确实已知。
显示已用时间，谨慎显示剩余时间。 只有在同类任务有足够历史数据时，才给出剩余时间估计，并用区间表达。
显示“最近一次活动”。 例如“12 秒前：正在读取竞品页面”，让用户知道它没有卡死。
计划变更要显式告知。 Agent 在执行中发现新情况而调整计划是正常的，但必须让用户看到：

计划已调整
  原计划第 4 步“抽查竞品排名”已取消
  新增第 4 步“检查 3 月 12 日上线的 URL 重定向规则”
  原因：发现下降的 18 个页面都在 3 月 12 日后返回了 301 跳转

不声不响地改计划，会让用户在事后看到结果时产生“它怎么自作主张”的不信任感。

任务状态模型

界面上的状态必须和后端真实的任务状态一致。一个常用的状态模型（图 2）：

图 2 · 任务状态模型：主路径、两种等待和四种结束状态

几条设计原则：

“等待”要说清在等谁。 “等待你审批”和“等待搜索平台接口恢复”对用户意味着完全不同的行动。
“部分完成”是独立状态。 不能为了界面简洁把它归入成功或失败，详见失败的呈现。
状态变化要能被通知。 尤其是进入“等待你审批”时，见异步任务体验。
状态文案面向用户。 用“等待你确认”而不是“interrupted”。

常见误区

“显示模型的思考过程就是透明。” 大段的中间推理文字信息密度低，用户难以从中判断进展。进度应该是结构化的步骤与发现。
“计划一旦确认就不能变。” Agent 的价值恰恰在于根据结果调整路径。关键是调整要可见、有理由。
“进度越实时越好。” 每秒刷新的工具调用列表会让界面剧烈跳动。步骤层按步骤更新即可，记录层才需要实时。
“简单任务也要先确认计划。” 查一个页面的收录状态还要先点“开始执行”，只会增加摩擦。按任务的耗时、成本和风险决定是否需要计划确认。

设计要点

长任务、高成本任务、涉及写操作的任务，执行前展示计划：复述目标、列出步骤、说明边界、提出待确认问题、给出预期耗时。
进度分为摘要、步骤、记录三层，默认只展开到当前步骤。
工具调用翻译成“动作 + 对象 + 关键发现”，异常和跳过的步骤要在进度中直接标出。
不使用无法兑现的百分比进度条，优先使用可数单位与最近活动时间。
计划调整必须显式告知原因。
界面状态与后端任务状态一一对应，“等待”要说明在等谁。

练习

为「销售分析 Agent」设计计划与进度界面（30–45 分钟）。用户输入：“分析上周华东区销售额下降的原因。”

写出 Agent 执行前展示的计划，包含理解复述、4–6 个步骤、边界说明和 1–2 个待确认问题。
假设执行到第 3 步时发现“下降主要来自一个大客户的订单延期”，写出计划调整的提示文案。
画出执行到第 4 步时的进度面板文字线框，包含摘要层和步骤层。

下一步

用户看到了进度，接下来会问：“你凭什么得出这个结论？”下一课「证据与可解释」讲如何让 Agent 的每个结论都有据可查。

计划与进度