智能体AI验证框架：让大模型Agent从不确定走向可信

在真实业务里引入大模型驱动的智能体（Agent）之后，我最直观的感受是：模型能力很强，但“不可信”的问题被放大了。一个智能体可能自己规划步骤、调用多个工具、生成新一轮指令，一旦某个环节出现幻觉或错误，整条链路都会偏离预期。网上关于 Agent 的文章大多在讲“怎么让模型更聪明”，却很少讲“怎么证明它这次没做错”。本文围绕“Only believe what you can validate”这一原则，梳理一套轻量级验证框架（verification framework）的搭建思路，覆盖核心概念、数据结构、验证器实现、与运行链路集成的完整代码，以及工程落地时的常见坑点，适合正在开发 Agent 应用的后端工程师、算法工程师和测试开发同学参考。

1. 为什么我们需要验证智能体 AI

1.1 智能体 AI 与传统程序的区别

传统程序是“确定的”：输入相同，执行路径基本固定，每一步可以通过单元测试覆盖。智能体 AI（agentic AI）则不同，它通常由大语言模型驱动，能够自主拆解任务、选择工具、编排执行顺序，并根据中间结果动态调整后续动作。这里的核心问题在于：模型生成的动作序列不是枚举出来的，而是概率采样出来的。这意味着同样的用户请求，两次执行可能调用不同的工具，甚至得到不同的结论。

这种能力给产品带来很大的想象空间，但同时也把不确定性带入了核心链路。如果不能对 Agent 的动作、参数、上下文、输出结果做验证，生产环境里出现的就不仅是 bug，而是不可控的行为。

1.2 智能体常见的失败模式

在落地 Agent 应用时，我会把失败大致分成四类：

这些失败模式并不互斥，一次执行可能同时踩中多个坑。它们与传统 Bug 的本质差异是：你很难通过“修复代码”一次性解决，因为同样的代码下一次可能生成不同的行为。唯一可靠的办法是建立一套机制，在 Agent 运行的每个关键节点采集证据，并基于证据做自动化判断。

1.3 能验证的才是能相信的

“Only believe what you can validate”是一句很直接的方法论：在 Agent 系统里，我们不应该无条件相信模型的输出，而应该只相信那些经过了验证、并且能拿出证据的内容。所谓验证，不是简单判断“答案是否非空”，而是把 Agent 的规划、工具调用、中间状态、最终输出全部纳入检查范围。

验证框架要回答的问题包括：

• Agent 是否按照预期完成了任务？
• 使用的工具和参数是否在允许范围内？
• 动作序列是否有异常循环或成本超限？
• 最终输出是否符合用户要求的格式和语义？
• 当验证不通过时，系统是否具备阻断和降级能力？

这篇文章要实现的，正是一个能回答上述问题的最小验证框架。

2. 验证框架的设计思路

2.1 核心设计目标

在设计验证框架之前，我定义了四个目标，后续所有模块都围绕它们展开。

第一是可观测性。框架必须能记录 Agent 每一步的关键信息，包括模型输入、模型输出、工具调用、返回值、耗时等。没有完整的轨迹，验证就是空谈。

第二是可验证性。所有检查项都以规则或函数的形式存在，输入是轨迹数据，输出是“通过/警告/阻断”的结论，并且结论必须保留判断依据。

第三是可阻断性。验证框架不能只做“事后分析”，而是在 Agent 运行过程中具备拦截能力，一旦命中高危规则，可以中断执行或进入人工审批。

第四是可扩展性。Agent 的业务场景差异巨大，验证规则不能写死在框架里，应当支持注册、组合、策略配置。

2.2 验证流程的节点

Agent 运行链路通常包含规划、工具调用、结果处理、输出生成几个阶段。验证框架应该贯穿其中，而不是只在最后验证一次。

• 规划验证：在 Agent 生成计划后检查步骤是否合法、是否有重复步骤、是否需要额外信息。
• 执行前验证：在调用工具前，验证工具名、参数、权限边界。
• 执行后验证：在工具返回后，检查返回值格式、错误码、数据范围。
• 最终输出验证：对生成给用户的最终回答做格式、关键词、语义一致性校验。

在框架实现中，我们并不要求每个 Agent 都接入所有节点，而是提供统一的验证入口，业务侧按需调用。

2.3 验证规则类型的划分

根据业务需要，我把验证规则分为四类。

第一类是参数约束规则，例如“工具参数中 limit 必须小于 100”“时间范围不能超过 30 天”。这类规则最容易实现，也可以直接复用传统的参数校验逻辑。

第二类是行为边界规则，例如“不允许调用删除数据库的工具”“不允许访问内网 IP”“所有读取操作必须带上租户 ID”。这类规则直接关系安全，建议默认开启。

第三类是输出质量规则，例如“回答必须包含数据来源”“回答长度在 200 字以内”“关键指标必须使用数字”。这类规则通常需要结合模型能力或正则表达式完成。

第四类是资源限制规则，例如“单次任务最多调用 10 次工具”“执行时间不能超过 60 秒”“批量导出最大行数不能超过 10000”。这类规则防止 Agent 进入失控循环。

2.4 验证框架的模块划分

基于上面的目标，我将验证框架拆成四个核心模块：

• 数据模型模块：定义 Agent 轨迹、工具调用、验证结果等数据结构。
• 验证器模块：提供验证器注册机制和执行逻辑。
• 规则库模块：根据业务场景组合各种规则。
• 决策模块：汇总所有验证结论，输出最终动作（允许、警告、阻断）。

下面进入代码实现。

3. 环境准备与项目结构

3.1 运行环境

为了降低入门成本，本文示例不依赖第三方库，使用 Python 3.10 标准库实现，具体版本需结合你的实际环境调整。如果你使用 Python 3.8 或 3.9，可以把dataclass和typing的写法稍作调整；如果使用 Python 3.12，则可以直接运行。

3.2 项目结构

示例项目结构如下：

verify-agentic/ ├── agentic_verify/ │ ├── __init__.py │ ├── models.py # 数据结构定义 │ ├── validators.py # 验证器基类与注册机制 │ ├── rules.py # 内置规则实现 │ └── framework.py # 验证框架核心 ├── example_agent.py # 模拟智能体调用演示 └── README.md

我们将按顺序逐个文件实现。

4. 核心验证器实现

4.1 定义验证结果与轨迹结构

先建立数据模型。AgentTrace描述一次 Agent 执行过程中的关键信息，ToolCall描述一次工具调用，VerificationResult描述一条验证结果。

文件路径：agentic_verify/models.py

from __future__ import annotations from dataclasses import dataclass, field from typing import Any, Dict, List, Optional @dataclass class ToolCall: """一次工具调用的记录。""" tool_name: str arguments: Dict[str, Any] result: Optional[Any] = None error: Optional[str] = None start_time: Optional[float] = None end_time: Optional[float] = None def duration(self) -> Optional[float]: if self.start_time is not None and self.end_time is not None: return self.end_time - self.start_time return None @dataclass class AgentTrace: """Agent 执行轨迹。""" task_id: str user_query: str plan: List[str] = field(default_factory=list) tool_calls: List[ToolCall] = field(default_factory=list) final_answer: Optional[str] = None metadata: Dict[str, Any] = field(default_factory=dict) def add_tool_call(self, tool_call: ToolCall) -> None: self.tool_calls.append(tool_call) def count_tool_calls(self, tool_name: Optional[str] = None) -> int: if tool_name is None: return len(self.tool_calls) return sum(1 for call in self.tool_calls if call.tool_name == tool_name) @dataclass class VerificationResult: """单条验证结果。""" rule_name: str passed: bool severity: str # allow / warn / block message: str evidence: Dict[str, Any] = field(default_factory=dict)

这些类的作用是统一轨迹和结果的结构。你在实际项目中，可以把AgentTrace替换为真实 Agent 框架内部的数据格式，但核心字段建议保持一致，尤其是plan、tool_calls、final_answer这三个字段。

4.2 实现验证器基类与注册机制

验证器是验证框架的最小执行单元。每个验证器只负责一件事，比如“检查工具调用次数”“检查参数范围”。验证器需要支持注册，这样业务侧可以灵活添加自定义规则。

文件路径：agentic_verify/validators.py

from __future__ import annotations from abc import ABC, abstractmethod from typing import Callable, Dict, List from .models import AgentTrace, VerificationResult class BaseValidator(ABC): """验证器基类。""" name: str = "base_validator" def __init__(self, severity: str = "block"): self.severity = severity @abstractmethod def validate(self, trace: AgentTrace) -> VerificationResult: """执行验证，返回验证结果。""" raise NotImplementedError class FunctionValidator(BaseValidator): """基于普通函数的验证器，适用于简单规则。""" def __init__( self, name: str, func: Callable[[AgentTrace], VerificationResult], severity: str = "block", ): super().__init__(severity) self.name = name self._func = func def validate(self, trace: AgentTrace) -> VerificationResult: return self._func(trace) class ValidatorRegistry: """验证器注册表。""" def __init__(self) -> None: self._validators: Dict[str, BaseValidator] = {} def register(self, validator: BaseValidator) -> None: if validator.name in self._validators: raise ValueError(f"validator {validator.name} already registered") self._validators[validator.name] = validator def unregister(self, name: str) -> None: self._validators.pop(name, None) def get(self, name: str) -> BaseValidator: if name not in self._validators: raise KeyError(f"validator {name} not found") return self._validators[name] def list_validators(self) -> List[str]: return list(self._validators.keys()) def run_all(self, trace: AgentTrace) -> List[VerificationResult]: results = [] for name in self._validators: validator = self._validators[name] try: result = validator.validate(trace) except Exception as exc: # 防止单个验证器拖垮整体 result = VerificationResult( rule_name=name, passed=False, severity="block", message=f"validator raised exception: {exc}", evidence={"error": str(exc)}, ) results.append(result) return results

这里有两个设计点值得注意。

第一，BaseValidator抽象类的存在是为了让验证器具备统一接口。FunctionValidator则降低了自定义规则的成本，很多时候我们只需要写一个函数。

第二，注册表的run_all方法将每个验证器的异常包装成失败结果，而不是直接抛出异常。这样即使某个规则写错了，也不会影响其他规则的判定，便于问题定位。

4.3 实现规则库

接下来实现具体规则。为了展示通用性，我设计了四个覆盖不同维度的规则。

文件路径：agentic_verify/rules.py

from __future__ import annotations import re from typing import Any, Dict, List, Optional from .models import AgentTrace, VerificationResult def rule_max_tool_calls(max_calls: int = 10, severity: str = "block"): """ 规则：单次任务工具调用总次数不能超过 max_calls。 用于避免 Agent 陷入长循环。 """ def _validate(trace: AgentTrace) -> VerificationResult: total = trace.count_tool_calls() passed = total <= max_calls return VerificationResult( rule_name="max_tool_calls", passed=passed, severity=severity, message=f"tool call count = {total}, limit = {max_calls}", evidence={"total_calls": total, "limit": max_calls}, ) return _validate def rule_disallow_tools(disallowed_tools: List[str], severity: str = "block"): """ 规则：禁止调用指定的高风险工具。 例如 delete_database, drop_table, send_email 等。 """ def _validate(trace: AgentTrace) -> VerificationResult: used_disallowed = [] for call in trace.tool_calls: if call.tool_name in disallowed_tools: used_disallowed.append( { "tool_name": call.tool_name, "arguments": call.arguments, } ) passed = len(used_disallowed) == 0 return VerificationResult( rule_name="disallow_tools", passed=passed, severity=severity, message=f"disallowed tools used: {used_disallowed}", evidence={"disallowed_calls": used_disallowed}, ) return _validate def rule_tool_argument_bounds( tool_name: str, param_name: str, min_value: Optional[float] = None, max_value: Optional[float] = None, severity: str = "block", ): """ 规则：指定工具的某个数值参数必须在边界内。 例如 search 的 top_k 不超过 20。 """ def _validate(trace: AgentTrace) -> VerificationResult: invalid_calls = [] for call in trace.tool_calls: if call.tool_name != tool_name: continue value = call.arguments.get(param_name) if value is None: # 参数缺失也可以视为不通过，这里根据业务决定 invalid_calls.append( { "index": trace.tool_calls.index(call), "reason": f"missing parameter: {param_name}", } ) continue if min_value is not None and value < min_value: invalid_calls.append( { "index": trace.tool_calls.index(call), "reason": f"{param_name}={value} < {min_value}", } ) if max_value is not None and value > max_value: invalid_calls.append( { "index": trace.tool_calls.index(call), "reason": f"{param_name}={value} > {max_value}", } ) passed = len(invalid_calls) == 0 return VerificationResult( rule_name=f"tool_argument_bounds_{tool_name}_{param_name}", passed=passed, severity=severity, message=f"invalid calls: {invalid_calls}", evidence={"invalid_calls": invalid_calls}, ) return _validate def rule_final_answer_contains( keywords: List[str], severity: str = "warn", ): """ 规则：最终回答必须包含指定关键词。 例如要求答案中必须包含"数据来源"或"建议"。 """ def _validate(trace: AgentTrace) -> VerificationResult: answer = trace.final_answer or "" missing = [k for k in keywords if k not in answer] passed = len(missing) == 0 return VerificationResult( rule_name="final_answer_contains", passed=passed, severity=severity, message=f"missing keywords: {missing}", evidence={"missing_keywords": missing}, ) return _validate def rule_final_answer_json(severity: str = "block"): """ 规则：最终回答必须是合法 JSON。 适用于 Agent 需要输出结构化结果的场景。 """ import json def _validate(trace: AgentTrace) -> VerificationResult: answer = trace.final_answer or "" try: json.loads(answer) passed = True message = "final answer is valid JSON" except json.JSONDecodeError as exc: passed = False message = f"final answer is invalid JSON: {exc}" return VerificationResult( rule_name="final_answer_json", passed=passed, severity=severity, message=message, evidence={"answer_preview": answer[:200]}, ) return _validate def build_default_rules() -> Dict[str, Any]: """ 构建一组默认规则，方便快速接入。 """ return { "max_tool_calls": rule_max_tool_calls(max_calls=10, severity="block"), "disallow_tools": rule_disallow_tools( disallowed_tools=["delete_database", "drop_table", "send_mass_mail"], severity="block", ), "tool_argument_bounds_search_top_k": rule_tool_argument_bounds( tool_name="search", param_name="top_k", min_value=1, max_value=20, severity="warn", ), "final_answer_contains_source": rule_final_answer_contains( keywords=["数据来源"], severity="warn", ), "final_answer_json": rule_final_answer_json(severity="block"), }

在实际项目中，规则函数可以通过配置动态加载。这里使用函数闭包是为了让代码更直观，每个函数返回一个接收AgentTrace的验证函数，与FunctionValidator配合使用。

4.4 实现验证框架核心

Framework类负责协调验证器和规则，并给出最终决策。

文件路径：agentic_verify/framework.py

from __future__ import annotations from typing import List from .models import AgentTrace, VerificationResult from .validators import FunctionValidator, ValidatorRegistry class VerificationFramework: """ 智能体验证框架核心。 负责注册规则、执行验证、汇总结果并生成决策。 """ def __init__(self): self.registry = ValidatorRegistry() def add_function_rule(self, name: str, func, severity: str = "block") -> None: validator = FunctionValidator(name=name, func=func, severity=severity) self.registry.register(validator) def add_rule_from_dict(self, rule_name: str, rule_func, severity: str) -> None: """ 从规则函数创建验证器并注册。 这里额外包一层，可以接入更多配置逻辑，例如灰度开关。 """ self.add_function_rule(rule_name, rule_func, severity) def verify(self, trace: AgentTrace) -> List[VerificationResult]: """执行所有验证器，返回验证结果列表。""" return self.registry.run_all(trace) def decide(self, results: List[VerificationResult]) -> str: """ 汇总验证结果，输出最终决策。 优先级：block > warn > allow。 """ if any(r.severity == "block" and not r.passed for r in results): return "block" if any(r.severity == "warn" and not r.passed for r in results): return "warn" return "allow" def verify_and_decide(self, trace: AgentTrace): """ 执行验证并返回决策，同时保留详细结果。 """ results = self.verify(trace) decision = self.decide(results) return decision, results def report(self, trace: AgentTrace, results: List[VerificationResult]) -> str: """生成人类可读的验证报告，方便排查。""" lines = [ f"Task: {trace.task_id}", f"Query: {trace.user_query}", f"Decision: {self.decide(results)}", "--- Validation Results ---", ] for r in results: status = "PASS" if r.passed else "FAIL" lines.append( f"[{status}] {r.rule_name} | severity={r.severity} | {r.message}" ) return "\n".join(lines)

这里的decide方法使用“一票否决”策略：只要存在block级别失败，就阻断执行；否则如果有warn级别失败，则返回警告；全部通过才允许继续。你可以在业务中改成“投票通过”或“白名单策略”。

5. 与智能体运行链路的集成

5.1 模拟智能体调用

为了演示完整流程，这里编写一个简单的模拟智能体。它会接收用户提问，生成计划，然后“调用”几个工具。实际项目中，这些步骤应该由你的 Agent 编排框架（如 LangChain、AutoGen 或自研框架）完成，但验证思路一致。

文件路径：example_agent.py

from __future__ import annotations import time from agentic_verify.framework import VerificationFramework from agentic_verify.models import AgentTrace, ToolCall from agentic_verify.rules import build_default_rules def fake_llm_plan(user_query: str) -> list[str]: """ 模拟 LLM 生成计划。 正常项目这里应该调用真实模型接口，例如 OpenAI、通义千问、ChatGLM 等。 """ if "业绩" in user_query: return ["search_database", "calculate_growth", "generate_report"] return ["search", "generate_report"] def fake_llm_final_answer(trace: AgentTrace) -> str: """ 模拟 LLM 生成最终回答。 """ growth_values = [] for call in trace.tool_calls: if call.tool_name == "calculate_growth": growth_values.append(call.result) if growth_values: return "本季度业绩同比增长 15%，主要原因是新客户增长。数据来源：销售数据表。" return "没有找到相关数据。数据来源：未获取。" def fake_execute_tool(tool_name: str, arguments: dict): """ 模拟工具执行。 """ if tool_name == "search": top_k = arguments.get("top_k", 10) return [{"id": i, "title": f"result {i}"} for i in range(top_k)] if tool_name == "search_database": return [{"month": "2024-01", "revenue": 120}, {"month": "2024-02", "revenue": 138}] if tool_name == "calculate_growth": return 0.15 if tool_name == "generate_report": return "report generated" raise ValueError(f"unknown tool: {tool_name}") def run_agent_with_verification(): # 1. 初始化验证框架并注册默认规则 framework = VerificationFramework() default_rules = build_default_rules() for rule_name, rule_func in default_rules.items(): # 默认使用 block 级别，演示时对 warning 类规则单独设定 severity = "block" if "top_k" in rule_name or "final_answer_contains" in rule_name: severity = "warn" framework.add_rule_from_dict(rule_name, rule_func, severity) # 2. 构造一条用户请求，并模拟 Agent 执行 task_id = "task-001" user_query = "查询本季度业绩同比增长情况，并生成 JSON 报告" trace = AgentTrace(task_id=task_id, user_query=user_query) trace.plan = fake_llm_plan(user_query) # 3. 模拟工具调用 call1 = ToolCall( tool_name="search_database", arguments={"table": "sales", "period": "2024Q1"}, start_time=time.time(), ) call1.result = fake_execute_tool(call1.tool_name, call1.arguments) call1.end_time = time.time() trace.add_tool_call(call1) call2 = ToolCall( tool_name="calculate_growth", arguments={"metric": "revenue_yoy"}, start_time=time.time(), ) call2.result = fake_execute_tool(call2.tool_name, call2.arguments) call2.end_time = time.time() trace.add_tool_call(call2) call3 = ToolCall( tool_name="search", arguments={"query": "业内增长案例", "top_k": 50}, # 故意超过边界 start_time=time.time(), ) call3.result = fake_execute_tool(call3.tool_name, call3.arguments) call3.end_time = time.time() trace.add_tool_call(call3) # 4. 最终回答 trace.final_answer = fake_llm_final_answer(trace) # 5. 执行验证 decision, results = framework.verify_and_decide(trace) print(framework.report(trace, results)) print(f"\nFinal Decision: {decision}") # 6. 业务侧根据决策决定是否继续交付结果 if decision == "block": print("已被验证框架阻断，禁止继续执行。") elif decision == "warn": print("存在警告，建议人工复核后下发。") else: print("验证通过，可正常返回结果。") if __name__ == "__main__": run_agent_with_verification()

在这个模拟示例中，我们故意构造了一个top_k=50的工具调用，用来触发警告规则。同时最终回答是合法 JSON 吗？其实不是。fake_llm_final_answer返回的是普通文本，因此会触发final_answer_json阻断规则，最终决策为block。

这说明验证框架在真实场景中非常严格：一旦 Agent 没有按约定输出结构化结果，就会被拦截。

5.2 在真实 Agent 链路中接入验证

如果你使用自研 Agent 框架，可以在每个关键函数增加如下逻辑：

• 在agent.execute_step(action)之前，先调用framework.verify_and_decide(trace)。
• 如果决策为block，直接抛出AgentVerificationError并终止任务。
• 如果决策为warn，将结果标记为needs_review，进入人工审核队列。
• 每次执行工具后，把结果写入trace.tool_calls，并再次触发验证。

这种“每步一验”的方式比“最终一验”更安全，但会增加一些性能开销。建议对高成本、高风险动作做执行前验证，对普通动作做执行后验证。

6. 运行验证与结果分析

6.1 运行方式

在项目根目录执行：

cd verify-agentic python example_agent.py

由于示例使用标准库且无第三方依赖，你可以直接运行。如果你使用虚拟环境，请先激活环境。

6.2 预期输出

运行后，你会看到类似下面的输出：

Task: task-001 Query: 查询本季度业绩同比增长情况，并生成 JSON 报告 Decision: block --- Validation Results --- [PASS] max_tool_calls | severity=block | tool call count = 3, limit = 10 [PASS] disallow_tools | severity=block | disallowed tools used: [] [WARN] tool_argument_bounds_search_top_k | severity=warn | invalid calls: [{'index': 2, 'reason': 'top_k=50 > 20'}] [PASS] final_answer_contains_source | severity=warn | missing keywords: [] [FAIL] final_answer_json | severity=block | final answer is invalid JSON: Expecting value: line 1 column 1 (char 0) Final Decision: block 已被验证框架阻断，禁止继续执行。

这条输出非常有价值，它清晰地告诉我们三件事：

1. Agent 的工具调用数量正常，没有循环。
2. 没有使用高风险工具。
3. search工具参数top_k=50超出边界，触发了警告。
4. 最终回答不是 JSON，触发了阻断。

如果没有验证框架，这个错误会直接流向业务侧，用户会收到一段不符合合约的数据，进而导致前端解析失败。

6.3 结果解读

Decision: block表示本次 Agent 运行不能交付，需要返工修复或人工介入。在实际项目中，“block”不一定代表 Agent 行为非法，也可能代表输出格式不满足契约。因此，规则严重级别的配置需要结合业务容忍度，避免把“警告级”问题升级成“阻断级”。

7. 常见问题与排查思路

7.1 常见问题汇总

7.2 排查步骤

如果验证结果不符合预期，建议按以下顺序排查：

第一步，确认轨迹完整性。打印trace对象，检查plan、tool_calls、final_answer是否都被正确填充。

第二步，确认规则配置。查看每个规则的severity是否与预期一致，是否误把warn写成了block。

第三步，单独执行规则。从run_all结果中挑选 FAIL 的规则，在单元测试里单独调用，确认是规则逻辑问题还是 Agent 行为问题。

第四步，检查规则函数本身。如果规则函数抛异常，框架会将其包装成 FAIL，并附带错误信息。优先查看evidence中的error字段。

第五步，回归测试。把规则和 Agent 行为固化为测试用例，每次修改规则后执行全量回归。

7.3 如何避免误报

误报是验证框架落地时最大的阻力之一。如果规则过于严格，业务方会频繁绕过框架，最终导致框架形同虚设。

降低误报的方法有三个：

• 用“警告”代替“阻断”。对于不涉及安全、资金、隐私的规则，先使用warn级别。
• 增加人工复核通道。当warn命中时，允许人工审核后继续执行。
• 定期分析历史命中数据，调整阈值。例如top_k限制为 20 如果太频繁误伤，可以调成 50，但需要同步评估资源成本。

8. 工程化最佳实践

8.1 从第一步就接入验证

很多 Agent 项目是在上线后才开始补验证，但这种验证往往只能覆盖最终输出，无法还原中间决策过程。更推荐的方式是在 Agent 框架内部预留验证入口，从第一个工具调用开始记录轨迹。这样即使后续出问题，也有完整的证据链可以回放。

8.2 验证与轨迹必须深度绑定

验证框架的价值不只在于“拦截”，更在于“留痕”。每次验证结果都应该关联到具体的任务 ID、Agent 版本、LLM 版本、Prompt 版本和工具版本。否则，当一条规则从“历史通过”变成“突然失败”，你将很难定位是模型升级导致的，还是数据变化导致的。

我建议在AgentTrace.metadata中记录这些版本信息，并在验证报告里一并输出。

8.3 制定分级策略

不要把验证结果简单分为“通过”和“不通过”。更实用的分级策略是：

• allow：继续执行或交付。
• warn：继续执行，但标记为需要人工关注。
• block：停止执行，返回固定错误信息。
• review：进入人工审核队列，审核通过后才能继续。

这四种状态可以映射到你现有的工单系统或审批流中。

8.4 权限与安全考虑

Agent 验证框架本身不负责权限控制，但它可以作为权限控制的前置关卡。例如，当 Agent 尝试调用一个高权限工具时，验证框架可以先判断该 Agent 是否有权调用，再判断参数是否在允许范围内。

这里需要强调：验证框架不能替代身份认证和资源授权，它只是把“不该发生的事”尽可能在早期拦截下来。生产环境中的认证、授权、审计仍然要由专门的系统负责。

8.5 持续回归测试

智能体的行为是概率性的，因此验证规则的回归测试比传统程序更复杂。我们需要准备三类测试数据：

• 正向样本：Agent 正常完成任务的轨迹，验证结果应全通过。
• 负向样本：Agent 故意触发了危险动作的轨迹，验证结果应阻断。
• 边界样本：工具参数刚好在阈值上下，验证结果应与约定一致。

每调整一次规则，就运行一次全量回归，避免修了一个误报又制造了新的漏报。

8.6 保持验证框架轻量

验证框架不应过度设计。如果你为每个动作都设计五个验证器，开发成本和运行开销都会上升。我更推荐从安全红线和输出契约开始验证，比如：

• 禁止调用高风险工具；
• 禁止访问敏感资源；
• 强制输出 JSON；
• 控制最大工具调用次数。

随着业务稳定，再逐步增加语义校验、质量评分、成本预估等高级规则。

总结与下一步

本文围绕 “Only believe what you can validate” 这条原则，实现了一个轻量的智能体 AI 验证框架。我们从 Agent 失败模式出发，设计了以轨迹为核心的数据模型，实现了验证器注册机制、内置规则库和最终决策模块，并通过一个模拟 Agent 完成了从规划、调用工具到输出回答的验证演示。整条流程不依赖外部框架，方便你快速嵌入到现有 Agent 链路中。

下一步建议你先画出自己业务里的“高风险动作清单”，把最危险的三到五个工具调用纳入验证框架，再逐步扩展到输出约束和成本控制。验证框架不是一次建设就能完成的，它应该和 Agent 应用一起持续演进。如果本文对你有帮助，可以收藏备用，后续在真实项目里遇到验证规则设计问题时，再回来对照落地。