AI Agent 能力调用方式Tool、MCP、Skill 到底怎么被调用在 AI Agent 系统里Tool、MCP、Skill经常被一起讨论。真正容易混淆的地方不是它们的概念定义而是模型到底是怎么“调用”这些能力的Agent 又在中间负责什么核心原则可以先记住一句模型负责决策Agent 执行器负责调用外部能力。也就是说模型通常并不直接操作文件、数据库、浏览器、Shell 或第三方服务。模型更多是生成一个结构化调用意图比如“调用哪个工具、传什么参数”。真正执行动作的是 Agent Runtime、Tool Executor、MCP Client 或 Skill Executor。1. 基础调用链一个标准 Agent 调用链大致如下用户输入 ↓ Agent 整理上下文、可用工具、系统规则 ↓ 模型判断是否需要调用外部能力 ↓ 模型通过 Function Calling 输出 tool call ↓ Agent 校验 tool name 和 arguments ↓ Agent 路由到对应执行器 ↓ 执行器调用本地函数、MCP Server、Skill 脚本或 Shell ↓ 执行结果返回模型 ↓ 模型继续推理或生成最终回答所以“模型调用工具”这句话更准确的表达是模型生成工具调用请求Agent 负责执行这个请求。下面按不同能力来源拆开看。2. Local Tool本地 Tool 调用Local Tool 是最直接的一类工具。它通常注册在 Agent 的 Tool Registry 里由 Agent 本地执行。常见能力包括文件读取与写入本地数据库查询HTTP 请求本地检索服务浏览器自动化图片生成Shell 命令封装调用方式通常是模型通过 Function Calling 选择 Local Tool ↓ Agent 根据 Tool Registry 找到对应实现 ↓ Agent 在本地进程或本地服务中执行 ↓ 结果返回模型例如模型可能输出{tool:read_file,arguments:{path:package.json}}Agent 收到后不是让模型自己读文件而是由本地执行器读取文件再把内容返回给模型。Local Tool 的特点是工具实现直接归 Agent 环境管理调用链短适合本地能力和内部服务。3. MCP Tool远程能力接入MCP Tool 本质上也是 Tool只是它的能力来源不是 Agent 本地函数而是 MCP Server。MCP全称是 Model Context Protocol主要解决的问题是外部系统如何以标准方式把能力暴露给 Agent调用链通常是MCP Server 暴露工具列表和 schema ↓ Agent 通过 MCP Client 获取这些工具 ↓ 模型看到 MCP Tool 的 schema ↓ 模型通过 Function Calling 调用某个 MCP Tool ↓ Agent 通过 MCP Client 把请求转发给 MCP Server ↓ MCP Server 执行真实操作 ↓ 结果返回 Agent再返回模型例如 GitHub、Slack、Notion、Excel、数据库系统都可以通过 MCP 暴露能力。模型看到的仍然是一个个 tool schema但真正执行发生在远程或外部系统中。MCP Tool 的特点是模型仍通过 Function Calling 调用工具但 Agent 需要通过 MCP Client 转发请求。4. Skill Tool企业级 Agent 主流方式在很多企业级 Agent 系统中Skill 不只是SKILL.md说明书而是会被注册成标准 Tool。这类 Skill 通常代表一个业务能力比如生成财务分析报告查询客户画像执行订单审核生成投标文件调用内部审批流程完成某个固定业务 SOP调用链通常是业务 Skill 注册为标准 Tool ↓ 模型通过 Function Calling 调用 Skill Tool ↓ Agent 路由到 Skill Executor ↓ Skill Executor 执行内部实现 ↓ 内部实现可能是 Python、Docker、RPC、工作流引擎或内部服务 ↓ 执行结果返回模型这里的关键点是Skill 内部怎么实现对模型是透明的。模型只知道有一个工具比如{tool:generate_financial_report,arguments:{company:A 公司,period:2026 Q2}}至于这个 Skill 内部是跑 Python 脚本、启动 Docker、调用 RPC还是编排多个服务模型并不需要知道。这种方式适合企业场景因为它可以把复杂业务流程封装成稳定接口让模型只负责判断“什么时候用这个 Skill、参数是什么”。Skill Tool 的特点是Skill 被工具化模型通过 Function Calling 直接调用业务复杂度封装在 Skill Executor 里。5. Skill BashCode Agent 常见方式在代码类 Agent 中Skill 的形态经常不同。它不一定注册成一个独立 Tool而是作为一组任务说明、脚本和约束存在。例如一个 Skill 目录里可能有SKILL.md scripts/ templates/ references/调用链通常是Agent 判断任务匹配某个 Skill ↓ 模型阅读 SKILL.md ↓ 模型理解 Skill 的用途、流程和约束 ↓ 模型通过 Function Calling 调用 Bash Tool ↓ Agent 在本地 Shell 中执行命令 ↓ 命令可能是 python、git、pytest、npm、docker 等 ↓ 结果返回模型这里不是模型直接调用 “Skill Tool”而是Skill 指导模型怎么做Bash Tool 负责承接具体执行。比如某个 PDF Skill 要求“生成后必须渲染检查”模型读完SKILL.md后可能会调用 Bash Tool 执行python render_pdf.py output.pdf所以在 Code Agent 里Skill 更像“专业操作手册 附带脚本资源”。模型先读懂规则再通过 Shell、文件工具、测试工具等完成任务。Skill Bash 的特点是Skill 不一定是 Function Calling 目标而是影响模型如何使用 Bash 和其他 tools。6. Prompt Skill早期方案Prompt Skill 是更早期的一类实现方式。它不依赖标准 Function Calling而是让模型按照约定在自然语言里输出特殊指令。例如[EXEC] python analyze.py data.csv或Action: run_script Input: analyze.py data.csvAgent 再通过正则、状态机或自定义解析器识别这些文本决定执行什么脚本。调用链通常是模型阅读 Prompt Skill 规则 ↓ 模型在自然语言中输出特殊格式指令 ↓ Agent 解析这些指令 ↓ Agent 执行对应脚本或服务 ↓ 结果返回模型这种方式的问题是它高度依赖模型输出格式。一旦模型多写、少写、格式错乱Agent 就可能解析失败。因此在现代 Agent 系统中Prompt Skill 正逐渐被 Function Calling、Tool Registry 和结构化调用方式替代。Prompt Skill 的特点是实现简单但鲁棒性较弱不适合复杂或高可靠场景。7. 五种方式对比类型模型调用方式Agent 执行方式典型场景Local ToolFunction Calling本地函数或本地服务文件、HTTP、数据库、本地检索MCP ToolFunction CallingMCP Client 转发到 MCP Server第三方服务、外部系统、远程工具Skill ToolFunction CallingSkill Executor 执行业务封装企业业务流程、标准 SOPSkill BashFunction Calling 调用 BashShell 执行脚本或系统命令Code Agent、自动化开发、测试Prompt Skill自然语言特殊指令正则或状态机解析后执行早期 Agent、轻量原型从调用层面看最重要的差异不是名字而是模型是否通过 Function Calling 发起结构化调用Agent 把调用路由到哪里Skill 是作为 Tool 暴露还是作为上下文规则影响模型外部能力是本地实现还是通过 MCP Server 实现8. 总结如果从模型和 Agent 的分工看可以这样理解模型判断要不要调用能力、调用哪个能力、传什么参数 Agent校验、路由、执行、回传结果 Tool承接结构化调用 MCP把远程或外部系统包装成 Tool Skill Tool把业务能力包装成 Tool Skill Bash让模型读 Skill 规则后通过 Bash 执行脚本 Prompt Skill让模型输出约定文本由 Agent 解析执行所以Tool、MCP、Skill 不应该只按“概念区别”理解更应该放到 Agent 调用链里看Tool 是调用接口MCP 是外部工具接入协议Skill 可以是被工具化的业务能力也可以是指导模型使用工具的方法包。这也是为什么在不同 Agent 系统里Skill 的含义会不一样企业 Agent 更常见的是Skill Tool代码 Agent 更常见的是Skill Bash而早期系统里还会看到Prompt Skill。