武阳
392 lines
12 KiB
Markdown
392 lines
12 KiB
Markdown
中控数据Agent构建-汇报
|
||
Badcase 反馈渠道接入与自动收集分析:数据挖掘Agent设计方案
|
||
1. 背景与目标
|
||
- 数据开发是中控核心工作之一，但当前流程仍以人工驱动为主。
|
||
- 需求 / badcase 驱动的评测集构建、样本补充和线上挖掘链路分散，人工介入重、复用性差。
|
||
- 结合近期 AI native 工作方式转变，我们希望基于 Agent 底座先打通最小数据开发闭环。
|
||
当前方式的瓶颈与挑战：
|
||
- 人工驱动重：从需求、badcase 到评测集构建，多个关键环节依赖人工推进。
|
||
- 流程割裂重：人工构造、线上挖掘、LLM 生成彼此分散，数据格式转换和整理成本高。
|
||
- 经验复用弱：边界判断和处理经验难以沉淀，导致新问题进入后仍需重复劳动。
|
||
数据开发范式转变：
|
||
[图片]
|
||
2. AI Native数据Agent
|
||
不是做一个固定流程平台，而是做一个 Agent-native 的数据开发工作台。
|
||
让 Agent 能够围绕一个需求 / badcase，自主理解问题、探索数据、发现边界冲突、提出人工裁决问题、生成评测集候选、沉淀长期经验，从而显著提升路由评测 / 训练数据构建效率。
|
||
|
||
---
|
||
2.1 设计目标与边界
|
||
- 核心目标：基于一个精简、可定制的 Agent 底座，建设一个面向中控数据开发场景的智能体执行底座。
|
||
- 方案形态：不是“流程自动化 + LLM 节点”，而是一个以 Agent 为核心、能够围绕任务自主检索、生成、筛选和整理的数据开发执行底座。
|
||
- 实现方式：基于 code-agent / claw-code-agent 实现，复用 Agent loop、文件读写、工具调用、代码执行、过程记录等通用能力。
|
||
[图片]
|
||
|
||
---
|
||
2.2 核心架构
|
||
- 中控数据Agent应该由 6 个核心要素组成：
|
||
- Workspace：任务工作区
|
||
- Skills：领域经验包
|
||
- Tools：可执行工具
|
||
- Memory：Agent 外部认知状态
|
||
- Policy：权限与人工裁决边界
|
||
[图片]
|
||
|
||
---
|
||
2.2.1 Workspace：任务工作区
|
||
每个需求 / badcase 启动后，系统创建一个独立 workspace。
|
||
示例结构：
|
||
[图片]
|
||
Workspace 的作用：
|
||
- 承载任务上下文
|
||
- 记录 Agent 中间理解
|
||
- 保存探索过程
|
||
- 支持人机协作
|
||
- 沉淀可复用经验
|
||
- 保证过程可追溯
|
||
Agent 不是在一个固定流程里跑，而是在 workspace 按照我们之前的工作流程去工作
|
||
|
||
---
|
||
2.2.2 MD First：以 Markdown 作为 Agent 工作语言
|
||
[图片]
|
||
Agent 工作过程优先使用 Markdown
|
||
- MD 是 Agent 的工作语言；
|
||
- JSONL / CSV / DB 是数据资产的交换格式。
|
||
内容
|
||
推荐格式
|
||
需求理解
|
||
MD
|
||
边界分析
|
||
MD
|
||
人工裁决
|
||
MD
|
||
经验沉淀
|
||
MD
|
||
候选样本池
|
||
CSV / JSONL
|
||
评测集
|
||
JSONL
|
||
训练集
|
||
JSONL
|
||
回放结果
|
||
表格 + MD 报告
|
||
工具调用参数
|
||
schema / JSON
|
||
|
||
---
|
||
2.2.3 Skills：固化成熟工作流程
|
||
[图片]
|
||
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.2.4 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.2.5 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
|
||
记录可复用经验，供后续任务调用。
|
||
长期看，系统要沉淀：
|
||
哪些标签容易混淆
|
||
哪些边界已有裁决
|
||
哪些挖掘策略有效
|
||
哪些关键词误伤高
|
||
哪些样本适合评测集
|
||
哪些样本只适合训练集
|
||
哪些模型错误模式反复出现
|
||
|
||
---
|
||
2.2.6 Policy：权限与人工裁决边界
|
||
[图片]
|
||
Agent 可以自主推进任务，但不能无限自由。
|
||
需要明确哪些事情 Agent 可以自动做，哪些必须人类确认。
|
||
动作
|
||
权限
|
||
读取需求文档
|
||
自动
|
||
读取历史标签定义
|
||
自动
|
||
查询脱敏线上 session
|
||
自动
|
||
挖候选样本
|
||
自动
|
||
聚类去重
|
||
自动
|
||
预打标
|
||
自动
|
||
生成边界分析
|
||
自动
|
||
生成标签定义修订建议
|
||
自动
|
||
修改标签边界
|
||
人工确认
|
||
样本入库抽检
|
||
人工确认
|
||
修改历史数据资产
|
||
人工确认
|
||
|
||
---
|
||
2.3 典型运行方式
|
||
[图片]
|
||
|
||
用户输入：
|
||
一批 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
|
||
|
||
---
|
||
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 自动收集分析
|
||
打通
|
||
作为第三条真实链路
|
||
[图片]
|
||
|
||
|
||
|
||
|