AI Agent卡在六成成功率不动，问题不在你正在调的那一层

摘要：把AI Agent架起来跑的那套外围系统，业界现在管它叫harness，中文可以叫骨架。流行的讲法是六层：上下文、工具、执行、记忆、评估、容错，然后按这个顺序建。这个顺序是反的。真实的贡献分布严重不平等——评估和容错这两层加起来撑住了大约八成的稳定性，而它们通常被排在最后，甚至被当成可有可无的打磨。更麻烦的是，业界至少有三套互不兼容的拆法，其中只有一套能回答“下一步该改哪儿”。这篇把三套摆在一起对照，给出倒着建的顺序、每一层的真实投入产出、传感器具体装哪些、以及三种情况下干脆别建。最后用两篇2026年6月的论文说明一件事：骨架不是永久护城河，它是一扇会关的窗。

先说一个让人不太舒服的观察。

过去大半年里，我见过的AI Agent项目卡住的位置高度一致：成功率停在六成到七成之间，怎么调都不动。团队的反应也高度一致——回头去改提示词，去精简那份规则文件，去换一个更贵的模型。三件事轮着做，一个月过去，成功率纹丝不动。

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

六层框架是对的分类，却是错的施工顺序

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

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

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

这正是大多数团队的实际做法，也正是他们卡在六七成好几个月的原因。

这六层的权重为什么严重不平等？

前四层全是盲操作

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

第一层你调上下文，Agent的行为变了，然后呢？你没有任何依据判断它是变好了还是只是变了。第二层你加一个工具，你在假设它会被正确调用。第三层你画一套执行流程，你在假设每一步真的能跑通。第四层你上记忆，你在假设记住的那些东西确实有用。

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

四层全是在假设。没有评估和容错，你是关着仪表盘在飞——你对前四层做的每一个改动都是赌博，赢了不知道为什么赢，输了不知道输在哪。

第五层和第六层不是叠在前四层之上的优化项，它们是让你能判断前四层有没有效的那副眼镜。没有这副眼镜，前四层的每一次调优都只是在换一种方式瞎。

一张按周记录下来的贡献表

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

这张表值得读两遍。第五层给出的提升接近第一层的两倍，工时只用了一半。第六层给出的提升是第四层的六倍，工时完全一样。

五和六加起来是40个百分点，其余四层加起来是29个百分点。这就是“八成稳定性来自后两层”这个说法的来源——不是修辞，是记账。

一个被指标救回来的项目

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

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

后来花了一个下午加了第五层，就是一组极其朴素的检查：改完之后页面还能不能正常渲染、结构化数据能不能通过校验、站内链接有没有指向404、改动行数是不是异常的大、改动内容和需求描述的语义相似度够不够。加起来两百来行脚本，谈不上任何技术含量。

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

花两天修链接处理逻辑，通过率从62%跳到84%。上下文、工具、模型，一个都没动。

这里的教训不是“凡事都要测量”这种正确的废话。教训是：瓶颈几乎从来不在你以为的地方，而没有仪表你永远找不到它。六周的前三层调优没找到这个bug，两天的第五层找到了。

倒着建：从容错和评估往回走

所以正确的顺序是反的。推荐的施工序列是六到一：

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

今天下午就能试的三十分钟启动法

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

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

整套倒序哲学就是这一个循环：容错、评估、诊断、修真正的瓶颈，然后重复。

如果你打算把这套循环真的写成代码而不是停在纸面上，站内那篇用官方软件开发工具包几行代码搭一个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那篇还给了第三个维度：骨架按管的东西分三类——可维护性骨架（内部代码质量，目前最成熟）、架构适应度骨架（性能要求、可观测性标准）、行为骨架（功能正确性）。她对最后一类的原话是“我们还有很多事要做”。前面那个户外站的案例正好落在这一类：内链被打坏，不是代码质量问题，是行为正确性问题，而这恰好是三类里最不成熟的那一类。

传感器具体该装哪几个？

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

会话进行中就该跑的（全是计算型）

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

接进流水线之后重跑的

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

按更慢的周期跑的（推断型为主）

安全审阅、数据处理方式审阅、依赖新鲜度报告、模块化与耦合度审阅。前两个纯粹靠提示词跑，后两个是计算加推断的混合。

三种接进循环的方式，两种不好使

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

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

第一条值得放大讲。把校验写进指令，和把校验写进机制，是两件事。写进指令的东西，模型会看心情执行；写进机制的东西，模型没得选。这条经验和站内那篇讲给循环工程装刹车的实战是完全一致的结论——那篇里的掉沟检测之所以有效，正是因为它们是硬编码的计数器，不是写在提示词里的君子协定。

阈值别设成二选一

还有一个特别聪明的设计细节：她配置静态检查的时候，没有把阈值做成“要么改要么加豁免注释”的二选一，而是允许Agent在它认为这次重构确实没必要的时候，把阈值稍微往上调一点。

这个设计的道理是：卡死的阈值只会训练出满屏的豁免注释，那时候你的传感器就等于关了。给一点可协商的空间，反而能让规则活着。

最后她自己留了一句警告，我觉得比前面所有工具清单都值钱：“我忍不住会想，这是不是也会带来一种虚假的安全感，一种质量的错觉。”传感器装满了，不等于质量真的上去了——它只等于你现在能看见一部分问题。

没有验证面的话，从零怎么建一个？

前面反复说“先建验证面”，但很多人卡在这句话上：我做的就是内容，哪来的测试和类型检查？

这是个真问题，也是个被高估的问题。验证面不等于单元测试，它的定义宽得多——任何一个能在不看人脸色的前提下、对一次输出给出“合格/不合格”的判断，都是验证面。按这个定义，内容类的工作里能拿来当验证面的东西其实相当多，只是没人把它们收拢过。

先捡那些能数出来的

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

别小看这一批。前面那个户外站的故事里，把项目从判死刑救回来的正是这一类里最不起眼的一条——内链是否404。

再补那些能对照的

第二批稍微费一点事，但价值更高：这次输出和需求描述的语义相似度、这次输出和站内已有文章的重复度、这次改动的规模是不是异常（一个只该改标题的任务却动了三百行，那多半出事了）。这批是计算加推断的混合，也是最容易发现“做了但做错了”的一批。

最后才是需要人的那一档

确实有一部分东西没法自动判断：这段话是不是像人写的，这个论断成不成立，这个例子有没有说服力。这一档的正确做法不是放弃，而是把它压缩成抽检——不是每篇都看，而是固定比例随机抽，抽到不合格就回头查前两批传感器为什么没拦住。抽检的价值不在抽检本身，在于它持续告诉你自动化那部分漏了什么。

保哥的经验是，这三档建完，大部分内容流水线的成功率就已经能从“大概能用”推到“可以放着跑”了，而这中间一行提示词都没改过。

记忆层是最容易过度建设的一层

这一节单独拎出来，因为它是我见过最贵的一个坑。

记忆工程看起来很高级：向量库、语义索引、回合摘要、偏好学习，每一个词都很有面子。但这也是大多数团队砸进四到六周、最后只换回三个百分点的地方。

三条可以直接抄的规矩：

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

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

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

关于上下文该怎么减不该怎么加，站内那篇讲上下文工程真正杠杆在删不在加的复盘写得更细，那组“五千词元打赢十万词元”的对照实验，本质上讲的也是同一件事。

哪三种情况下干脆别建？

写到这里得踩一脚刹车。这篇不是在推销骨架工程，所以有必要把“不该建”的情形单独说清楚。

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

如果你在用Agent做头脑风暴、起草、摸可能性，那么骨架机制伤大于帮。裸跑保留了模型的发散空间。等你确实从“探索”跨过“可重复生产”那道门槛之后再建也不迟。

情况二：你根本没有验证面

补一句和安全有关的：验证面缺失还有一个更贵的版本，就是把权限也一起省掉了。站内那篇从安全评审到权限边界与提示注入防御的实战讲的那几道边界，本质上就是第六层里“不许它做什么”的那半边——这半边不属于优化项，属于底线。

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

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

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

这个要展开说。

建还是不建，该看哪两根轴？

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

压成一条可以口算的启发式：未来六个月内同一条流水线会跑超过五十次，并且这个窗口里没有已知的模型换代——建。任一条件不成立，往下降一格。两条都不成立，直接放弃实现，把预算转到阅读上。

国内团队最常见的误判是坐在橙区却在按绿区做事：为一个两个月后就会过期的内部一次性工具，精雕细琢一套多层骨架。橙区的正确动作听起来有点残忍——别建，去读。把预算花在能深读发布说明、看懂能力差量、能复述骨架迁移模式的工程师身上。这种阅读能力是跨代复利的，那套精雕细琢的实现不是。

它是一扇会关的窗，不是一条护城河

最后这一节要说的，是这个话题里最容易被两边同时说错的地方。

每吃掉一层，就解锁更高一层

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

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

数据指向相反方向：每一层被吸收掉的骨架，都解锁了此前根本够不着的任务复杂度。上下文焦虑一被治好，团队立刻就去挑战更难的全栈拆解了。骨架不是在缩小，是在随模型能力上移——它迁移到海拔更高的问题上去了。

更尖锐的版本：骨架是因模型而异的

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、结构化数据是否通过），再谈提示词怎么写，顺序反了就会一直在原地打转。

权威参考资料