一场关于AI代理架构的认识论转变正在开发者社区展开；风险投资家Brad Feld用十二个Markdown文件运营整个公司，无需Web应用程序或工作流引擎，仅凭Git仓库中的结构化文档就能指导Claude Code完成电子邮件起草、工单分类、董事会指标准备和产品发布管理。这个开源项目CompanyOS虽然连接了八个模型上下文协议（MCP）服务器以访问Gmail、Linear等第三方API，但其核心智能存在于Markdown文件之中。 这不是孤立现象。Sentry工程师David Cramer开发MCP服务器后指出"许多MCP服务器没有存在的必要"。Supabase开源了agent-skills仓库，将开发实践与API交互分离。微soft的.NET Skills Executor专门编排SKILL.md文件，将MCP工具调用作为从属层。这些案例表明一种新的架构范式正在形成。 问题的根源在于对AI代理任务的认识不足。专业人士将代理任务分为两类：知识问题和执行问题。知识问题涉及编码标准、部署程序、工作流、公司政策等相对稳定的信息，以自然语言表达，适配现代大型语言模型的上下文窗口。执行问题包括数据库查询、GitHub议题创建、电子邮件发送等需要实时运行、身份验证、网络访问和错误处理的操作。 当前的普遍做法存在架构浪费。许多团队为知识问题构建MCP服务器，导致每次调用都处理庞大的工具schema。GitHub官方MCP服务器曾消耗约50000个Token来教导代理与GitHub交互，而一个简明的SKILL.md文件仅需200个Token，降幅达99.6%。这种资源浪费直接转化为成本上升和效率下降。 分离知识与执行的优势逐渐显现。Markdown技能文件可通过Git进行版本控制，便于追踪变更、协作编辑和快速回滚。MCP服务器则专注于管理身份验证、API调用、数据访问等执行层面的工作。这种分工使系统更模块化、可维护性更强、扩展性更优。即使MCP服务器断开连接，技能文件仍可独立运行，只是从自动执行降级为复制粘贴操作，确保系统的韧性。 业界实践的演进反映了认识的深化。从CompanyOS到Supabase，从Sentry到微软，开发者正在用实际行动验证该架构理念。结构化的自然语言文档正在成为AI系统的核心知识库，而不再依赖复杂的中间件。这一转变不是否定MCP技术，而是重新界定其适用边界。
从"把一切装进服务器"到"让知识回到文档、让执行回到协议"，此转向并非否定工具化，而是强调回归问题本质：用更轻的方式表达稳定规则，用更强的工程能力保障真实执行。对正在推进智能代理落地的机构而言，厘清边界、沉淀资产、强化治理，将成为决定系统能否长期可用、可管、可扩展的关键一步。