1. 本地化Agent为什么绕不开小模型这堵墙先说个很现实的场景某AIoT公司做设备预测性维护时边缘网关里只有一块工业级芯片内存256MB还要同时跑采集、滤波、协议转换和运维决策。想在网关里直接塞一个70B的大模型做故障分析先不说显存能不能放下光是那几秒的冷启动延迟就能把产线上的告警窗口全拖过去。这时候很多人会问那能不能把大模型的能力“压缩”到小模型里我的态度是方向错了正确的解法不是压缩模型而是重构任务——用Agent Skills把大任务拆成小动作再用POMDP把决策逻辑固定下来。这篇文章是我基于一套真实落地的小模型Agent Skills方案写的总结核心主题是工业级的本地化Agent在“离线、低成本、高可靠”三重约束下应该怎么设计。我们这一轮做的是把7B量级的本地模型接进一套基于POMDP的决策框架里配合一组自定义的Agent Skills覆盖了产线告警诊断、设备参数调整建议和夜间巡检辅助三个任务。整套方案跑在纯本地的容器里不依赖云端API所有推理都在内网完成。适合看这篇文章的人我认为有两类一类是正在为“大模型部署成本太高”发愁的工程团队另一类是已经在做Agent相关项目、但对POMDP这类经典决策理论怎么跟现代LLM结合还没有清晰思路的人。这篇文章可能会打破一个观念小模型并非大模型的“降级替代”在特定任务约束下小模型Skills的组合在时延、成本、可解释性上是可以优于大模型方案的。标题里提到的POMDP全称是部分可观测马尔可夫决策过程。它跟普通Agent方案最大的区别在于它不假设Agent能拿到“完全真实的环境状态”而是用一套“信念状态”来维护自己对世界的估计。这个特性跟工业场景特别匹配因为传感器永远有噪声数据永远有缺失你永远不可能让Agent看到全部真相。这一点恰恰是大模型做决策时最忽视的部分——大模型默认“你问它什么它都能答”但真正到了执行层面观测不完整这件事会致命地影响判断。这一轮测试下来我可以很明确地说小模型Agent Skills完全能用而且不只是“能用”在某些指标上还相当能打。文章后面我会拆开讲原理、架构、实测数据踩坑记录把我踩过的、调整过的、最终稳定下来的方案全部写出来。想直接抄作业的朋友重点关注第三、四、五章。2. 拆解POMDP为什么它比纯Prompt工程更配得上“工业级”2.1 POMDP的五元组跟Agent架构是怎么对应的多数人聊Agent时随口就是“记忆、规划、工具调用”但真到了要保证“每次决策都有依据、每步动作都可追溯”的阶段这些词就不够硬了。POMDP的价值在于它把Agent系统变成了一个数学上有边界的决策结构每个决策步骤都能对应到一个形式化元素上。用一个简单的对照就能说明白POMDP元素含义在Agent系统中的落地对应物状态空间S环境真实状态的全集产线点位状态、设备健康度、当前告警级别动作空间AAgent可执行动作的集合调用某个Agent Skill、切换诊断策略、升级告警观测空间OAgent能获得的传感器/文本信息日志片段、传感器的数据窗口截图、告警文本状态转移T动作之后环境发生变化的概率某操作执行后设备状态的变化统计观测概率O在当前状态下产生某种观测的概率日志中症状与真实故障之间的相关性奖励函数R每个动作对应得失的量化标准诊断命中得分、误报扣分、操作耗时惩罚这套映射做完之后Agent的每个动作都有了精确的定义域。很多团队做Agent只觉得“模型能回答就行”完全没定义“模型能不能做这个动作”“做了之后可能得到什么观测、转移到什么状态”。POMDP把这一层补上了这也正是“工业级”三个字的关键所在。2.2 信念更新机制为什么小模型能在不确定性下“猜得准”POMDP里最核心的机制是信念状态更新。简单说Agent心里维护着一个“当前最可能是哪个状态”的概率分布叫做信念状态。每次拿到新的观测之后它不是直接推翻原来的判断而是按照贝叶斯公式更新这个分布。这也是POMDP跟传统规则专家系统最根本的差异——规则系统只跟“当前输入”说话但POMDP会同时参考“历史信念新观测”来形成判断。我们在实测中有一个印象极深的案例产线上某设备温度异常Agent在前一次观测中已经倾向于“冷却液不足”这个假设但置信度只有0.55。下一次观测来了压力信号正常但振动信号有轻微上升。如果是一个“只看当前输入”的规则系统很可能被压力正常这个信号误导直接转向“轴承磨损”假设。但POMDP的信念更新机制结合振动上升和冷却液不足之间本来就存在的相关性把“冷却液不足”信念从0.55拉到了0.78后续的动作全部围绕这一个假设展开最终诊断与实际故障完全吻合。这个特性对小模型来说是加分项而不是负担。因为小模型本身对复杂上下文的利用能力不如大模型如果每次决策都像“失忆的人被拉来问路”那再强的底座也白搭。但信念更新机制实际上给小模型外挂了一个“长期记忆概率推理器”让每次决策不是从零开始而是基于累积证据往前走。我认为这是整套方案“以小博大”的根本原因。2.3 为什么大模型直接硬干反而不如“小模型POMDP”很多人会本能地问直接把POMDP换成大模型的CoT思维链不就行了吗我的实测结论是不行。大模型跑通用推理确实很强但有两个致命问题。第一是决策过程不具备可复现的概率语义。你问大模型“你有多大把握是冷却液问题”它给出的回答可能是“非常有把握”但这个把握程度没法参与任何概率运算也不能在后续观测里被按公式更新。第二是长流程动作容易漂移跑着跑着忘了任务边界。POMDP刚好补齐这两个缺陷具备形式化概率语义和严格的信念收敛过程。小模型在这里的定位也很清晰它不负责做出“最终决策”它主要负责把非结构化的文本观测映射成结构化的特征表示。也就是说小模型在POMDP框架里充当的是“观测编码器局部推理器”它把“温度有点高而且波动大”这种自然语言内容编码成可供信念更新函数使用的结构化证据。这一步让整个Agent的决策质量和推理底座解耦底座差一点决策质量并不差。这也是我对整个方案最核心的判断大模型、小模型之争在Agent场景里其实是伪命题。真正重要的是谁在负责决策谁在负责语言理解。当你把决策逻辑交给POMDP把语言理解交给小模型你就会发现底座规模的重要性断崖式下降。3. Agent Skills设计小模型的能力边界被“技能化”扩张3.1 Skills不只是工具调用而是动作空间的标准化再来看Agent Skills的设计思路。现在很多文章讨论Agent Skills上来就列一堆工具列表。但在我看来Skills在POMDP语境下有一种更本质的定位它实际上是在为动作空间A定义一套“可枚举、可验证、可组织”的执行单元。也就是说Skill不是万金油函数它是在特定状态转移中能够被预期效果的标准化子过程。拿我们的方案为例整个系统一共定义了6个Skill不多但覆盖了诊断、查询、建议、上报四个维度Skill名称输入观测动作效果关联的POMDP状态转移analyze_symptom告警文本传感器窗口数据输出候选故障假设置信度从排查态转入假设态query_manual故障假设设备型号检索本地维护手册相关段落假设的证据增强correlate_signal故障假设历史信号数据计算多路信号相关性特征更新信念分布suggest_action故障假设置信度设备状态输出维修或操作建议转入动作推荐态escalate_alert置信度风险等级向上级系统生成升级告警状态收敛到最终态write_log全量上下文生成操作记录与文档进入收尾态从POMDP角度来理解每个Skill本质上都对应一类状态下的“动作候选”。Agent系统在决策时先判断当前信念状态落在哪个区域再从可用Skill里挑出最适合的那一个。小模型的角色在这里变成“状态识别器”它判断当前该倾向哪个动作方向而具体动作执行后的效果由系统逻辑来保证。这种分工让整套系统非常稳。3.2 Skill的粒度控制也不是越细越好过粗过细都会出事Skill粒度设计可能是整个方案里最容易翻车的地方没有之一。我们最初把Skill设计得特别粗一个execute_action就包打天下。结果是动作语义太泛系统根本没法决定什么时候该调用它信念更新也不知道该拿这个动作的哪个结果来校准分布。后来改成另一套极端做法把每个Skill拆成十多个微步骤表面上看起来灵活但模型频繁在Skill之间跳来跳去上下文窗口根本装不下而且每次跳转都有工造成的时延最终整个方案慢到不可用。经验公式是一个Skill的输入、输出都必须可以被一个持续的观测窗口覆盖。也就是说模型只需要关注“最近几步的上下文”就能完成Skill的输入输出映射。以我们的correlate_signal为例它只关心最近5分钟的信号窗口不需要长周期记忆这就保证小模型不会因为上下文过长而丢失关键信息。粒度判断我们最终的校准标准是——当一个Skill的描述超过40个字还说不清楚动作边界时就说明这个Skill拆分得有问题需要重新定义。3.3 小模型的规划能力弱怎么办用“前向引导”给Agent戴上安全绳小模型最吃亏的地方是长链路规划能力。让它一口气规划八个步骤再逐步执行大概率中途就会跑偏。我们的解法是引入“前向引导机制”系统在阶段起点生成一组“候选Skill序列”模板而不是让模型自由生成完整规划。模型的作用是从模板池里挑选最合适的一条路径。当完成当前动作后再基于最新信念状态继续选择下一步。整个过程规划权仍然在POMDP框架手里模型只是一个“局部选择器”。这套设计非常像“给不会开手动挡的人改装了一台自动挡车”。模型不需要理解复杂的路径规划它只需要在每一个档位选择正确的下一步动作。经过实测这套机制把长流程任务的成功率提升了将近三成同时避免了小模型在长规划链条上因为“遗忘”而导致的错误。实际上对7B量级的模型来说与其强求它具备复杂的规划能力不如在系统层面把复杂规划拆解为“自动挡”选择问题。这也是我想对所有在小模型上硬凹“Agent规划能力”的团队说的不要跟底座能力较劲要在系统架构上做补偿。4. 从观测到动作本地化Agent运行时的完整决策链路4.1 观测处理先抽取证据再走向量映射只有当理论映射到线上实际运转时才算落地。我们的系统日常运行时第一步做的永远是观测处理。告警文本里往往包含大量干扰词比如“该设备于10:32产生温度过高告警当前温度为83.5摄氏度……请确认”这类表达。如果直接把这堆原始文本丢给小模型去“理解”效果会有一定误差且很容易被“请确认”这样的运维废话带偏重点。我们的做法是先做一层证据抽取通过一个轻量信息提取模型把时间、点位、数值、事件四个要素结构化再转成统一的观测向量。这套抽取逻辑不需要额外训练基于一个公开的小模型通过少量样例就可以做到很高的准确率。观测向量也不是简单的“文本嵌入”而是针对设备域定制的结构化描述。比如温度观测的向量就会包含“数值偏移量、变化速率、与上一小时的差值”等字段。这样处理之后信念更新模块拿到的是一个规范的、可计算的输入而不是模型随缘输出的自然语言。在实际测试中带上结构化抽取的版本比直接喂原始文本的版本在诊断准确率上高出约11个百分点。4.2 信念更新怎么落地不用贝叶斯公式从头算用查表就可以很多人一听到POMDP就想到复杂的贝叶斯更新数学推导担心计算量在边缘设备上吃不消。实际上在工业场景中状态数量和观测空间都是有限的。以我们这套方案为例设备故障状态只选了8种常见类型观测信号种类也只有10条相关特征。在这种有限规模下信念更新完全可以预计算成一张概率表系统运行时只需要查表更新即可。这个设计对本地化部署的意义非常大。它意味着Agent系统实质上运行时不涉及任何复杂的概率计算一个查表操作微秒级就能完成。这也是我特别喜欢POMDP的地方——它是理论上很“重”的框架但只要在落地阶段把离散化做好运行时的负担就小得惊人。从实测数据看更新一次信念分布的平均耗时不到0.02毫秒几乎可以忽略不计。信念更新的核心逻辑本质上就是“预测校正”两步。预测环节按照状态转移概率把上一步的信念往前推校正环节拿最新观测和观测概率表对信念重新加权、归一化。这两步在代码架构上被封装成一个独立的服务层不依赖任何模型推理资源因此哪怕小模型因为任务过载暂时降速信念更新始终能保持实时运转。这种结构分层带来的鲁棒性在大模型方案里很难复制。4.3 动作选择的折中策略精确采样不如“阈值触发随机采样”动作选择策略是整套系统最需要调参的地方同时也是最容易过度设计的地方。理论上有两种极端做法一种是纯贪心策略每次只选择信念中最优动作另一种是完全随机采样以信念分布为权重随机抽取动作。纯贪心策略的问题是容易陷入局部最优尤其是在观测噪声较大的弱信号场景下完全随机采样虽然探索性强但可能会做一些“看起来没把握”的动作这在工业场景下不可接受。我们最终使用的是“阈值触发随机采样”的混合策略。具体描述为当最优先动作对应的信念值超过某个阈值我们最终调节为0.72时直接触发若不满足则进入随机采样模式按信念分布加权抽取下一步动作。这个做法既保留了对高置信度状态的果断性又给了低置信度状态一个“探索”的出口。也就是说在系统明显偏向某个故障假设时立即执行在系统拿不准时它会试一个观测信息更丰富的动作去买新证据。长时间跑下来的结果非常理想对比纯贪心策略任务完成率提升约18%而且没有一个“乱动作”导致了实际操作风险。5. 实测效果三组对照实验告诉你小模型方案输不了5.1 实验一跟“大模型零样本”方案比任务完成率和时延我在同一批标注好的工业流实测数据上对比了小模型POMDPSkills方案和大模型零样本方案的各项性能表现任务池里有产线告警诊断、参数建议生成、夜间巡检判断。这个对比非常能说明问题。指标小模型POMDPSkills(7B本地)大模型零样本(云端API)差值诊断任务完成率91.4%89.2%2.2%平均决策时延(单步)0.46秒2.3秒快5倍误报率3.2%7.6%低4.4%单次任务成本约0.015元约0.42元省约96%离线可用性完全支持不支持—大模型零样本方案准确率其实没有想象中那样碾压式领先反而在误报率上输给了小模型方案。核心原因在于大模型对“工业上下文中的不确定性”没有感知它倾向于用常识答题而不是用统计数据更新答题。比如同样是“温度过高且波动大”的观测大模型零样本很容易直接给一个“可能是传感器故障”的答案而我们的POMDP系统会通过信念更新去对比多个假设的累积证据结论更稳。时延上的差距就更加明显了。本地小模型一次推理只有几百毫秒但云端API光网络往返就带来了明显额外开销。在工业现场告警窗口可能只有几秒钟这多出来的1.8秒已经足够错过一条关键的处置提示了。5.2 实验二跟纯规则专家系统比“长尾故障”覆盖率很多人可能觉得既然POMDP这么强干脆不要小模型直接上一套专家规则系统不就行了稳定可靠还省钱。为了回答这个问题我特别设计了第二组对照把POMDPSkills方案里的模型推理全部替换成“if-else规则诊断库”开发出的纯规则方案对比同一批任务。结果表明常规故障场景里纯规则系统的准确率和POMDP方案几乎不相上下甚至在某些“已被完全覆盖的故障模式”上规则系统的稳定度更好。但在占总数约18%的长尾故障场景中纯规则系统的命中率骤降到了26.5%而POMDPSkills方案依然维持在了79.3%左右。原因很好理解规则系统遇到没定义过的组合基本只能走“未知故障”分支瞎蒙或上报而POMDPSkills方案里的小模型可以帮助系统从不规则的文本观测中提炼出类属特征再借助信念更新把未知故障往“最像的那一类”上靠拢。这组数据说明了一个关键问题工业场景真正的痛点不是“常见的五次故障”而是“一年只会出现一两次的疑难杂症”。在长尾故障面前规则系统的知识上限完全锁死而“小模型语言理解概率决策”的组合打开了这个上限。5.3 实验三对不同模型尺寸做敏感度分析最小能压到多小最后一个实验想解决的问题是如果模型底座进一步缩小系统会崩在哪一个环节这个结果直接影响未来我们在更廉价的硬件上部署方案的可行性。我用同一套POMDP框架和Skills分别跑了7B、3B、1.5B、0.5B四个尺寸的底座模型所有其他条件保持一致。底座模型尺寸诊断任务完成率平均单步时延崩溃风险7B91.4%0.46秒极低3B86.7%0.28秒低1.5B78.2%0.19秒中等0.5B53.6%0.13秒高敏感度分析的结果其实很有意思——系统并没有随模型尺寸减小而“线性崩溃”而是在1.5B到0.5B之间存在一个明显的断崖。原因是0.5B模型在“从噪声文本中抽取结构化证据”这一步开始失准大量关键要素丢得比较多导致后续的信念更新收不到合格输入。换句话说系统的性能瓶颈不在POMDP决策框架而在“语言理解编码器”的能力下限。这一发现直接指导了我们的硬件选型在满足成本的前提下最低推荐底线就是3B级别低于这个级别的模型再省钱也不能上。6. 落地过程中踩过的坑给小模型Agent团队的实战避坑手册6.1 坑一Skill返回格式不统一信念更新模块频繁报错第一个踩得最深也最没有料到的坑是Skill返回的结构化输出不统一。最开始我们让不同Skill的返回结果自由发挥这直接导致信念更新模块花大量精力在“猜这个字段是什么意思”上。比如analyze_symptom返回的是“可能性较高的故障是冷却液不足”但correlate_signal返回的是JSON格式的相关系数矩阵两边的字段语义完全对不上。后来我们给每个Skill都定了严格的标准返回Schema所有返回都必须是一个JSON对象包含confidence、evidence、action_needed三个固定字段。这样信念更新模块就只需要解析固定结构不需要再做语义适配。这件事看起来不起眼但确实直接决定了整个系统的稳定性上限。强烈建议任何做Agent Skills的团队从第一天起就给每一个Skill强制定义数据契约不要等到联调时才想起来。6.2 坑二小模型的“冷启动幻觉”导致诊断第一次判断就跑偏第二坑是关于小模型冷启动阶段的。前几版系统启动时小模型在没有任何历史信念的情况下直接收到观测信息然后做出第一次诊断这里就经常性出现“幻觉”会引用一些跟设备毫无关系的常识性内容。纠其原因本质是模型在“低信念先验”状态下过拟合了通用语料因为缺乏工业场景语料的兜底。我们的解决方案分两层。第一层是在系统启动阶段注入“先验信念”启动时不是完全从均匀分布出发而是依据设备历史数据把最近几个月的故障占比作为先验分布灌进信念状态。第二层是降低冷启动状态下模型的决策权重规定前两步动作必须以“信息探针类Skill”为主不允许在证据不足时就出具高置信度的诊断结论。这套组合拳打下来冷启动阶段的误判率下降了约七成。6.3 坑三过度依赖文本理解忽略了信号数值特征还有一个认知层面的坑值得提醒。因为Agent Skills里大量特性是通过自然语言触发的我们一度把诊断质量押注在小模型“读文本”的能力上导致系统对数值信号特征的利用不足。实际上在工业场景信号数据的数值特征往往比语言描述可靠得多。比如振动幅值趋势、温度变化速率、报警频率这些信息都在传感器数据里摆着不需要大模型去“意会”什么。这个认知修正之后我们在观测层单独加了一条“数值特征提取链”它不依赖模型推理用直接统计方法如均值、方差、变化斜率从窗口数据里提取紧凑的数值特征表示再与模型编码的文本特征拼接一起输入信念更新模块。这一项改造让整体诊断准确率又往上涨了大约6个百分点。这件事也让我深刻体会到Agent系统里并不是所有环节都要上模型能用传统方法的就用传统方法模型应该在它真正擅长语言泛化的地方发挥作用。7. 由当前结果往前看一步什么场景下“小模型Skills”不该硬撑先回答一个更直接的问题小模型Agent Skills这套组合边界在哪实测数据告诉我它并不适合以下场景。第一类是开放域的创意或长文生成类任务就算接上POMDP模型生成内容本身的门槛摆在那。第二类是跨系统跨领域的复杂长程推理比如让Agent同时操作数据库、前端、后端并且在多个历史会话之间进行深度关系推理这种场景小模型的上下文卡死之后信念更新模块也会出现连带失稳。第三类是决策粒度极细、动作频次极高的仿真优化场景POMDP的建模成本会变得比较高。所以我对这个方案的定位是它是一个面向“特定任务、闭合环境、可枚举动作”的局部Agent架构尤其适合设备制造、能源运维、仓储调度这类场景。在这些领域里它的可靠性、时延、成本优势都是大模型方案暂时无法追赶的。另外我还想再分享一个这轮实践中比较深刻的体会很多团队立项时就直接以“用哪个底座模型”为起点我认为这个次序是反的。应该先从任务目标推导出状态空间和动作空间再确定POMDP里各个概率模块的建模方式最后回到事实判断的底座模型该选多大。底座选型永远是系统设计的结果而不是出发点。这套顺序在我参与的多个项目里已经被反复验证过。