在人工智能的演进历程中，如果说大语言模型（LLM）是'大脑'，那么 Agent (智能体) 就是拥有手脚的'完整人'，而 Skills (技能) 正是这些手脚能完成的具体动作。
从单纯的对话机器人（Chatbot）向能够解决复杂任务的 Agent 进化，核心在于 Skills 的设计与集成。本文将深入探讨 Agent Skills 的定义、架构、运作机制以及设计最佳实践。
1. 什么是 Agent Skills？
Agent Skills，通常也被称为 Tools (工具) 或 Capabilities (能力)，是指赋予大语言模型与外部世界交互的接口。
原生的 LLM 存在两个主要局限：
- 幻觉与知识截止：它只能依赖训练时的权重，无法获取实时信息。
- 行动力缺失：它只能输出文本，无法点击按钮、发送邮件或查询数据库。
Skills 填补了这一空白。它本质上是一段可执行的代码、一个 API 接口或一个工作流，Agent 可以根据用户的意图，自主决定何时调用、如何调用这些技能，从而完成实际任务。
比喻
- LLM：一位博学但被关在空房间里的指挥官（大脑）。
- User：下达命令的客户。
- Skills：电话、互联网、计算器、文件柜、秘书（手脚和工具）。
2. Skill 的核心解剖结构
一个标准的 Agent Skill 通常包含以下四个关键要素。对于开发者而言，这通常对应于 Function Calling (函数调用) 的定义结构：
2.1. 名称 (Name)
技能的唯一标识符。例如 get_current_weather 或 search_wikipedia。
2.2. 描述 (Description) —— 最关键的部分
这是写给 LLM 看的'说明书'。LLM 并不理解代码逻辑，它依靠自然语言描述来判断：
- 这个技能是做什么的？
- 在什么场景下应该使用这个技能？
示例：
'当用户询问特定地点的实时天气状况、气温或风向时使用此工具。不要用于查询历史天气。'
2.3. 参数架构 (Parameter Schema)
定义了技能运行所需的输入数据格式（通常是 JSON Schema）。
- 必填项：如查询天气的
location(城市)。 - 选填项：如
unit(摄氏度或华氏度)。
2.4. 执行逻辑 (Implementation)
这是实际运行的代码。当 LLM 决定调用技能并填充好参数后，系统会在后台运行这段代码（如调用 REST API、执行 Python 脚本、查询 SQL 数据库），并将结果返回给 LLM。
3. Skills 的分类
根据功能属性，Agent Skills 通常分为以下几类：
3.1. 信息检索类 (Retrieval Skills)
解决 LLM 知识时效性和私有数据问题。
- Web Search：使用 Google/Bing API 搜索实时新闻。
- RAG (检索增强生成)：在企业私有向量数据库中查找文档。
3.2. 计算与逻辑类 (Computation Skills)
解决 LLM 数学能力弱和逻辑不严谨的问题。
- Code Interpreter：编写并执行 Python 代码来进行复杂数学运算或数据可视化。
- Calculator：精确的数值计算工具。
3.3. 生产力与行动类 (Action Skills)
真正改变物理或数字世界状态的能力。
- 办公自动化：发送 Gmail、创建 Google Calendar 日程、发送 Slack 消息。
- SaaS 集成：在 CRM 系统中更新客户信息，在 Jira 中创建工单。
3.4. 多模态类 (Multimodal Skills)
处理非文本数据。
- Image Gen：调用 DALL-E 或 Midjourney 生成图片。
- OCR：识别上传文档中的文字。
4. Agent 如何使用 Skills：认知循环
Agent 使用技能的过程不是简单的'触发器'，而是一个复杂的认知推理过程，通常被称为 ReAct (Reasoning + Acting) 循环或 Plan-and-Execute 模式。
假设用户指令：'帮我看看这周末上海下不下雨，如果下雨就帮我起草一封取消户外活动的邮件。'
第一步：意图识别与规划 (Reasoning)
Agent 思考：用户的意图包含两个步骤。首先需要获取天气信息，然后根据结果决定是否写邮件。
- 当前状态：未知上海周末天气。
- 所需技能：
weather_api。
第二步：参数提取 (Parameter Extraction)
Agent 根据 Schema 提取参数：
location= 'Shanghai'date= 'this weekend' (Agent 会将其转换为具体日期，如 '2026-01-24')
第三步：技能执行 (Execution)
系统调用 weather_api(location="Shanghai", date="...")。
假设 API 返回结果：{"condition": "Rainy", "probability": "80%"}。
第四步：观察与决策 (Observation & Decision)
Agent 接收到 API 返回的 JSON 数据。
Agent 思考：API 显示会下雨。根据用户指令'如果下雨就…'，现在需要执行第二个动作。
所需技能：虽然可以调用邮件 API，但用户说的是'起草'，所以可能只是调用 LLM 自身的文本生成能力，或者调用 draft_email 工具。
第五步：生成响应 (Response)
Agent 输出：'已为您查询，上海这周末有 80% 的概率下雨。以下是为您起草的取消活动邮件：……'
5. 设计高质量 Skills 的最佳实践
在开发 Agent 时，Skill 的质量直接决定了 Agent 的智商。以下是设计原则：
5.1. 原子性 (Atomicity)
一个 Skill 最好只做一件事，且把这件事做好。
- Bad:
manage_data(既查数据又改数据，描述模糊)。 - Good:
query_customer_record和update_customer_status分离。
这样可以降低 LLM 混淆的概率，提高规划的准确性。
5.2. 描述即 Prompt (Description is Prompt)
LLM 是通过阅读描述来选择工具的。因此，描述必须：
- 清晰：消除歧义。
- 鲁棒：包含边缘情况说明（例如：'如果是模糊查询，请先调用搜索工具'）。
5.3. 容错性设计 (Error Handling)
Skill 的输出不仅要给用户看，更要给 Agent 看。如果 API 调用失败，Skill 应该返回清晰的错误信息（如 {"error": "City not found"}），而不是抛出异常崩溃。这样 Agent 可以自我纠正：'抱歉，找不到该城市，您是指……'
5.4. 最少上下文原则
Skill 的返回结果应尽量精简。如果一个查询返回了 5MB 的 JSON 数据，可能会撑爆 LLM 的上下文窗口（Context Window）。Skill 内部应预处理数据，只返回 Agent 决策所需的关键字段。
6. 未来展望：Agentic Workflow
随着技术发展，Agent Skills 正在经历从'单一工具'向'复合能力'的转变。
- 技能自动生成：未来的 Agent 可能会编写代码来为自己创建新的 Skill，而不是等待开发者开发。
- 多智能体协作：一个 Agent 的 Skill 可能是'呼叫另一个专业的 Agent'。例如，主 Agent 调用'法律顾问 Agent'作为一种 Skill 来处理合同。
- 端侧执行：手机上的 Agent 将拥有操作本地 App 的 Skill，如直接操作微信发送消息或在美团点外卖。
结语
Agent Skills 是连接大模型这一'数字大脑'与现实世界的桥梁。对于开发者而言，学会定义清晰、健壮的 Skills，是构建下一代 AI 应用（AI Native Apps）的核心竞争力。
