写在前面

目前已步入一个“万物皆可AI”的时代，公司做个啥项目，就要与AI结合，用AI分析一下，比如，要实现对不同维度的数据，进行分析，给出对应建议。之前的实现思路是，为每个业务场景重写一个专用Agent（Prompt驱动），分析场景较少时，这种方式省时省力，但当要分析的场景日益增加时，就会发现代码中变得日益“凌乱”，因为我们需要将业务数据，组织成大模型便于分析的模式，每一个分析，都会涉及一次业务对象与AI数据的耦合。Skills的应用，完美解决这一天痛点，打造一个通用的Agent，然后、、把专业知识、流程、规范打包成可插拔、可复用的“技能包”（Skills），当有新的分析场景时，我们只需要在“技能包”中配置一个新的skill接口，实现对对修改封闭，而对扩展开放【开闭原则】。

“开闭原则（Open/Closed Principle, OCP）是软件设计的核心原则，主张软件实体（类、模块、函数）应对扩展开放（方便增加新功能），对修改封闭（不修改现有代码）。其核心在于通过接口、抽象类等抽象化手段隔离变化，利用多态和策略模式实现新功能，提升代码的可维护性、可扩展性和复用性。”

一、Prompt 驱动的 Agent：传统模式及其局限

1.1 什么是 Prompt 驱动？

传统做法是将所有内容塞进 system prompt：

角色定义、语气风格、格式约束
业务流程说明
大量示例

1.2 Prompt使用及局限分析

图中是项目的一个代码片段，原本独立的AI项目中，会充斥着大量的业务对象的定义以及提示词的定义。总结而言，其有一下局限性：

问题	说明
Token 浪费	所有内容始终占用上下文
难以模块化	无法拆分成可重用、可测试的模块，难以挂接脚本和数据
协作困难	不适合多人协作和版本演进，容易变成「黑盒」
复用成本高	复制规则需要整段复制，修改成本极高

二、Skills 驱动的 Agent：新范式的核心优势

2.1 核心理念

知识按需加载、可执行、可组合

Agent 不再一次性吃下所有业务知识，而是：

识别可以用哪些 Skill
在真正需要时读取对应 Skill 的 SKILL.md、脚本和文档

2.2 Skills使用及优势

项目是使用Spring AI Alibaba，实现Agent与skills的配置。代码实现思路，会在专门的文章中详解。

    @Bean
    public SkillRegistry skillRegistry() {
        return ClasspathSkillRegistry.builder()
                .classpathPath("skills")
                .autoLoad(true)
                .build();
    }

    /**
     * 创建 SkillsAgentHook，将 skills 注入 Agent
     */
    @Bean
    public SkillsAgentHook skillsAgentHook(SkillRegistry skillRegistry) {
        return SkillsAgentHook.builder()
                .skillRegistry(skillRegistry)
                .build();
    }

    /**
     * 构建 ReactAgent，加载 skills 进行智能分析
     */
    @Bean
    public ReactAgent reactAgent(ChatModel chatModel, SkillsAgentHook skillsAgentHook) {
        return ReactAgent.builder()
                .name("agent")
                .model(chatModel)
                .systemPrompt("""
                        系统提示词""")
                .hooks(List.of(skillsAgentHook))
                .build();
    }

项目中使用的skills：

由此可见，后续需要分析其他数据，只需要增加一个新的skill，而不需对代码做任何修改。

http://43.143.217.213/upload/image-ukDH.png---
name: 门店数据MCP工具分析
description: 当用户需要分析指定门店的经营数据时，使用本技能通过 MCP Tool (get_store_data) 获取数据并进行财务分析
---

# 门店数据 MCP 工具分析技能

## 技能名称
门店数据MCP工具分析

## 适用场景
当用户只提供门店ID需要分析门店经营数据时，使用本技能。本技能演示 MCP Tool 的使用方式。

## MCP Tool
本技能使用 `get_store_data` MCP Tool 获取门店经营数据：
- **Tool 名称**: `get_store_data`
- **参数类型**: Long（门店ID）
- **返回**: 门店经营数据 JSON

## 执行步骤
1. 从输入中获取门店ID数值（输入会是上一个 agent 提取的纯数字）
2. 调用 get_store_data，参数格式：{"storeInfoId": 数字}
3. 分析返回数据，输出不超过100字结论

## 输入要求
输入的内容：门店ID（数值），例如：1、2、100

## 输出格式
分析总结不超过100字，包含：
- 回款总额、确认收入概况
- 收入/回款比分析
- 经营建议

维度	Skills 模式的优势
渐进式披露	知识按层级、按时机进入上下文，而非一股脑塞入
与代码深度融合	脚本运行时执行，只有输出进入上下文，本身不占 token
可组合性	多个 Skills 可协同工作，如「数据分析 + 报表格式化 + 合规审查」

三、从 0 到 1 构建 Skills 体系

第一步：整理现有知识为 Skills

目标：完成知识结构化迁移

操作：

挑选一个稳定的业务场景（如「生成月度经营分析报告」）
将现有 prompt、模板、规范文档集中到一个文件夹
编写最小化 skill.yaml（名称、描述、触发关键词）
撰写简洁的 SKILL.md（输入、输出、步骤、依赖文件路径）

第二步：用脚本替代自然语言流程

目标：降低对模型执行复杂流程的依赖，提升稳定性

适合脚本化的场景：

从 API 拉取数据
固定格式转换
调用内部工具生成可视化

做法：

用 Python/Shell 编写脚本，放入 scripts/ 目录
在 SKILL.md 中用简短指令告知「调用哪个脚本」「输入输出路径」

第三步：接入工具协议（如 MCP）

目标：统一封装系统交互，实现解耦

封装范围：

CRM / ERP / 财务系统
云存储、文档协作平台
内部数据服务或机器学习服务

收益：Skill 脚本仅依赖统一接口，更换系统时只改 MCP 层，不改 Skill

第四步：扩展为 Skill Library

前提：已成功迁移 3–5 个高价值场景

平台化工作：

统一命名规范和目录规范
为常用模式抽象模板 Skill（报表生成、数据分析、审批流等）
设计 Skill 发现与安装机制，支持跨团队共享

四、总结：范式转变的核心洞察

停止为每个领域重造 Agent，开始为通用 Agent 构建可组合的 Skills。

值得思考的问题不再是「怎样写一个更聪明的 Agent」，而是：

「如何把我所在领域的经验和流程，打包成高质量的 Skills，让任何 Agent 都能用？」

这也许是下一代「软件开发 + 知识管理」的交汇点。

菜单

分享

Agent 构建的范式转变：从 Prompt 驱动到 Skills 驱动