做 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 协议已经把事情定义得足够结构化。
MCP（Model 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用于校验和解析inputSchema，httpx用于发起工具调用请求。
如果只是做纯分析实验，也可以先只安装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", encoding="utf-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(days=1)).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", encoding="utf-8") as f: json.dump(report, f, ensure_ascii=False, indent=2) 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/checkout@v4 - uses: actions/setup-python@v5 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-artifact@v4 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 规范已经为这套体系提供了最好的数据源，剩下的，就看我们怎么把评测这个基础设施做扎实了。
