1. 从一次Agent 突然变傻的排查说起先说个我亲身经历的事。去年帮一个团队调一个基于大模型的自动化助手功能是帮运营同学自动整理竞品资料、生成周报、顺手把数据填进表格。Demo 阶段一切正常演示的时候行云流水老板看了直点头。结果上线第三天运营同学反馈它今天不查数据库了直接编了个数字给我。我第一反应是模型抽风换了更强的模型问题依旧。后来把日志翻出来逐条看才发现真正的原因那天我们调整了工具描述tool description的措辞把查询订单表改成了获取订单信息模型理解成了从上下文里找订单信息于是它压根没发起工具调用直接凭记忆编了一个。工具还在能力却消失了。这件事让我彻底想明白一个道理Agent 的能力不是模型自带的而是被接出来的。模型本身只会做一件事——根据上下文预测下一个 token。它能查天气、能读文件、能操作浏览器靠的全是外部挂载的能力。而这些能力怎么挂、挂什么、挂得对不对直接决定了 Agent 是真能干还是看起来很能干。这篇就围绕三个关键词展开工具调用Function Calling / Tool Calling、MCPModel Context Protocol、Skill。这三个词最近在 Agent 开发圈子里出现频率极高但很多人把它们混为一谈或者只知道概念不知道边界。我会从能力从哪来这个根问题出发把三者的定位、关系、实操细节和踩坑经验讲透。不管你是刚接触 Agent 开发的新手还是已经在搭框架的老手应该都能从中找到能直接用的东西。2. 工具调用Agent 能力的第一层地基2.1 工具调用到底解决了什么问题大模型有个天生的短板它的知识截止到训练数据的时间点而且它无法主动与外部世界交互。你问它今天北京天气怎么样它只能告诉你我无法获取实时信息。这不是它笨是它的运行机制决定的——它只是一个文本进、文本出的函数。工具调用就是在这个函数外面开了一扇门。开发者预先定义好一批工具每个工具包含名称、描述、参数结构。模型在对话过程中如果判断需要用到某个工具就输出一段结构化的调用请求通常是 JSON由外部程序执行再把结果塞回上下文模型继续往下推理。举个最朴素的例子。你定义一个工具叫get_weather参数是city。用户问上海今天热不热模型输出{ name: get_weather, arguments: { city: 上海 } }你的程序拿到这个 JSON去调天气 API把返回的32度晴塞回对话模型再生成上海今天 32 度挺热的注意防晒。整个过程里模型负责决策要不要调、调哪个、传什么参数你的代码负责真正去执行。这就是工具调用的本质把模型的语义理解能力和外部程序的执行能力用一套结构化协议对接起来。2.2 工具描述为什么比工具本身还重要回到开头那个事故。工具代码一行没改只是描述措辞变了Agent 就罢工了。这说明一个反直觉的事实在工具调用里描述的质量往往比实现的质量更影响成功率。模型决定调不调工具靠的是读描述。描述写得含糊模型就犹豫描述写得和用户意图对不上模型就选错工具描述里没写清楚参数格式模型就传错参数。我见过太多团队工具函数写得漂漂亮亮描述就一句查询数据然后抱怨模型不好用。我的经验是一个好的工具描述应该包含四要素做什么一句话说清功能动词开头比如根据城市名查询当前天气。什么时候用给出触发场景比如当用户询问天气、温度、是否下雨时使用。参数含义每个参数说明类型、格式、示例尤其是枚举值要列全。边界说明什么情况下不该用比如仅支持中国大陆城市其他地区返回错误。下面是一个对比左边是常见的敷衍版右边是我实际项目里用的可用版维度敷衍版可用版名称queryget_order_by_id描述查询订单根据订单 ID 查询订单详情包含金额、状态、下单时间。当用户提供订单号或询问某笔订单情况时使用。仅支持查询不支持修改。参数idorder_id (string)订单编号格式为 18 位数字例如 202405171234567890返回订单信息返回 JSON字段包括 order_id、amount、status、created_at订单不存在时返回 error 字段右边这种写法模型几乎不会用错。这不是玄学是把模型需要知道的上下文显式地喂给它。2.3 参数校验别把安全交给模型工具调用有一个巨大的坑模型生成的参数是不可信的。它可能传空值、传超长字符串、传不存在的枚举、甚至被提示词注入诱导传恶意内容。如果你直接把模型输出的参数拼进 SQL 或系统命令那就是在裸奔。我的做法是三层防护Schema 层校验用 JSON Schema 严格定义参数类型、范围、正则。模型输出不符合 schema 直接拒绝让它重试。业务层校验比如订单 ID 必须存在、金额必须为正、用户必须有权限。这些模型判断不了必须代码兜底。执行层隔离涉及文件、命令、数据库的操作用白名单 沙箱绝不允许模型自由发挥。提示永远假设模型会传最离谱的参数。你的工具函数第一行应该是校验而不是业务逻辑。2.4 工具调用的天花板在哪工具调用解决了单个能力接入的问题但它有个明显的局限每接一个新工具就要改一次代码、重新部署、重新调 prompt。当你有几十个工具、跨多个系统、还要和不同模型对接时维护成本会爆炸。更麻烦的是生态问题。A 团队写的工具B 团队想用得把代码抄过去改某个工具在 Claude 上跑得好换到另一个模型上描述格式又不一样。工具调用是点对点的接线方式接一根是一根没有统一插座。这个痛点直接催生了 MCP。3. MCP给工具调用装一个统一插座3.1 MCP 是什么一句话讲清MCP 全称 Model Context Protocol翻译过来叫模型上下文协议。你可以把它理解成AI 应用和外部能力之间的 USB-C 接口。以前每个工具要单独接线现在大家都插到同一个标准插座上谁都能用。它的核心思路是把提供能力的一方MCP Server和使用能力的一方MCP Client通常是 Agent 或 AI 应用解耦。Server 负责暴露工具、资源、提示词模板Client 负责发现这些能力并按需调用。中间用一套标准协议通信跟具体模型、具体语言、具体框架都无关。这意味着什么意味着你写一个 MCP Server 暴露公司的数据库查询能力那么任何支持 MCP 的 AI 应用——不管是桌面客户端、IDE 插件还是自研 Agent——都能直接接入不用改一行代码。这就是统一插座的威力。3.2 MCP 的三个核心概念Tools、Resources、Prompts很多人以为 MCP 就是工具调用的标准化其实它管的不止工具。MCP 定义了三种能力原语Tools工具可执行的动作模型主动调用比如发邮件查数据库创建文件。这是最常用的一类。Resources资源可读取的数据类似文件或 API 返回的内容通常由应用或用户决定是否加载进上下文比如项目文档日志文件配置信息。Prompts提示词模板预定义的提示词用户可以主动选择比如帮我做代码审查生成周报模板。这三者的区别很关键。Tools 是模型想做什么Resources 是模型能看到什么Prompts 是用户想让它怎么做。搞混了会导致架构设计出问题——比如把只读的文档硬做成 Tool模型每次都要调用一下才能读既浪费 token 又慢。3.3 传输方式本地和远程怎么选MCP 支持多种传输方式常见的有两类stdio标准输入输出Server 作为本地子进程运行Client 通过标准输入输出和它通信。适合本地工具比如读本地文件、操作本地软件。优点是简单、快、无需网络。HTTP/SSE流式 HTTPServer 作为远程服务运行Client 通过网络调用。适合团队共享的能力比如公司内部的知识库、统一的数据服务。选哪种我的判断标准很简单能力是这台机器专属还是大家共享。读本地文件、控制本地软件用 stdio查公司数据库、调内部 API用远程。别为了看起来高级把本地工具做成远程服务多一层网络就多一层故障。3.4 一个 MCP Server 的最小实现长什么样以 Python 为例用官方 SDK 写一个最简单的 MCP Server暴露一个查询天气的工具大概是这样from mcp.server.fastmcp import FastMCP mcp FastMCP(weather-server) mcp.tool() def get_weather(city: str) - str: 根据城市名查询当前天气。 Args: city: 城市名称例如 北京、上海 # 实际项目里这里调真实天气 API return f{city}晴26 度 if __name__ __main__: mcp.run()就这么几行。装饰器mcp.tool()自动把函数签名和 docstring 转成 MCP 协议需要的工具描述。Client 连上来之后会自动发现这个工具模型就能调用了。对比一下前面手写 JSON Schema 的方式MCP 把描述工具这件事标准化、自动化了。这是它最实在的价值之一。3.5 MCP 落地时最容易踩的三个坑坑一工具数量爆炸导致模型选择困难。我见过一个 MCP Server 暴露了 80 多个工具结果模型经常选错。MCP 让接入变简单了但不代表工具越多越好。我的建议是按领域拆分 Server一个 Server 管一类能力Client 按需加载。比如文件操作 Server数据库 Server通讯 Server分开而不是一个大杂烩。坑二把 MCP 当成万能胶什么都往里塞。MCP 适合标准化、可复用的能力。如果只是项目内部一次性用的逻辑直接写函数调用更简单。为了用 MCP 而用 MCP只会增加复杂度。坑三忽略权限和审计。MCP Server 一旦暴露了敏感能力比如写数据库、发消息就必须有权限控制。谁在调、调了什么、调了几次都要有日志。远程 MCP 尤其要注意别把内部能力裸奔到公网。注意MCP 是协议不是安全方案。协议负责怎么通信安全得你自己在 Server 层做。3.6 MCP 和工具调用是什么关系一句话MCP 是工具调用的标准化封装不是替代品。底层模型依然在做工具调用这件事——输出结构化请求、等待结果、继续推理。MCP 改变的是工具从哪来、怎么被发现、怎么被描述。打个比方工具调用是打电话你得知道对方号码、自己拨号MCP 是通讯录 总机你只管说找谁剩下的协议帮你搞定。电话本身没变变的是连接方式。4. Skill把会做一件事沉淀成可复用的能力包4.1 Skill 和工具、MCP 的本质区别如果说工具调用是给 Agent 一双手MCP 是给这双手配一套标准接口那 Skill 更像是教 Agent 一套做事的方法。Skill 这个词在不同语境下含义不太一样但在 Agent 开发的主流用法里它通常指一段封装好的、可复用的能力单元包含的不只是能调什么还有怎么调、按什么步骤调、注意什么。它可能是一段带完整提示词和工具组合的工作流比如竞品分析 Skill一个封装了多个工具调用的复合能力比如生成周报 Skill一套领域知识 操作规范的打包比如代码审查 Skill。和工具、MCP 最大的区别在于工具和 MCP 关注能力本身Skill 关注能力的组织和使用方式。一个 Skill 内部可能调用多个工具可能依赖某个 MCP Server也可能只是一段精心设计的提示词流程。4.2 为什么需要 Skill 这一层因为光有工具Agent 还是知道能做什么但不知道怎么做才好。举个例子。你给 Agent 接了读文件写文件调 API三个工具让它整理项目文档。它能做但做得好不好全看运气——可能顺序乱了可能漏了步骤可能格式不统一。如果你把这些经验固化成 Skill先扫描目录、再按类型分类、再提取关键信息、最后按模板输出那结果就稳定多了。Skill 的价值就是把老手的经验变成可复制的流程。它解决的是能力有了但用不好的问题。这也是为什么最近Skill 编码Skill 插件去 AI 味的 Skill这类词特别火——大家发现决定 Agent 好不好用的往往不是模型多强而是 Skill 设计得多细。4.3 一个 Skill 通常包含哪些部分我自己的 Skill 一般包含这几块触发条件什么情况下该用这个 Skill。写清楚避免误触发。前置检查用之前要确认什么比如文件是否存在权限是否足够。执行步骤分步骤的操作流程每步说明用什么工具、传什么参数、预期结果是什么。异常处理某步失败了怎么办是重试、跳过还是终止。输出规范最终结果长什么样格式、字段、长度都要定死。这五块写全了Skill 才算可复用。只写个名字和一句描述的那不叫 Skill叫想法。4.4 Skill 和 MCP 怎么配合实际项目里这两者经常一起用。典型架构是MCP Server提供底层能力读文件、查数据库、调 APISkill编排这些能力定义先做什么、再做什么、怎么组合Agent根据用户意图选择合适的 Skill 执行。比如一个周报生成 Skill内部可能调用数据库 MCP拉数据、文件 MCP读模板、文档 MCP写结果。Skill 是菜谱MCP 是厨房设备Agent 是厨师。菜谱决定做什么菜设备决定能不能做厨师决定什么时候做。这种分层的好处是能力可以独立升级换 MCP Server 不影响 Skill流程可以独立优化改 Skill 不影响底层能力职责清晰维护起来不头疼。4.5 Skill 设计中最容易犯的错错误一Skill 太粗。一个 Skill 想干十件事结果每件都干不好。我的原则是一个 Skill 只解决一类问题宁可多拆几个。错误二Skill 太死。把每一步都写死Agent 没有任何灵活空间遇到稍微不同的输入就崩。好的 Skill 应该框架固定、细节灵活关键步骤定死边缘情况给模型判断空间。错误三忽略失败路径。只写成功怎么做不写失败怎么办。实际跑起来失败才是常态。每个 Skill 都要有明确的降级和兜底策略。提示写完一个 Skill先拿 10 个真实案例跑一遍重点看失败的那几个。失败案例暴露的问题比成功案例有价值得多。5. 三者协同一个完整 Agent 的能力拼图5.1 从用户一句话到任务完成的完整链路把三者串起来看一个完整 Agent 处理请求的链路大概是这样用户说帮我整理上个月的销售数据生成一份报告。Agent 理解意图判断需要用到销售报告 Skill。Skill 启动按预设流程执行先调数据库 MCP拉数据再调文件 MCP读报告模板再调图表工具生成图最后调文档 MCP写文件。每一步的底层都是模型在做工具调用——输出结构化请求等待结果继续下一步。全部完成后Agent 把结果返回给用户。这条链路里工具调用是原子操作MCP 是能力接入标准Skill 是流程编排。三者各司其职缺一不可。只有工具调用Agent 是散装能力加上 MCP能力可复用再加上 Skill能力可稳定交付。5.2 分层设计的实际收益我在项目里坚持这种分层最直接的收益有三个换模型不慌底层工具调用协议是标准的换模型只需要调整适配层Skill 和 MCP 基本不动。能力可积累每做一个新场景沉淀一个 Skill团队的能力库越来越厚新人上手越来越快。问题好定位出问题时能快速判断是能力没接上MCP 层、流程设计错Skill 层还是模型判断错调用层排查效率高很多。5.3 一个容易忽略的点上下文管理三者协同还有个隐藏成本上下文膨胀。工具描述、MCP 能力列表、Skill 步骤全都要塞进模型的上下文窗口。工具一多光描述就占掉几千 token留给实际任务的空间就少了。我的应对策略按需加载不是所有工具都一次性暴露根据当前任务动态加载相关的那几个。描述精简工具描述控制在必要信息别写小作文。Skill 分层大 Skill 拆成小 Skill用到哪步加载哪步。这块没有银弹只能靠持续优化。但记住一个原则上下文是稀缺资源每一 token 都要花在刀刃上。6. 实操建议与常见问题答疑6.1 新手该从哪一层入手如果你刚接触 Agent 开发我的建议是从工具调用开始。先手写几个工具理解模型怎么决策、参数怎么传、结果怎么回。这一步跑通了再去看 MCP你会立刻明白它解决了什么痛点。最后再学 Skill因为 Skill 是建立在前面两者之上的。跳过工具调用直接上 MCP 和 Skill很容易变成会用框架但不懂原理遇到问题就抓瞎。6.2 常见问题速查问题原因解决思路模型不调工具直接编答案工具描述不清晰或触发条件没写补全描述明确何时使用模型选错工具工具太多或描述重叠拆分 Server精简描述加区分说明参数传错Schema 不严或示例缺失加 JSON Schema 校验描述里给示例MCP 连不上传输方式或权限配置错检查 stdio 路径或远程鉴权Skill 执行不稳定步骤太死或异常没处理加失败分支给模型留判断空间上下文超限工具/描述太多按需加载精简描述拆分 Skill6.3 几个我踩过的坑你可以直接避开坑一工具描述用中文还是英文看你的模型和用户。如果用户主要说中文描述用中文通常更准如果模型对英文更敏感可以中英混写。关键是和用户输入的语言保持一致减少模型的翻译负担。坑二MCP Server 要不要做缓存要。尤其是查询类工具同样的参数短时间内重复调用很常见。加一层缓存既省资源又快。但要注意缓存失效策略别把过期数据喂给模型。坑三Skill 要不要版本管理必须。Skill 是流程流程会变。每次改动都要有版本号出问题能回滚。我见过团队改 Skill 改出线上事故就是因为没有版本记录改坏了都不知道改的哪版。坑四怎么判断该用工具还是 Skill简单判断单一动作、无状态、可独立调用 → 工具多步骤、有流程、需要编排 → Skill。别把简单的事复杂化。6.4 关于去 AI 味的一点思考最近去 AI 味的 Skill这个词很火本质上是大家在追求让 Agent 的输出更像人、更自然。我的经验是去 AI 味不靠某个神奇 Skill而靠三点给足上下文让它知道背景、约束输出格式别让它自由发挥、提供真实样例让它模仿。工具、MCP、Skill 都是手段最终目的是让 Agent 的输出有用且自然。7. 最后聊几句个人体会做 Agent 开发这两年我最大的感受是大家太容易盯着模型忽略了模型之外的东西。模型确实重要但决定一个 Agent 能不能真正干活的往往是工具接得对不对、MCP 设计得合不合理、Skill 编排得细不细。模型是大脑工具是手脚MCP 是神经接口Skill 是肌肉记忆。缺了哪个都跑不起来。我现在的习惯是每接一个新能力先问自己三个问题这个能力该做成工具还是 Skill要不要走 MCP失败了怎么办把这三个问题想清楚比急着写代码有用得多。工具调用、MCP、Skill 这三层不是非此即彼的选择而是可以叠加的组合。小项目可能只用工具调用就够了大项目三层全上也不嫌多。关键是理解每一层解决什么问题然后在合适的场景用合适的层。别为了追新词硬上 MCP也别为了省事把所有逻辑塞进一个大 Skill。分层清晰、职责明确Agent 才能既跑得动又跑得稳。
1. 从一次Agent 突然变傻的排查说起先说个我亲身经历的事。去年帮一个团队调一个基于大模型的自动化助手功能是帮运营同学自动整理竞品资料、生成周报、顺手把数据填进表格。Demo 阶段一切正常演示的时候行云流水老板看了直点头。结果上线第三天运营同学反馈它今天不查数据库了直接编了个数字给我。我第一反应是模型抽风换了更强的模型问题依旧。后来把日志翻出来逐条看才发现真正的原因那天我们调整了工具描述tool description的措辞把查询订单表改成了获取订单信息模型理解成了从上下文里找订单信息于是它压根没发起工具调用直接凭记忆编了一个。工具还在能力却消失了。这件事让我彻底想明白一个道理Agent 的能力不是模型自带的而是被接出来的。模型本身只会做一件事——根据上下文预测下一个 token。它能查天气、能读文件、能操作浏览器靠的全是外部挂载的能力。而这些能力怎么挂、挂什么、挂得对不对直接决定了 Agent 是真能干还是看起来很能干。这篇就围绕三个关键词展开工具调用Function Calling / Tool Calling、MCPModel Context Protocol、Skill。这三个词最近在 Agent 开发圈子里出现频率极高但很多人把它们混为一谈或者只知道概念不知道边界。我会从能力从哪来这个根问题出发把三者的定位、关系、实操细节和踩坑经验讲透。不管你是刚接触 Agent 开发的新手还是已经在搭框架的老手应该都能从中找到能直接用的东西。2. 工具调用Agent 能力的第一层地基2.1 工具调用到底解决了什么问题大模型有个天生的短板它的知识截止到训练数据的时间点而且它无法主动与外部世界交互。你问它今天北京天气怎么样它只能告诉你我无法获取实时信息。这不是它笨是它的运行机制决定的——它只是一个文本进、文本出的函数。工具调用就是在这个函数外面开了一扇门。开发者预先定义好一批工具每个工具包含名称、描述、参数结构。模型在对话过程中如果判断需要用到某个工具就输出一段结构化的调用请求通常是 JSON由外部程序执行再把结果塞回上下文模型继续往下推理。举个最朴素的例子。你定义一个工具叫get_weather参数是city。用户问上海今天热不热模型输出{ name: get_weather, arguments: { city: 上海 } }你的程序拿到这个 JSON去调天气 API把返回的32度晴塞回对话模型再生成上海今天 32 度挺热的注意防晒。整个过程里模型负责决策要不要调、调哪个、传什么参数你的代码负责真正去执行。这就是工具调用的本质把模型的语义理解能力和外部程序的执行能力用一套结构化协议对接起来。2.2 工具描述为什么比工具本身还重要回到开头那个事故。工具代码一行没改只是描述措辞变了Agent 就罢工了。这说明一个反直觉的事实在工具调用里描述的质量往往比实现的质量更影响成功率。模型决定调不调工具靠的是读描述。描述写得含糊模型就犹豫描述写得和用户意图对不上模型就选错工具描述里没写清楚参数格式模型就传错参数。我见过太多团队工具函数写得漂漂亮亮描述就一句查询数据然后抱怨模型不好用。我的经验是一个好的工具描述应该包含四要素做什么一句话说清功能动词开头比如根据城市名查询当前天气。什么时候用给出触发场景比如当用户询问天气、温度、是否下雨时使用。参数含义每个参数说明类型、格式、示例尤其是枚举值要列全。边界说明什么情况下不该用比如仅支持中国大陆城市其他地区返回错误。下面是一个对比左边是常见的敷衍版右边是我实际项目里用的可用版维度敷衍版可用版名称queryget_order_by_id描述查询订单根据订单 ID 查询订单详情包含金额、状态、下单时间。当用户提供订单号或询问某笔订单情况时使用。仅支持查询不支持修改。参数idorder_id (string)订单编号格式为 18 位数字例如 202405171234567890返回订单信息返回 JSON字段包括 order_id、amount、status、created_at订单不存在时返回 error 字段右边这种写法模型几乎不会用错。这不是玄学是把模型需要知道的上下文显式地喂给它。2.3 参数校验别把安全交给模型工具调用有一个巨大的坑模型生成的参数是不可信的。它可能传空值、传超长字符串、传不存在的枚举、甚至被提示词注入诱导传恶意内容。如果你直接把模型输出的参数拼进 SQL 或系统命令那就是在裸奔。我的做法是三层防护Schema 层校验用 JSON Schema 严格定义参数类型、范围、正则。模型输出不符合 schema 直接拒绝让它重试。业务层校验比如订单 ID 必须存在、金额必须为正、用户必须有权限。这些模型判断不了必须代码兜底。执行层隔离涉及文件、命令、数据库的操作用白名单 沙箱绝不允许模型自由发挥。提示永远假设模型会传最离谱的参数。你的工具函数第一行应该是校验而不是业务逻辑。2.4 工具调用的天花板在哪工具调用解决了单个能力接入的问题但它有个明显的局限每接一个新工具就要改一次代码、重新部署、重新调 prompt。当你有几十个工具、跨多个系统、还要和不同模型对接时维护成本会爆炸。更麻烦的是生态问题。A 团队写的工具B 团队想用得把代码抄过去改某个工具在 Claude 上跑得好换到另一个模型上描述格式又不一样。工具调用是点对点的接线方式接一根是一根没有统一插座。这个痛点直接催生了 MCP。3. MCP给工具调用装一个统一插座3.1 MCP 是什么一句话讲清MCP 全称 Model Context Protocol翻译过来叫模型上下文协议。你可以把它理解成AI 应用和外部能力之间的 USB-C 接口。以前每个工具要单独接线现在大家都插到同一个标准插座上谁都能用。它的核心思路是把提供能力的一方MCP Server和使用能力的一方MCP Client通常是 Agent 或 AI 应用解耦。Server 负责暴露工具、资源、提示词模板Client 负责发现这些能力并按需调用。中间用一套标准协议通信跟具体模型、具体语言、具体框架都无关。这意味着什么意味着你写一个 MCP Server 暴露公司的数据库查询能力那么任何支持 MCP 的 AI 应用——不管是桌面客户端、IDE 插件还是自研 Agent——都能直接接入不用改一行代码。这就是统一插座的威力。3.2 MCP 的三个核心概念Tools、Resources、Prompts很多人以为 MCP 就是工具调用的标准化其实它管的不止工具。MCP 定义了三种能力原语Tools工具可执行的动作模型主动调用比如发邮件查数据库创建文件。这是最常用的一类。Resources资源可读取的数据类似文件或 API 返回的内容通常由应用或用户决定是否加载进上下文比如项目文档日志文件配置信息。Prompts提示词模板预定义的提示词用户可以主动选择比如帮我做代码审查生成周报模板。这三者的区别很关键。Tools 是模型想做什么Resources 是模型能看到什么Prompts 是用户想让它怎么做。搞混了会导致架构设计出问题——比如把只读的文档硬做成 Tool模型每次都要调用一下才能读既浪费 token 又慢。3.3 传输方式本地和远程怎么选MCP 支持多种传输方式常见的有两类stdio标准输入输出Server 作为本地子进程运行Client 通过标准输入输出和它通信。适合本地工具比如读本地文件、操作本地软件。优点是简单、快、无需网络。HTTP/SSE流式 HTTPServer 作为远程服务运行Client 通过网络调用。适合团队共享的能力比如公司内部的知识库、统一的数据服务。选哪种我的判断标准很简单能力是这台机器专属还是大家共享。读本地文件、控制本地软件用 stdio查公司数据库、调内部 API用远程。别为了看起来高级把本地工具做成远程服务多一层网络就多一层故障。3.4 一个 MCP Server 的最小实现长什么样以 Python 为例用官方 SDK 写一个最简单的 MCP Server暴露一个查询天气的工具大概是这样from mcp.server.fastmcp import FastMCP mcp FastMCP(weather-server) mcp.tool() def get_weather(city: str) - str: 根据城市名查询当前天气。 Args: city: 城市名称例如 北京、上海 # 实际项目里这里调真实天气 API return f{city}晴26 度 if __name__ __main__: mcp.run()就这么几行。装饰器mcp.tool()自动把函数签名和 docstring 转成 MCP 协议需要的工具描述。Client 连上来之后会自动发现这个工具模型就能调用了。对比一下前面手写 JSON Schema 的方式MCP 把描述工具这件事标准化、自动化了。这是它最实在的价值之一。3.5 MCP 落地时最容易踩的三个坑坑一工具数量爆炸导致模型选择困难。我见过一个 MCP Server 暴露了 80 多个工具结果模型经常选错。MCP 让接入变简单了但不代表工具越多越好。我的建议是按领域拆分 Server一个 Server 管一类能力Client 按需加载。比如文件操作 Server数据库 Server通讯 Server分开而不是一个大杂烩。坑二把 MCP 当成万能胶什么都往里塞。MCP 适合标准化、可复用的能力。如果只是项目内部一次性用的逻辑直接写函数调用更简单。为了用 MCP 而用 MCP只会增加复杂度。坑三忽略权限和审计。MCP Server 一旦暴露了敏感能力比如写数据库、发消息就必须有权限控制。谁在调、调了什么、调了几次都要有日志。远程 MCP 尤其要注意别把内部能力裸奔到公网。注意MCP 是协议不是安全方案。协议负责怎么通信安全得你自己在 Server 层做。3.6 MCP 和工具调用是什么关系一句话MCP 是工具调用的标准化封装不是替代品。底层模型依然在做工具调用这件事——输出结构化请求、等待结果、继续推理。MCP 改变的是工具从哪来、怎么被发现、怎么被描述。打个比方工具调用是打电话你得知道对方号码、自己拨号MCP 是通讯录 总机你只管说找谁剩下的协议帮你搞定。电话本身没变变的是连接方式。4. Skill把会做一件事沉淀成可复用的能力包4.1 Skill 和工具、MCP 的本质区别如果说工具调用是给 Agent 一双手MCP 是给这双手配一套标准接口那 Skill 更像是教 Agent 一套做事的方法。Skill 这个词在不同语境下含义不太一样但在 Agent 开发的主流用法里它通常指一段封装好的、可复用的能力单元包含的不只是能调什么还有怎么调、按什么步骤调、注意什么。它可能是一段带完整提示词和工具组合的工作流比如竞品分析 Skill一个封装了多个工具调用的复合能力比如生成周报 Skill一套领域知识 操作规范的打包比如代码审查 Skill。和工具、MCP 最大的区别在于工具和 MCP 关注能力本身Skill 关注能力的组织和使用方式。一个 Skill 内部可能调用多个工具可能依赖某个 MCP Server也可能只是一段精心设计的提示词流程。4.2 为什么需要 Skill 这一层因为光有工具Agent 还是知道能做什么但不知道怎么做才好。举个例子。你给 Agent 接了读文件写文件调 API三个工具让它整理项目文档。它能做但做得好不好全看运气——可能顺序乱了可能漏了步骤可能格式不统一。如果你把这些经验固化成 Skill先扫描目录、再按类型分类、再提取关键信息、最后按模板输出那结果就稳定多了。Skill 的价值就是把老手的经验变成可复制的流程。它解决的是能力有了但用不好的问题。这也是为什么最近Skill 编码Skill 插件去 AI 味的 Skill这类词特别火——大家发现决定 Agent 好不好用的往往不是模型多强而是 Skill 设计得多细。4.3 一个 Skill 通常包含哪些部分我自己的 Skill 一般包含这几块触发条件什么情况下该用这个 Skill。写清楚避免误触发。前置检查用之前要确认什么比如文件是否存在权限是否足够。执行步骤分步骤的操作流程每步说明用什么工具、传什么参数、预期结果是什么。异常处理某步失败了怎么办是重试、跳过还是终止。输出规范最终结果长什么样格式、字段、长度都要定死。这五块写全了Skill 才算可复用。只写个名字和一句描述的那不叫 Skill叫想法。4.4 Skill 和 MCP 怎么配合实际项目里这两者经常一起用。典型架构是MCP Server提供底层能力读文件、查数据库、调 APISkill编排这些能力定义先做什么、再做什么、怎么组合Agent根据用户意图选择合适的 Skill 执行。比如一个周报生成 Skill内部可能调用数据库 MCP拉数据、文件 MCP读模板、文档 MCP写结果。Skill 是菜谱MCP 是厨房设备Agent 是厨师。菜谱决定做什么菜设备决定能不能做厨师决定什么时候做。这种分层的好处是能力可以独立升级换 MCP Server 不影响 Skill流程可以独立优化改 Skill 不影响底层能力职责清晰维护起来不头疼。4.5 Skill 设计中最容易犯的错错误一Skill 太粗。一个 Skill 想干十件事结果每件都干不好。我的原则是一个 Skill 只解决一类问题宁可多拆几个。错误二Skill 太死。把每一步都写死Agent 没有任何灵活空间遇到稍微不同的输入就崩。好的 Skill 应该框架固定、细节灵活关键步骤定死边缘情况给模型判断空间。错误三忽略失败路径。只写成功怎么做不写失败怎么办。实际跑起来失败才是常态。每个 Skill 都要有明确的降级和兜底策略。提示写完一个 Skill先拿 10 个真实案例跑一遍重点看失败的那几个。失败案例暴露的问题比成功案例有价值得多。5. 三者协同一个完整 Agent 的能力拼图5.1 从用户一句话到任务完成的完整链路把三者串起来看一个完整 Agent 处理请求的链路大概是这样用户说帮我整理上个月的销售数据生成一份报告。Agent 理解意图判断需要用到销售报告 Skill。Skill 启动按预设流程执行先调数据库 MCP拉数据再调文件 MCP读报告模板再调图表工具生成图最后调文档 MCP写文件。每一步的底层都是模型在做工具调用——输出结构化请求等待结果继续下一步。全部完成后Agent 把结果返回给用户。这条链路里工具调用是原子操作MCP 是能力接入标准Skill 是流程编排。三者各司其职缺一不可。只有工具调用Agent 是散装能力加上 MCP能力可复用再加上 Skill能力可稳定交付。5.2 分层设计的实际收益我在项目里坚持这种分层最直接的收益有三个换模型不慌底层工具调用协议是标准的换模型只需要调整适配层Skill 和 MCP 基本不动。能力可积累每做一个新场景沉淀一个 Skill团队的能力库越来越厚新人上手越来越快。问题好定位出问题时能快速判断是能力没接上MCP 层、流程设计错Skill 层还是模型判断错调用层排查效率高很多。5.3 一个容易忽略的点上下文管理三者协同还有个隐藏成本上下文膨胀。工具描述、MCP 能力列表、Skill 步骤全都要塞进模型的上下文窗口。工具一多光描述就占掉几千 token留给实际任务的空间就少了。我的应对策略按需加载不是所有工具都一次性暴露根据当前任务动态加载相关的那几个。描述精简工具描述控制在必要信息别写小作文。Skill 分层大 Skill 拆成小 Skill用到哪步加载哪步。这块没有银弹只能靠持续优化。但记住一个原则上下文是稀缺资源每一 token 都要花在刀刃上。6. 实操建议与常见问题答疑6.1 新手该从哪一层入手如果你刚接触 Agent 开发我的建议是从工具调用开始。先手写几个工具理解模型怎么决策、参数怎么传、结果怎么回。这一步跑通了再去看 MCP你会立刻明白它解决了什么痛点。最后再学 Skill因为 Skill 是建立在前面两者之上的。跳过工具调用直接上 MCP 和 Skill很容易变成会用框架但不懂原理遇到问题就抓瞎。6.2 常见问题速查问题原因解决思路模型不调工具直接编答案工具描述不清晰或触发条件没写补全描述明确何时使用模型选错工具工具太多或描述重叠拆分 Server精简描述加区分说明参数传错Schema 不严或示例缺失加 JSON Schema 校验描述里给示例MCP 连不上传输方式或权限配置错检查 stdio 路径或远程鉴权Skill 执行不稳定步骤太死或异常没处理加失败分支给模型留判断空间上下文超限工具/描述太多按需加载精简描述拆分 Skill6.3 几个我踩过的坑你可以直接避开坑一工具描述用中文还是英文看你的模型和用户。如果用户主要说中文描述用中文通常更准如果模型对英文更敏感可以中英混写。关键是和用户输入的语言保持一致减少模型的翻译负担。坑二MCP Server 要不要做缓存要。尤其是查询类工具同样的参数短时间内重复调用很常见。加一层缓存既省资源又快。但要注意缓存失效策略别把过期数据喂给模型。坑三Skill 要不要版本管理必须。Skill 是流程流程会变。每次改动都要有版本号出问题能回滚。我见过团队改 Skill 改出线上事故就是因为没有版本记录改坏了都不知道改的哪版。坑四怎么判断该用工具还是 Skill简单判断单一动作、无状态、可独立调用 → 工具多步骤、有流程、需要编排 → Skill。别把简单的事复杂化。6.4 关于去 AI 味的一点思考最近去 AI 味的 Skill这个词很火本质上是大家在追求让 Agent 的输出更像人、更自然。我的经验是去 AI 味不靠某个神奇 Skill而靠三点给足上下文让它知道背景、约束输出格式别让它自由发挥、提供真实样例让它模仿。工具、MCP、Skill 都是手段最终目的是让 Agent 的输出有用且自然。7. 最后聊几句个人体会做 Agent 开发这两年我最大的感受是大家太容易盯着模型忽略了模型之外的东西。模型确实重要但决定一个 Agent 能不能真正干活的往往是工具接得对不对、MCP 设计得合不合理、Skill 编排得细不细。模型是大脑工具是手脚MCP 是神经接口Skill 是肌肉记忆。缺了哪个都跑不起来。我现在的习惯是每接一个新能力先问自己三个问题这个能力该做成工具还是 Skill要不要走 MCP失败了怎么办把这三个问题想清楚比急着写代码有用得多。工具调用、MCP、Skill 这三层不是非此即彼的选择而是可以叠加的组合。小项目可能只用工具调用就够了大项目三层全上也不嫌多。关键是理解每一层解决什么问题然后在合适的场景用合适的层。别为了追新词硬上 MCP也别为了省事把所有逻辑塞进一个大 Skill。分层清晰、职责明确Agent 才能既跑得动又跑得稳。
