一家制造企业的采购部把采购申请接进智能体让它识别需求后调用内部采购系统下单再调用库存系统更新数量。流程刚跑通问题就接连冒出来智能体把金额的元当成分传给财务接口把日期写成系统不认识的格式还漏传了必填的供应商编码。采购系统有时直接报错有时却照单收下用错误的数据生成了采购单。等采购员核对时金额已经差了一百倍单据也早流转到了审批环节。这类问题在企业AI应用开发中并不少见。不少团队把智能体调用内部系统简单理解成接口能调通就算接好了却忽略了从生成参数到真正执行之间还隔着一道参数是否合法、是否对得上的关口。接口能调通与参数能传对是两件不同的事。一种常见的误判是以为模型只要理解了用户意图参数自然就不会错。可模型生成参数带有概率性质单位、格式、枚举值这些细节稍不留神就会走样意图理解对了落到字段上的值仍可能填错。另一种误判是以为下游系统会替自己把关。可不少企业内部系统对传入参数并不做严格校验或者只校验类型对不对这一层单位是元还是分、日期格式对不对、枚举值在不在允许范围里它未必能识别出来错误参数就这样漏了过去。还有一种误判是以为出了问题再看日志就行。可当错误参数已被系统静默接受、落地成业务单据事后翻日志能查到错在哪却改不回已经发生的业务动作错误暴露得越晚纠正的代价就越高。拆开来看这类问题通常有三类原因。一类原因是工具定义缺少参数契约接口的字段类型、计量单位、日期格式、枚举范围、必填项没有在工具描述里写清楚模型缺少明确的参数规范可依只能凭感觉去猜。另一类原因是缺少类型与范围校验模型生成的参数在真正调用之前没有经过格式、单位、枚举值的强制校验非法值没有被拦下来直接递给了下游系统。还有一类原因是缺少执行前预检与失败处置参数校验失败之后既没有统一的拦截入口也没有清晰的失败路径该报错的时候没有报错该降级转人工的时候又直接放行。针对这些原因一种实现方式是把工具调用改造成先定义契约、再校验、后执行的流程。起始环节是参数契约定义把每个工具的字段名称、数据类型、计量单位、日期格式、枚举取值范围都写清楚并明确字段是否必填、是否允许为空仅对业务规则明确允许的字段设置默认值供应商、金额、账号、日期等关键参数缺失时阻止执行并补充信息而不是为了让接口通过自动填值。紧接着是类型与范围校验在参数生成之后、真正调用之前用独立的校验层对单位、格式、枚举值和必填项做强校验并补上跨字段约束例如起始日期不晚于结束日期、金额与币种和单位匹配。校验不依赖模型自觉由规则和约束把非法值挡在调用之前单位归一化只在原始单位和目标单位均明确、转换规则确定时才自动进行来源单位缺失或有歧义时应停止调用并要求澄清。再往后是执行前预检与参数规范化在实际执行前完成本地参数规范化和业务规则检查并确认必填字段齐全下游系统支持预检或 dry-run 时可进一步利用其预检能力。随后是失败处置与回退校验或预检不通过时走明确的失败路径能自动修正的就自动修正不能修正的明确报错并提示补充信息无法自动确定的关键参数或高风险业务动作再进入澄清、审批或人工确认而不是让一个错误参数带着未纠正的字段继续往下执行。本文基于青山不语AI工作室在部分企业AI应用开发项目方案中的实践将这套处理框架概括为工具参数约束与执行前校验。它要解决的不是让智能体能调通更多接口而是让每一次调用在真正执行之前参数都被定义清楚、校验到位把错误挡在业务动作发生之前。这里有一道边界需要企业自己拿捏。哪些字段必须强校验、哪些单位需要统一、参数校验失败后是自动修正还是转人工涉及企业的系统规范和业务容错要求。服务方提供的是参数契约、校验层和失败处置的机制具体的字段规则、单位和审批流程需要企业内部的系统和业务负责人确认。从行业观察来看企业评估AI应用开发服务时值得多问一句对方交付的系统有没有把参数契约、类型校验、执行前预检、失败处置作为一个整体来管理。我的判断是工具调用不是接口能通就上线的动作而是一条从参数定义到校验再到执行前预检的链路把错误参数挡在业务动作之前比事后翻日志追责更值得企业在开发阶段就重视。