AI Agent持续验证：从轨迹记录到四层框架的工程实践

“Do Not Trust, Continuously Verify”这句话原本是安全领域里关于信任边界的判断但放在 AI Agent 上它比大多数技术口号都更贴近现实。过去一年里我陆续接触过不少 Agent 项目从自动写周报的小工具到能调用多个工具完成数据处理的内部系统一个感受越来越强烈这类系统真正让人不安的不是它“不会做”而是它“看起来太会做了”。一个典型的场景是这样的某个 Agent 在演示环境里能自动读取文档、抽取字段、写入数据库流程很顺结果也很准。于是团队把它接到真实数据上。某一天它在关键字段上写错了值但因为工具调用成功、数据库写入成功、日志显示任务完成没有任何人发现问题。直到下游报表对不上大家才回去翻记录。这就是 AI Agent 的信任悖论它往往不是在某一步突然崩溃而是把错误包装成了“正常完成”。如果我们的验证思路还停留在“跑通一次就信任”那问题迟早会出现在最不该出错的地方。真正能建立信任的方式只有一个不把验证当成上线前的一次性考试而是把它变成一种持续运行的机制。能力可以快速提升但信任必须来自持续验证。1. 真正该担心的不是 Agent 不会干活而是它看起来干得挺好1.1 一次“很顺利”的 Agent 事故很多接触 Agent 的人第一次都会被它的“连贯性”打动它能分解任务、调用工具、根据结果调整下一步。这种体验很容易让人产生一种错觉觉得只要最后没报错任务就是成功的。但 Agent 的失败模式比传统程序复杂得多。传统代码里逻辑是确定的给定输入要么走这条分支要么走那条分支异常会抛出错误会暴露。Agent 不一样它每一步都是概率性的提议工具调用的参数是生成的下一步动作也是基于上下文推断的。这意味着它可能在“正确”的大框架下犯一个微小但致命的错误。我见过一个最典型的例子Agent 需要从一份客户表格里读取“公司名称”并写入另一个系统。它读取时一切正常写入时把“北京XX科技有限公司”自动截断成了一个简称因为模型认为“简称更合适”。下游系统没有报错字段长度合法日志显示写入成功。直到业务方发现客户名称对不上。这不是模型能力不够也不是工具出了问题。问题在于 Agent 有“自己的理解”而它会把这种理解包装成正常动作。1.2 为什么传统测试思路对 Agent 失效传统软件测试关注的是“逻辑是否正确”。你写单元测试验证函数输入输出的映射关系你写集成测试验证模块之间的交互。但 Agent 的逻辑不是固定代码而是模型在上下文中即时生成的决策。传统测试能验证“这个函数在给定参数下做了正确的事”但很难验证“这个 Agent 在开放式任务中是否选择了正确的事”。因为 Agent 面临的问题空间是开放的输入不是结构化的固定参数而是自然语言目标加上一堆动态上下文。同一个目标今天给出 A 方案明天可能给出 B 方案甚至同一个模型在相同输入下也可能有微小波动。所以验证 Agent 不能只验证结果还要验证过程不能只测一次还要持续测不能只看“有没有报错”还要看“它做这件事的方式是否在边界内”。这是整个 Agent 工程化里最反直觉但也最重要的一点。2. 验证 Agent结果正确只是最低标准2.1 过程比结果更容易暴露问题Agent 执行任务时会经历“思考 → 生成回复 → 决定调用工具 → 解析工具结果 → 生成下一步”这样的循环。最终结果只是这个循环的终端输出真正的风险藏在循环内部。举个例子一个负责写邮件摘要的 Agent最终摘要看着没问题但它可能偷偷访问了一个不该访问的文件或者在一个不需要写操作的场景下调用了写接口。如果只看摘要质量这个问题永远不会暴露。但一旦 Agent 被给了更大权限这个“偷偷访问”就可能发展成严重事故。所以我在项目里一直坚持一个原则结果指标只能用来衡量“做得好不好”过程指标才能用来衡量“做得安不安全”。两个都要看但过程往往更要紧。2.2 把轨迹变成可观测、可回放的记录要让过程可验证前提是过程可观测。很多 Agent 框架自带调试面板能实时显示模型输出和工具调用。但调试面板不等于日志更不等于可验证的记录。真正需要的是结构化的轨迹数据。每一条轨迹都应该包含任务目标、每一步模型输出、工具调用名称、工具输入参数、工具返回结果、每一步的时间、模型版本、提示词版本。这样任何一次任务完成后都能回放当时的完整过程。我建议把轨迹当作和业务日志同等重要的数据来管理。不要只存在内存里也不要只打印到控制台。要落盘、要可查询、要方便回溯。2.3 一条最小轨迹记录应该包含什么一个最小可用的轨迹记录可以设计成这样{ trace_id: trace_20250101_001, user_request: 整理客户信息并写入客户表, model_version: gpt-4o-2024-11-20, prompt_version: customer_agent_v3, steps: [ { step: 1, type: model_output, content: 我需要先读取客户文件, tool_call: { tool: read_file, input: {path: /data/customers.xlsx}, result: {status: ok, rows: 120} } }, { step: 2, type: tool_call, tool: write_db, input: {table: customers, field: company_name, value: 北京XX科技}, result: {status: ok, rows_written: 1} } ], final_status: completed }这里的关键不是字段多详细而是它能不能回答三个问题Agent 在每一步做了什么它为什么这么做对应的模型输出是什么工具返回了什么结果有了这个基础后面的验证才有抓手。3. 四层验证框架从“跑通”到“敢上线”3.1 第一层输入输出校验这是最基础的一层也最容易实现。对 Agent 的输入和最终输出分别做校验。输入校验包括任务目标是否合法、用户提供的文件或参数是否符合预期、上下文是否完整。输出校验包括最终输出格式是否正确、关键字段是否存在、类型是否匹配。但要注意输入输出校验只能拦截“显而易见的错误”它拦不住“看起来合理但实际错误”的情况。比如前面提到的公司名称被截断输出格式完全合法单看最终结果很难发现。所以输入输出校验只是第一道防线不能作为唯一防线。3.2 第二层过程轨迹校验过程校验的核心是检查 Agent 的动作是否符合预期。比如是否调用了不该调用的工具工具入参是否符合业务约束是否在任务不应该结束的时候提前结束了是否绕过某些步骤直接得出结论我在实际项目里一般会写一套规则引擎对轨迹做简单校验。比如规定只有任务目标中出现“写入”时才允许调用写数据库工具所有写操作之前必须有一个模型明确确认的步骤。# 伪代码示例校验轨迹中的工具调用是否合规 def validate_trace(trace, policy): steps trace.get(steps, []) if not steps: return {passed: False, reason: empty_trace} for step in steps: if step.get(type) tool_call: tool step[tool_call][tool] tool_input step[tool_call][input] if tool in policy[forbidden_tools]: return {passed: False, reason: fforbidden_tool:{tool}} if not is_valid_tool_input(tool, tool_input): return {passed: False, reason: finvalid_input:{tool}} if tool write_db and confirmed not in str(step.get(model_output, )): return {passed: False, reason: write_without_confirmation} return {passed: True, reason: ok}这套校验不需要多复杂但要把“业务红线”固化下来。校验规则本身要可维护后续每发现一次事故就要补一条规则。3.3 第三层策略边界校验策略边界校验解决的是“允不允许”的问题。Agent 的能力边界、工具权限、数据访问范围、操作可逆性都要在这一层明确。比如一个只负责“读取并整理信息”的 Agent不应该拥有删除文件的权限一个负责“生成营销文案”的 Agent不应该能访问客户手机号一个负责“写周报”的 Agent不应该能向外部发送邮件。这层校验的关键是权限最小化。给 Agent 的权限只要满足任务需求就好多给一点都是风险。我建议为每个 Agent 创建一张“能力清单”明确列出它可以使用哪些工具、不能使用哪些工具、可以访问哪些数据、可以修改哪些字段。上线前逐项确认上线后每次变更都要重新确认。3.4 第四层线上持续验证前三层是上线前的检查第四层才是“持续验证”的核心。线上持续验证包括三类动作第一对真实请求做随机抽样回放。不是每个任务都全量检查但要每天抽一部分重放轨迹确认 Agent 的行为一直符合预期。第二对模型升级、提示词修改、工具变更做回归测试。任何改动都可能改变 Agent 的行为分布不能只看“这次跑通了”还要看“之前能跑通的是不是还跑得通”。第三对异常进行实时监控和告警。比如工具调用失败率突然上升、某类输入导致 Agent 频繁重试、特定工具的调用频率异常都要能触发告警。持续验证的目的不是保证每次都对而是保证每次“错”的时候能被发现、被追踪、被快速纠正。4. 持续验证怎么落地离线评估、影子模式、线上监控与熔断4.1 离线评估先建一个能回归的样本集离线评估是持续验证的底座。没有一套固定的回归样本集任何改动都只能靠“感觉”。构建回归样本集时我建议覆盖三类场景正常场景日常任务的标准输入和期望行为。边界场景输入格式异常、字段缺失、上下文过长、工具返回空结果。历史事故场景每次线上出过问题的样本都要加入回归集防止同一个问题反复出现。回归集不需要一开始就很大。先收集 50 到 100 条高质量样本把通过率稳定下来再逐步扩充。评估指标也不能只看端到端成功率还要看每个关键节点的表现工具选择准确率、参数生成正确率、无效调用率、安全违规次数。4.2 影子模式让 Agent 在真实流量里“练习”影子模式是“让 Agent 在不影响业务的前提下观察真实流量里它会怎么做”。做法是把线上真实请求复制一份喂给新的 Agent 版本但它的输出只记录、不执行。这个阶段的价值在于你能用真实数据测试新版本又不会因为它的错误造成实际损失。比如你要升级一个负责写回复的 Agent可以先在影子模式里跑两周对比新旧两个版本在同样输入下的行为差异。影子模式特别适合模型版本升级、提示词大改、工具定义调整这几种场景。它能提前暴露很多离线测试看不到的问题比直接上线灰度安全得多。4.3 线上监控不能只看成功率上线之后监控指标要分三层看。第一层是任务层任务完成率、平均耗时、重试次数。 第二层是工具层每个工具调用成功率、调用次数、异常类型。 第三层是安全层越权调用次数、被拦截操作次数、人工干预次数。很多团队只看任务完成率这是一个很大的陷阱。因为 Agent 的“任务完成”和“真正做对”之间存在很宽的空间。任务完成率 98%可能意味着每 100 个任务里有一个草率执行的任务而这一两个恰恰可能造成最大影响。我建议对高风险操作单独设置监控和告警。比如写库、删除、发送消息每发生一次都要有记录每失败一次都要告警。4.4 回滚与熔断把风险圈在最小范围持续验证还要包含一个“失败预案”。一旦发现 Agent 行为异常要能快速隔离问题。熔断是一个很实用的手段当某个 Agent 的失败率、异常调用率、人工干预率超过阈值时自动暂停它的高风险工具权限只保留只读能力或者直接降级为人工处理。回滚则要覆盖全链路模型版本、提示词版本、工具配置、权限策略都要支持快速回滚。如果只回滚模型而提示词已经改成新版回滚效果可能很有限。建议上线前就把“熔断阈值”和“回滚流程”写好不要等出事以后再讨论。出事的时候人的判断力会明显下降。5. 真实项目里最容易被忽略的五个工程细节5.1 只统计成功率等于把风险藏起来成功率是结果指标它能反映整体稳定性但掩盖了很多细节。一个 Agent 可能任务完成率很高但每次涉及写操作时都会省略某些字段只是最终结果碰巧没报错。更合理的方式是分层统计每一类工具调用的成功率、每一类任务的通过率、每一次人工干预的事件率。把成功率拆细才能发现问题。5.2 测试集与真实分布的偏差很多团队在测试环境里用精心构造的样例测试 Agent效果很好一上生产就崩。原因通常是测试集和真实请求分布不一致。真实请求往往更口语化、更模糊、上下文更长、工具返回结果更乱。测试集再完善也很难完全模拟真实情况。所以测试集要定期从线上抽样补充而不是只靠人工编写。5.3 版本管理模型、提示词、工具定义都要留痕Agent 的行为同时受模型版本、提示词内容、工具描述、执行代码影响。任何一项变了行为都可能变。所以版本管理不是只给代码打 tag还要把模型版本、提示词版本、工具定义版本一起记录。每条轨迹数据里都带上这些版本信息出了问题才能精确定位是哪个变更引入的。5.4 权限和可逆性设计给 Agent 权限之前先问一句如果它误用这个权限后果是什么如果后果不可接受就不要给它这个权限。如果确实需要也要设计成可撤销的比如先写入临时表人工确认后再转正。权限设计不是限制 Agent 能力而是给业务留出安全的缓冲。对于不可逆操作我建议默认禁止 Agent 自动执行。改成“Agent 生成动作 → 人工确认 → 执行”的模式。这个流程虽然慢一点但能避免绝大多数严重事故。5.5 验证是一次性的还是持续性的很多团队在项目上线前做了大量测试上线后就不再验证。但 Agent 的行为分布会随着模型升级、用户输入变化、工具接口调整而变化。上一次测试通过不等于下一次还通过。持续验证要成为一个固定流程而不是临时动作。哪怕只是每周跑一次回归集、每月做一次影子模式对比也比完全不验证好得多。6. Agent 行为异常时按这个顺序排查6.1 先还原现象再怀疑模型Agent 出问题时很多人第一反应是“模型能力不行”。但实际上很多问题不是模型本身的错而是输入不对、工具定义不清楚、权限不足、上下文过长、依赖版本变化导致的。一开始先不要急着下结论先把现象还原完整是报错、卡住、无输出还是输出结果错误是偶发还是必现是某一个输入触发还是某一类输入触发是某一次工具调用后开始异常还是一开始就偏了把现象写清楚再开始查。模糊地怀疑模型只会浪费时间。6.2 按输入、轨迹、环境、策略逐层定位我一般按下面的顺序排查排查层要看什么常见问题输入用户请求是否完整、文件路径是否正确、字段格式是否符合预期编码问题、上下文被截断、字段缺失模版 / 模型输出Agent 第一步生成了什么内容、它选择了哪个工具工具选错、参数格式不对、生成了多余内容工具调用工具实际收到什么参数、返回什么结果工具定义和实际行为不一致、返回结构变化策略系统提示词是否限制了错误路径、权限配置是否合理提示词自相矛盾、工具权限过宽或过窄环境依赖版本、模型配置、资源占用模型版本被切换、依赖升级、上下文窗口溢出这个顺序的核心是先看输入再看过程然后看环境最后看策略。不要跳过轨迹直接改提示词。6.3 排查完要做的第一件事不是“调参”而是补一条回归用例很多人修复 Agent 问题后就直接上线了。这个习惯很危险。对于传统软件修 bug 后要加单测对于 Agent修复后要加一条回归样本。把这次异常输入和期望行为加入回归集确保后续任何版本变更都不会再次踩坑。这样做不看一两周效果有限坚持两三个月你会拥有一套非常有价值的“避坑样本库”。提示每发现一次线上事故都应该问一个问题我们的验证体系里为什么没有拦住它是缺少观测还是缺少校验规则还是规则没生效补规则比批评模型更重要。真实项目里Agent 能不能用不取决于 Demo 多惊艳而取决于出问题时能不能快速发现、能不能定位原因、能不能阻断风险。持续验证不是为了让 Agent 永远正确而是让它的每一次错误都在可掌握、可修复、可改进的范围里。如果你正在做一个 Agent不管它是自动写文案、做会议纪要还是会调用工具处理业务数据我都建议先从最小轨迹记录开始。记录它每一步做了什么再增加一层规则校验最后把它接入回归集。先从这一步开始你对 Agent 的信任就会从“感觉还行”变成“有据可依”。