AI代理：告别MCP服务器，拥抱Markdown文件

本文主张AI代理区分知识与执行问题。知识性任务（如流程、规范）应存储于Markdown技能文件，以节省Token并易于维护。执行性任务（如API调用）则由MCP服务器负责。这种分层架构能显著降低成本，提升AI系统效率与可维护性，同时利用Git进行版本控制。

在Markdown文件而非MCP服务器上运行AI代理的案例

一位风险投资家正在用十二个Markdown文件管理他整个公司。没有Web应用程序。没有工作流引擎。没有编排运行时。只有存储在Git仓库中的结构化文档，它们教会Claude Code 如何起草电子邮件、分类支持工单、准备董事会指标和管理产品发布。

CompanyOS的创始人Brad Feld于2026年2月将其开源，它连接到八个模型上下文协议（MCP）服务器，以访问Gmail、Linear、Help Scout和其他服务的API。但其智能存在于再次流行的Markdown中。每个技能文件都编码了工作流、护栏、语气校准和决策逻辑。MCP服务器只是管道。如果断开它们，技能仍然可以运行。你只是进行复制粘贴而非自动发送。

Feld并非孤身一人。Sentry的David Cramer，他构建了Sentry自己的MCP服务器，直言写道“许多MCP服务器没有存在的必要”，因为它们要么是糟糕的API封装器，要么可以被技能文件取代。

这样的例子还在继续：Supabase开源了一个agent-skills仓库，它将永恒的开发实践与动态API交互分离开来。微软的.NET Skills Executor于三周前发布，它编排SKILL.md文件，将调用MCP工具作为从属层。越来越多的实践者正在发现Júlio Falbo在他广为引用的文章“Markdown是新的API”中记录的内容。GitHub MCP服务器消耗了大约50,000个Token的上下文（后来缩减到大约23,000个），以教导一个代理如何与GitHub交互。一个说明“对这些操作使用gh CLI”的SKILL.md文件在大约200个Token内实现了相同的效果。

一些事情正在改变。开发者正在移除MCP服务器，并用Markdown文件取代它们。这并非因为MCP坏了，而是因为许多MCP服务器被构建来解决错误类型的问题。

两种类型的问题

AI代理执行的每项任务都属于以下两种类别之一：它要么需要知道某事，要么需要做某事。这两种类别之间的混淆正在导致当今代理系统中大部分的架构浪费。

当代理需要知道某事时，你处理的是一个知识问题。编码标准、部署程序、分类工作流、公司政策、API使用模式。这些知识相对稳定。它以数周或数月的时间尺度变化。它可以以自然语言表达。至关重要的是，它可以在不使用任何运行时基础设施的情况下，适应现代大型语言模型的上下文窗口。

当代理需要做某事时，你处理的是一个执行问题。查询数据库、创建GitHub议题、发送电子邮件和阅读Slack频道。执行需要一个运行时。它需要身份验证、网络访问、错误处理和状态管理。这正是MCP设计的目的，并且它能很好地处理这些。

问题在于许多团队为知识问题构建了MCP服务器。有人希望他们的代理了解如何与GitHub交互，因此他们构建或安装了一个MCP服务器，该服务器暴露了几十个用于仓库管理、拉取请求工作流、议题跟踪和CI/CD操作的工具。代理现在可以访问所有内容。它还必须在每次调用时处理一个庞大的工具 schema，仅为了理解可用内容，就消耗了数万个Token，然后才能决定做什么。

一个技能文件，其中写着“使用gh CLI，优先使用squash合并，推送前总是运行测试，并将提交信息格式化为传统提交”，以其上下文窗口预算的一小部分编码了相同的工作流知识。代理已经知道如何使用CLI。它只需要关于你的团队如何使用它的机构知识。

决策框架

可以将此框架视为映射到三个不同问题的三层结构。

第一个问题是代理是否需要知道某事。如果答案涉及编码标准、部署过程、分类工作流、语音和语调指南，或任何形式的机构知识，那么它属于技能文件。Markdown文件。在Git中进行版本控制。像任何其他代码工件一样在拉取请求中进行审查。

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

第三个问题变得有趣。代理是否需要知道如何把事情做好？这是混合情况，在生产系统中最为常见。这里的答案是引用MCP工具的技能。该技能编码了工作流、序列、边缘情况和判断。MCP提供底层的执行层。

Feld的co-support skill是这第三种模式的一个清晰示例。技能文件定义了整个支持分类工作流。它知道如何按严重程度对问题进行分类，对不同客户群使用何种语调，何时升级而非解决，以及在内部备注中包含哪些信息。Help Scout MCP服务器处理API调用、读取对话、发布回复和标记工单。但即使没有MCP服务器，该技能也能工作。在没有API访问的情况下，它仍然可以分类粘贴的客户消息，以正确的语调起草回复，并将其格式化为可供复制的文本。思考能力得以保留。只有管道消失了。

50倍的Token税

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

考虑一个具体的例子。GitHub MCP服务器，作为生态系统中最流行的服务器之一，它暴露了用于仓库管理、文件操作、搜索、议题、拉取请求、代码审查、分支等工具。当代理加载此服务器的工具 schema 时，它会消耗大约23,000到50,000个Token的上下文窗口空间，具体取决于版本。这是代理无法再用于推理实际任务的上下文窗口容量。

一个编码了你的团队GitHub工作流（包括分支命名约定、PR审查要求、CI预期和合并策略）的SKILL.md文件通常消耗200到500个Token。代理以低100倍的上下文消耗获得相同的操作知识。而且，由于技能是一个专注、精选的文档，而不是一个原始的API接口，代理能做出更好的决策。它了解你的团队约定，而不仅仅是GitHub所有可能的API调用。

这并非反对GitHub MCP服务器。存在真正的执行任务，例如创建议题、发布审查评论和合并拉取请求，它们需要API访问。争论在于，加载一个完整的MCP服务器来教代理你的团队如何使用GitHub，就像导入一个完整的数据库驱动程序库来共享几个配置值一样。你正在为知识问题支付基础设施税。

在大规模应用中，这种税会复合。一个连接到十几个MCP服务器的企业代理系统可能仅工具 schema 就消耗200,000到400,000个Token。这占据了大多数模型可用上下文窗口的一半甚至更多，在代理处理单个用户请求之前就被消耗掉了。用技能文件替换知识组件可以为实际推理回收大部分预算。

生产系统的样子

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

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

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

微软的.NET Skills Executor于二月初发布，它在架构中明确了分层。SKILL.md文件定义工作流。执行器在运行时解析依赖关系，包括MCP工具调用。技能是编排层。MCP提供函数调用。这可能是最清晰的信号，表明行业正在趋向于双层模型，而非“MCP包罗万象”的方法。

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

Git优势

技能文件的一个被低估的优势是它们所实现的操作模型。技能文件是纯文本。它们存在于Git中。它们经历拉取请求。它们有 blame 历史、差异视图和分支策略。

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

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

对于管理组织内代理系统的平台工程团队来说，这种操作模型比维护一支由MCP服务器组成、每个服务器都在应用程序代码中编码机构知识的队伍更具可持续性。

周一早上该做什么

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

审计你当前的MCP服务器，并询问，对于它们暴露的每个工具，该工具是解决知识问题还是执行问题。如果一个工具主要是为了教代理如何使用API而不是调用该API而存在，那么它就是提取到技能文件中的候选对象。

从Token成本最高的服务器开始。那些拥有最大工具 schema 的服务器最有可能在其执行能力之外编码了最多的知识。将知识提取到SKILL.md文件中，并将执行工具留在MCP中。

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

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

分层的未来

技能与MCP的讨论不是一场竞争。它是生态系统所需的架构澄清。

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

新兴的双层模型是清晰的。技能以廉价处理、易于版本控制和团队成员可访问的格式提供领域知识。MCP通过适当的身份验证、错误处理和可观测性提供工具执行。最好的代理系统同时使用两者，并具有清晰的边界。

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