在 agentic AI 项目中验证框架不是锦上添花的组件而是决定系统能否进入生产环境的底线。所谓 agentic AI指的不再是单轮问答而是具备规划、调用工具、读取外部结果并继续决策的智能体系统。这类系统一旦开始操作真实 API、数据库或文件系统模型输出里的格式错误、幻觉参数和越权动作就会从“小问题”变成真实事故。只相信你能验证的——这句话看起来像一句保守口号但它准确描述了 Agent 系统应该遵循的设计原则不能默认模型输出可信而是要对每个关键节点建立可程序化校验的关卡。这篇文章围绕“为 agentic AI 设计一个验证框架”这条主线展开。会先讲清楚为什么 Agent 系统比传统程序更需要验证层再逐步设计一个最小可用框架给出可运行的 Python 示例说明如何在校验失败时让模型自我修复最后补充生产环境中的排查路径、常见坑和上线检查清单。读完以后你应该能在自己的 Agent 项目里加入第一层“验证关口”而不是继续盲目信任模型输出。1. agentic AI 为什么不能走“信任模型输出”的路线1.1 传统程序里异常是少数路径Agent 里异常是默认路径传统程序的处理逻辑是确定性的函数入参校验、分支判断、数据库事务、异常捕获都是开发者事先定义好的。即使出现异常错误类型和影响范围基本可控。因为程序行为完全由代码决定输入只要符合契约输出就可以预测。Agent 系统不是这样。它依赖大语言模型在多个步骤里做概率决策每一步输出都可能不同。模型可能选择调用某个不存在的工具可能给工具传入错误类型或错误枚举值可能在拿到工具返回结果后编造一个与事实不符的总结。更麻烦的是多步推理会放大错误第一步生成一个不存在的订单号第二步基于这个订单号做计算第三步给用户一个有模有样的错误答案。这个过程中没有任何一层代码会主动说“我错了”。所以 Agent 的核心矛盾在于外部系统是确定性的工具的入参和返回值必须符合契约而模型的决策是概率性的它天然会犯格式错误、值域错误和幻觉错误。要弥合这个矛盾只能靠一个独立的验证层把“模型输出”翻译成“可执行动作”之前拦住问题。1.2 “可验证”的对象不只有最终答案许多人提到验证第一反应是校验最终回答有没有按 JSON 格式输出。这远远不够。一个 Agent 在运行过程中会产生多个中间产物它们都应该成为验证对象。按一次典型的多步 Agent 调用顺序来看至少包括五类东西。验证点验证内容示例规则失败后果用户输入是否包含必要信息、是否有注入风险、参数格式是否合法订单号必须匹配^[A-Z]\d{4}$用脏数据污染后续工具调用工具调用参数工具名是否允许、必填字段是否齐全、参数值是否满足约束分页大小不能超过 100日期必须是 ISO 格式触发外部接口 4xx/5xx甚至产生副作用工具返回结果返回结构是否符合预期、状态码是否正常、关键字段是否存在接口必须返回code0否则按失败处理Agent 基于异常数据继续推理中间推理状态多轮调用之间的数据是否自洽查询用的订单号必须与最终输出的订单号一致模型用 A 订单数据回答 B 订单问题最终输出格式、必填字段、枚举值、事实一致性状态枚举必须属于created/paid/shipped/completed/cancelled用户看到格式错误或内容矛盾的回答这里的关键不是“每一条规则都要写满”而是要在设计框架时意识到验证点必须分布在 Agent 的生命周期上不能集中在最后一环。否则模型可能已经完成了危险的工具调用最后才在输出层被拦下副作用已经发生了。1.3 验证框架应该放在哪一层验证框架不应该散落在 Agent 业务逻辑里也不应该和具体模型厂商绑定。它应该作为一个独立的包装层存在。常见的接入方式是在 Agent 的run()方法外层增加一个编排器在以下三个位置挂上钩子Agent 开始执行前校验用户输入。Agent 每次准备调用工具前校验工具名和参数。Agent 返回最终结果前校验输出结构和关键字段。在代码结构上可以简单理解成这样的执行顺序用户输入 - 输入校验 - Agent 规划循环 - 工具调用前校验 - 真实工具执行 - 工具结果校验 - 最终输出校验 - 返回用户把验证逻辑放在这个链条上而不是某个工具函数内部是为了保证校验规则可以复用、可以配置、可以记录也可以在故障时单独排查。工具函数只负责业务逻辑校验框架只负责“这个动作能不能执行、这个结果能不能接受”两者职责分离。2. 设计一个最小可用的验证框架先定边界再写代码2.1 验证框架的四个核心模块一个最小可用的 Agent 验证框架不需要做得像规则引擎那么重但至少要拆出四个模块各自职责清楚第一是规则仓库。它保存所有校验规则包括每个工具的参数 JSON Schema、最终输出的 JSON Schema、输入文本的规则等。规则仓库应该和 Agent 代码解耦后续才能做到规则版本化。第二是校验器。它接收规则和待校验数据输出一个结构化的校验结果对象。校验器不关心 Agent 怎么运行只负责判断“这份数据合不合法”。第三是结果模型。校验成功、失败、警告、错误详情都要用统一结构返回。失败信息要能直接回传给模型作为修复提示所以不能只返回一个布尔值。第四是失败策略。校验失败后框架决定是让模型基于错误信息重试、直接中断、还是进入人工审批流程。Agent 场景里最常使用的是“带最大轮数的重试修复”。把四个模块分开后续替换规则存储、增加新的校验器、调整失败策略都不会影响 Agent 主流程。2.2 技术选型为什么不从正则表达式开始示例框架使用 Python 3 实现校验部分依赖jsonschema这个库而不是手写大量正则和 if-else。原因有三点第一JSON Schema 是结构化数据校验的标准方式模型厂商提供的response_format或工具入参约束大多也兼容这种描述。用同一个 Schema 同时约束模型输出和校验真实输出可以最大限度减少“模型按规则生成、程序却不按规则校验”的偏差。第二JSON Schema 支持类型检查、必填字段、枚举、正则、嵌套对象、数组约束覆盖 Agent 场景里绝大多数校验需求。第三规则本身是数据不是代码。它可以存在数据库、配置文件或远程配置中心可以按版本发布也可以由非开发人员维护部分规则。安装依赖只需要两条命令python -m venv .venv source .venv/bin/activate pip install jsonschema pip install pytest示例代码不依赖 Pydantic也不绑定任何具体模型 SDK。如果要和 LangChain、LlamaIndex 或直接调用厂商 API 的项目集成只需要把框架中的llm回调替换成真实调用即可。2.3 目录结构与核心数据结构为了便于扩展示例项目采用以下目录结构agent_validator/ __init__.py models.py # 校验结果、异常 validators.py # 工具参数校验器、输出校验器 framework.py # ValidatedAgent 主循环 examples/ order_agent.py # 订单查询 Agent 示例 tests/ test_validators.py requirements.txtmodels.py中需要定义两个核心数据结构ValidationResult和ValidationFailure。ValidationResult包含三个字段passed表示是否通过errors是错误详情列表warnings是警告列表。为什么要有warnings因为生产环境中有些规则是软约束比如某个字段格式不规范但不会导致事故可以先警告再放行避免因为规则过严阻断所有请求。ValidationFailure是自定义异常当校验失败且已经达到最大重试次数时抛出必须携带校验结果和上下文方便上层捕获后记录日志。3. 实现验证框架核心代码3.1 定义校验结果模型和异常先把基础模型写出来。这段代码是整个框架的公共基础后续所有校验器都返回同一个结构。# agent_validator/models.py from typing import Any, Dict, List, Optional from dataclasses import dataclass, field dataclass class ValidationResult: passed: bool errors: List[str] field(default_factorylist) warnings: List[str] field(default_factorylist) def merge(self, other: ValidationResult) - ValidationResult: return ValidationResult( passedself.passed and other.passed, errorsself.errors other.errors, warningsself.warnings other.warnings, ) def to_dict(self) - Dict[str, Any]: return { passed: self.passed, errors: self.errors, warnings: self.warnings, } class ValidationFailure(Exception): def __init__( self, message: str, result: ValidationResult, context: Optional[Dict[str, Any]] None, ): super().__init__(message) self.message message self.result result self.context context or {}ValidationResult.to_dict()在日志里非常有用。实际项目中每个校验点的成功和失败都要输出成结构化日志包含agent_run_id、验证点、工具名、参数和错误列表。如果只记录一段字符串排错时会非常痛苦。3.2 编写工具调用参数校验器工具调用是 Agent 中风险最高的动作因为真实工具会产生副作用。ToolCallValidator接收一个规则字典内部为每个工具创建一个jsonschema校验器然后对外只暴露validate(tool_name, arguments)方法。# agent_validator/validators.py from typing import Any, Dict from jsonschema import Draft202012Validator from .models import ValidationResult class ToolCallValidator: def __init__(self, rules: Dict[str, Dict[str, Any]]): self._rules rules self._validators { name: Draft202012Validator(schema) for name, schema in rules.items() } def validate(self, tool_name: str, arguments: Dict[str, Any]) - ValidationResult: if tool_name not in self._validators: return ValidationResult( passedFalse, errors[ftool {tool_name} is not allowed by validation rules], ) validator self._validators[tool_name] errors [ f{list(error.path)}: {error.message} for error in validator.iter_errors(arguments) ] return ValidationResult(passednot errors, errorserrors)这里有两个容易被忽略的设计点。第一未知工具名直接判定失败而不是交给后续逻辑报“工具不存在”。因为对于 Agent 来说调一个不在白名单里的工具本身就是安全事件必须提前拦截。第二错误列表里的path要保留比如[properties, order_id]这样回传给模型时模型能知道具体是哪个字段出了问题。3.3 编写最终输出校验器最终输出校验器逻辑类似但校验的是 Agent 返回给用户的结构化结果。它不负责判断内容是否“正确”只负责判断结构、类型、枚举值、必填字段是否符合契约。# agent_validator/validators.py from jsonschema import Draft202012Validator from .models import ValidationResult class OutputValidator: def __init__(self, schema: Dict[str, Any]): self._validator Draft202012Validator(schema) def validate(self, output: Dict[str, Any]) - ValidationResult: errors [ f{list(error.path)}: {error.message} for error in self._validator.iter_errors(output) ] return ValidationResult(passednot errors, errorserrors)实际项目中最终输出校验还可以叠加“事实一致性”校验比如要求输出中的order_id必须等于本次查询使用的order_id。这类跨字段校验无法只靠 JSON Schema 表达需要在OutputValidator中增加额外的检查函数列表。示例为了保持简单先不展开但设计上要留出扩展口。3.4 把验证器接入 Agent 主循环框架核心是ValidatedAgent类。它不自己实现大模型调用而是接收一个llm回调函数这样就可以脱离具体厂商也方便测试时用 mock。# agent_validator/framework.py import json from typing import Any, Callable, Dict, List, Optional from .models import ValidationResult, ValidationFailure from .validators import ToolCallValidator, OutputValidator class ValidatedAgent: def __init__( self, *, llm: Callable[[List[Dict[str, Any]], List[str]], Dict[str, Any]], tools: Dict[str, Callable[[Dict[str, Any]], Any]], tool_validator: ToolCallValidator, output_validator: OutputValidator, max_tool_calls: int 5, max_repair_rounds: int 2, logger: Optional[Callable[[Dict[str, Any]], None]] None, ): self._llm llm self._tools tools self._tool_validator tool_validator self._output_validator output_validator self._max_tool_calls max_tool_calls self._max_repair_rounds max_repair_rounds self._logger logger or (lambda ctx: None) def _log(self, context: Dict[str, Any]) - None: self._logger(context) def run(self, user_query: str) - Dict[str, Any]: messages [{role: user, content: user_query}] tool_calls_done 0 repair_rounds 0 while True: response self._llm(messages, list(self._tools.keys())) self._log({event: llm_response, response: response}) messages.append({ role: assistant, content: response.get(content, ), tool_calls: response.get(tool_calls, []), }) tool_calls response.get(tool_calls, []) if not tool_calls: final_output response.get(output, {}) result self._output_validator.validate(final_output) self._log({ event: output_validation, output: final_output, result: result.to_dict(), }) if not result.passed: repair_rounds 1 if repair_rounds self._max_repair_rounds: raise ValidationFailure( output validation failed, result, {output: final_output}, ) messages.append({ role: user, content: ( Final answer rejected. fFix it. Details: {json.dumps(result.errors, ensure_asciiFalse)} ), }) continue return final_output should_repair False for tool_call in tool_calls: tool_name tool_call.get(name) arguments tool_call.get(arguments, {}) result self._tool_validator.validate(tool_name, arguments) self._log({ event: tool_call_validation, tool_name: tool_name, arguments: arguments, result: result.to_dict(), }) if not result.passed: repair_rounds 1 if repair_rounds self._max_repair_rounds: raise ValidationFailure( tool call validation failed after repair rounds, result, {tool_name: tool_name, arguments: arguments}, ) messages.append({ role: user, content: ( Tool call rejected. Fix the arguments. fDetails: {json.dumps(result.errors, ensure_asciiFalse)} ), }) should_repair True break if tool_name not in self._tools: raise ValidationFailure( tool not found, ValidationResult( passedFalse, errors[funknown tool {tool_name}], ), ) tool_output self._tools[tool_name](arguments) self._log({ event: tool_call, tool_name: tool_name, args: arguments, output: tool_output, }) messages.append({ role: tool, tool_call_id: tool_call.get(id), name: tool_name, content: json.dumps(tool_output, ensure_asciiFalse), }) tool_calls_done 1 if tool_calls_done self._max_tool_calls: raise ValidationFailure( too many tool calls, ValidationResult( passedFalse, errors[max tool calls exceeded], ), ) if should_repair: continue这段代码的核心思路是模型可以犯错但框架必须给模型修复的机会。每轮校验失败后框架不是直接返回错误而是把错误详情拼成一条用户消息放回对话历史让模型重新生成。同时用max_repair_rounds限制修复次数避免模型陷入死循环。有一个地方要在生产环境中特别注意工具执行过程本身可能抛异常。上面代码没有捕获工具异常实际项目里应该把异常转成一条tool结果消息放回对话告诉模型“工具执行失败原因是 XX请换一种方式处理”而不是直接中断整个 Agent。工具异常和校验失败是两类不同问题都必须有修复路径。4. 用一个订单查询 Agent 跑通完整验证流程4.1 场景说明和工具定义示例场景是一个订单查询 Agent。用户输入订单号Agent 判断需要调用get_order_info工具工具返回订单状态Agent 再整理成最终回答。工具get_order_info的入参规则如下TOOL_SCHEMAS { get_order_info: { type: object, properties: { order_id: { type: string, pattern: ^[A-Z]\\d{4}$ } }, required: [order_id], additionalProperties: False } } OUTPUT_SCHEMA { type: object, properties: { order_id: {type: string, pattern: ^[A-Z]\\d{4}$}, status: { type: string, enum: [created, paid, shipped, completed, cancelled] }, delivery_date: {type: [string, null]}, summary: {type: string} }, required: [order_id, status, summary], additionalProperties: False }规则里约定了订单号必须以大写字母开头后跟四位数字。这一条规则同时作用于工具参数和最终输出可以防止 Agent 拿着伪造订单号去查询。工具函数本身只做业务操作def get_order_info(args: Dict[str, Any]) - Dict[str, Any]: order_id args[order_id] # 实际项目里这里会查询订单服务或数据库 return { order_id: order_id, status: shipped, delivery_date: 2025-06-20, detail: 已从上海仓发出 }注意工具返回的数据比输出 Schema 多了一个detail字段。这是因为工具返回结果和最终用户可见输出是两个不同契约工具可以返回丰富数据模型负责挑选和加工。不要把两个 Schema 硬绑到一起。4.2 用可控 mock 模拟模型行为真实 LLM 调用的变数太多示例中用两个 mock 函数代替。一个模拟正常流程一个模拟“第一次参数不合法修复后成功”的流程。def mock_llm_normal(messages, available_tools): if not any(message.get(role) tool for message in messages): return { content: , tool_calls: [ { id: call_1, name: get_order_info, arguments: {order_id: A1001} } ] } return { content: , output: { order_id: A1001, status: shipped, delivery_date: 2025-06-20, summary: 订单 A1001 已发货预计 6 月 20 日送达。 } } def mock_llm_invalid_first(messages, available_tools): if not any(message.get(role) tool for message in messages): # 正常参数 if order_id in messages[-1].get(content, ): return { content: , tool_calls: [ { id: call_2, name: get_order_info, arguments: {order_id: A1001} } ] } # 第一次返回不合法参数 return { content: , tool_calls: [ { id: call_1, name: get_order_info, arguments: {order_id: abc} } ] } return { content: , output: { order_id: A1001, status: shipped, delivery_date: 2025-06-20, summary: 订单 A1001 已发货预计 6 月 20 日送达。 } }在mock_llm_invalid_first中第一次调用会返回非法参数{order_id: abc}框架会拒绝并回传错误详情mock 根据消息里的 “order_id” 信息返回正确参数。4.3 组装 Agent 并打印验证日志下面的main函数把校验器、工具和 mock LLM 组装起来运行后先输出结构化事件日志再把最终结果打印出来。import json from agent_validator.framework import ValidatedAgent from agent_validator.validators import ToolCallValidator, OutputValidator def main(): tool_validator ToolCallValidator(TOOL_SCHEMAS) output_validator OutputValidator(OUTPUT_SCHEMA) events [] agent ValidatedAgent( llmmock_llm_invalid_first, tools{get_order_info: get_order_info}, tool_validatortool_validator, output_validatoroutput_validator, loggerlambda event: events.append(event), ) result agent.run(查询订单 A1001 的状态) print( validation events ) for event in events: print(json.dumps(event, ensure_asciiFalse, indent2)) print( final output ) print(json.dumps(result, ensure_asciiFalse, indent2)) if __name__ __main__: main()运行后会看到两条关键事件第一次tool_call_validation返回passedFalse错误信息是[[order_id]: abc does not match ^[A-Z]\\d{4}$]第二次校验返回passedTrue随后工具正常执行最终输出也通过校验。这段输出就是验证框架存在的直接证据模型第一次给错参数框架没有让非法订单号进入真实工具而是把错误反馈给模型让模型在下一轮修正。这个“拒绝-反馈-修复”的循环就是 Agent 验证框架最核心的价值。4.4 故意注入非法参数验证框架如何拦截再换一个更极端的情况如果模型第一轮返回一个根本不存在的工具名称比如delete_order工具参数校验器会直接返回“tool delete_order is not allowed by validation rules”。框架不会去执行任何代码也不会继续往 Agent 循环里走而是进入失败处理流程。这里有一个值得强调的边界验证框架负责“合法性和安全性”不负责“业务正确性”。如果模型传入的order_id格式合法但数据库中不存在那属于业务查询失败应该由工具返回“订单不存在”然后由 Agent 决定下一步。验证框架不能代替业务逻辑否则会越权。5. 验证框架调试从失败日志定位到问题环节5.1 验证失败必须携带足够的上下文Agent 系统排错比传统程序难很多因为它不是一次调用而是一连串调用。每一个校验点失败时日志里至少要包含以下信息agent_run_id一次完整 Agent 运行的唯一 ID用于串联所有日志。event当前事件类型比如tool_call_validation或output_validation。tool_name准备调用哪个工具。arguments模型给出的完整工具参数。result校验结果包括passed、errors、warnings。repair_rounds当前是第几次修复。message_id或call_id对应模型输出中的工具调用 ID。推荐把每个事件输出成一行 JSON 日志而不是打印普通字符串。这样接入 Elasticsearch、Loki、CloudWatch 等日志平台后可以直接按agent_run_id搜索整个执行链路。{ agent_run_id: run_20250620_001, event: tool_call_validation, tool_name: get_order_info, arguments: {order_id: abc}, result: {passed: false, errors: [[order_id]: abc does not match ^[A-Z]\\\\d{4}$]}, repair_rounds: 1 }这样的日志在排查“模型为什么答错”时非常有用也能帮助后续做回归测试把每次失败的输入和轨迹保存下来模型升级后重新跑一遍看验证框架是否拦截了相同问题。5.2 校验失败后先按这个顺序排查当收到“Agent 输出验证失败”的告警时不要急着调 Prompt。按下面的顺序一步步缩小范围确认模型返回的是否是结构化结果。有时候模型没有按response_format返回 JSON导致解析失败。此时要检查llm_response原始日志。确认校验规则定义是否和工具契约一致。比如order_id规则写的是^[A-Z]\d{4}$但真实订单号已经扩展到^[A-Z]{2}\d{4}$那就是规则过期不是模型错误。确认校验失败发生在哪一层。工具调用前失败说明模型参数生成有误工具返回后失败说明工具契约或数据本身有问题最终输出失败说明模型整理答案阶段出问题。确认修复次数是否设置合理。max_repair_rounds太小可能模型第二次已经改对了但框架已经放弃太大可能导致单次请求耗时过长。确认warnings是否被忽略。如果一条规则是软约束不要把模型输出直接判定为完全正确要记录 warning否则会影响后续数据质量。下面用表格汇总几个典型问题。问题现象常见原因检查方式处理建议工具调用前校验失败模型生成参数不符合 Schema比如类型错误或正则不匹配查看tool_call_validation日志中的 arguments 和 errors把错误详情回传给模型并允许修复同时检查 prompt 中的工具说明是否清楚最终输出被反复拒绝输出 Schema 过严枚举值没有覆盖真实业务状态查看最近一次output_validation错误列表增加允许的枚举值或改为 warning 级别校验全部通过但业务仍报错工具返回结构异常但框架没有校验工具返回结果查看tool_call事件中的 output 字段为工具返回增加独立 Schema或在工具内做防御式检查单次请求耗时过长模型反复生成非法参数导致修复轮数过多查看repair_rounds计数和事件时间戳降低max_repair_rounds或提前用工具说明约束生成过程日志里找不到失败原因日志只记录了passedFalse没有记录参数和错误详情查看日志格式是否包含 arguments、result.errors统一日志结构必带agent_run_id和上下文5.3 三个最容易踩的坑以及对应解法第一个坑是只校验最终输出不校验工具参数。很多 Agent 项目在开发阶段只要求模型以 JSON 结尾结果工具调用时传入的参数全是乱的。比如一个查询工具要求order_id是字符串模型传成整数工具函数直接用args[order_id]去查库轻则查不到数据重则触发 SQL 拼接问题。解决方案就是文章里写的在工具执行前加一层ToolCallValidator。第二个坑是 Schema 写得太死把合法输出拒了。常见做法是把某个字段的enum写得非常小比如只允许shipped和completed但业务里还有processing、cancelled。模型一旦返回业务真实状态框架就误报失败甚至让模型反复重试最终给用户一个错误信息。解决手段有两条一是定期从真实接口数据里同步枚举值二是在规则设计时区分硬校验和软校验不影响安全的字段放warnings而不是errors。第三个坑是校验失败后不做结构化修复直接把异常抛给用户。有些实现会在校验失败时raise ValueError(invalid output)用户看到的是没有上下文的一行错误。正确做法是把失败详情转成模型可以理解的文本放回对话历史并限制修复轮数。模型不是靠猜去修复而是依据错误列表里的path和message修正这样成功率会高很多。6. 生产环境扩展建议与上线前检查清单6.1 从示例到生产环境还差哪些能力示例框架能跑通但离生产环境还有一段距离。至少要补齐以下内容第一规则引擎外置化。工具 Schema 和输出 Schema 不应该硬编码在代码里而是放到配置中心或数据库支持按版本发布、灰度切换。模型能力升级后规则的迁移和回滚都要有记录。第二跟踪和审计。每次 Agent 运行的完整轨迹包括模型请求、工具调用、校验结果、修复过程都要持久化。这不仅是排错需要也是评估模型质量、验证框架拦截率的数据基础。第三安全边界。对于高风险的写操作比如删除、转账、发消息验证规则只能保证参数合法不能保证操作本身被授权。生产系统里应该增加人工确认策略Agent 在调用高风险工具前先停下来由用户确认后再执行。第四工具执行异常处理。框架示例里没有捕获工具函数抛出的异常生产版本要把异常转成工具结果返回给模型否则一次外部服务超时就会让整个 Agent 失败。第五性能控制。Agent 多轮循环会显著增加延迟和 Token 成本。验证框架虽然增加了一层逻辑但开销很小真正要注意的是修复轮次。建议设置合理的max_repair_rounds并对超时、Token 上限做监控。6.2 Agent 上线前验证检查清单下面这份清单可以直接用于 Agent 项目上线前评审。不要求一次全部做到但每一项缺失都应该有明确的风险说明。检查项通过标准未通过的后果用户输入过滤长度、格式、黑名单校验脏数据进入 Agent 决策链工具白名单只能调用已注册工具模型控制任意工具执行工具参数 Schema每个公开工具都有参数规则非法参数打到真实接口工具返回 Schema每个工具返回结构可预期Agent 基于异常数据继续推理最终输出 Schema必填字段、枚举、类型完整用户拿到不可解析或矛盾结果修复轮次限制有max_repair_rounds坏请求无限消耗 Token结构化日志每个验证点都有agent_run_id无法定位失败链路高风险操作审批写操作或敏感操作有人工确认自动化动作失控规则版本管理Schema 变更可追溯规则改错后无法回滚监控告警校验失败率、耗时、Token 有指标问题延迟发现如果你现在维护的 Agent 系统还没有这些能力建议按表格优先级从“工具白名单”和“工具参数 Schema”开始补。这两个是风险最高的环节也是最容易快速落地的环节。6.3 下一阶段可以扩展的方向验证框架的下一步不只是“校验格式”而是向更全面的质量保障体系演进。一个方向是轨迹回放和回归测试。把生产环境中真实失败的输入保存下来模型升级或 Prompt 变更后用同一批数据重新跑 Agent观察校验框架是否修复了旧问题、是否引入了新问题。这比手工测试可靠得多。另一个方向是策略引擎。把规则从 JSON Schema 升级成更丰富的验证策略比如“连续两次工具调用都失败时切换到人工处理”“工具执行超过 3 次仍未得到最终结果时主动向用户确认”。这类策略可以和状态机结合让 Agent 在高风险场景下更可控。还有一个方向是人工反馈回路。验证框架拦截的每一条失败记录都应该进入人工标注队列。标注结果可以用来优化工具说明、调整 Schema、改进 Prompt甚至用于后续微调。这样验证框架的价值就不只是“拦住错误”而是持续提升 Agent 系统的整体质量。回到开头那句话只相信你能验证的。这句话的正确理解不是“不信任模型”而是“用验证结果决定信任程度”。模型可以给出丰富的判断和表达但凡是需要进入真实世界的动作、参数和结果都必须经过可程序化验证的关口。对正在开发 Agent 的团队来说先给系统加一层最小验证框架