AI agent 一旦开始做长任务，团队很快就会碰到一个很别扭的问题。用户不想等，产品也不想让界面长时间空白，于是大家自然会想：能不能把中间结果先给出去？例如先展示证据摘要、先给一版草稿、先把前半段代码 diff 放出来、先告诉用户“已经完成 60%”。这套想法本身没错，很多系统也确实需要 progressive feedback 才不会看起来像挂了。
问题在于，中间结果一旦出现在用户界面、进入下游系统，甚至被另一个 agent 当成输入，它就不再只是“暂时看看”。它会立刻开始影响判断、触发动作、改变预期。所以 partial completion 真正要设计的不是“如何更快露出内容”，而是“哪些内容只配做草稿，哪些内容已经足够进入可承诺状态”。
很多系统出事故，并不是因为没有提前展示，而是因为展示与提交没有边界。看起来只是让用户早一点看到东西，最后却演变成半成品被复制到正式邮件、未审核 patch 被当成最终提交、初步证据被误当成最终结论。
建议配合 AI agent Checkpoint 与断点恢复、AI agent 输出合并与冲突解决、AI agent 取消、中断与安全停机 和 AI agent 证据来源与可信度分层 一起看。
先给一个判断表：不是所有“有了点结果”都应该叫进度
| 结果类型 | 能否提前展示 | 能否提前提交到外部系统 | 更合适的状态 |
|---|---|---|---|
| 工作草稿 | 可以 | 不可以 | draft |
| 已完成但未复核的 evidence | 可以，但要标记可信度 | 不可以直接当结论 | candidate |
| 准备外发的内容 | 只适合内部预览 | 不应自动外发 | staged |
| 已完成审批且通过 policy 的结果 | 可以 | 可以 | committed |
这张表的价值在于把“可见”与“可提交”分开。很多团队恰恰是把这两件事混在了一起，才会让中间结果不小心越过最后一道门。
Progressive commit 的本质，是状态提升，不是内容早泄
设计 partial completion 时，最容易踩的坑是把它理解成“只要算出来了就先放出来”。真正稳定的系统会把结果拆成不同的 commit level：
draft：模型或工具刚产出的候选内容，只适合当前会话内部继续加工candidate：已经过基础校验，可以给用户看方向，但仍不该触发真实副作用staged：内容准备好了，正在等待人工批准、外部条件满足或最终 policy 放行committed：系统承认它已进入正式状态，可以作为下游事实被依赖
一旦这套状态清楚，产品、调度器和人工 review 才不会各自理解不同。否则前端以为自己显示的是“进度”，而后端实际上已经把同一份对象当成了“可以继续依赖的结果”。
用户看到的进度，最好解释“在做什么”，不要只解释“做了多少”
很多团队想通过一个百分比解决所有焦虑，但 AI agent 的长任务里，百分比往往并不诚实。因为真正关键的并不是已经跑了几步，而是系统当前处在哪一类风险状态：
- 还在收集证据
- 已经形成候选结论，但未确认
- 正在等待人工 review
- 已经冻结副作用，准备最终提交
相比一个看起来很精确的 60%，用户往往更需要知道：“现在这份内容能不能用？”
所以 progressive feedback 更适合用状态说明和结果等级来表达，而不是强行给出数学化的完成度。尤其在证据不完整或需要人工确认的场景里，过早给出“已完成 80%”非常容易让用户误判风险。
长任务中断时，partial completion 最容易暴露系统有没有边界
任务被取消、超时或 runner 崩溃时，partial completion 的质量会立刻见真章。因为这时系统必须回答：
- 已经产生的草稿是否继续保留
- 已经过基础校验但未审核的结果是否允许再次展示
- 已进入 staged 的对象能否在恢复后继续推进，还是必须回到候选态
- 哪些中间对象必须明确标成“不可继续依赖”
没有这一层状态设计的系统，恢复时很容易把旧草稿当成当前事实，或者把一次失败 run 留下的中间内容混进下一次成功 run。用户看到的是“系统似乎记得之前做过什么”，实际上系统只是把不同可信度的对象全混在了一起。
一个典型事故：先把邮件草稿给用户看，结果被误发成正式版本
某个销售支持 agent 会先根据线索和历史邮件生成一版 outreach draft，给销售团队预览。为了提升体验，团队做了 progressive UI，让用户在草稿生成过程中也能提前看到前几段内容。问题出在：
- 前端把“正在生成的 draft”与“已准备发送的 staged 内容”用了同一种卡片样式
- 后台又允许用户在同一面板直接点击“发送”
- 某次 run 在后半段调用客户画像工具失败，但前半段草稿已经显示出来
- 用户误以为这是完整版本，直接触发发送
最后发出去的不是最终版本，而是一封缺少免责声明和关键个性化信息的半成品邮件。
修复不是简单加一个弹窗，而是把 progressive object 和 sendable object 彻底分层：任何未到 staged 的内容只能留在草稿区，不能和外发动作共享同一条提交流程。这个改动看似小，但它把“先看见”和“先承诺”重新拉开了。
真正值得先做的，不是更多 loading 态，而是 commit 语义清楚
如果你现在要补 partial completion，最值得先做的不是设计更多骨架屏和进度动画，而是明确这四个问题：
- 哪些对象只允许停留在当前会话
- 哪些对象可以被用户看见，但不能触发副作用
- 哪些对象必须经过人工或 policy 放行才能升级
- 哪些对象一旦 commit，就必须被下游当成事实处理
只要这四件事没有说清，系统每多展示一点“进度”，都可能是在提前释放还没准备好的承诺。长任务最需要的不是快一点显得忙，而是让每一层结果都知道自己目前配得上什么身份。
延伸阅读：
