我最近和几个做 Agent 开发的朋友聊天发现大家卡住的点惊人地一致不是模型不够聪明也不是流程不会搭而是不知道怎么评价自己做出来的智能体到底行不行。你说它能调用工具但调用得准不准给它一个模糊任务它能不能选对工具、填对参数、走对流程这些问题都回答不了因为手头没有像样的评测集。自己写题吧工作量巨大从网上找吧又跟自己的场景对不上。后来我注意到一个叫 Agent Seer 的项目方向——从 MCP 规范自动合成智能体评测。这个思路很有意思它不是在模型层硬刚而是把矛头对准了评测数据生产的源头。这篇文章我想把这条思路拆开MCP 规范里到底有什么可以被用来“自动出题”这套方法能做到什么程度落地时又会在哪些地方翻车。先说我的核心判断Agent Seer 这类项目真正解决的不是“多了一个评测工具”而是把评测任务的生产方式从“人工写题”变成了“基于 schema 自动合成”。它让评测可以跟着工具更新走这比增加几个指标重要得多。1. 为什么智能体评测的难点变成了“出题”过去我们评测一个聊天机器人核心是考察它的“知识”和“语言能力”。你准备几百道问答题让模型回答然后看答案和标准答案的重合度。这个流程虽然也烦但出题这件事是有据可循的——围绕知识点、场景、难易程度去造题就行。但智能体不一样。智能体的核心能力是“执行任务”而任务天生是碎片化的环境不同、工具不同、参数不同、前置状态不同。你要评测一个智能体能不能通过 MCP 协议调用外部工具来完成一个具体目标比如查天气、操作数据库、读取文件再生成报告你就得准备一系列“任务场景”。这些任务场景还必须有明确的目标、合理的输入、可验证的输出否则你无法判断智能体的表现是好是坏。于是问题就来了任务集从哪来1.1 从问答到任务执行评测对象变了传统 LLM 评测有一个稳定的假设输入一个 prompt输出一个答案。答案的边界相对清晰好坏判断也相对直接。但智能体评测的假设完全不一样输入一个目标智能体需要自己观察环境、选择工具、构造参数、处理返回值、可能还需要多轮试探。这时候评测的任务就不是“写一个正确答案”而是“设计一个完整的工作流”。这个差别是本质性的。一个普通的聊天问答评测你可以让运营同事花一个下午整理两百道题。但一个智能体评测你需要每一个任务都覆盖到工具选择、参数格式、错误处理、结果校验等细节。复杂度和成本都不是一个量级。1.2 手动维护评测集的三个死穴我在自己的项目里手动维护过评测集体验可以用三个词总结慢、贵、脆。慢是因为每个任务都要设计输入、标注预期工具调用序列、准备验证逻辑一天能打磨 20 条就不错了。贵是因为这需要懂业务、懂模型、懂工具的复合人力不是随便找个外包就能干。脆是因为业务一变、工具接口一变、参数 schema 一变评测集可能全部失效需要整个重做。而且这里还有一层更难受的工具本身在快速迭代。你的 MCP server 今天加了一个工具明天改了参数名后天废弃了一个接口。评测集的更新速度永远追不上工具的更新速度。评测集一旦落后评测结果就失真——你以为是模型变差了其实是题目的假设已经过时了。1.3 真正值得自动化的是评测集生成所以我一直觉得智能体评测最值得自动化的不是“打分”而是“出题”。打分逻辑相对稳定出题才是不停消耗人力的地方。如果能让评测任务从工具的规范文件里自动长出来每当 server 端更新规范评测集也能随之更新这个回路才算真正转起来。Agent Seer 的思路正好踩在这个点上——它把 MCP 规范当作评测任务的“原料”从原料里自动合成出可执行的评测用例。与其问“这段描述能生成多少个题”不如问“规范文件里哪些字段、哪些约束本来就可以直接变成评测脚本”。2. MCP 规范为什么能成为评测原料MCPModel Context Protocol是模型上下文协议的缩写它定义了一套智能体与外部工具、资源、提示词交互的标准方式。当你说“我的 MCP server 提供了哪些工具”时这份 server 的定义文件里其实已经包含了大量结构化信息。这些信息单独看是给模型和客户端做路由用的但如果拿来做评测它反而是极其稀缺的“带标注数据”。2.1 MCP 规范里到底有什么一个典型的 MCP server 会声明三类东西工具Tools每个工具都有名字、描述、参数 schema。参数 schema 通常是 JSON Schema 格式规定了每个参数的类型、是否必填、取值范围、默认值等。资源Resources可以被读取的数据源比如文件、数据库、API 返回结构每个资源也有 URI 和描述。提示词Prompts预设的 prompt 模板用来指导模型如何完成某类任务。对于评测来说最有用的是工具部分。工具描述是模型选择工具时看的“说明书”而参数 schema 是模型必须遵守的“语法规则”。两个加在一起就构成了一个天然的评测关卡描述可以测模型“能不能找到正确工具”schema 可以测模型“能不能填对参数”。2.2 工具描述本身就是任务描述这里有一个很容易被忽略的细节MCP 工具的描述通常是以“人类可读的自然语言”写的。比如“根据城市名查询当前天气”“创建一条新的待办事项并返回其 ID”“读取指定路径的本地文件内容”。这些描述天然就是任务需求。你说“帮我看看北京现在多少度”对应的工具就是“查询天气”对应的参数就是城市名。如果你把这段需求原样交给智能体它必须经过“理解需求 - 匹配工具 - 填充参数 - 发起调用”的完整链路。评测点完全不需要额外设计规范文件已经把答案框架写好了。更妙的是这些工具描述往往带有口语化的语义变体。同一个“查询天气”工具描述里可能写着“weather”“气温”“天气预报”等多个词。这正好可以用来测模型对同义表达的识别能力。人工造题时你还要故意做“换说法”的数据增强而在 MCP 规范里描述本身就隐含着这种多样性。2.3 从字段到评测关注点的映射我们可以把 MCP 规范里的每个字段映射到评测维度上这比拍脑袋写题目要系统得多规范字段评测关注点说明工具名称工具选择是否准确模型是否能在多个工具里挑到正确的那个工具描述语义理解是否充分描述改为换说法的需求后模型还能不能匹配上参数名参数命名理解模型是否理解“city”和“location”指向同一个概念参数类型类型转换能力字符串、数字、布尔值是否能按 schema 转换成正确类型参数必填性完整性缺少必填参数时模型是主动询问还是硬编错值参数枚举值值域约束只允许“sunny/rainy”时模型会不会传“good”参数描述值理解模型是否理解“温度单位是摄氏度”这类隐性规则返回结构结果利用能力返回值的结构和字段名模型能不能正确读取并继续任务有了这个映射表你就能理解 Agent Seer 这类项目为什么选 MCP 作为切入口它不只是因为 MCP 火更是因为 MCP 规范本身就是一套高度结构化的评测标注。以前做评测要人先写问题再写答案现在只要解析规范问题模式和答案模板都能半自动生成。3. 从规范到评测任务合成策略与流程理论说得再漂亮最终还是要落到怎么实现。我没有拿到 Agent Seer 官方实现的具体代码但根据这类项目的通用做法可以把“从 MCP 规范到评测任务”拆成一条清晰的处理管线。我建议所有想自己动手做类似事情的人先按这个流程走一遍不要急着上复杂框架。3.1 第一步把 MCP server 的工具结构化解析出来这一步看似简单坑其实很多。一个 server 可能定义了 20 个工具每个工具的描述长短不一参数 schema 的嵌套层级也可能有三四层。你需要先写一个解析器把“工具名、描述、schema”完整提取出来并保存成统一的 JSON 结构。这一步的关键不是解析本身而是“留下原始字段”。你要保证后面所有合成逻辑都能溯源到规范文件的具体位置。为什么因为自动生成的问题如果需要人工修复你得能迅速判断是“规范写得不好”还是“合成逻辑有问题”。一个常见的做法是把解析结果保存为如下的中间结构。{ server: weather-server, tools: [ { name: get_current_weather, description: 根据城市名查询当前的天气情况包括气温、天气状况、风速, inputSchema: { type: object, properties: { city: {type: string, description: 城市名使用中文}, unit: {type: string, enum: [celsius, fahrenheit], description: 温度单位默认 celsius} }, required: [city] } } ] }这只是一个中间结构示例不是 Agent Seer 的输出格式。你可以根据自己的需求调整字段设计但原则是原始信息不丢能在后续环节重新引用。3.2 第二步设计多层级任务合成策略拿到工具清单后不要急着生成题。先按调用深度把评测任务分成几类每一类考察的能力不一样。我把任务分成四个层级单工具单参数最简单的“查天气”式任务。考察工具识别、必填参数填充。单工具多参数任务里包含多个参数的合理组合。考察对非必填参数、枚举值、默认值的理解。多工具串联需要先调用工具 A 拿到结果再调用工具 B 完成下一步。考察多步规划、结果传递。异常路径任务里故意给出不存在的实体、缺失的信息、越界的值。考察模型的鲁棒性和追问能力。这个分层很重要。因为 MCP server 的工具定义里各个工具之间可能是独立的也可能存在隐性的先后依赖。如果你只做单工具题目评测结果只能说明模型“会调用 API”不能说明它“能完成任务”。真正有价值的是多工具链路。合成多工具任务时通常的做法是把多个工具的 schema 拼起来做一个语义上的“串联模板”。比如一个工具负责“搜索城市 ID”另一个负责“按城市 ID 查天气”。模型必须理解光传城市名不够要先搜索拿到 ID 再传给下一个工具。3.3 第三步从 JSON Schema 反推自然语言任务这是整个合成逻辑里最核心的一步。你要把结构化的参数定义转化成一条自然的、可执行的任务指令。假设我们有这样一个天气工具{ name: get_weather_by_city, description: 输入城市名和中英文标识返回该城市当前温度, inputSchema: { type: object, properties: { city: { type: string, description: 城市中文名例如 北京 }, lang: { type: string, enum: [zh, en], description: 返回语言 } }, required: [city, lang] } }一个合成器可以生成出这样的任务任务描述“请帮我查询北京当前的气温并且我希望结果用英文返回。”预期工具调用get_weather_by_city(city北京, langen)再进一步还可以做语义增强。把“查询气温”换成“看看北京冷不冷”“北京现在穿什么合适”这些变体都能测出模型能否透过表层措辞找到底层工具。需要提醒的是完全自动地用模板生成的任务很容易出现“描述太赤裸”的问题。比如任务描述直接写成“调用 get_weather_by_city 方法传入参数 city北京, langen”那就不是在评测模型而是在考它能不能读懂 JSON。一个好的合成器应该把原始 schema 里的参数名打散把“北京”这个值藏进一个自然句子里让模型自己去抽取。3.4 第四步为每个任务准备可验证的预期结果这个问题最容易被低估。很多人以为生成了任务描述就完成了出题但评测必须有一个“判断对错”的基准。单工具任务可以靠“模型选择的工具名 参数匹配率”来判断多工具任务就必须用规则验证“中间步骤是否合理”而不只是看最终结果。我建议把验证逻辑分两层参数层模型生成的工具调用参数是否符合 schema 的约束。类型对不对、必填项有没有、枚举值是否合法。行为层模型是否调用了正确的工具序列。中间结果是否传递正确。遇到错误时有没有合理的应对。如果从规范生成的是一个“预期工具调用序列”那验证逻辑就是做序列比对。如果目标是一个“最终状态”那验证逻辑就要写成一个状态检查函数。这两种方式不是互斥的在真实项目里可以混合使用。4. 评测执行和打分重点不是对话是过程评测集生成好之后下一步是执行和打分。很多第一次做 Agent 评测的人会犯一个直觉性错误把智能体输出的最终结果跟参考答案做文本相似度比较。这看起来合理但实际会漏掉最关键的信息。智能体评测要抓的是“过程”不是“终态”。同样是从北京查天气模型可能调用了正确的工具、填了正确的参数、得到了正确的结果也可能把整个对话都理解错了只是因为工具本身返回了兜底数据看起来像是对的。只看最终文本这两种情况都会得高分但显然第一个智能体能复用第二个不能。4.1 评测系统至少要记录这些过程信息我建议评测时记录下来的完整事件序列至少包括模型收到了什么输入任务描述、系统提示词、可用的工具列表模型选择了哪个工具模型填了哪些参数具体值是什么工具返回了什么结果模型看到结果之后下一步做了什么如果发生了重试或报错报错信息是什么从开始到结束完整的事件时间线有了这份过程日志你才能回答“这个智能体到底在哪一步出了问题”。是第一步就没看懂需求是看懂了需求但选错工具还是选对了工具但参数没填对这些问题的答案决定了你接下来应该微调模型、优化提示词还是修工具描述。4.2 打分维度从“对不对”升级到“好在哪”只看一个总分太粗糙我一般会把评测分数拆成以下维度维度评价内容得分逻辑工具选择准确率在所有需要调用工具的任务里选对工具的比例选对 1 分选错 0 分部分正确 0.5 分参数填充准确率选中正确工具后参数与 schema 的匹配程度必填项全对且类型正确得满分缺一项扣 35%流程完整性多工具任务中是否按正确顺序执行用预期序列比对支持容错额外调用不扣分错误处理能力遇到缺失信息或工具报错时的表现主动询问加分硬传空值不扣但也不加结果利用率工具返回值被后续步骤正确使用的比例考察中间结果是否被真正读取并用于下一步成本效率完成同一任务的调用次数和 token 消耗调用次数越少越好但要保证完成度不降这套打分框架的核心是“分阶段评价”。工具选择、参数填充、流程编排、结果利用每一个阶段都是独立的瓶颈。如果你只拿一个总分你根本分不清是模型能力问题还是工具描述问题。4.3 用 schema 做参数校验用规则做结果校验参数校验是最容易自动化的部分。模型产生的工具调用直接对它生成的参数 JSON 做一次 schema validation。所有类型不匹配、必填缺失、枚举值越界都能被抓出来。这不需要人工判断几乎是零成本。结果校验就复杂一些。如果工具返回的是一串天气数据你要怎么判断模型“正确地使用”了它建议不要对原始文本做关键词匹配而是对工具返回的 JSON 做字段级断言。比如工具返回了一个temperature字段你要验证的是后续步骤有没有引用这个字段而不是输出文本里有没有出现数字“23”。当然这里的校验规则设计也不算轻松。如果任务的目标是“查询北京天气”最终输出是一个文本那你就需要提前定义好“标准输出应包含城市名、温度、天气状况”这类规则。这部分无法完全自动化但可以做成半自动先用模板生成规则再让人工快速确认一遍。5. 落地时最容易踩的坑自动合成评测听起来很美好但我必须提醒一句这类方案在 demo 阶段很好看真正放进项目里还是会遇到一系列问题。这里有几个我见过的高频坑提前列出来能帮你少走弯路。5.1 生成任务不等于真实任务语义改写不能只是换关键词最容易被忽略的坑是自动合成的任务往往“太规范”。真实用户不会说“请调用 get_weather_by_city 工具查询北京天气”他们会说“北京今天冷不冷”。如果你的合成器只是把 schema 里的字段拼成一个问句那模型不费吹灰之力就能答对评测结果会虚高。解决办法是给任务生成阶段加入“语义扰动”。把工具描述里的词换成近义词、把参数值藏进更复杂的语境、把直白指令改成含混意图。这需要一些模板设计和语言变体库。没有这一步你的评测集只能测出模型的“阅读理解能力”测不出它的“意图理解能力”。5.2 工具返回结果不唯一先跑通 reference 验证再开放测试另一个常见的坑是验证逻辑本身有问题。你明明设计了一个任务预期模型调用工具 A 拿到 ID再调用工具 B 查数据。但工具 B 有一定的随机性每次返回的数据都不同。这时候如果你的验证逻辑只检查最终数据里有没有某个关键字就会不稳定。我的建议是在任何模型进入评测之前先拿一套“标准参考答案”跑一遍 reference 验证。标准答案不是模型生成的而是你手写的最优调用序列。如果这套序列都不能稳定通过验证逻辑说明不是模型的问题是评测设计有问题。这个步骤看起来简单但真的能帮你过滤掉大量无效评测。5.3 防止评测泄漏agent 看到的是改造后的任务不是 schema 原文还有一个很隐蔽的坑如果任务描述里直接透露了工具名、参数名、枚举值那评测的难度会瞬间崩塌。模型根本不需要推理直接从文本里提取就行。所以任务合成时必须做“去工具化”处理。任务描述里不要出现get_weather_by_city要换成“查一下北京的天气”不要出现langen要换成“用英文给我返回”。如果模型看不到原始 schema它还能填对参数这才说明它真正理解了工具的语义边界。5.4 排查链路当 agent 得分不稳定先按顺序排查如果你的评测跑出来结果波动很大不要急着调模型。建议按下面的顺序排查先看工具描述。描述越短、越模糊模型出错率越高。先确认描述是否清楚以及是否有同义干扰项。再看参数 schema。类型、必填、枚举值有没有设计合理的边界。有时候模型填对了但 schema 本身定义得模棱两可也会被扣分。再看任务改写质量。真实任务描述和 schema 的差距有多大。如果模型总是识别不到正确工具往往是改写后的问题超出了 schema 的描述范围。再看验证逻辑。确认你的得分逻辑本身没有歧义尤其是多工具任务里的序列匹配规则。最后看模型基础能力。前面几层都没问题时再考虑换更强的模型或者调整提示词。这个顺序的本质是先怀疑评测设施再怀疑模型。大部分评测结果不可信的案例最后查出来都是评测设计本身的问题而不是模型能力的问题。6. 适用边界什么评测适合自动合成什么不适合任何一个技术方案都有边界。自动合成评测的最大优势是“快”和“跟得上变化”但它不是银弹。你需要清楚地知道在什么场景下这套方法是好东西什么场景下它反而会给你制造虚假的安全感。6.1 适合单一 server 工具调用、参数准确性、描述理解如果评测目标是回答这些问题模型能不能在 50 个工具里挑中那个对的模型能不能理解参数描述里那些隐性规则模型能不能在多工具串联时正确传递中间结果模型能不能在任务描述语义变化后仍然稳定调用那么基于 MCP 规范的自动合成评测是一个非常好的选择。因为这些问题都可以用工具名、参数 schema、工具返回结构来判定评测点非常清楚自动化的成本很低。6.2 不适合长期规划、复杂系统集成、真实用户满意度如果你的智能体是一个需要运行很长时间、在多个系统之间协调、并且要处理大量非结构化信息的系统比如一个客服智能体需要理解用户情绪、查询订单、协商补偿方案自动生成的评测就远远不够。因为任务的价值不止在于“调对工具”而在于“结果的合理性和用户满意度”这些很难从 schema 里推导出来。在这种场景下我建议把自动合成和人工构造混合使用。自动合成用来做“回归测试”和“冒烟测试”保证每次改动后核心链路不坏人工构造用来做“深度测试”和“场景化测试”覆盖那些 schema 表达不了的东西。6.3 长期价值评测集不是资产评测管线才是很多团队把评测集当成一次性资产花大力气做完几百道题就完事了。但在这个工具快速迭代的年代静态的评测集一定会腐烂半年后可能一大半已经失效。真正的资产是那条“从规范到评测集再到验证逻辑”的生产管线。Agent Seer 这类思路的长期价值正在于此它让评测集不再是写死的题库而变成一套可以从 MCP 规范持续再生的流水线。工具更新了重新拉取规范解析工具列表生成新的任务自动补全验证逻辑。虽然这个流程在初期需要投入不少工程精力但它解决的是“评测集永远跟不上工具迭代”这一根本矛盾。如果你打算在自己的项目里尝试这套方法我的建议非常直接不要一开始就追求覆盖几十个 server、上千个工具。先挑一个核心的 MCP server用五十个工具跑通从解析、合成、执行到打分的完整闭环。确认这套流程在你的场景里判断准确、波动可接受之后再逐步扩展到其他 server。先跑通再铺开这个顺序看起来慢但其实是这类评测基础设施最稳妥的落地方式。