面向 Agent 的训练集与测试集构造：编码场景与安全场景

如果目标是训练面向编码的 Agent，训练集和测试集的核心都不应只围绕“代码补全”本身，而应围绕 任务闭环能力 来构造：理解任务、检索上下文、规划步骤、修改代码、运行工具、读取错误、继续迭代，直到产出可验证结果。因此，数据样本的基本单位最好不是单条 prompt，而是一次完整任务轨迹（task episode）。

一、面向编码 Agent：训练集怎么构造

训练集建议按“任务单元”组织，每个样本至少包含以下几层信息：

任务描述：来自真实开发场景，例如修复 bug、增加 feature、补测试、改 CI、重构某个模块。
代码仓上下文：仓库快照、相关文件、依赖、README、测试框架、构建脚本。
允许使用的工具：如搜索、读文件、编辑、运行测试、查看日志。
过程轨迹：高质量示范轨迹，而不只是最终 diff。轨迹里应显式呈现“先看什么、为什么改、改完跑什么、失败后怎么修正”。
结果标签：最终代码 diff、命令执行结果、测试结果、是否完成任务、质量评分。

训练集来源通常可混合几类：

真实工程任务回放：从 issue、PR、commit、review 讨论中恢复任务闭环。
专家示范数据：由高水平工程师或强模型完成任务，保留完整工具调用轨迹。
自动合成任务：基于仓库自动注入 bug、删除测试、制造类型错误，再要求 Agent 修复。
对抗式难例：包含误导性日志、多个相似文件、跨模块依赖、 flaky 测试、隐式约束。

编码 Agent 的训练集不要只追求样本量，更关键的是覆盖任务分布。至少要覆盖：单文件修改、多文件联动、跨层调用链、带测试修复、无测试场景、依赖升级、配置错误、性能退化、兼容性问题、长上下文检索等。否则模型很容易在 benchmark 上表现好，但在真实仓库里崩在“找不到地方改”或“改了一处没补齐相关面”。

二、面向编码 Agent：测试集怎么构造

测试集的目标不是测“会不会写某段代码”，而是测 在受限工具和真实仓库约束下，能否稳定完成任务。因此测试集设计通常要满足四个原则：

与训练集严格隔离：不仅任务文本不能重合，仓库、commit、bug 模式、评测脚本也要尽量去重，避免数据泄漏。
可自动验证：优先选择可以用单元测试、集成测试、编译、lint、静态分析、安全扫描来自动判断成败的任务。
保留真实噪声：任务描述不应全部是理想化 specification，应该允许信息不全、日志冗长、上下文分散。
按难度分层：短路径任务、长链路任务、跨文件任务、需要多轮调试任务分别建桶。

一个好的编码 Agent 测试样本通常包括：

初始仓库快照
用户任务描述
可用工具集合与资源限制
隐藏评测脚本
成功标准（如测试全绿、某功能行为满足断言、diff 触达指定区域但不破坏别处）

除了 pass/fail，还建议记录更细指标：

任务完成率
首次成功率
平均工具调用步数
token/时间成本
无关修改率
回归引入率
长任务中途放弃率

也就是说，编码 Agent 的测试集本质上更接近 interactive software engineering benchmark，而不是传统静态代码生成 benchmark。

三、面向安全 Agent：有什么差异

有，而且差异很大。安全 Agent 不是简单地在编码 Agent 数据集上多加一些 CWE 标签，而是任务定义、样本来源、验证方式、风险控制都要重新设计。

1. 任务对象不同

编码 Agent 更关注“把功能做对”；安全 Agent 更关注：

找到漏洞
解释 exploitability
判断真实风险与可达性
给出最小且正确的修复
验证修复没有引入绕过或功能破坏

因此安全 Agent 的任务单元通常不是“实现需求”，而是：

漏洞发现（find)
漏洞确认（triage)
漏洞利用链分析（reason about reachability / impact)
补丁生成（patch)
补丁回归验证（verify)
大规模审计（audit)

2. 训练集来源不同

安全训练集更适合来自以下来源：

历史 CVE 与修复 commit 对
bug bounty 报告及其修复
静态分析/模糊测试触发的真实样本
人工注入漏洞的数据集（SQLi、XSS、SSRF、反序列化、命令注入、权限绕过、竞态等）
攻防题或安全实验仓库，但要注意与真实工程分布差异很大

这里有一个关键点：安全数据尤其需要 negative samples。也就是很多看起来像漏洞、其实不可达或影响极低的样本。如果没有这类数据，Agent 很容易变成“高召回低精度的误报机器”。

3. 标注目标不同

编码场景常见标签是“任务是否完成、代码是否通过测试”；但安全场景需要更细：

漏洞类型（CWE）
source / sink / sanitizer 路径
可达性条件
权限边界
利用前提
影响面
修复是否完整
是否存在变体绕过

换言之，安全 Agent 训练不能只学“哪里危险”，还要学“为什么成立”“在什么条件下成立”“怎样修才不被绕过”。

4. 测试集验证方式不同

安全 Agent 的评测比编码 Agent 更难，因为“测试通过”并不代表“漏洞已修复”。测试集往往需要组合多种验证：

PoC 触发前后对比：修复前 exploit 成功，修复后失败。
变体测试：同类 payload、编码绕过、大小写/路径/协议变体是否还能打通。
回归测试：修复后原有业务功能不能被破坏。
静态 + 动态联合评测：是否只是压住表面告警，而没有真正消除风险路径。
误报率评测：给定大量可疑点，是否能正确 triage，而不是把一切都报成高危。

5. 风险控制要求更高

安全 Agent 的训练与测试环境需要额外控制：

隔离运行环境，避免真实攻击外发
对 exploit/weaponized payload 做分级管理
对外网访问、凭证、系统调用权限做限制
将“发现漏洞”和“生成可直接滥用的攻击脚本”分开评估

这不是学术形式主义，而是因为安全 Agent 的能力如果直接按编码 Agent 方式开放，很容易跨过“防御分析”与“攻击助推”之间的边界。

四、一个实用的构造框架

如果要在工程上快速落地，可以采用两套但共享底座的数据体系：

编码 Agent 数据单元

输入：任务描述 + 仓库快照 + 工具权限
轨迹：检索、编辑、执行、调试、多轮修正
标签：最终 patch、测试结果、过程质量分
评测：任务完成率、成本、稳定性、回归率

安全 Agent 数据单元

输入：告警/审计目标 + 仓库快照 + 工具权限
轨迹：定位 source/sink、分析 reachability、验证 exploitability、生成补丁、复测
标签：漏洞是否真实、CWE、影响级别、修复完整性、误报/漏报
评测：检出率、误报率、修复成功率、绕过抵抗、业务回归

两者共同的底座是：都应以真实仓库、真实工具、真实闭环为单位来组织数据；最大的差异是安全场景需要更强的“判真伪、证风险、验修复、防滥用”能力，因此测试集设计显著更重 verification 和 risk control。

五、结论

一句话总结：

编码 Agent 的训练/测试集，应围绕“在真实工程环境中完成开发任务的闭环能力”来构造。
安全 Agent 在此基础上，还必须额外建模“漏洞真实性、可达性、利用条件、补丁完整性、误报/漏报与风险控制”。

所以答案不是“安全 Agent 和编码 Agent 差不多，只是任务换成安全题”，而是：底层框架相似，但安全场景对数据标注、验证机制、负样本设计和运行隔离都有更高要求。