一个真实的困惑2026 年AI Coding 的贡献率在头部团队已经超过 90%。菜鸟网络的数据显示他们的 AI 生成代码占比从 10% 一路涨到 90%但一个反直觉的事实是需求交付周期只缩短了约 10%。编码自动化并没有等比例地加速交付。原因很简单编码只占需求交付链路的 30% 左右剩下的需求澄清、方案设计、测试用例、联调、部署、验收每一步都还在等人推动。人成了端到端流程里的瓶颈。这意味着会写 Agent 调用的代码和能交付一个真正跑通的 Agent 应用是两件完全不同的事。这篇文章想聊的是后者当你把 MCP 工具、Skill 体系和端到端交付流程拼在一起时会遇到什么以及怎么解决。一、MCP 工具别把它当成“更高级的 Function Calling”MCP 和 Function Calling 的关系很多人的理解是错的。Function Calling 是模型在单次请求中“决定调什么”MCP 是工具能力的标准化接入层。用现实店舖打比方Skill 是知道怎么干的店員MCP 是货架和通道的访问权。店員再懂没有货架也拿不到东西。MCP Server 的工程现实一个生产可用的 MCP Server远不止把函数包一层。TypeScript SDK 的官方示例里每个工具定义包含五个必填字段name、description、inputSchema、outputSchema、execute。关键设计原则有三条错误要用返回值表达不要抛异常。 MCP Server 的 execute 函数应当返回人类可读的错误信息而不是抛出异常让上层崩溃。比如删除一个不存在的 TODO返回 “TODO with id 5 not found.”而不是 throw new Error()。模型能理解这段文字并据此调整策略。Schema 是模型能看到的唯一接口文档。 inputSchema 定义参数类型和必填项outputSchema 定义返回结构。如果 schema 写得含糊模型就会乱传参数。把每个 MCP 工具当成给一个“很听话但不会猜”的实习生写的 API 文档。工具结果要有稳定的标识符。 OpenAI 的 MCP 构建指南明确指出返回结构化结果时使用稳定 ID让后续工具调用能引用同一条记录。不要返回一堆没有主键的数据。MCP 的战略位置AWS 的 Agentic AI 框架指南给出了一个清晰的分工建议MCP 作为生产环境工具集成的首选协议框架原生工具留给快速原型和非关键场景。理由是可互操作性和未来灵活性——MCP 工具可以在不同 Agent 框架之间迁移框架原生工具则绑定在特定生态里。但 MCP 不解决“工具设计得好不好”。一个描述含糊的 MCP Server和一个描述含糊的 Function Calling 工具一样会让模型乱调。二、Skill 体系把“某人会做”变成“谁都能做”Skill 的本质不是文件格式。它的价值在于把某位同事脑子里的程序性知识变成可发现、可加载、可共享的能力包。渐进披露为什么你的 Agent 上下文总是不够用Agent 的上下文窗口看起来很宽裕但 System Prompt、历史会话、工具定义、工具调用结果、文件内容全都在抢这块空间。长程任务跑到一半上下文就爆了。Skill 的渐进披露机制就是为此设计的。系统提示词里只放 Skill 的名称和描述用 XML 格式挂在 available_skills 里。Agent 判断需要某个 Skill 时才通过工具调用加载 SKILL.md 的详细指令。如果指令里引用了参考文档或脚本Agent 在真正需要时才去读取。这意味着 Skill 的激活本身会消耗 1-2 步工具调用。description 写得准不准直接决定 Token 消耗和响应质量。误触发是浪费漏触发是能力缺失。写 Skill 的两个关键Description 决定“什么时候用”。 好的描述要同时回答三个问题能做什么、包含哪些核心能力、用户说什么话时应该触发。知乎专栏的对比很直观“管理 Linear 项目工作流包括迭代规划、任务创建和状态跟踪。当用户提到’迭代’、‘Linear 任务’、项目规划’时使用”远比 “Helps with projects” 有效。如果你的 Skill 经常在不相关场景被加载可以在描述里加“负向触发”“不要用于简单的数据浏览那个用>