用 Markdown 文件替代 MCP 服务器，成本降百倍

一位风险投资人用 12 个 Markdown 文件运行着整个公司。没有 Web 应用，没有工作流引擎，没有编排运行时。只有 Git 仓库里的结构化文档，它们教会 Claude Code 如何起草邮件、处理支持工单、准备董事会指标和管理产品发布。

创始人 Brad Feld 在 2026 年 2 月开源的 CompanyOS，连接了八个模型上下文协议（MCP）服务器来访问 Gmail、Linear、Help Scout 等服务的 API。但真正的智能存在于这些 再次流行起来 的 Markdown 文件中。每个技能文件编码了工作流、安全护栏（Guardrails）、语气校准和决策逻辑。MCP 服务器只是管道。断开它们，技能依然能运行——你只需要手动复制粘贴，而不是自动发送。

Feld 并不孤单。Sentry 的 David Cramer 曾为 Sentry 构建 MCP 服务器，他 直言不讳地写道：“许多 MCP 服务器根本没必要存在”，因为它们要么是糟糕的 API 包装器，要么完全可以用一个技能文件替代。

例子还在增加：Supabase 开源了一个 智能体技能仓库，将稳定的开发实践与动态 API 交互分离。微软的 .NET Skills Executor 三周前发布，它编排 SKILL.md 文件，将 MCP 工具作为下层调用。越来越多的实践者发现了 Júlio Falbo 在其广为引用的文章 《Markdown 是新 API》 中记录的现象。GitHub MCP 服务器消耗了约 5 万 token 的上下文（后来缩减到 2.3 万）来教智能体如何与 GitHub 交互。而一个写着“用 gh CLI 执行这些操作”的 SKILL.md 文件，只用大约 200 token 就达到了相同效果。

某种转变正在发生。开发者正在拆除 MCP 服务器，用 Markdown 文件替换它们。不是因为 MCP 有问题，而是因为许多 MCP 服务器被用来解决错误类型的问题。

两类问题

AI 智能体执行的每个任务都属于两类之一：它要么需要 知道 某事，要么需要 执行 某事。混淆这两类问题是当前智能体系统中大多数架构浪费的根源。

当智能体需要 知道 某事时，你面对的是知识问题。编码规范、部署流程、工单处理工作流、公司政策、API 使用模式。这些知识相对稳定，变化周期是几周或几个月，可以用自然语言表达，而且关键的是，它们能直接放入现代大语言模型的上下文窗口，无需任何运行时基础设施。

当智能体需要 执行 某事时，你面对的是执行问题。查询数据库、创建 GitHub issue、发送邮件、读取 Slack 频道。执行需要运行时，它需要身份验证、网络访问、错误处理和状态管理。这正是 MCP 的设计目标，而且它做得很好。

问题在于，许多团队为知识问题构建了 MCP 服务器。有人想让智能体理解如何与 GitHub 交互，于是他们构建或安装了一个 MCP 服务器，暴露几十个工具用于仓库管理、PR 工作流、issue 跟踪和 CI/CD 操作。智能体现在能访问一切，但每次调用时它都必须处理庞大的工具模式，消耗数万 token 才能理解有哪些可用选项，然后才能决定做什么。

一个写着“用 gh CLI，优先使用 squash merge，推送前务必运行测试，提交信息按约定格式”的技能文件，用一小部分上下文窗口预算编码了相同的工作流知识。智能体已经知道如何使用 CLI，它只需要了解 你的团队 如何使用它的制度性知识。

决策框架

把这个框架想象成三层，对应三个不同的问题。

第一个问题是智能体是否需要 知道 某事。如果答案涉及编码规范、部署流程、工单处理工作流、语气语调指南或任何形式的制度性知识，这属于技能层。用 Markdown 文件，在 Git 中版本控制，像其他代码工件一样在 PR 中评审。

第二个问题是智能体是否需要 执行 某事。如果答案需要调用 API、查询数据库、读取消息队列或在运行时与任何外部系统交互，这属于 MCP 层。一个运行中的服务器，具备身份验证、错误处理和适当的可观测性（Observability）。

第三个问题最有趣：智能体是否需要 知道如何很好地执行某事？这是混合情况，也是生产系统中最常见的。这里的答案是引用 MCP 工具的技能。技能编码工作流、顺序、边界情况和判断逻辑，MCP 提供底层的执行层。

Feld 的 协同支持技能 是第三种模式的清晰例子。技能文件定义了完整的支持工单处理工作流：知道如何按严重性分类问题、对不同客户群体使用什么语气、何时升级或解决、内部备注应包含哪些信息。Help Scout MCP 服务器处理 API 调用、读取对话、发布回复和标记工单。但即使没有 MCP 服务器，技能依然有效。没有 API 访问时，它仍然能处理粘贴的客户消息，用正确的语气起草回复，并格式化为可复制的文本。思考过程保留了下来，只有管道消失了。

50 倍 token 税

分层错误的成本并非抽象，它直接体现在你的上下文窗口预算中，进而影响 API 账单和智能体的推理质量。

看一个具体例子。GitHub MCP 服务器 是生态中最受欢迎的之一，它暴露了仓库管理、文件操作、搜索、issue、PR、代码审查、分支等工具。当智能体加载这个服务器的工具模式时，大约消耗 2.3 万到 5 万 token 的上下文窗口空间，具体取决于版本。这些容量智能体无法再用于推理你的实际任务。

“一个编码你团队 GitHub 工作流的 SKILL.md 文件……通常只需 200 到 500 token。智能体获得相同的操作知识，上下文消耗减少 100 倍。”

一个编码你团队 GitHub 工作流的 SKILL.md 文件，包括分支命名约定、PR 审查要求、CI 期望和合并策略，通常只需 200 到 500 token。智能体获得相同的操作知识，上下文消耗减少 100 倍。而且因为技能是聚焦的、精心设计的文档，而非原始 API 表面，智能体能做出更好的决策。它知道你团队的约定，而不仅仅是 GitHub API 调用的所有可能性。

这不是反对 GitHub MCP 服务器的论点。确实存在真正的执行任务，比如创建 issue、发布审查评论、合并 PR，这些需要 API 访问。论点在于，加载完整的 MCP 服务器来教智能体 你的团队如何使用 GitHub，就像导入整个数据库驱动库来共享几个配置值。你为知识问题支付了基础设施税。

在规模上，这种税会叠加。一个连接十几个 MCP 服务器的企业智能体系统，可能仅工具模式就消耗 20 万到 40 万 token。这占用了大多数模型可用上下文窗口的一半甚至更多，在智能体处理单个用户请求之前就烧掉了。用技能文件替换知识组件，可以回收大部分预算用于实际推理。

生产系统的样子

早期采用者中出现的模式遵循一致的结构。

Feld 的 CompanyOS 运行 12 个技能文件，总计约 2000 行 Markdown，连接 8 个 MCP 服务器。技能处理从邮件语气校准到使用 丰田五问法 进行根因分析的一切。每个技能都有“独立模式”，无需任何 MCP 连接即可工作。MCP 服务器严格用于 API 执行：发送邮件、查询数据库、搜索工单系统。

Supabase 的开源智能体技能仓库 采用类似方法。技能文件编码跨版本稳定的开发实践，比如数据库迁移模式、边缘函数部署约定和测试策略。这些由处理动态 API 文档和实时模式内省的 MCP 服务器补充。边界清晰：如果知识是永恒的，就放入技能；如果需要实时连接，就通过 MCP。

微软的 .NET Skills Executor 在 2 月初发布，其架构明确体现了分层。SKILL.md 文件定义工作流，执行器在运行时解析依赖，包括 MCP 工具调用。技能是编排层，MCP 提供函数调用。这可能是最清晰的信号，表明行业正在向两层模型收敛，而非一切皆 MCP 的方法。

Anthropic 自家的 Claude Code 实现内部也遵循此模式。Claude Code 附带的技能系统使用结构化 Markdown 文件编码文档创建、代码生成和工具使用的最佳实践。这些技能文件在需要执行时引用 MCP 工具，但将工作流逻辑保留在 Markdown 中，用户可以版本控制、评审和定制。

Git 优势

技能的一个被低估的好处是它们启用的操作模型。技能文件是纯文本，存放在 Git 中，经过 PR 流程，有追溯历史、差异视图和分支策略。

这比看起来更重要。当智能体的行为编码在 MCP 服务器中时，改变行为意味着修改服务器代码、重新部署，并希望有足够的测试覆盖。当行为编码在技能文件中时，改变它意味着编辑 Markdown 文档并提交更改。反馈循环是几分钟，而非几小时。而且更改对团队中的每个人都是可见的，格式无需理解服务器的实现语言就能阅读。

Feld 的 CompanyOS 充分利用了这一点。他的邮件语气校准规则，即决定协同通信如何为不同收件人调整语调的部分，是 Markdown 文件中的一个段落。当他想改变系统与投资者和客户的沟通方式时，他编辑一段话并提交。无需部署，无需重启，没有破坏 API 集成的风险。

对于跨组织管理智能体系统的平台工程团队，这种操作模型比维护一队将制度性知识编码在应用代码中的 MCP 服务器，可持续性要高得多。

周一早上做什么

如果你是平台工程师或团队负责人，正在评估智能体架构，这里有一个实用的起点。

审计你当前的 MCP 服务器，对每个暴露的工具问：这个工具解决的是知识问题还是执行问题？如果一个工具主要目的是教智能体如何使用 API，而非调用该 API，它就是提取到技能文件的候选。

从 token 成本最高的服务器开始。工具模式最大的服务器很可能编码了最多的知识以及执行能力。将知识提取到 SKILL.md 文件中，将执行工具留在 MCP 中。

采用 Feld 使用的独立测试。每个技能即使没有 MCP 连接也应产生有用输出。如果断开 MCP 服务器使技能完全失效，你可能有一个属于 MCP 的执行问题。如果技能仍然生成正确的分析、建议或草稿，你就验证了知识层已正确分离。

将技能与你的应用代码一起在 Git 中版本控制。将它们视为一等工件，采用与基础设施配置相同的评审流程。编码业务逻辑、合规要求或安全策略的技能文件，应得到与 Terraform 模块或 Kubernetes 清单相同的严谨对待。

分层的未来

技能与 MCP 的讨论不是竞争，而是生态系统需要的架构澄清。

MCP 赢得了协议战争。超过 3 万个服务器在注册表中被索引。每个主要云提供商、工具供应商和 AI 公司都支持它。这不会改变。改变的是认识到 MCP 是为工具执行设计的，将其作为智能体需要知道的一切的唯一机制，会创建昂贵、脆弱且难以维护的系统。

“智能体不需要另一个编排层。它需要领域知识，以它已经理解的格式。对于团队今天解决的大多数知识问题，Markdown 文件是比运行中服务器更好的架构。”

新兴的两层模型是清晰的。技能以廉价处理、易于版本控制且每个团队成员都可访问的格式提供领域知识。MCP 以适当的身份验证、错误处理和可观测性提供工具执行。最好的智能体系统两者都用，并在它们之间有清晰的边界。

Feld 的 12 个 Markdown 文件不会取代企业 MCP 基础设施。但它们展示了一个超越任何个体实现的原则。智能体不需要另一个编排层，它需要领域知识，以它已经理解的格式。对于团队今天解决的大多数知识问题，Markdown 文件是比运行中服务器更好的架构。