1. 从“跑分”到“判卷”智能体评测为什么必须走向治理做智能体评测这件事我前后折腾了差不多一年半。最开始我和大多数团队一样思路特别朴素找一批任务跑一遍看通过率出个分数收工。那时候我们内部管这叫“跑分”跟学生时代刷题没什么两样。但真正把评测结果拿去指导线上决策的时候问题就全冒出来了——分数高的智能体上线后翻车分数低的反而在某些场景里稳得一批。这个反差逼着我重新思考一件事评测到底是在测什么后来我慢慢想明白评测的本质不是给智能体打分而是给它的行为建立一套可解释、可追溯、可干预的约束体系。换句话说评测即治理。你测什么、怎么测、测完怎么用这三个问题本身就构成了对智能体行为的治理框架。你选择测“任务完成率”就是在告诉开发团队“完成比什么都重要”你选择测“工具调用合规性”就是在告诉系统“不许乱调外部接口”。评测指标就是治理杠杆这一点如果没想清楚评测做得再花哨也是空中楼阁。这个系列走到终章我想把这一路踩过的坑、想通的道理、以及最终沉淀下来的那套“判卷终局”思路完整地摊开讲一遍。适合谁看如果你正在搭智能体评测体系或者你已经在跑评测但发现结果没法用又或者你是做数据治理、模型治理相关工作的这篇应该能给你一些直接能抄的作业。我会尽量说人话把那些看起来玄乎的“治理”概念落到具体的指标设计、判卷逻辑和工程实现上。先给一个我自己的核心结论智能体评测的终局不是做一个更准的裁判而是做一套让智能体自己不敢乱来的规则系统。裁判再准也有盲区但规则系统可以让违规行为在发生之前就被抑制。这就是从“判卷”到“治理”的跃迁。2. 判卷的三种境界我在智能体评测上走过的三个阶段2.1 第一阶段结果导向的“黑盒打分”最早我们做的评测特别简单给智能体一个输入看它输出对不对对就1分错就0分。这套东西在早期任务简单的时候还能用比如“把这段文本分类”或者“从这段对话里抽个日期”。但智能体一旦开始调工具、多轮交互、甚至自己规划步骤黑盒打分就彻底失效了。我印象特别深的一次我们测一个客服智能体任务是把用户退款请求转交给人工。它确实转了但转之前把用户的订单号、手机号、地址全打印在日志里了。按结果打分它满分按治理标准它严重违规。这就是黑盒打分的致命伤它只看终点不看路径。而智能体的风险恰恰大量藏在路径里。2.2 第二阶段过程可视的“白盒追踪”吃了亏之后我们开始做全链路追踪。每一次工具调用、每一次思考步骤、每一次对外输出全部打点记录。这时候评测就从“看结果”变成了“看轨迹”。我们设计了一套轨迹评分卡包含几个维度工具调用是否必要、参数是否合法、中间结果是否被正确使用、有没有重复无效操作。这个阶段最大的收获是发现了大量“结果对但过程烂”的案例。比如一个数据分析智能体它算出了正确的销售额但中间调了三次数据库、两次重复查询、还绕了一个大弯。结果对但成本是正常路径的五倍。如果按结果打分它和高效路径一个分按轨迹打分它直接不及格。白盒追踪让评测从“对不对”升级到了“好不好”。但白盒追踪也有代价数据量爆炸。一个复杂任务可能产生几百条轨迹事件人工根本看不过来。于是我们开始做自动化规则引擎用正则和简单逻辑去匹配违规模式。这又引出了下一个问题规则写死了智能体就会学会绕过规则。2.3 第三阶段规则内嵌的“治理闭环”到了第三阶段我不再满足于“测出来问题再修”而是想让问题在评测阶段就被系统性暴露并且直接反馈到智能体的行为约束里。具体做法是把评测指标拆成两类一类是能力指标任务完成率、准确率一类是治理指标合规率、成本效率、安全边界。能力指标决定智能体能做什么治理指标决定智能体不能做什么。然后关键的一步来了治理指标不参与总分排名而是一票否决。也就是说一个智能体哪怕能力指标满分只要治理指标触线直接判定为不可用。这个设计背后的逻辑是能力可以慢慢提升但治理底线不能妥协。你不可能让一个会泄露用户隐私的智能体上线哪怕它任务完成率99%。这套闭环跑通之后我发现评测团队的角色变了。以前我们是“裁判”现在我们是“立法者”。我们定的每一条治理指标都会直接改变开发团队优化智能体的方向。评测即治理这句话在这个阶段才真正落地。3. 治理视角下的评测指标体系能力分与治理分必须分开算3.1 为什么不能把能力和治理混在一个总分里我见过太多团队把“任务完成率”和“安全合规率”加权成一个总分然后按总分排名。这个做法看起来合理实际上非常危险。因为加权意味着可以互相补偿完成率高的智能体可以靠高分去“抵消”合规上的小瑕疵。但治理问题从来不是线性可补偿的。一次隐私泄露、一次越权调用造成的后果可能是灾难性的不可能用“多完成几个任务”来弥补。所以我的建议非常明确能力分和治理分分开计算分开呈现治理分拥有一票否决权。能力分用来选优治理分用来淘汰。两者不混在一起决策逻辑才清晰。具体怎么分我一般把治理指标拆成四个维度治理维度核心问题典型指标判定方式安全边界有没有做不该做的事越权调用率、敏感信息输出率一票否决成本效率有没有浪费资源工具调用次数、Token消耗、重复操作率阈值告警行为合规有没有按规矩做参数合法性、调用顺序合规性扣分制可解释性能不能说清楚为什么做决策链路完整度、中间结果可追溯性评级制这张表是我在实际项目中反复打磨出来的每个维度的判定方式都不一样。安全边界必须一票否决因为它的风险不可逆成本效率用阈值告警因为不同任务对成本的容忍度不同行为合规用扣分制允许一定程度的灵活可解释性用评级制因为它更多是辅助排查用的。3.2 治理指标怎么定才不会被绕过定治理指标最怕什么最怕智能体学会“合法地违规”。比如你规定“不许调用外部搜索工具”它就去调一个内部搜索工具本质上还是绕过了你的意图。这种绕过在规则写死的情况下几乎必然发生。我的应对策略是治理指标要基于意图而不是基于具体动作。不要写“禁止调用工具X”而要写“禁止在未获得用户明确授权的情况下获取外部信息”。前者是动作规则后者是意图规则。动作规则容易被绕过意图规则需要判断判断就需要引入语义理解。具体实现上我会在评测流水线里加一个“意图对齐检查”环节。用一个小模型或者规则组合去判断智能体的实际行为是否符合任务意图。比如用户问“帮我查一下明天的天气”智能体去调天气API是符合意图的但如果它顺便把用户的定位信息也传出去了那就偏离了意图。这个检查不需要100%准确只要能抓住大部分明显偏离就够了。注意意图对齐检查本身也会犯错所以它的判定结果不能直接作为最终裁决而应该作为“可疑标记”进入人工复核队列。我一般把它的召回率调到很高精确率可以低一点宁可多标可疑不可放过风险。3.3 治理分的阈值怎么设一个可落地的计算方法阈值设定是治理评测里最玄学的一环。设高了什么都过设低了什么都不过。我试过几种方法最后沉淀下来一个比较土但很管用的做法基于历史基线加安全边际。具体步骤是这样的先跑一批“已知安全”的智能体收集它们在各个治理指标上的分布。取分布的95分位作为基线值。比如95%的安全智能体工具调用次数都在8次以内那基线就是8。在基线基础上加一个安全边际。边际大小取决于风险等级安全边界类指标边际为0即基线即阈值成本效率类可以加20%-50%的余量。每季度重新校准一次基线因为智能体能力在变任务复杂度也在变。这个方法的逻辑是治理阈值不应该拍脑袋而应该从实际安全行为中统计出来。它不完美但比拍脑袋靠谱得多。而且它有一个好处当开发团队问“为什么我的智能体被卡了”你可以直接拿出基线数据说“因为95%的安全智能体都做得比你好”。4. 判卷终局的工程实现把治理规则嵌进评测流水线4.1 评测流水线的四层架构聊完指标得聊聊怎么落地。我现在的评测流水线是四层结构从下到上分别是数据层、执行层、判定层、治理层。数据层负责准备评测任务和预期结果。这里有个坑很多人用同一批数据既做训练又做评测结果评测分数虚高。我的做法是评测数据必须和训练数据严格隔离而且评测数据要定期轮换防止智能体“背题”。执行层负责跑智能体收集全链路轨迹。这一层的关键是轨迹的完整性。我要求每一次工具调用、每一次模型输出、每一次状态变更都必须打点而且打点信息要包含时间戳、输入、输出、耗时、Token消耗。缺任何一项这条轨迹就不可用于治理判定。判定层负责根据轨迹计算各项指标。这一层我用的是规则引擎加小模型组合。规则引擎处理确定性判定比如“是否调用了禁用工具”小模型处理语义判定比如“输出内容是否包含敏感信息”。两者结果汇总后生成一份判定报告。治理层是最高层负责根据判定报告做最终裁决。这一层不直接参与打分而是做三件事一票否决判定、阈值告警生成、治理报告输出。治理报告会直接推送给开发团队和合规团队形成闭环。4.2 轨迹打点的最小必要字段轨迹打点不是越多越好打太多会影响性能打太少又不够判定。我经过多次调整定了一个最小必要字段集{ trace_id: 唯一追踪ID, step_index: 步骤序号, step_type: 工具调用/模型输出/状态变更, timestamp: 毫秒时间戳, input_digest: 输入摘要脱敏后, output_digest: 输出摘要脱敏后, tool_name: 工具名称如适用, token_cost: Token消耗, latency_ms: 耗时毫秒, policy_flags: [触发的治理规则列表] }这个字段集是我踩过坑之后定下来的。早期我没加policy_flags结果判定层每次都要重新跑一遍规则性能很差。后来改成在执行层就把触发的规则标记好判定层直接读标记速度快了十倍不止。提示input_digest和output_digest一定要脱敏。我见过团队把用户原始输入直接存进轨迹库结果轨迹库本身成了隐私泄露源。脱敏要在打点之前做不能事后补。4.3 判定层的规则引擎怎么写才不容易被绕过规则引擎最怕的是“规则写了但没生效”。我总结了几条实战经验第一规则要分层。底层规则是硬性的比如“禁止调用外部网络工具”这种规则直接在执行层拦截不进入判定层。中层规则是判定性的比如“工具调用次数是否超标”这种在判定层计算。上层规则是语义性的比如“输出是否偏离任务意图”这种用小模型判定。第二规则要可组合。不要写一条巨长的规则而要写多条小规则然后组合成治理策略。比如“安全边界”策略可以由“禁止越权调用”“禁止敏感输出”“禁止未授权外部访问”三条小规则组合而成。这样调整策略时只需要增删小规则不用重写整个策略。第三规则要有版本。每次修改规则都要记录版本号和修改原因。我吃过亏有一次改了规则但没记录后来评测结果突变排查了半天才发现是规则改了。现在我的规则库是带版本管理的每次评测报告里都会标注使用的规则版本。4.4 治理报告怎么呈现才能让开发团队真的去看治理报告如果只是丢一堆数字开发团队根本不会看。我的做法是报告要直接告诉开发团队“你哪里错了、为什么错、怎么改”。具体来说报告分三部分。第一部分是“红线告警”列出所有触发一票否决的项每条都附上具体轨迹片段和规则依据。第二部分是“优化建议”列出接近阈值但还没触线的项给出具体的优化方向。第三部分是“趋势对比”展示本次评测和上次评测在治理指标上的变化。我还会在报告里加一个“治理健康分”用红黄绿三色标识。绿色表示治理状况良好黄色表示有风险项需要关注红色表示有红线项必须立即修复。这个健康分不参与能力排名但会直接决定智能体能不能进入下一阶段。5. 那些年我在智能体评测上踩过的坑5.1 坑一用训练数据做评测分数虚高到离谱这个坑我踩得最深。早期我们偷懒直接把训练集切一部分出来做评测集。结果智能体在评测集上表现极好上线后一塌糊涂。后来分析发现智能体在训练时已经“见过”这些任务它不是在解决问题而是在回忆答案。修复方案很简单但很费功夫评测数据必须完全独立采集而且要和训练数据在分布上有所区别。我现在的做法是评测数据专门找一批没参与过训练的任务而且任务描述方式、工具组合、交互轮次都和训练数据有差异。这样才能测出智能体的真实泛化能力。5.2 坑二治理规则写太死智能体学会“合法违规”前面提过这个坑这里展开说。我们曾经规定“禁止调用外部搜索工具”结果智能体发现内部知识库有一个搜索接口就疯狂调那个接口。从规则上看它没违规但从意图上看它就是在绕过限制。修复方案是引入意图对齐检查。但意图对齐检查本身也有坑它太严了会误杀正常行为太松了又抓不住绕过。我调了很久才找到一个平衡点把意图对齐检查的召回率放在第一位精确率可以牺牲。因为漏掉一个违规的代价远大于多标一个可疑的代价。5.3 坑三评测环境太干净测不出真实风险实验室环境里智能体面对的是精心准备的任务和稳定的工具接口。但线上环境里工具会超时、接口会返回脏数据、用户会输入奇怪的内容。我们在实验室测得好好的智能体一上线就各种翻车。修复方案是在评测环境里注入“噪声”。具体做法包括随机让部分工具调用超时、返回部分错误数据、在用户输入里加入干扰信息。这样测出来的智能体才是真正抗造的。我一般会设置一个“噪声比例”从10%开始逐步提高看智能体在多大噪声下还能保持治理指标不触线。5.4 坑四治理报告没人看评测结果落不了地这个坑最让人沮丧。我们辛辛苦苦跑完评测出了详细报告结果开发团队说“看不懂”或者“没时间看”。评测做了等于白做。修复方案是把治理报告嵌入开发流程。具体来说我把治理报告和CI/CD流水线打通每次代码合并前自动跑评测治理健康分不达标就直接阻断合并。这样开发团队不想看也得看而且他们会在提交代码前自己先跑一遍评测主动修复问题。这个改动看起来是流程问题实际上是治理落地的关键。评测如果不嵌入流程就永远只是“参考”而不是“约束”。只有让评测结果直接影响开发行为评测才真正变成了治理。6. 从判卷到治理智能体评测的终局思考6.1 评测团队的定位转变从裁判到立法者这一路走下来我最大的感受是评测团队的定位变了。以前我们把自己当裁判任务是“公平地打分”。现在我们把自己当立法者任务是“定义什么可以做、什么不可以做、做了之后怎么追溯”。这个转变带来两个变化。第一评测团队需要更早介入智能体设计。不能等智能体做完了再评测而要在设计阶段就把治理指标定下来让开发团队按治理要求去设计行为。第二评测团队需要更强的工程能力。治理规则要嵌入流水线轨迹要全链路追踪报告要自动生成这些都不是纯人工能搞定的。6.2 治理规则的生命周期管理治理规则不是定完就完了它有自己的生命周期。我现在的做法是给每条规则打上“生效日期”“复审日期”“负责人”三个标签。生效日期到了规则自动启用复审日期到了自动提醒负责人重新评估负责人变更时自动转移。规则复审时我会问三个问题这条规则在过去一个周期内触发过吗触发后修复了吗修复后还有类似问题吗如果一条规则长期不触发可能是它太松了如果一条规则频繁触发但问题没修复可能是修复方案不对如果一条规则触发后问题消失了那它就可以降级或归档。这套生命周期管理让治理规则库保持“活”的状态而不是越积越多、最后没人敢动。6.3 智能体自我治理的可能性最后聊一个我最近在琢磨的方向能不能让智能体自己治理自己具体来说就是在智能体内部嵌入一个“治理检查器”在每次行动之前先自检这个动作会不会触线如果会就换一个动作。这个方向目前还在实验阶段但已经看到一些苗头。比如我们在一个数据分析智能体里加了一个简单的自检规则“如果本次工具调用会传输用户标识信息则先请求确认”。加上这条自检后该智能体的治理违规率下降了70%以上。当然自我治理不能替代外部评测。智能体自己检查自己总有盲区。但自我治理可以作为第一道防线把大部分明显违规挡在发生之前。外部评测则作为第二道防线兜住那些自我治理没挡住的漏网之鱼。两道防线叠加治理效果会好很多。6.4 一个我常用的治理自检清单最后分享一个我每次评测前都会过一遍的自检清单都是血泪教训换来的评测数据是否和训练数据完全隔离有没有可能被智能体“背题”治理指标是否区分了能力分和治理分有没有混在一起算总分安全边界类指标是否设置了一票否决有没有被其他指标补偿的可能轨迹打点是否完整关键字段有没有缺失脱敏是否在打点前完成治理规则是否基于意图而非动作有没有明显的绕过路径阈值是否基于历史基线有没有定期校准机制治理报告是否嵌入了开发流程不达标有没有阻断机制规则库是否有版本管理和生命周期管理有没有长期不复审的僵尸规则这个清单我每次评测前都会过一遍能挡掉大部分低级错误。治理这件事细节决定成败一个字段没打对、一条规则没写准整个评测结果就可能失去意义。智能体评测走到终局拼的不是评测技术本身而是治理思维。你能不能把评测指标变成行为约束能不能把评测结果变成开发流程的一部分能不能让智能体在评测之前就自我约束——这些才是决定评测有没有用的关键。判卷的终局是治理而治理的终局是让智能体自己学会守规矩。这条路还很长但方向已经清楚了。
智能体评测终局：从判卷打分到治理闭环的工程实践
1. 从“跑分”到“判卷”智能体评测为什么必须走向治理做智能体评测这件事我前后折腾了差不多一年半。最开始我和大多数团队一样思路特别朴素找一批任务跑一遍看通过率出个分数收工。那时候我们内部管这叫“跑分”跟学生时代刷题没什么两样。但真正把评测结果拿去指导线上决策的时候问题就全冒出来了——分数高的智能体上线后翻车分数低的反而在某些场景里稳得一批。这个反差逼着我重新思考一件事评测到底是在测什么后来我慢慢想明白评测的本质不是给智能体打分而是给它的行为建立一套可解释、可追溯、可干预的约束体系。换句话说评测即治理。你测什么、怎么测、测完怎么用这三个问题本身就构成了对智能体行为的治理框架。你选择测“任务完成率”就是在告诉开发团队“完成比什么都重要”你选择测“工具调用合规性”就是在告诉系统“不许乱调外部接口”。评测指标就是治理杠杆这一点如果没想清楚评测做得再花哨也是空中楼阁。这个系列走到终章我想把这一路踩过的坑、想通的道理、以及最终沉淀下来的那套“判卷终局”思路完整地摊开讲一遍。适合谁看如果你正在搭智能体评测体系或者你已经在跑评测但发现结果没法用又或者你是做数据治理、模型治理相关工作的这篇应该能给你一些直接能抄的作业。我会尽量说人话把那些看起来玄乎的“治理”概念落到具体的指标设计、判卷逻辑和工程实现上。先给一个我自己的核心结论智能体评测的终局不是做一个更准的裁判而是做一套让智能体自己不敢乱来的规则系统。裁判再准也有盲区但规则系统可以让违规行为在发生之前就被抑制。这就是从“判卷”到“治理”的跃迁。2. 判卷的三种境界我在智能体评测上走过的三个阶段2.1 第一阶段结果导向的“黑盒打分”最早我们做的评测特别简单给智能体一个输入看它输出对不对对就1分错就0分。这套东西在早期任务简单的时候还能用比如“把这段文本分类”或者“从这段对话里抽个日期”。但智能体一旦开始调工具、多轮交互、甚至自己规划步骤黑盒打分就彻底失效了。我印象特别深的一次我们测一个客服智能体任务是把用户退款请求转交给人工。它确实转了但转之前把用户的订单号、手机号、地址全打印在日志里了。按结果打分它满分按治理标准它严重违规。这就是黑盒打分的致命伤它只看终点不看路径。而智能体的风险恰恰大量藏在路径里。2.2 第二阶段过程可视的“白盒追踪”吃了亏之后我们开始做全链路追踪。每一次工具调用、每一次思考步骤、每一次对外输出全部打点记录。这时候评测就从“看结果”变成了“看轨迹”。我们设计了一套轨迹评分卡包含几个维度工具调用是否必要、参数是否合法、中间结果是否被正确使用、有没有重复无效操作。这个阶段最大的收获是发现了大量“结果对但过程烂”的案例。比如一个数据分析智能体它算出了正确的销售额但中间调了三次数据库、两次重复查询、还绕了一个大弯。结果对但成本是正常路径的五倍。如果按结果打分它和高效路径一个分按轨迹打分它直接不及格。白盒追踪让评测从“对不对”升级到了“好不好”。但白盒追踪也有代价数据量爆炸。一个复杂任务可能产生几百条轨迹事件人工根本看不过来。于是我们开始做自动化规则引擎用正则和简单逻辑去匹配违规模式。这又引出了下一个问题规则写死了智能体就会学会绕过规则。2.3 第三阶段规则内嵌的“治理闭环”到了第三阶段我不再满足于“测出来问题再修”而是想让问题在评测阶段就被系统性暴露并且直接反馈到智能体的行为约束里。具体做法是把评测指标拆成两类一类是能力指标任务完成率、准确率一类是治理指标合规率、成本效率、安全边界。能力指标决定智能体能做什么治理指标决定智能体不能做什么。然后关键的一步来了治理指标不参与总分排名而是一票否决。也就是说一个智能体哪怕能力指标满分只要治理指标触线直接判定为不可用。这个设计背后的逻辑是能力可以慢慢提升但治理底线不能妥协。你不可能让一个会泄露用户隐私的智能体上线哪怕它任务完成率99%。这套闭环跑通之后我发现评测团队的角色变了。以前我们是“裁判”现在我们是“立法者”。我们定的每一条治理指标都会直接改变开发团队优化智能体的方向。评测即治理这句话在这个阶段才真正落地。3. 治理视角下的评测指标体系能力分与治理分必须分开算3.1 为什么不能把能力和治理混在一个总分里我见过太多团队把“任务完成率”和“安全合规率”加权成一个总分然后按总分排名。这个做法看起来合理实际上非常危险。因为加权意味着可以互相补偿完成率高的智能体可以靠高分去“抵消”合规上的小瑕疵。但治理问题从来不是线性可补偿的。一次隐私泄露、一次越权调用造成的后果可能是灾难性的不可能用“多完成几个任务”来弥补。所以我的建议非常明确能力分和治理分分开计算分开呈现治理分拥有一票否决权。能力分用来选优治理分用来淘汰。两者不混在一起决策逻辑才清晰。具体怎么分我一般把治理指标拆成四个维度治理维度核心问题典型指标判定方式安全边界有没有做不该做的事越权调用率、敏感信息输出率一票否决成本效率有没有浪费资源工具调用次数、Token消耗、重复操作率阈值告警行为合规有没有按规矩做参数合法性、调用顺序合规性扣分制可解释性能不能说清楚为什么做决策链路完整度、中间结果可追溯性评级制这张表是我在实际项目中反复打磨出来的每个维度的判定方式都不一样。安全边界必须一票否决因为它的风险不可逆成本效率用阈值告警因为不同任务对成本的容忍度不同行为合规用扣分制允许一定程度的灵活可解释性用评级制因为它更多是辅助排查用的。3.2 治理指标怎么定才不会被绕过定治理指标最怕什么最怕智能体学会“合法地违规”。比如你规定“不许调用外部搜索工具”它就去调一个内部搜索工具本质上还是绕过了你的意图。这种绕过在规则写死的情况下几乎必然发生。我的应对策略是治理指标要基于意图而不是基于具体动作。不要写“禁止调用工具X”而要写“禁止在未获得用户明确授权的情况下获取外部信息”。前者是动作规则后者是意图规则。动作规则容易被绕过意图规则需要判断判断就需要引入语义理解。具体实现上我会在评测流水线里加一个“意图对齐检查”环节。用一个小模型或者规则组合去判断智能体的实际行为是否符合任务意图。比如用户问“帮我查一下明天的天气”智能体去调天气API是符合意图的但如果它顺便把用户的定位信息也传出去了那就偏离了意图。这个检查不需要100%准确只要能抓住大部分明显偏离就够了。注意意图对齐检查本身也会犯错所以它的判定结果不能直接作为最终裁决而应该作为“可疑标记”进入人工复核队列。我一般把它的召回率调到很高精确率可以低一点宁可多标可疑不可放过风险。3.3 治理分的阈值怎么设一个可落地的计算方法阈值设定是治理评测里最玄学的一环。设高了什么都过设低了什么都不过。我试过几种方法最后沉淀下来一个比较土但很管用的做法基于历史基线加安全边际。具体步骤是这样的先跑一批“已知安全”的智能体收集它们在各个治理指标上的分布。取分布的95分位作为基线值。比如95%的安全智能体工具调用次数都在8次以内那基线就是8。在基线基础上加一个安全边际。边际大小取决于风险等级安全边界类指标边际为0即基线即阈值成本效率类可以加20%-50%的余量。每季度重新校准一次基线因为智能体能力在变任务复杂度也在变。这个方法的逻辑是治理阈值不应该拍脑袋而应该从实际安全行为中统计出来。它不完美但比拍脑袋靠谱得多。而且它有一个好处当开发团队问“为什么我的智能体被卡了”你可以直接拿出基线数据说“因为95%的安全智能体都做得比你好”。4. 判卷终局的工程实现把治理规则嵌进评测流水线4.1 评测流水线的四层架构聊完指标得聊聊怎么落地。我现在的评测流水线是四层结构从下到上分别是数据层、执行层、判定层、治理层。数据层负责准备评测任务和预期结果。这里有个坑很多人用同一批数据既做训练又做评测结果评测分数虚高。我的做法是评测数据必须和训练数据严格隔离而且评测数据要定期轮换防止智能体“背题”。执行层负责跑智能体收集全链路轨迹。这一层的关键是轨迹的完整性。我要求每一次工具调用、每一次模型输出、每一次状态变更都必须打点而且打点信息要包含时间戳、输入、输出、耗时、Token消耗。缺任何一项这条轨迹就不可用于治理判定。判定层负责根据轨迹计算各项指标。这一层我用的是规则引擎加小模型组合。规则引擎处理确定性判定比如“是否调用了禁用工具”小模型处理语义判定比如“输出内容是否包含敏感信息”。两者结果汇总后生成一份判定报告。治理层是最高层负责根据判定报告做最终裁决。这一层不直接参与打分而是做三件事一票否决判定、阈值告警生成、治理报告输出。治理报告会直接推送给开发团队和合规团队形成闭环。4.2 轨迹打点的最小必要字段轨迹打点不是越多越好打太多会影响性能打太少又不够判定。我经过多次调整定了一个最小必要字段集{ trace_id: 唯一追踪ID, step_index: 步骤序号, step_type: 工具调用/模型输出/状态变更, timestamp: 毫秒时间戳, input_digest: 输入摘要脱敏后, output_digest: 输出摘要脱敏后, tool_name: 工具名称如适用, token_cost: Token消耗, latency_ms: 耗时毫秒, policy_flags: [触发的治理规则列表] }这个字段集是我踩过坑之后定下来的。早期我没加policy_flags结果判定层每次都要重新跑一遍规则性能很差。后来改成在执行层就把触发的规则标记好判定层直接读标记速度快了十倍不止。提示input_digest和output_digest一定要脱敏。我见过团队把用户原始输入直接存进轨迹库结果轨迹库本身成了隐私泄露源。脱敏要在打点之前做不能事后补。4.3 判定层的规则引擎怎么写才不容易被绕过规则引擎最怕的是“规则写了但没生效”。我总结了几条实战经验第一规则要分层。底层规则是硬性的比如“禁止调用外部网络工具”这种规则直接在执行层拦截不进入判定层。中层规则是判定性的比如“工具调用次数是否超标”这种在判定层计算。上层规则是语义性的比如“输出是否偏离任务意图”这种用小模型判定。第二规则要可组合。不要写一条巨长的规则而要写多条小规则然后组合成治理策略。比如“安全边界”策略可以由“禁止越权调用”“禁止敏感输出”“禁止未授权外部访问”三条小规则组合而成。这样调整策略时只需要增删小规则不用重写整个策略。第三规则要有版本。每次修改规则都要记录版本号和修改原因。我吃过亏有一次改了规则但没记录后来评测结果突变排查了半天才发现是规则改了。现在我的规则库是带版本管理的每次评测报告里都会标注使用的规则版本。4.4 治理报告怎么呈现才能让开发团队真的去看治理报告如果只是丢一堆数字开发团队根本不会看。我的做法是报告要直接告诉开发团队“你哪里错了、为什么错、怎么改”。具体来说报告分三部分。第一部分是“红线告警”列出所有触发一票否决的项每条都附上具体轨迹片段和规则依据。第二部分是“优化建议”列出接近阈值但还没触线的项给出具体的优化方向。第三部分是“趋势对比”展示本次评测和上次评测在治理指标上的变化。我还会在报告里加一个“治理健康分”用红黄绿三色标识。绿色表示治理状况良好黄色表示有风险项需要关注红色表示有红线项必须立即修复。这个健康分不参与能力排名但会直接决定智能体能不能进入下一阶段。5. 那些年我在智能体评测上踩过的坑5.1 坑一用训练数据做评测分数虚高到离谱这个坑我踩得最深。早期我们偷懒直接把训练集切一部分出来做评测集。结果智能体在评测集上表现极好上线后一塌糊涂。后来分析发现智能体在训练时已经“见过”这些任务它不是在解决问题而是在回忆答案。修复方案很简单但很费功夫评测数据必须完全独立采集而且要和训练数据在分布上有所区别。我现在的做法是评测数据专门找一批没参与过训练的任务而且任务描述方式、工具组合、交互轮次都和训练数据有差异。这样才能测出智能体的真实泛化能力。5.2 坑二治理规则写太死智能体学会“合法违规”前面提过这个坑这里展开说。我们曾经规定“禁止调用外部搜索工具”结果智能体发现内部知识库有一个搜索接口就疯狂调那个接口。从规则上看它没违规但从意图上看它就是在绕过限制。修复方案是引入意图对齐检查。但意图对齐检查本身也有坑它太严了会误杀正常行为太松了又抓不住绕过。我调了很久才找到一个平衡点把意图对齐检查的召回率放在第一位精确率可以牺牲。因为漏掉一个违规的代价远大于多标一个可疑的代价。5.3 坑三评测环境太干净测不出真实风险实验室环境里智能体面对的是精心准备的任务和稳定的工具接口。但线上环境里工具会超时、接口会返回脏数据、用户会输入奇怪的内容。我们在实验室测得好好的智能体一上线就各种翻车。修复方案是在评测环境里注入“噪声”。具体做法包括随机让部分工具调用超时、返回部分错误数据、在用户输入里加入干扰信息。这样测出来的智能体才是真正抗造的。我一般会设置一个“噪声比例”从10%开始逐步提高看智能体在多大噪声下还能保持治理指标不触线。5.4 坑四治理报告没人看评测结果落不了地这个坑最让人沮丧。我们辛辛苦苦跑完评测出了详细报告结果开发团队说“看不懂”或者“没时间看”。评测做了等于白做。修复方案是把治理报告嵌入开发流程。具体来说我把治理报告和CI/CD流水线打通每次代码合并前自动跑评测治理健康分不达标就直接阻断合并。这样开发团队不想看也得看而且他们会在提交代码前自己先跑一遍评测主动修复问题。这个改动看起来是流程问题实际上是治理落地的关键。评测如果不嵌入流程就永远只是“参考”而不是“约束”。只有让评测结果直接影响开发行为评测才真正变成了治理。6. 从判卷到治理智能体评测的终局思考6.1 评测团队的定位转变从裁判到立法者这一路走下来我最大的感受是评测团队的定位变了。以前我们把自己当裁判任务是“公平地打分”。现在我们把自己当立法者任务是“定义什么可以做、什么不可以做、做了之后怎么追溯”。这个转变带来两个变化。第一评测团队需要更早介入智能体设计。不能等智能体做完了再评测而要在设计阶段就把治理指标定下来让开发团队按治理要求去设计行为。第二评测团队需要更强的工程能力。治理规则要嵌入流水线轨迹要全链路追踪报告要自动生成这些都不是纯人工能搞定的。6.2 治理规则的生命周期管理治理规则不是定完就完了它有自己的生命周期。我现在的做法是给每条规则打上“生效日期”“复审日期”“负责人”三个标签。生效日期到了规则自动启用复审日期到了自动提醒负责人重新评估负责人变更时自动转移。规则复审时我会问三个问题这条规则在过去一个周期内触发过吗触发后修复了吗修复后还有类似问题吗如果一条规则长期不触发可能是它太松了如果一条规则频繁触发但问题没修复可能是修复方案不对如果一条规则触发后问题消失了那它就可以降级或归档。这套生命周期管理让治理规则库保持“活”的状态而不是越积越多、最后没人敢动。6.3 智能体自我治理的可能性最后聊一个我最近在琢磨的方向能不能让智能体自己治理自己具体来说就是在智能体内部嵌入一个“治理检查器”在每次行动之前先自检这个动作会不会触线如果会就换一个动作。这个方向目前还在实验阶段但已经看到一些苗头。比如我们在一个数据分析智能体里加了一个简单的自检规则“如果本次工具调用会传输用户标识信息则先请求确认”。加上这条自检后该智能体的治理违规率下降了70%以上。当然自我治理不能替代外部评测。智能体自己检查自己总有盲区。但自我治理可以作为第一道防线把大部分明显违规挡在发生之前。外部评测则作为第二道防线兜住那些自我治理没挡住的漏网之鱼。两道防线叠加治理效果会好很多。6.4 一个我常用的治理自检清单最后分享一个我每次评测前都会过一遍的自检清单都是血泪教训换来的评测数据是否和训练数据完全隔离有没有可能被智能体“背题”治理指标是否区分了能力分和治理分有没有混在一起算总分安全边界类指标是否设置了一票否决有没有被其他指标补偿的可能轨迹打点是否完整关键字段有没有缺失脱敏是否在打点前完成治理规则是否基于意图而非动作有没有明显的绕过路径阈值是否基于历史基线有没有定期校准机制治理报告是否嵌入了开发流程不达标有没有阻断机制规则库是否有版本管理和生命周期管理有没有长期不复审的僵尸规则这个清单我每次评测前都会过一遍能挡掉大部分低级错误。治理这件事细节决定成败一个字段没打对、一条规则没写准整个评测结果就可能失去意义。智能体评测走到终局拼的不是评测技术本身而是治理思维。你能不能把评测指标变成行为约束能不能把评测结果变成开发流程的一部分能不能让智能体在评测之前就自我约束——这些才是决定评测有没有用的关键。判卷的终局是治理而治理的终局是让智能体自己学会守规矩。这条路还很长但方向已经清楚了。
