企业官网建设流程全解析

很多开发者在本地连 MySQL 时都碰到过这样一行报错：public key retrieval is not allowed。第一次看到这个错误，绝大多数人会以为是自己密码写错了，实际上这是数据库服务端要求客户端使用公钥加密传输密码，而 JDBC 驱动默认没有获得“请求公钥”的授权。一行allowPublicKeyRetrieval=true就能解决，但它背后暴露出的问题很值得多想一层：在系统里，不是每个操作都默认可用，安全策略会先于业务逻辑执行。

同样的现象，正在 AI Agent 开发里再次上演。当我们让一个模型去调用工具、查询资料、完成一个需要多步推理的复杂任务时，模型的推理能力不再是唯一决定因素，工具是否允许、检索是否合法、每一步调用是否符合既定策略，都会直接影响最终结果。于是问题变成了：我们该如何评估一个 Agent 在多跳推理、API 调用和检索环节里的真实水平？这正是本文要聊的主题——VAKRA 这类评估方案想解决的问题。

VAKRA（Evaluating Multi-Hop Reasoning Across APIs and Retrieval Under Tool-Use Policies）从命名看，是一个围绕多跳推理、API 调用与检索场景，并把工具使用策略纳入评估口径的评测方案。它关注的不是单个 Prompt 的生成质量，而是模型在复杂任务链路中的整体表现。

这篇文章会从概念讲起，依次拆解多跳推理、工具调用、工具使用策略在评估中的角色，再给出一个可运行的最小评估框架示例，最后整理实际接入和排查时容易踩的坑。如果你正在做 Agent 应用、RAG 系统，或者准备给自己的 AI 应用设计一套效果评估方案，这篇文章值得收藏备用。

1. 这篇文章真正要解决的问题

在讨论 Agent 评测之前，先看一个现实矛盾。

过去两年，基于 LLM 的 Agent 应用大量出现，工具调用（Tool Calling / Function Calling）也成为各家模型的基本能力。很多团队在 Demo 阶段都能跑出漂亮效果：让模型查询订单、检索文档、调用内部服务，看起来一切顺利。可一旦进入生产环境，问题就出现了：查询条件稍微复杂一点，模型第一跳拿错了参数，后面全错；或者模型确实调用了工具，但调用的时机不对、缺少前置步骤；更常见的是，模型调用了策略上不允许的工具，比如在“只读”场景里尝试触发写操作。

这些问题的共性是：我们缺少一种能同时评估“推理正确性”和“行为合规性”的方法。传统的评测大多只看最终答案对不对，中间调用了什么工具、检索了什么内容、是否遵守策略，全部被忽略。

这就是 VAKRA 这类评估方案的价值所在。它是面向多跳推理场景的、带有工具使用策略约束的评测口径。与其说它是一套新 benchmark，不如说它提供了一种更接近真实业务的评估思路。

对读者来说，这篇文章能带来几个直接收益。首先，清晰理解多跳推理、工具调用、工具使用策略这三个概念之间的边界与关系；其次，掌握一个不依赖特定厂商 API 的评估框架设计思路；第三，在自己的项目中落地一套最小可用的 Agent 效果评估流程。明白了这几个点，你再去看各种 Agent 评测榜单时，就不容易只被“准确率”一个数字牵着走。

接下来的内容不追求复现 VAKRA 的完整论文实现，而是把它的评估思想拆成可以动手实践的工程方案。先理解原理，再动手实现，最后解决生产中的真实问题，这条路径对大多数开发者更友好。

2. 三个基础概念：多跳推理、工具调用与工具使用策略

2.1 什么是多跳推理

多跳推理（Multi-Hop Reasoning）指的是：一个任务无法通过一次查询或一次推理完成，需要模型基于前一步的结果继续推理，形成一条推理链。它是 Agent 应用中最常见、也最容易出问题的能力形态。

用一个客服场景举例。用户问“上周李小明下单的那个订单发货了没有”。这句话包含三个隐含步骤：先根据“李小明”查询用户信息；再根据用户 ID 查询订单；最后根据订单号查询发货状态。每一步都依赖上一步的输出，任何一步出错，最终答案都会错。这就是“多跳”。

没有多跳能力时，我们通常会把上面三个步骤写成硬编码的串行调用，也就是传统程序里的流程编排。有了 LLM 之后，我们希望模型自己决定下一步做什么。但模型自由决策也带来了新问题：推理链不可控，错误会沿着链条向后传播。比如第一跳拿到一个错误用户 ID，后续所有查询都会建立在错误基础上。这也是为什么评估不能只看最终答案，必须把中间步骤纳入观测范围。

2.2 什么是工具调用与检索

工具调用（Tool Use / Function Calling）是模型按照结构化 Schema 选择并调用外部函数的能力。在 OpenAI、Anthropic 以及各类开源模型中，工具调用都有各自的协议形式，但本质是一致的：模型输出一个结构化的调用意图，由应用层去执行真实 API。比如模型输出“调用 get_user_id 函数，参数是李小明”，应用层再真正执行这个查询。

检索（Retrieval）则是指从外部知识库、文档库或索引中查找到相关片段。检索与 API 调用的区别在于，API 调用通常是确定性的业务动作，比如创建订单、查询余额；检索更像是从信息海洋中挑选证据，比如从退款政策文档中找到适用于当前用户的那一条。实际场景里，RAG（检索增强生成）就是把检索结果作为上下文交给 LLM 作答。

为什么要区分这两个概念？因为在多跳任务里，检索和 API 调用经常交替出现。比如第一跳需要从文档中检索出“哪些订单可以退款”，第二跳再调用订单 API 去判断当前订单是否命中条件。这种混合链路对评估框架提出更高要求：既要评估检索相关性，也要评估 API 调用参数正确性，两者不能混为一谈。

2.3 什么是工具使用策略

工具使用策略（Tool-Use Policies）定义的是“什么工具在什么条件下可以被调用”。这是真实系统里的第一道门，也是 VAKRA 与其他测评方案差异最大的地方。

举个例子，在一个客服系统里：只读操作允许直接调用；写操作需要登录态与权限校验；退款操作必须经过二次确认；某些内部服务只允许在指定环境调用。这些约束不是模型自己决定的，而是系统管理员预先定义的策略。public key retrieval is not allowed这个报错就是策略的一种体现：数据库认为客户端不应该随意获取公钥，除非显式授权。

对 Agent 评测来说，策略合规必须成为评估维度。否则，一个模型即使推理再强，只要它习惯性地绕过策略，就不能上线。这里可以把几个概念之间的关系用表格串起来，方便对照记忆：

这张表格会在后面的评估器实现里反复用到。理解这几个概念的边界，是读懂 VAKRA 的前提。

3. VAKRA 的定位：它究竟在评估什么

从标题 VAKRA: Evaluating Multi-Hop Reasoning Across APIs and Retrieval Under Tool-Use Policies 可以拆出三个关键词：Multi-Hop Reasoning 代表“能力”维度，APIs and Retrieval 代表“交互”维度，Tool-Use Policies 代表“约束”维度。一个完整的 Agent 评估，应该让这三个维度同时被观测到，而不是只测某一个。

现在很多工具调用评测，实际上只测了“单跳工具选择”：给一个问题，给一个工具列表，看模型能不能选对工具并填好参数。这种评测对真实场景来说太单薄。真实任务往往需要先检索、再调用、再根据结果二次检索，而且每一步都受策略约束。VAKRA 这类方案把注意力放在：模型在一个带约束的多步环境里，能否完成正确推理。

VAKRA 的思路可以概括为：构造任务时，先设置一个包含多个推理步骤的目标，再给模型提供一套工具集合和一个检索库，同时用策略文件约束哪些工具可以被调用。模型需要在这种环境下自主完成任务。评估时不仅要看最终答案是否命中，还要看推理链是否合理、工具调用是否符合策略、检索内容是否为推理提供了真实支撑。

这种设计有四个特点。第一是场景真实，多跳推理加工具调用已经是真实 Agent 应用的主流形态；第二是可量化，每个维度都可以单独打分，便于定位问题；第三是可扩展，工具集、检索库、策略都可以按业务替换；第四是关注约束，把策略合规纳入得分，而不是只奖励结果正确。

更稳妥的判断是：VAKRA 的侧重点并不是用一个大模型去生成更聪明的推理，而是把“推理过程”和“策略约束”放进同一个评估框架里，让开发者能看清模型在复杂任务里到底卡在哪一环。这一点对工程实践尤其重要——因为生产环境里出现的大部分 Agent 事故，不是因为模型不够聪明，而是因为它在某个不该调用工具的节点上越权了。

4. 一个典型的多跳工具调用评估任务拆解

用一个客服场景举例。任务背景：一个客服 Agent 需要查询订单的发货状态。

工具集合：

• get_user_id(username)：根据用户名查询用户 ID；
• list_orders(user_id)：查询用户订单列表；
• get_shipment_status(order_id)：查询订单发货状态；
• refund(order_id)：发起退款，高风险操作。

策略配置：

• get_user_id、list_orders、get_shipment_status允许调用；
• refund只有在“用户申请退款且管理员确认”条件下才允许，普通评估任务中应禁止。

目标问题：用户问“李小明最近的订单发货了吗”。

一个完整且合规的推理链应该长这样：

1. 调用get_user_id("李小明")，得到user_id=U1001；
2. 调用list_orders("U1001")，得到最近订单order_id=O20240501；
3. 调用get_shipment_status("O20240501")，得到已发货。

这条链路里，任一步骤失败或跳步，都会导致最终结果错误。如果模型在第二步直接尝试调用refund，策略评估应该直接判负。

一个合格的评估器，要能自动判断五件事：推理链是否完整；每一步的工具选择是否正确；工具参数是否合法；是否违反策略；最终答案是否正确。这五件事里，前四件都指向“过程”，只有最后一件指向“结果”。

这里还要注意一个容易忽略的细节：检索与调用的顺序。模型不能先调用get_shipment_status，因为它是根据订单号查询的，而订单号来自list_orders的结果。如果模型跳过前两步直接猜一个订单号，即使 API 调用成功、最终答案也碰巧正确，推理链依然是不合理的。这种“答案对但过程错”的情况，正是传统评测最不容易发现的问题。

5. 最小化评估框架：Python 实现示例

下面给出一个接近 VAKRA 思路的最小评估框架。它不依赖外部 API，只用一个 Python 脚本就能跑通，方便你理解评估逻辑；理解了之后，再把工具集合、检索库和策略替换成自己业务的。

5.1 定义工具与策略

首先定义工具集合和策略配置。这里用 Python 字典模拟工具注册表，实际工程中可能会用 JSON Schema 或接口元数据，但结构是相通的。

# 文件路径：agent_eval/tools.py # 模拟一个多跳检索 + 工具调用环境的工具与策略定义 TOOLS = { "get_user_id": { "description": "根据用户名查询用户ID", "params": ["username"], }, "list_orders": { "description": "根据用户ID查询订单列表", "params": ["user_id"], }, "get_shipment_status": { "description": "根据订单ID查询发货状态", "params": ["order_id"], }, "refund": { "description": "发起退款操作", "params": ["order_id"], }, } # 工具使用策略定义 TOOL_POLICIES = { # 允许调用的工具 "allow": ["get_user_id", "list_orders", "get_shipment_status"], # 禁止调用的工具，模拟高风险操作 "deny": ["refund"], } def is_tool_allowed(tool_name: str) -> bool: if tool_name in TOOL_POLICIES["deny"]: return False return tool_name in TOOL_POLICIES["allow"] or tool_name in TOOLS

这段代码里，TOOLS是工具注册表，TOOL_POLICIES是策略。is_tool_allowed函数用于判断某个工具是否在当前策略下被允许调用。设计上，deny名单的优先级高于allow，因为安全场景下默认应该是“未明确允许即拒绝”，而不是“未明确禁止即放行”。这一点在实际生产环境非常重要。

5.2 编写评估器

评估器的职责是接收模型生成的一条推理轨迹（trace），逐步骤检查策略合规性和工具调用质量。

# 文件路径：agent_eval/evaluator.py from typing import List, Dict class AgentEvaluator: def __init__(self, tools: Dict, policies: Dict): self.tools = tools self.policies = policies def check_policy(self, tool_name: str) -> bool: if tool_name in self.policies.get("deny", []): return False return tool_name in self.tools def evaluate_trace(self, trace: List[Dict]) -> Dict: steps_ok = 0 policy_violations = [] for step in trace: tool_name = step.get("tool") # 工具是否存在且策略是否允许 if not self.check_policy(tool_name): policy_violations.append(step) else: steps_ok += 1 return { "trace_len": len(trace), "steps_ok": steps_ok, "policy_viol