同一个模型，0分到满分：智能体可靠性关键在调用时机

当智能体表现不佳时，很多开发者的第一反应是换更大的模型。但最近一位开发者在真实安卓设备上的实验表明，同一个4B小模型，仅仅改变了「何时询问模型」的策略，成功率就从0/20跃升到20/20。这引出一个关键问题：智能体的可靠性，到底有多少来自模型本身，多少来自它周围的结构？

实验设计：在真实硬件上注入故障

这位开发者将一台安卓手机改造成常亮屏幕，并注入多种故障：应用崩溃、后台服务挂起、后端不可用，甚至模拟「有人拿起手机」的人为干扰。每次故障触发一个恢复循环：观察、决策、策略门控、执行、验证。决策器可替换为纯规则、规则优先+模型兜底，或完全交给模型。每个场景在真实硬件上运行20次，由独立的验证器检查结果。

为了验证结构本身的价值，开发者特意选择了本地运行的4B小模型，而不是前沿大模型。实验的核心是观察：在模型能力有限的前提下，良好的结构能带来多少提升？

4B 小模型指参数量约 40 亿的语言模型，通常可在手机或笔记本上本地运行，推理成本极低，但泛化与推理能力明显弱于百亿级以上的前沿模型。本地运行意味着不依赖云端 API，延迟低、隐私好、可离线，但模型能力受限。**智能体（Agent）**在此指能感知环境、做决策并执行动作以完成恢复任务的程序，常由「观察—决策—执行—验证」循环驱动。策略门控是决策流程中的一层过滤：在执行动作前按规则或条件判断是否放行，用于拦截高风险或不合规操作。实验中，决策器可替换指同一套感知与执行框架下，可切换纯规则、规则优先+模型兜底或纯模型三种决策后端，从而隔离「结构」与「模型能力」两个变量。

规则引发的失败：模型还没上场就出局

最初的失败案例很典型：当有人打开另一个应用时，一条规则「前台有其他应用，把展示界面拉回来」在模型被咨询之前就触发了，导致智能体错误地干扰用户操作，成功率0/20。问题不在模型，而在规则太早介入。

开发者引入了「争议机制」：如果规则读取不到的证据（例如最近30秒内有人触摸屏幕）反驳了规则的动作，该规则被视为有争议，此时先询问模型。同一个模型，成功率直接变成20/20。而对照场景（前台有应用但无人触摸）仍然以零模型调用保持20/20。这说明，不是模型变聪明了，而是模型在正确的时机被召唤。

争议机制是一种元规则：当某条规则所依据的证据不完整或被相反证据削弱时，不直接执行该规则，而是把决策权交给模型。实现上，每条规则声明其依赖的证据类型（如屏幕触摸事件、前台应用状态），系统在触发前检查这些证据是否可得且未被反驳。若最近 30 秒内检测到触摸，而规则只看到「前台有其他应用」却读不到触摸证据，则该规则被标记为「有争议」，转入模型询问流程。这一设计把模型的调用时机从「固定兜底」改为「按证据冲突触发」，既减少无谓的模型调用，又避免规则在信息不足时误判。

规则优先：模型只在规则沉默时发言

实验还发现，规则优先的策略在几乎所有场景下都能匹配纯模型方案的正确率。在可预见的故障中，纯规则方案实现了240/240的完美恢复。模型只负责提议，而一个确定性的策略层负责裁决：只允许目录内动作，优先选择破坏性最小的操作，并设置预算和冷却时间。没有任何不可逆动作仅凭模型的「信心」被授权。

这种设计将模型定位为「顾问」而非「指挥官」，既利用了模型的泛化能力，又通过确定性策略兜底，避免了模型幻觉带来的风险。

确定性策略层是不含随机性或模型推理的裁决模块，按固定优先级和约束对候选动作做筛选与排序。典型约束包括：动作目录（白名单，只允许预定义动作）、破坏性最小优先（如先尝试重启服务再考虑清除数据）、预算与冷却时间（限制单位时间内的动作次数，防止抖动或风暴）。不可逆动作指删除数据、卸载应用、恢复出厂设置等无法回滚的操作，策略层要求此类动作必须有额外授权或人工确认，不能仅凭模型输出的置信度放行。这样模型只提供候选建议，最终执行由可审计的确定性逻辑决定。

验证与学习：证据比信心更可靠

实验强调用决策器看不到的证据来验证结果。在真实手机上，强制停止命令返回成功，但应用仍在运行——「命令返回OK」不等于「问题已修复」。只有独立验证才能确认故障是否真正解决。

学习机制也很克制：重复出现的答案会被编译成规则，但候选规则必须在484个历史事件上回放通过才能晋升。真正阻止坏规则进入系统的，是回放验证，而不是模型本身。这形成了一种「提议-验证-固化」的闭环，让规则库稳步进化而不失控。

独立验证器是与决策器分离的检查模块，使用决策器看不到的观测信号（如应用进程是否仍在、界面是否可交互、后端健康检查结果）判断故障是否真正修复。它与决策器隔离，避免「自己验证自己」的偏差。回放验证指把候选规则放到历史事件日志上重新执行，检查其决策结果是否与已知正确结果一致；只有全部或高比例通过才允许晋升为正式规则。历史事件回放相当于离线回归测试，能拦截在单一场景下有效、但在其他场景会误触发的规则。实验中的 484 个历史事件即回放数据集，规则晋升需在此通过，形成「提议—验证—固化」的闭环。

启示：先检查结构，再考虑换模型

这项实验传递的核心信息是：在伸手去拿更大模型之前，先检查你的智能体在什么时候被询问，以及什么在检查它的输出。更强的模型只是下一次运行的事，而模型本身只是一个配置开关。对于构建可靠智能体的团队来说，投资于规则边界的设计、争议处理机制和独立验证流程，可能比升级模型带来更直接的收益。

开发者最后提出的问题值得每个从业者思考：在你的系统中，你如何决定规则与智能体的边界？