麦睿菱AI实践 07｜自动化失败后，工作怎样继续

条件已经不对，自动化却还能顺利跑完，这比一次清楚报错更值得警惕。企业决定让智能体接手多少工作，需要检查错误在哪里被发现、任务怎样停止，以及人工接手后如何继续。正常路径、失败交接和恢复条件一起验收，才看得清这段自动化减少了多少工作。

设想一份每周生成的性能核验报告：计算没有报错，所选曲线却还处在升温阶段，尚未进入约定工况。报告已经用错了依据。

团队可能只把顺利的一次操作录下来：读数据、选区间、算指标、填模板。换一批数据后，流程仍能跑完，却没有检查这批数据是否适合照做。

先选一个边界明确的工作段

把“生成报告”拆开，就能看到不同性质的劳动。

客户要求需要从文本中提取，型号、标准和工况要逐项核对；有效数据区间需要有依据；按已确定口径计算指标，可以交给经过测试的程序；陌生异常的解释和出厂批准，则涉及新的事实、专业责任与授权。

这些步骤适合采用不同的处理方式。单位换算可以交给确定的程序，客户描述中的不规范表达可以由模型辅助整理，最终参数和适用条件再按要求核对。

选一个边界明确的起点，往往更容易看清价值。例如，先把“读取指定数据、检查必要字段、按确认口径计算、生成待审附件”做好，保留后面的专业判断。再用真实任务检查，这一段能否减少读取、计算和整理附件的时间。

在 MEASIX 的产品分工中，衡准 Metrivon[1]面向精密测量与设备协同，报告要能追查相应采集条件、专业计算和复核依据。开发候选脚本、比较输出和运行测试时，可由自托管工作空间工舱 Runcove[1]承载获准的文件处理与程序运行。候选脚本先在样本上验证，纳入正式测量流程前，再完成专业评审和设备侧验证、批准。

按任务选择工作流或智能体

输入通过检查后计算，计算成功后生成待审材料，条件不满足就转人工，这种步骤和分支可以预先安排成工作流。

若客户没有写清工况，系统可能需要先查手册，再发现资料冲突，随后向员工提问。这类根据中间结果选择下一步的工作，可以由智能体辅助推进。Anthropic 对工作流与智能体的区分[2]，重点就在于路径是预先确定，还是由模型动态选择。

在这类任务中，可以授权智能体选择查阅资料的顺序。试验要求由有权人员确认，提取的参数和必要条件也要经过核对。无论模型位于哪一个步骤，都需要明确它可以作哪些选择，以及结果通过什么检查。图1同时列出正常推进和异常接手的要求。

图1｜工作分工与异常恢复路径示意

若困难在客户文件中的工业术语、缩写和条件提取，可把知衡 Noetral[1]这样的工业领域模型纳入同任务测试。比较要求提取是否准确、依据是否完整、缺条件时能否正确停止，以及运行与复核负担，再决定是否采用。

验收时故意放入不该通过的材料

验收既要检查正常任务能否做对，也要检查不适用的输入能否被识别和拦下。

对于前面的报告，可以准备几类测试：一份条件完整的输入，一份缺单位的输入，一份型号相近但不匹配的输入，以及一份曲线平稳、工况记录却不满足要求的输入。

最后一种尤其重要。它能揭示检查是不是只盯着数值。如果系统仅凭“曲线看起来稳定”就认定工况正确，即使后续公式完全正确，也会一路错到结论。

每个样本都应写明预期结果：该输出什么，哪一步必须停止，交给人时应留下哪些材料。可以程序核验的地方，用程序检查；方法适用性和证据是否充分，由具备资格的人员判断。模型可辅助筛查，但其评分也要用人工已判定的样本校准。

测试应逐步覆盖真实变化，包括曾经出错的情况、新增设备配置以及工具失败。关键模型步骤还需要重复运行，观察结果与处理路径是否稳定。

若某类错误只有客户收到报告后才容易发现，就应先收窄自动化范围。例如只形成计算附件，由人判断适用性；或者提供候选区间，保留人工选择。仍可单独检验前面这段是否节省时间。

给人工审核留出条件

人工审核需要看得见依据。如果完整报告把关键依据藏得很深，审核人可能要重做整套分析。

有效审核至少要方便查看：本次对象与配置、原始曲线、所选区间、计算口径和未解决的问题。审核人还需要时间、有权推翻建议，并知道疑点该交给谁。试用时记录审核耗时和待审数量，确认他有足够的时间认真核对。

权限也要落在实际操作上。只读数据、生成草稿、调整设备参数和批准出厂，后果不同，需要分别设置工具权限、应用检查和业务批准，并验证越权操作能被拦下。

停止时留下可接手的材料

如果系统发现工况记录缺失后停下，只留一句“失败，请人工处理”，接手人仍要重新找数据、确认版本、重跑计算。正常时省下的劳动，又在异常时被花掉。

更有用的交接应该说明：已完成哪些步骤，采用哪些输入和版本，哪项检查未通过，最后可信结果在哪里，以及还缺什么事实。输入被纠正后，也应知道哪些后续产物需要重新生成，避免继续沿用旧结果。

工具超时则有另一种风险。读取失败和设备动作回执丢失，不能一律处理成“再执行一次”。后者可能已经完成，只是结果没有传回。应先查询状态，无法确定时转交处理。

同一个请求重复到达，也不应因此多做一次设备动作。技术上常用幂等性[3]来约束重复请求的影响。例如，同一请求标识和同样输入重复提交时，只返回已有任务，不新建一次执行；输入改变则另作新请求。这个能力需要由服务实现，并通过重复提交、超时等测试验证。

恢复还需要任务状态、可信产物和明确的继续条件。验收时可以安排一次中断，检查接手者能否沿着已有证据继续处理。

扩大范围之前先算上异常工作

一段自动化工作的试用账，应同时包括正常处理、人工复核、失败恢复和版本维护。如果简单程序已经解决问题，就让它保持简单；如果任务少、条件常变，由员工借助 AI 完成，可能比建设完整自动运行机制更合适。

这一段在正常和异常情况下都通过检验后，再考虑扩大范围。员工遇到的新情况可补充为候选测试，经整理、测试和专业验证后，更新给后续使用者。

下一次讨论“把整份报告自动化”时，可以先选出一个工作段，让它接受三项检验：正常时能做对，不适用时能停下，交给人时能接着做。

把审核和恢复所需的工作也算进去，再决定是否增加下一段。

参考阅读

[1] MEASIX：衡准 Metrivon、工舱 Runcove与知衡 Noetral

[2] Anthropic：Building effective agents

[3] AWS Builders’ Library：幂等接口与可靠重试