假设你做了一个采购 Agent它会查库存、找合同、推荐供应商还能调用接口创建申请。演示时从一句需求到一张单据整个过程很顺。现在换个条件合同更新了负责人隔天才审批创建申请的接口又在返回前超时。它还能处理吗如果不能下一步未必是换模型。模型会影响理解和推理但它不能代替系统保存任务状态也不能自动替目标系统兑现幂等约定。先把这些缺口找出来才能判断模型升级到底有没有用。下面沿着这条假设采购任务整理七个值得检查的环节。场景为说明工程问题而简化不是实际项目复盘也不是完整上线标准。1. 输出契约返回 JSON只完成了第一道检查容易出的问题字段有了业务含义却没核对。比如模型返回物料编码、供应商和数量数量也是正整数。但物料编码不存在或者选中的供应商已停用。这份输出仍然不能进入执行。应检查什么先验证字段、类型、必填项和取值范围再查业务目录、对象状态和相关规则。两层检查分别记录失败时说明是哪一层没通过。Pydantic 这类工具可以帮助固定结构业务事实仍需要另外验证。不要让“解析成功”直接变成“可以创建采购申请”。2. 证据来源找到一份合同不代表找到有效合同容易出的问题检索到的内容看起来相关实际上已经过期或者请求人无权访问。比如补货方案引用旧价格但合同已经换版。模型推理再完整也是基于不适用的信息。应检查什么库存查询时间、合同版本、生效范围、原文位置以及访问主体的权限。涉及动态数据时在关键动作之前按业务需要重新核验。给用户的解释可以很简短后台要能找回对应依据。不能只存一段模型总结把真正的来源丢掉。3. 工具权限查库存和创建单据要分开看容易出的问题工具都能调用就误以为每个用户都能执行。比如只允许查看库存的员工通过聊天触发了采购创建或者查询工具没有限制租户读到了别的组织的数据。应检查什么用户身份、租户、资源范围、工具的读写属性和风险。权限判断要在工具或业务服务边界落实不能只在提示词里提醒模型。无权限的动作应当被拒绝。审批用于确认符合条件但风险较高的动作不能当作绕过权限的后门。4. 审批绑定同意方案不等于给后续操作通行证容易出的问题系统只留下一个“已批准”没有记录批准的具体内容。比如负责人确认供应商甲、数量二十。执行前模型改成供应商乙、数量三十系统仍沿用旧审批。应检查什么审批与任务、具体变更、目标工具和目标对象之间的关联。执行内容变化后应重新核对授权是否覆盖不覆盖就重新确认。最好在审批页让人看清准备修改什么、依据是什么。审批人不应通过猜聊天上下文承担一个范围不清的授权。5. 任务恢复服务重启不该把审批也重来一遍容易出的问题任务进度只存在当前进程或者藏在一长段聊天记录里。比如方案已经审批服务重启以后却只记得最初需求于是重新检索、重新生成甚至再次创建申请。应检查什么任务标识、当前状态、已确认方案、等待对象和外部动作结果能否持久保存。恢复后先核对这些记录再决定继续哪个步骤。简单后台任务可以先用队列和数据库状态。跨天等待、多个外部动作及复杂补偿出现后再评估长任务运行时不必一开始就把组件堆满。6. 重复执行控制接口超时不等于对方没做容易出的问题把“没收到成功响应”当成“执行失败”直接提交第二次。比如采购申请已经创建返回途中超时。重试用了一次全新的请求标识目标系统便创建了另一张。应检查什么同一个业务动作的重试能否使用稳定标识目标系统能否据此去重或查询已有结果。仅在调用方生成一个键并不能自动让对方具备幂等能力。还要分类处理错误权限拒绝要停止业务冲突需重新判断结果不确定先查询或接管。不要给所有异常套同一个重试循环。7. 评测与成本把“不该执行”也测出来容易出的问题测试集全是正常输入指标只看回答和单次模型价格。应该补上旧合同、缺少依据、越权请求、审批拒绝、重复消息、接口超时和任务重启这些场景。既检查该做的事是否完成也检查不该做的事有没有被挡住。成本则按完整任务看模型调用、检索、重试、等待和人工接管分别留下记录。便宜的单次调用如果反复返工也未必带来便宜的交付。这些检查项是我结合《企业级 AgentOS 架构设计与工程实践》整理的阅读笔记。书中用虚构采购异常逐步串起对象、流程、策略、写回和恢复适合对照理解它们为何需要配合。具体上线仍要结合自身业务验证框架接口也要核对对应版本。最后留一份可以对照的清单字段校验与业务校验分别完成。依据能回查版本和权限适用。查询与写入各有明确权限边界。审批覆盖这次执行的具体内容。重启后能辨认已完成和待确认步骤。重试不会悄悄重复同一业务动作。异常路径有验证完整任务有成本记录。这七项不是上线许可证。它们的作用是让排查从“是不是模型不行”变成“这一环到底缺了什么”。