第 20 章 Agent 运行时数据处理¶
客服负责人提出了一个具体要求：每天看一批退款对话，找出“工具没有办成，Agent 却告诉用户已经办好”的问题；改完提示词后，还要用这些案例检查问题有没有减少。
运行记录已经接入，轨迹也能打开，但质检人员需要的是一张可以直接使用的表：用户问了什么、Agent 如何回答、执行了哪些操作，以及记录来自哪里。数据多了，还希望按业务分类、抽取样本，每天自动补充新数据。如果每次都由开发者导出日志、改脚本、整理表格，质检很难成为日常工作。
Pipeline 将这套整理方法保存为数据处理任务，按约定持续生成 Dataset。 应用开发者把业务字段接对，业务负责人围绕预览确认样本是否符合用途；之后，评估、人工复核和实验共用这些字段，减少反复找数据、解释数据的工作。
在上一章中，我们已经得到可以阅读和回查的执行过程。本章接着说明，怎样将这些过程整理成业务用得上的样本。
20.1 Pipeline 能帮业务做哪些事¶
Pipeline 的功能可以按要交付的结果来选择。多数任务只需要其中几项，无需把所有处理都加进去。
| 业务需要 | 可以采用的处理 | 得到什么、何时有用 |
|---|---|---|
| 把日志变成可读表格 | 字段投影、字段扩展、条件过滤 | 提取问题、回答、模型、耗时等字段，适合质检、分析和评估前的数据准备 |
| 把分散事件整理为完整样本 | 实例构建 | 按已确认的任务或会话身份组装记录，适合输入仍是 Span、消息片段的应用 |
| 从相似内容中整理题库 | 精确去重、近似去重、语义去重 | 减少相同或相近问题，降低题库维护与重复评估的工作量 |
| 在有限预算内多看几类问题 | 随机采样、分组采样、向量生成、语义聚类 | 按比例、条数或类别选样，适合人工复核、专项排查与评估集扩充 |
| 为样本补充业务信息 | LLM 调用、智能体调用 | 分类、摘要、信息提取或生成候选标注，让筛选与分析更方便 |
| 找出异常长的内容 | 文本统计、条件过滤 | 计算文本长度等特征，定位过长输入或工具返回，为内容治理和成本排查选样 |
| 持续收集新数据 | 单次执行、周期执行、运行历史 | 先整理一个历史时间段，再按小时或天生产新样本，支撑日常质检 |
同一份数据可以服务不同目的。客服团队需要问题与答复，开发者排查工具使用需要步骤和返回结果，成本分析还需要模型与消耗字段。可以保留共同的基础字段，再根据用途配置不同的处理任务和输出集合。
选择之前，先明确一行代表什么。退款质检可以从“一次任务一行”开始；分析用户为何反复补充信息，需要连续多轮；比较多个并行 Agent，则要分别保留各条路径。这个选择决定了后面怎样分组、采样和评分，也决定业务人员打开表格后能否直接理解。
20.2 从合适的入口开始¶
进入对应 AgentSpace，在“数据中心”的“数据处理”中点击“创建 Pipeline”。创建页支持选择来源、使用模板或让 Loopie 生成管线，并在同一流程中配置输出与调度。已经在整理 Dataset 的用户，也可以从创建数据集的“从轨迹数据导入”入口开始。
选择来源时，可以这样判断：
-
已有 Agent 轨迹，准备做评估：选“轨迹数据”。 页面使用当前空间关联的轨迹来源，可从“Agent 轨迹样本提取”推荐方案开始，直接提取输入、输出、会话与完整轨迹。
-
需要从调用日志提取业务字段：选“Trace 数据”。 查看页面带出的日志来源与应用范围，从推荐的问答提取方案开始；还需要其他字段或组装方式时，再修改处理模块。
-
只需问题与回答：优先选问答提取。 如果还要检查工具是否用对、失败后如何恢复，就保留完整过程，减少质检时重新找日志的工作。
页面按来源推荐处理方案，背后使用相应的预置模板。选择后，左侧“流水线”展示处理模块，点选模块即可查看配置，也可以通过“添加模块”补充采样、分类等处理。开发者熟悉字段时，直接改配置通常最快；需要更多处理步骤，也可以让 Loopie 生成后再调整。
不熟悉原始结构时，可以先向 Loopie 描述目标。例如：
整理退款客服最近一天的运行轨迹，一次任务一行。保留用户问题、实际答复、完整执行过程和来源 ID，输出到退款质检数据集。先给我看真实样本；没有最终答复的任务也保留，方便检查中断问题。
Loopie 可以生成并将管线呈现在编辑器中，用户接着查看真实预览、补充要求。例如“这里取到的是系统包装后的问题，请改成业务入口原文”“增加一列区分退款申请和进度查询”。对话缩短了从业务要求到配置草稿的距离；确认结果后，这份配置就能用于后续数据生产。
20.3 完成第一条退款质检任务¶
下面用一个教学示例走完流程。假设退款 Agent 已产生标准轨迹，我们先整理昨天的数据，输出到新数据集 refund_review_samples。首轮保留各次真实任务，便于看到相同问题成功与失败的不同处理。
选来源与字段¶
在创建页选择“轨迹数据”，找到“Agent 轨迹样本提取”推荐卡片，点击“选择此方案”。进入编辑器后，可以在“智能生成”中继续对话，也可以切到“手动配置”修改字段。先查看输入来源是否属于目标空间，再根据实际存在的服务或业务字段确定应用范围。若多个应用共用来源，可以让 Loopie 根据样本补充筛选规则。
该方案将原有输入、输出和完整轨迹整理为以下字段。业务人员主要读前两列，评估器还能读取过程，开发者可以沿身份回查原记录。
| 输出字段 | 内容 | 退款示例中的用途 |
|---|---|---|
| input | 用户输入 | “订单 1001 需要退款” |
| output | Agent 的最终答复 | “退款申请已经提交” |
| agent_trajectory | 完整轨迹内容 | 查看退款工具的参数、结果及后续回复 |
| trajectory_id、trace_id | 来源身份 | 找到这次实际执行，供复核和排查 |
| session_id | 会话关联 | 必要时联系前后交互 |
其中，模板把源数据中的 atif_content 映射为 agent_trajectory，方便在后续评估中使用。若业务还需要渠道、订单类型等字段，可在“字段投影”或“字段扩展”模块中添加，并从真实样本确认其来源。
字段选择应体现质检目标。检查“用户后来补充的退款原因有没有被使用”，应在输入或轨迹中保留补充信息；检查是否实际办理成功，则需要相应的工具反馈或业务结果。这样，评估器拿到的材料才足以回答具体问题。
用预览确认这张表好不好用¶
方案卡片提供“生成预览”；进入编辑器后，可以选择输出模块点击“预览”，查看整条管线的结果。选择有真实数据的时间范围，先展开一条普通任务的输入、输出和轨迹，确认质检人员能连续读懂；再找一条工具报错或没有答复的任务，看它是否保留下来。
例如预览里出现：工具返回“缺少退款原因”，最终答复却是“退款已经提交”。这正是希望交给质检的样本。若只保留最后一句话，之后很难判断它为什么不对；如果过滤模块删掉了工具失败记录，也要调整条件。可以点选对应模块修改，再生成预览。
预览还适合当场确定输出形态。较长的过程保留在结构化内容列中，列表先显示问题与回答；需要按渠道筛选的字段则单独成列。业务负责人用这几条样本确认“收到这样的表，是否已经能开始工作”，开发者据此收敛配置。
创建、运行，再到 Dataset 使用结果¶
点击页面的“创建并启动”，进入“任务信息与调度策略”，填写任务名称、描述，选择“单次执行”，将处理时间明确设为昨天。在“输出”中填写新数据集名称 refund_review_samples。提交前再次看清时间范围，预览所选时间不一定就是正式执行时间。
确认后再次点击“创建并启动”。系统创建输出数据集与处理任务，单次执行会进入运行队列。随后可在任务详情的“运行历史”查看数据窗口、状态、输出行数与耗时。执行完成后，回到“Pipeline 配置”，通过输出目标卡片的“跳转到数据集详情”图标进入 Dataset，按一条已知 trace_id 找到样本，展开字段读取。预览帮我们定方案，这一步让质检团队拿到可查询、可标注的数据。
如果结果为空，先确认所选时段是否有记录，再检查应用筛选；字段大面积为空，就检查提取位置。初次运行用一个明确的时间段，可以较快分清是数据范围问题还是加工规则问题。
20.4 按实际用途加上采样和 AI 处理¶
第一条任务只需要把材料整理清楚。开始使用之后，再根据复核量、场景覆盖和分析方式增加处理，更容易判断每一步是否有用。
人工看不过来，先缩小到能处理的量¶
假设质检人员一天能认真复核 100 条，可以增加“随机采样”模块，选择“按采样条数”，填写 100；需要让业务类别都有机会入选时，在“分组列”中选择已有类别字段，再设置每组采样条数。这里的 100 是示例工作量，应按实际人力调整。
如果还不知道问题分为哪些类别，可以先用向量生成与语义聚类整理主题，再按聚类结果采样。例如从相似的“进度查询”里取少量代表，把更多阅读时间留给其他问题。这适合扩充题库和发现问题类型；需要估计线上总体失败率时，则保留具有代表性的抽样口径。
内容去重适合另一个需求：已经选出不少案例，准备整理一份不重复的回归题库。在去重模块里选择比较字段；精确去重处理相同文字，近似去重处理细微改写，语义去重处理含义接近的不同表达。按问题去重前，要把结果和重要场景差异考虑进去，避免将同一道题的一次成功与一次失败混为一份。
没有业务标签，让模型先做一版¶
退款记录可以分成“申请退款”“查询进度”“退款被拒”等类别。原始数据没有这些标签时，在提取字段后增加“LLM 调用”模块，选择调用模型，填写自定义提示词，将“输出解析格式”设为“JSON格式”，把“输出列名”设为 scenario_label。
可以从这样的提示词开始：
根据用户输入 {{input}}，将本次任务归为“申请退款”“查询进度”“退款被拒”“其他”之一。只根据输入判断，不推断办理结果。返回 category 和 reason 两个字段；reason 简短说明分类依据。
生成预览后，查看 scenario_label 中的类别和理由。遇到“已经申请三天了怎么还没到账”，应能归到进度查询；如果分类不符，补充类别解释和相近例子，再试一批样本。需要直接按类别列筛选时，可继续用字段扩展将 JSON 中的 category 提取为独立列。
同一个模块还可以生成问题摘要、提取产品名称或补充候选标签。需要检索知识、调用工具才能完成的分析，可以选择智能体调用，并配置相应智能体与提示词。生成的标注先供筛选和人工复核使用；正式质量评分交给可校准、可比较的评估器，便于长期维护标准。
题库还缺少某类表达时，可以用 LLM 调用做数据增强：以已有样本为种子，通过提示词生成不同说法或边界条件。例如已经有直接申请退款的题目，希望补充“用户先问到账时间、随后改为申请退款”的多轮要求，就把需要保留的业务事实和允许变化的部分写清楚。生成结果先放入候选材料，人工确认后再使用，同时保留合成来源，方便与真实用户任务区分。
处理顺序可以按成本安排：已有字段能筛选的先筛选，明确只需 100 条的先采样，再做模型处理。如果采样依赖模型生成的类别，就先分类再按类别抽样。每增加一步，都应说明它要帮使用者少做什么工作、增加哪项信息。
20.5 从一次整理变成日常质检¶
当昨天的样本已经可用，就可以使用相同的处理定义另建周期任务：重新选择相应模板，沿用已确认的字段、筛选和采样设置。在“任务信息与调度策略”选择“周期执行”，设置起始时间和每隔多少小时或天执行，例如按小时补充新任务，或按天集中交付。这次创建一个日常使用的数据集 refund_review_daily，之后各次周期执行都向它写入，质检人员便能在固定位置查看新增内容。
首次配置时，把历史补数范围与后续周期的起始时间衔接好。之后主要在任务详情中查看执行历史、成功与失败情况，再抽查新增样本。应用增加了新渠道或新的回复方式，也要更新相应处理规则，让数据集包含这些变化。
接下来进入评估功能，新建以 Dataset 为来源的评估任务，选择 refund_review_samples 和准备好的退款质检评估器，将评估器需要的输入、输出、轨迹变量分别映射到 input、output、agent_trajectory。先评一批样本，查看分数、理由和对应证据，便能找到“工具失败却回复成功”等待处理案例。开始日常质检后，再以 refund_review_daily 中的新样本作为评估材料。
业务负责人可以看到问题集中在哪些场景，开发者拿着对应轨迹定位并修改，评估人员把确认的问题加入回归材料。新版本重新执行这些任务后，实验再比较结果，判断修改是否有效。新增运行记录继续进入同样的加工任务，日常数据准备就接上了调优工作。
操作演示中，两道客服问题起初共用评分细项，后来发现“介绍有哪些功能”和“说明如何做评估”需要不同标准，于是回到 Dataset 增加逐题 Rubric，再调整评估与实验的映射。这也说明，产出的字段应便于继续扩充。后续使用提出了新问题，就补充相应材料，而不必重做全部数据准备。
20.6 第一次使用，先交付一批有人愿意用的数据¶
先完成“轨迹提取→Dataset→一批评估”，让负责质检的人读一遍结果。字段对了，再增加标签和采样；已有稳定使用节奏，再建立周期生产任务。
长期使用时，保留三项简单约定：样本粒度、关键字段含义、数据用途。业务负责人确定要看什么问题，应用开发者维护来源字段，数据处理任务负责重复执行。复杂的并行聚合、超长任务或跨窗补取，再由开发者按实际数据补充处理。
判断是否值得继续投入，也可以看具体工作有没有变得顺畅：质检人员是否还需要逐条找原日志，新增一种业务场景能否通过补充字段和规则纳入，开发者收到问题后能否定位到同一次执行。若这些环节已经衔接起来，再增加语义聚类、合成或复杂 Agent 分析才有明确目的。管线简单而输出被持续使用，通常比配置了很多处理却无人消费更有价值。
退款质检的首次交付可以很明确：在 refund_review_samples 中找到昨天的任务，打开一行能读懂问题、回答和办理过程，启动评估能得到有依据的结论。哪些记录值得长期保留、如何经过人工确认成为黄金集与回归集，接着在下一章中展开。