创作 Agent 的任务状态该如何保存

只保存 Agent 的最终回答，无法解释它中间为什么选了某张图，也无法在工具超时后从原步骤恢复。对内容生产来说，这会把一个可重试的问题变成整条任务重跑。

最小对象不是一条 ChatMessage
建议拆成五类对象：
Task 用户目标和业务归属
Step Agent 拆出的具体步骤
ToolCall 模型、连接器或本地能力调用
Artifact 图片、视频、文档和结构化结果
Approval 需要人工确认的决定
一个任务示例：
{
"task_id": "task_1001",
"project_id": "drama_01",
"goal": "生成第3集分镜候选",
"status": "waiting_approval",
"context_version": 4,
"steps": $"step_script", "step_subject", "step_shot"$ ,
"pending_approval_id": "approval_72"
}
project_id 和 context_version 不能省略。没有业务归属，产物容易落到个人空间；没有上下文版本，任务恢复时可能读到已经变更的角色或商品资料。
状态要表达"等待什么"
建议使用：
queued -> running -> waiting_input -> running
-> waiting_approval -> running
-> succeeded
-> failed_retryable
-> failed_terminal
-> cancelled
waiting_input 表示缺少用户资料，waiting_approval 表示结果需要人工决定，两者都不能显示为失败。用户补充资料后，应从原步骤恢复，而不是复制出一条新任务。
ToolCall 必须支持幂等和重试
工具调用至少保存：工具名称、输入摘要、权限主体、幂等键、开始结束时间、结果引用、错误类型和重试次数。
call_key = hash(task_id + step_id + input_version + tool_name)
if ToolCall.exists(call_key):
return existing_result

call = create_call(call_key, status="running")

try:

result = invoke(tool, input)

mark_success(call, result)

except Timeout as e:

mark_failed(call, retryable=true, reason=e.code)

没有幂等键的反例是：视频接口已经生成成功，但回调超时，Agent 重试后又生成一条并重复扣费。重试策略必须与工具特性和费用相关。

嘟哩 AI 的专家团、技能、连接器和自动化任务可以作为 Step 和 ToolCall 的执行来源；图片、视频、项目文件和短剧节点作为 Artifact 回到企业项目中。用户在任务过程中可以暂停、补充资料或确认候选，而不是被迫把所有判断一次性写进提示词。

这类工作流的目标不是开放一个无限自主循环，而是让 AI 在授权范围内继续推进明确任务，并在高风险节点停下来。权限、连接器能力和本地 Harness 是否可用，仍要按实际部署环境配置。

MVP 先做状态可见、输出可追溯、人工暂停、失败重试和任务取消。不要第一版就允许 Agent 自己修改权限、无限创建子任务或自动发布所有内容。

验收时可以模拟三种故障：用户中途补资料、工具调用超时、审批拒绝。只要系统能从正确状态恢复，且不重复生成或丢失产物，状态设计才算真正可用。