Agent Skills本质解析：函数调用+Schema+HTTP服务的开源实践

最新推荐文章于 2026-06-28 14:43:28 发布

原创

最新推荐文章于 2026-06-28 14:43:28 发布 · 391 阅读

1. 别再被“Agent Skills”这个词带偏了：它根本不是Claude专属功能

最近刷技术社区、AI工具群，甚至朋友圈里，总能看到“Agent Skills”“Claude Skills”“Superpower Skills”这类词高频出现，配图往往是某个插件图标闪着光，标题写着“Claude必装的5个Skills”“一键解锁Anthropic超能力”。我点进去一看，内容却五花八门：有的教你怎么在Cursor里装一个Figma同步插件，有的贴一段curl命令调用本地Ollama模型，还有的直接甩出GitHub仓库链接，备注“已失效”。更离谱的是，好几篇所谓“教程”开头就写“请先获取Anthropic API Key”，可翻遍官方文档，Anthropic压根没发布过叫“Skills”的SDK、CLI或插件市场。

这背后其实是个典型的术语迁移失焦现象。2024年中后期，随着Claude Code（原Codeium）和Cursor等AI编程助手深度集成大模型能力，“Skills”这个词被开发者社区自发借用来指代“可被AI代理（Agent）主动调用的、封装了特定动作能力的代码模块”。它不是Anthropic官方定义的技术标准，也不是Claude模型内置的功能开关；它更像程序员之间心照不宣的黑话——就像当年说“写个Shell脚本”没人会去查POSIX标准，大家默认就是指“能自动完成某件事的一段可执行逻辑”。

提示：所有标着“Anthropic Skills”“Claude Skills下载”的资源，99%与Anthropic公司无任何技术关联。Anthropic官网从未上线过Skills商店、SDK或注册中心。那些报错信息如 unable to connect to anthropic services failed to connect to api.anthropic.com ，本质是用户误将第三方工具配置指向了Anthropic的生产API域名，而该域名只接受标准Chat Completion请求，根本不识别任何“Skills”协议。

真正构成“Agent Skills”底层骨架的，是三个早已成熟、且完全开源的技术事实： 函数调用（Function Calling）能力 、 工具描述规范（Tool Schema） 和 本地服务桥接机制（Local HTTP/IPC Bridge） 。前者由OpenAI在2023年GPT-4 Turbo发布时正式推广，后者被Llama.cpp、Ollama、LM Studio等本地运行框架广泛采用。所谓“Skills”，不过是开发者把这两者组合起来，用Python/TypeScript写个HTTP接口，再给Agent配上一段JSON Schema描述——就这么简单，也这么容易被包装成玄学。

我去年帮一家做工业质检的客户落地AI辅助标注系统时，就用这个思路做了个“OCR校验Skill”：前端上传模糊图片，后端用PaddleOCR跑一遍，把结果结构化成JSON返回。整个过程没碰过Anthropic一行代码，但标注Agent每次遇到文字识别任务，都会自动触发这个Skill并消化结果。客户后来问：“这算不算你们说的Claude Skills？”我笑着摇头：“不，这只是你自己的技能，刚好被AI看懂了。”

2. 拆解真实世界的Agent Skills：从概念到可执行代码的四层结构

很多人一听到“Skills”，下意识觉得要搞个高大上的平台、注册账号、申请审核。其实真正在一线跑通的Agent Skills，结构极其朴素，完全可以拆成四个物理上分离、逻辑上咬合的层次。我把它们画成一张工作流图（纯文字描述，不依赖Mermaid），你对照着看，就能立刻明白为什么网上那些“安装包”“一键下载”全是误导：

[用户指令] 
     ↓ 解析意图（LLM判断需调用哪个Skill）
[Agent核心] → [Skill路由表] → [Skill执行器]
     ↑              ↓                ↓
[上下文记忆]   [JSON Schema描述]  [实际业务逻辑]
                          ↓
                    [结构化输出结果]

2.1 第一层：Agent核心——不是Claude，而是你选的推理引擎

所谓“Agent”，在这里特指能理解工具描述、决定何时调用、并解析返回结果的LLM运行时。它 必须支持函数调用协议 ，目前主流选择有三类：

云端闭源模型 ：OpenAI GPT-4o、Anthropic Claude 3.5 Sonnet（注意：Claude 3.5本身不提供Skills，但它支持Tool Use协议，可作为Skill调用器）
本地开源模型 ：Qwen2.5-7B-Instruct（经QLoRA微调后）、DeepSeek-V2-Lite（需开启tool_calling flag）、Phi-3-mini-128k-instruct（轻量首选）
专用Agent框架 ：LangChain的AgentExecutor、LlamaIndex的ReActAgent、自行编排的State Graph（推荐）

关键区别在于：Claude官方SDK（anthropic-python） 不原生支持Tool Calling 。你得用 messages 接口手动拼接 tool_use 块，再自己解析 tool_result 。而OpenAI SDK的 tools 参数、Ollama的 --tool 标志、Llama.cpp的 -t 选项，都是开箱即用的。所以当别人说“Claude Skills”，实际运行时大概率是用Claude当LLM，但Skill调度逻辑跑在LangChain里——Claude只是个“大脑”，不是“操作系统”。

2.2 第二层：Skill路由表——用JSON Schema说话，不是靠名字匹配

这是最容易被忽略、却最影响稳定性的环节。很多教程教你写个 get_weather.py ，然后在Agent里写 tools=[{"name": "get_weather"}] ，结果一跑就报错。问题出在Schema没对齐。

一个合格的Skill描述必须包含三项硬性字段：

type : 固定为 "function"
function.name : 函数名，必须与执行器暴露的端点一致（如 /weather ）
function.parameters : 严格遵循JSON Schema Draft 07规范 的object定义，不能少 type 、 properties 、 required

举个真实案例：我们给某跨境电商做的“物流轨迹查询Skill”，其Schema长这样：

{
  "type": "function",
  "function": {
    "name": "track_package",
    "description": "根据运单号查询国际快递实时物流状态，支持DHL/FedEx/UPS",
    "parameters": {
      "type": "object",
      "properties": {
        "tracking_number": {
          "type": "string",
          "description": "12位纯数字运单号，不含空格或字母"
        },
        "carrier": {
          "type": "string",
          "enum": ["DHL", "FedEx", "UPS"],
          "description": "快递公司简称，必须大写"
        }
      },
      "required": ["tracking_number", "carrier"]
    }
  }
}

注意两个细节： tracking_number 明确要求“12位纯数字”，

标签