Agent工作流与可靠执行

A01Workflow 与 Agent 的边界

默认选择：退款这类高风险流程用确定性Workflow主导，只在“理解用户、选择查询工具、整理信息”等低风险环节使用Agent判断。

A02Agent循环在系统哪里运行

Agent循环运行在你控制的后端编排器中，不在模型内部自动永久运行。每一轮后端把当前目标、状态和工具结果发给模型，模型返回下一动作。

for step in 1..max_steps:
    decision = 调用模型(目标, 当前状态, 可用工具)
    if decision是最终答案: 结束
    if decision是工具调用: 校验并执行，保存结果
    if 超预算/高风险/连续失败: 停止并转人工

A03状态机让复杂任务可解释

程序控制结构 State Machine状态机把流程表示成有限状态和允许的转换。状态保存在数据库，模型只能提出下一状态，程序检查转换是否合法。

不允许从collecting_info直接跳到refund_completed；即使模型这样要求，状态机也拒绝。

A04Planner、Executor 与 Verifier 的职责

A05Checkpoint检查点与断点恢复

Checkpoint是每个重要步骤后保存的可靠快照，包括任务ID、当前状态、已完成步骤、工具调用ID、结果摘要、下一步和版本。服务重启后从最后检查点继续。

{
 "task_id":"refund-task-88",
 "state":"awaiting_confirmation",
 "completed":["get_order","check_policy"],
 "pending":"user_confirmation",
 "workflow_version":"refund-v3"
}

不要只保存一大段聊天文字；程序需要明确知道哪些真实操作已经成功。

A06有限循环、预算和停止条件

Agent必须同时有：最大步数、最大工具调用数、总Token/费用预算、总耗时、单工具超时、连续失败上限、允许工具列表和明确完成条件。

A07Human-in-the-loop 人工控制点

人工控制点 系统要保存并展示：用户目标、模型建议、依据资料、准备执行的工具与参数、风险提示、已完成步骤。人工可以批准、修改、拒绝或接管，决定也要写审计日志。

如果人工只能看到“AI不确定，请处理”，却看不到上下文和已执行步骤，转人工会造成重复询问和误操作。

A08失败补偿与Saga思路

跨多个系统的操作很难使用一个数据库事务全部回滚。Saga表示把长流程拆成多个本地操作，并为已成功步骤设计补偿动作。

成功：创建退款 → 取消发货 → 发通知
若取消发货失败：
  不要再次创建退款
  记录退款已创建、发货取消失败
  尝试补偿/人工介入，并告知真实状态

补偿不一定能恢复原状，例如邮件发出后无法“收回用户已经看到的内容”，因此执行前确认更重要。

A09多 Agent 的适用条件

多Agent是多个受限角色通过消息协作，例如检索Agent、订单Agent和审查Agent。它会增加调用次数、延迟、状态同步和错误传播。

默认不用：一个模型加清晰工具和确定性工作流能完成时，不拆多Agent。只有角色权限必须隔离、任务确实可并行、或不同专业模型收益经评测证实时才使用。

A10退款Agent完整执行轨迹

request_id=req-9 / task_id=task-88
1 intent识别：退款进度查询（不改业务）
2 get_order：成功，订单属于当前用户
3 retrieve_policy：命中v4有效政策
4 判断：只需查询，无写操作
5 get_refund_status：成功
6 verifier：订单号、状态、引用齐全
7 final：生成回答并记录trace

若用户要求立即退款：进入awaiting_confirmation，不直接执行。