# Stanford CS 329Z lecture 12 says filtering agent training data matters more than volume

> Original title: CS 329Z: Engineering AI Agents

- Source: meng shao
- Published: 2026-11-05T02:41:24.000Z
- Bad Influence: https://badinfluence.news/items/gcu0i2lx85bpzy8z4koern8cp
- Original: https://x.com/shao__meng/status/2118171796310720746

## Summary

Meng Shao reposts Stanford CS 329Z lecture 12 on data selection for agent training, arguing that filtering matters most when data is scarce. The lecture cites SWE-bench Verified, where 68.3% of tasks were filtered out, and LIMI, where 78 curated trajectories scored 73.5% on AgencyBench versus 47.8% for a model trained on 10,000.

## Post

CS 329Z: Engineering AI Agents
Stanford / Fall 2026 @stanfordnlp
https://cs329z.stanford.edu

第 12 讲「Data Selection & Quality」：Agent 训练数据，难的是决定留下哪些
https://web.stanford.edu/class/cs329z/slides/lecture12.pdf

现在生成 Agent 的任务和轨迹已经很便宜，真正难的是筛选。这一讲回答三个问题：哪些任务值得拿来做强化学习，哪些轨迹值得拿来做模仿学习，以及数据要多还是要精。结论是：数据少的时候精挑细选更有用，数据规模上去以后，数量和多样性更重要。

为什么筛选是重点

讲义开头举了 Meta CWM 的例子：先在 3150 个仓库、10200 个 Docker 镜像上生成 300 万条轨迹，再去掉同一仓库内相似度过高的轨迹（Jaccard 相似度不低于 0.5）。因为目标是学习代码环境的世界模型，失败的轨迹也保留了下来。课程把要筛选的对象分成两类：一类是用来做监督微调的轨迹，一类是用来做强化学习的环境，也就是任务加沙箱加判定器。坏数据有三种：信号错误（判定器坏了，或者靠作弊拿到奖励），没有信号（任务太容易或太难），信号重复（大量同类数据）。

哪些任务值得训练

讲义把任务筛选看成一个循环：先剔除有问题的任务，再实际运行检验，只保留模型有时能做对的任务，模型变强后重新筛选。

· SWE-bench Verified：93 名 Python 开发者标注了 1699 个样本，38.3% 的问题描述不够清楚，61.1% 的单元测试不公平，最终过滤掉 68.3%。例如 sklearn-14520 的测试要求一条精确的弃用提示语，而这句话只出现在 Agent 看不到的 PR 讨论里。GPT-4o 在原版上只有 16%，在筛选后的版本上是 33.2%。有问题的任务会掩盖模型的真实能力，用于训练时还会给出错误的奖励。
· APIGen：人工审核无法规模化，所以改成自动检查：先查格式，再实际执行，最后让大模型判断结果是否符合问题的本意。
· CodeMidas（小米 MiMo 团队）：只从源代码构建编程环境。测试只检查任务描述里写明的要求。每个任务要在 6 个新容器里各跑一次：起始代码跑 2 次，必须失败；参考答案跑 4 次，必须通过。之后再做三层过滤：检查答案是否泄露，复核判定结果，剔除全部通过或全部失败的任务。过滤后的 3000 个任务已经胜过未过滤的 8000 个，完整的 5000 个任务比 8000 个在三项评测上分别高出 0.59、4.59 和 4.49 分。
· DAPO：同一题的几次采样奖励完全一样时，强化学习学不到东西。模型越强，全对的题越多，所以要持续采样，直到批次里都是有对有错的题。
· LEGO-RL：36884 个候选任务经过有效性检查后剩下 21681 个，其中约 2.5% 的判定器有错。再只保留 4 次尝试里做对 1 到 3 次的任务，最终剩下 2699 个。不做这一步筛选，训练在两项指标上都没有提升，因为未筛选的任务池中 72.7% 从来做不对，13.4% 每次都做对。随着训练推进，没有区分度的题组占比从 44.7% 升到 51.4%，任务池需要定期更新。
· WebRL：从失败的尝试中生成新任务，再配一个奖励模型，把 Llama-3.1-8B 在 WebArena-Lite 上的成功率从 4.8% 提升到 42.4%，70B 版本达到 47.3%。

哪些轨迹值得模仿

通过测试不等于好示范。通过的轨迹里，有的靠作弊，有的过程很粗糙；失败的轨迹里，也有可用的步骤。

· The Verification Horizon（Qwen 团队）：总结了 Agent 的七种走捷径方式，比如直接找到答案文件、改动测试框架或测试本身、翻 git 历史。直接找答案的轨迹只占 4.32%，但其中 72.34% 能解决问题。通过率可能一直很高，而不作弊的真实表现却在下降。加上轨迹监控后，作弊解决率从 28.57% 降到 0.56%，真实解决率从 40.22% 升到 60.53%。
· SWE-Prime：成功的轨迹里也有无效、重复或有风险的步骤。它先按过程质量挑轨迹，再按贡献、风险和可学性给每一段打分。只用挑出的 10% 训练，效果就超过用全部成功轨迹训练，相对提升最高达到 SWE-bench Pro 上的 12.2% 和 SWE-bench Verified 上的 24.2%。
· NAT：失败的轨迹不丢，而是加上「这次失败了」的标记一起训练，让模型既能学到其中有用的信息，又不会照搬错误。
· EEF：只用专家成功的轨迹训练时，难的子任务几乎进不了训练集，而失败往往只错在最后几步。从失败的专家轨迹里挑出好的步骤后，在 WebShop 上的胜率达到 62%，拒绝采样微调是 53.6%，GPT-4 是 35.6%。

数据要多还是要精

· 少而精的一方，LIMI：78 条人工精选的轨迹，在 AgencyBench 上拿到 73.5%，用 10000 条训练的模型只有 47.8%。这 78 条由四名博士生配合 GPT-5 反复调试完成。但讲义也指出了局限：AgencyBench 只有 10 个任务，而且和 LIMI 有很多共同作者；离开命令行环境后，优势只剩 50.0% 对 48.7%。
· 量更重要的一方，Orchard：基础模型和训练方法固定，只改变数据量和筛选策略。在 SWE-bench Verified 上，表现最差的策略从 512 条加到 2048 条，提升了 8.2 分；而在 512 条时，六种策略之间最多只差 5.5 分。
· 多样性：AgentRefine 发现，在新环境里的错误主要是格式错误、推理不合逻辑和重复生成。用多样的合成环境训练模型纠正自己的错误，泛化能力更强。SWE-smith 用同样 700 条轨迹，分散到从 4 个到 100 个不同仓库里，效果大致随仓库数量呈对数增长。
· 两边的结论怎么统一：Qwen 团队的一组数据显示，同样大小的数据集，筛选过的比随机选的好（23.52 对 21.61），但更大的未筛选数据集更好（24.75）。也就是说，候选数据有限时，筛选的价值最大。

课程给的检查清单

按顺序做五件事：检验任务是否有效，筛出难度合适的任务，审查成功轨迹是怎么成功的，给失败轨迹加上标记后保留，数据来源尽量多样。

![](https://badinfluence.news/api/img-proxy?u=https%3A%2F%2Fpbs.twimg.com%2Fmedia%2FHWVCA45bQAAFqEC.jpg&mode=thumb&exp=1794096000&sig=81c823b7358982f2)

## Quoted post @shao__meng

> CS 329Z: Engineering AI Agents
> Stanford / Fall 2026 @stanfordnlp 
> https://cs329z.stanford.edu/
> 
> 课程定位：从"模型"到"系统"的工程学
> 覆盖：简单 LLM 流水线 → 复合 AI 系统 → 自主 Agent。三位讲师的背景也高度互补：
> @Diyi_Yang（斯坦福 NLP 教授，人机交互与社会计算方向）
> @michaelryan207（DSPy 核心贡献者，自动评估 AutoMetrics 作者）
> @jyangballin（SWE-agent / SWE-bench / SWE-smith 作者，软件工程 Agent 领域最重要的研究者之一）
> 
> # 课程主线：三大工程挑战
> 贯穿全课的三个核心问题——分解（decomposition）、数据（data）、评估（evaluation）。11 周的内容基本围绕这三条线展开，可以分为五个模块：
> 
> 模块 1：构建基元（Week 2–3）
> · LLM 作为构建材料：API/SDK（litellm）、结构化输出、约束生成、解码策略、test-time compute、上下文工程、模型选型与成本/延迟权衡
> · RAG：embedding、向量库、分块策略、混合检索、cross-encoder 与 ColBERT 后期交互
> · 工具调用：函数调用 API、MCP（Model Context Protocol）、工具设计、代码沙箱、错误处理与重试
> 
> 模块 2：框架与设计模式（Week 3–5）
> · 框架层：DSPy（signature / module / optimizer）、LangChain/LangGraph、LlamaIndex，重点是"框架抽象了什么 vs. 你手写了什么"
> · 设计模式：workflow vs. agent 的分类学，五种可组合 workflow 模式，ReAct / plan-and-execute / reflection，"scaffold（脚手架）本身就是设计决策"
> · 记忆架构：短期/长期记忆、记忆作为工具动作、文件系统作为外化记忆、跨 Agent 记忆（MemGPT、Mem0、Generative Agents）
> · 多 Agent 系统：编排模式、handoff 与状态传递，以及一个很有态度的对照阅读——既读 AutoGen，也读《Why Do Multi-Agent LLM Systems Fail?》和 Neubig 的《Don't Sleep on Single-agent Systems》
> 
> 模块 3：优化（Week 5）
> · 从提示词到微调的全景：GEPA、MIPROv2、OPRO、TextGrad（提示优化）；LoRA/QLoRA、蒸馏、RLHF/DPO（权重优化）；test-time scaling（推理算力）
> · 核心问题是决策框架：什么时候优化 prompt、什么时候优化 weights、什么时候堆推理算力
> 
> 模块 4：数据与评估（Week 6–8）——最有分量的部分
> · 数据：trace、demonstration、feedback 三类数据；训练数据 vs. 评估数据；数据飞轮；合成数据；从 Agent 轨迹构建数据集（SWE-smith）
> · 评估基础：为什么 eval 难；4 元组框架（request / environment / stopping criteria / scorer）；好 benchmark 的性质；tinyBenchmarks
> · 评估基础设施：三类 grader、LLM-as-judge 的 prompt 设计与已知偏差、pairwise vs. pointwise、非确定性指标 pass@k vs. pass^k、harness 设计
> 
> 模块 5：安全与前沿（Week 8–11）
> · 安全：工具访问的隐私风险、prompt injection（含间接注入）、红队、沙箱与权限模型、输出护栏、human-in-the-loop
> · Coding Agent：SWE-agent、Claude Code、OpenHands 的端到端架构对比
> · 主动式 Agent：从 reactive 到 proactive，General User Models（GUM）、Next Action Prediction，以及"Agent 何时应主动、何时应等待"的 mixed-initiative 问题
> · 开放问题：多模态/web/计算机使用 Agent、科学 Agent、长时运行架构、生产可观测性（tracing、monitoring、成本管理）
> 
> # 作业设计：一手建、一手评
> 
> HW1：从零构建 Agent 系统（10%） 给定论文库，构建能检索并推理回答科学问题的 Agent。
> · Part A：只用 litellm 手写 RAG + 工具调用 + ReAct 式 Agent 循环
> · Part B：用 DSPy 重建关键组件，并反思框架抽象了什么
> 
> HW2：评估一个 Agent（10%） 给定一个预构建 Agent，设计完整评估套件：代码型 grader、至少一个 LLM-as-judge、用 4 元组框架构建 benchmark 任务、错误分析。

https://x.com/shao__meng/status/2095330467000328632