zk-data-agent/data_agent_v0.md

文档结构

1. 数据迭代Agent架构

• 1-2周MVP方案

• badcase反馈渠道接入、自动收集分析

• 1-2周MVP方案

1. 定义一个最小的任务流程，整理流程中AI需要具备的能力

• 工具
• 记忆
• 环境
• 技术选型

Badcase 反馈渠道接入与自动收集分析:数据挖掘Agent设计方案

Router Data Agent Workbench 方案文档

1. 背景 当前快慢系统路由的数据开发流程，主要围绕以下任务展开：

• 分析需求 / badcase
• 明确快慢系统边界
• 构建评测集
• 构建训练集
• 挖掘线上样本
• 人工标注与复核
• 模型训练与回放评估
• 根据结果继续补齐数据 现有流程本质上仍然是 人驱动的数据开发 人理解需求 → 人拆解边界 → 人写 prompt / 规则 → 人捞数据 → 人筛样本 → 人整理评测集 → 人分析模型问题 → 人沉淀经验 这个流程可以用 AI 做局部提效，但如果只是把每一步变成一个 LLM 节点，本质上仍然是旧框架。 本项目希望重构的不是某几个节点，而是整个数据开发范式。

---

1.1 业务尝试：快慢系统评测集构建 当前路由标签空间包括： FAST_DIRECT SLOW_FILTER_RANK SLOW_DISAMBIGUATE SLOW_GOAL_STATE SLOW_WORKFLOW SLOW_CONTEXT_DEPENDENT SLOW_UNCLEAR SLOW_ADVANCED_CAPABILITY 这些标签不是普通分类标签，而是路由系统的 能力边界定义。 评测集构建的核心目标也不是简单判断 fast / slow，而是判断： 这个请求为什么复杂？ complexity reason 是什么？ 例如： 导航到附近停车场 → FAST_DIRECT

导航到附近最大的停车场 → SLOW_FILTER_RANK 真正困难的不是打标签本身，而是持续维护这些边界：

• 哪些请求快系统可以稳定承接？
• 哪些请求必须交给慢系统？
• 哪些 case 是边界混淆？
• 哪些标签定义不清？
• 哪些线上 badcase 暴露了新的边界问题？
• 哪些模型错误值得转成训练集 / 评测集？

2. 数据迭代Agent架构 建设一个面向快慢路由系统的数据开发 Agent 环境：Router Data Agent Workbench 它的目标是： 让 Agent 能够围绕一个需求 / badcase，自主理解问题、探索数据、发现边界冲突、提出人工裁决问题、生成评测集候选、沉淀长期经验，从而显著提升路由评测 / 训练数据构建效率。 目标不是做一个固定流程平台，而是做一个 Agent-native 的数据开发工作台。

---

2.1 Agent定位

• 不做传统 workflow+LLM节点提效 [图片] 2.1.1 不做传统 workflow 不采用这种模式： 需求理解节点 → 边界分析节点 → 样本挖掘节点 → 预打标节点 → 人工审核节点 → 评测集生成节点 这种方式的问题是：
• 还是人预先设计流程
• LLM 只是填充节点
• Agent 没有真正自主决策
• 新问题仍然需要人调整流程 / prompt
• 长期价值有限 这不是 AI 原生，而是旧流程自动化。

---

2.1.2 做 Agent-native workbench 目标模式是： 给 Agent 一个目标、工作区、资料、工具、经验、权限和评价标准； Agent 自己决定下一步做什么； 系统负责提供环境、边界、记录、校验和人工裁决入口。 核心区别： 传统 Workflow Agent-native Workbench 人提前画流程 Agent 根据任务自主推进 LLM 填节点 Agent 自己选择资料、工具和行动 prompt 是核心 workspace / skills / memory / tools 是核心 人负责执行大量步骤 人只负责关键业务裁决 每次任务从头开始 经验持续沉淀，下一次复用 输出一个结果 输出结果 + 过程 + 经验 + 可复用资产

---

2.2 系统定位 Router Data Agent Workbench 应该承担以下职责： 输入：

• 需求文档
• badcase
• 线上 session
• 当前标签定义
• 历史评测集
• 模型预测结果
• 人工裁决记录

输出：

• 边界分析
• open questions
• 人工裁决问题
• 候选样本池
• 标注任务
• 专项评测集候选
• 训练集候选
• 回放评估报告
• 标签定义修订建议
• 可复用经验 它不是一个“评测集生成器”，而是一个 路由数据开发 Agent 工作环境。

---

2.3 核心架构 Router Data Agent Workbench 由 6 个核心要素组成：

• Workspace：任务工作区
• Skills：领域经验包
• Tools：可执行工具
• Memory：Agent 外部认知状态
• Policy：权限与人工裁决边界 [图片]

---

2.4 Workspace：任务工作区 每个需求 / badcase 启动后，系统创建一个独立 workspace。 示例结构： [图片] Workspace 的作用：

• 承载任务上下文
• 记录 Agent 中间理解
• 保存探索过程
• 支持人机协作
• 沉淀可复用经验
• 保证过程可追溯 Agent 不是在一个固定流程里跑，而是在 workspace 中像研究员一样工作。

---

2.5 MD First：以 Markdown 作为 Agent 工作语言 [图片] Agent 工作过程优先使用 Markdown 适合用 Markdown 的内容： 需求理解 边界分析 open questions 人工裁决记录 挖掘策略 失败尝试 经验总结 效果报告 标签定义说明 原因：

• MD 更适合人读
• MD 更适合 Agent 自然读写
• MD 更适合沉淀讨论和判断过程
• MD 更接近真实工作台，而不是状态机 但不是完全不要结构化。 原则是： MD 是 Agent 的工作语言； JSONL / CSV / DB 是数据资产的交换格式。 也就是： 内容 推荐格式 需求理解 MD 边界分析 MD 人工裁决 MD 经验沉淀 MD 候选样本池 CSV / JSONL 评测集 JSONL 训练集 JSONL 回放结果 表格 + MD 报告 工具调用参数 schema / JSON 最终原则： Agent 工作过程 MD first； 系统边界 schema when needed。

---

2.6 Skills：领域经验包，而不是流程节点 [图片] Skills 不应该被设计成固定节点。 错误理解： Skill 1：需求理解 Skill 2：边界分析 Skill 3：数据挖掘 Skill 4：预打标 Skill 5：评测生成 这还是 workflow。 正确理解： Skill 是 Agent 可发现、可按需加载、可组合的领域经验包。 示例： /skills/ router-label-boundary/ SKILL.md examples.md known-confusions.md decision-principles.md

online-session-mining/ SKILL.md query-patterns.md sampling-strategies.md badcase-mining.md

eval-set-construction/ SKILL.md golden-set-rules.md boundary-set-rules.md anti-patterns.md

active-learning-router/ SKILL.md disagreement-mining.md hard-negative-mining.md recall-gap-analysis.md Agent 在运行中根据问题自主选择是否读取某个 skill。 例如： 发现 FAST_DIRECT 和 SLOW_FILTER_RANK 边界不清 → 读取 router-label-boundary skill

需要从线上 session 挖相关样本 → 读取 online-session-mining skill

发现模型离线准确率高但线上效果差 → 读取 active-learning-router skill Skill 的价值不是定义流程，而是沉淀经验。

---

2.7 Resources：可检索资料 Resources 是 Agent 可读取的业务上下文。 包括： 当前标签定义 历史标签定义版本 历史 badcase 历史人工裁决 已有评测集 已有训练集 线上 session 索引 topquery 集合 模型预测结果 模型误判样本 历史回放报告 Agent 不应该一次性把所有资料塞进上下文。 更合理的方式是： Agent 先读任务目标 → 判断需要什么资料 → 按需检索相关资源 → 只把当前需要的内容纳入上下文 这样可以避免上下文污染，也能让 Agent 更像真实研究员一样探索。

---

2.8 Tools：可执行能力 Tools 是 Agent 可以调用的实际能力。 示例： search_online_sessions() sample_top_queries() find_similar_cases() mine_by_pattern() mine_by_embedding() mine_by_model_disagreement() cluster_and_dedup() run_router_eval() run_online_replay() create_annotation_queue() read_human_review_result() train_router_model() compare_model_versions() Agent 不应该直接写复杂 SQL 或手工操作数据表。 系统应该提供稳定、可控、可审计的工具接口。 Agent 自己决定： 什么时候查线上 session 什么时候找历史裁决 什么时候跑模型分歧 什么时候构造混淆样本 什么时候创建标注任务 什么时候请求人工裁决

---

2.9 Memory：Agent 外部认知状态 Memory 不是简单存几个结构化字段。 错误理解： { "status": "running", "target_label": "SLOW_FILTER_RANK" } 正确理解： Memory 是 Agent 为了完成长期任务而主动维护的外部认知状态。 建议形式： memory/current_understanding.md memory/open_questions.md memory/human_decisions.md memory/failed_attempts.md memory/reusable_lessons.md 其中： current_understanding.md 记录 Agent 当前对任务的理解。 open_questions.md 记录尚未解决的边界问题。 human_decisions.md 记录人工裁决及其理由。 failed_attempts.md 记录无效挖掘策略，避免重复踩坑。 reusable_lessons.md 记录可复用经验，供后续任务调用。 长期看，系统要沉淀： 哪些标签容易混淆 哪些边界已有裁决 哪些挖掘策略有效 哪些关键词误伤高 哪些样本适合评测集 哪些样本只适合训练集 哪些模型错误模式反复出现 判断系统是否真正 Agent-native 的关键标准之一： 下一次遇到类似问题，Agent 是否明显更聪明。

---

2.10 Policy：权限与人工裁决边界 [图片] Agent 可以自主推进任务，但不能无限自由。 需要明确哪些事情 Agent 可以自动做，哪些必须人类确认。 暂时无法在小米办公Pro文档外展示此内容 核心原则： Agent 负责探索和建议； 人负责业务边界裁决。

---

3. 人的角色 人不再是流程执行者。 人不应该做： 手写 prompt 手动拼关键词 手动捞数据 手动合并 Excel 大量刷 easy case 手动维护所有边界记忆 人应该做： 裁决业务边界 确认标签定义变更 审核 golden set 入库 处理高分歧样本 处理高流量低置信样本 确认模型回放结论 一句话： 人是边界裁判，不是数据流水线工人。

---

4. Agent 应该如何向人提问 Agent 不应该问： 下一步怎么办？ 而应该提出可裁决问题。 示例： 边界裁决问题：

“导航到最近的停车场”应该标为 FAST_DIRECT 还是 SLOW_FILTER_RANK？

候选判断：

A. FAST_DIRECT 理由：最近可以视为导航系统默认距离排序，快系统可以直接执行。

B. SLOW_FILTER_RANK 理由：最近也是排序条件，请求涉及候选集合选择。

Agent 建议：A

原因： 当前快系统导航 POI 默认支持距离优先，因此“最近的停车场”不应等同于“最大的停车场 / 评分最高的停车场”这类优化筛选请求。

请确认：

1. 接受 A
2. 改为 B
3. 补充新的边界规则 人工裁决后，Agent 写入： memory/human_decisions.md 长期标签边界知识库 相关 skill 的 known-confusions.md 以后类似问题直接复用。

---

5. 典型运行方式 [图片]

用户输入： 一批 badcase + 需求说明 + 当前标签定义 Agent 启动任务 workspace。 然后 Agent 自主推进：

1. 读取需求和 badcase
2. 写 goal.md
3. 写 current_understanding.md
4. 检索相关标签定义
5. 检索历史类似裁决
6. 判断当前问题涉及哪些边界
7. 自主选择数据挖掘策略
8. 查询线上 session / topquery / 模型误判样本
9. 聚类、去重、找代表样本
10. 发现标签冲突或定义不清
11. 生成 open_questions.md
12. 向人提出高价值裁决问题
13. 根据裁决继续挖掘和修正
14. 生成候选评测集
15. 生成回放报告
16. 沉淀 reusable_lessons.md 注意：这不是预设流程，而是一个典型任务可能自然形成的行动轨迹。

---

6. 关键产物 第一版系统建议产出以下文件： goal.md current_understanding.md boundary_analysis.md open_questions.md human_decisions.md failed_attempts.md reusable_lessons.md candidate_pool.csv annotation_queue.csv eval_set_candidate.jsonl label_definition_patch.md replay_report.md trace.md skills_used.md 这些产物分为三类： 6.1 Agent / 人类协作产物 goal.md current_understanding.md boundary_analysis.md open_questions.md human_decisions.md reusable_lessons.md 6.2 数据资产产物 candidate_pool.csv annotation_queue.csv eval_set_candidate.jsonl 6.3 审计与复盘产物 trace.md skills_used.md failed_attempts.md replay_report.md

---

7. MVP 建议 第一版不要做大而全平台。 先验证一个最小闭环： 输入 badcase，Agent 能否自主探索并产出高质量边界问题和候选评测集。 MVP 输入
8. 一批 badcase
9. 当前标签定义
10. 可查询的线上 session / topquery
11. 现有评测集
12. 模型预测结果，可选 MVP 输出
13. boundary_analysis.md
14. open_questions.md
15. human_decisions.md
16. candidate_pool.csv
17. eval_set_candidate.jsonl
18. replay_report.md
19. reusable_lessons.md MVP 验收标准
20. Agent 能自己识别涉及的标签边界
21. Agent 能自己查找相关历史定义 / 样本
22. Agent 能自己提出挖掘策略
23. Agent 能找出一批有效候选样本
24. Agent 能提出高质量人工裁决问题
25. 人工裁决后，Agent 能继续修正结果
26. 最终候选评测集可被人工抽检使用
27. 本次经验能被后续任务复用

---

8. 成功标准 项目成功不看是否跑通一个固定流程，而看以下能力：
9. Agent 是否能自主理解新需求 / badcase？
10. Agent 是否能主动寻找相关历史定义和裁决？
11. Agent 是否能判断当前问题属于哪些标签边界？
12. Agent 是否能自主决定挖哪些数据？
13. Agent 是否能发现标签定义冲突？
14. Agent 是否能提出高质量人工裁决问题？
15. Agent 是否能生成可用候选评测集？
16. Agent 是否能根据人工裁决修正自己的判断？
17. Agent 是否能沉淀经验？
18. 下一次遇到类似问题，Agent 是否明显更聪明？ 最重要的是第 10 点。 如果每次任务都像第一次一样重新开始，那就不是经验驱动。

---

9. 最终结论 [图片] 本项目不应该定义为： 用 Agent 编排快慢系统评测集构建流程 而应该定义为： 给路由数据开发建设一个 Agent-native 工作环境。 最终形态是： Router Data Agent Workbench 它的核心不是流程，而是： Workspace Skills Resources Tools Memory Policy 它要实现的能力是： 需求 / badcase → Agent 自主探索 → 发现边界问题 → 挖掘候选数据 → 提出人工裁决 → 生成评测 / 训练资产 → 回放验证 → 沉淀经验 → 下次复用 一句话总结： 不是让 AI 跑数据流程，而是让 Agent 拥有一个可以自主完成数据开发工作的环境。