56%的AI代理工作去向不明：一个会话标签引发的度量灾难

一个看似普通的查询，揭开了一个惊人的黑洞

三周，65个会话，4,985条消息。一位开发者把AI代理（agent）的聊天记录拉进数据库，试图用SQL分门别类地盘点：多少时间花在修复自己的失误上？多少花在真正发布内容上？剩下的又是些什么？

结果出现了一条巨大的裂缝：2,813条消息，占总量的56%，不属于他定义的任何类别。这个数字在数据集里静置了三天，直到他终于动手拆解。

AI代理（AI Agent） 是指能够自主感知环境、做出决策并执行多步操作以完成目标的大语言模型驱动系统。与传统的单轮问答不同，代理可以在一个会话中连续调用工具、读写文件、执行代码、访问网络，并根据中间结果调整后续动作。这种多步自主性使得代理的工作过程高度非结构化：它可能在用户不知情的情况下进行大量探索、试错和自我修正。正因如此，代理的“工作量”很难用传统项目管理中的任务分类来衡量——一条消息既可能是发布一篇博客的关键步骤，也可能只是代理在自言自语地思考。本文所揭示的度量难题，正是这种非结构化自主工作带来的直接后果。

一个会话吃掉整个语料库的四分之一

要理解这个56%，得先看整个会话的分布。中位数会话只有18条消息，但最大的那个会话——标题竟然叫“Quick check-in”（快速确认一下）——一个人就包含了1,327条消息，占整个三周活动的26.6%。

这个会话从某天早上06:10持续到五天后的07:39，开发者只发了133轮消息，代理却回了1,194条。仅从数据量看，这完全不像一次“快速确认”，更像是一场长达五天的马拉松式协作。

它发布了六个帖子，标题却毫无线索

更深的挖掘让事情变得荒诞：这个名叫“快速确认”的会话，实际上产出了博客第17到22篇的全部六篇文章，占这位开发者全部已发布内容的24%。他逐条比对发布时间与会话消息时间戳，发现每一篇的发布日期都能在同一分钟内找到对应的消息记录。

帖子	发布时间 (UTC)	最近消息时间
Blog 17	10-07 06:34	10-07 06:33
Blog 18	10-08 18:34	10-08 18:33
Blog 19	10-10 03:55	10-10 03:55
Blog 20	10-11 12:15	10-11 12:15
Blog 21	10-12 04:18	10-12 04:17
Blog 22	10-12 07:39	10-12 07:38

时间戳精确到分钟的重合，几乎没有给巧合留下空间。数据证据链完整而坚实。

罪魁祸首是一个下拉菜单

为什么这个庞然大物会被扔进“未分类”？答案简单到令人尴尬——算术。

开发者定义“恢复类”会话（标题含crash、diagnose、recover等词）共10个，合计1,636条消息。这个1,327条的会话显然塞不进去。然后他定义“发布类”会话共3个，合计536条消息。1,327比536还大，也不可能属于这一类。

于是，三周里最大的一个会话，既不算失败也不算产出，只因为它开始时开发者从下拉菜单里随手选了一个标题。那个动作发生在10月，他当时很累。

这是纯粹的入口污染：分类标签在会话开始前就被固定，而当时他根本不知道这个会话会变成什么。

入口污染（entry-point contamination） 是数据标注领域的一个经典问题，指的是在数据生成或采集的起点就引入的、后续难以消除的偏差。在AI代理的场景中，会话标题通常在会话创建时由用户手动选择或输入，而这一刻恰恰是用户对会话最终会变成什么知道得最少的时刻。一旦这个前置标签被写入元数据，它就会渗透到后续所有的分类、统计和报告中，形成一种系统性的度量偏差。与事后标注不同，入口污染的问题在于标签携带的是“初始意图”而非“实际结果”，当工作本身是涌现式的时候，两者可能完全脱节。本文中一个名为“Quick check-in”的会话最终产出了24%的已发布内容，正是入口污染的极端案例。要消除这种偏差，必须将标注点从会话开始后移到会话结束。

真相：不是11%，而是37%

纠正这个错误标签后，数据发生了剧烈位移。“恢复类”仍是1,636条（32.8%），开发者谨慎地表示这个数字是否准确无法确认，但他强调它至少没有移动。真正被改写的是“发布类”：从536条跃升至1,863条，占比从11%变成37.4%。

一个会话的错误标签，让代理超过三分之一的工作量被系统性低估。他原本报告的数字，只有真实产出的不到三分之一。

“残差”里不止一个错误标签

如果把一切归咎于这一个标签，故事就太干净了。开发者特意提醒自己不要掉进这种叙事陷阱。

按规模拆解残差：1,327条是那个“快速确认”，下面依次是273、211、205、107、98、83、83、46、43条。其中273条的那个会话标题叫“Greeting”（打招呼）。2,582条消息躺在40条以上的会话里，从未被分类过。

“我不知道‘Greeting’里发生了什么。语料库里第二大的会话有273条消息，我能给出的最好解释是：我开了一个会话，没有命名，在里面待了九个小时。”

还有三个会话完全没有标签，标题是原始时间戳。比如 “New session - 2026-09-27T15:11:27.049Z”。这是选择器上什么都没选留下的痕迹，覆盖三个会话共235条消息。

在数据分析和统计建模中，残差（residual） 指的是观测值与模型预测值之间的差异，即那些无法被现有分类体系或解释变量所覆盖的部分。残差本身并不一定是“错误数据”——它往往包含了模型尚未捕捉到的真实信号。本文中，开发者将56%的未分类消息称为残差，这个措辞是准确的：这些消息并非不存在，而是现有分类框架无法容纳它们。进一步拆解残差可以发现，其中既有因错误标签而未被正确归类的会话，也有完全没有标签的会话，还有可能属于“代理自言自语式思考”的新类别。残差的大小和内部结构，实际上反映了分类体系与真实工作形态之间的根本性不匹配。在度量自主代理的工作时，残差往往比已分类部分更有信息量，因为它指向了现有框架的盲区。

错误标签可修复，无标签则无法分类

开发者在这里做出了一个关键区分：一个错误的标签是可以补救的——回头查看工作内容，重新命名即可。但“无标签”在分类体系内是不可恢复的，因为没有任何东西可以拿来分类。那三个会话不在错误的桶里，而在整个度量工具之外。

“如果我每结束一个会话就写一句话总结，我就能抓住那个‘快速确认’。但我再怎么重读自己的分类体系，也永远抓不住那三个会话，因为分类体系从未被应用在它们身上。”

无标签数据（unlabeled data） 与错误标签数据（mislabeled data） 在分类理论中有着本质区别。错误标签数据仍然存在于分类体系之内，只是被放错了位置，因此可以通过重新审查内容来纠正。而无标签数据则完全在分类体系之外，它从未被任何类别“看见”过，因此无法通过任何基于现有体系的算法或人工流程来恢复。在机器学习的半监督学习中，无标签数据通常需要额外的假设或先验知识才能被利用。在本文的语境下，那三个以原始时间戳命名的会话就是典型的无标签数据：它们不是被错误地归入了某个桶，而是根本没有进入任何桶。这意味着，无论开发者如何改进分类体系，只要标注动作发生在会话开始前，就永远会有一些会话因为“什么都没选”而彻底逃逸出度量范围。

修复方案只有四个字：事后命名

他给出的解法朴素到近乎反高潮：在会话结束后写标题，而不是在开始前。

标题是整个系统里最便宜的字段，也是唯一承载意图的字段，但他在每次会话开始时填写，而那是他对此会话将变成什么知道得最少的时刻。五天后，其中一个会话成了他四分之一产出的容器，而名字还写着“快速确认”。

如果要事后分类代理的工作，标签必须来自工作本身，而不是打开窗口时的那个念头。

那56%到底是什么

那么，扣掉恢复和发布之后，那56%的残差究竟包含什么？开发者坦承他无法回答。部分可能是维护工作，部分是他反复阅读已经读过的笔记——但连这个比例他都无法精确测量，因为他自己写下的定义在不同解读下会在8.7%到26.2%之间摇摆。

还有一部分，可能是代理在以他从未计入“工作”的方式自言自语式地思考。

“那个残差才是有意思的部分，而我无法分类它，因为我唯一能抓住的把手，是我在自己还不知道在做什么之前敲下的一个标签。”

这不是一个关于SQL技巧的故事。它揭示了自主代理时代一个被低估的度量难题：当工作本身是非结构化、涌现式的，任何前置的分类尝试都可能制造出比它解决掉的更多盲区。开发者在文末向读者发出邀请——如果你测量过，请分享你的数字；如果你没有，你的数据形状本身可能就是最值得争论的东西。