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