金融控股企业引入 AI 时，真正的核心资产不是模型、不是算力、不是界面——而是 Skills：那些封装了财务分析口径、风险监控阈值、合规审查流程、跨系统数据调度的"业务方法论软件包"。
既然是核心资产，就必须自主可控——格式不能被厂商锁定、运行时不能依赖外部 SaaS、数据不能离开集团网络、演进不能等待厂商排期。这不是技术偏好，是资产安全逻辑的必然推论。
本文以此为线索，论证为什么在一个以 Skills 为中心的企业 AI 架构中，Agent Runtime 的选择标准必是"谁的设计更能保障资产主权"——并以两个 Skills 原型作为验证。
1. 金融控股企业的 AI 困局：数据在，决策不在
金融控股企业是数据密度最高的企业形态之一，横跨银行、证券、保险、信托、租赁多个业态，每个业态都有独立的报表体系、风险指标和监管要求，概括起来有两类宝贵的底层资产。
指标库（结构化）。财务指标（LCR、CAR、NPL、ROE/ROA）、风险指标（集中度风险、市场风险 VaR、信用风险敞口）、经营指标（子公司 KPI、营收利润、净息差）、监管指标（拨备覆盖率、杠杆率）——这些数字分散在数据仓库和 BI 看板中。
知识库（非结构化）。外部监管制度、内部管理制度（风险管理办法、授权管理细则、业务操作规程）、合规清单（反洗钱规定、关联交易限额、信息披露要求）——这些文档以 PDF 和 DOCX 形式散落在 OA 系统、合规系统和档案库中。
但一个现实是：数据在那里，却不在决策发生的地方。这不是数据不够的问题，是数据没有被组织为"可行动的洞察"的问题。
2. Skills 是王冠上的明珠
引入 AI 解决上述问题时，注意力很容易被"选哪个模型"和"用什么界面"吸走。这恰好搞反了优先级。
模型的商品化趋势已经明朗。DeepSeek、GLM、Qwen——基础模型的能力在快速趋同，切换成本在持续降低。模型是消耗品，不是资产。
界面是基础设施，不是护城河。WebUI、CLI、IDE 插件——任何一个团队都能在几天内搭建出来。界面是管道，不是竞争优势。
Skills 才是真正的核心资产。一个金融控股企业的"资本管理分析 Skill"，其内部包含了：
- 财务口径：资本充足率的分子分母具体怎么取数（商誉是否扣减？无形资产是否全扣？）
- 风险阈值：关联交易集中度超过 15% 算什么级别的事件？谁有权审批？
- 制度引用：涉及《金控办法》第几条、《关联交易管理办法》哪一版？
- 分析流程：先查什么、再算什么、最后跟什么做交叉比对？
- 输出规范：结论怎么写、预警级别怎么标、建议动作怎么列？
这就是方法论的代码化。 它不会因为换了一个 LLM 而失效，不会因为 UI 改版而丢失。它是组织特有的、积累性的智力资产。别人可以买到同样的模型，但拿不到这些 Skills——因为他们既没有你的数据源，也不理解你的业务逻辑。
模型 + UI = 谁都能做的 AI 工具
模型 + UI + Skills + 数据源 = 只有你能做的 AI 能力
3. 核心资产的必然推论：自主可控
如果 Skills 是核心资产，它就必然适用资产管理的基本原则。
资产安全的四个维度
|
|
|
|
|---|---|---|
| 格式自主 |
|
|
| 运行时自主 |
|
|
| 数据自主 |
|
|
| 演进自主 |
|
|
这四个维度不是"技术偏好"——它们是一个持有金融牌照的企业在监管合规、业务连续性、信息安全等方面的硬约束。
你的 Skills 还能用吗？
如果你的核心业务分析逻辑完全依赖一个你无法控制底层代码、无法导出 Skill 定义、无法独立部署运行时的平台——那你的 Skills 只是"托管在别人服务器上的借来的能力"，不是你的资产。
资产的定义不是你"正在使用"它，而是你"可以独立处置"它。
4. Agent Runtime 的选择标准：从生态规模到资产主权
这个逻辑链条推导出一个反直觉的结论：
选 agent runtime 时，"谁的生态最大、功能最多"不是首要标准。"谁的设计最能保障你的 Skills 资产主权"才是。
这意味着几个硬性条件。
Skill 存储格式必须开放、可迁移——不能是专有格式，框架停服不等于资产归零。
运行时必须可自部署——核心业务分析不能依赖第三方 SaaS 的可用性。
数据源连接必须基于开放协议——MCP 而非私有接口，连接层不因更换 runtime 而作废。
许可证必须允许不受限的自主使用和 fork——在极端情况下（项目被收购后闭源、上游战略转向），你可以继续在内部维护和使用。
这四个条件对应第 3 节提出的四个自主维度——格式自主、运行时自主、数据自主、演进自主——它们共同划定了 agent runtime 选型的底线。
nanobot 的设计在这些维度上与资产主权逻辑一致。SKILL纯文本格式确保即使框架停止维护，Skills 仍然是完整可读的资产。Workspace 覆盖机制让定制和上游更新互不干扰——这是"自主可控"在架构层面的精确表达：你控制你的定制，不依赖上游的许可。MCP 开放协议独立于框架本身，数据连接层不会因为更换 runtime 而重做。Apache 2.0 许可证在极端情况下允许 fork 后继续内部使用。
需要承认的局限
结构性优势不意味着完美。SKILL标准格式虽然开放，迁移仍需适配层；方法论内容可以直接复用，触发机制需要重新实现，工作量不大但非零。MCP 工具的前缀约定是 nanobot 的实现细节，换框架时可能需调整。社区生态规模小，如果首要目标是"开箱即用的集成数量"，nanobot 还有差距。但如果首要目标是"不被锁定、资产自主、可以独立演进"，它的设计哲学与这个目标高度一致。
5. 完整架构：数据不动，能力流动
数据不搬运——指标通过 MCP 实时查询，Agent 拿到的是当前结果，不缓存；制度文档索引化后保留原文引用，每条结论可追溯到出处。
Skills 是独立资产——每个 SKILL是独立文件包，可用 Git 版本管理，不依赖任何专有数据库。
安全边界内建——Workspace Scope 限制文件访问范围，MCP 连接器内置 SSRF 白名单，工具调用全程可审计。
6. 原型验证：两个 Skills 的可行性演示
基于金控控股业务逻辑构建了两个 Skills 的原型，验证了"Skills 即资产"的技术可行性。
6.1 subsidiary-capital-efficiency：把管理判断编译为可执行规则
这是一个分析子公司资本效率的 Skill。核心方法论是双维度交叉诊断法——用 ROE（赚钱能力）和 RORWA（赚钱的资本代价）两个正交指标构建 2×2 矩阵，将子公司落入四个诊断象限：
RORWA ≥ 1% RORWA < 1%
ROE ≥ 6% → 高效（维持配置） → 重资本依赖（推动轻资本转型）
ROE < 6% → 轻型虚高（扩大规模） → 低效占资本（纳入压降清单）它的价值不在于"会算 ROE"——Excel 也能算。它的价值在于把一个风控总监脑子里的诊断逻辑，编译为确定性的、可复用的代码。
具体架构是一条五阶段管线——Extractor（加载数据）→ Calculator（计算指标）→ Diagnoser（矩阵匹配）→ Ranker（三维排名）→ Reporter（生成报告）——每一阶段都是确定性计算，不使用 LLM 做数学或规则判断。LLM 只负责理解用户意图和包装最终输出。阈值配置独立于代码，存储在 data/thresholds.yaml 中：业务人员修改阈值不需要懂 Python，改一个 YAML 值，分析口径即刻生效。
6.2 financial-metric-skill-blueprint：制造技能的技能
如果 subsidiary-capital-efficiency 是一个产品，那 financial-metric-skill-blueprint 就是制造这个产品的模具。这是一个元技能，定义了从零构建金融指标分析 Skill 的标准化流程：
定方法论 → 定字段 → 搭骨架 → 写 SKILL → 验证 → 交付每步有明确的输入、产出和质检关。第 3 步（搭骨架）的 TODO 检查确保无残留占位符；第 5 步（验证）三条命令全部 exit_code=0 才算通过。
它解决了"第一个 Skill 最难写"的问题。构建新 Skill 的人不需要从空白文件开始，只需做四件事：选方法论、填字段名、定义计算公式、写诊断规则。数据加载、排名生成、报告渲染、CLI 入口——骨架已经写好了。
6.3 两个 Skill 的关系
Blueprint → Subsidiary 的关系说明，Skills 可以形成"制造体系"而非"手工作坊"——元技能定义模板，实例技能填充逻辑。当第 10 个金融分析 Skill 被创建，它复用的是同一套骨架、同一套管线、同一套验证标准。
7. 从采购"AI 助手"，到积累"组织资产"
两个 Skills 原型指向的不是效率提升，而是一种范式转换：
传统模式：采购 AI 产品 → 使用功能 → 产生结果 → 能力沉淀在工具里 → 换工具则能力归零
Skills 模式：编写 Skill → 连接数据 → 运行分析 → 能力沉淀在 Skill 文件中 → 换 runtime 则 Skill 迁移
在传统模式下，你购买的是"能力的使用权"。在 Skills 模式下，你积累的是"能力的定义权"。
当企业的第 10 个、第 50 个、第 100 个 Skill 被创建出来，它们共同构成了一种新型的组织资产——不是代码、不是文档、不是流程手册，而是三者的融合体：可执行的业务智慧。
8. 结语
企业的 AI 建设如果止步于"采购大模型调用权限"或"部署通用 AI 聊天助手"，那只是把别人的能力搬到了自己的机房里。并没有产生任何独属于你的资产。
它不是"又一个人工智能功能"。它是业务方法论的形式化表达，是连接你的数据和你的决策之间的管道，是——如果你做得足够好——组织智慧最持久的容器。
Skills 是方法论的代码化。模型会换代，界面会过时，工具会退场。
但你的业务逻辑——你定义的口径、你设定的阈值、你积累的分析模式——
只要以开放格式保存，它就永远是你的。
nanobot 是一个开源的 AI Agent 框架（Apache 2.0），github.com/nanobot-ai/nanobot