ETF Agent如何守住原子报告身份
AI 总结
掘金·人工智能的一篇工程文章描述了一起同日覆盖问题：轻量报告写入正式报告的日期文件路径后，早先运行的记录虽保留原内容，其历史路径却指向另一份同样合法的 JSON。文章认为根因是报告身份、输出路径和读取约定未对齐，并非模型幻觉。其私有实现将轻量报告改写入独立的 lightweight/ 子目录，并把正式消费者限制在获准的报告根目录。
深度见解
这一案例表明，原子替换只能保证文件完整可见，无法单独保证运行身份，因此报告系统需要隔离发现范围并核验保存的身份。
早上生成了一份基金组合报告，里面有持仓、现金、市场证据和定投建议。下午系统又生成同一天的简版摘要。晚上，Agent 打开早上的正式报告，看到的却可能是下午摘要的内容。
文件没有损坏，JSON 甚至完全合法；错的是它已不再属于早上那次生成。这不是模型幻觉，而是报告身份、输出路径和读取约定没有对齐。
ETF Agent 曾在受控临时目录与 SQLite 验证中发现过这一类同日覆盖：正式报告 A 已进入历史记录，轻量报告 B 随后写入同一个日期文件名，A 的历史路径便指向了 B。修正办法不是给模型加一句“注意时间”，而是让正式报告和辅助产物拥有不同的可发现范围。
要理解这个修复，先要明确一份报告究竟代表什么。
一、报告不是六个临时结果的拼接
组合研究会陆续得到持仓、现金、市场数据、约束、建议和质量提示。如果把它们独立写成多个“最新文件”，读取者可能拿到周一的持仓、周二的净值以及周三的建议，最后拼成看似完整的今天。