Agent Skills：从“只会聊天”到“独当一面”1. 引言作为一名 Web 开发者，你可能已经玩过各种大语言模型

1. 引言

作为一名 Web 开发者，你可能已经玩过各种大语言模型（LLM）的 Chat 界面。它们博学多才，能写诗也能改 Bug，但当你试图让它“帮我查一下昨天的订单并给客户发一封补偿邮件”时，它通常只能尴尬地提供一段伪代码，而无法真正执行。

这就是目前 AI 应用从“玩具”走向“工具”的瓶颈：模型有大脑（智力），但没有手脚（执行力）。今天我们要聊的主题 Agent Skills（智能体技能） ，正是为 AI 装上“手脚”的核心机制。通过它，你可以将复杂的业务逻辑封装成 AI 可调用的能力单元，让 LLM 真正介入到你的现有业务系统中。

2. 从一个真实问题开始引入：为什么只靠 Prompt 是不够的？

想象你在负责一个内部研发运维助手的开发。你希望开发者通过自然语言直接询问：“生产环境的 CPU 负载高吗？如果高，请帮我扩容两个实例。”

如果你只用普通的 LLM API：

你必须在 Prompt 里写死所有的判断逻辑，或者手动解析 LLM 返回的文本。这就像是在写一个巨大的 switch-case，试图从自然语言中正则匹配出用户的意图。这种做法既脆弱又难以维护，一旦用户换种说法，逻辑就会崩溃。

传统方式的痛点：

无法触达私有数据：LLM 无法直接访问你的 Prometheus 监控或 K8s 集群。
逻辑黑盒：你无法控制 LLM 什么时候该查询、什么时候该执行，它可能在 CPU 正常时也触发扩容。
安全性与确定性：直接让 AI 写代码去执行是非常危险的，我们需要一套受控的、标准的接口。

3. Agent Skills 的核心思想：给 AI 的“Swagger 文档”

通俗来讲，Agent Skill 相当于为 LLM 定义的“语义化插件”或“具备说明文档的 API 接口” 。

核心逻辑类比：

在传统的后端开发中，我们编写 微服务（Microservices） 。每个服务都有 Swagger 文档，规定了输入参数和返回格式。

在 Agent 开发中，Skill 就像是给 LLM 看的 SDK。你不需要告诉 AI 什么时候调用它，你只需要告诉 AI：“我有这个技能，它的功能是什么，需要什么参数”。

它解决了什么： 解决了 AI 与现实世界的“连通性”和动作的“确定性”问题。
与传统微服务的关系： 一个 Skill 通常是对一个或多个微服务 API 的语义化封装。它不仅包含执行代码，还包含一段告诉 AI “在什么场景下该用我”的描述文字。

4. 实际开发场景

动态报表生成：用户查询“对比上季度营收” → 查询技能介入获取数据 → 绘图技能生成图表。
自动化工单处理：用户投诉“没收到货” → 订单查询技能调取物流 → 客服策略技能判断并执行补偿。
研发 CI/CD 助手：开发者输入“部署前端应用” → 构建技能触发 Jenkins → 状态监控技能实时反馈进度。
多源数据比对：查询“ERP 库存和 Excel 是否一致” → 数据库技能 + 文件处理技能同时介入 → 自动计算差异。

5. 典型架构与流程图

在工程实现上，Agent Skills 遵循一个“规划-执行-反馈”的闭环（ReAct 模式）：

Plaintext

6. 视觉辅助说明

类似于主流 Agent 框架（如 LangGraph 或 AutoGPT）中的智能体环路图（Agent Loop Diagram） 。

主要视觉元素：中心是一个大脑图标（LLM），周围环绕着多个带有“插头”标识的盒子（Skills/Tools）。
理解难点：该图能让开发者一眼看出 AI 不是通过单次请求完成任务，而是通过多次“观察（Observation）”和“动作（Action）”的迭代来逼近目标。
价值：读者可在 LangChain 官方文档或 Medium 搜索 “Agent ReAct flow diagram” 找到此类参考，它显著降低了对“多步推理”这一抽象过程的理解成本。

7. 代码示例：标准化 Skill 书写格式

在生产环境中，我们推荐使用 Pydantic 来定义强类型的输入 Schema。这能确保 AI 传递的参数符合后端接口要求。

from langchain.tools import tool
from pydantic import BaseModel, Field
from typing import Optional

# 1. 定义输入参数模型 (类似 Request DTO)
class RefundSchema(BaseModel):
    order_id: str = Field(description="订单号，格式为 ORD-12345")
    reason: str = Field(description="用户申请退款的原因")
    amount: Optional[float] = Field(None, description="退款金额，不填则全额退款")

# 2. 定义技能 (类似 Controller 里的 Action)
@tool("apply_refund_skill", args_schema=RefundSchema)
def apply_refund_skill(order_id: str, reason: str, amount: Optional[float] = None):
    """
    【重要：供 AI 阅读的描述】
    当用户明确要求对某个订单进行退款或取消并要求退钱时调用此技能。
    它会连接财务系统并返回处理流水号。
    """
    # 这里写具体的业务逻辑，如调用内部微服务
    print(f"正在执行退款逻辑: {order_id}, 原因: {reason}")
    
    # 返回给 AI 的结果，它会自动将其转化为自然语言告知用户
    return {
        "status": "success",
        "refund_id": "REF_2026_001",
        "message": "退款申请已提交，预计 24 小时内到账。"
    }

8. 工程化实践：推荐的目录结构 (Folder Tree)

当技能变多时，合理的目录结构能极大提升可维护性。建议采用类似插件系统的组织方式：

my-agent-service/ ├── app.py # 入口：加载 Agent 和所有技能 ├── agents/ # 存放不同角色的 Prompt 和逻辑 │ ├── support_agent.py # 客服智能体配置 │ └── ops_agent.py # 运维智能体配置 ├── skills/ # 核心：技能仓库 │ ├── __init__.py # 统一暴露技能 │ ├── order_manager.py # 订单相关技能 (查询、退款) │ ├── notify_service.py # 通知相关技能 (发邮件、发 Slack) │ └── db_querier.py # 数据查询技能 (只读 SQL) ├── schema/ # 存放通用的 Pydantic 模型 └── utils/ # 工具类：API Client、Logger

9. 实际应用案例

智能客服系统：集成“知识库搜索”技能与“订单修改”技能，实现从咨询到操作的闭环。
研发效率工具：集成“代码库搜索”与“Jira 自动创建”技能，AI 自动根据 Bug 描述定位代码并指派任务。
个性化营销助手：集成“用户画像查询”与“优惠券发放”技能，实现精准促活。

10. 从工程角度总结

核心价值

Agent Skills 实现了 “意图与执行的分离” 。开发者只需关注如何编写稳健的原子技能（Code），而复杂的逻辑编排（Workflow）则交由 LLM 根据用户意图动态完成。

工程注意事项：

语义冲突：如果两个技能的描述（Description）太接近，AI 会选错。描述必须具备唯一性和排他性。
原子化原则：一个技能只做一件事。复杂的任务应该由多个技能组合完成，而不是写一个“万能技能”。
安全性（Human-in-the-loop） ：对于涉及“写”操作（如删除、退款）的敏感技能，务必在 Skill 内部或 Agent 框架层加入人工确认逻辑。
可观测性：必须记录 AI 调用技能的完整链路（Input -> Thought -> Skill Call -> Output），这是后期调优 Prompt 的唯一依据。

建议路径：

从 只读技能（查询类）开始，逐步过渡到 状态变更技能（操作类）。在 2026 年的开发环境下，利用现成的框架（如 LangChain、Vercel AI SDK）可以让你在半小时内就完成第一个具备技能的 AI 助手。

你目前的项目中有哪些繁琐的手动操作流程是可以被封装成 Skill 的？或者在尝试定义 Schema 时遇到了哪些类型映射的难题？欢迎在评论区分享你的实战心得。