agent 的猜想会自我强化，得给提交单独设卡

你让 agent 整理客户档案，它把两家名字相近的公司并成一条。之后它每次检索都顺着这个错误去找，查回来的结果看起来全在「证实」这次合并。数据被写坏了，想再拆开，比当初合并难得多。

一、发生了什么

一篇 10 月 27 日提交的论文研究的就是这个场景。这类系统被称作 Agentic Entity Resolution：agent 自己规划步骤、检索证据、修正假设，最后对身份图谱提出修改。作者 Daniel Beránek 指出，一个错误的身份假设会污染后续检索，制造出表面上的确认。

论文的思路是把证据分成两档。一档只供 agent 推理用；另一档才有资格授权那些会持久改变身份记录的操作。方案以数字身份优化（DIO）与数字身份本体（ODI）两个框架为底，用一个由领域规则约束的绑定函数，把历史上重建失败时常见的混淆类型，转换成明确的身份保持约束。

把关的是一个两阶段监督器。只有当每个必要命题都有授权级证据支持、相关冲突已经解决、操作在授权范围内、状态与策略版本仍有效时，提交才被放行。条目被标记为未验证，并不因此获得授权资格，证据晋升走单独的通道。证据不够、或者存在未解决的重大冲突，操作一律延期，而不是降格放行。

论文把整套东西连成一份规格：从诊断到约束的映射、证据晋升、命题覆盖、冲突处理、范围绑定，一直到提交时的版本完整性，环节逐个写死。它还附了一个评测协议的设想，用来衡量这套约束相对通用授权和常规标识符规则到底多出多少价值——只是设想，尚未执行。

要说明白：这只是一个概念架构，没有实现，没有实验。作者自己声明它不保证语义正确，也拦不住错误假设本身——假设引导的检索仍是开放问题。

二、跟你有什么关系

做 agent 的人：推理上下文和授权上下文应当当成两个权限面，不是一个。做数据治理的人：写坏的记录比丢一条难收拾，提交前的门槛值得先建。写论文的人：这是一篇把直觉问题写成可评审规格的示范作。

三、怎么判断

1. 你的 agent 会不会把记忆里未经验证的条目当事实引用？会，就有同类风险。
2. 关键写操作之前，有没有一道独立于对话上下文的确认层？
3. 出错之后，能否追溯是哪一次假设污染了检索？
4. 三问里有一问答不上，先别让 agent 自动合并数据。

四、三个别信的说法

模型足够聪明就不会犯这种错。 聪明改变不了结构：假设引导检索，检索喂养假设，循环本身在放大错误。

提示词里提醒它谨慎就够了。 提示词是软约束，挡不住一次持久化写入。硬边界要落在流程和权限上，不落在措辞上。

这种问题离生产很远。 客户数据合并、知识图谱清洗、病历关联，全是 agent 正在接手的真实场景，错一条就是一笔账。

出了错让模型自己反思就能纠正。 论文里说得很清楚，这套边界不负责阻止错误假设，也不处理被假设引导的检索。依赖感知的证据流仍是未来工作，别把止损寄望于模型的自省。

五、一句话结论

让 agent 自由推理，但签发写数据的授权，得另设一道门。

信息来源

• arXiv 摘要页：提交边界授权护栏

事实引自 2026 年 10 月 27 日提交的论文摘要。

功能与价格以官方公告为准。本文写于 2026 年 10 月 28 日。