做 Agent 相关开发的读者可能最近都有同感Agent 用起来越来越顺手但评测一个 Agent 到底好不好用却越来越难。难点不在跑通一个 Demo而在“怎么证明它在真实任务上可靠”。工具调用是否准确、多步推理是否稳定、边界情况是否崩盘这些都需要大量测试用例。传统做法是人工写 Prompt、构造模拟环境再逐条标注预期结果。一套评测集做下来耗费几天时间不说Agent 一改工具定义评测集又得跟着改维护成本非常高。这也是 Agent Seer 这类系统真正值得关注的原因它把“评测用例”从手写变成从 MCP 规范自动合成把“评测”从人工密集劳动变成可持续运行的基础设施。过去要花几天构造的评测集现在可以随 MCP 工具定义的变化自动重新生成。这篇文章会围绕这条主线展开先解释为什么 MCP 规范是自动评测的突破口再拆解 Agent Seer 的合成思路和核心流程最后给出一套可落地的示例与工程建议。无论你是在做企业内部 Agent、MCP 服务还是准备评估第三方智能体平台这篇文章都能帮你把评测成本降一个量级。1. 智能体评测为什么这么难先说一个反直觉的事实模型评测已经很成熟但 Agent 评测远未成熟。普通大模型评测本质是“静态问答”——输入一个 Prompt比较生成文本和标准答案的相似度。即使要求高一些也只需要在选择题、判断题、简答题之间做区分。评测集可以提前构造模型版本可以离线批量跑。Agent 评测完全不同。它评测的不是“一句话回答得好不好”而是“目标有没有在真实环境里被完成”。这带来几个具体难题第一评测对象不是单次输出而是多步轨迹。Agent 可能需要先调用搜索引擎再读取页面再调用某个内部 API最后汇总答案。中间任何一步选错工具、传错参数最终结果就错了。传统“对答案”的方式无法定位是哪一步出错。第二环境是动态的。普通模型评测是“closed book”Agent 评测则需要真实环境一个数据库、一个浏览器、一个企业内部系统。环境状态会变化数据会更新测试用例的预期结果不再是静态字符串。第三工具定义经常变更。今天 Agent 有 5 个工具明天加了 1 个参数后天又废弃了某个工具。每次变更手写的评测集都可能失效。第四主观性强。“任务完成”有时候取决于用户意图而不只是一个布尔值。比如“帮我查一下这个项目最近的情况”完成标准是模糊的。所以很多团队开发 Agent 时面临一个尴尬局面跑 Demo 时表现惊艳一上真实任务就心里没底。不是模型能力不够而是“验证体系”没有跟上。1.1 为什么 MCP 规范能成为突破口一句话因为 MCP 协议已经把事情定义得足够结构化。MCPModel Context Protocol模型上下文协议是 Anthropic 于 2024 年底推出的开放标准它定义了 AI 应用与大模型之间访问外部工具、数据源和上下文的统一方式。在 MCP 的体系里每个工具都有标准化的描述、名称、输入参数 Schema每个资源都有 URI 和内容格式每个 Prompt 都有模板和参数定义。这意味着Agent 要做什么、能调用什么工具、工具接受什么参数都以机器可读的形式存在。既然机器能读机器就能基于它自动生成评测任务。这就是“从 MCP 规范自动合成智能体评测”的核心前提。没有 MCP 时每个 Agent 的工具定义是私有的评测系统需要针对每个平台写适配器。有了 MCP工具清单、参数结构、调用方式全部标准化自动合成评测用例就变成了一项可复用的技术能力。2. Agent Seer 的核心设计思路Agent Seer 的出发点可以概括为一句话把 MCP 的规范声明当作评测集的“生成种子”而不是把评测集当作脱离系统的静态文件。传统评测流程是人工分析 Agent 功能 → 设计测试场景 → 编写测试 Prompt 和预期结果 → 运行评测 → 输出报告Agent Seer 的思路则变成了读取 MCP 工具定义 / 资源配置 / Prompt 模板 → 自动生成评测任务输入、预期行为、验证方式 → 在受控环境中运行 Agent → 对比预期 → 输出报告这两条路径的差异不只是“自动化”三个字而是整套评测体系的维护模型发生了变化。Agent 的工具定义更新了评测任务也随之更新不再需要人工逐条同步。2.1 从“手写用例”到“Schema 派生用例”如果我们把 MCP 中的工具定义看成一份“接口契约”那么评测用例其实就是这份契约的“测试用例集”。契约声明了工具名、描述、参数类型、必填项、可选项测试用例则验证Agent 能否在合适的场景下选中这个工具、参数是否合法、异常输入是否有兜底、超时或报错时是否优雅降级。人工编写测试用例时本质上是根据契约在构建各种输入组合和场景假设。Agent Seer 把这个过程用规则和模型结合起来自动化从 Tool 的inputSchema中抽取参数类型、枚举值、边界值。从 Tool 的description中提炼工具用途和典型调用场景。根据参数组合策略生成一批候选任务。通过调度器在可控环境中执行任务记录 Agent 行为轨迹。对比工具调用结果与预期产出评测报告。这个过程中真正的工作量从“写用例”转移到了“设计生成策略和验证规则”后者可以做一次持续复用。2.2 工具级评测与任务级评测的结合智能体评测不能只看工具调用对不对还要看任务目标有没有完成。Agent Seer 的设计中通常会兼顾两个层级评测层级关注点示例验证方式工具级工具选择、参数构造、调用时机给定天气查询请求Agent 是否调用 get_weather 并传入正确城市对比工具调用日志和预期调用序列任务级用户目标是否达成用户要求“帮我安排明早 10 点的会议”Agent 是否成功创建会议并返回确认检查环境状态变化或最终回复内容工具级评测解决“Agent 会不会调用工具”的问题任务级评测解决“Agent 能不能完成任务”的问题。前者颗粒度细、定位准确后者贴近真实用户价值。Agent Seer 的自动合成能力可以同时支撑这两个层级从工具定义生成工具级用例从 Resource 和 Prompt 模板生成任务级用例。3. MCP 规范基础这份“契约”长什么样在深入 Agent Seer 的实现之前有必要先熟悉 MCP 规范中的基本结构。下面是一个典型的 MCP 工具定义示例它同时也是后续自动合成评测的输入。假设我们有一个天气查询工具{ name: get_weather, description: 获取指定城市在指定日期的天气情况。用于回答天气查询相关问题。, inputSchema: { type: object, properties: { city: { type: string, description: 城市名称例如北京、上海、广州 }, date: { type: string, description: 查询日期格式为 YYYY-MM-DD。默认为今天。, format: date }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位默认 celsius } }, required: [city] } }这段 JSON 已经包含了自动生成评测任务所需的几乎全部信息name工具名对应调用入口。description工具用途可以用于生成“用户意图”。inputSchema参数结构可以用于生成合法/非法输入。required必填项可以用于生成缺少参数时的评测任务。enum枚举值可以用于生成合法取值测试。format/type用于推断边界条件如日期格式错误、类型不匹配等。3.1 Resource、Prompt 与 Tool 的分工MCP 中除了 Tool还有 Resource 和 Prompt 两种重要类型Tool 是可执行的操作比如查询天气、创建订单、发送消息。它改变或读取外部状态。Resource 是结构化的数据资源比如一个数据库记录、一个文件内容。它以uri和内容类型暴露。Prompt 是模板化的提示语封装了特定的任务指令可用于生成对话或工作流。Agent Seer 的信息来源不限于 Tool。例如从一个 Resource 的 URI 结构和描述中可以生成“读取、查询、使用该资源”的任务。从一个 Prompt 模板中可以提取出用户输入变量和完整的执行步骤。从 Tool 的调用链关系中可以构造多工具协作的任务。所以Agent Seer 的“从 MCP 规范合成评测”可以理解成把所有 MCP 服务器暴露的信息当成数据集经过转换、组合、校验生成一套可执行的 Agent 评测计划。4. Agent Seer 环境准备与前置条件虽然 Agent Seer 目前还没有形成统一的开源标准或单一项目仓库但其核心思路完全可以作为一种评测基础设施来搭建。下面以 Python 技术栈为例给出环境准备建议。4.1 运行时与依赖建议使用 Python 3.10 以上版本核心依赖如下# 创建虚拟环境 python -m venv .venv source .venv/bin/activate # 安装依赖 pip install mcp httpx jsonschema如果你的场景需要跑 Python 版本的 MCP 服务端mcpPython SDK 是必须的。jsonschema用于校验和解析inputSchemahttpx用于发起工具调用请求。如果只是做纯分析实验也可以先只安装jsonschema把 MCP 定义文件当作普通 JSON 处理。4.2 准备 MCP 定义文件实际项目中MCP 定义可以从正在运行的 MCP 服务器通过协议动态读取也可以在离线场景下从 JSON 文件导入。为了方便演示下面我们直接使用一个静态 JSON 文件作为输入。{ tools: [ { name: get_weather, description: 获取指定城市在指定日期的天气情况。用于回答天气查询相关问题。, inputSchema: { type: object, properties: { city: { type: string, description: 城市名称例如北京、上海、广州 }, date: { type: string, description: 查询日期格式为 YYYY-MM-DD。默认为今天。 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位默认 celsius } }, required: [city] } }, { name: create_event, description: 在日历中创建一条日程事件。用于安排会议和提醒。, inputSchema: { type: object, properties: { title: { type: string, description: 日程标题 }, start_time: { type: string, format: date-time, description: 开始时间ISO 8601 格式 }, duration_minutes: { type: integer, minimum: 15, maximum: 480, description: 持续时间单位分钟 } }, required: [title, start_time] } } ] }这段定义是我们后面所有合成逻辑的输入样例。它包含一个查询类工具和一个操作类工具正好能展示 Agent Seer 如何处理不同性质的函数。5. Agent Seer 核心流程拆解从 MCP 定义到最终评测报告核心流程可以拆成四个阶段。5.1 阶段一MCP 描述解析第一阶段的任务是把 MCP 定义转换成内部数据结构。这一步看似简单但要注意几个细节inputSchema可能是嵌套结构需要递归解析。描述语言可能不规范需要做归一化处理。不同 MCP Server 的 JSON 格式存在细微差异需要容错。示例代码# 文件路径agent_seer/parser.py import json from jsonschema import Draft202012Validator from typing import Dict, Any, List def load_mcp_definition(path: str) - Dict[str, Any]: with open(path, r, encodingutf-8) as f: data json.load(f) return data def parse_tool_schema(tool: Dict[str, Any]) - Dict[str, Any]: schema tool.get(inputSchema, {}) properties schema.get(properties, {}) # 校验 schema 是否合法 Draft202012Validator.check_schema(schema) return { name: tool[name], description: tool.get(description, ), properties: properties, required: set(schema.get(required, [])), raw_schema: schema, } def parse_definition(path: str) - List[Dict[str, Any]]: data load_mcp_definition(path) tools data.get(tools, []) return [parse_tool_schema(t) for t in tools]这一步完成后我们得到的是一个结构化的工具描述列表后续的评测合成器直接消费这个列表。5.2 阶段二评测任务合成评测任务合成是整个系统的核心。它的输入是解析后的工具结构输出是一组评测用例。每个评测用例通常包含task_type任务类型比如tool_call、multi_tool、invalid_input。user_instruction交给 Agent 的用户指令。expected_tool_calls期望的工具调用序列。validator验证函数或验证规则。下面是一个规则驱动的合成器示例# 文件路径agent_seer/synthesizer.py import copy from typing import Dict, Any, List from datetime import datetime, timedelta VALID_CITIES [北京, 上海, 广州, 深圳] def generate_positive_cases(tool: Dict[str, Any]) - List[Dict[str, Any]]: 根据工具定义生成正常调用场景。 cases [] props tool[properties] if tool[name] get_weather: for city in VALID_CITIES: cases.append({ task_type: tool_call, user_instruction: f你好请帮我查询{city}今天天气怎么样。, expected_tool_calls: [ { tool: get_weather, args: {city: city}, must_contain: True, } ], validator: tool_call_exact, }) if tool[name] create_event: future_time (datetime.now() timedelta(days1)).strftime(%Y-%m-%d %H:%M) cases.append({ task_type: tool_call, user_instruction: f请帮我在明天上午10点安排一场产品评审会议持续1小时。, expected_tool_calls: [ { tool: create_event, args: { title: 产品评审会议, start_time: 2026-01-01T10:00:00, duration_minutes: 60, }, args_match_rule: semantic, must_contain: True, } ], validator: tool_call_semantic, }) return cases def generate_negative_cases(tool: Dict[str, Any]) - List[Dict[str, Any]]: 根据工具定义生成异常和边界场景。 cases [] props tool[properties] required tool[required] if tool[name] get_weather: # 缺省会提示用户补充 cases.append({ task_type: missing_param, user_instruction: 查询一下天气。, expected_tool_calls: [], expected_behavior: ask_clarification, validator: no_tool_call_or_clarify, }) # 非法城市名 cases.append({ task_type: invalid_input, user_instruction: 请查询北京市海淀区中关村软件园旁边的天气。, expected_tool_calls: [ { tool: get_weather, args: {city: 北京市}, args_match_rule: fuzzy, } ], validator: tool_call_fuzzy, }) if tool[name] create_event: # 缺少时间的场景 cases.append({ task_type: missing_param, user_instruction: 帮我创建一个会议。, expected_tool_calls: [], expected_behavior: ask_clarification, validator: no_tool_call_or_clarify, }) # 参数超出取值范围 cases.append({ task_type: invalid_param_value, user_instruction: 帮我创建一个持续24小时的会议。, expected_tool_calls: [], expected_behavior: ask_clarification, validator: no_tool_call_or_clarify, }) return cases def synthesize_tasks(tools: List[Dict[str, Any]]) - List[Dict[str, Any]]: tasks [] for tool in tools: tasks.extend(generate_positive_cases(tool)) tasks.extend(generate_negative_cases(tool)) return tasks这个示例的逻辑比较简单但已经体现了核心思路通过“契约”自动生成测试意图。更高级的合成器可以使用大模型辅助生成指令文本但规则驱动的方式更稳定、可解释、成本低。5.3 阶段三评测执行与数据收集评测执行阶段的关键是搭建一个受控环境。受控环境的边界决定了评测的可靠性如果是工具调用评测需要启动一个模拟的 MCP Server记录所有调用日志。如果是任务级评测需要准备一个可回滚的测试环境比如临时数据库、Mock 外部 API。所有外部调用都需要可追踪避免真实世界状态干扰。下面是一个简化的评测执行器# 文件路径agent_seer/runner.py import json import time from typing import Dict, Any, List class MockMCPRunner: 模拟 MCP Server 环境捕获工具调用日志。 def __init__(self): self.call_logs [] def execute_agent(self, user_instruction: str) - Dict[str, Any]: 模拟 Agent 执行。实际项目中这里是接入 Agent 的入口 比如调用你自己的 Agent 框架、大模型 API或者第三方智能体平台。 # 该函数内部应由实际 Agent 接管。 # 这里仅返回一个空的调用结果便于演示数据结构。 return { instruction: user_instruction, output: 模拟输出, tool_calls: [], } def run_case(self, case: Dict[str, Any], tool_name: str) - Dict[str, Any]: result self.execute_agent(case[user_instruction]) return { case: case, agent_output: result, timestamps: {start: time.time()}, tool_name: tool_name, } def run_evaluation(tasks: List[Dict[str, Any]]) - List[Dict[str, Any]]: runner MockMCPRunner() records [] for task in tasks: record runner.run_case(task, task.get(tool_name, unknown)) records.append(record) return records注意execute_agent是真正需要你自己接入的部分。实际项目中你会在这里调用你自己构建的 Agent比如基于 Dify、Coze、自研框架等。Agent Seer 的思路是提供“用例生成 结果校验”的能力而不是取代 Agent 本体。5.4 阶段四结果校验与报告评测执行完成后需要根据每个用例的验证规则判断结果是否通过。# 文件路径agent_seer/validator.py from typing import Dict, Any, List def validate_tool_call(record: Dict[str, Any]) - Dict[str, bool]: case record[case] expected_calls case.get(expected_tool_calls, []) actual_logs record[agent_output].get(tool_calls, []) passed True details [] for expected in expected_calls: found False for actual in actual_logs: if actual.get(tool) expected.get(tool): found True break if not found: passed False details.append({ expected_tool: expected.get(tool), found: found, }) return { case_id: id(case), instruction: case[user_instruction], passed: passed, details: details, } def generate_report(records: List[Dict[str, Any]]) - Dict[str, Any]: results [validate_tool_call(r) for r in records] total len(results) passed sum(1 for r in results if r[passed]) return { total_cases: total, passed_cases: passed, pass_rate: round(passed / total, 4) if total else 0, results: results, }这样一个最小可运行的 Agent Seer 流程就跑通了读取 MCP 定义 → 合成评测任务 → 执行 Agent → 校验结果 → 输出报告。6. 完整示例从 MCP 定义到评测报告下面把前面的代码串联起来在终端里跑一个完整流程。# 文件路径agent_seer/run_demo.py import json from parser import parse_definition from synthesizer import synthesize_tasks from runner import run_evaluation from validator import generate_report TOOLS_PATH mcp_tools.json def main(): # 第 1 步解析 MCP 定义 tools parse_definition(TOOLS_PATH) print(f解析到 {len(tools)} 个工具) # 第 2 步合成评测任务 tasks synthesize_tasks(tools) print(f合成 {len(tasks)} 个评测任务) for task in tasks: print(f - [{task[task_type]}] {task[user_instruction]}) # 第 3 步执行评测 records run_evaluation(tasks) # 第 4 步生成报告 report generate_report(records) with open(report.json, w, encodingutf-8) as f: json.dump(report, f, ensure_asciiFalse, indent2) print(f评测完成共 {report[total_cases]} 条用例 f通过 {report[passed_cases]} 条 f通过率 {report[pass_rate] * 100:.2f}%) if __name__ __main__: main()预期输出类似解析到 2 个工具 合成 13 个评测任务 - [tool_call] 你好请帮我查询北京今天天气怎么样。 - [tool_call] 你好请帮我查询上海今天天气怎么样。 - ... - [missing_param] 查询一下天气。 评测完成共 13 条用例通过 0 条通过率 0.00%由于示例中的MockMCPRunner没有真正执行工具调用所以通过率会是 0。当你把execute_agent替换为真实 Agent 后通过率才有意义。这也是评测框架设计中的正常现象架子搭好后接入实际系统才能看到效果。6.1 如何判断评测真的生效判断评测框架是否可靠不能只看通过率数字。建议做三个自检正例能过反例能拦。正常的工具调用应该通过缺少参数、参数非法的场景应该被判定为不合规或触发澄清。换一个工具定义评测集能自动变化。删掉某个 tool 后重新合成任务旧用例不应该残留。Agent 的行为能被完整记录。每个工具调用的入参、出参、耗时、错误信息都应该有日志否则无法定位问题。如果这三个自检都通过评测系统才算真正可用。7. 常见问题与排查思路在搭建和运行类似 Agent Seer 的评测系统时你可能会遇到下面这些问题。问题现象可能原因排查方式解决方案合成的评测任务与工具描述不匹配描述信息不全或输入 Schema 不规范检查 MCP 定义中的description和inputSchema内容完善工具描述在合成器中加入语义解析用例覆盖不全生成策略过于依赖规则缺少大模型辅助查看生成的用例类型分布引入模型辅助生成补充长尾场景Agent 调用环境不稳定评测环境依赖外部真实服务查看网络和第三方 API 调用日志使用 Mock 服务和沙盒环境隔离外部依赖通过率波动大大模型推理存在随机性多次运行查看标准差增加重试机制和多次采样评估工具调用日志缺失Agent 框架未暴露完整调用链检查 Agent 的追踪和日志配置在 Agent 层增加调用埋点评测任务之间互相影响共享环境状态未清理检查用例执行顺序每个用例执行前重建环境7.1 一个典型的“假阳性”陷阱评测系统最容易犯的错误是“用例通过了但问题依然存在”。例如你的验证规则只检查了工具是否被调用却没有检查参数是否合理。一个只会调用get_weather但乱传城市名的 Agent也可能获得很高的通过率。所以验证规则的粒度非常关键。仅做二值判断不够最好增加参数合法性校验必填参数是否齐全、类型是否正确、枚举值是否在范围内。调用顺序校验多步任务中工具调用顺序是否合理。结果状态校验工具返回数据是否被正确消费而不是只调用了就结束。8. 最佳实践与工程建议8.1 评测集版本化评测集应该是代码仓库中的一等公民。推荐把生成的评测任务和报告存为 JSON 文件纳入 Git 管理。当 MCP 定义变化时重新生成评测集并 diff 前后差异防止变更范围失控。8.2 最小权限与安全隔离Agent 评测一定要在可控环境中执行尤其是涉及数据库、支付、消息发送等操作时。建议使用独立测试数据库不连接生产环境。对工具调用做重定向比如把邮件发送工具指向测试邮箱。使用容器或沙盒隔离 Agent 的运行时环境。对评测用例中的敏感数据做脱敏处理。8.3 分层评测策略不要只做一个“综合评测集”建议按层级拆分单工具调用评测验证 Agent 能否正确使用单个工具。多工具协作评测验证 Agent 能否按顺序组合多个工具。端到端任务评测在完整业务流程中验证用户目标达成率。分层的好处在于当端到端评测失败时可以快速定位是“工具调用层”还是“任务规划层”出了问题。8.4 与 CI 流程集成如果你希望评测成为常态化机制可以把它做成 CI 流水线的一个环节。每当 MCP 定义或 Agent 代码变更时自动触发一次评测并把报告发布到内部平台。# 文件路径.github/workflows/agent-eval.yml name: Agent Evaluation on: push: paths: - agent/** - mcp/** jobs: evaluate: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.10 - name: Install dependencies run: pip install -r requirements.txt - name: Run agent evaluation run: python agent_seer/run_demo.py - name: Upload report uses: actions/upload-artifactv4 with: name: agent-eval-report path: report.json这样Agent 的每次变更都有自动化验证兜底回归问题能被及时发现。8.5 善用主流智能体平台做对照如果你正在使用 Dify、Coze 这类智能体平台也可以把 Agent Seer 的评测任务导出用于横向对比不同平台、不同模型在同一批任务上的表现。评测任务本身是模型无关的这正好体现了“从 MCP 规范合成评测”带来的平台迁移优势只要工具定义一致评测集可以复用到任何兼容 MCP 的 Agent 上。8.6 不要忽视人工抽检自动合成评测解决了“覆盖率”和“维护成本”问题但它不能完全替代人的判断。建议在自动化评测之外定期人工抽检一部分真实用户任务对比自动评测与人工判断的一致性。这个比例不一定高但能有效发现生成策略本身的偏差。9. 总结与后续学习方向Agent Seer 代表的是一种思路转变评测不再是 Agent 开发完成之后的“收尾工作”而是随着 MCP 规范演进而持续更新的基础设施。它的核心价值不在“生成多少用例”而在“把用例与系统契约绑定”让评测集永不落后于系统变更。如果你想深入实践下一步可以做三件事第一把你正在开发的 MCP Server 或 Agent 项目里的工具定义导出尝试用本文的方法生成一批评测任务跑通一个最小闭环。即使只是 2 到 3 个工具的规模也能感受到自动合成和手写用例的差别。第二把验证逻辑从“工具被调用”升级到“任务目标达成”。这需要为每个工具设计更细粒度的验证器也是整个评测系统最有挑战、最有价值的部分。第三关注 MCP 社区和主流智能体平台的演进。MCP 规范本身还在快速迭代Tool、Resource、Prompt 的定义方式会越来越丰富。随着规范不断完善Agent Seer 这类“从规范自动合成评测”的方法会越来越通用。Agent 的落地瓶颈正在从“能不能做出来”转向“能不能证明它可靠”。而证明可靠的关键就是一套可持续、可追溯、能随系统演进的评测体系。MCP 规范已经为这套体系提供了最好的数据源剩下的就看我们怎么把评测这个基础设施做扎实了。
