Agent、Tool、MCP、Skill 到底啥关系？一张图 + 一套能跑的实现

上个月我们排过一个很冤的故障一个租户的智能体突然集体失声每条对话都失败。模型没挂网关没挂知识库也没挂。排到最后真凶是一个中文名字 —— 用户给自建的 MCP server 起了个中文名拼接出来的工具名让模型厂商的 API 直接回了 400。协议文档里当然不会写这种事。这个故障后来变成了我们代码库里的一个类。这篇文章想讲的就是这类事MCP 和 Agent Skills 这两个正在快速标准化的东西规范讲的是理想态生产环境里全是规范不管的地方。前半篇讲最近发生了什么、概念怎么分后半篇讲我们在太一企业版mate-hive里是怎么落的 —— 包括踩过的坑。写到具体类名的地方都是生产环境里真实跑着的代码。01五天后MCP 要发它有史以来最大的一次修订7 月 28 日MCP 计划发布一次被维护者称为「发布以来幅度最大」的规范修订。目前公开的发布候选版里最关键的一条是协议核心转向无状态。图片来源MCP 官方博客2026-07-28 规范发布候选说明具体改了什么以前远程 MCP 连接要先做初始化握手维护协议级 SessionServer 想扩容就得靠粘性会话或者共享 Session Store。新候选版把这层协议状态取消了一次请求可以落到任意实例方法名和工具名进了 HTTP Header网关能路由、能限流缓存期限和 W3C Trace Context 也进了规范。做 Java 或 Node 的同学看这个清单会觉得眼熟 —— 对协议终于开始长得像一个能被负载均衡、API 网关和 OpenTelemetry 正常管理的服务了。它解决的不是「模型会不会调工具」而是 MCP Server 能不能像普通企业服务一样被运维。同一时间还有两件事在发生。一是 Agent Skills 已经从 Anthropic 的产品能力变成了开放格式OpenAI Codex、GitHub Copilot、VS Code、Gemini CLI、Spring AI 都陆续支持这种由 SKILL.md、脚本、参考资料和模板组成的能力包。MCP 社区也在推 Skills over MCP不过到 7 月 23 日为止相关扩展还在评审阶段别当成稳定协议用。图片来源Anthropic《Introducing Agent Skills》2025-10-16二是语言生态的节奏差摆上了台面MCP 的 Java SDK 2.0 已经在 6 月 11 日 GAPython SDK 2.0 到 7 月 14 日还是 beta官方明说别进生产TypeScript SDK 2.0 到 7 月 21 日同样是 beta。三种技术栈都能做智能体但进生产的节奏和成本差得不少 —— 这个后面第 05 节细说。这几条新闻放在一起看指向同一件事智能体的竞争正在从「模型能力」延伸到「能力如何被封装、连接、治理和复用」。对 CTO 来说要回答的问题已经不是选哪个模型而是重新划分架构里的责任什么交给模型什么交给 Skill什么走 MCP 暴露什么必须留在确定性的业务系统里。02先把四个词拆开Agent、Tool、MCP、Skill智能体这个领域最大的毛病是不同的概念在营销话术里被压成了同一个词。开会的时候一人一个理解方案根本没法对齐。先拆开**Agent 是决策循环。**围绕目标拿上下文、规划步骤、挑工具、看结果、定下一步。它的核心不是那个聊天框是模型进入了「判断、行动、反馈」的循环。**Tool 是原子动作。**查库存、建工单、算报价。它告诉模型「有什么动作可以做」但不解释一个复杂任务该按什么顺序干。**MCP 是连接协议。**规定 Host、Client、Server 怎么发现和调用能力。管接口形态管互操作别的都不管。**Skill 是操作手册加工具包。**任务说明、判断规则、脚本、参考资料、输出模板打包在一起。它回答的是「这类任务应该怎么干」。一句话记住四者的关系Agent 决定下一步做什么Skill 提供做好一类工作的经验MCP 让外部能力可以被发现和调用Tool 执行一个具体动作。这个区分不是抠字眼。MCP 不拥有业务流程Skill 也不天然拥有执行权限。把它们混着用最后就会得到一套「能调用很多东西但没人说得清为什么这样调用」的系统 —— 这种系统我们见过出了事连排查的入口都找不到。概念归概念落地得有实体。上图右列就是这四样东西在太一里对应的四个一等公民简单说概念太一里的实体关键设计AgentAgentDefinition 落库purpose 路由不绑厂商、草稿/发布双槽、上岗就绪探针SkillSkillRegistry平台/租户/工作区三层作用域、版本化、双道安审MCPMcpServerConfig租户级装卸、凭据加密、工具名统一归一化ToolToolGuard 沙盒只读/可逆/不可逆分级、高风险转人工、全轨迹审计03MCP 的真正进步和我们在生产里踩的四个坑MCP 的产业地位现在有背书了2025 年 12 月Linux Foundation 成立 Agentic AI Foundation首批项目就是 MCP、goose 和 AGENTS.md。从一家公司的开源项目进了中立基金会这一步很重要。图片来源Linux Foundation AAIF 成立公告2025-12-09但进了基金会不等于协议成熟。MCP 官方自己的 2026 路线图就承认企业规模化部署有四类缺口审计与可观测、企业身份、网关代理、配置可移植。7 月 28 日的新规范补的是其中一部分。这里要泼一盆冷水「协议无状态」不等于「业务无状态」。智能体建了采购单、发起了审批这些状态还是得应用自己存任务幂不幂等、失败怎么补偿MCP 也不替你决定。所以别把 MCP 用成企业内部所有接口的新包装 —— 订单服务和库存服务之间已经有稳定的 REST 或 RPC就没必要为了「智能体化」再套一层。**只有需要被 AI 动态发现和调用的能力才值得暴露成 MCP。**它是企业的 AI 能力边界不是新的微服务总线。规范讲完了讲点规范不写的。下面四个坑全部来自太一的生产环境每个都附修法。坑一 · 一个中文名字炸掉整条对话链就是开头那个故障。用户给自建 MCP server 起了个中文名拼出来的工具名让某家模型厂商的 API 直接回 400。表象是「对话突然失败」没人会往一个名字上想。修法不是规定「不许起中文名」—— 规定拦不住用户。而是建一个唯一的归一化入口 McpToolNames所有工具名从这里过注册、调用、回执三个消费方取同一个名字谁想绕开code review 就拦下来。坑二 · 单机内存态到了集群里就「时好时坏」MCP 客户端连接、凭据、工具缓存放在进程内存里单机一切正常。多实例一部署请求落在 A 实例有工具、落在 B 实例没有。这种概率性失灵最耗排查时间。修法配置与状态收进数据库和 Redis凭据加密存储、界面脱敏任何实例随时能重建完整视图。有意思的是这和 7 月 28 日新规范的无状态方向是同一个思路 —— 我们先在应用层做了协议现在追上来了。坑三 · stdio 不是免费的本地 stdio 形态的 MCP server 有三个经典死法npx 在生产机上找不到子进程把 stderr 缓冲区写满双方互相等死锁没有超时把 worker 线程整个挂死。修法生产环境优先 HTTP/SSE 形态确实要用 stdio 的必须带独立超时、stderr 排水线程和快速熔断。坑四 · 工具装配不过租户闸口全平台一起失灵工具桥拉取 MCP 工具的时候如果不带租户上下文两个租户各自装的同名 server 会撞出重名工具模型侧直接拒绝。症状是所有对话都答不上来而兜底话术会把真实原因盖得严严实实。修法装配链路强制带租户上下文过滤同租户内再做命名冲突检测。这个坑的教训比修法值钱兜底话术是症状不是原因—— 治理缺口会伪装成模型能力问题先去翻失败日志别急着调 prompt。04Skill把老师傅的经验变成管得住的资产过去企业管业务经验的方式是把它塞进一个越来越长的 System Prompt。流程一变改提示词模型一换重新调。半年之后没人说得清一项能力到底依赖哪些规则、模板和脚本 —— 我们叫它「提示词沼泽」。Agent Skills 给了另一种组织方式一个目录装着 SKILL.md、脚本、参考资料和模板。智能体启动时只读名字和描述任务匹配上了再加载完整说明。渐进式披露上下文占用低能力边界清楚。但对企业来说Skill 真正值钱的地方不是省那几百个 token而是把散在提示词、Wiki 和老师傅脑子里的操作知识变成有版本、有责任人、有发布流程的制品。举个例子「合同审核」不该是一句 prompt它应该长这样SKILL.mdcode: contract-reviewversion: 5scope: tenant # 平台 / 租户 / 工作区tools: [extract_clauses, check_qualification, review_contract]合同审核作业流程先抽合同类型与适用法域确定审查清单版本逐条核对资质与签署主体缺项直接标红不允许推断风险条款比对走 review_contract 工具的规则库—— 禁止让模型凭语感判级判错一次就是事故输出按公司模板分红/黄/绿三级每条结论附原文定位命中「不得转包」等一票否决条款立即停止转法务人工工具负责动作Skill 负责顺序与判断权限系统决定哪些数据和动作对当前用户开放。一句 prompt 喂给谁都一样这套流程是你独有的。五年之后它就是你和同行的差距。把 Skill 当资产管太一做了四件事。**三层作用域。**平台级是出厂能力租户级是这家企业的打法工作区级是这个部门的特例逐层覆盖。查询按作用域参数收敛不是「有就算数」—— 这一字之差决定了 A 部门的经验会不会漏给 B 部门。**资源真源放数据库。**SKILL.md、脚本、模板作为捆绑资源统一入库不散在文件系统里。版本、回滚、审计、多实例一致性全部一次拿到。**出厂自带 playbook。**平台内置 24 个预置技能公文、评标、合同、报告都有由 Seeder 播种。有条纪律改一次 frontmatter 必须升 version不升版存量环境就不更新 —— 版本号是唯一的升级信号。**上架前过两道安审。**Skill 可能带可执行脚本可能引用会变的外部资料也可能用一段话诱导 Agent 去调高风险工具 —— 它就是新的供应链风险面。所以第一道是静态审查查脚本、依赖、权限声明和诱导性文本第二道是动态审查让带自测试的 Skill 在沙盒里真跑一遍行为和声明对不上就拒绝上架。还有一条规矩是拿越权事故换来的读门不等于写门。曾经有个删除接口按裸 code 匹配 Skill结果跨租户删掉了别人的技能。读操作有作用域过滤不代表写操作也有 —— 两边必须分别验归属。05Java、Python 还是 Node这题的问法就错了「智能体该用什么语言写」—— 这个问题本身不成立三种语言都能做 Agent、做 MCP Client 和 Server。真正该问的是在你的存量系统、团队能力和风险约束下哪种语言承担某类责任的综合成本最低。维度JavaPythonNode.js / TS存量优势核心业务、中台模型、数据Web、SaaS 集成MCP 2.0 SDK已 GAbeta别进生产beta锁稳定线主要强项身份、事务、审计生态、评测、迭代交互、流式、接入治理成本实验速度、生态时差依赖、实验生产化npm 供应链、长任务优先承担控制面、核心 Tool智能面、评测交互面、Connector太一没回避这道选择题答案就写在部署拓扑里。**Java 承载引擎和全部写操作。**mate-hive 引擎跑在 Spring 生态上理由很朴素企业的身份、角色、事务、审计、消息、配置中心本来就在这里。Spring AI 2.0 稳定了MCP Java SDK 2.0 也 GA 了Java 团队不用把业务 API 复制一遍到 Python 才能做智能体 —— 在原有业务服务旁边定义受控 Tool复用 Spring Security 的身份、原来的事务边界和监控再挑着通过 MCP 暴露就够了。**Python 只做无状态边车。**文档深解析MinerU、版式渲染ppt-master这类活Python 生态确实最快那就用。但只能当边车独立容器、无状态、不持业务真源。慢调用绝不阻塞主引擎 —— 提交任务拿 taskId存下就还线程轮询到结果再续跑。一句话记住两者的地位差边车挂了能降级控制面挂了才是事故。**TypeScript 承担全部交互入口。**hive-ui、SSE 流式对话、微信/飞书/钉钉渠道、分享页、OpenAI 协议的开放 API。有一条没有捷径TS 的类型在运行时会消失来自模型和外部 MCP Server 的数据在边界上必须重新校验。要强调一下这是责任分工不是语言排名。纯 Python 的公司犯不着为「标准架构」引入 JavaNode 系的公司也不用迁移业务系统。控制、智能、交互三类责任有人认领就行 —— 千万别假设某个 Agent 框架会替你把它们都干了。06三平面而不是三套烟囱把上一节的分工画成图就是三平面架构。太一的实际形态长这样三平面架构和三套烟囱的全部区别就在右边那根「纵向贯穿」的柱子上统一身份从渠道入站到模型调用是同一个人工具权限按用户和任务上下文算不是按服务账号算runId、Skill 版本、Tool Call ID 进同一条审计链。如果三个平面各建一套用户、一套知识、一套审计那不叫架构分层叫重复建设。07真正的风险在协议之外八道边界MCP 规范自己都写着Tool 描述应被视为不可信信息协议不能强制实现所有安全原则。换句话说如果你只做到「连接成功」很可能刚好绕过了原来的安全边界。我们把一次受治理的工具调用拆成八道边界每一道在太一里都有对应实现对着这张图说说企业智能体最常见的五类生产风险。**一身份丢失。**MCP Server 只看到平台的服务账号不知道真实用户是谁结果所有人拿到同一份权限。新的企业授权扩展想靠 IdP 解决但那是可选扩展客户端支持还不齐。太一的做法GovernanceContext 带着 Principal 贯穿全链路渠道入站的租户身份只认 URL 租户段验签 ——报文里的租户字段是攻击面不是身份来源。**二提示注入变成执行注入。**一段恶意文档就能诱导 Agent 去调转账、发信、删除工具。防线不能只靠模型自己识别工具白名单加参数策略匹配前先做归一化 —— 全角字符、变体字符先归一再比对不然黑名单形同虚设 —— 再加高风险动作强制转人工。**三长任务没有业务语义。**新规范的 Tasks 提供了任务句柄和取消但「取消」可能只是个协作意图订单到底提没提交得业务系统用幂等和补偿来回答。轮询侧我们还有一条实测教训判失败要数连续失败次数不是总轮询次数—— 数总次数慢任务会被误杀不数失败伪造的任务卡会永远转圈。判据永远是「任务表里有没有新行」不是「工具有没有被调用过」。**四Skill 供应链。**脚本可能越权资料可能过期文本可能藏着诱导。像管容器镜像一样管它版本、依赖清单、两道安审、沙盒分级执行。第 04 节展开过不重复。**五观测只有 token没有业务结果。**token 数只是技术指标真正该盯的是任务完成率、人工接管率、错误写入率、单位成功任务的成本。这里有个特别容易全军覆没的细节流式对话的 usage 藏在结束尾帧里收尾的时候不解析token 台账就永远是零—— 你以为在观测其实什么都没记下。太一在审计上还加了一层 SHA256 哈希链轨迹不但要有还得改不了。这八道边界的验收标准就一句话审计问「这个结论怎么来的」你能不能一条 SQL 答出来。能系统就能进生产不能就进不了。08给 CTO 的七条建议都能当场开干1**先画能力边界不先画 Agent 数量。**哪些能力只给内部服务用哪些需要被 AI 动态发现 —— 只有后一类才值得 MCP 化。2**给 Tool 做风险分级。**只读、可逆写、不可逆写分别对应自动执行、条件执行、强制审批。这张策略表一天就能画出来。3**把 Skill 纳入制品库。**所有者、版本、依赖、权限、评测结果缺一不上架带脚本的必须过沙盒动态审查。4**固定协议和 SDK 版本。**Java 2.0 已 GAPython 和 TS 的 2.0 还是 beta别把候选版和稳定版混进同一条生产基线。5**建跨语言契约测试。**同一组样例验证 Schema、错误码、取消、超时和身份传播 —— 不是只测「能不能连通」。6**用业务结果评测智能体。**任务成功率、越权拦截率、人工接管率、恢复时间。别把模型评分当 KPI也别让 token 台账一直是零。7**从可撤回的流程开始试点。**高频、规则说得清、结果可验证、错了能补偿的场景先上再逐步放开执行权限。结语MCP 和 Agent Skills 的意义不在于让企业更快堆出更多智能体而在于智能体能力终于开始有了可以讨论的边界MCP 把连接变成协议Skill 把工作方法变成制品。但协议不会替你完成授权Skill 不会自动保证可信语言更不会替架构承担责任。下一阶段企业智能体的分水岭不是「有没有接入 MCP」是四件事能力可以发现 · 权限可以收敛过程可以追溯 · 失败可以恢复太一企业版做的就是这一层 —— 治理连接层。MCP 是连接手段权限和审计才是平台价值。文中出现的每个组件名GovernanceContext、ToolGuard、McpToolNames、SkillRegistry、就绪探针、审计哈希链都在生产环境里跑着每个坑也都是真踩出来的。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】