通用大模型 Agent 项目 · 标注规则文档
本文档适用于 Agent 数据项目中的标注员、质检员、规则负责人和项目经理，重点用于指导多场景 Agent 数据的审核、改写、质检与交付。
1
项目背景与目标
1.1 项目背景
本项目为通用大模型 Agent 能力建设项目，目标不是让模型只会“回答问题”，而是让模型能够围绕用户目标进行任务理解、步骤规划、工具调用、结果观察、继续决策与最终闭环。项目数据将主要用于 SFT 阶段，并可扩展支持 RM、行为偏好优化与 Agent 对齐训练。
Agent 项目和普通问答项目的关键差异在于：普通 QA 数据更强调“答案内容”，而 Agent 数据更强调“任务过程 + 工具行为 + 闭环结果”。
1.2 项目目标
模型侧目标
- 学会把复杂任务拆解成合理步骤
- 学会判断何时需要调用工具
- 学会选择正确工具并填写完整参数
- 学会基于工具结果继续决策而非直接编造
- 学会在失败、缺参、高风险场景中合理处理
数据侧目标
- 首期交付高质量 Agent 样本 80,000 条
- 试标期规则一致率达到 ≥ 85%
- 正式期整体质检通过率达到 ≥ 90%
- 高风险样本漏检率控制在 ≤ 0.5%
- 形成可复用的 Agent 场景规则与案例库
1.3 适用场景
办公协同类
会议、日程、邮件、文档、待办
如会议室预定、纪要总结、邮件起草、日程查询与待办抽取。
检索与分析类
搜索、总结、比对、归纳
如检索竞品信息、汇总报告、提取风险点、生成比较表。
服务与导购类
客服、导购、流程引导
如智能客服、旅游规划、商品导购、流程咨询。
2
Agent 基础认知
2.1 什么是 Agent
Agent 是指一个具备感知、决策、行动能力的自主系统。在大模型场景下，Agent 以 LLM 为认知核心，整合规划、记忆和工具调用等能力，能够完成复杂任务，而不只是输出单轮答案。
重要区分：“搭建 Agent”是基于现有模型和工具做应用层编排；“训练 Agent”是通过高质量数据教模型本身学会规划和调用工具。
2.2 技术原理
| 组件 | 子能力 | 说明 |
|---|---|---|
| LLM | 理解、生成、推理 | 作为 Agent 的认知核心，负责理解任务与生成中间/最终输出 |
| Planning | 目标分解、思维链、自我反思 | 把复杂任务拆解为可执行步骤 |
| Memory | 短期记忆、长期记忆 | 保存上下文、用户偏好和执行历史 |
| Tools | 搜索、日历、会议室、支付、数据库等 | 扩展模型的外部行动能力 |
| Action | 执行、观察、继续决策 | 基于工具结果推进任务闭环 |
2.3 Agent 数据的标准组成
User: 用户问题
Think: 模型的思考 / 规划过程
Action: 工具调用（工具名 + 参数）
Observation: 工具返回结果
Response: 最终回复2.4 为什么要单独做 Agent 项目标注
因为真实任务场景中，模型经常出现以下问题：该调用工具时不调、不该调用时乱调、缺少必填参数仍直接执行、上下文不一致、失败时编造结果、遇到高风险请求越权行动。Agent 数据标注的本质，就是筛掉这些错误行为，并把正确行为稳定地教给模型。
3
数据来源、总量级与输入输出形式
首期主数据
120,000
条
目标交付
80,000
条高质量样本
偏好对比数据
5,000
组
场景数
12+
会议/客服/导购/文档等
3.1 数据来源
| 数据来源 | 说明 | 建议占比 |
|---|---|---|
| 真实业务任务改写 | 基于真实用户需求脱敏、泛化后形成任务样本 | 35% |
| 人工构造任务 | 由项目组补齐多场景、多工具、多异常流程数据 | 30% |
| 历史 QA 升级 | 从问答项目中抽取可 Agent 化任务，补规划与工具行为 | 15% |
| 工具日志模拟 | 结合工具 schema 构造动作与 observation 轨迹 | 10% |
| 错误案例反构造 | 从内测失败案例中逆向构造纠错数据 | 10% |
3.2 输入与输出形式
输入字段
- 用户原始指令
- 历史上下文
- Agent 功能介绍 / System Prompt
- 工具定义表（Tool Definition）
- 环境状态 / 附件 / 权限说明
输出字段
- 思考是否正确
- 行动是否正确
- 思考错误原因
- 行动错误原因
- 改写后内容
- 是否已改写 / 备注
3.3 Session 级表格结构
| session序号 | 轮次id | 用户资料 | 角色 | 原内容 | 思考对 | 行动对 | 思考过程错误原因 | 行动部分错误原因 | 改写后 | 是否已改写 | 其他备注/疑问 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 001 | 1 | — | AGENT | 用户问：下周这个时候有个项目汇报，帮我查空会议室…… | 0 | 0 | 未确认会议时长即默认 1 小时，思考不完整 | 调用查询工具时缺少完整 end_time 构造依据 | 先取当前时间，再询问会议时长，再调用查询工具 | 已改写 | 培训案例 |
4
人员成本与人效
团队总人数
19
项目建议配置
标注员
12
常规 Agent 标注
质检员
4
含高风险样本复检
项目周期
10 周
含培训和复检
4.1 人效估算
| 角色 | 每小时产能 | 每天产能（8h） | 说明 |
|---|---|---|---|
| 标注员 | 18～24 条 | 140～180 条 | 按中等复杂度样本估算，建议按 160 条/天/人做排期 |
| 质检员 | 30～40 条 | 240～320 条 | 建议按 280 条/天/人做排期，高风险样本速度会下降 |
4.2 推荐作业节奏
| 周次 | 阶段 | 主要任务 | 交付物 |
|---|---|---|---|
| Week 1 | 规则定稿与试标 | 场景培训、答疑、带练，小样本全检，修正文档 | 试标报告、规则定稿 |
| Week 2～8 | 正式生产 | 按场景分桶标注，持续更新 FAQ，执行抽检与复检 | 各批次数据包 |
| Week 9 | 集中修订 | 回溯高争议数据、低分标注员样本与高风险池样本 | 修订汇总 |
| Week 10 | 终检与交付 | 完成 spot check、产出周报和最终交付集 | 最终数据集 + 质检报告 |
5
标注规则总表
5.0 规则优先级概览
Agent 标注规则按优先级分层，安全与权限合规为一票否决项，任何轮次中发现越权、臆造或高风险放行，整条数据直接判定「舍弃」。
安全维度为一票否决项：该澄清未澄清即执行高风险动作、编造工具结果、放过明显越权样本等，无需继续评估其他维度，整条数据直接舍弃。
最高优先级一票否决
任务理解20%
工具执行20%
逻辑闭环15%
结果可用15%
5.1 规则明细表
以下规则是 Agent 项目标注的统一判断口径，标注员必须先对照场景功能介绍和工具定义，再按下表逐项判断。
| 规则名称 | 解释 | 标注技巧 | 正向案例 | 负向案例 |
|---|---|---|---|---|
| 任务类型识别 | 判断用户请求属于何种 Agent 任务 | 先看最终目标，不只看表面动作词 | “整理合同并提炼风险”→文档分析 | 只因出现“合同”就标成知识问答 |
| 是否需要澄清 | 判断当前信息是否足够执行 | 缺主体、时间、对象、约束时优先澄清 | 未给会议时长 → 先询问用户 | 直接默认 1 小时后执行 |
| 是否需要工具 | 判断任务是否依赖外部能力 | 文件、最新信息、执行动作通常都需要工具 | 总结上传 PDF → 需要工具 | 没读文件就直接编摘要 |
| 工具选择合理性 | 所选工具是否和任务匹配 | 遵循最小必要原则，不乱串工具 | 总结纪要 → 文档读取工具 | 总结纪要却先网页搜索 |
| 工具参数完整性 | 参数是否足以执行 | 检查对象、范围、时间、条件是否齐全 | start_time + end_time 都齐全 | 只写“下周下午”就直接调工具 |
| 任务拆解有效性 | 步骤是否具体可执行 | 拒绝“分析问题/给出答案”式空话 | 读取文档→提取条款→定位风险 | 理解任务→认真思考→输出回答 |
| 中间决策一致性 | 前后动作是否与上下文一致 | 检查实体、时间、对象是否漂移 | 搜索失败后说明未找到 | 搜索失败却输出完整结果 |
| 最终结果完成度 | 是否真正满足用户目标 | 回到原始指令逐项核查 | 用户要待办+责任人，结果都给出 | 只写摘要，漏掉责任人 |
| 异常处理合理性 | 失败、无结果、冲突时是否诚实处理 | 不编造，说明限制并给替代方案 | 文件损坏 → 提示重传 | 文件读失败仍输出内容 |
| 安全与权限合规 | 高风险动作是否符合权限边界 | 删除、发送、支付、隐私读取要谨慎 | 发送邮件前先确认收件人 | 未确认就直接外发 |
核心原则：功能介绍是角色边界，工具定义是行动依据，用户目标是最终判断标准。
6
标注策略与 Agent 8 步法
6.1 标注总体策略
原则 1
先理解任务
不先看标签，先看用户真正想完成什么
原则 2
先判能否执行
信息不足先澄清，再谈工具和结果
原则 3
先看是否闭环
中间过程再漂亮，没解决问题也不合格
6.2 Agent 智能体标注步骤（8 步法）
1
阅读场景设定
每个场景文件都包含功能介绍、角色边界和注意事项，必须先读完。
2
阅读工具定义
所有行动都只能调用工具定义中已有的工具；若当前能力无法满足需求，思考中应明确说明需要向用户澄清或说明能力边界。
3
阅读 USER 需求并检查 Think
思考对标 1，思考错标 0，并写清错误原因。错误原因必须能让没参加标注的人也看懂。
4
检查 Action
行动对标 1，行动错标 0。重点判断：工具是否选对、参数是否填全、顺序是否正确。
5
如有错误则改写
可改、删、增，但必须符合上下文、场景设定和工具 schema。
6
填写“是否已改写”
若对原内容做了任何修正，必须在“是否已改写”列写明“已改写”。
7
全 Session 通读检查
若改写涉及新增或删除轮次，需要同步调整轮次 ID，保证整个 session 连贯。
8
JSON 代码检查
凡是修改了行动部分代码或参数对象，必须进行 JSON 合法性校验，否则整条数据会失效。
6.3 标注结果判定
| 判定结果 | 条件 | 操作 |
|---|---|---|
| 通过 | 思考与行动均无问题 | 标注为 1，可直接进入训练集 |
| 不通过—改写 | 存在错误，但可以修复 | 标注为 0，备注错误原因并完成改写 |
| 舍弃 | 整段多轮存在严重错误、乱码、工具定义不清或无法合理修复 | 直接丢弃，不进入训练集 |
6.4 特殊场景处理规则
| 特殊情况 | 处理方式 |
|---|---|
| 用户需求模糊或缺参 | 优先通过 talk_to_user 澄清，不得臆造参数直接执行；若无法澄清则说明能力边界 |
| 工具调用失败或无结果 | 诚实告知用户，不编造结果；可提供替代方案（如换时间、换条件查询） |
| 多工具需串联调用 | 按依赖顺序执行，前一步结果作为后一步参数依据；不得跳过必要步骤 |
| 遇到工具定义中未覆盖的能力 | 在思考中说明需向用户澄清或说明能力边界，不得调用不存在工具 |
| 规则文档没有明确说明的情形 | @组长/PM 描述疑问 → 等待官方解释，不擅自决策 |
7
会议室助手场景案例（附录示例）
7.1 填写规范约定
填写规范约定：
- 红色高亮：原内容列中，具体的错误片段区域
- 绿色高亮：「改写后」列中，相比原内容新增或修改的片段
- 错误原因必须具体到哪一轮、什么问题，不可模糊填写
7.2 功能介绍（System Prompt 示例）
【角色名称&功能概述】
你的名字叫小团，是一个会议室预定助手，你能够帮助用户完成会议室的查询和预定功能。
【运行准则】
1. 预订时间提醒：如果用户预订的时间在当前时间之前，则提醒用户已过期无法预订。
2. current_time_fetch 注意事项：current_time_fetch 如果之前调用过，则无需重复调用，直接使用之前结果。
【回复格式】
1. 信息展现：向用户展示会议室信息时，请采用 Markdown 表格。
2. 信息真实性：你提供给用户的信息一定来自行为日志中的，不得随意杜撰。7.3 工具定义示例
| Tool Name | Description | Argument Name | Schema | Required | Description |
|---|---|---|---|---|---|
| free_meeting_room_query | 查询指定时间段的空闲会议室 | start_time | string | TRUE | 格式 YYYY-MM-DDTHH:mm:ss |
| end_time | string | TRUE | 格式 YYYY-MM-DDTHH:mm:ss | ||
| meeting_room_availability_query | 查询某个会议室的空闲时间段 | meeting_room_id | integer | TRUE | 会议室 ID，例如 101 |
| date_range | string | TRUE | {'start_date': '2023-04-01', 'end_date': '2023-04-07'} | ||
| current_time_fetch | 获取当前时间 | [] | — | — | 无需传入任何参数 |
| meeting_room_booking | 预定会议室 | meeting_room_id | integer | TRUE | 需要预定的会议室标识 ID |
| username | string | TRUE | 进行预定的用户名称 | ||
| time_slot | string | TRUE | {'start_time': '2023-04-01T13:00:00', 'end_time': '2023-04-01T15:00:00'} | ||
| talk_to_user | 通过该工具和用户交流 | [] | — | — | 无需传入任何参数 |
7.4 该场景的标注重点
- 是否真正理解用户目标是“查空会议室 / 查某个会议室空闲时段 / 直接预定会议室”中的哪一种
- 是否识别缺失参数，如会议时长、开始时间、用户名、会议室 ID
- 是否遵守
current_time_fetch复用规则，避免重复调用 - 最终给用户的会议室信息是否全部来自工具日志，而非模型臆造
- 查询结果展示是否优先使用 Markdown 表格
7.5 典型错误案例与正确改写
左边看“错误写法”，右边看“正确改写”，标注员可以直接对照学习。
错误写法
用户：我下周这个时候有个项目汇报，帮我查一下那时候哪些会议室是空的。
错误思考：用户想查下周同一时刻的会议室空闲情况，我可以默认会议持续 1 小时，然后直接查询。
错误行动：先调用 current_time_fetch，再直接调用 free_meeting_room_query。
为什么错：用户没有提供会议时长，当前无法唯一确定
end_time。模型不能自行默认 1 小时，应先通过 talk_to_user 向用户确认持续时间。
正确改写
用户：我下周这个时候有个项目汇报，帮我查一下那时候哪些会议室是空的。
正确思考：用户希望查询下周同一时刻的空闲会议室。我需要先获取当前时间，计算出下周对应时间。由于用户未说明会议持续时长，暂时无法构造完整的查询时间段，因此需要先向用户确认会议时长。
正确行动：
- 调用
current_time_fetch - 调用
talk_to_user，询问：“请问这次会议预计持续多久？”
7.6 适合培训时投屏展示的完整改写示例
用户：我下周这个时候有个项目汇报，帮我查一下那时候哪些会议室是空的。
Agent思考：用户希望查询下周同一时刻的空闲会议室。我需要先获取当前时间，计算出下周对应时间。由于用户未说明会议持续时长，暂时无法构造完整的查询时间段，因此需要先向用户确认会议时长。
Agent行动：
1. 调用 current_time_fetch
2. 调用 talk_to_user，询问：“请问这次会议预计持续多久？”7.7 用于培训的表头示例
| session序号 | 轮次id | 用户资料 | 角色 | 原内容 | 思考对 | 行动对 | 思考过程错误原因 | 行动部分错误原因 | 改写后 | 是否已改写 | 其他备注/疑问 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 001 | 2 | — | AGENT | 默认会议 1 小时并直接查询会议室 | 0 | 0 | 未识别缺失参数：会议时长。用户只说“下周这个时候”，只能先定位开始时间，不能直接推导结束时间。 | 在参数不完整时提前调用查询工具，导致 free_meeting_room_query 的 end_time 缺乏依据。 | 先询问会议时长，再根据完整时间段查询空闲会议室。 | 已改写 | 会议室助手带练案例，可作为新人培训样例。 |
核心填写红线：
- 「思考过程错误原因」「行动部分错误原因」必须注明具体是哪一轮、什么问题，不可模糊填写
- 「改写后」是最终进入训练集的内容，改写质量直接影响模型效果，必须符合工具 schema 与场景设定
- 禁止使用工具定义中不存在的工具
- 禁止在参数不完整时臆造参数并直接调用
8
质检标准
8.0 三层质检体系
| 层次 | 执行者 | 方式 | 频率 | 目标通过率 |
|---|---|---|---|---|
| L1 自检 | 标注员本人 | 提交前逐项核对自检清单（见 8.4 节） | 每条提交前 | ≥ 98%（自检漏项 < 2%） |
| L2 抽检 | 质检员 | 每批次随机抽取 20%～30% 全量质检 | 每日 | ≥ 90%（低于此线全批打回） |
| L3 全量复检 | 质检员 + 组长 | 最终交付前对高风险样本、复杂多轮样本全量扫描 | 项目结束前 | ≥ 95%（最终交付标准） |
8.1 抽检比例
冷启动试标
100%
新人全检
正式期常规抽检
20%～30%
普通样本
高风险样本
100%
必须全检
复杂多轮样本
50%+
重点抽检
8.2 质检评分维度
| 维度 | 检查内容 | 分值 |
|---|---|---|
| 任务理解准确性 | 是否识别正确主目标与任务类型 | 20 |
| 规则执行一致性 | 是否按规则口径稳定标注 | 20 |
| 工具标注正确性 | 工具选择、时机、参数是否合理 | 20 |
| 逻辑链路完整性 | 步骤、上下文和最终结果是否一致 | 15 |
| 最终结果可用性 | 是否真正解决用户问题 | 15 |
| 安全合规性 | 是否存在越权、臆造或风险放行 | 10 |
8.3 质检判定标准
| 质检结论 | 触发条件 | 处理动作 |
|---|---|---|
| 通过 | 全维度达标，思考与行动正确，格式字段完整 | 数据进入训练集 |
| 退回修改 | 漏标问题类型，或改写内容有瑕疵但可补救；工具参数轻微错误 | 退回标注员，备注修改意见，24 小时内重新提交 |
| 质检直接丢弃 | 安全类漏标；改写引入新错误；工具选择/参数严重错误；编造工具结果 | 质检员直接丢弃，计入标注员错误统计 |
| 升级仲裁 | 标注员与质检员意见严重分歧，涉及工具边界或复杂安全判断 | PM 或数据负责人介入，裁定结果同步更新规则文档 |
| 分数区间 | 等级 | 说明 |
|---|---|---|
| 95～100 | A 优秀 | 直接通过，可作为正样本模板 |
| 85～94 | B 合格 | 通过，进入训练集 |
| 70～84 | C 待修订 | 退回修订后复检 |
| 0～69 | D 不合格 | 驳回，不进入训练集 |
8.4 标注员提交前自检清单
每条提交前请对照以下清单逐项确认，平台提供勾选框，全部勾选后方可提交。
| 序号 | 检查项 | 检查方式 |
|---|---|---|
| □ 1 | 已阅读场景功能介绍与工具定义 | 确认理解角色边界与可用工具 |
| □ 2 | 思考对/行动对标注正确，错误原因填写完整 | 错误原因能让他人看懂 |
| □ 3 | 工具选择、参数、顺序符合工具 schema | 对照工具定义逐项核查 |
| □ 4 | 改写内容符合上下文与场景设定 | 无臆造、无越权 |
| □ 5 | 【安全合规】无高风险动作放行、无编造结果 | 重新扫描全文 |
| □ 6 | Session 内轮次 ID 连贯，无跳号或重复 | 逐行确认轮次 id |
| □ 7 | 若修改了 Action 部分，已进行 JSON 合法性校验 | 平台格式自动校验 |
| □ 8 | 所有必填字段已填写（思考对、行动对、错误原因、改写后、是否已改写） | 平台必填校验 |
8.5 致命错误项
直接判 D 的情况
- 明显误判用户主目标
- 该澄清未澄清，直接执行高风险动作
- 使用了工具定义中不存在的工具
- 关键参数缺失仍直接调用工具
- 工具结果与最终输出明显冲突
安全与一致性红线
- 编造文件内容、搜索结果或执行结果
- 多轮上下文严重不一致
- 放过明显高风险/越权样本
- 漏标高风险标签
- 字段大面积空缺或明显敷衍
8.6 个人质量监控与一致性校准
📊 质量指标阈值
- 标注员错误率（质检驳回率）目标：≤ 5%
- 连续 3 天错误率 ≥ 10% → PM 约谈
- 单月错误率 ≥ 15% → 重新培训或调岗
- 安全类漏标一次 → 立即约谈
- 改写引入新错误（如臆造工具结果）→ 计 2 倍错误权重
🔄 一致性校准机制
- 黄金数据集比对（每周）：每人标注同一批 50 条，计算 Kappa ≥ 0.70，低于则追加培训
- 每日 Case Review：组长选取 3 条前日有争议案例集体讨论
- 规则迭代会议（每两周）：PM + 质检组长，裁定边界案例并更新本文档版本
- 个人准确率周报：质检员每周汇总每人通过率和主要差错类型并反馈
奖励机制：连续 2 周个人错误率 ≤ 2% 且日均产能达标的标注员，将获得优质标注员认证，优先参与后续项目，并有机会晋升为质检员。
规则争议处理：遇到规则文档未覆盖的情形，禁止自行判断后直接提交。正确流程：在项目沟通群 @组长/PM 并描述疑问 → PM 24 小时内给出官方解释 → 若涉及规则修订，同步更新本文档并全员通知。
通用大模型 Agent 项目 · 标注规则文档 v1.0 · 内部使用，请勿外传
最后更新：2026-03-19 · 如有疑问请联系项目 PM 或数据规则负责人
最后更新：2026-03-19 · 如有疑问请联系项目 PM 或数据规则负责人