技术观察工作流：把 AI 智能体的试错记录变成可验证的规则

长期运行的 AI 智能体有一个反复出现的难题：一次失败之后，团队往往会在下一次尝试前补上一句提示或一条规则，希望它别再犯同样的错。问题在于，这条规则如果本身是错的，失败就会被继承下去，而且越积越多，最后没人说得清哪条规则来自哪次事故。这篇教程讲的就是围绕这个问题的工程做法：怎样从试错记录里抽出短规则、怎样用两个不同的指标判断规则是否值得保留、怎样让每条规则都能追溯到它的来源。适合正在把智能体投入重复性业务流程、并且需要向他人解释「为什么它这次这么做」的团队。文中涉及的具体版本号、功能开关与配额，请以各产品官网当前信息为准。

准备工作

在动手之前，需要先把几件事定下来。这些不是软件安装步骤，而是让后续流程能跑通的前置条件。

明确要优化的业务场景

规则抽取不是通用能力，它依赖具体的任务分布。先选定一个边界清楚的场景，例如订单修改、退款审批、数据库更新前的确认。场景越窄，抽出的规则越可检验。素材中的实验选择的是零售业务中的客户服务任务，这类任务有明确的对错判定，也有可重复的模拟环境。

准备可重复的评测集

需要一组固定的任务，每个任务都能被反复执行，并且有明确的成功判定。关键点是：同一个任务要能被跑多次，而不只是跑一次。因为后面要用到「连续多次成功」这个指标，如果评测集只能跑一遍，这个指标就无从计算。

确定记录格式

每次试运行至少要留下四类信息：

• 本次任务是什么（输入）
• 智能体实际执行了哪些操作（动作序列）
• 结果是成功还是失败，失败在哪一步
• 本次运行使用了哪些已有规则

这四类信息缺一不可。缺少动作序列，就无法判断失败是规则错了还是执行错了；缺少规则引用，就无法在规则更新后回溯影响范围。

准备规则存储与版本管理

规则不能只写在提示词里。需要一份可版本化的规则清单，每条规则带唯一标识、正文、来源试运行编号、加入时间、当前状态（启用 / 停用 / 待验证）。这份清单可以用配置文件、数据库表或任何支持差异对比的形式保存，重点是能看出「这条规则是什么时候、因为哪次失败加进来的」。

操作步骤

第一步：跑基线，先不要加任何规则

在引入规则之前，先用评测集跑一轮完整基线。这一轮的目的不是看智能体有多强，而是拿到两个基准数字：平均成功率，以及同一任务连续多次全部成功的比例。

以零售客户服务任务为例，素材给出的基线是平均成功率 78.1%，四轮连续成功比例 57.5%。这两个数字的差距本身就说明问题：平均能过八成，但能稳定四次全过的只有不到六成。如果只看平均值，会高估系统的稳定性。

基线跑完后，把每次运行的记录按前面约定的四类信息存档。后续所有规则的效果都要和这一轮对比。

第二步：从失败记录中抽取短规则

规则抽取的输入是失败运行的记录，输出是一句可执行的行为约束。素材中给出的规则形态是这样的：

• 先确认客户身份，再修改订单
• 更新数据库之前先取得批准

这类规则有几个共同特征：短、以动作顺序表达、不涉及具体业务数据、可以直接拼进下一次运行的指令里。抽取时要注意，规则描述的是「做什么、按什么顺序做」，而不是「为什么失败」。原因分析留在记录里，规则本身只保留可执行的部分。

抽取过程中，同一条规则可能从多次不同的失败中被归纳出来。这时要记录它出现的次数，这个计数在下一步会用到。

第三步：选择规则的保留策略

规则抽出来之后，不是全部保留。素材中的实验对比了两种策略：

• 严格保留：只保留在多次不同训练任务中都出现过的规则，即出现次数达到某个阈值
• 宽松保留：把抽出的规则尽量都保留下来

两种策略的结果并不一致，这一点很关键。在零售任务上，宽松保留把平均成功率从 78.1% 提到 82.5%，把四轮连续成功比例从 57.5% 提到 67.5%。但在航空业务任务上，宽松保留的平均成功率更高，四轮连续成功比例却不如严格保留的短规则集合。

这意味着「规则越多越好」不成立。规则数量增加会提升单次表现的上限，但也可能引入互相干扰的约束，损害重复执行时的稳定性。选择策略时要看你的业务更在意哪一个指标：如果是一次性任务，平均成功率更重要；如果是反复执行的流程，连续成功比例更能反映实际体验。

第四步：把规则注入下一次运行

规则注入的方式是拼接进执行指令，而不是修改模型权重。素材明确说明这一方法不改变模型参数，规则以文本形式附加在每次运行的指令中。这样做的好处是规则可以随时增删、随时回滚，代价是规则会占用上下文，规则太多时可能互相冲突或被忽略。

注入时建议按场景分组，只注入与当前任务相关的规则，而不是把全部规则一次性塞进去。规则清单越长，单条规则被遵守的概率越难保证。

第五步：用两个指标评估，而不是一个

规则更新后，用同一套评测集重跑，并同时记录两个数字：

指标	含义	适用判断
平均成功率	所有任务单次执行的成功比例	反映单次任务的能力上限
连续多次成功比例	同一任务连续 N 次全部成功的比例	反映重复执行时的稳定性

素材中的对比数据是：无规则时平均成功率 78.1%、四轮连续成功 57.5%；宽松保留规则后分别为 82.5% 和 67.5%。注意这两个提升幅度不同，连续成功比例的提升更明显，说明规则主要改善的是稳定性而非单次能力。

需要强调的是，四轮连续成功是在模拟任务上测出的稳定性指标，不能直接等同于真实业务中的重复成功率。真实环境的输入分布更杂，规则覆盖不到的情况更多。

第六步：为每条规则保留来源

这是整个流程里最容易被省略、但对团队协作最重要的一步。每条规则都要能回答三个问题：它来自哪次试运行、它被应用在哪些任务上、应用后的评估结果如何。

具体做法是在规则清单里为每条规则维护以下字段：

• 规则标识：唯一编号，便于在运行日志中引用
• 规则正文：一句话的行为约束
• 来源试运行：触发这条规则的失败记录编号，可能有多条
• 出现次数：在不同训练任务中被归纳出的次数
• 启用状态：启用、停用、待验证
• 评估结果：启用前后两个指标的变化

有了这些字段，当某条规则导致新的失败时，可以快速定位它影响了哪些任务，并决定是修改还是停用。没有来源信息的规则，团队很难判断该不该保留，最终往往变成谁也不敢删的历史包袱。

第七步：建立规则更新的回归流程

规则更新后必须重跑同一套评测，并对比变化。建议把流程固定为：

1. 新增或修改一条规则，状态标为「待验证」
2. 用完整评测集跑一轮，记录两个指标
3. 与上一版结果对比，确认没有引入新的失败模式
4. 通过则标为「启用」，未通过则回退或修改

这个循环的关键是「同一套评测集」。如果每次评测用的任务不同，前后数字就没有可比性，规则的效果也就无从判断。

一个完整示例

下面用一个最小化的流程串起前面的步骤。示例中的数字取自零售客户服务任务的公开实验数据，仅用于说明流程，不代表你的业务场景会得到相同结果。

1. 建立基线

准备一组可重复执行的客户服务任务，每个任务跑四轮，记录每轮结果。

任务集：T1 ... Tn
轮次：4
记录字段：task_id, run_id, actions, result, rules_used

基线结果：
平均成功率        = 78.1%
四轮连续成功比例  = 57.5%

2. 抽取规则

从失败记录中归纳出短规则，并统计每条规则在不同任务中出现的次数。

R001  先确认客户身份，再修改订单
       来源：run_0032, run_0117, run_0204
       出现次数：3

R002  更新数据库之前先取得批准
       来源：run_0089, run_0156
       出现次数：2

3. 注入并重跑

把规则拼进执行指令，用同一套任务集重跑四轮。

注入方式：在执行指令末尾附加规则清单
模型权重：不修改

宽松保留全部规则后的结果：
平均成功率        = 82.5%
四轮连续成功比例  = 67.5%

4. 对比与决策

把结果与基线并排看：

条件	平均成功率	四轮连续成功
无规则	78.1%	57.5%
宽松保留规则	82.5%	67.5%

两个指标都上升，说明在这组任务上规则是有效的。但不要就此停止：换一组任务类型再测一次，看结论是否稳定。素材中航空业务任务就出现了平均成功率上升、连续成功比例反而下降的情况，说明规则的效果依赖任务分布。

5. 记录来源并归档

把每条规则的来源、出现次数、启用状态和评估结果写入规则清单，与本次评测结果一起归档。下次修改规则时，从这份清单出发，而不是从零开始回忆。

注意事项

规则会继承错误

这是整个方法最大的风险。一条从失败中归纳出的规则，如果归纳本身是错的，后续所有运行都会带着这个错误。缓解办法是保留来源信息，并在规则启用前用评测集验证，而不是直接上线。

平均成功率会掩盖不稳定

只看平均成功率，可能把「偶尔成功」误认为「稳定可用」。素材中基线平均成功率接近八成，但四轮连续成功只有不到六成，差距明显。面向重复性业务时，连续成功比例更值得关注。

规则数量与效果不是单调关系

宽松保留在部分任务上更好，在另一些任务上不如严格保留。不要假设规则越多越好，也不要假设出现次数多的规则一定更可靠。两种策略都应在自己的任务集上实测。

模拟指标不等于生产指标

四轮连续成功是在模拟任务上测得的稳定性指标，不能直接当作真实业务中的成功率。真实输入的多样性、规则覆盖的盲区、执行环境的差异都会影响结果。把模拟评测当作筛选手段，而不是上线承诺。

读取与写入需要分开授权

如果智能体在流程中既要读取项目信息、又要修改文件或数据，应把这两类操作分成不同的权限。素材中提到，工具预检查环节增加了标识只读属性的字段，用于区分读取与写入。设计审批界面时，把「读取」「提出建议」「实际修改」作为三个不同操作呈现，比笼统的「允许」更有意义。

确认提示过多会失效

为了安全不断增加确认步骤，最终会让使用者不再阅读确认内容。只保留真正有意义的边界，并用简短的方式说明「会读什么、会改什么」，比堆叠确认框更有效。

规则清单需要定期清理

长期运行后，规则清单会积累大量历史条目。建议定期检查每条规则的最近一次评估结果，对长期未验证或已被新规则覆盖的条目做停用处理。清单的可读性直接决定团队能否继续维护它。