一、采购背景与目的
为满足公司相关业务发展及项目推进需求，提升相关产品及技术能力，降低自研数据的时间与成本投入，保障各项工作有序推进，现对外采购成熟成品智能体数据，以适配相关技术应用及业务开展要求。
二、数据主体与范围
2.1 数据类型
信息获取类、内容生产类、执行操作类、决策支持类、交互陪伴类（目前类型上暂无侧重）
2.2 数据量级与交付要求
(1) 数据量级：待定____
(2) 交付周期：待定__
三、数据格式/内容要求
3.1 数据交付格式
高难Query：完整清晰Query。
- 完整智能体数据
- 数据基本单位：以一组完整的会话（Session）为一组数据，一组session中含多轮对话。（不可用单轮请求的数据因包裹上文信息而视为多轮对话）
- 文件存储规范：使用 .json/jsonl 格式。允许并建议将一个 Session 的所有交互时序数据整体打包，每轮对话作为单行 JSON 对象输出。
3.2 数据内容要求
3.2.1 用户输入需求
- 难度要求：所有会话的用户输入需求不得是简单指令（如单纯的问答、打招呼），整体数据集的难度分布必须在 中级及以上。定级标准如下：
| 难度等级 | 定义标准 | 数据示例 |
|---|---|---|
| 初级 | 问题基于基础常识或简单事实判断，知识门槛较低，一般由本科阶段学生或初入行业者即可准确回答。此类数据直接剔除。 | “如何打印Hello World”、“解释什么是 Git” |
| 中级 | 问题涉及基本专业概念、常见规范或通用实务，需具备一定的专业背景。通常需调用检索工具（如 Glob/Grep）或读取单个文件后才能较好作答。 | “帮我做一个销售数据分析的PPT” |
| 高级 | 问题需系统性知识支撑，涉及综合理解或多概念联动，适合具备扎实专业基础的 3 年以上从业人员。包含清晰的跨文件重构、复杂 Bug 修复及“规划(Plan) → 执行 → 测试”闭环。 | “每天早上9点从三个网站收集新闻，整理后发送到我的邮箱” |
| 资深级 | 问题带有实务难度或专业细节判断，涉及极度复杂的应用情境搭建、隐蔽的死锁/内存泄漏排查，通常需 5 年以上从业经验才能胜任。 | “分析我是否该创业，帮我做一个评估” |
| 专家级 | 问题处于该领域的前沿、交叉或争议地带，要求高度抽象思维与洞察力，涉及底层源码逻辑重写、前沿框架的交叉编译与调试。 | “收集竞争对手信息，形成对比报告” |
真实性要求：所有会话的用户输入需求不得是高级难度以下的有明显合成痕迹的数据（如“我下午要给客户提案，先帮我做一张咖啡品牌春季上新海报，风格要精致一点。”）。
3.2.2 交互轨迹数据
完整性要求：同一个 Session 内部的 API 请求/响应记录，必须包含从用户发起初始提问，到 AI 最终解决问题的全生命周期数据。
- 包含环境真实反馈：如果第 N 轮 response.choices 中模型发起了工具调用（如 Bash , Edit , Read 等），那么在第 N+1 轮请求的 messages 数组中，必须真实存在该工具执行后的返回结果（如报错堆栈、命令行 Stdout 输出、读取到的代码片段等）。缺失环境真实反馈的“断层数据”直接视为无效。
- 不可逻辑跳跃：模型不能在没有任何文件读取动作（如 Read/Glob/Grep ）的情况下，直接“盲猜”并准确给出指定文件某行某列的代码修改（Edit ）。必须体现出Search/Read → Think → Edit 的合理逻辑链条。
多轮对话要求：一组session中含多轮对话。
- 时序性要求：内部数组必须严格按照请求时间戳（start_time ）由远至近（升序）排列，不得出现抽帧、跳步或时序错乱。
有效性要求：
-
无报错：轨迹无报错（error ）；
-
报错被解决：轨迹有报错，报错被解决。
-
特殊标记数据：出现频繁报错，即使最后都被解决。
-
数据样例：
代码块
{// ================= [外层:Session 级元数据] =================“session_id”:
“session_240fcd18-61b1-4e9e-92eb-51eb40c085c3”, “session_start_time”: “2026-03
12T19:04:49.443695”, // 会话开始时间"session_end_time": “2026-03
12T19:30:59.113766”, // 会话结束时间"user_agent": “claude-cli/2.1.74
(external, cli)”, // 客户端种类信息
(JSON.kwargs.standard_logging_object.metadata.user_agent)“model”:
“anthropic/glm-4.7”, // 实际主力调用的模型
(JSON.kwargs.standard_logging_object.model)// ================= [内层:交互轨迹列
表(严格按时间升序)] =================“trajectories”: [
{// 第 1 轮交互"request_id": “e9d3dde0-884c-4737-be0f-780601212e0a”, //
匹配请求中的 litellm_call_id"start_time": “2026-03-12T19:04:49.443695”, // 对话
开始时间 JSON.kwargs.start_time"end_time": “2026-03-12T19:04:59.113766”, //
JSON.kwargs.end_time"call_type": “anthropic_messages”, // 网关信息遵循
的格式协议 JSON.kwargs.standard_logging_object.call_type"status": “success”,
// 请求是否成功 JSON.kwargs.standard_logging_object.status
(必须为 success)// 必须字段:当前轮次开放给大模型的实际可用工具集 (JSON Schema 格
式)“tools”: [ { “name”: “Bash”, “description”: “…”, “input_schema”: {…} }
],
// 必须字段:System Prompt 列表"system": [ { “type”: “text”, “text”:
“You are Claude Code…” } ],
// 必须字段:发送给大模型的完整上下文。// 【重点质检项】:必须真实包含历史
User 输入、Assistant 回复，以及上一轮 Tool 执行后的真实返回结果
(Observation)“messages”: [
{ “role”: “user”, “content”: “…” }
],
// 必须字段:大模型的真实响应"response": {“response_id”: “e9d3dde0
884c-4737-be0f-780601212e0a”, // JSON.response_obj.id (匹配 request_id)“model”:
“glm-4.7”, //
JSON.response_obj.model"session_id": “session_240fcd18-61b1-4e9e-92eb
51eb40c085c3”, // 和外层一致"choices": [// JSON.response_obj.choices 模型响应列
表。包含文本(thinking/content)和动作(tool_calls)
],“usage”: {// JSON.response_obj.usage Token消耗情
况"prompt_tokens": 21836,“completion_tokens”: 207
}
}
},
{// 第 2 轮交互…(结构同上，其 messages 数组内必须带有第 1 轮工具执行后的结
果)“request_id”: “f8a4d2b1…”,// …
}// … 直至任务结束的第 N 轮
]
}
四、数据质检&验收维度
接收数据之后按照完整的 Session作为单条数据进行质检&验收，若出现以下任意情况异常，则判定为此条数据不合格。
- JSON/JSONL 格式及字段完整度（tools , messages , response 缺一不可）。
- trajectories 数组内的时间戳（start_time ）是否保持固定升序。
- 工具调用闭环：发起的 tool_calls 是否在后续 messages 中有对应的结果回传。
- 必须剔除因网络超时（Timeout）、网关 502/504 错误产生的纯废弃请求。只保留具有明确交互意义的 status: “success” 的请求。
- 任务难度：是否达标中级及以上，若不达标直接判定为不合格。
- 任务真实性：初级和中级难度且有明显合成痕迹的数据判定不合格。
- 任务解决情况：最终模型输出是否真正解决了用户的初始问题，若没有解决则直接判断为不合格。
- 交互轨迹真实性：是否存在伪造工具返回值、是否存在严重的逻辑断层。
- 隐私与敏感信息：交付的数据中不可包含，真实的个人姓名、手机号、真实企业内网 IP/域名、绝对本地路径（如真实的 C:\Users\张三\公司机密项目\
五、验收及结算规则
5.1 验收及格线
整体数据合格率必须 ≥98 % 。
5.2 结算规则
在确认本批次数据采购后，供应商需提供全量数据进行交付，我方会根据交付数据随机抽取50~100条数据进行验收。
- 合格率（98%以上）：正常100%结算
- 合格率（98%以下）：允许供应商返修2次，返修时间不可超过3个工作日，若返修依旧不合格，则不予结算
- 交付周期：供应商需在确认采购的5日（工作日）完成交付，如果交付逾期，我方可有权放弃采购