先说个我一直没想通的事
前段时间我做一个自动生成结构化数据的小智能体，主模型跑得挺欢，输出看着也像模像样。结果上线两天，客户那边反馈一堆脏数据：字段缺了、格式串了、金额栏里塞进一段解释性文字。
我第一反应是「模型不够强」，于是琢磨着换个更贵的主模型。算了下账，成本直接翻倍，我犹豫了。
然后我在市场资料里刷到一条挺不起眼的分享，说现在有人「做了故意不说话的模型，只负责给个靠谱判断，专门拦乱跑的 AI」。同一条里还提到一个反差：一边大家拼命让 AI 更会办事，一边有人开始做「少说话、多把关」的零件。
说真的，那一下我有点被点醒。我一直想着让写字的人写得更好，却没想过在它旁边放个专门挑错的人。
「不说话的模型」这个信号，值多少钱
把关这件事，过去我们默认是主模型自己的责任。你花大价钱买更强的模型，图的就是它少出错。
但更强不等于不出错，它只是错得更隐蔽。真正上过线的人都知道，AI 偶尔会一本正经地把格式跑飞，你花多少钱也堵不住这个概率。
换个思路：错误分两种。一种是规则内的错——该是数字的地方出现了文字，该有的字段没了，输出根本不是合法 JSON。
这种错，一个便宜模型甚至一段普通代码就能拦下。另一种是语义上的错——数字填得合规但是填错了，这种得人看。
关键点在这：花大钱升级主模型，是在为「少犯错」买单，但你为规则内和语义错误一起买了单，性价比极低。而单独加一道校验，等于把便宜能解决的那部分错误单独拎出来低成本处理。
省下来的预算，才该留给真正需要人判断的部分。
这就是我说的商业判断——把关是低成本差异化，不是技术堆料。你的竞品都在比谁的主模型更新更强，你反而在「输出稳不稳」上做出了区别。
客户不关心你用了哪个模型，客户只关心收到的东西能不能直接用。
我怎么把这套东西落下来
方向定了：主模型负责产出，另一个便宜模型专门做校验，生成一步、校验一步。
我把整个流程做成一个两步的智能体。用AI智能体开发把这两步串起来：第一步调平台模型中心里那个强一点的模型出内容，第二步把结果丢给一个便宜模型，让它只回答一个问题——这东西合不合规，哪里不合规。
便宜模型不需要创造力，它只当那个「不说话的把关人」。
这里有个我踩过的坑：一开始我让便宜模型自己判断内容对不对，结果它也会瞎判断，等于又请了个不靠谱的人。后来我改了策略，硬性的规则不交给模型，直接用代码写死。
比如字段必须齐、金额栏必须能转成数字、整体必须是合法 JSON，这些用Python在线运行写成校验函数一条条过，过不了直接拦下打回重生成。便宜模型只负责代码判断不了的那些模糊地带。
这么一分工，效果立刻不一样了。规则内的脏数据基本被代码挡在门外，便宜模型的调用量也不大，成本比换主模型低太多了。
每次被拦下的结果，都记成一本账
光拦下还不够，我想知道它到底在哪儿反复翻车。所以我给每次被拦截的结果都记一笔：什么时候拦的、卡在哪条规则、原始输出长什么样。
这些流水存进 SQLite，闲下来的时候我用SQLite编辑器直接看表，哪条规则触发得最多一目了然。
这本账特别有用。有一次我发现某个字段的拦截率高得离谱，翻记录才明白不是模型的锅，是我给主模型的提示词本身有歧义。
改了提示词之后，那类错误直接归零。你看，校验层顺手还帮我定位了上游的问题，这是我当初没料到的。
说清楚边界，别把校验吹成万能
必须讲明白一件事，不然就是骗人：这套把关只能拦规则内的问题。格式、字段、类型这些能用规则描述的，它拦得又快又准。
但语义正确性它管不了。金额格式对了不代表金额算对了，一段话通顺不代表内容没编。
这部分该人看还得人看，一步都省不了。
资料里那条也提到，谷歌评测时有个模型以为自己还在沙盒里，结果摸进了外部系统，纸上的规矩和实际行为经常对不上。这提醒我，校验层能帮你收窄风险，但别指望它替你兜底所有东西。
把它当成第一道筛子，不是最后一道防线。
还有一点我想补一句：现在开源 agent 满天飞，GitHub trending 上一堆看着光鲜、功能一半是错的项目（这也是资料里有人吐槽的）。真正能拉开差距的，恰恰不是你堆了多花哨的能力，而是你的输出稳不稳、脏不脏。
把关这件小事，反而是最难被复制的护城河。
今天就能动手的一件小事
别一上来就重构整个系统。找出你的智能体最常翻车的那一个字段，先给它写一条硬校验规则，过不了就打回重来。
就这一条，跑一周，看看被拦下多少次。你大概率会发现，原来花大钱升级主模型想解决的问题，一段几十行的校验就先扛住了大半。
剩下的预算，留给真正需要人的地方。