为什么聊天记录不能代表任务状态
用户在对话里说“每天早上整理行业新闻并发到群里”，这句话并不等于一个已经可运行的Automation。系统仍需明确来源、时间、筛选规则、交付位置、权限、失败策略和成本限制。
同样，“我已经帮你创建”也不能证明任务真的会持续运行。企业用户需要区分可复用的Automation与某一次Run：前者可能处于已启用或已暂停，后者则有等待、执行中、成功、失败或取消等状态。把两类状态混在一起，用户无法判断该修改任务定义，还是只需要重试本次运行。
四类能力不是后台工程细节，而是产品界面
任务与运行状态
用户能区分“自动化是否启用”和“这一次执行到哪一步”，并看到下一次触发时间。
权限与关键确认
读取、写入、发送和删除分级处理；高影响动作说明对象、范围和后果后再确认。
运行证据
保留run_id、触发方式、数据来源、执行步骤、工具结果和最终交付物，支持核验与审计。
失败恢复
告诉用户失败节点和原因，并提供检查点重试、重新授权、修改输入或人工接管。
自动化程度不是越高越好
产品经理需要根据失败成本分配自动化权。低风险、可逆、重复操作可以默认执行；对外发送、覆盖数据和改变权限等动作应提高确认门槛。判断依据不是“模型置信度很高”，而是操作后果、可逆性、权限范围和用户预期。
因此，我更倾向于把Agent主流程设计成“确定性骨架＋受控智能分支”：触发、权限、持久化和写入保持确定性；需求澄清、内容理解、工具选择或异常重规划可以使用模型，但每个节点都要有最小上下文、结构化输出和缺失兜底。
失败提示为什么必须可行动
“执行失败，请稍后重试”只描述了结果，没有帮助用户恢复。一个可行动的失败状态至少回答四个问题：
- 失败发生在哪个步骤？
- 已经完成的步骤和数据是否保留？
- 需要用户补充信息、重新授权，还是系统可以自动重试？
- 再次执行是否会造成重复发送或重复写入？
这也是为什么幂等、检查点和人工接管最终会成为用户体验问题：它们决定用户是否敢把重要任务交给Agent。
验收企业Agent时，我会问：用户能否看见目标、状态和证据？高风险动作是否经过授权？失败是否可恢复？历史运行是否可追溯？如果这些问题没有答案，再自然的对话也不能构成可信的Automation。
证据边界：本文来自Elo Automation、Search和Settings模块的产品设计复盘，覆盖原型、PRD、评测与功能验收思路；不将尚未完成端到端生产验证的Runtime能力表述为已规模化上线结果。