Hugging Face Daily Papers 8 月 28 日把 What Makes Good Agentic Data? An ACE Lens on Data Generation for LLM Agents 放在前列。arXiv 页面显示这篇论文 2026 年 8 月 27 日提交，作者把 agentic data 表示为环境、任务信号、交互实现和可选验证器组成的经验对象，并用 Accuracy、Complexity、divErsity 三个维度讨论数据生成。参考来源：arXiv 论文页、Hugging Face 论文页、Reddit r/MachineLearning。
这篇论文的价值不只在学术分类。它描述的其实是 agent 工程正在发生的迁移：过去我们把数据当训练模型前的一次性资产，现在 agent 系统需要把数据当持续供应链。每一次工具调用、每一次失败恢复、每一次人工接管、每一个环境变化，都可能成为未来训练、评测、技能更新和路由策略的输入。
如果说 2024 到 2025 年的应用型 AI 关键词是 RAG、工具调用和评测，那么 2026 年 agent 团队真正要补的是数据工程。没有 agentic data 供应链，长任务 agent 的改进会停留在手工调 prompt、换模型和看 demo 的循环里。
为什么普通数据思维不够
传统语言模型数据常被简化成输入输出对。给一个问题，给一个理想答案，模型学会从前者映射到后者。这对摘要、翻译、分类、单轮问答很有用，但对 agent 不够。
Agent 的行为质量藏在中间过程里。它是否先读 README，是否检查测试，是否在工具失败后重试，是否区分权限错误和业务错误，是否在信息不足时停止，是否把临时文件清理掉，这些都不会自然出现在最终答案里。
因此 agentic data 必须包含环境和轨迹。环境定义可见文件、API、浏览器、数据库、权限和状态；任务定义目标和成功标准；轨迹记录动作与观察；验证器判断是否成功。缺少任意一环，数据就很难被复用。
例如一个“修复构建失败”的样本，如果只保存用户请求和最终 patch，它对训练 agent 的帮助有限。更有价值的数据应该包括：初始 pnpm run check 的错误、agent 查看了哪些文件、做了哪处修改、再次运行检查是否通过、有没有引入无关 diff。这样模型或技能才能学到过程，而不是只学最终答案的表面形态。
ACE 的顺序
论文提出的 ACE 可以被工程化理解成一个筛选漏斗。
第一是 Accuracy，准确性。这里的准确不是语言答案像不像，而是环境、任务、交互和成功信号是否一致。一个轨迹如果声称测试通过，但日志里根本没有测试命令；或者任务要求只读数据，但轨迹里写入了生产系统；这样的数据即使看起来完整，也不应该进入训练集。
第二是 Complexity，复杂度。复杂度不是越难越好，而是要相对于学习者能力分配。对一个刚会工具调用的小模型，直接喂跨仓库重构、多代理协作和长上下文恢复，可能只会学到混乱。对强模型，过多简单任务又会浪费训练预算。
第三是 divErsity，多样性。多样性不是换几个变量名或改写任务描述，而是覆盖不同环境、失败模式、工具组合、权限条件和验证路径。真正有价值的多样性应该改变 agent 的决策，而不是只改变文本外观。
这个顺序很重要。很多团队一上来就追求多样性，合成大量任务变体，但没有先证明这些轨迹可执行、可验证、适合当前模型。结果是数据规模变大，系统却更不稳定。
Agentic Data 供应链的五个环节
成熟的 agent 团队需要把数据链路拆成五段。
第一，采集。采集真实任务轨迹，包括成功、失败和人工接管。失败轨迹尤其重要，因为它暴露了工具边界、权限边界和模型误判。
第二，规范化。把不同工具、不同 agent 主机、不同日志格式统一成结构化事件。至少要有任务 ID、环境版本、动作、观察、错误、耗时、成本和验证结果。
第三，验证。用自动测试、规则检查、LLM judge 和人工抽检组合验证轨迹。对高风险任务，自动验证只能作为初筛。
第四，分层。把数据分成评测集、训练集、技能更新候选集、回归失败集。不要把所有轨迹混成一个大 JSONL。
第五，发布。像发布代码一样发布数据版本：记录来源、过滤规则、采样策略、已知偏差和适用模型。模型训练、技能进化和 prompt 优化都应该引用明确数据版本。
这一套听起来重，但不做会更贵。长任务 agent 的问题不是一次失败，而是同类失败反复出现却无法被系统吸收。
合成数据应该怎么用
合成 agentic data 很诱人，因为真实轨迹慢、贵、脏。论文也承认生成数据在 agent 训练中越来越重要。但合成不应该替代验证。
比较稳的做法是从真实任务出发做局部扩展。比如真实轨迹是“修复 TypeScript 类型错误”，可以合成相邻任务：错误文件不同、依赖版本不同、测试命令不同、权限限制不同。每个合成任务都必须能在环境里执行，并由验证器确认。
不稳的做法是让模型批量生成一万条“agent 编程任务”，再让另一个模型写答案。这样的数据可能语言多样，但环境不真实、成功信号虚假、错误恢复缺失。它适合做 demo，不适合做训练供应链。
合成数据还要记录生成策略。用了哪个 teacher model、什么 prompt、采样温度、过滤规则、通过率是多少，这些都应该进入数据卡。否则几周后你只会知道“这批数据效果不好”，却不知道为什么。
和本地模型趋势的关系
Reddit r/LocalLLaMA 最近关于本地模型的讨论里，一个反复出现的主题是：同样参数规模下，长上下文、量化、推理速度和 agentic coding 表现差异很大。很多用户不再只问 benchmark，而是问“这套配置能不能连续跑 70K 上下文、能不能完成真实项目、能不能在 16GB VRAM 里保持可用速度”。
这说明 agentic data 不只是云端大模型团队的问题。本地模型社区同样需要可复现的任务轨迹和配置记录。没有统一任务和验证器，所谓“某模型更适合 agent”就很容易变成主观体验。
一个小团队可以把本地模型评测做成 agentic data：记录模型、量化格式、上下文长度、KV 设置、任务轨迹、成功标准和人工干预次数。这样当新模型发布时，你能比较它在自己任务上的真实收益，而不是只看排行榜。
组织层面的变化
Agentic data 会改变团队分工。过去数据工程更多服务于训练前处理；现在它要进入产品运行时、评测平台、安全审计和成本治理。
产品工程师需要埋点任务和工具事件。平台工程师需要维护沙箱和日志 schema。安全团队需要标注越权、泄露和提示注入样本。领域专家需要审核高价值轨迹。模型团队需要把这些数据转成训练、评测或技能更新材料。
这就是为什么我把它称为供应链。它不是某个 researcher 在 notebook 里整理的一份数据集，而是跨系统、跨角色、跨版本流动的生产资料。
结论
Agent 工程下一阶段的核心问题不是“能不能让模型调用工具”，而是“能不能让系统从每次工具调用中学习”。ACE 框架给了一个清晰起点：先保证数据准确可验证，再让复杂度匹配学习者，最后扩展真正影响行为的多样性。
谁能把 agentic data 供应链做扎实，谁就能更快迭代模型选择、技能库、prompt 优化和运行时策略。反过来，只靠换更强模型和堆更多轨迹，短期可能有效，长期会被不可解释的失败、成本和维护债拖住。