从构建Agent转向发展Skills

引言：AI Agent 的热潮与隐忧​

2023 年以来，AI Agent（人工智能智能体）成为技术圈最炙手可热的概念。从 AutoGPT 的 “自主完成任务”，到 ChatGPT Plugins 的 “连接现实世界”，再到各类垂直领域 Agent（如办公 Agent、编程 Agent、客服 Agent），仿佛一夜之间，“造一个全能 Agent” 成了所有 AI 团队的终极目标。​

打开 GitHub，搜索 “AI Agent”，能找到上万个仓库；翻阅技术论坛，“如何构建自己的 Agent”“Agent 架构设计指南” 的帖子层出不穷。但热闹背后，一个残酷的现实正在浮现：​

• 90% 的 Agent 项目都在重复造轮子 —— 几乎每个 Agent 都要实现 “任务拆分、工具调用、结果反馈” 的基础逻辑；​

• 80% 的 Agent 无法落地 —— 要么功能冗余到用户用不上，要么适配性极差，换个场景就失效；​

• 70% 的开发精力浪费在 “非核心能力” 上 —— 为了让 Agent 能处理 Excel，团队要开发 Excel 解析模块；为了让 Agent 能生成图表，又要从头做数据可视化功能。​

我们陷入了一个 “为了造 Agent 而造 Agent” 的怪圈，却忽略了 AI 应用落地的核心逻辑：用户需要的不是 “一个全能 Agent”，而是 “能解决具体问题的模块化能力”。​

这篇文章将带你跳出 Agent 的迷思，厘清两个关键概念 ——“Agent” 与 “Agent Skills”，剖析当前造 Agent 模式的核心问题，并用实例证明：未来的 AI 生态，必然是 “Skills 为核心，Agent 为载体” 的模块化范式。

一、基础概念：先搞懂「Agent」与「Agent Skills」

在展开论述前，我们必须先明确两个核心定义 —— 很多争议的根源，其实是概念混淆。

1.1 什么是 AI Agent？​

AI Agent 的学术定义是：一个能够感知环境、自主决策、执行任务，并通过反馈持续优化的智能体。通俗来讲，一个完整的 Agent 需要具备三大核心能力：

举个例子：一个 “办公 Agent” 接到用户指令 “分析上周的销售数据，生成可视化报表并发送给团队”，它需要：​

• 感知：读取用户上传的 Excel 销售数据、理解 “上周”“可视化报表”“发送团队” 等关键信息；​

• 决策：拆解任务为 “解析 Excel→提取上周数据→生成图表→创建报表文档→调用邮件工具发送”；​

• 执行：依次完成每个子任务，最终输出结果。​

但这里有个关键误区：Agent 是 “能力的集合体”，而非 “能力本身”。就像一个厨师（Agent），会做菜（核心价值），但做菜的能力依赖于 “切菜”“炒菜”“调味” 等具体技能（Skills）—— 没有这些技能，厨师只是一个空壳。

1.2 什么是 Agent Skills？​

Agent Skills（智能体技能）的定义是：能够独立完成某一特定任务的模块化、可复用能力单元。它具备以下三个核心特征：​

特征 1：单一职责 —— 只解决一个具体问题​

一个 Skill 不应该是 “多功能的”，而应该是 “专精的”。比如：​

• 不是 “文档处理 Skill”，而是 “PDF 文本提取 Skill”“Word 格式转换 Skill”；​

• 不是 “数据处理 Skill”，而是 “Excel 数据筛选 Skill”“SQL 查询生成 Skill”；​

• 不是 “图表生成 Skill”，而是 “折线图生成 Skill”“热力图生成 Skill”。​

单一职责保证了 Skill 的通用性 —— 无论哪个 Agent，只要需要 “提取 PDF 文本”，都能直接使用这个 Skill，无需重复开发。​

特征 2：标准化接口 —— 可被任何 Agent 调用​

Skill 必须具备统一的输入输出格式，就像电器的 USB 接口一样，无论哪个品牌的设备（Agent），都能即插即用。一个标准化的 Skill 接口应该包含：​

• 输入参数：明确需要什么类型的输入（如文件路径、文本内容、数值范围、配置选项等）；​

• 输出结果：明确返回什么类型的结果（如字符串、JSON 数据、文件流、执行状态码等）；​

• 调用协议：明确如何触发 Skill（REST API、函数调用、消息队列等）。

示例：“PDF 文本提取 Skill” 的接口设计

// 输入 { "file_path": "/user/docs/report.pdf", // PDF文件路径（必填） "page_range": "1-10", // 提取页码范围（可选，默认全部） "output_format": "text" // 输出格式（text/json，可选，默认text） } // 输出 { "status": "success", // 执行状态（success/fail） "data": "PDF中的文本内容...", // 提取结果 "error_msg": "" // 错误信息（失败时填写） }

特征 3：可配置、可扩展 —— 适配不同场景​

Skill 不是固定死的，而是可以通过参数配置调整行为。比如 “折线图生成 Skill”，可以通过参数配置：​

• 横轴数据字段、纵轴数据字段；​

• 图表标题、坐标轴标签；​

• 颜色主题、线条样式；​

• 是否显示数据标签、是否支持交互。​

通过配置，同一个 Skill 可以满足不同 Agent、不同用户的个性化需求，而无需修改 Skill 的核心代码。

1.3 Agent 与 Skills 的关系：组装与被组装​

如果把 Agent 比作 “智能手机”，那么 Skills 就是 “手机 APP”—— 手机（Agent）提供了操作系统（运行环境）和交互入口（屏幕、按键），而 APP（Skills）提供了具体功能（聊天、购物、导航、办公）。​

两者的核心关系是：​

1. Agent = 运行环境 + 决策引擎 + Skills 集合；​

1. Skills 是 Agent 的核心价值来源 —— 没有 APP 的手机只是一块砖，没有 Skills 的 Agent 只是一个空的决策框架；​

1. 一个 Agent 可以集成多个 Skills，一个 Skill 可以被多个 Agent 复用。​

这个关系的本质，是 “模块化思想” 在 AI 领域的延伸 —— 就像工业生产中，我们不会为每个产品单独制造零件，而是生产标准化零件，再根据需求组装成不同产品。AI 领域的 “零件”，就是 Skills。

二、现状反思：当前 “造 Agent” 模式的三大核心问题​

为什么说 “停止造 Agent，开始造 Skills”？因为当前的 Agent 开发模式，存在三个无法回避的痛点，而这些痛点的根源，就是 “重 Agent、轻 Skills” 的思路。

2.1 痛点 1：重复造轮子 ——90% 的开发精力在做无用功​

现在的 Agent 开发，大多是 “从零开始”：团队要先搭建 Agent 的基础框架（感知、决策、执行），再为每个具体任务开发专属能力。比如：​

• 团队 A 开发 “财务 Agent”，需要实现 “Excel 解析、数据计算、报表生成” 能力；​

• 团队 B 开发 “运营 Agent”，同样需要 “Excel 解析、数据筛选、图表生成” 能力；​

• 团队 C 开发 “销售 Agent”，还是需要 “Excel 读取、数据统计、PPT 生成” 能力。​

这些团队都在独立开发 “Excel 处理”“报表生成” 等相似能力，代码逻辑大同小异，但因为没有标准化的 Skills，只能重复造轮子。​

根据 Gartner 的调研数据：2024 年 AI 领域的开发团队中，67% 的工程师表示 “至少一半的工作是在重复开发已有功能”；而在 Agent 相关项目中，这个比例高达 83%。​

更讽刺的是，这些重复开发的能力，往往质量参差不齐 —— 有的团队缺乏经验，开发的 “Excel 解析能力” 不支持复杂格式；有的团队为了赶进度，代码缺乏容错机制。最终，用户拿到的 Agent，核心功能反而不稳定。​

2.2 痛点 2：能力耦合 —— 修改一个功能，整个 Agent 瘫痪​

当前的 Agent 开发，大多是 “单体架构”：所有能力都写在一个项目里，相互依赖、紧密耦合。比如，一个 “办公 Agent” 的代码中，“Excel 解析”“Word 转换”“报表生成” 等功能的代码交织在一起，形成一个庞大的 “代码迷宫”。​

这种架构带来的问题是：​

• 维护成本极高：修改 “Excel 解析” 的一个小 bug，可能会影响 “报表生成” 功能；​

• 迭代速度极慢：要新增一个 “PDF 转 Excel” 功能，需要修改 Agent 的核心代码，还要进行全量测试；​

• 无法灵活扩展：如果用户需要 “处理 CSV 文件”，团队不能直接添加一个 CSV 处理模块，而是要重构整个数据处理流程。​

这本质上是 “把 Skills 和 Agent 绑定” 的错误 ——Skills 应该是独立的模块，Agent 只是 “调用者”，而不是 “包含者”。就像手机 APP 出了问题，我们只会卸载 APP，而不会换一部手机；但如果 APP 和手机系统深度绑定，出问题就只能换手机了。​

2.3 痛点 3：适配性差 —— 一个 Agent 只能服务一个场景​

当前的 Agent，大多是 “场景专属” 的：比如 “财务 Agent” 只能处理财务相关任务，“运营 Agent” 只能处理运营相关任务，“客服 Agent” 只能处理客服相关任务。​

为什么无法跨场景？因为 Agent 的能力是 “硬编码” 的 —— 它的决策逻辑、任务拆解方式、工具调用路径，都是为特定场景设计的。比如 “财务 Agent” 的决策逻辑是 “财务数据→计算分析→生成财务报表”，而 “运营 Agent” 的决策逻辑是 “运营数据→统计汇总→生成运营图表”，两者无法互通。​

但用户的需求是 “跨场景的”：比如一个用户可能需要 “用财务 Agent 的数据分析能力，处理运营数据，再用办公 Agent 的报表生成能力，创建可视化文档”。但在当前模式下，这是无法实现的 —— 因为财务 Agent 的 “数据分析能力” 和办公 Agent 的 “报表生成能力”，都是各自的专属功能，无法被对方调用。​

这种 “场景绑定” 的 Agent，本质上是 “封闭的能力孤岛”，无法形成生态效应。而 Skills 的出现，正是要打破这种孤岛 —— 让 “数据分析能力” 成为一个独立 Skill，任何 Agent（财务、运营、办公、销售）都能调用，从而实现能力的跨场景复用。

三、核心论点：为什么要从 “造 Agent” 转向 “造 Skills”？​

“造 Skills” 不是要否定 Agent，而是要重构 AI 应用的开发范式 —— 从 “为每个场景造专属 Agent”，转向 “造标准化 Skills，再根据场景组装 Agent”。这种范式转换，能解决当前的痛点，同时带来三大核心价值。​

3.1 价值 1：提升开发效率 —— 用标准化零件，快速组装产品​

就像工业生产中，标准化零件让 “批量生产” 成为可能，标准化 Skills 能让 AI 应用的开发效率提升 10 倍以上。​

举个例子：如果要开发一个 “电商运营 Agent”，传统模式需要做：​

1. 搭建 Agent 基础框架（感知、决策、执行）；​

1. 开发 “Excel 数据解析”“订单数据统计”“销售趋势分析”“图表生成”“PPT 制作”“邮件发送” 等 6 个核心能力；​

1. 集成这些能力，设计任务拆解逻辑；​

1. 测试、调试，修复各模块的耦合问题。​

整个过程需要一个团队开发 1-2 个月，而且代码只能用于这个 Agent。​

而 “造 Skills” 的模式下，开发流程是：​

1. 选择成熟的 Agent 基础框架（如 LangChain、AutoGPT、AgentGPT 等）；​

1. 从 Skills 市场中，直接调用现成的 “Excel 解析 Skill”“数据统计 Skill”“图表生成 Skill”“PPT 制作 Skill”“邮件发送 Skill”；​

1. 开发一个专属的 “电商数据拆解 Skill”（负责将 “分析电商运营数据” 拆分为具体子任务）；​

1. 将这些 Skills 集成到 Agent 框架中，配置调用逻辑。​

整个过程只需要 1-2 个工程师，1-2 周就能完成 —— 因为大部分核心能力都是现成的，团队只需要聚焦于场景专属的 “决策逻辑”。​

更重要的是，这些 Skills 可以重复使用 —— 如果后续要开发 “电商客服 Agent”“电商销售 Agent”，只需要复用已有的 “Excel 解析 Skill”“邮件发送 Skill” 等，无需重新开发。

3.2 价值 2：提升产品灵活性 —— 用户按需组合，适配所有场景

“造 Skills” 的模式，让 AI 应用从 “固定功能的产品”，变成 “可自定义的平台”。用户可以根据自己的需求，选择需要的 Skills，组装成专属 Agent—— 这就像 “搭积木”，不同的积木（Skills）能搭出不同的造型（Agent），满足无限场景的需求。

我们来看几个真实的用户场景：

场景 1：中小企业老板的 “全能办公助手”

一个开网店的中小企业老板，日常需要处理 “订单统计、财务核算、客户回复、营销文案、报表生成” 等任务。在传统模式下，他可能需要同时使用 “财务 Agent”“客服 Agent”“营销 Agent” 三个独立产品，数据无法互通，操作繁琐。

而在 “Skills 模式” 下，他可以：

1. 选择基础 Agent 框架（提供任务拆解和交互入口）；
2. 集成 “Excel 订单解析 Skill”“财务数据计算 Skill”“自动回复生成 Skill”“营销文案创作 Skill”“可视化报表生成 Skill”；
3. 配置任务逻辑：“每天上午 10 点，解析前一天的订单 Excel→统计销售额和利润→生成财务报表→自动回复未发货客户→生成当日营销文案发送到朋友圈”。

这样，他就拥有了一个 “专属办公 Agent”，所有功能都围绕自己的核心需求，没有冗余，操作统一，数据打通 —— 这是传统 “场景专属 Agent” 无法实现的灵活性。

场景 2：自媒体人的 “内容创作工具箱”

一个美食自媒体人，核心需求是 “生成食谱文案、处理美食图片、剪辑短视频、发布到多平台”。在 Skills 模式下，他的 Agent 可以是：

• 核心 Skills：“食谱文案生成 Skill”（根据食材生成详细做法）、“图片美化 Skill”（调整亮度、添加滤镜、加文字）、“短视频剪辑 Skill”（自动剪辑食材处理过程）、“多平台发布 Skill”（一键同步到抖音、小红书、视频号）；
• 配置逻辑：“上传食材图片→生成食谱文案→美化图片→剪辑短视频→自动填充文案并发布到指定平台”。

如果后续他想新增 “粉丝评论回复” 功能，只需添加一个 “评论自动回复 Skill”，无需重构整个 Agent—— 这种 “按需扩展” 的灵活性，正是用户真正需要的。

场景 3：程序员的 “开发辅助 Agent”

一个后端程序员，日常需要 “生成接口代码、调试 bug、生成 API 文档、查询技术资料”。他的 Agent 可以组合：

• “接口代码生成 Skill”（根据需求文档生成 Java/Go/Python 接口）；
• “bug 自动修复 Skill”（上传错误日志，生成修复方案）；
• “API 文档生成 Skill”（从代码中提取注释，生成 Swagger 文档）；
• “技术资料查询 Skill”（连接 Stack Overflow / 官方文档，获取解决方案）。

更重要的是，这些 Skills 可以跨场景复用：比如 “API 文档生成 Skill”，不仅程序员能用，产品经理、测试工程师也能用来生成文档；“技术资料查询 Skill”，学生、科研人员也能用来查找学术资料 —— 这就是 Skills 的 “跨用户、跨场景” 价值。

3.3 价值 3：构建生态效应 ——Skills 的复用与迭代，形成正向循环

“造 Skills” 的终极价值，在于构建一个 “Skills 生态”—— 就像手机 APP 生态一样，第三方开发者可以开发、分享、售卖 Skills，用户可以自由选择、组合 Skills，Agent 框架提供运行环境，最终形成 “开发者受益、用户受益、生态繁荣” 的正向循环。

生态效应 1：Skills 的复用降低开发门槛，吸引更多开发者

对于第三方开发者来说，开发一个 Skill 的门槛远低于开发一个完整 Agent：

• 开发一个 Agent 需要覆盖 “感知、决策、执行” 全流程，技术栈复杂，周期长；
• 开发一个 Skill 只需聚焦 “单一任务”，技术栈单一（比如 “PDF 文本提取 Skill” 只需掌握 PDF 解析技术），周期短（1-2 天就能完成一个基础 Skill）。

这意味着，更多的开发者（包括学生、独立开发者、中小企业团队）都能参与到 Skills 的开发中。比如，一个擅长 Excel 处理的独立开发者，可以开发 “Excel 复杂公式生成 Skill”“Excel 数据可视化 Skill”，上传到 Skills 市场，获得收益；一个精通自然语言处理的学生，可以开发 “文案润色 Skill”“多语言翻译 Skill”，积累项目经验。

生态效应 2：多 Agent 使用反馈，推动 Skills 快速迭代

一个 Skill 被越多 Agent 使用，获得的反馈就越多，迭代速度就越快，质量就越高 —— 这是 “单一 Agent 专属能力” 无法比拟的。

举个例子：“SQL 查询生成 Skill” 最初只能支持简单的 SELECT 查询，当它被 100 个不同行业的 Agent 使用后，开发者会收到各种反馈：

• 财务 Agent 用户：需要支持 GROUP BY 分组统计；
• 运营 Agent 用户：需要支持 JOIN 多表关联查询；
• 科研 Agent 用户：需要支持复杂的数学函数计算。

基于这些反馈，开发者迭代优化 Skill，新增这些功能 —— 最终，这个 Skill 会变得越来越强大，能满足更多场景的需求，而所有使用它的 Agent 都能 “免费” 获得这些优化，无需自己修改代码。

生态效应 3：Skills 市场形成，催生新的商业模式

就像 APP Store 催生了 “付费 APP、订阅制 APP、广告变现 APP” 等商业模式一样，Skills 市场也会催生新的商业形态：

• 免费 Skill：基础功能免费，吸引用户，积累流量；
• 付费 Skill：专业级功能收费（如 “高精度 OCR 识别 Skill”“专业财务分析 Skill”）；
• 订阅制 Skill：持续提供更新和维护的 Skill（如 “实时数据查询 Skill”“行业动态分析 Skill”）；
• 分成模式：第三方开发者开发的 Skill，在 Skills 市场售卖，与 Agent 框架提供方分成。

这种商业模式能激励更多优质 Skill 的产生，进一步丰富生态 —— 而这一切，都是 “造 Agent” 模式无法实现的，因为单一 Agent 的能力无法形成规模化的市场。

四、实例验证：那些已经成功的 “Skills 优先” 案例

理念需要实例支撑。事实上，当前 AI 领域的很多成功产品，本质上都是 “Skills 优先” 的践行者 —— 它们没有追求 “全能 Agent”，而是聚焦于打造高质量的模块化 Skills，再通过 Agent 载体提供服务。

4.1 案例 1：ChatGPT Plugins——AI 界的 “APP Store”

ChatGPT Plugins（现已升级为 GPT-4 Plugins）是最典型的 “Skills 生态” 案例。OpenAI 没有试图让 ChatGPT 本身具备 “订酒店、查天气、写代码、做数据分析” 等所有能力，而是开放了 Plugin 接口，让第三方开发者开发 “Skill 插件”，ChatGPT 作为 Agent 载体，负责 “理解用户指令→选择合适的 Plugin→调用并整合结果”。

比如：

• “Expedia Plugin”：专注于 “酒店 / 机票预订” 的 Skill；
• “Wolfram Plugin”：专注于 “数学计算、数据分析、图表生成” 的 Skill；
• “Code Interpreter Plugin”：专注于 “代码执行、文件处理” 的 Skill；
• “Zapier Plugin”：专注于 “连接其他应用（如 Excel、Slack、Notion）” 的 Skill。

这些 Plugin 本质上都是标准化的 Skills，具备 “单一职责、标准化接口、可配置” 的特征。用户可以根据自己的需求，启用不同的 Plugin，组装成专属的 ChatGPT Agent—— 比如，一个经常出差的用户可以启用 Expedia Plugin+Weather Plugin+Calendar Plugin，让 ChatGPT 成为 “出行助手”；一个数据分析师可以启用 Wolfram Plugin+Code Interpreter Plugin+Excel Plugin，让 ChatGPT 成为 “数据分析助手”。

截至 2024 年，ChatGPT Plugins 生态已拥有超过 1 万个第三方 Plugin，覆盖生活、工作、学习、科研等所有领域，用户数突破 1 亿 —— 这正是 “Skills 优先” 模式的巨大成功：OpenAI 只需维护 ChatGPT 的核心决策能力，而生态的丰富性由第三方开发者共同构建。

4.2 案例 2：LangChain——AI Agent 的 “Skill 工具箱”

LangChain 是当前最流行的 AI Agent 开发框架，它的核心设计理念就是 “模块化 Skills”。LangChain 本身不提供 “全能 Agent”，而是提供了一系列 “预制 Skills（Tools）” 和 “Agent 框架”，让开发者可以快速组装 Agent。

LangChain 的 Skills 生态主要包括：

• 文档处理类 Skill：PDFLoader、CSVLoader、WordLoader（读取不同格式文档）；
• 数据查询类 Skill：SQLDatabaseToolkit、VectorStoreToolkit（查询数据库、向量库）；
• 内容生成类 Skill：LLMChain、PromptTemplate（生成文本、优化提示词）；
• 工具调用类 Skill：PythonREPLTool、ShellTool（执行 Python 代码、Shell 命令）。

这些 Skills 都具备标准化的接口，开发者可以直接调用，也可以自定义新的 Skill。比如，一个开发 “法律 Agent” 的团队，不需要从头开发 “PDF 合同解析” 能力，只需使用 LangChain 的 PDFLoader Skill，再开发一个 “法律条款提取 Skill”，就能快速组装出一个能 “解析合同、提取关键条款、生成法律意见” 的 Agent。

截至 2024 年，LangChain 的 GitHub 星标数超过 8 万，成为 AI Agent 开发的事实标准 —— 这背后的核心原因，就是它抓住了 “Skills 复用” 的痛点，让开发者从重复造轮子中解放出来，聚焦于场景专属的决策逻辑。

4.3 案例 3：Notion AI—— 模块化的 “办公 Skill 集合”

Notion AI 是 Notion 推出的 AI 功能，它没有被包装成 “办公 Agent”，而是以 “模块化 Skills” 的形式嵌入在 Notion 的各个场景中，用户可以按需调用：

• 文本生成 Skill：“写一篇博客大纲”“生成会议纪要”“总结文档核心内容”；
• 文本编辑 Skill：“润色文案”“简化语言”“转换语气（正式 / 口语）”；
• 数据处理 Skill：“将表格数据生成图表”“统计表格中的数值”；
• 格式转换 Skill：“将文本转换为表格”“将列表转换为任务清单”。

这些 Skills 都具备 “单一职责、可配置” 的特征：比如 “生成会议纪要” Skill，可以配置 “参会人员”“会议时长”“重点提炼程度” 等参数；“润色文案” Skill，可以配置 “语气（专业 / 友好 / 幽默）”“长度（缩短 / 延长）” 等参数。

Notion AI 的成功，在于它没有试图打造一个 “全能办公 Agent”，而是将 AI 能力拆解为用户日常办公中最需要的 “小 Skill”，让用户在使用 Notion 的过程中，随时随地都能调用 —— 这种 “嵌入式 Skills” 的模式，让 AI 功能的使用率大幅提升，截至 2024 年，Notion AI 的月活用户已突破 2000 万，成为办公 AI 领域的标杆产品。

五、如何落地：从今天开始，打造你的第一个 Skill

理念和案例都已明确，现在最关键的问题是：作为开发者，你该如何从今天开始，打造自己的第一个 Skill？以下是一套经过验证的落地方法论，分为 5 个步骤，每个步骤都有具体的操作指南和示例。

5.1 步骤 1：明确核心任务 —— 聚焦 “单一职责”，拒绝 “多功能”

打造 Skill 的第一步，是明确它要解决的核心任务—— 必须是 “单一、具体、无歧义” 的，不能是模糊的 “多功能集合”。

操作指南：

1. 用一句话描述 Skill 的核心功能，格式为：“为【用户 / Agent】提供【具体操作】，解决【具体问题】”；
2. 排除无关功能：如果一个功能和核心任务无关，即使看起来有用，也要砍掉；
3. 避免 “过度设计”：不要一开始就考虑 “未来可能需要的功能”，先实现核心任务，再逐步迭代。

示例：打造 “SQL 查询生成 Skill”

• 核心任务描述：“为 Agent 提供‘根据自然语言指令生成 SQL 查询语句’的能力，解决‘非技术用户无法编写 SQL’的问题”；
• 排除无关功能：不包含 “SQL 执行”“结果分析”“错误修复” 等功能（这些可以作为独立 Skill）；
• 核心范围：仅接受自然语言指令和数据库表结构，输出对应的 SQL 查询语句。

5.2 步骤 2：设计标准化接口 —— 遵循 “通用协议”，保证 “即插即用”

接口是 Skill 的 “灵魂”—— 标准化的接口能让 Skill 被任何 Agent 调用，而无需修改 Agent 代码。设计接口时，要遵循 “输入明确、输出统一、错误可预期” 的原则。

操作指南：

1. 定义输入参数（Input）：
   • 区分 “必填参数” 和 “可选参数”；
   • 明确参数类型（字符串、数字、JSON、文件路径等）；
   • 提供参数说明和示例。

1. 定义输出结果（Output）：
   • 统一输出格式（推荐 JSON）；
   • 包含 “执行状态”（成功 / 失败）、“核心结果”、“错误信息”（失败时）；
   • 结果要结构化，便于 Agent 解析。

1. 定义调用协议（Protocol）：
   • 推荐使用 REST API（最通用）或函数调用（适用于 Agent 框架）；
   • 明确请求方法（GET/POST）、请求头、响应状态码。

示例：“SQL 查询生成 Skill” 的接口设计

// 输入参数（POST请求体） { "natural_language_query": "查询2024年10月的销售额大于10万的订单", // 必填：自然语言指令 "database_schema": { // 必填：数据库表结构（JSON格式） "table_name": "orders", "columns": [ {"name": "order_id", "type": "int"}, {"name": "sale_amount", "type": "decimal"}, {"name": "order_date", "type": "date"}, {"name": "customer_id", "type": "int"} ] }, "sql_dialect": "MySQL" // 可选：SQL方言（默认MySQL，支持PostgreSQL/Oracle等） } // 输出结果（响应体） { "status": "success", // 执行状态：success/fail "data": { "sql_query": "SELECT * FROM orders WHERE order_date BETWEEN '2024-10-01' AND '2024-10-31' AND sale_amount > 100000;" // 核心结果：生成的SQL }, "error_msg": "", // 错误信息：失败时填写（如“数据库表结构缺失”“指令无法解析”） "debug_info": { // 可选：调试信息（便于迭代优化） "parsed_intent": "查询指定时间范围、销售额阈值的订单", "used_columns": ["order_date", "sale_amount"] } } // 调用协议（REST API） - 请求方法：POST - 请求URL：/api/skills/sql-generator - 请求头：Content-Type