Agent Skills用什么语言编写？技能描述层与执行层的语言选择详解

Agent Skills 的语言之问

随着 AI Agent（智能体）技术的快速发展，"Agent Skills"（智能体技能）逐渐成为构建自主 AI 系统的核心组件。在开发者社区中，一个常见的疑问是：Agent Skills 究竟是用什么语言编写的？ 这个看似简单的问题，实际上触及了 AI Agent 架构设计中的关键议题——技能的定义与执行范式。

本文将围绕这一话题，深入探讨 Agent Skills 的语言选择、背后的设计哲学，以及不同实现方式的优劣权衡。

什么是 Agent Skills？

在深入语言问题之前，需要先明确 Agent Skills 的概念。智能体技能是指赋予 AI Agent 执行特定任务能力的功能模块，包括调用外部 API、执行代码、查询数据库，以及更复杂的多步骤工作流。

要理解技能在 Agent 架构中的位置，需要先了解当前主流的 Agent 运行范式。大多数现代 AI Agent 采用的是 ReAct（Reasoning + Acting） 框架的变体：大语言模型先进行推理（Reasoning），决定下一步应该采取什么行动（Acting），然后观察行动结果，再进入下一轮推理。ReAct 框架由 Yao et al. 在 2022 年提出（论文发表于 ICLR 2023），其创新之处在于将推理能力与外部工具交互能力统一在一个 Thought → Action → Observation 的交替循环中。在 ReAct 之前，研究者通常将推理（如 Chain-of-Thought 思维链）和行动（如 WebGPT 的搜索操作）分开处理，ReAct 则证明了交替进行的方式能显著提升任务完成质量。这一范式后来衍生出 Reflexion（加入自我反思机制）、LATS（结合蒙特卡洛树搜索进行更优决策）、Plan-and-Execute（先制定完整计划再逐步执行）等变体，共同构成了当前 Agent 系统的理论基础。在这个循环中，Agent Skills 就是"Acting"这一环节的具体载体——它们是 Agent 能够与外部世界交互的"手和脚"。

从软件工程的视角来看，Agent Skills 的角色类似于传统应用中的插件系统或微服务：它们以模块化的方式封装特定能力，通过标准化接口与主系统交互，支持动态加载和组合调用。但与传统插件不同的是，Agent Skills 的调用方（LLM）并不是通过硬编码的逻辑来选择和调用技能，而是基于语义理解进行动态决策，这要求技能的定义必须同时对人类和 AI 都具有可理解性。

从架构角度看，一个 Agent Skill 通常包含两个层面：

• 技能的描述/定义层：告诉大语言模型（LLM）这个技能能做什么、需要什么参数、何时调用。
• 技能的执行层：真正实现功能逻辑的代码。

这两个层面使用不同的"语言"来表达，这也是"Agent Skills 用什么语言编写"这个问题值得深入讨论的原因。

描述层：自然语言与结构化配置

自然语言提示定义技能

在许多现代 Agent 框架中，技能的描述层大量依赖自然语言。开发者通过自然语言告诉 LLM 某个工具的用途，例如"这个函数用于查询天气，输入城市名称，返回温度信息"。这种方式充分利用了大模型对自然语言的理解能力，降低了技能定义的门槛。

这背后的机制与 Prompt Engineering（提示工程） 密切相关。在实际运行中，技能的自然语言描述通常被注入到 System Prompt（系统提示词）中，与 Agent 的角色设定、行为规则等共同构成完整的提示上下文。LLM 在每轮推理时会"阅读"所有可用技能的描述，理解它们的功能边界和适用场景，然后决定是否调用某个技能以及如何构造调用参数。因此，技能描述的质量直接影响 Agent 的行为准确性——一段模糊的描述可能导致模型在错误的场景下调用工具，或者传入不合适的参数。这也是为什么越来越多的框架开始强调"工具描述即文档"的理念，要求开发者像编写高质量 API 文档一样精心撰写技能描述。值得注意的是，当可用技能数量增多时，所有技能描述会占据大量的上下文窗口（Context Window），这不仅增加了推理成本，还可能因信息过载导致模型选择准确率下降。为此，一些框架引入了"技能检索"机制——先通过语义相似度从技能库中筛选与当前任务最相关的少量技能，再将它们注入提示中，这本质上是 RAG（检索增强生成）思想在工具选择领域的应用。

JSON Schema 结构化定义

为了让技能调用更加可靠，业界普遍采用 JSON Schema 等结构化格式来定义工具接口。OpenAI 的 Function Calling、Anthropic 的 Tool Use，以及 MCP（Model Context Protocol）协议，都采用 JSON 作为技能描述的标准载体。

JSON Schema 本身是一个用于描述 JSON 数据结构的规范标准（IETF 标准草案），最早由 Kris Zyp 在 2009 年提出，经过多年迭代目前处于 IETF Draft 2020-12 版本。它最初被广泛用于 API 验证和表单校验等场景，定义了一套丰富的关键字体系（如 type、properties、required、enum、pattern、minimum/maximum 等），能够精确约束 JSON 数据的类型、格式、必填项、取值范围等条件。这种精确性正是 Agent 技能调用所需要的——它同时服务于两个受众：LLM 通过阅读 Schema 理解工具的语义和参数约束，而执行引擎则利用 Schema 进行参数验证和类型检查，确保模型输出的调用请求符合预期格式。这种双重服务能力使其成为连接 AI 推理层和代码执行层的理想桥梁。

在具体的技术演进上，各家平台走过了不同的路径：OpenAI 在 2023 年 6 月率先推出 Function Calling，允许开发者通过 JSON Schema 定义函数签名，模型会输出结构化的函数调用请求而非纯文本，这被视为 Agent 技能调用的里程碑事件；Anthropic 随后推出 Tool Use 功能，采用了类似但更灵活的 JSON 定义方式，并在错误处理和多工具协同方面做了改进；MCP（Model Context Protocol） 则是 Anthropic 于 2024 年底提出的开放标准协议，它不仅定义了工具（Tools）的描述规范，还涵盖了资源（Resources）和提示模板（Prompts）的标准化，目标是建立一个类似于"AI 领域的 USB-C 接口"的通用互操作标准，让不同的 Agent 框架和 LLM 提供商能够共享同一套技能生态。

MCP 在架构上采用客户端-服务器模式，其中 MCP Host（如 Claude Desktop、IDE 插件等应用）通过 MCP Client 与多个 MCP Server 通信。每个 MCP Server 暴露三类能力原语：Tools（可执行的操作）、Resources（可读取的数据源）和 Prompts（可复用的提示模板）。通信协议基于 JSON-RPC 2.0，支持 stdio 和 HTTP+SSE 两种传输方式。这种架构设计借鉴了 Language Server Protocol（LSP） 的成功经验——LSP 统一了代码编辑器与语言服务之间的接口，使得 VS Code、Vim、Emacs 等任何编辑器都能获得任何编程语言的智能补全和诊断能力。MCP 试图在 AI 领域复制这一成功，让任何 Agent 都能接入任何数据源和工具，从而打破当前各框架各自为政的工具生态碎片化问题。

这种设计的核心思想是：用人类和机器都能理解的结构化格式，明确定义技能的输入输出契约，减少 LLM 调用时的歧义。

执行层：主流编程语言的选择

当技能真正被调用执行时，背后运行的是传统编程语言编写的代码。目前主流选择如下：

Python：Agent Skills 执行层的首选

Python 是 Agent Skills 执行层的绝对主流语言，原因包括：

• 拥有最丰富的 AI/ML 生态，几乎所有主流 Agent 框架（如 LangChain、AutoGPT、CrewAI）都以 Python 为核心语言。
• 语法简洁，适合快速迭代和原型开发。
• 庞大的第三方库让技能可以轻松对接各类外部服务。

Python 在 AI 领域的统治地位有深层的历史原因。早在深度学习兴起之前，Python 就因 NumPy、SciPy 等科学计算库成为数据科学的首选语言。随后 TensorFlow（2015 年）、PyTorch（2016 年）等深度学习框架选择 Python 作为主要接口语言，进一步巩固了这一生态优势。到 Agent 时代，这种先发优势产生了巨大的网络效应——最多的开发者、最多的开源项目、最多的教程资源都围绕 Python 展开，形成了自我强化的正向循环。

具体到各主流框架的技术演进：LangChain 是最早将"链式调用"（Chain）和"工具使用"（Tool Use）抽象化的框架，它提供了 @tool 装饰器等便捷方式，让开发者只需几行 Python 代码就能将一个普通函数转化为 Agent 可调用的技能。LangChain 团队后来推出了 LangGraph，采用有向图（DAG）结构来编排 Agent 工作流，提供了更细粒度的状态管理和循环控制流，解决了线性 Chain 在复杂场景下的表达力不足问题。AutoGPT 是 2023 年 3 月引爆自主 Agent 概念的先驱项目，它展示了 Agent 自主规划、执行和迭代的可能性，其技能系统完全基于 Python 模块构建；CrewAI 则代表了多 Agent 协作范式，它允许开发者定义多个具有不同角色和技能集的 Agent，让它们以团队协作的方式完成复杂任务，每个 Agent 的技能同样以 Python 函数形式实现。此外，微软推出的 AutoGen 强调多 Agent 对话式协作，而斯坦福的 DSPy 则另辟蹊径，将 Prompt 优化转化为可编程的模块优化问题，整个生态呈现百花齐放的态势。

TypeScript：全栈场景的有力选择

在 Web 和全栈应用场景中，TypeScript 正成为重要选择。Vercel AI SDK、LangChain.js 等框架让开发者能在 Node.js 环境中构建 Agent 技能，特别适合需要与前端深度集成的应用。

TypeScript 在 Agent 开发中的崛起与 Web 平台计算能力的演进密切相关。Edge Runtime（边缘运行时） 和 Serverless（无服务器） 部署模式的成熟，使得 JavaScript/TypeScript 代码可以在全球分布的边缘节点上以极低延迟运行。Cloudflare Workers、Vercel Edge Functions、Deno Deploy 等平台提供了基于 V8 引擎的轻量级运行时环境，冷启动时间可低至几毫秒，相比传统 AWS Lambda 等 Serverless 函数动辄数百毫秒甚至数秒的冷启动有数量级的提升。对于需要实时响应的 AI 应用（如聊天机器人、实时助手）来说，这种低延迟特性具有天然优势，因为一个复杂的 Agent 任务可能涉及十几次工具调用，每次调用节省的延迟累积起来非常显著。Vercel AI SDK 正是利用了这一架构优势，让开发者可以将 Agent 技能部署为 Edge Function，实现毫秒级的冷启动时间。

此外，TypeScript 的强类型系统在技能定义中提供了额外的安全性——当技能的输入输出通过 TypeScript 类型系统定义时，许多参数错误可以在编译阶段就被捕获，而不必等到运行时才暴露。配合 Zod 等运行时类型验证库，TypeScript 可以实现从编写、编译到运行的全链路类型安全。对于已有大量 Web 前端投入的团队来说，使用 TypeScript 编写 Agent 技能可以实现前后端技术栈的完全统一，减少上下文切换和团队协作成本。

不过 Edge Runtime 也有明确的限制：执行时间通常有上限（如 30 秒）、可用内存有限（通常 128MB 左右）、不支持所有 Node.js API（如文件系统操作受限），因此更适合轻量级的 API 调用类技能，而计算密集型或长时间运行的任务仍需要传统的服务器端运行环境。

Go 和 Rust：高性能场景的探索

部分开发者使用 Go、Rust 等语言构建高性能的技能执行层，尤其在对延迟和并发有严格要求的生产环境中，这些语言的性能优势更为明显。Go 语言的 goroutine 并发模型使其特别适合需要同时处理大量并发技能调用的场景（如多 Agent 系统中的并行工具执行），而 Rust 的零成本抽象和内存安全保证则在需要极致性能且不容许运行时错误的关键基础设施中占据优势。在实际应用中，这些语言通常不用于编写业务层的 Agent 技能，而是用于构建底层的技能执行引擎、沙箱运行时或高性能的 MCP Server 实现。

新兴范式：代码即技能（Code as Skills）

近期出现了一种值得关注的新趋势——让 LLM 直接生成并执行代码作为技能。与其预先定义大量固定工具，不如让模型根据任务需求即时编写 Python 代码并在沙箱中运行。

这种"代码即技能"的思路，把编程语言本身作为 Agent 的通用行动接口。其优势在于极大的灵活性——理论上任何能用代码表达的任务都可以被完成，无需为每个场景单独封装工具。

这一范式已经在多个项目中得到了实践验证。OpenAI 的 Code Interpreter（现已整合为 Advanced Data Analysis 功能）是最广为人知的例子——它让 ChatGPT 能够动态编写并执行 Python 代码来完成数据分析、绘图、文件处理等任务，用户无需提前定义任何工具，模型会根据需求自行编程。在学术研究中，Voyager（NVIDIA 等机构发布的 Minecraft AI Agent）展示了更激进的代码即技能思路：Agent 不仅在运行时生成代码，还会将成功执行的代码片段保存为可复用的技能库，实现"技能的自我积累与进化"。具体来说，Voyager 维护了一个「技能库」（Skill Library），每当 Agent 成功完成一个新任务，对应的代码会被抽象为一个带有自然语言描述的可复用 JavaScript 函数，存储在向量数据库中。未来遇到类似任务时，Agent 会先通过语义检索查找已有技能，尝试复用或组合，只在现有技能不足时才生成新代码。这种「课程学习 + 技能缓存」的机制，使得 Agent 的能力随时间持续增长，类似于人类通过经验积累形成肌肉记忆的过程。这一思路也被后续的 DEPS、Ghost in the Minecraft 等研究项目继承和发展，标志着 Agent 从"工具使用者"向"工具创造者"的范式转变。

不过，动态代码执行也带来了严峻的安全性和可控性挑战——恶意或错误的代码可能导致数据泄露、系统资源耗尽甚至基础设施破坏，因此通常需要配合严格的沙箱隔离机制来保障系统安全。当前主流的沙箱方案包括：Docker 容器隔离，为每次代码执行创建独立的容器环境，通过 namespace 和 cgroup 限制网络访问、文件系统权限和计算资源使用；WebAssembly（Wasm）沙箱，在浏览器或服务端提供近乎原生性能的安全执行环境，其线性内存模型天然阻止了缓冲区溢出等常见攻击；gVisor 等内核级沙箱，通过在用户态拦截和重新实现系统调用，提供比 Docker 更细粒度的安全控制；以及 Pyodide 等将 CPython 解释器编译为 WebAssembly 的方案，让 Python 代码在完全隔离的环境中运行，E2B（"Environment to Browser"）平台就是基于类似理念提供了开箱即用的云端代码沙箱服务。每种方案在安全性、性能和兼容性之间都有不同的权衡取舍：Docker 兼容性最好但启动开销较大，Wasm 启动极快但生态支持有限，gVisor 安全性最高但可能引入性能损耗。

总结：Agent Skills 的语言选择是分层且多元的

回到最初的问题——Agent Skills 用什么语言编写？ 答案需要分层来看：

层面	主流语言/格式	核心诉求
描述层	自然语言 + JSON Schema	可读性与契约明确性
执行层	Python（主流）、TypeScript、Go/Rust	功能实现与性能
新兴范式	动态代码生成（主要为 Python）	灵活性与通用性

对于开发者而言，选择哪种语言与范式，取决于具体的应用场景、性能需求和团队技术栈。理解这种分层结构，有助于更清晰地设计和构建可靠的 AI Agent 系统。

随着 MCP 等标准化协议的普及，Agent Skills 的编写方式正在走向规范化，未来有望形成更加统一的技能定义与执行标准。值得注意的是，技能标准化的进程可能还会受到另一个趋势的影响——随着 LLM 能力的持续提升，描述层与执行层之间的界限可能逐渐模糊，模型或许能够直接从简洁的自然语言描述推断出完整的执行逻辑，进一步降低技能开发的门槛。但在可预见的未来，这种分层架构仍将是构建可靠 Agent 系统的最佳实践。