返回首页

对比阅读

对比阅读:Agent Calls Can Succeed While Targeting the Wrong Record 与 Agent 参数全绿也可能写错对象,单纯校验格式已不够

AEN
AgentJSON SchemaParameter Fabrication·

Agent Calls Can Succeed While Targeting the Wrong Record

After an Agent fails to find its target record, it may pick another numeric identifier from the context and proceed: the tool name, parameter type, and API status are all valid, but the operation ultimately lands on the wrong object. This shows that the AI failures most likely to slip through in production are not failures to call a tool correctly, but successful calls that accomplish the wrong task.

What this is

The article calls this problem “parameter fabrication.” An Agent—an AI application capable of autonomously invoking tools, planning steps, and executing tasks—correctly understands that the query returned no results, but instead of stopping, it finds a string ID with a matching shape in the context and inserts it into the next call.

Existing checks focus mainly on whether an answer is factually wrong, or whether an action faithfully follows the instructions, execution history, and environment observations. Parameter fabrication occurs between observation and action. The fabricated content may be entirely valid, but it applies to the wrong record. Strict JSON Schema—a structural constraint that specifies parameter names, types, and formats—can guarantee only that a value “looks right,” not that it “came from the right place.”

A more reliable governance model is to make every critical parameter traceable to an explicit source, and to stop and request clarification when no source can be found. A further step is to let the model submit only a reference path while the execution engine retrieves the actual value, then echo back the target for confirmation before high-risk actions such as writes, notifications, fund transfers, and status changes.

Industry view

We see enterprise Agent monitoring shifting from “whether the call succeeded” to “whether it acted on the correct object.” A green dashboard for error and timeout rates cannot establish business correctness. Parameter source validation and business reconciliation have therefore become critical parts of post-deployment governance.

This approach also has costs. Source allowlists and workflow constraints increase system coupling; dereferencing values requires changes to the toolchain; and confirmation for high-risk actions introduces an extra human step. Test sets must also cover empty results, missing fields, and similar identifiers rather than only happy paths. More importantly, rules alone cannot capture every business meaning, and source validation can break when the model, prompt, or tool description changes. Continuous server-side verification remains necessary.

Impact on regular people

For enterprise IT: Connecting an Agent to APIs is not enough. Teams must also establish parameter provenance, pre-execution verification, and business reconciliation. Otherwise, errors may be written directly to production data without appearing in conventional monitoring.

For workplace productivity: When using Agents that can handle tasks on their behalf, users should initially permit them to read information and provide recommendations, while retaining confirmation steps for payments, outbound messages, and status changes.

For the consumer market: AI assistants will play deeper roles in ticketing, customer service, and after-sales workflows. Providers must clearly show users the final target object so that a “successful execution” does not mean the wrong task was completed.

来源: juejin.cn
BZH
AgentJSON Schema参数编造·

Agent 参数全绿也可能写错对象,单纯校验格式已不够

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

这是什么

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

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

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

行业怎么看

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

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

对普通人的影响

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

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

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

来源: juejin.cn