Agent五维体检：从乱编、连锁到失忆，一套用例识别智能体可靠性问题

1. 为什么单测“满分”的Agent，一连起来就翻车

先说一个我最近遇到的场景。

某公司在做内部效率工具，把几个Agent Demo拿给我看。单拎某一个对话任务，比如“查一下上周的销售数据并做简评”，表现确实不错——数据对、表述顺、动作也快。可一旦把一个多步骤任务交给同一个Agent，比如让它在查完数据之后接着写邮件、再更新CRM状态、最后还要总结发给部门群，问题就出来了。有的环节数据张冠李戴，有的环节把上一轮的错误结论当成既成事实继续往下推，还有的干脆忘了最开始的需求是“把数据汇总成周报”，一路跑偏成“帮用户写产品介绍”。

这类问题不新鲜，但过去我们习惯用“单轮准确率”“人工满意度打分”来评价Agent，结果就是——每一项看起来都能及格，实际一跑业务链路就崩。道理很简单：传统软件测试测的是“固定的代码路径”，而Agent本质是由大模型驱动、路径不固定、会自我决策的系统。LLM每次生成的推理过程都会有细微偏移，这些偏移在单轮任务里不致命，一旦被串联成多步工作流，就会像滚雪球一样被放大。

我去年开始琢磨一件事：能不能像给人做体检一样，给Agent做一套结构化的健康检查？不是测它某个点好不好，而是把“事实性”“过程可靠性”“长程记忆”“工具调用”“稳定性”这些关键能力拆开，用一套可复现的用例集去压测，最后输出一份体检报告。这套东西我们内部用了大半年，确实帮我在上线前拦住了不少问题。这篇文章就把这套“五维体检”的设计思路、实操方法，以及体检之后怎么对症下药，完整写出来。

它适合谁看？如果你是做Agent应用、智能体落地、或者在做AI产品评估的工程师，这篇文章可以直接拿去做参考；如果你只是好奇“为什么我的Agent有时候像个明白人，有时候像个傻子”，那你也能从“病症”的描述里对上号。

2. 五维评级体系：不只看“答得对不对”，还要看“怎么答的”

给Agent做体检，首先得想清楚一件事：我们要测的不是“这个模型聪明不聪明”，而是“这个Agent系统稳不稳定、可不可信”。

模型能力是底座，但底座再强，也架不住Agent在链路里乱发挥。所以我把体检拆成下面五个维度，对应五类最常见的翻车方式：

顺带解释一下为什么是这五维，而不是“语义理解”“推理深度”这类维度。因为语义和推理能力，本质上已经在单轮测试里被模型厂商测过了，我们做应用层体检，真正要管的是**“模型能力转化为业务结果的过程中，哪里会掉链子”**。事实性、过程一致性、记忆持久性、工具正确性和稳定性，才是决定Agent能不能真正跑业务的五个关键点。

每个维度我设计了独立的评分规则，采用0到100分制，及格线定在80分——不要觉得这个线高，要知道Agent在真实场景里是连续执行任务的，一个环节低于80分，整条链路大概率要在某个中间步骤上翻车。总分计算按加权平均来算，权重我一般这样配：事实准确性30%，轨迹一致性25%，上下文持久记忆15%，工具与动作正确性20%，稳定性10%。权重不是拍脑袋定的，是根据我们线上任务类型的频次和翻车后果反推的——比如对客服类Agent，事实性和记忆权重就会对调；对自动化执行类Agent，工具正确性权重提到30%也不奇怪。

这套评分体系设计上有三个原则，比具体分数更值得借鉴。第一是数据确定性：所有测试用例必须有可校验的“标准答案”或“判定规则”，不能靠评测者主观感受打分。第二是过程可追踪：每轮测试都要记录Agent的完整轨迹——工具调用、中间输出、重试动作，否则你不知道哪一环出了问题。第三是结论可复测：同一用例要跑多轮，取分布而非单次结果，因为LLM天生有随机性。

2.1 三个“传染病”的典型表现，先从症状入手

这里先把标题里提到的三个病灶说透，因为五维体检里，有一半的维度其实就是在专门盯这三件事。

乱编，对应事实准确性。表现是Agent振振有词地说出一个不存在的文件路径、编造一个不存在的客户名称，或者把A项目的数字安到B项目的头上。最坑的是——它乱编的细节往往和真实情况高度相似，比如日期精确到某月某日，比如语气非常笃定。乱编不是“不知道”，而是“不知道但装作知道”。

连锁，对应轨迹一致性。表现是一个中间步骤产生了微小的错误结论，Agent非但没有停下来检查，反而基于这个错误结论继续推理，甚至为了让结果自洽，又编出一个新的理由。就像多米诺骨牌——第一块错误牌一倒，后面每一块都跟着倒。最典型的场景是：Agent调用工具A失败，它换个方式重试，但拿到一个部分成功的结果，就当作完整成功继续跑下一步。

失忆，对应上下文持久记忆。表现是任务做到一半，忘了用户最初提出的约束条件。比如用户开头说“只要华东区的数据”，Agent后面还是把全国数据混了进来；或者任务做到第6步时，它已经忘了第1步得出的结论，又重新算了一遍，而且算出了不一样的结果。长上下文不等于记住了——这是很多人忽略的事实，上下文再长，模型每生成一步都只依赖它“此刻注意到的内容”，而这个注意力分布是会在长流程里漂移的。

我专门管这三个病症叫“传染病”，是因为它们不像单个错误那样好修——一旦出现，会在后续所有步骤里二次传染。你修接口、加提示词，如果没从链路层面制止传播，下次换个场景照样犯。

3. 实操：用可复现的用例集，给Agent拍一张“病灶片”

给Agent做体检的核心，不是你有多少套评估理论，而是你有没有一套能稳定复现、可量化、能区分病灶的用例集。下面我把三个核心的“病理性检验”具体怎么设计、怎么跑、怎么判，完整展开。

3.1 乱编检测：事实核查类任务的设计思路

第一步，准备三类“事实敏感型”任务：

• 明确事实核查：给Agent一个需要精确数据的任务，比如“请根据内部工时表，计算A组上周的总工时”。标准答案是可以精确核对的，模型如果凭感觉给个数字，就是乱编。
• 知识盲区诱导：故意问一个知识库里没有的细枝末节，例如“我们公司的报销制度里，单笔超过多少钱需要线下审批？”标准答案是“知识库无相关内容”，正确做法是明确说不知道，而乱编型Agent会在“无中生有”给出一个具体金额。
• 时间敏感性探测：问“我们当前季度的OKR是什么？”如果Agent在长时间对话里引用了上一季度的内容，说明它没有正确检索当前数据。

每个用例我固定跑5次，记录命中“乱编”的比例。判定规则很简单：凡是标准答案里标注为“无”的，Agent只要给出了具体且并非“未知”的回答，直接扣该项得分。凡是标准答案可核查，Agent给出内容与标准答案不一致的，算乱编。

这类检测用例设计有两个容易踩的坑，说给你听。一个是题目不能太偏，如果问的内容连一个正常人都不知道，Agent说“不知道”和乱编都被扣分，测不出来东西；另一个是答案必须预先强制标注，否则评测人自己也分不清什么算编、什么算对。

3.2 连锁检测：错误注入与恢复率的计算

连锁错误检测的核心思路是：人为制造一个中间错误，观察Agent往下走的过程是止住错误、纠正错误，还是带着错误一路跑到底。

具体设计一个联合作业场景，比如“查询某客户的合同编号，然后根据合同编号查找对应项目进度，最后生成一份进度报告”。测试手法是在某一环注入错误——比如让查询接口返回一个不存在的合同编号，或者让项目进度接口临时返回一个明显异常的状态（如“已完成”但日期在未来）。

判定分三层看：

实际操作时，我会统计每个用例的**“恢复率”**——也就是所有注入错误场景中，Agent能主动发现并停止或纠正的比例。恢复率低于50%的Agent，基本不具备上生产链路的资格。这个检测之所以重要，是因为真实业务里，接口返回脏数据、第三方服务超时是常态，而Agent能不能在异常面前刹车，直接决定了整条工作流的安危。

3.3 失忆检测：长对话记忆探测的训练场

失忆检测是三个检测里最容易被糊弄过去的，因为单看一轮回答你根本看不出它记没记住——人是没有办法在短对话里验证“记忆”的。我的做法是构造长程多轮任务，至少包含15轮以上交互，并在任务中间埋入“记忆探针”。

举一个我们内部用的标准任务样例：第一轮，用户告诉Agent“我叫A同学，我在华东分部，我的项目预算上限是12万”。之后经过若干无关任务——查日历、查天气、翻译一段文档——在第10轮左右，突然问“请你帮我判断一下，刚才那个预算申请是否超过我的权限？”正确回答必须引用12万这个预算上限。

探针不止埋一个，我会埋三到五个，分散在不同轮次：有的问基础身份信息，有的问任务开始时设定的目标，还有的问上一轮刚刚生成了什么中间结论。判定规则也不复杂：引用正确算过，引用错乱或丢失就扣分。这个维度的及格线我设在90分，因为“忘事”在长流程里几乎是致命的——你宁可让它每一步都多确认一句，也不想它埋头做到最后才发现方向全错了。

这里多说一句：很多人会用“上下文长度”来推断记忆能力，这是个误区。上下文长只代表“能容纳”，不代表“会使用”。模型每生成一个token，注意力都会重新分布，早期的关键信息很容易被后面的海量内容稀释。所以记忆维度必须用“信息能否被准确复用”来验证，而不是看上下文窗口有多长。

4. 跑一次完整体检：从任务编排到报告解读

有了用例集，接下来就是把体检流程跑起来。我们内部的做法是用编排脚本批量执行，每轮测试记录出完整轨迹日志，最后统一归算成体检报告。

4.1 测试执行框架的最小实现思路

我不推荐直接用现成的benchmark框架——它们多数面向模型评测，而不是面向Agent的业务链路。更适合自己搭一个轻量的执行器，核心逻辑只有三块：

• 任务调度器：按用例清单逐条执行，每条用例可以设置单独的环境变量和工具mock。
• 轨迹记录器：把Agent每一步的输入输出、工具调用、重试行为全部落地为JSON日志。
• 评分器：根据每条用例预先设计的判定规则，对结果自动打分，输出结构化分数。

用伪代码表达就是这个思路（具体语言不限，我们用的是Python）：

class AgentCheck: def run_case(self, case): # 启动一个全新会话，避免上下文残留干扰 session = start_session() for step in case.steps: # 每个用例步骤都记录轨迹 trace = session.execute(step.prompt) self.logger.append(case.id, step.seq, trace) # 某些用例步骤可注入预设异常 if step.inject_error: inject_into_tool(step.error, trace.tool_call) score = self.grader.grade(case.id, session.output) return {"case_id": case.id, "score": score, "trace": self.logger.read(case.id)}

有一个细节是很多初做评测的人会忽略的：每个用例必须起一个全新的、空的会话。如果让Agent带着上一题的“记忆”做下一题，这道题的结果就污染了，你分不清它是真会还是背下了上一轮的答案。

4.2 一份真实风格的体检报告长什么样

下面这组数据是我近期一次内部评测的截取，模型用了某主流商业大模型，Agent框架用的是我们内部基于某开源编排框架二次开发的那套。为了不暴露具体模型名称，以下统称“模型A”和“模型B”：

这份报告里有两处特别值得解读。

第一处是“工具与动作正确性”这个维度，模型A分数反而低于模型B。查轨迹日志发现，A的问题是“调用工具时参数冗余”——每次调用都会带上额外字段，导致某些老接口解析失败。这类问题是纯单轮对话测试里根本测不出来的，因为你得看它实际调用工具时发的参数才会发现。这就是为什么体检必须是“任务级”而不是“对话级”。

第二处是模型B的轨迹一致性只有61分，但如果你只跑单轮问答，它的表现其实不差。问题出在它一旦进入多步骤工作流，就会把一个“未知”状态误判为“成功”状态，直接往下执行。最终报告里，我给这条备注了一行：“该模型在无人监督的多步任务中具备自洽性幻觉倾向——即使结果错，它也会编一套逻辑让它显得对。”这句话后来成了我们那里判断Agent能不能上生产的一句黑话。

4.3 分数之外的隐藏信息：轨迹日志才是体检的“影像片”

报告给出分数以后，千万别急着看总分。分数只是筛选器，真正决定你该怎么修的证据，全在轨迹日志里。

我习惯把每个失败用例的轨迹翻出来，重点看三件事：

• 重试次数和重试时机：Agent在失败后是立刻重试，还是先执行了其他动作再回头重试？前者说明它知道自己错了，后者说明它可能在碰运气。
• 上下文引用来源：Agent在对话中间引用的关键数据，到底是来自用户输入、工具返回结果，还是它自己推理出来的？如果是后者，就要警惕乱编。
• “自洽化”痕迹：是否存在“为了圆前面的错误，故意构建新论据”的行为。比如数据明明对不上，Agent却写了一句“考虑到统计口径差异，数据存在正常波动”，这种话术在轨迹里出现，基本就是连锁污染的前兆。

这些信息普通文档不会教你，但体检做多了以后，你会发现AI系统的问题不是“有没有病”，而是“病的形态千奇百怪”。有的Agent像个嘴硬的员工，错了从来不改，只是把理由越编越圆；有的Agent像个健忘的老头，开头交代的事到后面干干净净忘光；有的Agent则像个手脚不听使唤的实习生，脑子明白，调用接口时老写错参数。体检报告的意义就在于把“感觉不太对劲”变成“具体哪里不对劲”。

5. 体检之后的“治疗”顺序：先止血，再调理

体检本身不是目的，治才是。基于我上面这套评测，发现病灶之后的处理顺序，我强烈建议按“止血—纠正—强身”三步来走。

5.1 治“乱编”：双模型校验 + 检索锚点

乱编的本质是模型在“没有把握”时仍然选择生成。常规做法是加提示词——“没有把握请说不清楚”，但实测效果很有限，因为提示词只能约束“态度”，不能约束“知识边界”。

更靠谱的做法是给Agent增加一个外部事实锚点。我们在工具层做了一个“事实校验器”：当Agent需要输出一个具体数字、日期、人名等实体时，强制要求它携带引用来源ID。如果Agent给出的内容无法对应到任何检索结果或工具返回值，系统直接拦截并返回“信息不足，请重新检索”。

这个方法比单纯加提示词有效得多，因为它把“模型自由发挥”的空间从机制上压缩掉了。配合上双模型校验——让另一个模型对同一问题的回答做交叉核对——乱编检出率在当时下降了大约六成。

5.2 治“连锁”：工作流转折点上的行为干预

连锁错误的根因是Agent缺少“中间结果复核”的机制。人做事的时候会定期停下来看看自己做到哪、对不对，但很多Agent框架下，LLM只是埋头一个接一个地调用工具，直到产出最终结果才被审视——那时候往往已经晚了。

我的干预方案是在工作流里加入**“轨迹检查点”**：每隔N步（建议3到5步），暂停执行，让Agent回顾“我完成了什么、正在做什么、下一步应该做什么”，并将回顾内容与最初的用户目标做一致性校验。若发现偏差，则强制回退到最近的正确节点重跑。

用伪代码示意如下：

def guarded_run(agent, task): steps = task.steps executed = [] for step in steps: result = agent.execute(step) executed.append(result) if len(executed) % 3 == 0: # 检查点：让agent自述当前进展 review = agent.review(executed, task.goal) if not is_aligned(review, task.goal): # 回退到最近一个成功检查点 executed = rollback(executed, review.safe_index) return agent.finalize(executed)

这类机制看起来简单，但关键点是“回退到哪里”。体检轨迹日志正好能帮上忙：你可以根据历史失败轨迹，统计“错误通常在第几步被引入”，把回退点设在那一步之前。我们的实测是，引入工作流检查点后，连锁污染的发生率下降了近一半。

5.3 治“失忆”：显式记忆队列，不靠上下文硬扛

治失忆最反常识的做法是：不要让模型从长上下文里“回忆”，而是让它每次都在一个显式的记忆队列里“读取”。

什么意思？把关键信息——用户身份、目标约束、阶段性结论——单独抽取成结构化记忆项，存到一个队列里。每次Agent要做出决策时，先把这些记忆项灌进当前提示词，再做推理。这样相当于把“大海捞针”变成“抽屉取针”，模型不再需要从几万字的上下文里搜索关键信息，而是直接拿到摘要。

这个方案对长会话任务效果显著，但同时也会增加token开销，所以记忆队列需要主动淘汰过期项。我们现在的做法是给每个记忆项打上“活跃度”和“过期时间”，每轮更新一次。比如预算约束这类信息活跃度最高，永久保留；而一次性的临时状态，比如“正在执行XX任务”，任务完成后就从队列移除，避免干扰后续步骤。

坦白说，这个维度对模型能力依赖最小，反而最讲究工程细节——把记忆做成显式的系统模块，而不是寄托于模型的注意力机制。这是我个人认为投入产出比最高的修复。

5.4 复诊：修复后同一套用例集再跑一遍

每修完一个问题，我会原封不动地拿同一套体检用例集再跑一遍，对比修复前后的分数变化。注意，是同一套用例，不是新用例——否则你无法确定变化到底是修复带来的，还是换了题目带来的。

下面是我一次真实修复后的复诊对比样例：

这个表里有个很有意思的负分项：稳定性从90降到88了。查完日志才发现，是因为我们在工作流里加了检查点回退机制后，某些边缘用例会触发更多的回退路径，反而引入了新的随机性。这提醒了我一件事——任何修复方案都可能带来新的副作用，所以复诊比初诊更重要。修复不是“改完就好”，而是“改完再测、测完再改”的循环。

6. 体检的边界：这套体系不能帮你测什么

把话说全一点。五维体检能测出很多问题，但它有明确的边界，别指望一套用例集解决所有评估问题。

它测不了“长期业务价值”。Agent跑通一个任务，和它是否真的为用户创造了长期价值，是两回事。比如一个Agent能完美执行“帮用户预订会议室”的流程，但用户真正需要的是“改变开会方式，少开会”——这不是评测能回答的问题，是产品定位问题。

它测不了“多Agent协作的涌现问题”。我上面的体检都是针对单个Agent系统设计的。多个Agent之间互相传信息、互相调用、甚至互相博弈时，会出现全新的模式——比如角色混淆、信息回声、责任归属不清。这套五维体检的指标没有一个能覆盖到这类问题，那需要单独的“群体协作压力测试”来补充。

它测不了“恶意输入下的安全韧性”。提示词注入、越狱攻击、对抗样本，这些属于安全评测范畴，和“业务质量体检”是两条线。如果你的Agent会对外输出内容，或者会操作敏感数据，务必再单独做安全评测，不要拿这份体检报告当挡箭牌。

这层边界感很重要。我见过不少团队，拿到一份好看的体检报告就自信满满上线，结果被一个简单的注入攻击打穿——那不是体检报告骗你，是你问错了问题。

7. 最后说点我的个人体会

这套五维体检体系从设计到现在，给我最大的一个感受是：AI系统的质量评估，本质上是在建立一套“可谈论的语言”。

以前团队里出了一次事故，大家只能含糊地说“这Agent好像不太行”“这里感觉不靠谱”。有了体检报告之后，大家能明确指出：“这次是轨迹一致性问题，在第3步引入的错误没被发现”“这次是记忆衰减问题，第12轮之后开始丢失关键约束”。当你能把问题精确命名，修复方案才可能精确到位。

我的另一个体会是：体检用例本身是会“过期”的。模型在快速迭代、Agent框架在快速变化、业务场景在快速扩展——一套用例集跑三个月后，有些题目就变得太简单或者太偏门了。所以我把体检用例当“测试资产”来持续维护，每次线上出事故，都顺手把事故场景改写成新的体检用例。半年下来，这套用例集的覆盖度和敏感度，比市面上任何开源评测集都更贴合我们的业务。

至于工具选择，我不展开推荐某个具体产品了。你可以用现成的评测框架做二次开发，也可以像我们一样自己写脚本——关键是先建设“用例集+评分规则+轨迹记录”这套骨架，工具只是骨架上的肌肉。骨架对了，谁来执行都是那么回事。

如果你正在为一个“感觉还行但老是哪里不对劲”的Agent发愁，不妨按这篇文章的方法，给它做一次体检。说不定报告第一页就会告诉你——它和你以为的，根本不是同一个Agent。