实战：同一个 Markdown 检查器的 Skill、Plugin 与 MCP 三种实现
内容提要
本文以同一Markdown检查器为例，对比Skill、Plugin和MCP三种实现方式。三者共享相同输入、规则和JSON输出契约，区别在于：Skill由模型执行规则，Plugin在Hermes进程内运行，MCP在独立子进程中执行。文章强调选择时应考虑确定性、权限、进程和协议成本，并指出三者是替代方案而非组合依赖。
延伸解读
三种实现的本质差异
本文通过同一Markdown检查器对比Skill、Plugin和MCP，核心差异在于规则执行位置：Skill由大模型推理执行，Plugin在Hermes进程内运行Python函数，MCP则在独立子进程中运行。这决定了确定性、权限和协议成本的不同。选择时应根据需求权衡：需要语义判断可选Skill，追求确定性和低延迟可选Plugin，需要跨语言或跨宿主复用则选MCP。
确定性：模型生成与代码执行的差距
Plugin和MCP共享同一份audit_core.py，能保证逐字段一致的输出；而Skill依赖模型生成，即使目标JSON相同，也无法保证每次逐字一致。因此，对输出格式有严格要求的场景，应优先考虑Plugin或MCP。测试时，Plugin和MCP可用单元测试验证，Skill则只能检查是否符合JSON Schema和语义。
权限与安全边界
Plugin一旦导入即成为Hermes进程内的可信代码，拥有较高权限，但Capability Consent不等于操作系统沙箱；MCP虽在独立进程运行，提供依赖隔离，但子进程仍继承配置允许的环境和权限，并非自动安全沙箱。选择时需评估对第三方代码的信任程度，以及是否需要隔离依赖或限制权限。
成本考量：进程与协议开销
Plugin在进程内调用，开销最小；MCP需要启动子进程、进行stdio通信和协议序列化，成本更高。但MCP带来跨语言和跨宿主复用的优势。文章强调三者是替代方案而非组合依赖，不应同时安装。实际选择应基于具体需求，如是否需要独立环境、是否被多个宿主复用等。
Q&A
Skill、Plugin 和 MCP 三种实现方式在运行位置和确定性上有什么区别？
Skill 由大模型在模型上下文中执行规则，确定性较低；Plugin 在 Hermes 进程内运行 Python 处理函数，确定性高；MCP 在独立子进程中运行，确定性高且可跨宿主复用。
为什么 Plugin 和 MCP 使用相同的 audit_core.py？
为了公平比较，Plugin 和 MCP 都复制同一份 audit_core.py，这是一个纯函数，不依赖 Hermes 或 MCP，只接收文本并返回 JSON 兼容字典，从而排除算法差异，只比较封装和调用边界。
Skill 实现中，模型如何获取检查规则？
Hermes 扫描 SKILL.md 的元数据头，将名称和描述放入系统提示词索引；模型匹配任务后调用 skill_view 工具，完整规则作为工具结果进入对话，然后由模型执行检查。
Plugin 实现中，工具是如何注册和调用的？
Plugin 通过 plugin.yaml 声明，在 register(ctx) 中调用 ctx.register_tool 注册工具，包含名称、schema 和处理函数。调用时，工具执行器按名称从作用域注册表分派到处理函数，处理函数调用 audit_markdown_text 并返回 JSON。
MCP 实现中，工具名为什么带前缀？
MCP 工具注册时使用 mcp__server__tool 格式，例如 mcp__markdown_audit__audit_markdown，以明确服务器和工具边界，避免与其他工具冲突。
如何验证 Plugin 和 MCP 的输出符合统一契约？
使用 test_contract.py 测试，对同一示例输入调用 audit_markdown_text，断言输出与预期 JSON 完全一致。Plugin 和 MCP 都使用同一份 audit_core.py，因此输出确定；Skill 则检查是否符合 JSON Schema 和语义。
选择 Skill、Plugin 还是 MCP 时，应该考虑哪些因素？
考虑规则是否依赖语言理解且允许少量输出差异（选 Skill）；是否需要高频、确定、低延迟且信任进程内代码（选 Plugin）；是否需要独立依赖、跨语言或被多个宿主复用（选 MCP）。三者是替代方案，不应同时安装。
