北大研究：Agent工具越多越弱？通过率从91.7%跌至83.3%

说真的，最近一周我被一篇论文反复刷屏。每次刷到评论区都有人在吵同一个问题。

一边是，「MCP 不就是 AI 工具的 USB-C 吗，Code Agent 接上去不就完事了」。另一边是，「MCP 接上去之后，Agent 还是瞎搞啊，调用不存在的算子、流程顺序全错」。

两边吵得不可开交，但其实谁都没说到点子上。

真正的答案是，工具给够了不够，还得给一份「使用说明书」。这个使用说明书，在工程里叫 Skills。

最近北大 DCAI 团队联合上海算法创新研究院、北京中关村学院发的 DataFlow-Harness 论文（arXiv 2607.16617）就专门研究这件事。他们把 AI 准备训练数据的整个流程跑了一遍实验，得出的核心数字是这样的，给 Agent 完整的 MCP 工具，通过率从 91.7% 降到 83.3%。补上 Skills 之后，通过率回升到 93.3%，成本还下降了 72.5%。

今天这篇文章，我就按自己的理解，把这个实验拆给你看。

我第一次看到这个数字的时候，第一反应是看错。

逻辑上，MCP（Model Context Protocol）不就是给 Agent 提供工具的标准协议吗。给得越全，Agent 能做的事越多，通过率应该越高才对。

但实验结果恰恰相反。

对照组是「自由脚本」模式，工程师写一段一次性 Python 脚本直接跑，通过率 91.7%。这个模式其实有点粗糙，但它依赖的是模型在训练阶段见过的大量代码模式，写出来的东西大概率能跑。

然后是「MCP-only」模式，给 Agent 完整的 MCP Tools Layer（Agent 能查到平台里有哪些算子、每个算子的参数和 Schema、能读取 pipeline 状态、能提交结构化修改），通过率反而掉到 83.3%。

少了 8.4 个百分点。

这组下降把论文里提出的概念直接量化出来了，NL2Pipeline gap。用户说的是自然语言里的工作流意图，生产环境真正需要的，却是一条可检查、可编辑、可复用的平台原生流水线。

进入平台约束后，Agent 不再是单纯写代码，它要同时理解算子依赖、字段流转、Schema 兼容和质量检查顺序。任务没变简单，只是错误从「代码写错」变成了「流程编排错」。

更细的实验数据是这样的，论文把 12 个数据工程任务按复杂度拆开。

程序性知识密集任务（QA 生成、QA with filter、Text-to-QA chain），MCP-only 合计通过 18/30 次，DataFlow-Harness 是 29/30。MCP-only 生成的 DAG 在结构上通常合法，问题出在业务顺序上。比如它不知道 PDF 解析后要先做 layout recovery，再做 QA matching。也不知道 nested field flatten 之前不能直接做 semantic filter。

自明性路由任务（字段重命名、Nested flatten、长度过滤、LLM semantic filter），两种方法都是 40/40 通过。这类任务的路径几乎唯一，算子说明本身已经足够。

非合成瓶颈任务（多字段评分类），两种方法失败率相同。失败原因来自数值约束，而不是 DAG 结构，流程知识在这里帮不上忙。

所以，Skills 的价值边界其实很清楚。它不会凭空让 Agent「更聪明」，而是把工程师长期积累的程序性知识编码进去，某类任务应该选哪些算子、顺序怎么排、字段怎么接、哪一道检查不能跳过。

Operator registry 回答的是「平台里有什么」，Skills 回答的是「怎样把这些东西连成一条真正可用的流水线」。

二、四组件架构，一步步缩小 Agent 的犯错空间

DataFlow-Harness 不是单点优化，是围绕四个核心组件搭的约束系统。越往后，Agent 可以自由发挥的地方越少。

第一层，Data Pipeline Backend。单一真相源，一条 pipeline 被形式化为五元组 P = (D, O, E, S, R)。所有修改只认这一个状态，不管 Agent 怎么改、工程师怎么改，画布怎么改，最后都回到这个五元组上。

第二层，Operator Registry。算子注册表。Agent 能看到的所有算子都在这里，每个算子有明确的参数、Schema、依赖关系。Agent 不能调用注册表里不存在的算子，这一条是硬约束。

第三层，Typed Mutations。结构化变更。Agent 提交的不是「一段修改后的代码」，是一个类型化的 mutation 对象。Schema 不兼容的连接在提交前就会失败，根本进不到执行环节。

第四层，Skills。程序性知识。告诉 Agent，这些算子应该按什么顺序连接，哪些步骤不能交换，哪些检查不能省略。Skills 的设计跟 Anthropic 在 2025 年 12 月发布的 Agent Skills 开放标准是兼容的。

这四层叠加之后，效果是这样的，Agent 能发挥的余地被压缩在「平台已有算子 + 已知程序性知识」的交集里。听起来是束缚，其实是保护。

我自己的体感是，这种架构跟传统软件工程里的「强类型 + 设计模式 + 代码规范」是同一套思路的延伸。不是说 Agent 笨所以要约束，是说任何复杂系统都需要约束才能稳定。

三、从 Textbook-to-VQA 看下游训练的真实差距

只证明 Agent 能生成一条合法 DAG，还不够说明这套方法真有用。论文还设计了 Textbook-to-VQA 场景，以及两个下游训练案例。它们想回答的是另一个问题，流水线搭得更稳，最终训练出来的数据和模型会不会也更好。

Textbook-to-VQA 的故事。这是一个从教材、解答手册、考试答案页里抽取视觉问答数据的任务。不是「读一个 PDF 再调一次模型」就能完成的，需要 PDF 解析、版面结构恢复、OCR、图表抽取、多模态理解、跨页面问题答案对齐。任何一个环节漏掉，后面数据看起来完整，实际上已经错位。

实验中，DataFlow-Harness 的 Precision 达到 0.972，Coverage Rate 达到 0.873，均高于 Vanilla CC（0.621 / 0.533）、Context-Aware CC（0.893 / 0.801）和 MCP-only（0.784 / 0.621）。

这里最该拎出来说的是 Harness 与 Context-Aware CC 的对比。Context-Aware CC 拥有完整上下文注入，可以输出任意合法 Python 代码，自由度比 Harness 更高。但到了多算子协同的复杂流程里，自由度反而扩大了搜索空间。

Harness 的做法更克制。它把 Agent 的选择空间压缩到 DataFlow 已有算子体系内，再用 typed mutations 和 Skills 约束组合方式。Harness 的优势来自成熟平台资产的系统性复用，而不是模型推理能力突然变强。（顺带一提，延迟也从 190.7s 降到 95.5s，下降 49.9%）

数学推理场景的对照实验。Agent 要搭建一条完整的数据清洗和合成流水线（题目验证、低质样本过滤、问题扩展、推理链生成、n-gram 去重）。生成的数据用于微调 Qwen2.5-32B-Instruct，训练 2 epochs 后，Harness 数据的平均分为 55.7，Vanilla CC 数据为 54.5。

差距最明显的是对数据污染更敏感的 benchmark，AIME24@32 训练 1 epoch 时从 25.1 提升到 35.9，AIME25@32 从 21.6 提升到 34.5。这类 benchmark 很容易受到「表面正确、推理链却有问题」的样本影响。Harness 管道把验证、过滤和去重固定成流水线步骤，减少了 Agent 漏做某一道质量检查的机会。

通用 SFT 的对照实验。Agent 从零构建通用指令数据合成流程，主题条件生成、critique-then-rewrite、LLM-as-judge 评分过滤。最终产出 10K 条 instruction-response 数据，用于微调 Qwen2.5-7B-Base。9 个 benchmark 的总体平均分从 61.5 提升到 63.8。

提升较明显的两个代码 benchmark，HumanEval 78.0 → 80.5，MBPP 64.6 → 75.4。代码任务对训练数据中的逻辑瑕疵尤其敏感。一条结构完整但关键步骤有错的指令数据，可能比普通知识问答里的噪声更难被模型「忽略」。

Harness 把 critique、rewrite、judge 等环节组织成固定流程后，每一步都必须被执行，也更容易检查中间结果。它减少的不是所有错误，而是「某一步被 Agent 顺手跳过了」这种很难追踪的错误。

需要说一句的是，论文把这两个下游实验明确标注为 controlled case studies，只提供初步证据，不构成因果估计。两个实验都没有进行多次独立重复，也没有统计检验。边界需要保留，但方向同样值得注意。

四、底座和接口，两层都重要

DataFlow-Harness 的应用价值来自两层能力叠加。

第一层是 DataFlow 本身。这是北京大学 DCAI 团队 2024 年 10 月就开源的 AI 数据准备底座（OpenDCAI/DataFlow 仓库，目前 7178 颗星，Apache 2.0 协议）。它围绕数据生成、清洗、过滤、评估、去重、流水线编排，形成了一套面向 AI 数据准备的工具体系。

具体能力上，DataFlow 提供 100+ 算子，覆盖文本合成、数学推理、代码生成、PDF 转 QA、Agentic RAG、Text2SQL 等场景。提供类似 PyTorch 的 Pipeline → Operator → Prompt 编程层级。基于 Ray 做分布式编排调度。ICML SeePhy 比赛冠军和智源 LIC 挑战赛冠军，也为这套底座提供了独立于论文之外的竞赛验证。

第二层是 Harness 化封装。DataFlow-Harness（实际工程仓库是 OpenDCAI/DataFlow-WebUI，150 颗星）通过 MCP 把 DataFlow 的算子、Schema、流水线状态和运行能力暴露给 Code Agent。过去需要人工查文档、写配置、连节点、调脚本的流程，现在可以通过对话完成。

但它没有让 Agent 绕开平台。对话最后生成的，仍然是与人工在 WebUI 中搭建相同类型的 Native DAG，可持久化、可编辑，也可以继续被团队审计和维护。

这两层不是并列关系，而是底座和接口。Harness 没有重新发明一套算子，也没有把算子设计权交给 Agent。它做的是在成熟算子体系上增加一层安全、可审计的 Agent 调用方式。

这个选择看起来不够「万能」，却更接近真实工程，算子能力由平台长期维护，Agent 负责理解意图和完成组合。边界清楚，出了问题也更容易定位。

五、我的理解，Harness 不是更聪明的 Agent，是更稳的工程

我自己看完这篇论文，最大的感受是，Harness Engineering 范式不是在造更强的模型，是在给已有的强模型配一个更靠谱的工程环境。

我之前写过好几篇讲 Agent 工具调用、Skills、MCP 的文章，每次都会在评论区看到一类反馈，「工具给这么多，模型不还是会瞎调」。这种反馈其实很真实，它说明在真实工程里，工具调用问题比工具缺失问题严重得多。

DataFlow-Harness 这套设计回答的就是这个问题，你给 Agent 越多工具，它需要的程序性知识也越多。这两件事必须同时做。只做工具调用不做程序性知识，结果就是 MCP-only 那种「工具有 100 个，每个都调一遍但顺序全错」的状态。

六、踩过的坑和实操建议

如果你的团队在尝试类似方案，我自己有三个建议。

第一，先把 Operator Registry 建起来。这是底座，没有它后面所有 Skills 都是空中楼阁。Registry 要覆盖的不只是算子名，还要有参数 Schema、依赖关系、典型调用顺序。

第二，Skills 不要追求大而全。从高频任务开始写，一个 Skill 解决一类问题。Skills 的颗粒度跟 SOP 类似，太粗用不上，太细维护成本高。

第三，typed mutations 不要急着上。这是四层架构里工程量最大的一层。前三层跑稳了，再考虑用它来收紧最后一道口子。

最后说句掏心窝的话。我自己看这个领域一年多了，最大的感受是，真正决定 AI 能不能稳定产生价值的，往往不是模型本身，而是模型被放进什么样的工程环境里。

DataFlow-Harness 这篇论文的核心贡献，不是证明了 Agent 有多强，是证明了好的工程环境能让 Agent 强的那部分稳定地发挥出来。

• • 论文地址 → https://huggingface.co/papers/2607.16617
• • DataFlow 主库 → https://github.com/OpenDCAI/DataFlow（7178⭐，Apache 2.0）
• • DataFlow-WebUI 工程交互入口 → https://github.com/OpenDCAI/DataFlow-WebUI（150⭐）
• • DataFlow-Harness 论文 PDF → https://arxiv.org/abs/2607.16617

既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。 想第一时间收到推送，也可以给我个星标⭐～ 我们下次再见。 / 作者 OPC