Agent 体检：乱编、连锁、失忆，给 Agent 做一次五维体检

AI 健康三部曲 · 第 2 篇（Agent 体检）

上一篇，体检的是"单个 Skill 写得好不好"------静态资产。

这一篇，视角升一级：Agent 系统。它们会跑、会错、还会把错误传下去。

三个病例，都在正常"跑"：

编程助手乱编 API------换更强的模型，还是编；

5 个 Agent 的流水线------每一环都"干完了活"，最后一环收到了全错的输入；

客服记忆越加越贵------每轮对话都躺在 prompt 里，效果反而越来越糊。

它们病的位置，和喊疼的位置，都不在同一处。

一、Agent 的病，为什么比 Skill 更难发现

上一篇体检 Skill，操作很直接：扫一遍文件、逐项打勾，谁好谁坏一目了然。

Agent 系统是另一个物种------它是动态的。这个区别带来三个麻烦：

麻烦 1：症状出现的位置，不是病因的位置。

编程助手乱编 API，看起来是"模型能力不行"。你换更强的模型，还是编。

真正的病因可能在别处：整个防御体系里，负责"发现编造"的那个环节，选错了工具。盯着症状修，永远修不到点上。

麻烦 2：错误是结构性的，不是单点的。

单个 Agent 出错，是一次事故；多个 Agent 出错，可能是结构缺陷------不是"某一环错了"，而是"错误可以一路传递"这个事实本身。结构不改，每一环都在正常工作，结果整体是错的。

麻烦 3："在跑"会掩盖一切。

系统不报错、有输出、任务"完成"了------只是结果是错的。没人报警，因为看起来一切正常。

Skill 腐化你还看得见（版本号打架、护栏缺失，白纸黑字摆在那）；Agent 腐化藏在运行轨迹里，你不主动查，它永远"看着挺好"。

所以我需要一个能从结构层 下刀的体检器。这就是今天的主角：agent-arch-inspector------Agent 架构审查器。

它的定位很有分寸：只出报告，不改代码。像体检医生------拍片、出报告、告诉你哪有问题、该挂哪个科；手术做不做、怎么做，你自己决定。

二、五维体检器：从五个地方下刀

体检器开了五个"检查窗口"，正好对应 Agent 系统最容易病的五个部位：

该不该用 Agent------很多系统的病根在选型。用错了架构，后面全是在错误的地基上装修；
防幻觉设计------编造能不能被拦住；
质量保障------上一步的错误，能不能传到下一步；
记忆设计------是真记忆，还是伪装成记忆的日志；
自改进能力------"越用越聪明"是有证据，还是营销话术。

顺序不是随便排的：选型排最前，因为选型不过关，后面四个窗口只做"止损评估"，不再深入------架构选错了，防幻觉和记忆做得再好，也是给错误的架构打补丁。

体检流程分 5 步：

vbnet 复制代码

┌──────────────────────────────────────────────────────┐
│             agent-arch-inspector 体检工作流          │
├──────────────────────────────────────────────────────┤
│                                                      │
│  Step 0  情绪拦截   先共情，再审查                   │
│    │                                                 │
│  Step 1  对象定位   形态 / 数据 / 痛点 三件事实      │
│    │               → 预勾选审查维度                  │
│    │                                                 │
│  Step 2  选型漏斗   选型不过关 → 后四维只做止损评估  │
│    │                                                 │
│  Step 3  深度审查   现状 / 缺口 / 反模式 / 证据      │
│    │                                                 │
│  Step 4  报告输出   一句话结论 + P0/P1/P2 修复清单   │
│                                                      │
└──────────────────────────────────────────────────────┘

两个设计细节单独说：

Step 0 是"情绪拦截"。 来做体检的人，很多是刚被 Agent 坑了的（"它老是乱编！"）。带着情绪做审查，结论会被情绪带偏。所以第一步是共情，然后才开始结构化检查。

Step 4 有一条可读性铁律。 报告是写给不懂方法论的人看的------内部的维度代号、专业说法，不许原样抛给用户，必须翻译成人话。后面第七节你会看到，这条铁律是被用户的真实反馈逼出来的。

另一个贯穿全局的原则：每个结论必须有证据。引用哪个文件、什么行为、哪条运行数据------写不出来，就写"无证据，跳过"。宁可比实际少判一项，不虚构证据。

三、现场一：乱编 API 的编程助手

病例描述（体检器验证集里的高频场景）：

"我们公司的 AI 编程助手老是编造不存在的 API 和函数名，明明没有这个方法它说有，团队现在都不敢信任它了。它的架构是这样的：有个 CLAUDE.md 写了些规则，代码生成靠 ReAct 循环，写完会跑一下 lint------但经常 lint 过了还是乱引用。"

体检切口：防幻觉设计。

先说结论：它不是没有防御------规则文件有，lint 也有。问题是，它的防御漏在了最关键的一层。

防幻觉有一张四层清单，从便宜到贵：

层级	干什么	这个系统的现状
写规则	规则文件里写"诚实条款"	⚠️ 有规则文件，缺强制验证条款
改流程	写代码前必须查证	❌ 无
上检查	自动拦截编造	⚠️ 有 lint，但选错了检查器
加对抗	让另一个 AI 专门挑刺	❌ 无

两个关键误诊点，展开说。

关键 1：lint 只管"代码写得规不规整"，不管"引用的东西存不存在"。

调用一个不存在的函数 validateToken()，语法完全合法------lint 一路全绿。

你要的是"引用存在性检查"，那就得用对工具：TypeScript 上 tsc / LSP，Python 上 pyright，这类能解析符号表的检查器才能发现"这个函数不存在"。

这里还有一层更细的坑：grep 也只能算半个证据。grep 只能证明"这个字符串在文件里出现过"，不能证明"它可调用"------TODO 注释、被注释掉的废代码、README 里的示例，全都能骗过它。

关键 2：错误必须回到上下文里。

有的系统也配了自动检查，但检查结果只写进日志文件------模型看不到错误，下一轮继续自信地编。检查器要"快"（3 秒内出结果，慢了就会被绕过）且"吵"（错误拍回当前对话）------静默的检查，等于没有检查。

这个病例的一句话结论是这样的：

一句话结论：乱编问题不在模型，在检查器选错了类型。必修项两条：把 lint 换成能查引用存在性的检查器；在规则文件最显眼的位置写"诚实条款"。

诚实条款怎么写？ 核心心法就一句：

不要试图消灭幻觉------做不到。要做的是让编造的代价远高于诚实。

三个动作：

声称某个符号存在前，必须验证------无法验证时，明确说出来；
"不知道"不惩罚，编造才惩罚------被惩罚过"说不知道"的模型，下次更倾向猜；
规则放在文件前 50 行------那里是注意力最集中的区域，规则要短、要狠、要写踩过的坑，不写废话说明书。

最终报告里的修复清单长这样（P0 = 必修，只做 P0 就是最小改动路径）：

优先级	做什么	为什么	改动量级
P0	检查器升级：lint → tsc / pyright	lint 查不出不存在的引用，这是乱编的直接出口	小
P0	规则文件前 50 行写"诚实条款"	规则放在注意力区域才有效	小
P1	写代码前强制查证（read / grep / tsc）	把验证从"自觉"变成"流程规定动作"	中
P1	commit 前加独立 fact-checker	另一双眼睛专挑刺：只查证不写代码，产出"已核实 / 有误 / 无法核实"三类结论	中

这个病例的复盘一句话：它一直在修模型，其实该修的是检查器。

四、现场二：5 个 Agent 的流水线，错误为什么能传到最后一环

病例描述：

"我搭了一个 5 个 agent 的流水线做代码开发：需求拆解 → 设计 → 写代码 → 补测试 → 写文档，每个 agent 把产出传给下一个。我担心前面的错误会一路传下去最后全错，这种流水线架构怎么审查？"

体检切口：质量保障。

体检先做一个结构判定：这套系统是"串联"还是"互锁"？

串联：每个环节只管"接着干"，不管"上一步对不对"→ 前一个错了，后一个接着错；
互锁：上一环节没通过，下一环节物理性无法启动（借鉴电气系统的连锁机制）→ 错误层层被拦截。

这个病例是标准的串联。所以那句"我担心错误一路传下去"------不是多虑，是数学：

单环节正确率 80%，串联 5 环：0.8⁵ ≈ 33%；串联 10 环：0.8¹⁰ ≈ 11%。

单环节正确率	5 环节串起来	10 环节串起来
90%	59%	35%
80%	33%	11%

注意使用纪律：这不是精确预测------单环节正确率要取你系统的实测值，取不到就用保守的 80%。公式的作用只有一个：让你直观感受串联的损失规模。每个 Agent 单看都是"挺靠谱的"，串起来，结果是灾难。

第二刀，查四类互锁点：

互锁模式	检查问题	这个系统
测试互锁	测试没跑通，任务能不能算"完成"？	❌ 测试在代码之后------顺序反了
架构互锁	跨层调用会不会被打回？	❌ 无卡口
文档互锁	实现偏离设计会不会阻断？	❌ 无
验证互锁	覆盖率不足会不会被打回？	❌ 无

四枪全空。这一刀的核心洞察：

不是让一个 Agent 更聪明，而是让 Agent 集群的错误无处传递。

修复的最小路径（P0）两条：

测试前置：测试 Agent 先动、代码 Agent 后动。测试没跑通 → 代码任务无法完成。注意：这是硬约束，不是"建议你跑一下测试"；
加架构卡口：AI 跨层直接调用 → 架构扫描报警 → 直接打回，从"写在 Wiki 里偶尔违反"升级为"物理隔离一样的强契约"。

顺带说人的角色变化，这是我在这个维度里最想强调的一条：

互锁体系里，人负责设计"谁锁谁、锁的规则、熔断条件"，并当弱连接的最终裁判。如果这条流水线还需要人逐行 review 才敢上线------说明互锁没建起来。

五、现场三：越塞越贵的客服记忆

病例描述：

"我想给客服 Agent 加记忆功能，让它记住用户偏好和历史。现在的做法是把每轮对话存进日志文件，需要的时候全文塞进 prompt。感觉效果很一般，还越来越贵。帮我审查一下这个记忆设计该怎么改。"

体检切口：一个是选型，一个是记忆------双维度。

这个病例最有趣：用户来问"记忆怎么改"，体检结果第一句话是------你这套系统，首先不该是 Agent。

问题 1：客服场景，问题可枚举 → 应该用固定流程。

选型漏斗的三连问，走到第一问就停了：

任务完成度能一次性判定吗？------客服问答能 → 不需要循环，固定流程就够了。

客服是什么场景？问题可枚举（退款 / 物流 / 改地址），用户要的是"快 + 可解释"。给它上 Agent 循环，等于给"办证窗口"配了个"探险家"：延迟 ×5-10、成本 ×3-5，还是黑盒的。

这条心法请记住：Agent 是少数，不是默认。

问题 2：日志不是记忆。

就算继续用 Agent，记忆这块也不及格。记忆有"七问清单"，拿它过一遍这个系统：

记什么？✅ 对话记录（勉强算）
存在哪？✅ 日志文件
怎么找？❌ 全文塞 prompt------没有检索，全靠"倒"
怎么压？❌ 无
怎么忘？❌ 无------只进不出

后三问全空。而记忆的本质是四件事：存、查、改、删。

类比一下：这不算记忆，是把所有便签一股脑塞进抽屉。真正的记忆是"这件事这样做有效，下次就这么干"------它需要查得到 （检索）、需要会淘汰 （旧的清出去）、需要能纠错（发现记错了要改）。

上下文窗口 ≠ 记忆。 把历史全灌进 prompt，既贵（token 成本 ×N）又糊（无关信息淹没重点）。

修复清单（P0）两条：

主流程改造：Agent 循环 → 固定流程（问题分类 → 固定分支）。这一条能同时省掉延迟和成本；
补"查 / 忘"能力：加检索（向量相似度）+ 淘汰机制（时间衰减 / 预算阈值）。先让记忆配齐"四件套"，再谈优化。

六、第五维：给"越用越聪明"打假

三个现场拆完，五维还剩最后一维：自改进。它单独成节，因为它是最容易被营销话术污染的一维。

先看光谱。自改进能力从低到高分六级：单次任务内自我修正 → 跨会话记忆沉淀 → 系统化搜索配置 → 对抗训练 → 自我修改机制 → 编排层自动迭代。

我见过的、宣称"自进化 / 越用越聪明"的系统，大部分实测只到前两级。

怎么打假？体检器上个月刚加了三条硬检验（来源：字节自进化论文 + AgentLoop 实测数据）：

检验	问什么	反例信号
提升发生在哪	只在可见反馈集上提升，还是 held-out 集上也提升？	可见集 +13.9 vs held-out 仅 +1.43 → 过拟合训练数据
自评判可信吗	自己给自己打的分，和实际改进相关吗？	相关性 r = -0.23，接近零相关 → 自评高分不构成证据
验收口径	看单次评测通过率，还是多次执行的稳定性？	Agent 天然不确定、路径非唯一，单次评测没有统计效力

判据一句话：宣称进化，但拿不出 held-out 对照或多次执行分布的------一律按"未验证的进化"处理。

再记住一条区分：自动化 ≠ 自我改进。

"每天定时把固定流程跑一遍"是自动化；"改进流程本身"才是自我改进。这两件事看起来都像"系统在进化"，但差了十万八千里。

七、这个体检器，自己也摔过两跤

按这个系列的规矩（上一篇，体检器先查出了自己的 8 个"假 0 分"），继续自曝。

第一跤：报告没人看懂。

初版报告里直接写"防幻觉第三层缺失、互锁未建立"这种话。首轮测试的反馈只有三个字："没看懂。"

问题不在用户------是我的报告在自嗨。体检报告是给人看的，不是展示我懂多少术语。于是有了那条"可读性铁律"：内部代号不进报告，全部翻译成人话。

翻译对照大概是这样：

内部说法	报告里怎么写
选型合理性	该不该用 Agent
串联	错误一路传递的流水线
互锁	上一步不过关，下一步跑不起来
对抗层	加对抗验证（让另一个 AI 挑刺）

还加了两条输出纪律："一句话结论"必须最先出现（用户可能只看这一句，它必须独立成立）；修复清单必须有"为什么"一列（用户不信"方法论说该这样"，只信后果）。

第二跤：误触发。

体检器的边界测试一度 20 条错 3 条------"帮我写个 agent 代码""搭个聊天页面""评估某个 Skill 的质量"全被误判成"要审查"。根因：触发词的收尾句写太宽（"只要涉及 Agent / AI 应用"）。

修法：收紧边界 + 明确列出"不触发"清单（写代码、搭页面、性能排查、写 PRD 都不归它管）。复测 20/20。

这两跤的共同点：工具的边界感，比工具的能力更影响信任。

八、你也能用：三种用法

体检器可以跑任意 Agent 系统------自研的、社区的、项目里的。三种用法：

1. 完整体检（默认）

复制代码

你：审查一下这个 Agent 的架构
或：帮我评估一下要不要上 Agent 还是固定流程

输出完整报告：一句话结论 → 体检结果表（该不该用 / 防幻觉 / 质量保障 / 记忆 / 自改进）→ 详细诊断 → P0/P1/P2 修复清单。

2. 专项体检（只查一维）

复制代码

你：帮我审查一下它的防幻觉设计哪里有问题
或：帮我审查一下这个记忆设计该怎么改

只对指定维度深查，适合"我已经知道哪里疼"的情况。

3. 三色快评（只要快速意见）

复制代码

你：给这个 Agent 系统一个快速意见

跳过深度诊断，直接输出红黄绿三色结论 + 最优先修的一项。

适用 / 不适用

适合	不适合
审查 Agent 系统的架构设计（选型 / 防幻觉 / 互锁 / 记忆 / 自改进）	写 Agent 代码、搭聊天页面（那是开发，不是审查）
上线前做架构决策评审	性能排查、Bug 定位（那是调试）
Agent 项目复盘：找出"为什么一直乱编 / 一直贵"	审查单个 Skill 的质量（用 skill-inspector，上一篇）
评估"要不要上 Agent"这个提案本身	体检整个 Skill 体系（用 system-health，下一篇）

九、速记表

你想做什么	用什么
给 Agent 系统做架构体检	agent-arch-inspector（五维审查 → P0/P1/P2 清单）
只要快速意见	三色快评：红黄绿一句话
防幻觉专项	指定维度：防幻觉设计检查
记忆专项	指定维度：记忆架构审查
体检单个 Skill	skill-inspector（上一篇）
体检整个 AI 体系	system-health（下一篇）
验证"越用越聪明"	要 held-out 对照 + 多次执行稳定性，别信自评分

这次体检的核心结论一句话：Agent 系统的问题，九成能在"选型 / 防幻觉 / 质量保障 / 记忆 / 自改进"五个窗口里找到位置；剩下的关键，是别让术语挡在你和答案之间。

避坑指南

问题现象	原因	解决方法
lint 全绿，但引用都是编的	lint 查语法，不查"引用存在性"	换 tsc / pyright；写码前强制 read / grep 查证
Agent 越加越多，错误照传不误	串联结构，没有互锁点	测试前置 + 架构卡口，错误不入下一环
检查器配了，模型还继续编	错误进了日志，没回到上下文	检查结果必须拍回当前对话，静默检查等于没查
记忆越用越贵、越用越糊	日志全文塞 prompt，只存不查不删	补检索 + 淘汰；控制注入预算
"越用越聪明"无法验证	只看可见反馈集 + 自评分	要 held-out 对照 + 多次执行稳定性
报告看不懂、没人用	术语代号直接抛给用户	一句话结论先行 + 全部翻译成大白话

十、常见问题（Q&A）

Q1：我的系统只有一个 Agent，也需要互锁吗？

单 Agent 不存在"错误传递"问题，互锁不是必选项。但单 Agent 仍然要查防幻觉和选型------尤其是"这个任务其实用固定 Workflow 就够了"的情况。

Q2：用了 RAG 就不用 Agent 了吗？

不一定。RAG 解决的是"知识检索"，Agent 解决的是"多步决策"。如果任务可枚举、完成标准明确，RAG + 固定流程通常更便宜、更快、更可解释；只有下一步必须由模型决定时，才需要 Agent。

Q3：防幻觉四层必须全做吗？

不必。多数系统把 L1 规则层 + L2 协议层 + L3 自动化层做好，就已经能拦住 80% 的编造。L4 对抗层适合对准确性要求极高、且愿意承担额外成本的场景。关键是"每一层都真的有咬合"，不是"每一层都存在"。

Q4：记忆一定要用向量数据库吗？

不是。向量库适合"语义检索"，但如果记忆主要是结构化事实，关系型数据库 + 简单查询可能更稳、更便宜。选存储前先回答"记什么、怎么找、怎么忘"三问，storage 选型是第二步。

Q5：怎么判断"越用越聪明"是真的？

看三个证据：held-out 集上是否也提升、自评分和实际改进是否相关、有没有多次执行的稳定性数据。三者缺两个以上，就按"未验证的进化"处理。

Q6：审查报告出来了，谁来落地修复？

agent-arch-inspector 只出报告，不改代码。修复通常由开发团队按 P0/P1/P2 分级执行。建议把报告直接 attach 到迭代计划里，而不是只在群里发一次。

写在最后

三个现场，三种病，其实是一条主线：

Agent 系统的质量问题，很少是"某个环节不够努力"，大多是"结构上让错误有路可走"。

防幻觉是给"编造"设路障，互锁是给"错误"建卡口，记忆是给"上下文"做减法，选型是给"复杂度"踩刹车------四件事在做同一件事：收窄错误能走的路径。

所以这篇最想立的立场是：不要指望让 Agent 变得更聪明，先让它错得不那么顺理成章。

今天是三部曲的第二篇------中观视角，体检的是"一个 Agent 系统架构得好不好"。

下一篇，视角再升一级到全体系：幽灵注册、版本漂移、文档失联------AI 体系失控的三种方式。11 项检测，15 分钟摸清一个体系的家底。

我们下篇见。

本文相关产出：

体检器：skill/agent-arch-inspector/（SKILL.md + 5 个维度审查参考 + 报告模板）

方法论来源：知识库 5 篇 Agent 架构方法论（选型 / 防幻觉 / 互锁 / 记忆 / 自改进）

边界测试：触发词 eval 集（20 条用例，误触发从 3 → 0 的完整记录）

想要本文的完整体检脚本？

体检器（agent-arch-inspector）+ 五维审查清单 + 报告模板------都已打包好，评论区留言或私信我，直接发你。