LLM/Agent 工程里的三件套与使用边界：Local Tool、MCP 与 Skill

摆正位置：一份写给工程师的 LLM/Agent 工具体系拆解

在当前的 LLM/Agent 技术浪潮中，我们几乎每天都在与“工具”打交道。从基础的本地脚本（Local Tool），到标准化的模型上下文协议（MCP），再到近期备受瞩目的技能（Skill），新概念层出不穷。

但这也带来了普遍的困惑：三者之间究竟是什么关系？如果 MCP 已经能解决工具复用，为什么还需要 Skill？如果 Skill 只是“带脚本的 Prompt”，它和把 SOP 写在 Prompt 里又有什么本质区别？许多讨论停留在宣传层面，缺乏一个清晰、务实的工程视角来指导我们的架构设计与技术选型。

这篇文章的目的，就是尝试把这三者摆回它们在工程体系中应有的位置。我们不讨论某个具体业务，而是希望为内部的技术同学提供一个统一的认知框架，深入剖冷静析 Local Tool、MCP 与 Skill 的角色边界、设计权衡与组合模式，最终帮助大家在实际工作中做出更合理的决策。

一、 重新定义三件套：回归工程本质

要厘清关系，首先要撕掉营销话术，用工程师的语言重新描述这三个概念分别解决了什么问题。与其说它们是并列选项，不如说它们代表了 LLM Agent 能力栈中三个不同抽象层次的组件：执行层、连接层与策略层。

1. Local Tool：原子能力的「执行层」

Local Tool 的本质，是你手中真实、可控的执行单元。它可以是一个 Python 函数、一段 Shell 脚本，甚至一个通过 bash 调用的二进制程序。它的核心价值在于 确定性 和 可观测性。

• 确定性：一个 Local Tool 的输入和输出是明确的。你为它编写了单元测试，处理了异常，它的行为在你熟悉的开发环境中是稳定可预测的。
• 可观测性：你完全掌控它的运行时。无论是日志、监控、Trace 还是断点调试，所有传统的软件工程手段都可以用在 Local Tool 上。

当我们将 Local Tool “注册”给 LLM 时，我们只是为这段确定的代码增加了一个新的调用方（Agent），并没有改变它的工程属性。LLM 在这里扮演的是一个“解释用户意图，并决定调用哪个函数”的角色，而 Local Tool 则负责把这件具体的事“干对、干稳”。

因此，Local Tool 是所有 Agent 能力的基石，是价值交付的最终落点。它的质量，直接决定了 Agent 的可靠性下限。

2. MCP Server：能力服务的「连接层」

当你的工具不再局限于单个 Agent 或单个进程使用，而是希望被多个团队、多个 Agent 平台安全、稳定地复用时，Local Tool 的模式就显得力不从心了。

MCP （ Model Context Protocol ）的本质，是一个标准化的「能力服务 网关 」协议。它解决的核心问题是“如何将外部世界的能力，以统一、安全、可治理的方式接入 LLM 生态”。

采用 MCP，你实际上是在做两件事：

1. 能力服务化：将你的 Local Tool（例如数据库访问、内部 API 调用）封装在一个独立的、长期运行的服务中，这个服务遵循 MCP 协议，能告诉外界“我有哪些工具、每个工具的 schema 是什么”。
2. 标准化消费：任何支持 MCP 协议的客户端，都可以通过标准方式发现并调用你的工具，而无需关心你的服务端是 Go、Python 还是 Node.js 实现的。

MCP 的核心价值： 解耦 与治理

• 解耦：将工具的 实现 与 Agent 的 消费 分离开。工具开发者可以独立迭代和部署他们的 MCP 服务，而 Agent 开发者只需关心如何调用这些标准化的工具。
• 治理：MCP 为权限控制、流量管理、版本控制、日志审计等提供了统一的抓手。你可以集中管理哪些 Agent 有权调用哪些工具，而不是在每个 Agent 中都维护一套独立的配置。

从 LLM 的视角看，MCP Tool 和 Local Tool 最终都表现为一系列可调用的函数。但从架构上看，MCP 将工具从“Agent 的一部分”变成了“平台上的一个独立服务”，这是构建可扩展 Agent 生态的关键一步。

3. Skill：场景策略的「使用层」

有了 MCP，工具的复用问题解决了，但新的问题随之而来：当一个 MCP Server 提供了数十个工具，或者一个复杂任务需要协同调用多个 MCP 服务和本地脚本时，模型和非专业用户如何知道“正确的用法” ？

你可以把所有用法都写在工具的 description 里，或者在 Agent 的 system prompt 中塞入冗长的 SOP。但这两种方式都面临扩展性问题：description 过长会干扰模型选择，system prompt 则难以在不同 Agent 间复用。

Skill 的本质，是一份模型可读的、围绕特定任务的「场景级策略说明书」。它将“如何使用一系列工具来完成一个完整任务”的知识，从 Prompt 和工具描述中剥离出来，打包成一个独立、可分发、可治理的“策略包”。

一个典型的 Skill（以 SKILL.md 为核心）主要包含：

• 场景定义：这个 Skill 是用来做什么的（description），例如“用于对线上服务进行初步的故障排查”。
• 工具清单：完成该场景需要用到哪些核心工具（MCP Tool 或本地脚本）。
• 策略与SOP：推荐的调用顺序、参数组合、以及处理常见异常的 fallback 流程。
• 最佳实践：提供正反案例，告诉模型在特定情况下应该如何决策。

Skill 的出现，标志着我们将 Agent 的能力构建从“提供原子工具”提升到了“封装场景策略”的阶段。它不创造新的执行能力，而是教会模型如何更智慧地编排和使用已有的执行能力。

二、设计权衡：从六个维度看三者的差异

理解了三者的定位后，我们可以从更具体的工程维度来审视它们的优劣。对于技术选型而言，没有银弹，只有基于特定场景的权衡。

维度	Local Tool	MCP Server	Skill
运行时控制	高：完全掌控执行环境、依赖和生命周期。可本地调试，符合传统开发习惯。	高：作为独立服务，拥有完整的日志、监控、报警和部署流程。开发者对运行时有完全控制权。	低：运行在平台的沙箱环境中，开发者无法直接干预。生命周期由任务驱动，是临时的。
可观测性与调试	高：可以直接查看本地日志、断点调试、性能分析。问题定位链路最短。	高：标准的服务端可观测性。可通过 TraceID 轻松关联请求，排查问题。	低：调试依赖平台提供的日志和输出。无法断点，问题排查链路长，且受沙箱环境限制，如同在“黑盒”中调试。
性能	高：本地执行，无网络开销。性能瓶颈主要在于工具自身逻辑。	中：引入了网络调用开销，但作为长驻服务，无冷启动问题。可通过优化部署和缓存来提升性能。	低：每次调用可能涉及沙箱环境的冷启动。此外，Skill 的执行还包含模型自身的推理延迟，整体耗时最长。
安全与治理	低：权限控制依赖宿主 Agent 的实现，缺乏统一治理。每个 Agent 都可能需要独立处理凭证，存在安全风险。	高：天然的中心化治理节点。可在 Server 端统一处理鉴权、密钥管理和访问审计，客户端无需感知敏感信息。	中：策略本身（SKILL.md）易于审计和共享。但其依赖的脚本或工具的安全性，仍需依赖 MCP 或平台注入的凭证机制来保障。
开发与迭代效率	高：开发新工具或修改逻辑最为快捷，直接修改本地代码即可。适合快速原型验证和个人使用。	中：需要遵循服务端开发流程，涉及接口定义、部署等环节，比本地脚本重。但长期看，接口稳定后迭代成本可控。	高（策略迭代） / 低（代码迭代） ：修改 SKILL.md 中的策略和SOP非常快。但如果涉及修改内部脚本，则会受限于调试困难，迭代效率反而最低。
复用与分发	低：强依赖于具体实现和 Agent 上下文，难以跨团队、跨平台复用。	高：只要网络可达且协议兼容，任何客户端都可以复用。是实现能力跨平台共享的最佳方式。	高（场景级） ：非常适合场景化“玩法”的沉淀与分发。一个写好的 Skill 包可以轻松分享给其他团队，在平台上被发现和复用。

小结：不存在最优解，只有最合适的组合

• 如果你追求 极致的开发效率和运行时控制，尤其是在能力探索阶段，Local Tool 是不二之选。
• 如果你的目标是构建 稳定、安全、可复用的平台级能力，并提供给多个消费方，MCP Server 是必然选择。
• 如果你希望将一套复杂的 任务级“玩法”或“SOP” 沉淀下来，并让非专业用户也能轻松使用，Skill 则是最合适的载体。

三、Agent 如何消费它们：一个简化的协作模型

理解了上述差异后，我们再来看看在一个实际的 Agent 系统中，这三者是如何协同工作的。当一个用户请求到达时，Agent 的决策过程大致如下：

1. 上下文加载：

   1. 工具加载：Agent 首先会加载当前可用的所有工具，这包括注册在平台上的 Local Tool 和通过 MCP Server 发现的远程工具。对模型而言，这是一个扁平化的工具列表，每一项都包含名称、描述和参数结构。
   2. Skill 加载：接着，平台会根据用户意图、当前项目空间的配置等信息，筛选出可能相关的 Skill。这些 Skill 的 SKILL.md 内容或其摘要，会作为一份特殊的“背景知识”或“指导手册”被注入到上下文中。

2. 模型推理与规划：

   1. 模型现在同时拥有了“能做什么”（工具列表）和“建议怎么做”（Skill 指导）。
   2. 当没有相关 Skill 时：模型会基于用户问题和它对工具 description 的理解，自行进行推理和规划（Plan），尝试组合工具来完成任务。这种方式在简单场景下有效，但在复杂场景中容易“走偏”。
   3. 当有相关 Skill 时：Skill 的内容会像一个“强引导”。模型会优先参考 Skill 中定义的 SOP 和最佳实践来制定计划。例如，Skill 中写道“排查问题分三步：查日志、看监控、给结论”，模型就会倾向于按这个顺序调用工具，而不是自己发明一套流程。

3. 工具执行：

   1. 无论决策是来自模型的自主规划还是 Skill 的引导，最终都会落到对具体工具的调用上。
   2. 调用 Local Tool，执行的是本地代码；调用 MCP Tool，则向 MCP Server 发起一个网络请求。Agent 负责执行这些调用并把结果返回给模型。

一个重要的心智模型：Skill 是“推荐路线”，而非“强制路线”

MCP/Local Tool 定义了地图上所有 可走的路（原子能力） 。而 Skill 则是在这张复杂的地图上，为你画出了一条或几条 推荐的旅游路线（场景策略） 。

• 如果你不提供 Skill，模型需要自己看着地图摸索，可能会走冤枉路。
• 你提供了 Skill，模型会倾向于沿着你画好的路线走，更高效、更对路。
• 但这并不意味着模型被“锁定”了。在遇到路线外的特殊情况时，它依然可以基于对地图（工具列表）的理解，选择走一些“小路”来解决问题。

这个模型解释了一个常见的疑问：“如果我只提供 MCP，模型就不能用了吗？” 答案是 能用，但不一定用得好。特别是在工具繁多、流程复杂的场景下，一份好的 Skill 指导，能极大地提升模型规划的准确性和效率，从而降低任务失败率。

四、何时选择？一个决策矩阵与三种核心模式

理论拆解最终要服务于实践。在日常工作中，我们到底应该选择哪种模式？下面提供一个简化的决策矩阵和三种业界正在普遍采用的核心模式，帮助你在不同阶段做出选择。

决策矩阵：从两个核心问题出发

你的选择，主要取决于两个问题：

1. 你的能力是否需要跨团队/跨平台复用？
2. 你的任务场景是否涉及复杂的多步SOP？

	简单、单步任务	复杂、多步SOP任务
个人/单团队使用 (无需跨平台复用)	Local Tool最快、最直接。例如，写一个个人用的代码格式化脚本。	Local Tool + 强 Prompt将SOP直接写在Agent的System Prompt中。简单有效，但SOP难以复用和管理。
跨团队/跨平台复用	模式一：MCP-Only将原子能力封装为MCP服务，依靠清晰的 description 引导模型。	模式二：MCP + 瘦 Skill核心能力在MCP，Skill只提供SOP，这是最理想的工程化组合。

此外，还存在一种特殊但常见的模式，即 Skill 需要依赖一些本地资源或脚本来完成标准化操作。

模式三：带本地脚本的 Skill

当某些标准化的前/后处理逻辑、模板文件或二进制工具难以通过 MCP 服务提供时，可以将其与 SKILL.md 一同打包。Skill 在这种模式下，不仅指导模型，还提供了完成任务所需的“物料”。

下面，我们详细拆解这三种核心模式。

模式一：“MCP-Only”——原子能力的稳定基石

这是将能力服务化的最直接方式。当你有一系列相对独立、原子化的功能，希望以服务形式提供给不同 Agent 消费时，此模式是最佳选择。

• 核心思想：将所有能力封装在一个或多个高内聚的 MCP Server 中。每个工具都设计得尽可能简单、正交，并通过 description 清晰地说明其功能和参数。

• 适用场景：

  • 提供基础的 CRUD 操作，如“根据用户 ID 查询订单信息”。
  • 封装一个独立的第三方 API，如“查询某个城市的天气”。
  • 功能边界清晰，调用链短，模型仅凭工具描述就能理解其用途。

• 例子：一个 user_profile_mcp 服务，提供 get_user_by_id、update_user_email 等工具。模型在需要获取用户信息时，可以直接调用，无需复杂的组合逻辑。

• 优点：架构清晰，职责单一。MCP Server 专注于提供稳定可靠的原子服务，Agent 则专注于消费这些服务。

• 挑战：当工具数量增多，或任务需要复杂的工具组合时，模型可能会“迷失”，做出错误的规划。此时，开发者需要花费大量精力在 Prompt Engineering 上，试图“教会”模型如何正确使用工具。

模式二：“MCP + 瘦 Skill”——场景策略的优雅封装

这是目前业界公认的、最具扩展性的理想组合模式。它在 MCP 的基础上，引入 Skill 作为策略层，实现了 执行与策略的分离。

• 核心思想：

  • MCP Server (执行层) ：负责所有“脏活累活”，提供稳定、高性能的原子工具。这里是工程质量和可观测性的保障。
  • 瘦 Skill (策略层) ：Skill 包中几乎只有 SKILL.md 文件。它不包含复杂的执行逻辑，只专注于定义“在某个特定场景下，应该如何编排和调用 MCP 工具”。

• 适用场景：

  • 复杂业务流程：一个需求需要依次调用“创建订单”、“锁定库存”、“发起支付”等多个 MCP 工具，Skill 定义了这一完整流程和异常处理方式。
  • 领域SOP固化：将某个领域的最佳实践（如“分析一次接口性能问题”的完整步骤）封装成 Skill，供团队复用。
  • 降低非专业用户使用门槛：产品经理可以用自然语言说“帮我创建一个营销活动”，Agent 通过匹配对应的 Skill，就知道要调用哪些 MCP 工具来完成。

• 例子：一个“商品发布”场景。

  • MCP 工具：product_mcp 提供 validate_title、upload_image、create_draft、submit_for_review 等原子工具。
  • 瘦 Skill：publish_product_skill 的 SKILL.md 中定义了商品发布的完整 SOP：“第一步调用 validate_title 检查标题；第二步调用 upload_image 上传图片并获取 URL；第三步调用 create_draft 创建草稿；最后调用 submit_for_review 提交审核。任何一步失败则中止流程并报告错误。”

• 优点：完美的关注点分离。MCP 团队保障服务的稳定，而业务或场景专家则可以快速迭代 Skill 中的策略，两者互不干扰。

• 挑战：需要对场景有深刻的理解，才能设计出清晰、鲁棒的 SOP。

模式三：“带本地脚本的 Skill”——标准化步骤的便捷实现

在某些情况下，一些标准化的操作逻辑并不适合或不方便放在远端的 MCP Server 中。此时，可以将这些逻辑作为脚本与 SKILL.md 一同打包。

• 核心思想：将一些 与场景强相关、且相对固定的辅助性逻辑 以脚本（Python, Shell 等）或资源（模板文件）的形式打包进 Skill。SKILL.md 则指导模型何时调用这些本地脚本。

• 适用场景：

  • 数据格式转换：一个脚本负责将 MCP 返回的复杂 JSON 转换为用户需要的特定格式的 Markdown 表格。
  • 客户端侧的校验：在调用一个代价高昂的 MCP 工具前，先用本地脚本对参数进行一轮预校验。
  • 使用模板文件：Skill 中包含一个 report_template.md，脚本负责读取模板并填入从 MCP 获取的数据，生成最终报告。
  • 调用 CLI 工具：Skill 中打包了一个特定的 CLI 工具（如 kubectl, terraform），模型通过 bash 调用它来完成与特定系统的交互。

• 例子：一个“代码扫描报告生成” Skill。

  • MCP 工具：code_analysis_mcp 提供一个 run_scan 工具，输入代码库地址，异步返回扫描任务 ID。另有一个 get_scan_results 工具，根据任务 ID 获取原始 JSON 格式的扫描结果。

  • Skill 包：

    • SKILL.md：定义 SOP：“先调用 run_scan 发起扫描，然后轮询 get_scan_results 直到任务完成。获取到结果后，调用本地脚本 python scripts/format_report.py 将 JSON 结果转换为 HTML 报告。”
    • scripts/format_report.py：一个 Python 脚本，负责将扫描结果 JSON 渲染成一个美观的 HTML 文件。

• 优点：灵活性高，可以将一些不适合服务化的逻辑快速实现和分发。

• 挑战：滥用此模式可能导致 Skill 变得“臃肿”，大量业务逻辑耦合在脚本中，使其退化为“难以调试的 Local Tool”，违背了关注点分离的初衷。

何时使用模式三的警戒线

一个好的判断标准是：脚本中的逻辑是否是 通用 的。如果一段逻辑只服务于这个特定场景，且相对稳定，那么放在 Skill 中是合适的。如果这段逻辑可能被多个场景复用，或者需要频繁迭代，那么它更应该被重构为一个独立的 MCP 工具。

五、常见陷阱与反模式

在实践中，由于对三者定位的混淆，很容易陷入一些常见的陷阱。识别并规避这些反模式，是构建一个健康、可扩展的 Agent 工具体系的关键。

陷阱一：万物皆工具，在 description 中堆砌 SOP

这是最常见的误区。开发者为了让模型“更懂”自己的工具，将大量关于“如何使用”、“在什么场景下使用”、“与其他工具如何配合”的逻辑塞进 description 字段。

• 后果：

  • 信息过载：当 Agent 加载多个此类工具时，海量的 description 文本会迅速撑爆上下文窗口，并严重干扰模型的注意力。
  • 规划困难：模型需要从一堆混杂着实现细节和使用逻辑的文本中，艰难地提取出真正的调用 schema，导致规划能力下降。
  • 违反单一职责：description 的核心职责是“描述工具本身的功能”，而非“指导任务流程”。

• 正解：保持 description 简洁、聚焦。将跨工具的、场景级的 SOP 剥离出来，用 瘦 Skill （模式二）来承载。

陷阱二：万物皆 Prompt，在 Agent 指令中硬编码一切

另一种极端是将所有工具的使用手册、SOP、甚至 fallback 逻辑全部写进一个庞大、复杂的 system prompt 中。

• 后果：

  • Agent 强耦合：SOP 与特定的 Agent 实现强绑定，无法在其他 Agent 或项目空间中复用。
  • 维护噩梦：当 SOP 需要更新时，你必须找到并修改所有使用了该 SOP 的 Agent 的 Prompt。
  • 可读性差：一个长达数千字的 system prompt 几乎无法阅读和维护。

• 正解：将 Agent Prompt 还原其核心职责：定义 Agent 的角色、个性和高级目标。将可复用的场景级 SOP 沉淀为 Skill。

陷阱三：把 Skill 当作新的“运行时”

由于 Skill 支持打包脚本，一些开发者会倾向于将大量复杂的业务逻辑、状态管理甚至服务调用直接实现在 Skill 的本地脚本中，把它当作一个便捷的“微服务”或 FaaS 平台。

• 后果：

  • 可观测性灾难：你实际上是在一个无法有效监控和调试的“黑盒”沙箱中运行着复杂的业务逻辑。
  • 性能瓶颈：受限于沙箱的冷启动和资源限制，性能远不及一个真正的长驻服务。
  • 状态管理困难：Skill 的执行是无状态的，任何需要跨步骤保持的状态都极难处理。
  • 逻辑耦合：核心业务逻辑与场景策略耦合在一起，难以独立测试和迭代。

• 正解：坚守 “执行在 MCP，策略在 Skill” 的原则。Skill 中的脚本只应包含轻量级、无状态、与场景强相关的辅助性逻辑（如数据格式化）。核心的、可复用的业务逻辑，必须沉淀到 MCP Server 中。

陷阱四：在 Skill/MCP 中处理用户凭证

一个危险的做法是，将获取用户凭证（如 API Key, Secret）的逻辑设计为工具的一个参数，或在多轮对话中向用户索要。

• 后果：

  • 严重安全风险：敏感凭证在对话历史、日志和模型上下文中暴露，极易泄露。
  • 糟糕的用户体验：每次调用都需要用户手动输入凭证，完全违背了自动化的初衷。

• 正解：凭证管理必须与工具执行分离。

  • 最佳实践：利用平台级的凭证管理机制。例如，通过 AGENT 注入的环境变量，在 MCP Server 端或一个专门的认证服务中，换取访问外部服务所需的真实 Token。
  • 基本原则：模型和 Agent 在任何时候都不应直接接触到用户的长期有效凭证。

六、可落地的实践建议：一个循序渐进的采纳路径

理解了理论和陷阱，如何在你的团队中一步步落地？这里提供一个三步走的渐进式路径，帮助你平滑地从 Local Tool 演进到“MCP + Skill”的理想架构。

第一步：夯实基础——打磨高质量的 Local Tool / MCP

目标：构建稳定、可靠、可观测的原子能力。

• 行动项：

  • 从 Local Tool 开始：在探索一个新场景时，先用本地脚本或函数快速实现核心功能。在这个阶段，优先保证逻辑正确性，并养成良好的日志打印习惯。
  • 服务化封装：当能力趋于稳定，且有复用需求时，立即将其封装为 MCP Server。遵循良好的 API 设计原则：保持接口的原子性和正交性，提供清晰的错误码和信息。
  • 建设可观测性：为你的 MCP Server 配备完善的日志、监控和分布式追踪。这是未来排查一切问题的生命线。
  • 守住执行层：在这个阶段，坚决抵制在 Agent Prompt 中编写复杂 SOP 的诱惑。让 Agent 的职责保持简单：调用工具，并根据结果响应。

第二步：沉淀策略——将隐性知识显性化为“瘦 Skill”

目标：将经过验证的、可复用的任务级 SOP 从 Prompt 和人脑中剥离出来，沉淀为 Skill 资产。

• 行动项：

  • 识别高价值场景：梳理你们团队最高频、最痛点的多步任务，例如“新服务上线检查”、“周报数据自动生成”、“线上告警处理”等。
  • 编写 SKILL.md：为每个场景创建一个 瘦 Skill。在 SKILL.md 中，用清晰的语言描述完成该场景的完整步骤、推荐调用的 MCP 工具、关键参数的填写逻辑，以及常见错误的排查指南。
  • 只打包策略，不打包逻辑：此时的 Skill zip 包中应该只有 SKILL.md 文件。所有执行逻辑依然由第一步构建的 MCP Server 承载。
  • 在小范围验证：在你的团队或项目空间中启用这些 Skill，观察 Agent 的行为是否符合预期，并根据反馈迭代 SKILL.md 的内容。

第三步：按需增强——谨慎引入带脚本的 Skill

目标：处理那些确实不适合在 MCP 中实现的、轻量级的场景辅助逻辑。

• 行动项：

  • 评估必要性：在为 Skill 添加本地脚本前，先问自己一个问题：“这个逻辑是否足够通用，以至于值得被升级为一个独立的 MCP 工具？”如果答案是肯定的，那么它应该被实现在 MCP Server 中。
  • 保持脚本轻量和无状态：只将那些纯粹的、无副作用的辅助功能（如数据格式化、简单的客户端校验、调用模板）作为脚本打包进 Skill。
  • 明确依赖：如果脚本依赖特定的 CLI 工具或库，确保在 SKILL.md 的“前置条件”部分明确声明，或在脚本中提供清晰的检查和安装提示。
  • 定期重构：定期审视你的 Skill 库。如果发现某个脚本被多个 Skill 依赖，或者其逻辑正变得越来越复杂，这通常是一个明确的信号：是时候将它重构为一个独立的 MCP 工具了。

通过这条路径，你可以确保团队的工具体系始终保持在 “执行层稳定，策略层灵活” 的健康状态，避免过早陷入维护复杂 Skill 脚本的泥潭。

七、结语：回归工程本质，做出理性选择

Local Tool, MCP Server, Skill，这三者并非相互替代的竞争关系，而是一个成熟 LLM/Agent 工具体系中，分别位于 执行、连接、策略 三个不同抽象层次的有机组成部分。

• Local Tool 是我们验证想法、打磨核心逻辑的起点，它保证了能力的 可靠性。
• MCP Server 是我们将能力规模化、服务化的关键，它解决了 复用与治理 的问题。
• Skill 则是我们沉淀场景知识、降低使用门槛的载体，它赋予了 Agent “智慧”与“经验” 。

在日常的工程实践中，我们不应被层出不穷的新概念所迷惑，更不必为“是否用上了最新技术”而焦虑。最重要是回归工程的本质：认清当前阶段要解决的核心问题，并选择最适合的抽象层次和工具组合。

对于工程师而言，最务实的路径永远是：先用你最熟悉的工具（Local Tool, MCP）把事情做对、做稳；当“如何用”本身也成为一个值得被管理和复用的复杂问题时，再引入 Skill 这一更高层次的抽象，来封装和分发“用法”和“策略”。这才是构建一个可持续演进的 Agent 生态系统的根本之道。