Agent 如何判断任务已经完成？

核心回答

Agent说“完成了”只是一种停止请求，任务是否成功要看环境里的目标状态。 在GUI与轨迹执行场景，判断应落到页面、文件或业务系统实际发生了什么：按钮点击成功，只说明动作执行了；订单状态确实改变、目标文件内容正确，才接近任务完成。

我会把“是否继续运行”和“是否完成目标”分开：模型提出停止，运行时收集结果，验证器依据任务标准判断成功、失败、待外部结果或需要补充操作。步数、时间或预算耗尽可以停止执行，但应报告未完成，而不是成功。

完成标准从哪里来

开始时把用户目标转换成可检查条件，粒度与任务相称。比如“把报表导出为CSV并放到指定目录”，至少包含正确报表与时间范围、文件已生成、路径正确、内容可解析；不用给普通小任务增加繁重审批。

复杂任务将最终条件与子目标分开。填写表单、点击导出和下载结束是不同状态；子任务全部打勾，也要检查最终产物是否满足最初要求，防止计划本身漏项。

GUI场景如何获得证据

• 先读执行结果。 工具异常、页面跳转和操作返回值用于确认动作有没有执行。异步操作还要观察进度、任务ID或完成通知，不能在点击提交后立即判成功。
• 再检查目标状态。 能查询业务接口、数据库或文件内容时优先用明确结果；只能看界面时，重新观察页面，结合文本、控件状态与前后变化验证。成功提示可能转瞬即逝，截图也可能陈旧，需要确认时间与对应任务。
• 检查必要的约束。 操作对象是否正确，是否只完成部分记录，是否留下未保存编辑。验证应覆盖用户在意的条件，不强求重放唯一标准路径。
• 不确定时有限补证。 重新查询、刷新状态或读取产物；避免为了验证重复执行会产生副作用的动作。仍无法确认就说明结果与缺口。

例如“将商品库存改成20”，屏幕出现“保存成功”可作为信号，但重新读取同一商品的库存值更直接。模型生成一段解释、返回STOP或页面没再变化，都不足以单独证明成功。

验证器与停止策略

可确定的条件用规则或执行检查；语义目标如“摘要是否覆盖重点”可以用独立模型按明确维度评审，并用人工标注样本校准。独立验证降低同一次推理自我肯定的风险，但Judge也会误判，不能把它当绝对真值。

运行时保存停止原因、检查项、证据引用和待完成部分。检测到重复动作、无进展或预算耗尽时收敛；遇到可恢复错误则在限定次数内调整。评估时同时看真实成功率、错误宣布成功的比例，以及成功后仍多做动作的比例。真正的亮点是用可观察结果约束轨迹终点，同时让停止成本可控。

对应教程

参考资料