ZGI 里同时有 Skills、Tools 和运行时循环。Skill 保存一类任务的做法、约束与配套材料，Tool 提供可以执行的动作，Runtime 负责在权限、隔离和状态边界内把它们跑起来；MCP 则解决客户端怎样发现和调用外部工具、读取资源、取得提示模板。它们经常一起出现，却不在同一个层次。

Skill 不是一段更长的 Prompt

按照 Agent Skills 的公开规范，一个 Skill 至少是一个包含 SKILL.md 的目录。文件里写名称、用途和执行说明，还可以带上脚本、参考资料、模板等资源。普通 Prompt 更像当前对话中的一次要求，Skill 则把重复任务沉淀成可以按需加载的任务包。

以合同字段抽取为例，Skill 可以规定要识别哪些字段、按什么顺序检查、遇到缺失值怎么处理、最终交付什么格式，也可以引用校验脚本和字段表。它回答的核心问题是“这类任务该怎么完成”，不是“系统现在能调用哪些接口”。

Tool 才是执行动作

Tool 是更小

的一层执行契约。查数据库、读取文件、调用业务 API、发送消息，都可以封装成 Tool；名称、用途和输入结构告诉模型该在什么情况下调用，以及参数应该怎样组织。Tool 可以由系统内置，也可以来自插件或 MCP Server。

所以，Skill 和 Tool 的分工可以压成一句话：Skill 负责“怎么做”，Tool 负责“动手做”。没有 Tool，Skill 仍能提供分析步骤和输出规范，但不能凭空获得数据库写入、文件修改或消息发送能力。

MCP 管的是连接方式

MCP 是一套客户端—服务端协议。官方架构中，Server 可以暴露 Tools、Resources 和 Prompts，Client 通过统一消息完成能力协商、列表发现、读取或调用。它处理的是“外部能力如何接进来”，并不负责为某个业务任务编排完整步骤。

三者的关系并不绕：执行 Skill 的 Agent 或 Runtime，可以调用通过 MCP 接入的 Tool；同一个 MCP Tool 也可以脱离 Skill，被 Agent 直接调用。Skill 能复用，MCP 能连接，Tool 能执行，运行时再决定这次调用是否获准、在哪里运行、失败后留下什么记录。

层次	主要回答的问题
Skill	这类任务怎么完成
Tool	当前能执行什么动作
MCP	外部能力怎么被发现和调用
Runtime	动作在什么边界内运行

Skill 不是安全边界

这是最容易混淆的一点。即使 Skill 写了“只读”或列出了允许使用的工具，也不能单靠这份说明证明执行安全；Agent Skills 规范里的 allowed-tools 字段目前仍是实验项，不同实现的支持程度可能不同。

真正限制动作范围的，仍是工具授权、输入校验、工作区与租户边界、Sandbox、人工审批和运行日志。MCP 统一了调用方式，也不会自动替接入方完成这些控制。协议通了，只能说明能力接上了，不能说明它已经适合进入生产。

放到实际系统里怎么看

ZGI 的 Skill 包含解析后的定义、引用文件和脚本路径，Tool Manager 管理内置与动态 Provider，Chat Runtime 还保留有界 Skill Loop、结构化工具载荷和 Trace。这里说的是代码快照，不代表所有部署都已经启用相同配置。

判断一项能力该放在哪层，可以直接看它解决的问题：反复变化的操作流程适合写进 Skill；需要统一接入外部系统时看 MCP；单个可执行能力落到 Tool；涉及权限、隔离、审批和追踪时，则已经进入 Runtime。层次分清后，失败时才能判断是方法、接口，还是运行时出了问题。