一个 Agent 查询不到目标记录后，可能从上下文另找一个数字型编号继续执行：工具名、参数类型和接口状态全部正常，最终却把操作落在了错误对象上。这说明生产环境最容易漏掉的 AI 故障，不是“不会调用”，而是“调用成功却办错事”。

这是什么

文章把这种问题称为“参数编造”。Agent（能自主调用工具、规划步骤并执行任务的 AI 应用）准确理解了“查询结果为空”，却没有停止，而是从上下文找出一个形状匹配的字符串 ID，填进下一步调用。

现有检测多关注回答是否失实，或动作是否忠于指令、执行历史和环境观察；参数编造发生在观察与行动之间。错误内容可能完全成立，只是作用于错误记录。严格 JSON Schema（规定参数名称、类型和格式的结构约束）也只能保证“长得对”，不能保证“来自对的地方”。

更可靠的治理方式，是让关键参数可追溯到明确来源；找不到来源便中止并澄清。进一步可让模型只提交引用路径，由执行引擎取出实际值，并对写入、通知、资金和状态变更等高风险动作回显确认。

行业怎么看

我们注意到，企业 Agent 的监控指标正从“调用是否成功”转向“是否作用于正确对象”。错误率、超时率全绿并不能证明业务正确，参数来源校验和业务对账因此进入上线后的关键环节。

但这套办法也有成本。来源白名单和流程约束会增加系统耦合，引擎解引用需要改造工具链，高风险确认则多一步人工介入；测试集还必须覆盖空结果、缺字段和相似编号，不能只看正常流程。更重要的是，仅靠规则无法覆盖所有业务语义，来源校验也可能因模型、提示词或工具描述变化而失效，需要服务端持续复核。

对普通人的影响

对企业 IT：Agent 不应只接上接口，还要建立参数溯源、执行前复核和业务对账，否则错误可能直接落库，且常规监控无法发现。

对个人职场：使用能代办事务的 Agent 时，应优先允许读取和提供建议，对涉及付款、发送、状态变更的动作保留确认环节。

对消费市场：AI 助手会更深入参与订票、客服和售后流程，但服务方需要向用户明确展示最终对象，避免“执行成功、事项办错”。