“小模型+Agent Skills能用吗？”这个问题，我以前几乎不用犹豫就能回答：不能。一个7B参数量的模型，连复杂指令都容易跑偏，让它当一个能自主决策的Agent，那不是强人所难吗？但最近我花了一个下午认真啃了一份关于“基于POMDP的工业级本地化Agent”的报告，发现我之前想得太简单了。这篇报告不是概念堆砌，而是在真实工业场景里做了对照实验和架构拆解，结论让我很意外：小模型配上Agent Skills，再用POMDP做决策控制，是真的能顶上去的，而且某些环节的数据比云端大模型方案还好看。这篇内容就是想把这套东西拆开揉碎，讲讲小模型为什么“看起来弱但能用”，POMDP到底在里头干了什么活，以及如果你想自己落地，应该在哪些地方下功夫。

1. 先搞明白：这份报告到底在研究什么

1.1 “小模型”说的是哪一类模型

我最早看标题时以为“小模型”泛指所有开源模型，但看完正文才知道，报告里说的“小模型”是有明确边界的：参数量在3B到14B之间的开源模型，通过INT4或INT8量化后，单张消费级显卡就能跑起来，或者直接部署在边缘计算盒子里。这类模型的共同特点是：能完成基本的文本理解和生成，但复杂推理、长上下文、工具调用能力都明显拉胯，和闭源大模型差了一个身位。

之所以选这个区间，不是因为模型能力刚好够用，而是因为算力成本和数据主权卡在这条线上。想用更大的模型，要么买高昂的API调用，要么得在公司机房堆硬件，这对很多制造企业、能源企业来说都不现实。小模型的一条潜在出路，就是“架构补足能力”：不指望模型自己什么都懂，而是让它在一个不那么智能的壳子里，做出还算聪明的行为。

1.2 为什么工业场景一定要“本地化”

“本地化”在报告里被反复强调，不是技术洁癖，而是三个硬性约束逼出来的。

• 第一是数据合规和私域性。工业现场的工艺参数、设备日志、质检数据都是企业的核心资产，很多合同和审计要求明确规定数据不能出园区。把生产数据送到外部API，光合规评审就能卡几个月。
• 第二是时延。工业控制场景里的很多决策窗口只有几百毫秒，而Agent要经过“理解请求->规划->调用工具->生成回复”这一整条链路，如果每次都和云端来回通信，链路稍微抖动就废了。
• 第三是可用性。车间网络断掉是常态，一旦Agent依赖外部服务，断网就是停线。所以工业级Agent必须能完全离线工作，模型、技能库、知识库全部放在本机或内网。

这三个约束放在一起，导致唯一可行的选型就是小模型+本地部署。大模型很强，但在这个场景里“进不来”。

1.3 报告的主线：把POMDP引入Agent控制层

这份报告最硬核的地方，不是堆了多少粗糙的本地方案，而是它把“部分可观测马尔可夫决策过程”这个偏学术的控制模型，真正用到了Agent的决策循环里。

一般人对Agent的理解是：模型拿到任务后直接调用工具，然后根据反馈继续下一步。但报告指出，在工业现场，Agent永远无法知道系统的“真实状态”。设备告警可能误报，传感器数据可能延迟，控制系统反馈可能和实际操作脱节。如果Agent只看单次观测就做决定，很容易被噪声带偏。POMDP的引入就是解决这个问题：Agent不直接看“观测值”，而是维护一个“信念状态”——对系统所有可能状态的概率估计，每收到一条新观测就更新一次，然后基于信念状态做决策。

这个思路技术上是成熟的，但在Agent落地里被应用得这么直白，确实少。后面我会详细拆解它到底改变了什么。

2. POMDP：让Agent在“看不清”的时候也能下手

2.1 从MDP到POMDP，差在哪

要先理解POMDP，可以先从它的前身MDP说起。马尔可夫决策过程假设Agent能完全看到当前状态，状态转移只依赖当前状态和采取的动作，Agent的目标是找到一个策略，让累积收益最大化。这个框架在很多经典控制问题里很好用，比如库存管理、路径规划。

但到了真实工业环境，这个假设就撑不住了。你告诉我当前设备状态是“正常”，但你怎么知道的？也许你只是看到回传电压正常，可齿轮箱内部已经开始磨损了，你压根看不到。POMDP放宽了这个假设：真实状态被隐藏了，Agent只能拿到一个和真实状态有概率关系的观测。它不再说“当前状态是X”，而是说“我有70%的把握状态是正常，25%的把握是退化，5%的把握已损坏”。

2.2 信念状态：Agent大脑里的“概率地图”

“信念状态”是POMDP里最核心的概念，也是一个被很多人忽略的好工具。它本质上是一个概率分布，写在数学上就是向量b(s)，表示Agent对每个可能真实状态s的置信度。任务不是求出唯一确定的状态，而是持续维护这组概率。

每当Agent执行一个动作并收到新观测时，就通过贝叶斯公式把先验信念更新为后验信念。这个更新过程非常简单，但效果极其强。它让Agent不会因为一次抖动就立刻改变判断，也不会对持续异常视而不见。比如报警值偶尔超过阈值，信念状态只从90%正常滑到80%正常，不触发维护动作；但连续三次超阈值，信念状态就会快速逼近“故障”区间，这时Agent就不再犹豫，直接安排停机检查。

这个机制对工业场景非常重要，因为故障的早期信号往往不是一次突变，而是一串微小异常的累积。普通的大模型Agent很容易在上下文里被最新一条消息牵着走，而信念状态相当于给Agent提供了一个“长期记忆”的概率形式。

2.3 POMDP在工业Agent里的三个具体作用

结合报告里的实验设计，POMDP在Agent循环里承担了三个不可替代的任务。

• 第一个是异常状态的早期识别。在设备发生真实故障前，通过观测序列更新信念，把“潜在故障”的概率推高，进而提前切换策略。
• 第二个是动作选择的分流。信念状态把问题空间划分为“正常区”“警戒区”“危险区”，Agent只需在这三个区块内选择不同策略，不需要在每一步都做大规模规划，大大减轻了小模型的推理负担。
• 第三个是反馈校验。工业控制里，执行了动作不代表动作一定生效。Agent发出“停止传送带”指令后，需要结合后续观测判断是否真的停了；如果没停，POMDP策略会把它解释为“执行失败”，触发重试或升级告警，而不是让Agent在那里自说自话。

这三个作用，本质上都不是让模型变得更聪明，而是让决策变得更稳。小模型本身容易“忘事”“猜错”，但信念状态帮它把信息压缩成一组概率数据，不容易忘，也不容易猜过头。

3. Agent Skills：给装备差的小模型“开外挂”

3.1 什么是Agent Skills

Agent Skills最近被频繁提起，但它不是新概念，本质上就是“可复用的原子操作集合”。一个Skill是一段结构化的行为原语，包含名称、参数列表、触发条件、执行逻辑、返回结果格式。举个例子：在产线场景里，“读取当前产线温度”是一个技能，“写入维护工单”是一个技能，“调用预测模型判断轴承剩余寿命”也是一个技能。

之所以叫“Skills”而不是“普通函数”，是因为它比普通函数多了两层东西：一是语义层面，它告诉Agent这个技能在什么业务意图下使用；二是组织层面，它带描述、示例和校验规则，让模型可以基于文本描述完成调用。以前的Agent可能要把业务逻辑塞在提示词里，Skills相当于给Agent提供了一本结构化的“操作手册”。

3.2 为什么大模型靠涌现，小模型靠Skill补

大模型在Agent场景里能表现得像是“天生会使用工具”，其实是海量预训练数据带来的涌现能力。你用自然语言描述“查一下温度并判断是否偏高”，大模型基本能理解意图并正确调用接口。小模型不行。小模型在指令理解上的天花板太低，同样一段话，大模型能抓住两个隐含意图，小模型只能抓住一个。

但有一个残酷的现实：工业场景里，你根本不需要模型处理那么多隐含意图。场景里的任务是可以提前枚举的——巡检、诊断、调度、记录、告警。一旦任务边界确定了，你完全可以把这些操作封装成一组技能，然后让小模型只做一件事：从技能列表里选一个、填好参数、解释结果。

这就像“把开卷考试变成闭卷题库”。题目范围都划好了，模型需要的能力从“全能推理”降级成了“模式匹配”。当模型只需要理解技能的文本描述和参数要求时，7B模型也能做得不错。

3.3 把POMDP和Skills串起来：控制层决定技能调度

这套架构的关键在于，小模型不是直接根据用户指令决定调用哪个技能，而是POMDP策略层先把信念状态转换为“当前应该进入哪个操作模式”，再由小模型从这个模式允许的技能集合里做选择。比如：

• 信念状态在“正常区”时，Agent只允许做常规监控和记录类技能；
• 信念状态进入“警戒区”时，允许触发诊断类技能，并在诊断完成后给出预警建议；
• 信念状态进入“危险区”时，强制调用停机保护类技能，同时生成告警工单。

这个分层极大减小了小模型的选择空间。原来模型要在几十种技能之间做精细化区分，现在它只会在最多五六个技能里做选择。技能一旦选错，POMDP策略层也能通过执行校验及时发现并重试，而不是一路错下去。

3.4 技能构建实操：拆解、描述、验证三件套

我在实际测试中发现，技能库的构建质量比模型选型还要重要。报告里提到的方法可以总结为三个步骤。

第一步是“拆解”：把业务流程的所有操作动作不重不漏地列出来，每个动作尽可能原子化。比如“调整传送带速度”和“设置传送带速度上限”要拆成两个技能，不要混在一起。

第二步是“描述”：每个技能必须写清楚用途、参数、示例输入输出、注意事项。这里有个坑：描述太简单，模型不会用；描述太长，小模型上下文窗口扛不住。我自己试下来，一个技能的描述控制在100到200字之间最合适，核心信息前置，示例放在最后。

第三步是“验证”：每个技能构建好后，要让目标模型反复调用100次以上，观察它的命中率和参数错误类型。如果模型在某类技能上频繁选错，就要考虑调整技能名称或描述。这个验证过程看起来笨，但非常有效，能直接决定Agent能不能上线。

4. 报告里的关键实验：小模型方案到底差在哪、赢在哪

4.1 测试环境设计：仿真产线 + 私有化部署

报告里描述的是一个柔性装配产线仿真环境，包含上料模块、视觉质检、机械臂装配和输送带调度。Agent的目标是在运行过程中处理异常事件、安排维护计划、修改产线参数，并保证一定时间的连续生产。传感器会偶尔丢包或误报，控制指令的反馈也有概率延迟，这正好覆盖了POMDP需要的非确定性条件。

被测试的Agent有两种配置：一种是大模型直连模式，模型直接充当调度大脑；另一种是小模型+Agent Skills+POMDP策略层。两边都部署在本地服务器，网络隔离，完全离线。这个设置很值得参考，因为它把大模型的优势架空了——大模型真正厉害的地方是它见过的世界很大，但在一个封闭、可枚举的工厂环境里，它的世界知识并不能转化为太多额外的操作能力。

4.2 我复现时改了几个参数

我没有条件完全复刻整个实验，但按报告的方法做了一次简化版，用一台显卡部署了一个小模型。改动主要有三个：把技能数量从30个缩到12个，把仿真环境跑成单机版，把POMDP更新周期从实时改成每两秒一次。改动之后，结论方向仍然和报告一致。

我自己的对比数据是这样的：

任务成功率方面，大模型方案仍然领先，没有意外。但真正让我意外的是时延和严重错误率：小模型方案的端到端决策链路非常短，而且由于POMDP策略层限制住了动作范围，几乎不会出现“模型自作主张执行危险操作”的情况。

4.3 最有价值的发现：错误模式不一样

报告里一个很扎眼的发现在于两种方案的失败模式完全不像。

大模型方案的错误大多数来自“幻觉式操作”，典型表现是：模型在计划里想象了一个不存在的功能，或者把一个动作的副作用描述成了另一个动作。比如出现异常时，模型会虚构一个“重新校准全产线参数”的命令，而真实系统里根本没有这个接口。这类错误很难防范，因为幻觉是随机的，你永远不知道模型哪一步会编。

小模型方案的错误则集中在“参数偏差”：它很少选错技能，但经常把参数写偏，比如把温度阈值写成300而不是500，把延时设成5秒而不是10秒。这类错误反而好处理，因为只要在技能调用层加上参数范围校验，就能过滤掉一大部分非法值。换句话说，小模型方案的错误是可枚举、可拦截的，大模型方案的错误是黑天鹅。

这个结论直接影响了一个工程决策：如果你想做一个可靠的工业级Agent，大模型方案要花大量精力在约束模型行为上，而小模型+Skills+POMDP方案的约束点非常清晰，就是技能库和参数校验规则。后者的工程量是可预测的，这一点在很多企业里比最终准确率还重要。

5. 本地化部署与实操实现：把方案从报告搬进机房

5.1 模型选型：别盯着参数规模，盯任务负荷

如果你要在本地复现这套方案，第一个问题就是选模型。我的建议是，在能跑得动的范围内，优先选指令遵循能力强的模型，而不是纯粹追求参数量大。因为在这套架构里，模型的主要任务是“从技能列表里选一个并填参数”，指令遵循能力远比知识储备重要。

另外建议优先考虑量化方式。用INT4量化把模型塞进单卡是常规操作，但要注意量化对指令遵循的影响。我测下来，有些模型量化后性能掉得不多，有些则明显变笨。保险的做法是拿技能调用测试题在量化前后各跑一遍，正确率下降超过三个点就换另一种量化格式。

单机显存够用的话，尽量选有更强中文能力的模型；如果任务以英文参数和日志为主，选通用开源模型也没问题。总之，模型选型服务于技能调度平均错误率，别的都是虚的。

5.2 推理框架部署：别在小事上翻车

推理框架要考虑三个点：第一是延迟稳定性，第二是批处理能力，第三是兼容性。工业场景不太需要极致的吞吐，但非常忌讳偶发的长尾延迟。我的建议是最开始就做一次压力测试，模拟连续调用几十次技能，看耗时分布是不是稳定在一个区间。

除了框架，还有一个很容易被忽略的点：模型的上下文管理。Agent每轮都要把当前技能列表、部分观测、历史信念状态塞进提示词，如果一直累积，小模型的上下文会被拖爆。实践中要设计一个精简的“系统提示词模板”，只保留本轮决策必需的信息，比如最近几条观测和信念向量，去掉历史细节。这个模板的写法需要反复调，但收益很大。

5.3 技能库管理：你迟早要面对版本和冲突

技能库不是写一次就完事了。现场会不断加传感器、改控制接口，技能描述和参数都要跟着改。如果你只有一个文件，改来改去很快就乱套。

我的建议是给每个技能加上版本号，并且在技能描述里写清“从哪个版本开始支持”。调用层要记录Agent使用了哪个版本，方便排查。新增技能时，必须先在仿真或沙箱环境里跑通验证，再切到真实环境。技能冲突更要注意，比如“停止传送带”和“紧急停止传送带”，如果同时存在，模型很容易混淆。处理办法是让名称体现粒度差异，或者在描述里明确适用范围。

5.4 一个你直接能抄的参考架构

把流程串起来的话，大概是这样的：

• 最底层是工业接口层，负责和PLC、传感器、数据库通信，把数据统一成结构化格式。
• 第二层是状态感知层，收集结构化观测，执行数据清洗和异常过滤。
• 第三层是信念维护层，维护当前系统状态的概率分布，每收到一组新观测就更新信念向量。
• 第四层是策略控制层，根据信念向量判断处于哪个操作区间，确定允许执行的动作集合。
• 第五层是Agent执行层，小模型读取允许的技能列表，生成具体的技能调用请求。
• 最上层是校验层，检查参数合法性、执行前置条件，并收集执行反馈回流给信念更新模块。

这个架构里最妙的一点是：小模型的角色被严格限定在“生成调用请求”这一段，它不需要理解整体生产流程，也不需要维护长期目标。长期目标被编码在策略控制层里，短期动作生成归小模型管。各干各的活，责任边界非常清晰。

6. 实测中遇到的问题和排查办法

6.1 两个高频翻车点，我帮你踩过了

第一个翻车点在“技能选择漂移”。模型在简单任务上选技能很稳，但一旦任务描述里出现两个技能的关键词，它就容易选偏。解决方法是调整描述措辞，把区分度最高的关键词前移，比如把“读取实时温度”和“读取平均温度”改成“读取当前温度值”和“读取一个时长内的平均温度”，效果立竿见影。

第二个翻车点在“信念状态发散”。系统长时间运行后，信念概率可能被异常的观测序列拉到一个极端值，之后恢复不过来。我后来加了两个限制：概率更新时给每个状态设一个最低下限，比如不低于百分之五；连续多轮没有异常观测后，强制把信念向“正常”方向拉回一部分。这样能防止Agent对某一次误报耿耿于怀。

6.2 问题排查速查表

6.3 三个最容易被忽略的细节

第一，别把POMDP想得太复杂。落地时不需要求解精确策略，只要用“信念区间+规则策略”就能覆盖八成需求。把学术概念降级成工程规则，反而更可靠。

第二，日志要做成可回溯的。工业Agent出问题时，责任判断和日志字典一样重要。日志里除了记录模型输出，还要记录当时的信念向量和技能白名单，否则出问题时你根本不知道Agent为什么那么选。

第三，给Agent设计一个人工接手通道。不管是多好的策略层，总有它处理不了的状况。系统监测到连续N次校验失败或信念状态混乱时，要自动切换到人工模式。这个兜底通道不复杂，但价值极大，它决定了你的Agent能不能在真实产线里活过第一周。

从我个人这段时间折腾下来的体会看，小模型+Agent Skills+POMDP这套组合，完全不是妥协方案。它实际上是在“单点能力有限”和“环境不确定性高”这两个现实约束下，能找到的最优工程解。大模型当然更聪明，但在封闭的工业场景里，聪明不如可控，知识量不如一致性。如果你也在做本地化Agent，不妨把小模型先放回工具箱里，配合技能库和信念状态重新试一次。