How ETF Agent Keeps Atomic Reports from Losing Their Identity
A Juejin AI engineering article describes a case where a same-day lightweight report replaced a formal portfolio report at the same date-based path, leaving the earlier run’s history pointing to different but still valid JSON. It attributes the problem to mismatched report identities, output paths, and discovery rules rather than model hallucination. The described private fix routes lightweight reports to a separate lightweight/ subdirectory and restricts formal consumers to the approved report root.
The case demonstrates that atomic file replacement can preserve file validity while breaking run identity, so report systems must isolate discovery scopes and verify saved identities rather than assume an old path still contains the same run.
早上生成了一份基金组合报告，里面有持仓、现金、市场证据和定投建议。下午系统又生成同一天的简版摘要。晚上，Agent 打开早上的正式报告，看到的却可能是下午摘要的内容。
文件没有损坏，JSON 甚至完全合法；错的是它已不再属于早上那次生成。这不是模型幻觉，而是报告身份、输出路径和读取约定没有对齐。
ETF Agent 曾在受控临时目录与 SQLite 验证中发现过这一类同日覆盖：正式报告 A 已进入历史记录，轻量报告 B 随后写入同一个日期文件名，A 的历史路径便指向了 B。修正办法不是给模型加一句“注意时间”，而是让正式报告和辅助产物拥有不同的可发现范围。
要理解这个修复，先要明确一份报告究竟代表什么。
一、报告不是六个临时结果的拼接
组合研究会陆续得到持仓、现金、市场数据、约束、建议和质量提示。如果把它们独立写成多个“最新文件”，读取者可能拿到周一的持仓、周二的净值以及周三的建议，最后拼成看似完整的今天。