每天，你的智能体（Agent）都会把失败案例打包成“礼物”发还给你。一名用户点击了“踩”。另一名用户读完答案后一言不发，直接关掉了标签页。第三名用户将同一个问题改写了三次，直到智能体终于答对。每一个都是带标签的失败案例 —— 真实的输入、真实的上下文、系统失误的真实时刻 —— 由那些最希望系统运行正常的人免费提供给你。
大多数团队都会把这些信息全部丢掉。并非故意为之。点击“踩”只是增加了仪表盘上的一个计数；放弃使用表现为留存图表中的一次下滑；改写问题看起来就像普通的日常使用。没有任何东西能将信号及其产生的上下文 一并捕捉，因此也就无法进行回放、分选（Triage）或转化为测试用例。你所拥有的最丰富的评估数据源正擦肩而过，而团队却还在继续手动编写合成的评估（Eval）案例。
这就是你从未构建的智能体反馈循环。它不是你忘记购买的某种工具，而是一条流水线 —— 从用户信号，到分选后的失败案例，再到新的评估案例 —— 它之所以未能建立，与技术本身关系不大。
没有 Trace 的“踩”只是数字，而非教训
从最常见的错误开始：只收集反馈，不收集上下文。
添加一个“踩”按钮很容易。它会在某处写入一行数据：timestamp, user_id, rating: -1。一周下来，你会得到一个数字 —— “满意度降至 71%”。这个数字告诉你出了问题，但它没告诉你哪里 出了问题，也没提供任何可操作的建议。
相比之下，如果一个“踩”附带了完整的决策上下文：精确的用户输入、对话历史、系统提示词版本、模型版本、检索到的文档、调用的工具及其返回结果，以及用户拒绝的最终输出。那就不再是一个数字。那是一个可复现的失败案例。你可以打开它，查看发生了什么，提出假设，修复它，并且 —— 至关重要的一点 —— 将其保留为测试用例，确保同样的失败不再发生。
这两种产物之间的区别，就是反馈循环存在与否的区别。没有 Trace 的评分只是情绪。绑定到 Trace 的评分才是数据。大多数生产系统收集的是前者，却以为自己拥有后者。
修复方法是结构性的，且必须在反馈到来之前就位。每一次智能体运行都应该生成一个 Trace —— 一个记录了智能体看到的所有输入和采取的所有步骤的结构化记录。反馈信号无论何时产生，都通过 ID 关联到该 Trace。当用户点击“踩”时，你记录的不是一个观点，而是标记了一个特定的、可回放的执行过程供审查。先构建 Trace，按钮是最简单的部分。
大多数反馈是无声的
显式反馈 —— 赞、踩、星级评分 —— 是每个人都会埋点的部分，但它只是最小的一部分。反馈组件的使用率极低是众所周知的；点击的用户往往是带有偏见、发声欲望强烈的少数群体。如果你只从点击中学习，那你只从极小部分的流量中学习，错过了其余大部分信息。
更大的信号是隐式的，它们现在就躺在你的日志里。关于人类与 LLM 对话的研究总结了这些信号的特征：
改写 (Rephrasing) 。用户用不同的词再次询问同一件事。这是前一个答案未达预期的最强烈隐式信号 —— 没有人会对满意的答案进行改写。放弃 (Abandonment) 。对话在任务中途停止。用户得到了答案后直接离开而没有后续行动，或者直接放弃了。复制粘贴与后续模式 。用户复制了输出的一部分，并立即提出修正。他们转向同一个目标的另一种表述方式。他们用平实的语言表达挫败感。升级 (Escalation) 。用户要求人工介入，或者愤怒地退出并转向支持渠道。
这些都没有对应的按钮。它们是从行为中推断出来的 —— 而这种推断正是团队感到紧张的地方，因为隐式信号具有噪声。用户改写问题可能是因为想到了更好的问法，而不是因为之前的答案不好。最近的研究直言不讳：隐式反馈对于理解 用户很有启发，但作为直接的训练信号则充满噪声。
这种噪声是分选隐式信号的理由，而不是忽略它们的借口。将它们视为候选 失败案例，而非确定的失败。改写事件会为人工审核标记一个 Trace；由人来查看并判断这是否是真实的失误。你不是在进行自动标注，而是利用隐式信号引导稀缺的人工审核资源去关注那 2% 最可能包含缺陷的流量，而不是让他们进行盲目采样。仅凭这一点就值得构建。
流水线：信号 → 分选后的失败案例 → 评估案例
反馈循环不是一个功能，而是一个具有不同阶段的流水线，每个阶段都可能被跳过 —— 而且通常确实被跳过了。以下是它正常工作时的样子：
1. 捕捉 (Capture) 。每一次运行都会生成一个 Trace。每一个显式评分和每一个可检测的隐式信号都关联到其 Trace。这是基础；没有它，下游的一切都不可能实现。
2. 采样与聚类 (Sample and cluster) 。你无法审核每一个标记的 Trace，也不应该这样做。提取失败案例，对输入和输出进行嵌入（Embedding），然后进行聚类。错误分析框架正是这样操作的：与其逐个阅读失败案例，不如将它们分组，这样 30 个“智能体忽略了日期过滤器”的实例就会合并成一个你可以直观看到并评估规模的类簇。
3. 分选 (Triage) 。由人打开每个类簇并标记根本原因。是检索（Retrieval）拉取了错误的文档？是工具返回了误导性的错误？是提示词缺少指令？还是模型本身确实搞错了？类簇大小乘以严重程度决定了优先级。你要修复的是排名前三的类簇，而不是长尾问题。
4. 提升为评估案例 (Promote to eval) 。这是闭环的最后一步，也是最常缺失的一步。每个带标签的类簇变成一个或多个评估（Eval）案例：真实的输入、捕捉到的上下文以及期望的行为。修复方案体现在你的提示词、工具或逻辑中。评估案例则进入你的回归测试集。从那时起，该失败模式在每次迭代中都会被测试。
跳过第四步，你拥有的只是一个观测仪表盘 —— 很有用，但三个月后你还会修复同类漏洞，因为没有任何机制能记住它。“提升”步骤是将一次性修复转化为永久性防线的关键。
飞轮效应：每次事故都在提高系统下限 当流水线完整时，某种复利效应就会发生。每一个经过分类处理的线上故障都会变成一个永久的测试用例。评估集（eval suite）不再是某人在项目开始时构思的一组静态案例；它是你的系统在真实用户面前所有失败方式的鲜活记录。
这改变了交付的经济学。如果没有这个闭环，每一次提示词（prompt）变更或模型升级都是一场赌博 —— 你修复了一个问题，却在不知不觉中破坏了另外两个，而且只能通过用户反馈才能发现。有了这个闭环，每一次变更都会针对一个包含所有过往失败案例的评估集进行运行。回归问题在部署前就能被发现。这个集合只会不断扩大，因此系统的下限只会不断提高。
它还改变了你评估数据的来源。手动编写的评估案例反映了工程师“想象”中用户的行为。而源自生产环境的评估案例则反映了用户的“真实”行为 —— 包括团队中任何人都未曾想过要测试的输入。模型升级的决策变成了一种衡量，而非凭运气的纵身一跃：你在积累的测试集上重新运行新模型，清晰地看到它修复了哪些历史失败，又引入了哪些新问题。
这才是真正的奖赏。不是仪表盘，也不是满意度指标 —— 而是一个变得单调递增、难以被破坏的系统，其动力完全来自于你已经在产生、但此前被丢弃的数据。
为什么闭环始终无法建立 如果飞轮如此有价值且原材料是免费的，为什么它还如此罕见？障碍在于组织架构，而非技术。
反馈闭环跨越了大多数团队在职能之间划定的界限。捕获 Trace（追踪）是平台组的工作。集成反馈组件是前端的工作。聚类和分拣是数据科学或机器学习组的工作。将案例提升到回归套件中则属于评估集的负责人。根据修复方案采取行动的是产品工程团队。没有单一角色能够端到端地负责这个闭环，因此当它不存在时，也没有单一角色需要为此负责。
正因为没有人负责，它在每一次优先级竞争中都会落败。闭环是纯粹的基础设施 —— 它不交付任何可见的功能。它的回报是下个季度“不会”发生的回归，而这在定义上是不可见的。将其与带有演示（demo）的路线图项目放在一起，闭环在每个 Sprint（迭代）中都会输掉。它永远是每个人都认同其重要性，但却没人被安排去构建的东西。
还有一种更隐蔽的不安感。一个运转良好的反馈闭环会产生一份诚实的、不断增长的、公开的账本，记录你的 Agent（智能体）每一次失败的方式。这正是严肃团队想要的，也正是焦虑的组织想要逃避的。与其把故障维护成一个具体、可查阅的、带有分拣责任人姓名的缺陷列表，不如将它们维持在一个模糊的满意度百分比，这样心理压力更小。
解决之道是将闭环明确为某人的工作，并将评估集视为拥有负责人的第一类资产 —— 就像你绝不会让生产数据库处于无人管理的状态一样。命名这个角色。在仪表盘上展示“本周从线上故障转化为评估案例的数量”，并让负责人进行汇报。技术环节 —— Trace、聚类、标注队列 —— 已经非常成熟，且越来越多是开箱即用的。难点从来不在于流水线，而在于决定它归谁所有。
从 Trace 开始 如果你这季度只想做一件事，那就构建 Trace 并将反馈绑定到它上面。闭环中的其他一切 —— 聚类、分拣、提升 —— 都是拥有可复现失败记录后的下游产物，如果没有它们，一切都无从谈起。
你的用户已经在做最昂贵的部分了。他们正在真实环境下寻找你 Agent 的薄弱点，并告诉你位置所在 —— 通过点击、通过离开、通过再次询问。唯一的问题在于，这些信号是进入了一个让你的系统永久变得更好的流水线，还是仅仅变成了一个让数值下降的计数器。数据是免费的。构建闭环是一个决定。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
