AI Agent 上线前如何设计步骤上限与停止条件

原型中的 Agent 可以在失败后继续搜索、换工具或重写计划，但上线后，“继续尝试”会变成实际风险：重复调用持续消耗资源，错误参数可能反复写入外部系统，任务最后也无法说明停在哪一步。生产化的关键不是让 Agent 获得更多自主权，而是把它放进可观察、可终止的工作流中。本文从状态、步骤预算、错误分类和人工接管四方面设计停止条件，使每次运行都能回答当前阶段、已执行动作和为何结束。

先把目标写成完成谓词

“收集资料并生成报告”不是可判定的结束条件。应把完成状态拆成能够检查的谓词：

required_sources_found：已获得要求数量和类型的可访问来源
facts_verified：关键字段通过规则或人工核验
draft_created：产物写入指定位置并能重新读取
review_passed：预定义检查没有阻断项

工作流只有在必要谓词都为真时才进入 completed。模型说“已完成”不能替代文件、接口响应或校验程序提供的证据。

用显式状态代替自由循环

一个受限工作流可以包含：

received → planning → executing → validating
    ↘ blocked       ↘ awaiting_approval
validating → completed | needs_revision | failed

每次转换记录前一状态、目标状态、触发事件和证据。不存在于状态表中的转换直接拒绝。例如 planning 不能跳过执行和验证进入 completed。

状态数据应由工作流引擎维护，不能只存在模型对话中。模型可以建议下一动作，但转换是否允许由确定性规则判断。

给每次运行分配步骤预算

预算不只是模型调用次数，还包括工具调用、相同错误重试和外部写入：

{
  "max_steps": 12,
  "max_tool_calls": 8,
  "max_same_error": 2,
  "max_external_writes": 1
}

数字应依据任务测试确定，示例只表示配置结构。每执行一步先扣减对应预算；预算耗尽时进入 blocked 或 failed，并输出已经收集的证据，不再要求模型“最后再试一次”。

按错误类别决定是否重试

不是所有失败都适合重试：

错误类别	处理方式
临时网络失败	有限次数、带退避重试
认证失败	立即停止，检查凭据
权限不足	立即停止，请求授权
输入校验失败	返回调用方修正输入
工具不存在或参数不兼容	停止并记录能力差异
外部写入状态未知	先查询状态，不直接重写
相同未知错误重复出现	停止并交给人工

错误分类来自工具返回的稳定状态，而不是让模型从任意文本中猜测。工具应把用户错误、权限错误和服务端错误区分开。

外部写入采用两阶段动作

发送消息、创建工单或修改记录前，先生成变更计划：

目标对象
将写入的字段
与当前状态的差异
幂等标识
撤销或补偿方式

工作流进入 awaiting_approval，获得授权后才执行。执行超时后，使用幂等标识查询结果；若无法确认状态，停止并标记 unknown，不能再次提交相同写入。

验证节点必须独立于生成节点

生成节点负责产生候选结果，验证节点使用确定性检查或独立人工规则验收。例如：

• JSON 是否通过 Schema 校验；
• 文件是否存在且能重新解析；
• 引用的来源标识是否都能在来源表中找到；
• 代码目标测试和回归测试是否实际通过；
• 外部系统是否返回可查询的资源标识。

验证失败时只把具体失败项送回修订，不让 Agent 重做整个任务。修订仍消耗步骤预算。

为人工接管准备最小状态包

进入 blocked、failed 或 unknown 时，输出：

run_id 与当前状态
原始目标和完成谓词
已执行步骤与工具结果摘要
最后一个稳定检查点
错误类别和重复次数
已产生的外部副作用
剩余预算
需要人工决定的问题

状态包不应包含密钥、完整敏感输入或无法核实的推断。人工处理后通过明确事件恢复，例如 credential_replaced 或 approval_granted，而不是直接把状态改为完成。

用故障注入测试停止条件

上线前主动构造：

• 工具连续超时；
• 凭据失效；
• 输入缺少必填字段；
• 输出 Schema 不合法；
• 写入成功但响应丢失；
• 验证持续失败；
• 达到步骤和工具调用上限。

验收重点不是 Agent 能否“想办法成功”，而是它能否在规定状态停止、不重复副作用，并留下足够的接管证据。

结论与限制

可上线的 Agent 工作流需要显式完成谓词、状态转换、步骤预算、错误分类和人工接管。模型负责提出动作，确定性控制层负责判断动作是否允许以及何时停止，才能避免开放式循环扩大失败。

本文是通用控制模型，不包含特定框架的实现接口。实际预算与重试策略必须根据工具幂等性、任务风险和故障测试确定；对于付款、权限变更等高风险动作，仍应采用专门业务流程和人工审批。