TDSQL Agent 能力探索 —— 实习生任务说明
分支文档快照 · 同步于 2026-09-09 · 来源：origin/summer-intern @ 9f4cdc5 · 原路径：docs/TDSQL_Agent能力探索_实习生任务说明.md。正文描述的是该分支的方案或进展，合入与验收状态以当前看板为准。
项目背景：基于 TDSQL 优化项目，探索 Agent 能力在数据库 SQL 优化场景中的应用。当前分布式数据库优化率基线为 20%，目标冲刺 50%。两个方向共同服务于这一目标，基于通用 Agent 框架（推荐 LangGraph）进行原理理解、前沿技术调研与应用实践。
总周期：8 周（约 2 个月），每周 2 天投入，单人总投入约 16 人天。
总原则：不做从零造轮子，重在理解原理、调研前沿方案、基于成熟框架落地验证。
方向分工总览
| 方向 |
核心命题 |
对 20%→50% 的预期贡献 |
| 方向一：Memory & 上下文管理 & 提示词编写 |
Agent 能不能"记住关键信息、用好有限窗口、选对思考模式" |
+8~12% |
| 方向二：测试集构建 & 测评方案生成 |
能不能精确知道"卡在哪里"、把每次优化结果沉淀为数据资产 |
间接 +10~15% |
说明：原方向二（Subagent & 任务规划及编排）因人力调整已取消。其中专家模式（Multi-Agent 编排范式）的调研工作并入方向一的 Memory 调研阶段，作为 Memory 机制中"经验如何在多角色间流转共享"的理论基础。
方向一：Memory & 上下文管理 & 提示词编写
关注重点
分布式数据库优化场景下，Agent 面临三个核心挑战：
- 上下文太长，窗口不够用：分布式数据库的 schema 信息（分片键、分布策略、节点拓扑、表结构）动辄数万 token，内网可用模型上下文约 100K，如何在有限窗口内装入最关键的信息是一个硬约束。
- 中间经验如何沉淀复用：每次 SQL 优化过程会产生有价值的中间产物（分析结论、改写决策、验证结果），这些"经验"能不能存下来、检索到、用起来，决定了 Agent 是"每次都从头来"还是"越用越聪明"。
- 提示词里的思维模式：grill-me（批判性自检）、Brainstorm（发散探索）、Chain-of-Thought 等不同的 Skill 模式，在 SQL 分析、改写、验证等不同阶段，该用什么模式？什么时候该切换？
任务内容
阶段一：调研（W1-W2，约 5 天）
| 序号 |
任务 |
说明 |
| 1.1 |
Memory 技术综述 |
调研至少 3 个前沿方案（如 Mem0、MemGPT、LangGraph Checkpointer），梳理 Short-term / Long-term / RAG 增强 Memory 在代码优化 Agent 中的应用方式，输出对比分析 |
| 1.2 |
LangGraph 框架学习 |
熟悉 LangGraph 的 Checkpointer、State 管理、Tool 机制，为后续开发做准备。这是后续专家模式调研和开发实现的前置基础 |
| 1.3 |
Skill 模式调研 |
调研 grill-me（批判性自检）、Brainstorm（发散探索）、Chain-of-Thought、Tree-of-Thought 等思维模式的定义与适用场景，分析在 SQL 优化各阶段的潜在应用 |
| 1.4 |
专家模式（Multi-Agent 编排范式）调研 |
基于 LangGraph 框架理解，对比 LangGraph（固定 DAG）、CrewAI（角色分工）、AutoGen（对话协商）三种主流 Multi-Agent 编排范式，重点关注：不同范式下 Agent 间的经验共享与 Memory 传递机制，以及角色分工对记忆管理的影响。为后续经验记忆库的多角色扩展提供理论储备 |
阶段二：设计与实现（W3-W5，约 6 天）
| 序号 |
任务 |
说明 |
优先级 |
| 2.1 |
100K 上下文窗口管理策略 |
实现至少 3 种策略并对比：①滑动窗口截断 ②分层摘要（schema→表级→列级）③按需检索（仅在需要时注入相关 schema）。在测试集上对比各策略的优化率损耗 |
P0 |
| 2.2 |
经验记忆库原型 |
设计经验抽取规则（什么值得存）、实现基于向量检索的经验存储与召回（推荐 ChromaDB / FAISS）、构建"经验抽取→存储→检索→注入"完整链路 |
P0 |
| 2.3 |
Skill 模式切换策略 |
定义至少 3 种 Skill 模式的触发条件（如在分析阶段自动切换 Brainstorm、改写阶段自动切换 grill-me），实现模式切换逻辑并验证效果 |
P1 |
阶段三：实验与验证（W6-W7，约 3 天）
| 序号 |
任务 |
说明 |
| 3.1 |
上下文策略 A/B 实验 |
在统一测试集上跑 3 种上下文策略的优化率对比，输出量化结论 |
| 3.2 |
经验库有效性验证 |
有经验库 vs 无经验库的 A/B 对比，分析经验复用对优化率的提升幅度 |
| 3.3 |
交叉验证 |
上下文策略 × Skill 模式的交叉组合实验 |
阶段四：收尾（W8，约 1 天）
| 序号 |
任务 |
说明 |
| 4.1 |
技术总结文档 |
汇总调研结论（含专家模式调研）、实现方案、实验数据、可复用的设计原则 |
时间分配
W1-W2 ██████████████ 调研 + 框架学习（5天）
W3-W5 ████████████ 开发实现（6天）
W6-W7 ████████ 实验验证（3天）
W8 ██ 总结收尾（1天）
缓冲 ██ 1天
交付物清单
| 编号 |
交付物 |
形式 |
优先级 |
| D1-1 |
Memory 技术综述报告（≥3 方案对比，含专家模式/Multi-Agent 范式调研） |
文档 |
P0 |
| D1-2 |
上下文窗口管理策略实现代码 + 对比实验报告 |
代码 + 文档 |
P0 |
| D1-3 |
经验记忆库原型（含检索链路） |
代码 |
P0 |
| D1-4 |
有/无经验库 A/B 对比实验报告 |
文档 |
P0 |
| D1-5 |
Skill 模式切换策略文档 + 实验数据 |
文档 |
P1 |
| D1-6 |
技术总结报告（含可复用设计原则 ≥5 条） |
文档 |
P0 |
方向二：测试集构建 & 测评方案生成
关注重点
测试与测评是这个项目的"尺子"——没有它，方向一的工作无法被客观评价。
- 多维度比对：不仅仅是"方案 A vs 基线"，而是横向（不同方案间对比）、纵向（同一方案的版本演进追踪）、跨库（分布式 TDSQL vs TDSQL-PG 差异分析）三个维度都要覆盖。
- 结果管理：每次评测的结构化数据（SQL + 方案 + 优化率 + 时间戳）需要持久化存储，支持历史趋势追踪和回归检测。
- 数据资产化：将 Agent 优化过程中产生的 SQL→改写→效果数据，按规范标注，为未来微调储备训练数据。这是具有长期战略价值的产出。
任务内容
阶段一：调研与准备（W1-W2，约 2 天）
| 序号 |
任务 |
说明 |
| 1.1 |
LLM 评测方法论调研 |
调研 LLM-as-Judge、RAGAS 等评测框架在 SQL 等价性验证中的应用，了解业界评测方案设计 best practice |
| 1.2 |
现有测试资产盘点 |
梳理项目已有的 SQL 用例、规则覆盖情况、已知的优化盲区，确定测试集需要补齐的方向 |
阶段二：测试集构建（W3-W4，约 4 天）
| 序号 |
任务 |
说明 |
优先级 |
| 2.1 |
SQL 测试集构建 |
构造 ≥60 条标注 SQL，覆盖：①按规则类型（JOIN/子查询/UNION/窗口函数）②按难度（简单/中等/复杂）③按库（TDSQL 分布式 / TDSQL-PG 双轨）。每条 SQL 需标注预期行为 |
P0 |
| 2.2 |
自动化评测脚本 |
实现一键运行评测、自动输出优化率报告、定位低分 SQL 的脚本。支持批量运行和单项运行两种模式 |
P0 |
阶段三：平台与系统（W5-W6，约 4 天）
| 序号 |
任务 |
说明 |
优先级 |
| 3.1 |
多维度比对平台 |
支持：①横向对比（不同 Agent 方案间的优化率对比）②纵向追踪（同一方案 v1→v2→v3 的优化率变化）③跨库差异分析（分布式 vs PG 的优化率差异）。输出可视化对比报告 |
P0 |
| 3.2 |
评测结果管理系统 |
设计评测结果存储结构（推荐 SQLite 起步，轻量够用），实现评测结果的增删查改和历史趋势查询接口 |
P0 |
阶段四：数据标注与资产化（W7，约 3 天）
| 序号 |
任务 |
说明 |
优先级 |
| 4.1 |
数据标注规范设计 |
设计标注 schema，至少包含：SQL 类型标签、改写规则标签、难度标签、优化效果标签。形成《标注规范文档》 |
P0 |
| 4.2 |
标注工具 + 首批数据集 |
实现简易标注工具（或基于现有工具配置），产出首批标注数据：目标 ≥50 条人工标注 + ≥150 条 LLM 辅助标注（人工抽检） |
P0 |
标注执行分工：标注规范设计和工具由方向二负责。首批数据集的标注执行阶段（W7），方向一投入 0.5 天协助标注，减轻方向二负担。
阶段五：收尾（W8，约 1 天）
| 序号 |
任务 |
说明 |
| 5.1 |
测评方案总文档 |
汇总测试集说明、评测指标体系、评测流程、结果管理方案、标注规范 |
时间分配
W1-W2 ████ 调研与准备（2天）
W3-W4 ████████ 测试集构建（4天）
W5-W6 ████████ 平台与系统开发（4天）
W7 ██████ 数据标注与资产化（3天）
W8 ██ 总结收尾（1天）
缓冲 ██ 2天（含 W7 外援 0.5天）
交付物清单
| 编号 |
交付物 |
形式 |
优先级 |
| D2-1 |
LLM 评测方法论调研报告 |
文档 |
P0 |
| D2-2 |
SQL 测试用例集（≥60 条，分类标注） |
数据文件 |
P0 |
| D2-3 |
自动化评测脚本 + 使用说明 |
代码 + 文档 |
P0 |
| D2-4 |
多维度比对平台 + 可视化报告模板 |
代码 |
P0 |
| D2-5 |
评测结果管理系统（数据库 + 接口） |
代码 |
P0 |
| D2-6 |
数据标注规范文档 |
文档 |
P0 |
| D2-7 |
首批标注数据集（≥200 条） |
数据文件 |
P0 |
| D2-8 |
测评方案总文档 |
文档 |
P0 |
共同时间线
| 周次 |
阶段 |
方向一 |
方向二（原方向三） |
共同动作 |
| W1 |
调研 |
Memory 综述 + LangGraph 框架学习 |
评测方法论调研 |
周五：方向 review 会，各自汇报调研进展 |
| W2 |
调研 |
Skill 模式调研 + 专家模式调研 |
资产盘点 |
周五：统一选定主框架（推荐 LangGraph），各方向确认技术方案 |
| W3 |
研发 |
上下文策略实现 |
测试集构建 |
— |
| W4 |
研发 |
上下文策略实现 |
测试集构建 + 评测脚本 |
— |
| W5 |
研发 |
经验库开发 |
比对平台开发 |
周五：中期同步，各方向展示 v1 成果 |
| W6 |
★评测 |
A/B 实验 |
结果管理系统 |
周三前：方向一提交评测数据给方向二；周五：强制合流评测，全量数据汇总 |
| W7 |
迭代 |
交叉实验 + 补齐 P1 |
数据标注（二人协作） |
周三：标注突击（二人各 0.5 天）；周五：交叉集成验证 |
| W8 |
收尾 |
总结文档 |
方案总文档 |
周五：终期汇报 + 成果归档 |
其他重要事项
1. 优先级约定
每个方向标注了 P0（必须交付）和 P1（尽量交付）。核心底线：所有 P0 项必须在 W8 前完成。P1 项可在 W7 根据实际进度决定是否补齐。
2. 每周同步机制
- 时间：每周五下午 30 分钟
- 内容：本周进展、阻塞项、下周计划
- 产出：周报要点（方向二汇总评测数据时一并输出）
3. 技术栈建议
| 组件 |
推荐方案 |
说明 |
| Agent 框架 |
LangGraph（主推） |
Checkpointer 天然支持 Memory 方向，同时为后续可能的多角色扩展留有接口 |
| 向量存储 |
ChromaDB / FAISS |
轻量、本地可跑，满足原型阶段需求 |
| 评测存储 |
SQLite |
轻量够用，后续可迁移到正式数据库 |
| 标注工具 |
基于现有工具配置或简易自研 |
优先复用，不造轮子 |
| 内网模型 |
项目提供（上下文约 100K） |
所有方案需适配此约束 |
4. 信息共享
- 两个方向的代码统一放在项目仓库，目录结构在 W2 同步会上确认
- 调研报告和实验报告上传项目资料库，方便互相引用
- 方向二的评测脚本需提供 API，供方向一在 W5 前接入自测
5. 关键风险提示
| 风险 |
应对 |
| 内网模型能力/稳定性不确定 |
W1 先跑通模型调用链路，尽早发现兼容性问题 |
| 方向一的实验可能多轮迭代 |
W5 前锁定上下文策略实现，W6 开始实验，不够就压缩 Skill 模式探索（P1） |
| 方向二标注耗时可能超预期 |
W7 二人协作 + LLM 辅助标注，目标不降但分配更灵活 |
| 方向间接口不兼容 |
W2 统一框架选型，W5 前方向二给出评测接入规范 |
| 方向一调研范围扩大（新增专家模式） |
专家模式调研定位为理论储备，不要求实现验证；若时间紧张可降为 P1 |
6. 交付物归档要求
所有交付物（代码、文档、数据）需在 W8 完成时归档到项目资料库，归档结构：
TDSQL-Agent-Exploration/
├── 01-Memory（方向一）/
│ ├── 调研报告/
│ │ ├── Memory技术综述（含专家模式调研）/
│ │ └── Skill模式调研/
│ ├── 实现代码/
│ └── 实验报告/
├── 02-Evaluation（方向二）/
│ ├── 测试集/
│ ├── 评测平台代码/
│ ├── 标注数据集/
│ └── 测评方案文档/
└── 00-Common/
├── 周报/
└── 终期汇报材料/
最后提醒：本次实习的核心目的是让两位同学在真实项目中理解 Agent 技术的原理和前沿方向，并通过实践验证学到的东西。代码 demo 不追求生产级质量，但实验设计必须严谨、结论必须有数据支撑、调研报告必须体现深度。能说清楚"为什么这个方案好/不好"比"实现了一个能跑的方案"更有价值。