简介：Agent Skill正在从黑盒经验走向可量化工程。本文从POMDP视角系统定义Agent Skill，拆解其文本描述、内部策略与引用机制三元结构，说明它如何解决工业级本地部署中的合规、成本与可观测性问题，并分析该形式化方法在金融风控、数据隔离等场景中的适用边界与落地注意事项。
Agent Skill，在通常的工程语境中，指的是智能体为完成特定任务而封装的一组可复用能力。它可能是一次文档解析流程，可能是一段数据清洗脚本，也可能是一条包含工具调用、分支判断和返回结果的完整工作流。过去，这类能力的描述往往依赖工程直觉：开发者知道什么情况下该调用哪个技能，但很难把这种“判断”转化为可以度量、比较和优化的工程指标。
部分可观测马尔可夫决策过程（POMDP）为这一问题提供了严格的数学语言。POMDP是马尔可夫决策过程（MDP）在“状态不可完全观测”条件下的扩展。在MDP中，智能体假设自己能够完整看到当前环境状态，并据此选择最优动作；而POMDP承认智能体只能获得观测，观测与真实状态之间存在不确定性，因此智能体需要维护一个“信念状态”——即对当前所处状态的概率分布。
将Agent Skill系统放入POMDP框架后，它不再只是一个工程实践概念，而被形式化为一个受限的、在部分可观测世界中执行信息搜寻的控制器。这个控制器在每个决策步都要回答三个问题，并从中选择其一：
这三个问题之所以需要在同一个形式框架中处理，是因为智能体面对的并非一个固定不变的决策环境。用户意图可能隐晦未知，任务执行到哪一步可能无法直接观测，技能所依赖的上下文可能尚未加载。智能体每一次选择，都在任务推进效率与信息获取成本之间进行权衡。
从这一视角出发，研究者将每一个技能抽象为一个三元组：
这个三元组定义的意义在于：它将Agent Skill从“一段提示词”或“一个函数调用”提升为可以在POMDP中显式建模的控制组件。技能不再是游离于状态空间之外的外部工具，而是智能体决策过程中的内在要素。
在云端大模型API的常见用法中，Agent Skill机制已经表现出很强的实用价值。开发者可以为智能体注册若干技能，每个技能附带说明、参数模式和执行逻辑，智能体根据用户输入和当前上下文动态选择并调用。这种模式在原型开发、产品探索和通用任务处理中效率很高。
但工业场景的约束完全不同。金融风控、政务数据、医疗记录、军工数据隔离等场景通常要求数据不能离开受控环境。持续调用公共云端API在合规审查中几乎必然被否决——不仅因为数据传输本身可能越界，也因为外部服务在审计链路中不可解释、不可控制。与此同时，完全本地化部署又面临另一个问题：如果本地模型能力不足，原本依赖强模型“直觉式”技能调度还能工作的框架，可能在弱模型上出现明显的性能塌缩。
形式化定义的价值在这里凸显出来。“黑盒的直觉”无法告诉我们：模型在什么情况下选择技能是合理的，什么情况下是冒险的；输入上下文如何变化会影响技能选择的置信度；技能内部引用展开到什么程度，收益开始低于信息获取成本。这些问题都迫切需要一种可量化语言来回答。
POMDP框架提供了这种语言。一旦状态空间、观测空间、动作空间和信念状态被明确定义，评估就不再只依赖最终任务的成败，而可以拆解到每一个决策步：技能选择是否最优、信息揭示动作是否必要、执行动作是否在正确的信念状态下做出。工程团队可以因此获得更细粒度的诊断信号，而不是面对一个整体失败却无从定位原因的智能体。
对于开源模型的全谱系适配，这一形式化同样重要。开源模型的参数规模从数亿到数百亿不等，能力差异显著。一个技能描述在强模型上可能被正确理解并激活，在弱模型上则可能被忽略或误解。将技能系统放入POMDP框架后，研究者可以在统一的数学标准下测试不同规模模型的行为差异，从而更客观地判断：本地部署的硬件门槛究竟高在何处，哪些环节可以通过工程手段弥补模型能力的不足。
要完整理解这一形式化方法，需要拆解POMDP的各组成部分，以及它们如何映射到Agent Skill系统。
状态空间S：在Agent Skill场景中，状态表示可能被隐藏的任务情境。它至少包含三类信息：用户意图，即用户真正想完成什么；任务阶段与进度，即当前已经完成到什么程度、下一步应当是什么；未检索到的环境事实，即对当前任务有影响但智能体尚未获取的上下文。这些状态并非全部可以直接观测。用户可能只给出一句模糊指令，任务进度可能依赖历史执行轨迹，环境事实可能散落在未被加载的文档或数据库中。
观测空间O：智能体在时间步t可以访问的内容构成观测。这包括当前用户消息、可用的历史记录，以及任何已经揭示或加载的资源和技能内容。观测的边界受限于上下文窗口大小、已执行的检索动作和此前已展开的技能信息。观测不是状态本身，而是状态的一个不完整投影。
动作空间A：动作被分为四类。技能选择动作决定激活哪一项技能；付费上下文获取动作需要额外消耗时间或计算资源，以换取更好的观测质量，例如展开技能引用、读取附加文档、触发二次检索；技能执行动作是真正将技能内部策略展开为环境效应或工具调用的动作；环境与工具调用动作则是直接作用于外部系统，如写入数据库、调用计算接口或发送请求。这四类动作的共同特点是：它们对状态和观测的影响不同，成本结构不同，因此在决策中需要分别建模。
信念状态b：这是POMDP区别于简单规则映射的核心。智能体在给定迄今为止的观测和过去动作的情况下，维护一个关于真实状态的概率分布。信念状态不是“智能体认为当前是什么状态”这样单一判断，而是一个完整的概率权重。它由初始信念出发，通过贝叶斯更新的方式，随着每次新的观测和动作逐步修正。技能选择是否合理，本质上取决于当前信念状态是否已经足够收敛；如果信念高度分散，那么“先获取信息”往往优于“直接执行技能”。
将上述元素组织起来，整个系统的运行可以概括为：智能体始终处于某个信念状态下，它可以选择花费成本去改善观测，也可以选择基于当前信念执行某个技能。技能本身又是一个具有内部时间结构的过程，技能执行过程中可能继续触发引用展开、工具调用和子任务切换。POMDP的存在，使得这些选择都处在同一个可优化、可评估的数学框架内。
在没有形式化的工程实践中，技能调度通常依赖提示词工程：系统把当前任务描述与技能清单一起交给模型，由模型输出一个“应该调用哪个技能”的判断。这个过程的问题在于，判断依据是不可见的。模型可能因为技能描述中的某个关键词而触发调用，也可能因为上下文顺序的微小变化而做出不同选择。
在POMDP框架下，技能选择被重新解释为在给定信念状态下的动作决策。智能体当前拥有的观测，形成了对真实任务状态的信念。技能文本描述符的作用，是让智能体能够在语义上将当前信念与可用技能进行匹配。这个匹配过程不是简单的字符串相似度，而是在概率层面回答：在信念状态b的条件下，执行技能k期望获得的回报是否高于执行其他动作。
一旦某个技能被选中，其内部策略开始沿时间展开。内部策略的每一步都可能产生新的观测，这些观测反过来更新信念状态。例如，一个数据分析技能可能先读取一份数据表，发现表结构与预期不符，此时信念状态发生显著变化，技能内部策略可能需要调整后续步骤，甚至触发提前终止或转交。技能因此不是一次性、不可中断的固态模块，而是一个在时间维度上参与信念更新的动态过程。
引用机制则使得技能具备了“按需加载”的能力。当智能体对某个技能的适用性不确定时，不立即执行，而是先展开该技能的引用——这可能带来更详细的说明、前置条件、参数格式或相关技能指针。这一过程在POMDP中对应付费上下文获取动作，其成本是额外的推理时间、上下文占用和潜在的信息过载。正确的做法是，只有在预期信息收益超过成本时才进行引用展开。形式化模型的优势在于，它把“要不要看更多说明”这样一个原本被淹没在模型内部激活模式中的隐性决策，外化为一个可以观测、可以记录、可以优化的系统行为。
这一形式化方法最典型的应用场景，是那些数据不能离开受控环境、同时又需要智能体具备多步骤任务处理能力的业务系统。
在金融风控场景中，原始交易数据、客户信息和内部规则文档往往都处于严格隔离环境。智能体需要在本地推理环境中完成信息检索、规则匹配、风险判断和报告生成。使用POMDP建模后，工程团队可以区分“模型对当前风控规则理解不足”和“技能内部执行逻辑有误”两类问题。前者可以通过改进技能文本描述或调整信息揭示策略来缓解，后者则需要修改技能内部策略本身。
在数据治理场景中，技能常被用于元数据解析、质量检查和异常修复。这类任务的复杂之处在于：数据湖中的表结构、字段含义和上下游依赖关系不是一次性可见的。智能体必须先花费动作去查询目录或读取表定义，再决定执行哪个数据修复技能。POMDP模型能够明确刻画“信息获取”与“任务执行”之间的先后依赖，避免智能体在信息不足时贸然修改数据。
另一个重要场景是本地化模型的选型与能力评估。当企业考虑用开源模型替代云端大模型时，一个关键问题是：多大规模的本地模型能够在给定技能系统下保持可接受的调度准确率与执行成功率。POMDP框架允许研究者在标准动作空间和统一信念更新规则下，系统性比较不同模型的决策质量，而不是笼统地比较模型的对话能力。这类评估对降低本地AI部署的硬件门槛具有直接指导意义。
有几个概念容易与本文讨论的方法混淆，需要加以区分。
技能与工具（Tool）：工具通常指单一功能的接口，执行一个明确动作并返回结果，如调用计算器、查询天气。技能则由文本描述符、内部策略和引用机制共同构成，它可以在时间上延伸，内部包含多步流程和条件分支，甚至能触发其他技能。工具更接近“动作”，技能更接近“选项级过程”。
技能与工作流（Workflow）：工作流是预设的步骤序列，通常在执行前已经确定。技能的内部策略虽然也是步骤序列，但每一步都可能依据新的观测和信念更新进行调整。从POMDP角度看，工作流更接近开放环策略，而技能内部策略是闭环策略。
POMDP建模与提示词工程：提示词工程通过文本指令影响模型行为，属于经验性、启发式的手段。POMDP形式化则用状态空间、动作空间、观测函数和信念更新规则来描述系统，追求可复现、可验证的工程指标。前者可以作为后者在工程落地时的一种实现手段，但二者的分析层次和严谨程度不同。
另外，本文所讨论的形式化定义与一般意义上的MDP任务规划也不同。普通MDP任务规划假设环境状态完全可观测，因此规划器可以直接根据当前状态选择动作。而在Agent Skill的真实使用中，智能体常常不知道用户完整意图，也不清楚技能引用的具体内容，这正是必须使用POMDP而非MDP的原因。
引入POMDP形式化并非没有代价。在实际项目中，需要注意以下问题。
首先是建模成本。完整定义状态空间、观测空间、动作空间和转移概率是一项繁重工作。实际任务的状态往往高度复杂，难以用有限的离散变量穷尽。因此，工程实现中通常采用近似方法，例如将信念状态表示为生成模型产生的向量嵌入，而非完整概率分布。这会导致POMDP的理论最优性无法严格保证，但可以通过限制问题规模和引入启发式约束来获得可用解。
其次是样本效率。POMDP的求解通常比MDP更困难，因为信念空间是连续高维空间。在数据稀缺的本地化场景中，依靠大量轨迹采样来学习策略可能不现实。更可行的方式是以规则或历史数据初始化策略，再用在线交互逐步优化。
三是模型能力与形式化框架的匹配度。POMDP框架并不改变底层模型的理解和推理能力，它只是提供了一个更清晰的问题结构。如果本地模型连技能描述的基本语义都难以准确解析，那么再严格的数学建模也无法拯救调度质量。因此，形式化定义应与技能描述的简洁性、规范性相结合，尽量降低对模型语义解析能力的过度依赖。
最后是观测成本的真实性。在理论模型中，信息获取动作的成本是抽象数值；在真实系统中，一次引用展开可能意味着额外几百个token、几百毫秒延迟或一次外部检索。团队需要根据实际基础设施情况校准成本参数，避免模型在理论与现实之间产生系统性偏差。
基于POMDP对Agent Skill进行形式化定义，本质上是在回答一个工程问题：当智能体面对不完全可观测的任务环境时，它应该如何在信息获取、技能执行和直接环境操作之间进行权衡。通过将技能拆解为文本描述符、内部策略和引用机制三元组，并将它们纳入状态、观测、动作与信念状态构成的数学框架，原本依赖强模型直觉的调度行为变得可描述、可度量、可优化。
这一方法对工业界最直接的意义，在于它为本地化、受控环境中的智能体系统提供了一套不依赖特定云端服务的分析语言。它使得工程团队能够更精确地定位模型能力短板，更客观地比较不同规模开源模型的表现，从而更理性地规划本地AI部署的硬件与模型组合。形式化不是目的，但它让Agent Skill从经验性的工程技巧，向可验证的工程学科迈出了重要一步。