在上一篇文章中，我们讨论了技能资产化的核心命题：将承载企业业务工艺的技能，从"可复制的文件"升级为"可管控的资产"。这个结论回答了"为什么"，但更棘手的问题是"怎么做"。
从产品设计的视角看，技能资产化不是一个单纯的工程问题——它涉及分发模式、权限体系、数据边界、性能架构、知识治理和安全模型六个维度的交叉设计。每一个维度都牵一发动全身，需要通盘考虑。
一、不分发，如何执行？
技能资产化的起点是一个看似矛盾的诉求：技能定义文件不应该离开服务端，但用户必须能够执行它。
在"文件分发"模式下，技能就是一个 Markdown 文件，用户下载后交给本地 Agent 执行。这种模式的便利性毋庸置疑，但它让技能的核心逻辑完全暴露在客户端，工艺保护无从谈起。
技能资产化的解法是将执行逻辑从客户端迁移到服务端。具体来说：技能定义文件存储在服务端，Agent 通过 MCP 协议调用技能服务——服务端读取技能定义、编排工具调用、执行推理流程，最终将执行结果返回客户端，而技能定义本身始终不离开服务端。
这里的关键设计在于 MCP 协议的标准化抽象。技能服务对外暴露的不是"技能文件"，而是一组标准化的工具接口（Tool List + Tool Call）。客户端 Agent 看到的是一系列可用工具，它不需要知道这些工具背后是本地脚本还是远程服务。对用户而言，体验不变——在对话中激活技能，获得结果。但对企业而言，核心工艺已经被保护在服务端容器内。
这种架构解决了"不分发也能用"的问题，但随之而来的是一个新的设计问题：谁能用哪些技能？
二、技能授权：从"文件拷贝"到"能力授予"
在文件分发模式下，技能的"授权"本质上是文件访问权限——谁能拿到这个 Markdown 文件，谁就能使用这个技能。这种授权粒度太粗，无法满足企业场景的需求。
技能资产化需要一套更精细的授权体系，至少包含三个层级：
第一层：技能准入。 哪些用户或团队可以调用某个技能？这需要技能级别的访问控制列表（ACL），支持按组织、团队、角色进行授权。
第二层：能力范围。 同一个技能在不同授权等级下，能力范围可以不同。例如，BA Master 技能包含需求规格说明书、业务流程建模、合规审查等多项子能力，企业可以只授权初级 BA 使用"需求规格说明书"，而将"合规审查"保留给高级 BA。
第三层：调用配额。 技能的执行消耗计算资源，需要配额控制——按用户、按时间周期限制调用次数，防止资源滥用。
这三个层级叠加在一起，构成了从"谁能用"到"能用多少"的完整授权链路。但授权只是解决了"人"的问题，下一个难题是"数据"。
三、数据授权与脱敏：同一技能，不同视野
企业场景中，同一个需求分析技能在 A 项目和 B 项目中面对的数据应该完全不同。这要求技能在服务端执行时，数据访问范围必须跟随用户身份动态变化。
这里的设计要点是两个维度：
维度一：数据空间隔离。 每个技能实例绑定一个数据空间（Data Space），该空间定义了技能可以访问的数据源范围。用户调用技能时，系统根据用户的组织归属和项目归属，自动路由到对应的数据空间。A 项目的 BA 调用需求分析技能，只能看到 A 项目的需求文档、业务规则和历史记录；B 项目的信息对他完全不可见。
维度二：数据脱敏策略。 即使在同一数据空间内，不同角色的用户看到的数据粒度也应不同。例如，财务报表中的金额字段，财务人员可见精确值，项目经理可见区间范围，外部顾问仅可见"已填报/未填报"状态。这要求技能在输出结果前，根据调用者的角色执行字段级脱敏。
将这两层结合起来，技能资产化的数据授权模型可以概括为：同一技能 + 不同用户 = 不同数据视野。 技能逻辑是统一的，但输入数据的范围和输出内容的粒度随用户身份动态裁剪。
四、服务化后的性能挑战
技能从客户端执行迁移到服务端容器执行后，性能模型发生了根本变化。本地执行没有网络延迟，没有资源争抢；服务端执行则引入了冷启动、并发竞争和资源隔离等一系列新问题。
从产品设计角度，以下三个性能问题最为关键：
冷启动延迟。 容器化的技能服务在无流量时可能会被缩容到零。当用户首次调用时，容器启动、技能定义加载、知识库预热都需要时间。对交互式场景（用户在对话框等待回复），冷启动超过 3-5 秒就会显著影响体验。解决方案包括预留最小实例、预热机制，以及在前端通过流式响应（SSE）让用户感知到"正在准备"而非"卡住了"。
并发隔离。 当多个用户同时调用同一个技能时，容器内部的多任务执行需要严格的资源隔离。一个用户的大规模需求分析不应拖慢另一个用户的简单查询。容器编排层面的资源配额（CPU/Memory Limit）+ 执行队列层面的优先级调度，是解决这个问题的两条主线。
知识库检索性能。 许多技能依赖领域知识库（如企业业务规则、行业合规标准）。当知识库规模增长到数万条记录时，向量检索的延迟和召回率成为瓶颈。产品上需要考虑混合检索策略（关键词 + 向量）、分层索引（热数据内存缓存、冷数据磁盘检索），以及知识库的精简与淘汰机制。
说到精简与淘汰，这引出了下一个设计要点：知识本身的生命周期管理。
五、知识的存储、精炼与淘汰
技能依赖的知识库不是静态的。业务规则会变更，行业标准会更新，历史知识会过时。如果知识库只增不减，技能的执行质量会随着时间推移逐步劣化——这被称为"知识熵增"。
产品设计上需要建立知识的生命周期管理机制：
存储层需要支持版本化——每次知识更新生成新版本，旧版本保留但标记为"已过期"。技能执行时默认使用最新版本，但允许用户在特定场景下回溯历史版本（例如审计场景需要还原"当时的规则"）。
精炼层需要建立反馈闭环。技能每次执行后的结果，由使用者进行质量评价（采纳/修改后采纳/未采纳）。修改后采纳的结果，可以提取出"实际使用的知识"与"技能输出的知识"之间的差异，作为知识精炼的输入。这个闭环让知识库在使用中持续优化，而非依赖人工定期维护。
淘汰层需要设置知识条目的"活性阈值"。连续 N 次技能执行都未引用的知识条目，自动标记为"待淘汰"，经人工确认后归档或删除。这解决了"不敢删"的问题——没有淘汰机制的知识库最终会变成没人敢碰的"垃圾场"。
六、模型端的安全边界
技能在服务端执行，意味着用户输入的上下文和技能的知识内容都会发送给 LLM。这里存在两个安全风险：
提示注入风险。 用户可能在输入中嵌入恶意指令，试图覆盖技能的系统提示。在文件分发模式下，这种风险由客户端 Agent 承担；在服务端模式下，风险转移到了技能服务平台。产品设计上需要输入清洗（过滤已知注入模式）、提示结构强化（系统提示优先级高于用户输入），以及输出审查（检测异常输出模式）。
跨租户数据泄露。 如果 LLM 提供商在多租户之间共享模型实例（大多数商业 LLM 服务如此），A 企业通过技能发送给 LLM 的数据，理论上可能影响 B 企业调用时的模型状态。尽管主流 LLM 服务商声称请求间隔离，但在高度合规的场景（金融、医疗）中，这仍然是一个需要评估的风险点。对于极端敏感的场景，可能需要支持私有化部署的 LLM 实例。
七、实践落脚点
上述六个设计要点——不分发执行、技能授权、数据授权与脱敏、服务化性能、知识生命周期、模型端安全——构成了技能资产化产品设计的核心框架。它们不是孤立的设计决策，而是一个互相咬合的系统：授权体系决定了谁能调用技能，数据空间决定了调用时能看到什么，性能架构决定了调用体验，知识治理决定了技能的长期可用性。
目前，这些设计思路正在 Agent Skill Warehouse 项目中逐步落地验证。BA Master 技能已经实现了服务端容器化部署、MCP 协议标准化分发、多租户数据空间隔离等关键能力。
当然，距离完整的"技能资产管理平台"，还有一段路要走。授权粒度的细化、知识精炼闭环的自动化、性能模型的持续优化——这些问题还将继续研究和实践。
