wuyang/zk-data-agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add docs

Browse Source
This commit is contained in:
武阳
2026-04-24 10:33:15 +08:00
parent b521d6ce29
commit fed0999f55
4 changed files with 1893 additions and 2055 deletions
Download Patch File Download Diff File Expand all files Collapse all files
data_agent_v0.md
+208 -370
View File
@@ -1,149 +1,29 @@
文档结构
1. 数据迭代Agent架构
- 1-2周MVP方案
- badcase反馈渠道接入、自动收集分析
- 1-2周MVP方案
1. 定义一个最小的任务流程，整理流程中AI需要具备的能力
- 工具
- 记忆
- 环境
- 技术选型
中控数据Agent构建-汇报
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节点提效
1. 背景与目标
- 数据开发是中控核心工作之一，但当前流程仍以人工驱动为主。
- 需求 / badcase 驱动的评测集构建、样本补充和线上挖掘链路分散，人工介入重、复用性差。
- 结合近期 AI native 工作方式转变，我们希望基于 Agent 底座先打通最小数据开发闭环。
当前方式的瓶颈与挑战：
- 人工驱动重：从需求、badcase 到评测集构建，多个关键环节依赖人工推进。
- 流程割裂重：人工构造、线上挖掘、LLM 生成彼此分散，数据格式转换和整理成本高。
- 经验复用弱：边界判断和处理经验难以沉淀，导致新问题进入后仍需重复劳动。
数据开发范式转变：
[图片]
2.1.1 不做传统 workflow
不采用这种模式：
需求理解节点
→ 边界分析节点
→ 样本挖掘节点
→ 预打标节点
→ 人工审核节点
→ 评测集生成节点
这种方式的问题是：
- 还是人预先设计流程
- LLM 只是填充节点
- Agent 没有真正自主决策
- 新问题仍然需要人调整流程 / prompt
- 长期价值有限
这不是 AI 原生，而是旧流程自动化。
2. AI Native数据Agent
不是做一个固定流程平台，而是做一个 Agent-native 的数据开发工作台。
让 Agent 能够围绕一个需求 / badcase，自主理解问题、探索数据、发现边界冲突、提出人工裁决问题、生成评测集候选、沉淀长期经验，从而显著提升路由评测 / 训练数据构建效率。
---
2.1.2 做 Agent-native workbench
目标模式是：
给 Agent 一个目标、工作区、资料、工具、经验、权限和评价标准；
Agent 自己决定下一步做什么；
系统负责提供环境、边界、记录、校验和人工裁决入口。
核心区别：
传统 Workflow
Agent-native Workbench
人提前画流程
Agent 根据任务自主推进
LLM 填节点
Agent 自己选择资料、工具和行动
prompt 是核心
workspace / skills / memory / tools 是核心
人负责执行大量步骤
人只负责关键业务裁决
每次任务从头开始
经验持续沉淀，下一次复用
输出一个结果
输出结果 + 过程 + 经验 + 可复用资产
2.1 设计目标与边界
- 核心目标：基于一个精简、可定制的 Agent 底座，建设一个面向中控数据开发场景的智能体执行底座。
- 方案形态：不是“流程自动化 + LLM 节点”，而是一个以 Agent 为核心、能够围绕任务自主检索、生成、筛选和整理的数据开发执行底座。
- 实现方式：基于 code-agent / claw-code-agent 实现，复用 Agent loop、文件读写、工具调用、代码执行、过程记录等通用能力。
[图片]
---
2.2 系统定位
Router Data Agent Workbench 应该承担以下职责：
输入：
- 需求文档
- badcase
- 线上 session
- 当前标签定义
- 历史评测集
- 模型预测结果
- 人工裁决记录
输出：
- 边界分析
- open questions
- 人工裁决问题
- 候选样本池
- 标注任务
- 专项评测集候选
- 训练集候选
- 回放评估报告
- 标签定义修订建议
- 可复用经验
它不是一个“评测集生成器”，而是一个 路由数据开发 Agent 工作环境。
---
2.3 核心架构
Router Data Agent Workbench 由 6 个核心要素组成：
2.2 核心架构
- 中控数据Agent应该由 6 个核心要素组成：
- Workspace：任务工作区
- Skills：领域经验包
- Tools：可执行工具
@@ -152,7 +32,7 @@ Router Data Agent Workbench 由 6 个核心要素组成：
[图片]
---
2.4 Workspace：任务工作区
2.2.1 Workspace：任务工作区
每个需求 / badcase 启动后，系统创建一个独立 workspace。
示例结构：
[图片]
@@ -163,32 +43,14 @@ Workspace 的作用：
- 支持人机协作
- 沉淀可复用经验
- 保证过程可追溯
Agent 不是在一个固定流程里跑，而是在 workspace 中像研究员一样工作。
Agent 不是在一个固定流程里跑，而是在 workspace 按照我们之前的工作流程去工作
---
2.5 MD First：以 Markdown 作为 Agent 工作语言
2.2.2 MD First：以 Markdown 作为 Agent 工作语言
[图片]
Agent 工作过程优先使用 Markdown
适合用 Markdown 的内容：
需求理解
边界分析
open questions
人工裁决记录
挖掘策略
失败尝试
经验总结
效果报告
标签定义说明
原因：
- MD 更适合人读
- MD 更适合 Agent 自然读写
- MD 更适合沉淀讨论和判断过程
- MD 更接近真实工作台，而不是状态机
但不是完全不要结构化。
原则是：
MD 是 Agent 的工作语言；
JSONL / CSV / DB 是数据资产的交换格式。
也就是：
- MD 是 Agent 的工作语言；
- JSONL / CSV / DB 是数据资产的交换格式。
内容
推荐格式
需求理解
@@ -209,22 +71,10 @@ JSONL
表格 + MD 报告
工具调用参数
schema / JSON
最终原则：
Agent 工作过程 MD first；
系统边界 schema when needed。
---
2.6 Skills：领域经验包，而不是流程节点
2.2.3 Skills：固化成熟工作流程
[图片]
Skills 不应该被设计成固定节点。
错误理解：
Skill 1：需求理解
Skill 2：边界分析
Skill 3：数据挖掘
Skill 4：预打标
Skill 5：评测生成
这还是 workflow。
正确理解：
Skill 是 Agent 可发现、可按需加载、可组合的领域经验包。
示例：
/skills/
@@ -261,33 +111,10 @@ Agent 在运行中根据问题自主选择是否读取某个 skill。
发现模型离线准确率高但线上效果差
→ 读取 active-learning-router skill
Skill 的价值不是定义流程，而是沉淀经验。
Skill ：之前工作经验的沉淀
---
2.7 Resources：可检索资料
Resources 是 Agent 可读取的业务上下文。
包括：
当前标签定义
历史标签定义版本
历史 badcase
历史人工裁决
已有评测集
已有训练集
线上 session 索引
topquery 集合
模型预测结果
模型误判样本
历史回放报告
Agent 不应该一次性把所有资料塞进上下文。
更合理的方式是：
Agent 先读任务目标
→ 判断需要什么资料
→ 按需检索相关资源
→ 只把当前需要的内容纳入上下文
这样可以避免上下文污染，也能让 Agent 更像真实研究员一样探索。
---
2.8 Tools：可执行能力
2.2.4 Tools：可执行能力
Tools 是 Agent 可以调用的实际能力。
示例：
search_online_sessions()
@@ -314,7 +141,7 @@ Agent 自己决定：
什么时候请求人工裁决
---
2.9 Memory：Agent 外部认知状态
2.2.5 Memory：Agent 外部认知状态
Memory 不是简单存几个结构化字段。
错误理解：
{
@@ -348,74 +175,39 @@ reusable_lessons.md
哪些样本适合评测集
哪些样本只适合训练集
哪些模型错误模式反复出现
判断系统是否真正 Agent-native 的关键标准之一：
下一次遇到类似问题，Agent 是否明显更聪明。
---
2.10 Policy：权限与人工裁决边界
2.2.6 Policy：权限与人工裁决边界
[图片]
Agent 可以自主推进任务，但不能无限自由。
需要明确哪些事情 Agent 可以自动做，哪些必须人类确认。
暂时无法在小米办公Pro文档外展示此内容
核心原则：
Agent 负责探索和建议；
人负责业务边界裁决。
动作
权限
读取需求文档
自动
读取历史标签定义
自动
查询脱敏线上 session
自动
挖候选样本
自动
聚类去重
自动
预打标
自动
生成边界分析
自动
生成标签定义修订建议
自动
修改标签边界
人工确认
样本入库抽检
人工确认
修改历史数据资产
人工确认
---
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. 典型运行方式
2.3 典型运行方式
[图片]
用户输入：
@@ -438,116 +230,162 @@ Agent 启动任务 workspace。
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. 最终结论
3. 第一阶段目标
- 基于现有 Agent 底座完成最小运行环境搭建，并优先打通三条主要的数据开发链路：
- 需求 / badcase 反馈 → 生成式构建专项评测集 → 数据持久化
- 需求 / badcase 反馈 → 挖掘线上问题 → 构建专项评测集 → 数据持久化
- badcase 自动收集与分析链路打通
3.1 第一阶段落地方案
第一阶段基于现有 claw-code-agent 作为执行底座，在保留其通用 Agent 能力的基础上，补齐面向中控数据开发场景的输入、检索、生成、落盘和 review 能力。
让 claw-code-agent 从一个通用 code-agent，变成一个能够进入中控数据开发环境并执行真实任务的数据 Agent 底座。
前两周的目标：
在一个受控工作区内完成：
- 读取需求 / badcase
- 检索线上样本
- 生成或筛选评测集候选
- 记录过程和中间判断
- 输出可落盘、可 review 的结果
在这一底座之上，第一阶段优先验证三条真实链路：
- 需求 / badcase 反馈 → 生成式构建专项评测集 → 数据持久化
- 需求 / badcase 反馈 → 挖掘线上问题 → 构建专项评测集 → 数据持久化
- badcase 自动收集与分析链路打通
落地原则：
底层复用
claw-code-agent 现有的 loop、tool calling、session persistence、transcript、compaction、markdown memory 注入、policy hook 等能力已经足够成熟，适合作为底层执行引擎直接复用。
因此，第一阶段不重写主循环，不重写工具调用链，不重写 session 基础设施。
上层收口
当前 claw-code-agent 的默认形态是 coding-first：prompt 偏代码助手，工具面偏泛代码操作，workspace 也更接近 code workspace。
第一阶段要做的不是扩展更多能力，而是把这些默认形态收口成 data-first：让 Agent 更聚焦于数据检索、样本筛选、评测集构建和结果沉淀。
具体任务拆解：
直接复用底层执行内核
这一部分不作为改造重点，只作为底座能力直接承接：
- Agent loop
- session / transcript / file_history
- tool schema + tool execution
- markdown memory 注入基础能力
- hook / policy 基础机制
- compaction / replay 基础设施
这些能力已经能支撑“模型驱动循环 + 工具调用 + 过程追踪”，第一阶段不需要投入主要精力。
需要改造的四个点：
1）把 code workspace 改成 task workspace @王云浩
这是最关键的一步。
当前底座支持 markdown memory，但还没有真正 task-native 的工作区。第一阶段要把任务固定到 /tasks/{task_id}/ 目录下，让输入、记忆、产物和日志都围绕任务目录组织。
2）把 coding-first prompt 改成 data-first prompt @王云浩
当前 system prompt 更强调读代码、改代码、bash、git、验证代码修改。
第一阶段需要改成围绕：
- 需求理解
- 边界分析
- open questions
- 样本挖掘
- 标注 / 裁决
- eval/train set 构造
- 经验沉淀
这些数据任务来组织默认口径。
3）把默认工具集改成最小数据工具集 @武阳
当前工具面过宽，对数据 Agent 初版来说不是增强，而是噪音。
第一阶段要做的是裁出一套 default_data_tool_registry()，只保留必要文件工具和少量数据专用工具，让 Agent 的动作空间收敛。
4）把 coding policy 扩展成数据治理 policy @武阳
当前权限语义更像：
- allow write
- allow shell
- deny tool
- ask user
但数据场景需要更细的治理边界，比如：
- 是否允许查线上样本
- 是否允许导出敏感字段
- 是否允许生成标注任务
- 哪些问题必须人工裁决
- 哪些标签修订必须人工确认
这一部分必须在第一阶段明确下来。
需要重点建设的两层能力：
1）之前挖掘经验通过SKILL的方式进行注入(需要进行实验和验证)
第一阶段 skill 不应再只是 prompt 片段，而应沉淀成目录化 markdown 经验包，至少覆盖：
- 边界判断
- 线上挖掘
- 评测集构建
并采用“元信息先注入，正文按需展开”的方式，避免一次性把全部经验塞进上下文。
2）artifacts 统一沉淀
第一阶段所有关键结果都应统一沉淀到 task workspace 下，而不是只停留在 session json 或临时输出里。
这一步是后续 review、复盘、数据资产化的前提。
目标的形态
/tasks/{task_id}/
goal.md
context/
requirement.md
badcase.md
memory/
open_questions.md
working_notes.md
decisions.md
artifacts/
eval_candidates.jsonl
mining_strategy.md
report.md
logs/
agent_trace.md
在这个形态下，Agent 能够围绕一个任务完成：
- 输入读取
- 数据检索
- 样本筛选或生成
- 结果沉淀
- 人工 review 触发
代码改造清单
类型
项目
第一阶段动作
说明
直接复用
Agent loop
保留
不重写主循环
直接复用
session / transcript / compaction
保留
直接复用过程追踪能力
直接复用
tool schema / execution
保留
不改调用链
核心改造
workspace
改造
从 code workspace 收口为 task workspace
核心改造
system prompt
改造
从 coding-first 改为 data-first
核心改造
默认工具集
改造
裁出最小数据工具集
核心改造
policy / human gate
改造
从 coding 权限扩展为数据治理边界
必须新增
skill 机制
新增
目录化 markdown 经验包，按需加载
必须新增
artifacts 沉淀规则
新增
所有关键结果统一沉淀到 task 目录
业务验证
生成式评测集构建
打通
作为第一条真实链路
业务验证
线上问题挖掘
打通
作为第二条真实链路
业务验证
badcase 自动收集分析
打通
作为第三条真实链路
[图片]
本项目不应该定义为：
用 Agent 编排快慢系统评测集构建流程
而应该定义为：
给路由数据开发建设一个 Agent-native 工作环境。
最终形态是：
Router Data Agent Workbench
它的核心不是流程，而是：
Workspace
Skills
Resources
Tools
Memory
Policy
它要实现的能力是：
需求 / badcase
→ Agent 自主探索
→ 发现边界问题
→ 挖掘候选数据
→ 提出人工裁决
→ 生成评测 / 训练资产
→ 回放验证
→ 沉淀经验
→ 下次复用
一句话总结：
不是让 AI 跑数据流程，而是让 Agent 拥有一个可以自主完成数据开发工作的环境。