AI Agent骨架工程：成功率卡在六成时先建评估与容错层

摘要：AI Agent外面那套负责把它跑起来的系统，业界现在叫harness，中文可以叫骨架。流行的讲法把它分成六层：上下文、工具、执行、记忆、评估、容错，并按这个顺序建。这个顺序是反的。六层的贡献很不平均：评估和容错两层合计撑起大约八成的稳定性，却通常排在最后，甚至被当成可有可无的收尾工作。业界至少还有三套互不兼容的拆法，其中只有一套能回答“下一步该改哪儿”。本文把三套放在一起对照，给出倒着建的顺序、每一层的实际投入产出、传感器具体装哪些，以及三种不该建的情况。最后用两篇2026年6月的论文说明：骨架不是永久护城河，更像一扇会关上的窗。

先说一个不太讨喜的观察。

保哥过去大半年见过的AI Agent项目，卡住的位置几乎一样：成功率停在六成到七成之间，怎么调都不动。团队的反应也几乎一样：回头改提示词，精简那份规则文件，换一个更贵的模型。三件事轮着做，一个月过去，成功率没有变化。

问题不在他们改的那些地方，而在于他们没有任何一个仪表能指出到底哪一层坏了。

AI Agent六层框架为什么不能当施工顺序？

现在讲AI Agent工程，几乎所有的图都是同一个样子：上下文（模型看到什么）、工具（模型能做什么）、执行（步骤怎么串）、记忆与状态（跨轮次记什么）、评估与观测（到底做对没有）、约束与容错（出错了怎么办）。六个盒子从上往下排成一列，箭头依次往下指。

作为分类，这套框架没有问题。它把散落在各处的实践收进一个能讲清楚的范畴，这件事有价值。“测试夹具”这个词在上世纪九十年代末稳定下来之前，每家公司对测试运行器、Mock、断言库、集成框架都有各自的叫法；这个伞形概念被接受之后，那些散落的实践才第一次被当作一个整体来设计。

问题在于，几乎所有人都把这张图当成了施工顺序图。从上往下读，得出的做法是：先做上下文，再做工具，再做执行，再做记忆，最后加评估和容错。

大多数团队正是这样做的，这也是他们在六七成成功率上卡好几个月的原因。

AI Agent骨架六层的贡献为什么严重不平等？

前四层全是盲操作

把六层拆开，只看一件事：哪几层能产生反馈，哪几层不能。

第一层你调上下文，Agent的行为变了，接下来呢？你没有依据判断它是变好了，还是只是变了。第二层你加一个工具，前提是假设它会被正确调用。第三层你画一套执行流程，前提是假设每一步都能跑通。第四层你上记忆，前提是假设记住的内容确实有用。

顺带澄清工具层的一个常见误解：很多人以为工具越全越好，实际情况相反，工具目录的质量取决于精选，而不取决于覆盖面。站内那篇拆协议服务、技能与钩子三种扩展机制该怎么选的文章讲的就是这个取舍，和这里的第二层是同一件事的两种说法。

这四层全建立在假设上。没有评估和容错，相当于关着仪表盘飞行：你对前四层做的每一次改动都在碰运气，成功了不知道原因，失败了不知道出在哪里。

第五层和第六层的作用，是让你判断前四层的改动有没有效果，它们并非叠在前四层之上的优化项。缺了这两层，前四层的每一次调优都只是换一种方式盲调。

按周记录的各层贡献表说明了什么？

下面这组数据来自一条在生产环境连续运行六十天的AI编程流水线：每周只加一层，逐周记录同一批真实任务上的成功率变化。

这张表建议读两遍。第五层的提升接近第一层的两倍，工时只有一半。第六层的提升是第四层的六倍，工时完全相同。

第五、六层合计40个百分点，其余四层合计29个百分点。“八成稳定性来自后两层”这个说法就是从这笔账算出来的，并非修辞。

评估层指标怎样救回一个项目？

保哥这两年帮客户看过不少这类项目，其中一个印象很深。

客户是一家做户外装备的独立站，想用Agent自动给站内几百个产品页补结构化数据和内链。项目做了六周，通过率卡在62%。上下文调过两次，模型换过三次，新加了两个工具，通过率始终不动。团队已经在开会讨论要不要砍掉这个项目。

后来团队花一个下午加上了第五层，内容是一组很朴素的检查：改完后页面能否正常渲染、结构化数据能否通过校验、站内链接有没有指向404、改动行数是否异常偏大、改动内容与需求描述的语义相似度是否足够。总共两百来行脚本，没有什么技术难度。

一天之内，看板暴露了一件此前完全看不见的事：四成的失败，是有效的改动打坏了一条不相关的内链。Agent的内容改动本身是对的，但每跑三次就会把某篇相关文章的交叉引用弄坏。之前的上下文调优都没碰到这块，因为团队根本不知道这个问题存在。

团队花两天修好链接处理逻辑，通过率从62%升到84%。上下文、工具、模型都没有改动。

这个案例的教训比“凡事都要测量”具体：瓶颈几乎从来不在你以为的地方，没有仪表就永远找不到它。六周的前三层调优没找到这个bug，两天的第五层工作找到了。

Agent骨架为什么要从容错和评估倒着建？

因此正确的顺序是反过来的，推荐的施工顺序是从第六层到第一层：

1. 先做容错。失败是常态，不是例外。如果Agent不能从一次错误的工具调用里恢复，上下文调得再好也没用。先把验证关卡和回滚路径接上。
2. 再做评估。无法衡量的东西无法改进。先建看板，再谈优化。
3. 第三是工具。有了评估之后，改工具是改变Agent行为性价比最高的手段。工具选错的代价会不断累积；没有评估就改工具，结果只能靠运气。
4. 第四是上下文。上下文调优的边际收益递减，而且很容易过度设计。有评估才知道什么时候该停手。
5. 第五是执行编排。显式的流程编排只有在底层组件稳定之后才有回报。
6. 记忆放最后，而且经常根本不做。这一层过度建设最严重，在半小时以内的任务里它几乎从来不是瓶颈。

三十分钟启动法具体怎么做？

如果你手上正好有一个卡住的Agent，下面这五步是一次性动作，不需要重构任何东西：

1. 挑出过去一周观察到的三个失败模式。只挑三个，不要多。
2. 每个失败模式写一个二十行的校验器。不需要聪明，硬编码判断即可：构建过了没有？接口调用返回200没有？输出结构是否合规？
3. 把校验器接进Agent的循环。失败时把校验器的输出作为重试提示喂回去：“这次输出不合格，原因是X，按这个约束重来”。
4. 跑二十次有代表性的任务，看哪个校验器触发得最频繁。
5. 触发最频繁的那个，就是你的下一个bug。它属于哪一层就在哪一层修，但不看校验器，你无法知道它属于哪一层。

倒序建设的做法就是反复执行这个循环：容错、评估、诊断、修复真正的瓶颈，然后重复。

如果你打算把这个循环写成代码，站内那篇用官方软件开发工具包几行代码搭一个Agent的实战可以作为起点，校验器和重试提示都接在那个循环的同一个位置。

Agent骨架的三套拆法，哪一套能回答下一步改哪儿？

有一件事很少被公开讨论：所谓“骨架”，业界至少有三套完全不同的拆法，而且彼此对不上。

第一套拆法：按部件列清单

2026年3月10日，LangChain的Vivek Trivedy发表了一篇拆解Agent骨架解剖结构的文章，提出了后来流传最广的公式：Agent等于模型加骨架。文章列了十三个组件：系统提示、工具与技能与协议服务及其描述、随包提供的基础设施、编排逻辑、钩子与中间件、文件系统、命令行与代码执行、沙箱、记忆与检索工具、压缩、工具调用卸载、技能的渐进披露、规划与自校验。

文章里最有冲击力的是公式之外的一条观察：在Terminal-Bench 2.0的榜单上，同一个模型跑在不同骨架里，分数差距很大，而且官方自家工具里的成绩明显低于其他骨架。文中还提到，只改骨架、完全不换模型，就能把排名从三十名开外推进前五。

第二套拆法：按层级排栈

也就是本文开头的六层。它的优点是好教好记，缺点前面已经讲过：它看起来像施工顺序，实际不是。

第三套拆法：按作用时机和确定性排2×2

2026年4月2日，Thoughtworks的Birgitta Böckeler在Martin Fowler的网站上发表了一篇面向编码Agent使用者的骨架工程指南，给出了一种和前两套都不同的切分方式。

她先区分了两层：内骨架是模型厂商随产品提供的部分（Agent软件开发工具包、编码工具本身），外骨架是你自己在上面搭建的部分（规则文件、协议服务、自定义技能）。这个区分直接回答了预算问题：内骨架是免费的，你的每一分投入都应该花在外骨架上。

接下来是真正实用的2×2。横轴是作用时机：

• 引导是前馈控制，预判Agent的行为，在它动手之前把它引向正确方向。原文的说法是，引导“提高Agent第一次就做对的概率”。
• 传感器是反馈控制，在Agent动手之后观察结果，让它自我修正。原文特别补充：传感器“在产生专门为大模型消费而优化的信号时，威力尤其大”。

纵轴是确定性：

• 计算型：确定性、速度快，跑在CPU上。测试、静态检查、类型检查、结构分析，毫秒到秒级出结果，结果可靠。
• 推断型：语义分析、AI代码评审、大模型当裁判，跑在GPU上，更慢、更贵，结果更不确定。

四个格子分别是：编码约定属于推断型前馈（规则文件、技能），代码批量改写属于计算型前馈（重构配方），结构测试属于计算型反馈（架构约束测试），评审指令属于推断型反馈（技能）。

第三套拆法胜在哪里

三套放在一起，差别很明显：前两套按部件分类，部件清单回答不了“下一步该改哪儿”；第三套按作用机制分类，所以能回答。

用一个具体故障验证一下。假设你的Agent总是漏掉某个必填字段。按十三个组件的清单，你会陷入“改系统提示、加工具还是写钩子”的三选一，三个选项都说得通。按六层，你会在“这是上下文问题还是执行问题”之间反复。按2×2，你只需要回答两个问题：这件事应该在它动手前拦住，还是在它动手后抓住？有没有确定性的判据？两个问题各有一个答案，格子就确定了，改哪里也就确定了。

怎样把2×2落成四步故障定位法？

只有分类仍然抽象。下面四步是实际使用这套分类后固定下来的做法，任何反复出现的故障都可以照着走一遍。

1. 先写下那句“它又干了什么”。要具体到能复述：不能只写“它写得不好”，要写“它把描述写到了一百八十个字”“它把内链指到了一个已删的分类页”。写不具体，说明观察还不够，后面三步都无法进行。
2. 问第一个问题：这件事有没有确定性判据？字数、返回码、结构是否合法、必填字段在不在，这类有判据的走计算型；只能靠“读起来像不像话”判断的，才走推断型。这一步最常见的错误，是把明明能数出来的东西交给裁判凭感觉判断。
3. 问第二个问题：拦在前面更划算，还是抓在后面更划算？判断依据是重做一次的代价。改一行描述，重做成本很低，就抓在后面；跑完一整套多语言生成才发现语种混了，重做成本很高，就拦在前面。
4. 落到格子里，只改那一个格子。两个答案确定一个格子，改动限定在这个格子内，改完把这个故障加入回归集。后半句最关键：不进回归集的修复，下个月一定会以另一种形式复发。

这套做法还有一个附带作用：它会暴露出有些故障你其实无法判断。第二步答不上来时，要解决的已经不是选计算型还是推断型，而是你对“做对了”的定义还没写下来。这种情况比预想的常见，而且不会自行好转。

另外，Böckeler那篇文章还给出了第三个维度：骨架按管理对象分三类，分别是可维护性骨架（内部代码质量，目前最成熟）、架构适应度骨架（性能要求、可观测性标准）、行为骨架（功能正确性）。她对最后一类的原话是“我们还有很多事要做”。前面户外站的案例正好属于这一类：内链被打坏，是行为正确性问题，与代码质量无关，而这一类恰恰是三类里最不成熟的。

编码Agent的传感器具体该装哪几个？

2026年5月27日，Böckeler又发表了一篇专讲可维护性传感器的实操文章，把“该装什么”落实到了具体工具。这一节信息密度很高，建议逐条记下来。

会话进行中该跑哪些传感器？

全部是计算型：类型检查器、代码静态检查（配自定义输出格式，方便Agent自行修正）、静态安全扫描、依赖关系检查器（管理目录结构和依赖方向）、带覆盖率的测试套件、增量变异测试、提交前的密钥泄露检查。

接进流水线后要重跑哪些？

同一批计算型传感器，在干净的基础设施上再跑一遍。这一步并不多余：本地环境的脏状态会让不少问题在会话里被掩盖。

哪些传感器按更慢的周期跑？

以推断型为主：安全审阅、数据处理方式审阅、依赖新鲜度报告、模块化与耦合度审阅。前两项完全靠提示词运行，后两项是计算与推断的混合。

三种接入循环的方式对比

这是全文最实用的一段。Böckeler试了三种接法：

1. 写进规则文件，让Agent自己去跑。她的原话是“相当不可靠”，还补了一句很真实的抱怨：她得反复问Agent为什么一次都没跑过那些检查。
2. 挂钩子。在文件修改时触发，或接在提交前。可用，但她提醒要注意别让它太吵。
3. 写成自定义扩展。她的评价是“看起来挺有前途”，但使用量还不足以下结论。

第一条需要展开讲。把校验写进指令和把校验写进机制，是两回事。写进指令的，模型执不执行不确定；写进机制的，模型没有选择余地。这条经验和站内那篇讲给循环工程装刹车的实战结论一致：那篇里的掉沟检测之所以有效，是因为它们是硬编码的计数器，没有写在提示词里靠模型自觉。

静态检查阈值为什么不该设成二选一？

还有一个设计细节很巧妙：她配置静态检查时，没有把阈值做成“要么改、要么加豁免注释”的二选一，而是允许Agent在判断这次重构确实没必要时，把阈值稍微调高一点。

原因是：卡死的阈值只会逼出满屏的豁免注释，到那时传感器实际上等于关掉了。留一点可协商的空间，规则才能持续生效。

最后她留了一句警告，恐怕比前面所有工具清单都更值得记住：“我忍不住会想，这是不是也会带来一种虚假的安全感，一种质量的错觉。”传感器装满，不代表质量真的提高了，只代表你现在能看见一部分问题。

内容类Agent没有验证面，怎么从零建一个？

前面反复强调“先建验证面”，很多人会卡在这里：我做的是内容，哪来的测试和类型检查？

这个问题确实存在，但被高估了。验证面不等于单元测试，它的范围宽得多：任何不依赖人工主观判断、就能对一次输出给出“合格/不合格”结论的检查，都是验证面。按这个定义，内容类工作里可以当验证面的东西其实很多，只是没人把它们整理到一起。

第一档：哪些检查能直接数出来？

成本最低、见效最快的一批全是纯计算：描述字数是否在区间内、标题里的核心词有没有被改写掉、标点里是否混进了半角、结构化数据能否通过校验器、新加的内链是否全部返回200、图片有没有alt、同一批稿子里有没有重复标题。每一条都只要几行代码，合起来一个下午就能写完。

这一批检查不能小看。前面户外站的案例里，把项目从濒临砍掉的状态救回来的，正是这一类里最不起眼的一条：内链是否404。

第二档：哪些检查需要对照基线？

第二批稍费功夫，但价值更高：本次输出与需求描述的语义相似度、本次输出与站内已有文章的重复度、本次改动的规模是否异常（一个只该改标题的任务却改了三百行，大概率出了问题）。这批是计算与推断的混合，最容易发现“做了但做错了”的情况。

第三档：必须由人判断的部分怎么处理？

确实有一部分内容没法自动判断：这段话像不像人写的，这个论断是否成立，这个例子有没有说服力。这一档不应放弃，而应压缩成抽检：不逐篇看，按固定比例随机抽，抽到不合格就回头查前两批传感器为什么没拦住。抽检的价值主要在于持续暴露自动化部分漏掉了什么。

保哥的经验是，三档建完后，大部分内容流水线的成功率就能从“大概能用”提高到“可以放着跑”，整个过程一行提示词都没改。

Agent记忆层为什么最容易过度建设？

这一节单独拿出来讲，因为这是见过的项目里代价最高的一个坑。

记忆工程看起来很高级：向量库、语义索引、回合摘要、偏好学习，每个词都很体面。但大多数团队在这里投入四到六周，最后只换回三个百分点。

三条可以直接照做的规则：

• 任务每次在半小时以内，跳过记忆。把偏好直接写进一次性的系统提示，更快、更便宜，也不会过时失效。
• 确实需要跨会话状态时，先用平文件或最简单的键值存储。向量库和向量化在九成场景里都属于过早优化。
• 长任务里，干净交接比持久记忆更有效。与其让一个Agent在塞满噪音的上下文里挣扎，不如带着显式的状态摘要交给一个全新的Agent接力。持久上下文会不断累积噪音，而恢复需要的恰恰是干净的上下文：当前这个Agent背的包袱太多，已经看不见自己的bug。

还有一点与直觉相反：写给Agent看的那份规则文件，同样容易过度建设。站内那篇讲规则文件不是写得越详细越好、以及最优行数在哪的实证复盘，结论和这里完全一致：加的内容越多，真正被执行的比例越低。

唯一的例外，是确实需要在几周内学习特定用户模式的场景，比如一个要学会公司内部黑话的客服Agent。除此之外，记忆层都应该往后放。

关于上下文该怎么减、不该怎么加，站内那篇讲上下文工程真正杠杆在删不在加的复盘写得更细，其中“五千词元打赢十万词元”的对照实验说明的也是同一个道理。

哪三种情况下不该建Agent骨架？

到这里需要踩一下刹车。本文并不是在推销骨架工程，所以有必要把“不该建”的情形单独讲清楚。

情况一：任务是探索性的，不是生产性的

如果你用Agent做头脑风暴、起草、探索可能性，骨架机制弊大于利。不加骨架直接跑，能保留模型的发散空间。等任务确实从“探索”进入“可重复生产”阶段之后再建，也来得及。

情况二：根本没有验证面

安全方面还要补一句：缺少验证面还有一个代价更高的版本，就是连权限控制也一起省掉了。站内那篇从安全评审到权限边界与提示注入防御的实战讲到的那几道边界，对应的就是第六层里“不许它做什么”的那一半。这一半属于底线，不能当作优化项。

第五层是承重层。如果你的任务没有测试、没有类型、没有静态检查、没有可观察的副作用、没有可对比的基线、没有人工抽检机制，你就建不出有意义的骨架，想建也建不了，因为没有任何东西可以用来验证。先建验证面，再建骨架。

这一条对内容和SEO类的Agent影响尤其大。很多人一上来就让Agent批量改标题、批量写描述，然后奇怪效果为什么不稳定，原因是整条链路上没有任何一个环节能判断“这次改得对不对”。站内那篇讲AI内容流水线为什么会被降权、三处人工节点该卡在哪里的复盘，讲的就是缺少验证面的代价。

情况三：处在投资象限的橙色区

这一种需要展开说明，见下一节。

Agent骨架建不建，该看哪两根轴？

把整个决策压缩成一个平面，两根轴就够了：任务重复度有多高，以及距离下一代模型发布有多近。

压缩成一条可以心算的规则：未来六个月内同一条流水线会运行超过五十次，并且这段时间里没有已知的模型换代，就建。任一条件不满足，往下降一格。两个条件都不满足，直接放弃实现，把预算转到阅读上。

国内团队最常见的误判，是身处橙区却按绿区的方式做事：为一个两个月后就会过期的内部一次性工具，精心打磨一套多层骨架。橙区的正确做法听起来有些不近人情：别建，去读。把预算投在能深读发布说明、看懂新旧模型能力差异、能复述骨架迁移模式的工程师身上。这种阅读能力跨模型代际持续有用，那套精心打磨的实现则不会。

模型变强后，Agent骨架会被吃掉吗？

最后这一节讨论的，是这个话题里正反两方最容易同时说错的地方。

模型每吸收一层骨架，就解锁更高一层

怀疑派最有力的论点是：模型变强会把骨架吃掉。这个论点有实际依据。厂商自己的复盘基本承认了这一点：上一代模型有“上下文快满时急着收尾”的失败模式，于是出现了专门的上下文重置补丁；下一代模型基本没有这个毛病，补丁也就没用了。同样，早期需要用硬约束逼模型“每轮只做一件事”，规划能力提高之后，这条约束反而帮倒忙，被直接删掉了。

但把这个模式外推成“骨架终将归零”是错的。错误在于把骨架看成一块面积固定、随时间缩小的东西。

数据指向相反的方向：每一层被模型吸收的骨架，都让此前做不到的复杂任务变得可行。上下文焦虑的问题一解决，团队马上转去挑战更难的全栈拆解。骨架没有缩小，而是随着模型能力提升，转移到了更高层次的问题上。

Agent骨架因模型而异

2026年6月8日的一篇论文把这个问题推得更进一步。Self-Harness这篇提出了让Agent改造自己骨架的范式，作者的出发点是：不同模型的行为不同，所以有效的骨架设计因模型而异；而目前骨架基本靠人类专家手工搭建，在模型越来越多样、迭代越来越快的情况下，这种方式很难扩展。

论文的方法是一个三段循环：弱点挖掘（从执行轨迹里找出该模型特有的失败模式）、骨架提议（针对这些失败生成多样但最小的骨架改动）、提议验证（只接受通过回归测试的改动）。在Terminal-Bench 2.0上用三个不同家族的基座模型测试，保留集通过率分别从40.5%升到61.9%、从23.8%升到38.1%、从42.9%升到57.1%。

这组数字里更值得关注的是起点，而不是涨幅：同一套初始骨架，三个模型的成绩分别是40.5%、23.8%、42.9%，最高和最低相差将近19个百分点。这是“骨架因模型而异”最直接的证据。它同时意味着一件让人泄气的事：你在网上看到的任何一份“通用骨架最佳实践”，上限都由作者当时所用的模型决定。

论文还有一句补充值得引用：定性分析显示，这套方法产出的不是泛泛的通用指令，而是针对模型特有弱点的具体、可执行的骨架改动。能自动化的部分是“针对性”，而非“通用性”。

把状态移出模型，学术上是否成立？

另一项2026年6月的证据来自检索方向。Harness-1这篇论文把搜索Agent的状态外置到了环境侧，作者的论证是：把常规状态管理塞进策略里是错误的，因为这会迫使强化学习同时优化两件事，一是语义搜索决策，二是那些环境本可以更可靠地维护的记账工作。

他们的做法是让骨架维护环境侧的工作记忆：候选池、带重要性标记的精选集、紧凑的证据链接、验证记录、压缩去重后的观察，以及按预算渲染的上下文；策略只负责语义决策，即搜什么、留哪些、验什么、什么时候停。在覆盖网页、金融、专利和多跳问答的八个检索基准上，平均精选召回率为0.730，比次强的开源检索子代理高11.4个百分点，而它只是一个两百亿参数的模型。论文特别指出，收益在留出的迁移基准上尤其明显。

可以带走的一句话是：凡是环境能可靠维护的记账，就不该交给模型去记。让模型记账，代价不只是多消耗一些词元，还会往它的优化目标里混进一件本不该由它承担的任务。

补充一点：这个词现在已经收进维基百科关于Agent骨架的词条，词条明确写着这个说法的归属存在争议：一派归给在博客里随口起了这个名字的独立开发者，另一派归给LangChain那篇解剖文章。词条还指出了这套东西的前身：推理与行动交替的循环范式来自一篇经过同行评审的框架论文，模型调用外部工具的能力则更早就有研究演示过。一个七周内传遍全行业的新词，底下是好几年积累的旧基础。

常见问题解答

骨架工程和上下文工程、提示词工程是什么关系？

三者是层级关系。提示词工程优化的是单次交互，上下文工程管理的是某一时刻模型能看到什么，骨架设计的是整个运行环境，前两者都是它的组成部分。有一个区别需要单独记住：被包裹的那个组件是非确定性的，所以骨架从一开始就要按“模型会编造一个动作，或者会谎报任务已完成”来设计恢复路径，这和包裹一个确定性组件完全不同。

小团队没资源，六层里最先建哪一个？

先建第六层的最小可用版本：挑出三个最常见的失败模式，每个写二十行硬编码校验，失败时把校验结果作为重试提示喂回去。这一步通常一个下午就能做完，而且它会立刻告诉你第五层该测什么。先建第五层也可以，但先有恢复路径，调试期间会少丢很多次工作成果。

怎么判断我该继续加骨架还是该停手？

看指标是否还在变化。上下文调优的边际收益递减很明显，如果指标连续两三轮改动都只在噪声范围内波动，就该停了。这也是评估必须先建的原因：没有指标，你分不清是“已经到顶了”还是“方向错了”。

用不同模型要不要重做骨架？

大部分不用重做，但必须重测。前面的数据显示，同一套骨架在不同模型上的成绩能相差近19个百分点，所以换模型后至少要把评估集重跑一遍，看哪几个校验器的触发频率变了；变化最大的那几个，就反映了新模型和上一个模型的行为差异。

推断型传感器（大模型当裁判）可靠吗？

在文件和函数级别，计算型传感器更有效；在跨文件的问题上，原始数据本身噪音很大，没有语义解释就不太好用，这时推断型传感器才有用武之地。实际做法是分工，不必二选一：能用确定性判据的地方一律不用裁判，剩下确实需要语义判断的部分再交给裁判，并给它可对照的基线。

这套东西对做SEO和独立站运营的人有什么用？

用处很直接。任何一条“让AI批量处理内容”的流水线都是一个Agent系统：批量写描述、批量补内链、批量生成产品文案、批量做多语言。它们卡住的原因和编程Agent完全一样：没有验证面，就没有仪表，每次改动都在碰运气。先建校验（描述长度、关键词是否原样保留、内链是否404、结构化数据是否通过），再考虑提示词怎么写；顺序反了，就会一直在原地打转。

权威参考资料