“让 Agent 自己决定下一步”听起来很自然，但一旦它要调用业务系统，问题就变了：重复调用会不会创建两张工单？权限不足时是否还能读取结果？执行到一半失败后从哪里恢复？
我的判断是：模型适合处理开放问题和选择候选动作；执行、记账和恢复应交给确定性的工作流。
先分清建议与动作
同一个工具调用可能处于不同风险层级。查询订单是读取；生成报价草稿仍可回退；发送报价、修改权限或提交审批则会影响外部世界。系统应把工具声明成明确的动作契约：输入结构、权限、预期结果、幂等键、失败语义和审计字段。
模型可以提出“需要查询知识库”或“建议生成草稿”，但不能因为一段自然语言就绕过权限检查。高风险动作进入人工确认，并在确认后重新校验参数和权限，避免确认之前与执行时的状态已经不同。
用状态机代替无限循环
Agent 循环适合探索，却不适合独自承担长事务。一个实际可恢复的流程可以拆成：
接收目标 → 收集证据 → 形成计划 → 执行低风险步骤
↓
等待人工确认
↓
执行写入 → 验证结果
每个节点保存输入、输出和运行状态。超时或进程重启后，从最后一个已确认节点继续，而不是重放全部动作。写入工具需要幂等键；如果外部系统不支持幂等，至少要先查询是否已经完成，并记录无法自动判定的情况。
失败不该只剩一句“请重试”
一次失败可能发生在模型决策、检索、工具参数、外部 API、权限或结果验证。日志应把这些层次分开。用户看到的是可操作的状态，例如“草稿已生成，发送未执行，等待确认”，而不是一个笼统的失败提示。
评估 Agent 也不能只看最终回答是否漂亮。任务完成率、人工接管率、无效工具调用、重复写入、恢复成功率和平均成本，才更接近真实体验。每次改提示词或模型后，用固定任务集回放，才能知道系统究竟改善了什么。
Agent 不需要拥有所有控制权才有价值。清晰的边界让模型的灵活性可以用于解决问题，同时让业务系统保持可解释、可恢复和可审计。
幂等不等于“失败后再调用一次”
考虑“创建工单”接口超时：请求可能没有到达，也可能工单已经创建、只是响应丢了。直接重试可能生成两张工单。幂等键应由一次业务意图稳定地产生，在重试期间保持不变；执行侧用这个键查询已完成结果或拒绝重复写入。若第三方系统不支持幂等，工作流需要保存外部请求标识，超时后先核对状态。无法确认时进入人工核查，不能把不确定性包装成“已失败”。
同样，人工确认不是一个永远有效的通行证。用户确认的是当时的报价金额、收件人和文档版本；执行前若这些参数发生变化，系统应再次要求确认。将计划、确认快照和实际执行参数并排记录，审计时才能看出模型是否在确认后又改了目标。
给模型留出可用的自由度
如果每步都写死，Agent 只是昂贵的流程图；如果完全放开，故障恢复和权限又无法保证。比较合理的切分是让模型在一个受限集合内选择：下一步检索哪个知识源、是否需要补问、候选方案如何排序；执行器只接受经过结构校验和授权检查的动作。探索自由度留在“提出建议”，副作用边界留在“执行决定”。
这种切分也更方便评估。可以单独测模型是否提出了正确计划，再测执行器面对重复请求、权限不足和外部超时是否保持一致。否则一次任务失败时，很难知道是模型判断错了，还是确定性代码也没有守住约束。