最近这一年，不论是大模型厂商的发布会，还是各类技术方案宣讲，“数据飞轮”和“越用越聪明”几乎成了出现频率最高的词。那些架构图画得都极其漂亮：用户在前端发指令，后端把完整的交互轨迹存下来，系统自动提取反馈，提示词自动优化，模型自动微调，第二天整个 Agent 就变得比昨天更懂业务。
但真正在生产环境管过核心业务 Agent 的人，哪怕只是带团队上线过一个内部数据分析助手，心里都很清楚这幅图景有多脱离实际。
真实情况恰恰相反：原始的生产流量不仅不会天然变成学习资产，绝大多数时候它直接就是系统的运行负债。把未经治理的生产日志直接当成经验回灌给系统，换来的通常不是自主进化，而是灾难性的记忆污染、规则漂移和层出不穷的线上故障。
堆积日志不是学习，很多所谓的飞轮只是在交存储账单
很多团队容易把“记录了数据”误当成“沉淀了资产”。
在真实的线上环境里，海量的交互日志中超过八成都是毫无增量信息的常规问答，剩下两成则充斥着各种噪声：用户输入错别字引发的死循环，网络抖动导致的重复重试，用户因为情绪烦躁给出的自相矛盾的追问，以及下游服务偶尔超时抛出的脏报错。
如果不对这些日志做清洗、归因和物理隔离，直接把它们作为少样本样例塞进上下文，或者拿去给模型做微调，系统很快就会学到错误的因果关系。学术界在持续学习领域早就验证过这种现象：未加约束的在线记忆累积会导致严重的记忆中毒与灾难性遗忘。你今天为了修一个生僻的边界特例，明天系统可能连最基础的业务指标口径都会算错。
这就像我在《错题集越厚，AI 为什么反而更容易做偏？》里聊过的那种体感：如果只是机械地把报错记下来当成负向约束，系统不会变得更稳，反而会把精力全耗在如何绕过约束上，最后彻底偏离最初的目标。
未经治理的生产流量，本质上就是工业废水。你可以先把它抽进蓄水池里沉淀，但绝不能连过滤都不做，就直接把管道接回饮用水管网。
白天服务，夜间对账：解耦两套运行系统
为什么在线实时做自我反思和规则修改走不通？根本原因在于生产环境有不可妥协的物理约束。
白天在线上响应真实用户时，系统面对的是极其严苛的服务承诺：两秒以内的响应时延，严格受控的算力成本，还有对高可用和确定性的硬性要求。在这样的实时链路里，你根本不可能现场拉起三四个模型做交叉辩论，不可能跑复杂的搜索树，更不可能让大模型当场总结出一套新的工作流并直接生效。
白天的线上服务必须保持克制，像营业时间里的银行柜台一样，以最低的时延和最稳的操作把当下的业务办完。它消费的是经过严格测试的技能、只读的知识库和版本固化的提示词，绝不能在柜台上现场搞创新实验。
真正的反思与学习，必须完全挪到离线的异步链路里，就像银行在夜间闭门后的盘库与对账。
当白天的业务高峰过去，离线学习系统开始拉取当天的重点样本：执行报错的任务、用户反复修正的会话、人工介入接管的异常链路。在没有实时时延压力的离线环境里，我们才能给系统充足的算力和完整的上下文，让它从容地去做重放、对比、归因与提炼。
这种线上执行与离线学习的物理切分，是目前工程上唯一既能守住线上稳定性，又能让系统持续演进的合理架构。
离线重放的两个物理前提：环境快照与副作用隔离
把一次线上的执行失败搬到离线环境里重新跑一遍，难度远比把聊天记录重新发给模型要大得多。要做到确定性的只读重放，必须在底层解决两个工程前提。
第一个前提是运行环境与上下文的完整快照。
大模型的调用天然带有随机性，不仅因为采样参数，更因为运行时的外部环境每分每秒都在变化。如果你的日志系统只记录了用户的提问和模型的文字回复，到了第二天，你根本没有可能在离线环境里复现当时的故障场景。
一个具备可重放价值的调用轨迹，在发生的那一刻就必须把所有环境状态冻结下来：
- 当时生效的提示词版本编号；
- 具体的模型路由与参数配置；
- 向量检索在那个毫秒实际命中的切片内容与相似度得分；
- 外部接口返回的原始数据结构；
- 当时的用户权限与业务租户配置。
只有把这些上下文完整定格，后续的排查才是在同一个物理现场分析案情，而不是对着虚无的影子抓鬼。
第二个前提是副作用工具的沙箱隔离。
真正能干活的 Agent，核心能力都来自于外部工具调用。而很多工具是带有状态修改属性的：往数据库写记录、调整广告投放预算、发送通知邮件、创建审批单据。
当你在夜间离线重放昨天的失败轨迹时，你不可能让系统真的再去调一次真实的扣费接口，或者往生产库里插入一条垃圾数据。这就要求评测环境必须具备工具分流机制：对于只读工具，比如指标查询和知识检索，可以打向只读副本，或者直接回放线上录制好的返回包；对于所有带有写操作和状态变更的外部动作，必须强制路由到模拟沙箱，只验证 Agent 生成的参数格式与调用逻辑是否正确，坚决切断真实的外部通信。
做不到副作用隔离，离线重放就永远只能停留在纯文本聊天的浅层玩具阶段，根本无法触碰核心业务系统。
强模型和用户纠正，都不是天然的标准答案
在离线归因阶段，最容易踩的另一个坑，是以为存在现成的“标准答案”。
有些团队寄希望于更强的大模型，觉得只要引入一个更大参数的模型来当裁判，就能自动判定昨天线上哪个步骤做对了、哪个步骤做错了。但大模型当裁判有着天然的固有偏置：它容易被更长的回答迷惑，容易偏好特定句式，更重要的是，通用的基础模型根本不懂你业务内部特有的统计口径和私有流程。
还有些团队觉得用户的现场反馈就是真理。但在真实的业务交互中，用户反馈同样充满了个体偏差：有的用户因为不清楚规则给出了错误的修改意见，有的用户带着情绪把整个正确的流程全盘否定，更有不同部门的用户对同一个业务指标有着完全相反的理解。
把这两者直接当作标准答案，本质上都是把系统进化的工程责任甩给了另一个不可控的黑盒。
可靠的归因链路必须经过三级漏斗的层层过滤：
- 第一级是规则过滤：通过接口报错、超时熔断、用户中途放弃或人工强制接管等客观信号，圈出高价值的候选集合；
- 第二级是语义聚类：把上百个表象不同但本质相似的失败案例，聚类成少数几个典型的失效模式；
- 第三级是领域责任人复核：由真正对该业务负责的专家对聚类中心进行抽样确认，把真实的业务判断固化为带有唯一裁决权的标准用例。
知识晋升与发布门禁：没有评测的优化就是线上裸奔
当一个典型问题被彻底归因清楚之后，最后一步也是最关键的一步：这条经验到底应该以什么形式进入生产系统？
很多刚接触 Agent 开发的人习惯随手去改系统提示词，在里面加上一句“注意：当遇到某种情况时，千万不要怎样做”。
这种打补丁的方式极其危险。提示词越堆越长，不仅会迅速稀释模型的注意力焦点，更可怕的是，为了修补 A 场景随手加的一条规则，极有可能在毫无察觉的情况下直接破坏 B 场景的正常运转。
在严肃的生产体系里，任何经验要进入系统，都必须经过两道严格的关卡。
第一道关卡是知识晋升。 一次被确认的业务认知，必须被定型为一种结构化的系统资产：它到底应该沉淀为一个独立的标准化技能，还是更新底层知识库中的指标定义，亦或是作为一个高质量的参考样例？这个判断必须有明确的业务负责人确认，而不是任何工程师在后台随手改动一段提示词。
第二道关卡是发布门禁。 提炼出的新规则与新配置在推向生产之前，必须进入自动化流水线，在黄金评测集上跑全量回归测试。
这正是《真正该越积越厚的不是 Prompt，是 Eval》里最核心的逻辑：真正能让团队放心迭代系统的，从来不是写得越来越臃肿的提示词，而是那套沉淀了所有历史教训、随时能够拉出来全面跑一遍的回归测试集。
只有当新的修改在确保解决了当前典型问题的同时，历史基准用例的通过率依然保持稳定，并且整体响应耗时和算力消耗没有出现异常劣化，这次优化才有资格被打包发布，推向第二天的生产环境。
让复利发生在控制面里
回过头来看，“数据飞轮”这个概念本身并没有问题。但它绝不是模型接上数据库之后就会自然发生的魔法，而是一套极其严密、环环相扣的工程控制面。
从生产现场的每一次异常，到上下文快照的定格，到只读沙箱中的确定性重放，再到多级归因、专家抽样、黄金评测集沉淀，最后通过发布门禁完成上线，这个链条只要缺失了任何一环，所谓的飞轮都会在旋转中迅速瓦解。
大模型确实大幅降低了我们做出一个演示 Demo 的门槛，但它从未降低过将一个复杂系统长期托付给核心业务的门槛。
真正的 Agent 复利，不在于系统的数据库里存了多少万条聊天记录，而在于团队能不能把线上每一次真实踩过的坑，都扎扎实实地变成一道再也不会被同样问题击穿的质量防线。