一个真实的困惑
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 经常在不相关场景被加载，可以在描述里加“负向触发”：“不要用于简单的数据浏览（那个用>