企业官网建设流程全解析

Agent Seer 这个方向，最近在智能体开发社区里被问得挺多。简单说，它不是又一个聊天助手，也不是 MCP server 的管理面板，而是一套“从 MCP 规范自动合成智能体评测”的做法。它解决的问题非常具体：当你的智能体接入了多个 MCP 工具后，怎么快速、低成本、可重复地判断它到底会不会用这些工具。

先说结论：Agent Seer 的核心价值，不是让你少写几条测试用例，而是让评测用例的生成从“人工写 prompt”变成“从接口规范自动推导”。只要 MCP server 暴露出来的工具描述足够完整，就能自动生成覆盖单工具调用、多工具协作、参数边界、异常恢复的评测任务。适合做智能体开发、MCP server 封装、Agent 平台接入验证的人看。最值得关注的是它的评测合成思路，而不是某个具体功能按钮。

下面按实际落地顺序拆一遍。

1. MCP 规范为什么能成为智能体评测的入口

要理解 Agent Seer，先要理解 MCP 在智能体里扮演的角色。MCP 全称 Model Context Protocol，是模型上下文协议，它给智能体提供了一套标准方式去调用外部工具、读取资源、访问提示词模板。简单理解，MCP 是智能体与外部世界的“接口层”。

智能体本身可以很会聊天，但如果它不会在正确的时候调用正确的工具，那在实际业务里基本没法用。可问题在于，评测一个智能体“会不会调用工具”，过去特别麻烦。

人工评测要准备一堆业务问题，还要定义标准答案。比如“帮我查一下北京今天的天气”，理想结果应该是什么？有时候只要智能体调用了 get_weather 就算成功，有时候还要看参数传得对不对，有时候还要看它有没有把返回值整理成用户能看懂的回复。这类评测工作量很大，而且换一个模型、换一套 prompt，之前的用例又要重新过一遍。

MCP 规范把这个问题变简单了。因为 MCP server 里的工具定义是机器可读的，工具名、描述、输入参数、必填字段、参数类型都写在 JSON 结构里。这些信息本身就是评测用例的天然素材。

1.1 工具描述本身就是接口契约

一个标准 MCP 工具定义通常长这样。

{ "name": "get_weather", "description": "查询指定城市的当前天气", "inputSchema": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名，例如北京、上海" } }, "required": ["city"] } }

这份描述里包含了足够多的评测信息：

• 工具能力：它负责查天气。
• 参数约束：需要一个 city 字段，类型是 string，而且必填。
• 描述信息：城市名应该传中文全称或城市名。

评测系统可以从这里自动生成至少几类用例：

• 正常用例：用户说“北京天气怎么样”，模型应该调用 get_weather，并且 city 参数为“北京”。
• 缺失参数用例：用户说“帮我查一下天气”，但不给城市。模型应该追问城市，或者给出合理拒绝。
• 错误参数用例：用户把 city 传成数字，模型应该识别输入不符合 schema。
• 无关工具干扰：用户问“今天适合跑步吗”，模型不应该强行调用 get_weather。

这就是 MCP 规范作为评测入口的关键：你不用人工手写大量 prompt，只要解析工具 schema，就能按规则自动生成一批有明确目标的任务。

1.2 Agent Seer 的定位：评测用例自动合成，而不是只跑一次对话

Agent Seer 这类方案和普通评测工具的区别，在于“自动合成”这三个字。

普通评测工具需要你先准备好测试集，再跑到智能体上，最后看结果。Agent Seer 的思路是把“准备测试集”这一步也自动化。它读取 MCP server 的规范文件，理解每个工具能做什么、需要什么参数，然后自动生成评测任务。

这样做的优势有三个。

第一，覆盖面更广。人工写用例容易漏掉冷门工具，规范解析不会漏。一个 MCP server 只要暴露了工具，理论上就能生成对应用例。

第二，更新及时。工具定义改了，评测用例也跟着改，不用等人重新维护。

第三，可解释性强。每个评测任务都能追溯到某条工具描述或某个参数约束，出问题后容易定位是智能体理解错了，还是工具描述不清晰。

当然，自动合成不是完全靠程序硬拼。实际实现里通常会把“模板生成”和“大模型辅助生成”结合起来。模板负责保证结构稳定，大模型负责把结构化工具调用翻译成更自然的用户表达。

2. 从 MCP 规范到评测任务：按四层粒度合成

自动合成评测任务，不能只做“单工具调用”这一层。否则评测结果只能说明智能体认识工具，不能说明它会用工具。我建议按四层粒度设计合成策略。

2.1 单工具调用：先覆盖参数边界

第一层是单工具调用，也是所有评测的基础。每个工具都要单独过一遍。

生成用例时，重点看这几个维度：

• 正常调用：用户意图清晰，参数完整，模型应该调用对应工具。
• 缺失必填参数：用户没给必填字段，模型应该追问或拒绝。
• 参数类型不匹配：用户给了错误类型，模型应该尝试澄清。
• 参数为空或含义模糊：比如空字符串、null、只有一个标点。
• 与工具无关的请求：用户提了别的问题，模型不应该强行调用工具。

单工具层适合用模板生成，不需要太多大模型参与。工具描述里有什么字段，就按字段生成对应的正常和异常输入。

有一个容易忽略的点是参数描述的质量。如果 MCP 工具 description 写得太模糊，比如只说“查询信息”，而不说信息类型，模型很可能不知道该传什么。这类问题也能在评测里暴露出来。

2.2 多工具串联：把流程变成评测用例

单工具能跑通，不代表多工具协作能跑通。第二层合成要关注工具之间的编排。

多工具用例通常从这几个角度生成：

• 顺序依赖：先调用 A 工具拿到结果，再用结果调用 B 工具。例如通过订单查询工具拿到订单号，再调用退款工具。
• 条件分支：根据用户指令选择不同工具。例如用户明确说“中文”，智能体应该选中文翻译工具，而不是默认英文翻译工具。
• 并行合并：一次请求需要调用多个独立工具，再把结果组织成回答。
• 结果传递：前一个工具的输出要作为后一个工具的输入，参数名可能不一致，需要智能体理解语义映射。

多工具用例不能只靠模板，最好让大模型根据工具列表辅助生成。比如给出一组 MCP 工具清单，让模型提出“哪些工具组合起来能完成一个真实业务”，再转成评测 prompt。

多工具层的判定标准要比单工具更严格。不仅要看最终结果，还要看中间过程。理想结果应该包含一条可验证的工具调用序列，而不只是“最后回答对”。

2.3 资源和指令级约束：从服务元数据生成场景

MCP 不只是工具调用协议，它还规范了资源（Resource）和提示词模板（Prompt）。Agent Seer 如果只盯着 tools，会漏掉一整块能力。

资源类评测可以这样生成：MCP server 暴露了某个资源地址，比如weather://cities，评测任务就是让智能体基于这个资源内容回答用户问题，或者判断智能体是否主动访问了该资源。

提示词模板类评测可以这样生成：MCP server 定义了某种指令模板，比如“合同审查”，评测任务就是让智能体识别出用户需求匹配这个模板，然后按模板流程执行。

这一层对做企业级智能体尤其重要。很多复杂需求不是靠单个工具一次调用完成的，而是靠一套标准流程。如果智能体不知道流程入口，用户问得再自然，它也答不对。

2.4 异常注入：评测智能体的恢复能力

真实环境里，MCP server 不是永远可用。工具可能超时、返回空结果、报权限错误、参数校验失败。评测如果不覆盖这些异常，线上很容易翻车。

异常注入用例包括：

• MCP server 不可用：工具调用直接报连接错误，智能体应该告知用户，而不是撒谎说查到了。
• 工具返回空数据：比如查订单返回空列表，智能体应该给出相应提示。
• 工具返回格式异常：字段缺失或类型不对，智能体应该做容错。
• 权限不足：某个工具调用被拒绝，智能体应该停止，而不是反复重试。

这类用例的难点在于判定标准比较灵活，不一定要模型给出某个固定答案，而是要判断它是否走了合理的兜底路径。比如“工具失败后，是否明确向用户说明失败原因”比“是否成功完成任务”更重要。

3. 落地一套 Agent Seer 式评测需要准备什么

如果想把这套思路实际落地，不用一开始就搞很复杂的平台。先准备三块东西：可解析的 MCP 规范、可观测的智能体运行环境、一个简单的评测执行器。

3.1 至少要有可解析的 MCP 工具清单

评测系统需要知道你的 MCP server 里有哪些工具、参数是什么。所以第一步是把 MCP 规范统一收集起来。

一般来源有三种：

• MCP server 提供的 JSON 描述文件。
• 通过 MCP client 动态发现工具列表。
• 团队内部维护的接口文档，如果能转成 JSON Schema，也可以作为输入。

建议先厘清一件事：你的评测目标是验证“智能体是否会调用这个 MCP server”，还是验证“这个 MCP server 本身的能力”。Agent Seer 更偏向前者。如果 MCP server 本身还不稳定，评测结果会混入外部服务故障，不好定位。

对工具清单的格式，最好是统一的 JSON Schema。MCP 规范本身已经规定了一套结构，但不同 server 实现可能略有差异。落地时先做一个解析层，把差异抹平。

3.2 智能体运行环境要有完整日志

评测不能只看最后的回答文本。很多问题出在中间过程，比如模型调了工具但参数不对，或者模型没有调工具却假装完成了任务。

因此智能体运行环境至少要输出以下日志：

• 用户输入的原始 prompt。
• 模型每次生成的中间消息。
• 工具调用请求，包括工具名和参数。
• 工具返回结果。
• 模型看到工具结果之后的下一条消息。
• 最终回答。

这些日志是评测断言的数据源。没有日志，你很难判断一个任务是“成功”还是“碰巧看起来成功”。

如果用的是现有智能体框架，比如 Dify、Coze、LangChain，尽量开启调试模式或输出追踪。如果自己写客户端，一定要把工具调用链路单独记录成结构化 JSON。

3.3 评测执行器的四个基本模块

一个最简单的评测执行器，只需要四个模块。

第一个是“任务加载器”，负责读取合成出来的评测用例。每个用例应该包含用户 prompt、预期行为、判定规则。

第二个是“执行器”，负责把用户 prompt 发给智能体，并回收运行日志。执行器和智能体之间最好通过接口隔离，这样换模型、换 prompt 都不用改评测逻辑。

第三个是“断言器”，负责判断这次执行是否符合预期。断言不能只看最终回答，还要看工具调用序列和参数校验。

第四个是“报告器”，负责把成功率、失败用例、错误日志汇总成可读报告。报告要能直接定位到具体工具和具体用例。

这四块不需要做得很重。先跑通，再扩展。

3.4 一个最小流程示例

下面是一个概念性流程示意，不是某个具体项目的完整代码。

specs = load_mcp_specs("servers/") tasks = [] for tool in specs["tools"]: tasks.extend(synthesize_single_tool_cases(tool)) tasks.extend(synthesize_multi_tool_cases(specs["tools"])) tasks.extend(synthesize_resource_cases(specs["resources"])) tasks.extend(synthesize_error_injection_cases(specs["tools"])) runner = EvalRunner( agent_client=agent_client, assertion_rules=default_assertion_rules ) report = runner.run(tasks, concurrency=4) report.save("eval_result.json")

这个流程说明了一个关键点：评测用例是“合成”出来的，不是手动维护的。你只需要维护合成策略，比如“单工具参数边界”“工具串联场景”“异常注入比例”，剩下的用例数量可以自动放大。

4. 从单条样例到批量评测：参数和判断标准

评测系统上线后，很容易被“生成几千条用例”吸引。但我的建议是先跑小样例，不要一上来就全量跑。

4.1 先用小样例验证评测链路本身

第一次运行时，建议只挑 10 到 20 条用例，覆盖：

• 一个最简单的单工具正常调用。
• 一个缺失必填参数的用例。
• 一个多工具串联用例。
• 一个工具报错的用例。
• 一个用户与工具无关的用例。

先用这批用例验证评测链路是否正常。比如：

• 任务能否正常发送给智能体。
• 智能体是否有日志回传。
• 断言器能否正确识别工具调用。
• 报告里能否看到失败原因。

如果这批用例跑完，失败原因全都指向“评测脚本本身的问题”，那就先修评测环境，再调智能体。千万不要在链路没跑通的情况下直接开全量。

小样例还有一个作用：校准判定规则。比如“模型只调用了工具但没有格式化输出”，到底算成功还是失败？这种标准最好在早期就确定，不然批量跑完后统计口径会乱。

4.2 批量任务参数设置建议

批量评测时，最核心的参数是并发数、超时时间、重试次数。

不要一上来就开 30 并发。很多智能体评测系统不是被模型打垮的，而是被 MCP server 打垮的。尤其是第三方工具服务，可能有限流。评测不是为了压测服务，是为了测智能体决策能力，所以应该尽量让环境稳定，而不是制造大量外部错误。

批量任务还要考虑结果文件命名。每条评测用例最好有唯一 ID，报告里展示工具名、用例类型、模型响应、工具调用记录。否则几千条用例堆在一起，根本没法定位问题。

4.3 如何判断评测结果可信

评测结果可信，至少要满足三个条件。

第一，可重复性。同一条用例跑两次，结果应该基本一致。如果同一个 prompt 有时调用工具、有时不调用，要考虑模型温度设置是否太高，或者工具描述不够稳定。

第二，失败原因可解释。失败用例不能只显示“任务失败”，要能看到具体是哪个环节失败。是模型没有生成工具调用，还是调用了错误工具，还是工具调用后返回异常，原因必须区分清楚。

第三，判定标准不被模型带偏。自动合成用例时，如果预期结果也是大模型生成的，要防止模型判定自己生成的内容时过于宽松。关键用例最好加上确定性断言，比如“必须调用 get_weather”“必须包含参数 city”。

我自己踩过的坑是：评测报告显示成功率 95%，结果打开失败用例一看，全是同一个工具描述不清导致的，而其他工具基本没被测到。这就是合成策略不平衡。所以查看结果时，不光要看总分，也要按工具、按用例类型拆开看。

5. 实际落地中的常见坑和排查顺序

这部分是真正容易卡人的地方。很多问题不是智能体能力不够，而是评测环境或者输入数据有问题。

5.1 工具没被调用，先别急着骂模型

评测结果里最常见的现象是：用户问了一个问题，智能体直接回答，没有调用任何工具。

遇到这种情况，先别急着判定模型失败。按下面顺序排查：

1. MCP server 是否已经连接成功。
2. 工具列表是否真的推送给了智能体。
3. 工具描述是否写清楚了触发条件。
4. 用户 prompt 是否与工具描述有明显语义关联。
5. 模型配置里是否禁用了工具调用。

很多时候问题是工具没注册上，或者工具描述太泛，模型根本不知道什么时候该用它。Agent Seer 这类方案的价值，恰好就是通过大量用例暴露这些问题。

5.2 服务连不上与依赖不一致

如果评测过程中频繁出现工具调用报错，不一定是智能体问题，先看服务端。

常见情况包括：

• MCP server 地址配错了。
• 本地端口被占用。
• 请求超时时间太短。
• 服务端更新了接口，但评测环境还在用旧 schema。
• 依赖版本不匹配，比如 MCP client 和 server 使用的协议版本不一致。

排查顺序应该是：先看 MCP server 日志，再看评测执行器日志，最后看模型调用记录。

如果工具本身不稳定，建议先把相关用例隔离开，做好 mock，不要让它污染整体评测结果。

5.3 不要拿高并发来掩盖评测设计问题

有些评测跑得慢，你会想加并发。但慢的原因要先搞清楚。

如果慢是因为模型推理，加并发可能有用。如果慢是因为 MCP server 每次响应都很慢，加并发只会让超时更多。如果慢是因为评测用例里要跑很长的多工具流程，那更要从用例设计上优化。

还有一个容易被忽略的问题是模型上下文长度。工具一旦多了，每次请求都要把工具描述塞进上下文。工具数量超过几十个后，模型可能会漏掉一部分工具，或者选错工具。这时候更值得优化的不是跑得更快，而是工具检索和筛选策略。

评测里暴露出的很多问题，其实指向的是生产环境问题，不只是评测问题。比如工具描述太长、工具命名冲突、多个工具能力重叠，这些都应该被评测报告暴露出来，而不是靠人工去猜。

6. 哪些场景适合用 Agent Seer，哪些场景还得靠人工

Agent Seer 的思路不是万能的。它有非常明确的适用边界。

6.1 适合做回归、接口验证和平台级冒烟

最适合的场景是回归测试。智能体本身没改，但底层模型换了一个版本，或者 MCP server 升级了工具定义，这时候跑一遍自动合成评测，能很快发现工具调用能力有没有退化。

其次适合做 MCP server 接入验证。当你写了一个新的 MCP server，想知道智能体能不能正确理解你暴露的工具，Agent Seer 式评测可以自动生成大量调用用例，验证描述是否清晰、参数是否合理。

再适合的是平台级冒烟测试。Dify、Coze 这类平台也许已经帮你做了可视化流程，但底层接入多个 MCP server 后，仍然需要一套可重复的自动化验证。用 MCP 规范自动合成评测，比手动创建对话测试要高效得多。

6.2 不适合做开放对话体验和复杂安全评估

自动合成评测对“工具调用正确性”很擅长，但对“回答是否自然”“语气是否合适”“是否有创意”这类开放性问题不太擅长。这些指标还是需要人工打分，或者配合专门的模型评估策略。

复杂安全评估也不能完全依赖自动合成。比如涉及恶意 prompt、权限边界、隐私内容识别，这类问题需要专门设计的红队测试。MCP 规范只能告诉评测系统工具有哪些限制，不能保证智能体在复杂场景里一定遵守安全边界。

评测结果只能说明“在这个工具集、这个模型配置、这套 prompt 下，智能体大概率能完成这些任务”，不能说明“在所有场景下都可靠”。

6.3 最终建议

如果你想在自己项目里引入 Agent Seer 这套思路，我建议按三步走。

第一步，先挑一个 MCP server，用单工具参数边界生成几十条用例，跑通评测链路。不要贪多。

第二步，把多工具串联和异常注入加上，跑一轮中等规模批量测试，重点看失败用例集中在哪些环节。

第三步，把评测接入日常开发流程，工具描述有改动时自动触发回归。

真正落地时，最该盯住的不是评测工具本身，而是输入规范是否完整、运行日志是否可追溯、判定规则是否稳定。这三件事做好了，Agent Seer 这类方案才能真正帮你省时间，而不是又多一个需要维护的测试系统。