文档结构
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 输入
1. 一批 badcase
2. 当前标签定义
3. 可查询的线上 session / topquery
4. 现有评测集
5. 模型预测结果，可选
MVP 输出
1. boundary_analysis.md
2. open_questions.md
3. human_decisions.md
4. candidate_pool.csv
5. eval_set_candidate.jsonl
6. replay_report.md
7. reusable_lessons.md
MVP 验收标准
1. Agent 能自己识别涉及的标签边界
2. Agent 能自己查找相关历史定义 / 样本
3. Agent 能自己提出挖掘策略
4. Agent 能找出一批有效候选样本
5. Agent 能提出高质量人工裁决问题
6. 人工裁决后，Agent 能继续修正结果
7. 最终候选评测集可被人工抽检使用
8. 本次经验能被后续任务复用

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

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