同一日正式报告与轻量摘要共用日期文件时，后一次写入可能覆盖前一次；文章披露的 ETF Agent 测试中，两份 JSON 都合法，历史记录指向的内容却已错位。这说明“写入成功”不等于“报告身份正确”。

这是什么

这不是模型幻觉，而是软件工程中的版本身份问题。系统原本按日期生成文件，正式报告 A 先写入，轻量报告 B 随后覆盖同名文件；A 的历史记录仍保存原路径，但该路径已经指向 B。

修复方式不是提示模型“注意时间”，而是让正式报告与辅助报告进入不同目录，限定读取范围。系统还区分生成时间、报告日期、持仓基线日期和数据来源时间，避免把旧净值配成今日建议。原子写入只能保证读者看到完整旧文件或完整新文件，不能保证读到原来的那一版。

行业怎么看

这篇文章最值得借鉴的，不是基金报告本身，而是“先定义业务事实，再允许 Agent 消费”的方法。模型负责研究与表达，确定性程序负责金额计算、约束校验和发布；可展示的数据也不等于可用于下单的数据。

但风险同样明确。目录隔离、日期命名和私有读取链仍依赖配置与部署纪律。文章也承认，文件替换与历史存储写入并非同一事务，断电持久性、并发写入协调及长期可追溯性，仍需按实际环境验证。把它上升为通用 Agent 架构原则，未免过快；更稳妥的判断是，企业可以借鉴身份隔离思路，但不能把一套局部实现当成端到端一致性方案。

对普通人的影响

对企业 IT：企业部署 AI 报告、合同或客服记录时，应把正式产物与摘要、缓存、草稿分开存放，并保留唯一运行标识；否则“生成成功”可能掩盖错链和覆盖。

对个人职场：使用 AI 整理投资、经营或项目材料时，要检查数据时点和版本，不应把摘要当成最新事实。关键结论仍需回看原始文件与生成时间。

对消费市场：金融、健康等高风险应用会逐步要求生成依据、有效期和版本可追溯。消费者看到的可能不再只是一段 AI 回答，还会附带报告身份、更新时间及适用范围。