最近在评估一个内部项目的技术路线时我一直在纠结一个问题小模型7B、13B这种量级搭配Agent Skills到底能不能扛起工业级的本地化任务这个问题圈子里吵了很久有人说小模型做Agent就是玩具幻觉严重、任务稍微复杂就崩也有人说只要把技能库设计得足够好小模型的稳定性和性价比远超云端大模型。直到我看到一份基于POMDP的工业级本地化Agent技术报告才把这笔账彻底算明白。这份报告最硬核的地方不是堆了多少指标而是给“小模型Agent Skills能用吗”这个问题提供了一个理论化的回答框架POMDP部分可观测马尔可夫决策过程。用这个框架一拆小模型在Agent场景里的可靠性问题、技能编排问题、多轮交互中的不确定性处理问题全部都有了可讨论、可计算、可优化的抓手。这篇文章我想把这份报告的核心思路结合我自己在模拟项目X里的实践从头到尾讲清楚适合正在做本地化Agent方案选型、或者被小模型工具调用稳定性折磨过的开发者参考。1. 为什么大家都在讨论“小模型Agent Skills”这一节先聊清楚背景业界对“小模型Agent”的讨论为什么突然热起来它和大模型Agent方案相比核心差异到底在哪。1.1 大模型Agent的瓶颈不只是成本大模型做Agent单看效果确实漂亮。任务规划、工具调用、多轮对话GPT级别的能力摆在那里。但放到工业级本地化场景里问题就来了。数据合规是第一条红线很多制造企业的设备数据、工艺参数、质量记录根本不允许出内网云端API这条路直接堵死。网络条件也是硬伤车间网络环境波动大一根光纤断了整条Agent链路就瘫了这在大模型方案里很常见。更关键的是工业场景的根本诉求并不是“什么都会”而是“会的就一定要做对”。一个Agent如果偶尔在设备故障诊断上给出错误建议哪怕成功率99%剩下的1%在产线上可能就是一次停机事故。大模型的“全能”在这里反而变成了不可控因素——你不知道它在哪个知识边界上会突然胡编。而且云端大模型的单次推理成本在每天几万次调的强度下换算成年度预算相当吓人。算上网络延迟和流式输出的不确定性整个方案的SLA很难承诺。所以在真正的工业现场团队往往不是“不想用”大模型而是“不敢用”。本地化、可控性、确定性执行这些需求和云端大模型的特性天然错位。于是大家开始回过头来看那批被冷落的小模型——它们参数小、部署轻、推理快但会不会牺牲太多效果这成了整个讨论的起点。1.2 小模型加技能编排为什么能打小模型的劣势是公开的推理能力弱、上下文理解有限、容易在复杂指令下“迷路”。但工业Agent任务有个特点它足够垂直。一个设备运维助手核心任务就那么十几类每类任务的处理路径基本固定。这时候思路可以反过来——不让模型什么都干而是把任务拆成一条条确定性的技能链模型只负责“理解意图、选择技能、解析参数”剩下的脏活累活交给代码去执行。这个思路就是Agent Skills。每个技能是一段封装好的函数逻辑有明确的输入输出契约比如“查询设备最近7天报警记录”“解析工单图片中的仪表读数”。模型需要做的是从技能库里挑出正确的那把“扳手”然后按格式填好参数。这比让模型直接“思考出答案”要稳得多。小模型虽然上下文窗口小、推理链路浅但在“选技能填参数”这个任务上它足够用。我之前在模拟项目X里试过一个7B的量化模型在技能库有30个技能的情况下技能选择准确率能做到95%以上剩下5%的误选基本都能通过参数约束和二次澄清拉回来。这说明小模型不是不能做Agent而是要用对方法——它的能力上限不取决于“推理深度”取决于“任务被拆得多干净”。1.3 POMDP出现在这个讨论里的原因既然“技能编排”思路有效那为什么还要搬出POMDP这种偏学术的决策框架原因很简单工业场景里的不确定性不是靠多写几个if else就能覆盖的。用户的输入模糊、系统之间数据不一致、多轮交互中用户改了主意这些都是典型的局部可观测状态。技能编排解决的是“动作怎么做”而POMDP解决的是“下一步到底该选哪个动作”尤其是在信息不足的时候应该继续查还是澄清还是下结论。这个问题如果全靠人工写规则十几条规则以内还能撑技能库上百个之后就彻底失控了。POMDP的价值在于它给Agent的决策过程建立了一个“信念——行动——观测——更新信念”的闭环每一步动作都基于当前对任务状态的概率估计而不是拍脑袋。这份报告正是把POMDP引入了小模型Agent的决策循环让“选技能”“要不要多问一句”“能不能直接给结果”这些判断变成可计算的策略选择这也是它硬核的核心原因。2. 先搞懂POMDPAgent决策的数学骨架很多人一看到POMDP就头大觉得这是机器人控制领域的学术概念离大模型Agent太远。实际上它一点都不难而且一旦理解了你再看Agent的交互设计会有一种“原来如此”的通透感。2.1 从一个导航的例子说起想象你开车到一个陌生街区找一家餐厅。你手上没有完整地图只能看到眼前的路口和路牌这就是“部分可观测”——环境状态很多但你只能看到一部分。你每到一个路口会根据路牌决定左转还是直行走了一段又看到新的路牌再修正对“餐厅在哪”的判断。这个过程里你从来没直接见过餐厅坐标但每一步都在缩小不确定范围最后找到它。POMDP把这个过程数学化了。它由六个要素组成状态S比如餐厅的真实位置你看不到、动作A左转、直行、问路、转移函数T开了一段后位置如何变化、观测O你看到的每个路牌、观测函数Ω在某个状态下看到某个路牌的概率有多大、奖励R每走一步的代价找到餐厅给正奖励。Agent的目标是在长期期望回报最大化的前提下选择一个动作序列。这个框架和MDP马尔可夫决策过程最大的区别就是引入了观测和观测函数。MDP假设Agent能直接看到完整状态但现实里的Agent从来都不可能完全看到状态。工业现场更是如此——你不知道用户的真实意图不知道数据库里是否有匹配记录不知道上一个系统返回的数据是不是过期了这些都是“路牌之外的隐藏信息”。2.2 信念状态小模型可靠性的关键POMDP里最核心的概念不是状态而是信念状态belief state。它不是一个确定值而是对当前所有可能状态的一个概率分布。比如“用户想查的是上个月北方工厂的异常工单可能性70%想查的是华北区所有工单汇总可能性25%还有5%是别的”。Agent每一步都不直接“看到”真实状态而是维护这样一个信念分布用贝叶斯规则不断更新它。这对小模型Agent来说是关键的一把钥匙。小模型最大的问题不是“不会做”而是“不知道自己做没做对”它缺乏大模型那种“我知道自己不确定”的元认知能力。但如果你在外面套一个信念状态的维护机制模型的不确定就不再是黑盒了。每调用一个技能、每得到一次用户反馈信念分布都在更新当某个状态的概率超过阈值Agent再采取行动。我在实际项目中就是这么做的把“用户想要的报表维度”建模成几个候选状态Agent每次回复或调用工具后根据用户反应和返回数据更新概率。一开始可能50%对50%分不清但两轮澄清之后信念收敛到95%以上这时候再让模型去执行查询输出结果就相当稳了。这个机制比单纯让模型“再想想”可靠得多因为它是把不确定性显式地算出来而不是靠模型感觉。2.3 POMDP如何约束Agent的行为选择在POMDP里策略Policy是信念状态到动作的映射。给定当前的信念分布Agent选择一个动作让期望回报最大。这个回报不只看当前一步还包含未来的折扣累计回报所以Agent必须权衡“现在直接给答案”虽然快但如果答错了扣分很多“再追问一句”虽然多花一次交互但能把成功率拉高很多。这个权衡在工业场景里特别重要因为工业Agent最怕的不是慢而是错。如果把这个决策循环映射到Agent的日常交互上你会看到一个很清晰的骨架接收用户输入后先把自然语言压缩成几个关键槽位这对应初始信念然后从技能库选一个动作执行后得到工具返回结果这对应观测更新如果信念还不够确认就进入下一轮“选择——执行——更新”直到信念足够收敛再输出最终答案。这套逻辑和现在流行的ReAct、Plan-and-Execute等范式并不矛盾反而是它们的理论底座。ReAct是“推理行动交替进行”的工程实现而POMDP告诉你在每一步交替时应该如何计算“该不该继续”而不是无脑循环。理解了这层关系你再看市场上各种各样的Agent框架就不会被花哨的名字带偏核心都是那个“信念更新—动作选择”的共同点。3. 小模型Agent Skills的工业级落地架构理论框架说完了现在落到工程上。这部分我结合模拟项目X的实践讲清楚一个基于POMDP思路的小模型本地化Agent在工业现场应该怎么搭。3.1 总体架构分层我把整个系统分成四层感知层、决策层、执行层、记忆层。感知层负责把用户的自然语言输入转成结构化信息包括意图识别、槽位抽取、上下文压缩。执行层就是那批Agent Skills一个个确定性函数。记忆层维护短期对话状态和长期领域知识短期状态对应POMDP里的信念状态更新。决策层是核心它读取感知层的结果和记忆层的信念分布决定下一步动作是调用技能、澄清还是直接回答。这个分层最重要的设计原则是“模型尽量瘦代码尽量厚”。模型的职责严格限定在意图识别、技能选择、参数抽取这些“认知型”任务上而所有“逻辑型”任务比如数据聚合、条件分支、格式校验全部下沉到代码里。比如“查询设备报警记录”这个技能内部涉及时间筛选、分页查询、去重排序这些逻辑根本不经过模型模型只需要输出一个结构化的查询参数就够了。这么设计的好处有两个。第一是稳定模型参与度越低幻觉空间就越小。第二是可测每一层都有明确的输入输出契约出了问题能快速定位是模型理解错了还是参数传错了还是代码执行报错而不是整个Agent黑盒一样糊成一团。3.2 技能库的设计原则技能库是整个Agent的地基。技能设计得好不好直接决定小模型能不能用得动。我踩过不少坑之后总结出三条必须遵守的原则。第一技能粒度要“一技能一职责”。一个技能只做一件事“查询设备信息”和“查询设备报警记录”要拆成两个技能不要合并。技能拆分越细模型选择的决策边界就越清晰。反过来技能太粗模型判断“当前该用哪个”就会犹豫一犹豫准确率就掉。第二技能描述要写给模型看而不是写给程序员看。很多团队写的技能描述充满了内部术语模型根本理解不了。正确的做法是描述里说清楚“这个技能在什么场景下用、输入是什么、输出是什么”最好附上一个典型调用示例。我实测下来一个描述里带示例的技能选择准确率能比不带示例的高5到8个百分点这个提升在小模型上尤其明显。第三技能必须有输出校验逻辑。每个技能执行完后都要往数据模型里填结果然后做一层校验比如“返回值是否为空”“返回结果是否在预期枚举范围内”。校验不通过就抛出一个结构化错误信号这个信号会驱动决策层的信念更新让Agent决定是换一个技能还是转人工。这一步往往是新手最忽视的但它是工业Agent避免连环错误的最后一道闸门。3.3 任务规划与决策循环当用户提出一个复杂任务时Agent不会一次性规划完所有步骤而是走一个“三步循环”理解当前意图、选择单个动作、根据结果更新信念。POMDP在这里的应用是显式的每一次交互的开始决策层都会检查信念分布的不确定度如果不确定度高于阈值就优先选择能最大程度降低不确定度的动作——通常是查询类技能或者向用户澄清。举个例子。用户说“帮我看看A设备的运行状态怎么样”系统先做初始信念估计可能是“查实时状态”概率60%也可能是“查最近一周状态趋势”概率30%还有10%的杂类。决策层觉得60%不够高于是先调用“查询设备实时概要信息”这个低成本技能拿到结果后如果数据显示正常信念就向“查趋势”倾斜因为用户不会平白无故问一句“怎么样”如果数据显示有异常信念则向“查报警详情”倾斜。这种决策方式完全是POMDP里“用信息增益指导动作选择”的思路。实操过程中我发现这个循环要跑得顺有两个工程细节很关键。一是每个动作都要带着成本标注比如“澄清”这个动作虽然保险但有交互成本所以不能滥用否则用户会觉得Agent很啰嗦。二是信念更新的规则要写在决策引擎里而不是让模型自己算概率模型只需要输出结构化的“置信度”字段真正的贝叶斯更新用代码实现。这样又稳又快。4. 本地化部署的环境构建与资源测算工业级本地化部署第一步就是回答一个问题要买什么样的硬件够不够跑得动。这里我给出一套可复用的测算方法和实测基准。4.1 硬件选型与模型规模我会先定一个原则能用7B解决的坚决不上13B。小模型每大一个量级显存、延迟、功耗都跟着涨一截但效果提升在小模型区间里并不线性。特别是在技能编排场景下7B和13B的差距往往没有“技能描述写得好不好”影响大。所以先测试7B不够再升级这是我反复验证过的路线。以7B模型为例将权重量化到INT4之后显存需求大约在5到6GB。推理时还需要KV cache一般给2到3GB所以一张16GB显存的卡就能跑得很从容甚至可以同时开两个实例做负载均衡。13B模型量化后大约需要9到10GB显存一张24GB的卡也能跑但并发能力就弱很多。再往上14B、30B甚至更大的模型基本上就要两张卡起跳而且对CPU内存和主板带宽都有额外要求部署复杂度会上一个台阶。我在模拟项目X里的基准配置是单张16GB显卡跑7B INT4模型同时挂两个推理实例后端配一个4核8G的小服务器跑技能引擎和数据库。这套配置整体成本不算高换来的能力是单次推理延迟在2到3秒以内并发的十几个请求能稳定响应而且本地推理完全不依赖外网这在车间网络环境下是刚需。4.2 关键参数配置部署完之后参数调优是个不能跳过的环节。我有几个默认配置可以直接抄作业。上下文长度我建议设成4096而不是默认的8192或者更多。小模型在长上下文上的注意力分布很容易乱技能编排场景下真正重要的信息往往集中在前几轮对话里上下文太长反而是负担。温度从0.1起步在技能选择和槽位抽取这类任务上温度越高越容易随机出错我最终固定在0.1到0.2之间。Top-p配合温度一起调一般也是0.9以下。系统提示词里明确写入“宁可不回答也不要瞎猜”这类约束对小模型的行为约束比大模型更有效。还有一个容易忽略的参数是结构化输出约束。我在每个模型的输出层外面套了一层JSON Schema校验模型想输出什么必须严格按schema来非法输出直接触发重采样。这一步能显著降低“小模型调用技能时参数格式错误”的频率。实测如果不做约束错误率能到20%以上加了约束之后直接降到3%左右这个差距值得花半天时间去做配置。4.3 性能评测指标最后聊聊怎么评测一个本地化Agent到底行不行。我用的核心指标有三个缺一不可。第一个是任务完成率最简单的定义最终结果正确且用户确认满意的比例。第二个是平均交互轮数这个指标直接反映决策质量如果Agent老是问东问西才完成任务说明信念更新机制不够高效。第三个是P95延迟工业场景要对SLA负责平均值好看没用最差的5%请求能不能在可容忍时间内返回才决定这系统能不能真上线。我自己会在这些指标之外额外记录一个“错误模式分布”把失败案例按“技能选择错误”“参数抽取错误”“逻辑执行异常”“用户意图理解错误”四类分桶统计。这个数据比总正确率有价值得多它能告诉你下一步该优化技能描述、参数约束还是决策策略。这份POMDP报告里也强调了类似观点决策质量要分解成可追踪的中间指标而不是只看最终结果这一个数字。5. 工业场景中的常见问题与排查落地过程中总会遇到一些奇奇怪怪的问题这里整理一份高频问题速查表都是我实际踩过的坑附带排查思路的实录。5.1 高频问题速查表问题现象常见根因排查方向模型选错技能频繁答非所问技能描述语义重叠或输入示例不足检查技能库里是否存在功能相似的技能合并或增加区分性描述工具调用参数总是格式错误未加结构化输出约束或提示词schema不清晰强制JSON Schema校验配合重采样机制多轮交互中越答越偏信念状态未更新决策层没有“倾向性修正”确认每次工具调用后是否执行了信念更新代码记忆层是否被清空Agent在正常状态下突然死循环决策策略里缺少退出条件设置最大交互轮数和不确定度下限阈值满足条件强制输出或转人工返回结果看起来对但数据细节对不上技能里的SQL查询条件有误被模型幻觉掩盖为每个技能增加数据校验层比如结果数量、枚举值合法性检查同一句话在不同时间回答不一致温度偏高采样随机性太大将温度降到0.1并固定随机种子复测用户给的信息很少不知道怎么办澄清技能缺失增补一个专门的澄清技能让决策层在信念熵过高时调用它这张表我贴了好几个项目的回顾九成的问题都能归到上面这几类。而且它们之间通常是连锁反应——格式错误导致执行异常执行异常导致上下文混乱上下文混乱导致下一轮选择技能错误。所以排查的时候顺序很重要永远从“离模型最近的那一层”开始查起。5.2 排查思路实录分享一个很有代表性的案例。模拟项目X上线初期辅助报表生成技能的准确率只有60%左右怎么调都提不上去。一开始我以为是模型太笨换了好几个prompt模板都没用。后来把错误案例按分桶统计一看超过70%的失败都集中在“查询时间范围”这个参数上——模型经常把“上周”解析成“上个月”。问题根因一下就清楚了不是模型理解不了中文时间词而是技能库里的时间schema写得不够明确。模型面对“start_time”“end_time”两个字段不知道该填什么格式。修复方案也很简单在技能描述里加了一个时间参数对照表注明“上周”应该转换成具体的周一日期和周日日期并附了一个示例。改完再测准确率直接跳到92%后续通过增强schema约束进一步稳定在95%以上。这个案例给我的经验是小模型Agent的绝大多数问题本质上是“接口设计”问题而不是“模型能力”问题。模型只是夹在用户意图和技能执行之间的一层薄片你把两边的接口做清晰了这层薄片就不会出大乱子。排查时先质疑接口定义再怀疑模型能力这个顺序能帮你少走无数弯路。5.3 关于“要不要上更大模型”的抉择很多团队在项目后期都会纠结同一个问题小模型调来调去还是有几个边角案例搞不定要不要直接换一个大一档的模型我的建议是先用这个表做一次快速判断如果出错案例集中在“需要复杂推理”的任务上比如多条件综合判断、长文档归纳那换大模型确实能解决但如果出错案例仍然集中在参数解析、技能选择这些接口性任务上换模型大概率没用该修的还是接口问题。POMDP框架在这时候也提供了一个理性决策依据。模型的升级可以看作“信念更新函数的精度提升”它可以降低观测噪音、提高对状态的判别能力但并不能解决“行动集合定义不完整”的问题。换句话说如果技能库里就没有能解决用户需求的技能再强的模型也没法凭空变出答案。所以“先评估技能覆盖度、再评估模型能力”应该成为做这类决策的固定顺序。6. 写在最后的几点体会这份基于POMDP的报告虽然表面上是学术味道很重的技术方案但它落到工程上给我的核心启示其实是两个很朴素的道理一是Agent的价值不在于模型多大而在于决策系统多稳二是工业场景里的“可靠”不是靠感觉堆出来的而是靠显式的不确定性管理算出来的。我自己在实际搭建这类系统的过程中最大的一次认知转变就是从“把推理交给模型”转向“把推理拆给框架”——模型负责感知和表达框架负责决策与执行。这个过程并不轻松你需要为每一个技能写清楚说明为每一次交互设计好状态更新为每一个失败案例建立反馈闭环。但一旦这套系统跑起来你会看到小模型真的能扛住工业级任务而且它的稳定性和可维护性反而比那些“什么都行”的大模型方案更让人安心。最后再分享一个小技巧。如果你刚开始尝试这个方向不要一上来就搞完整的POMDP建模那是自己给自己上难度。可以先挑一个垂直场景手写三个技能加一层手动的信念更新逻辑跑通最小闭环。等你真切地体会到“模型选技能经常选对但偶尔选错时被信念机制纠正回来”这个瞬间你再回头去补理论就会非常轻松。这个方向迭代空间还很大但路径是清晰的值得多花时间。