我的基础设施分析智能体陷入了一个我尚未命名的循环中。
它会编写一个包含虚构列名的结构化查询语言（SQL）查询。该查询会因 PostgreSQL 错误而失败。我的错误处理程序会从 pg_attribute 返回真实的列列表作为响应。智能体会读取这些信息，在其推理轨迹中确认修正，然后在下一次尝试中写出完全相同的错误列名。
不是不同的错误列，而是同一个。
我开始称这种现象为“虚构级联”。以下是实际发生的情况、为什么这更多是一个工具设计问题而非模型问题，以及我对此采取的措施。
背景设置
Nexus 是我的个人智能平台。它运行着 8 个以上的自主智能体，针对一个包含 191 张表的 PostgreSQL 数据库模式执行操作，例如每周生活章节分析、关系健康跟踪，以及基于 24 年个人数据进行传记推断。基础设施分析智能体负责查询这些表，以发现模式和异常。
当智能体在 Nexus 中编写 SQL 时，它们会通过 tool-executor.ts 中的 handleQueryDb 函数进行处理。该处理程序强制仅允许 SELECT 访问权限，应用智能体作用域的角色，并在失败时调用 query-db-schema-hint.ts 中的 buildQueryDbSchemaHint() 来增强错误消息。
问题就出在最后这一步。
被动式模式提示
buildQueryDbSchemaHint() 执行两项操作：
当出现“列不存在”错误时：内省
pg_attribute并返回该表的真实列列表当出现“表不存在”错误时：在
pg_class中搜索相似的表名并提供建议
这很有用。当触发时，智能体会获得准确的模式信息。问题在于“当”这个词。这种提示完全是被动的。它仅在查询失败后才会触发。
没有 describe_table 工具。没有 get_schema 调用。智能体无法在编写 SQL 之前询问“aurora_life_chapters 有哪些列？”。获取真实信息的唯一途径是试错。
因此，智能体的循环如下：
生成查询。列名来自训练权重加上上下文——称之为一个自信的先验概率。
查询失败。错误消息带着真实列列表到达。
智能体将修正作为上下文处理，用于下一次生成。
训练先验概率重新占据主导。相同的错误列名出现在新查询中。
回到第 1 步。
智能体并没有忽略修正。它接收到了两个相互竞争的信号：一个是基于现实的错误消息修正，另一个是嵌入在模型权重中更强的模式先验概率。修正只出现一次。而先验概率在每个令牌生成时都会出现。猜猜哪一个赢了。
为什么这是一个工具设计问题
人们很容易将此归结为“模型应该更加关注错误消息”。这种 framing 将修复工作置于提示工程领域——增加强调、重新排序上下文、告诉模型这次一定要认真阅读提示。
这可能会在边际上有所帮助。但它无法解决结构性问题。
结构性问题在于，我设计了一个工具界面，使得自信地猜测成为获取准确信息的唯一入口。智能体在行动前无法验证结构。它只能通过失败来学习。当模型的训练先验概率很强时，这种学习通道是有损耗的。
将其与你为人类设计工具的方式进行比较。如果你给人类提供一个应用程序接口（API），而他们询问接受哪些字段，你会给他们提供文档。你不会让他们提交格式错误的请求，直到错误消息教会他们
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
