Agent、Tool、MCP、Skill 到底啥关系？一张图 + 一套能跑的实现-平芜编程栈

上个月我们排过一个很冤的故障：一个租户的智能体突然集体失声，每条对话都失败。模型没挂，网关没挂，知识库也没挂。

排到最后，真凶是一个中文名字 —— 用户给自建的 MCP server 起了个中文名，拼接出来的工具名让模型厂商的 API 直接回了 400。协议文档里当然不会写这种事。

这个故障后来变成了我们代码库里的一个类。这篇文章想讲的就是这类事：MCP 和 Agent Skills 这两个正在快速标准化的东西，规范讲的是理想态，生产环境里全是规范不管的地方。

前半篇讲最近发生了什么、概念怎么分；后半篇讲我们在太一企业版（mate-hive）里是怎么落的 —— 包括踩过的坑。写到具体类名的地方，都是生产环境里真实跑着的代码。

五天后，MCP 要发它有史以来最大的一次修订

7 月 28 日，MCP 计划发布一次被维护者称为「发布以来幅度最大」的规范修订。目前公开的发布候选版里，最关键的一条是：协议核心转向无状态。

图片来源：MCP 官方博客，2026-07-28 规范发布候选说明

具体改了什么？以前远程 MCP 连接要先做初始化握手，维护协议级 Session，Server 想扩容就得靠粘性会话或者共享 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 日 GA；Python SDK 2.0 到 7 月 14 日还是 beta，官方明说别进生产；TypeScript SDK 2.0 到 7 月 21 日同样是 beta。三种技术栈都能做智能体，但进生产的节奏和成本差得不少 —— 这个后面第 05 节细说。

这几条新闻放在一起看，指向同一件事：智能体的竞争正在从「模型能力」延伸到「能力如何被封装、连接、治理和复用」。对 CTO 来说，要回答的问题已经不是选哪个模型，而是重新划分架构里的责任：什么交给模型，什么交给 Skill，什么走 MCP 暴露，什么必须留在确定性的业务系统里。

先把四个词拆开：Agent、Tool、MCP、Skill

智能体这个领域最大的毛病，是不同的概念在营销话术里被压成了同一个词。开会的时候一人一个理解，方案根本没法对齐。先拆开：

**Agent 是决策循环。**围绕目标拿上下文、规划步骤、挑工具、看结果、定下一步。它的核心不是那个聊天框，是模型进入了「判断、行动、反馈」的循环。

**Tool 是原子动作。**查库存、建工单、算报价。它告诉模型「有什么动作可以做」，但不解释一个复杂任务该按什么顺序干。

**MCP 是连接协议。**规定 Host、Client、Server 怎么发现和调用能力。管接口形态，管互操作，别的都不管。

**Skill 是操作手册加工具包。**任务说明、判断规则、脚本、参考资料、输出模板，打包在一起。它回答的是「这类任务应该怎么干」。

一句话记住四者的关系：Agent 决定下一步做什么，Skill 提供做好一类工作的经验，MCP 让外部能力可以被发现和调用，Tool 执行一个具体动作。

这个区分不是抠字眼。MCP 不拥有业务流程，Skill 也不天然拥有执行权限。把它们混着用，最后就会得到一套「能调用很多东西，但没人说得清为什么这样调用」的系统 —— 这种系统我们见过，出了事连排查的入口都找不到。

概念归概念，落地得有实体。上图右列就是这四样东西在太一里对应的四个一等公民，简单说：

概念	太一里的实体	关键设计
Agent	AgentDefinition 落库	purpose 路由不绑厂商、草稿/发布双槽、上岗就绪探针
Skill	SkillRegistry	平台/租户/工作区三层作用域、版本化、双道安审
MCP	McpServerConfig	租户级装卸、凭据加密、工具名统一归一化
Tool	ToolGuard + 沙盒	只读/可逆/不可逆分级、高风险转人工、全轨迹审计

MCP 的真正进步，和我们在生产里踩的四个坑

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。

Skill：把老师傅的经验，变成管得住的资产

过去企业管业务经验的方式，是把它塞进一个越来越长的 System Prompt。流程一变，改提示词；模型一换，重新调。半年之后没人说得清一项能力到底依赖哪些规则、模板和脚本 —— 我们叫它「提示词沼泽」。

Agent Skills 给了另一种组织方式：一个目录，装着 SKILL.md、脚本、参考资料和模板。智能体启动时只读名字和描述，任务匹配上了再加载完整说明。渐进式披露，上下文占用低，能力边界清楚。

但对企业来说，Skill 真正值钱的地方不是省那几百个 token，而是把散在提示词、Wiki 和老师傅脑子里的操作知识，变成有版本、有责任人、有发布流程的制品。举个例子，「合同审核」不该是一句 prompt，它应该长这样：

SKILL.md

code: contract-review

version: 5

scope: 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，结果跨租户删掉了别人的技能。读操作有作用域过滤，不代表写操作也有 —— 两边必须分别验归属。

Java、Python 还是 Node？这题的问法就错了

「智能体该用什么语言写」—— 这个问题本身不成立，三种语言都能做 Agent、做 MCP Client 和 Server。真正该问的是：在你的存量系统、团队能力和风险约束下，哪种语言承担某类责任的综合成本最低。

维度	Java	Python	Node.js / TS
存量优势	核心业务、中台	模型、数据	Web、SaaS 集成
MCP 2.0 SDK	已 GA	beta，别进生产	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 的公司犯不着为「标准架构」引入 Java，Node 系的公司也不用迁移业务系统。控制、智能、交互三类责任有人认领就行 —— 千万别假设某个 Agent 框架会替你把它们都干了。

三平面，而不是三套烟囱

把上一节的分工画成图，就是三平面架构。太一的实际形态长这样：

三平面架构和三套烟囱的全部区别，就在右边那根「纵向贯穿」的柱子上：统一身份从渠道入站到模型调用是同一个人；工具权限按用户和任务上下文算，不是按服务账号算；runId、Skill 版本、Tool Call ID 进同一条审计链。

如果三个平面各建一套用户、一套知识、一套审计，那不叫架构分层，叫重复建设。

真正的风险在协议之外：八道边界

MCP 规范自己都写着：Tool 描述应被视为不可信信息，协议不能强制实现所有安全原则。换句话说，如果你只做到「连接成功」，很可能刚好绕过了原来的安全边界。

我们把一次受治理的工具调用拆成八道边界，每一道在太一里都有对应实现：

对着这张图，说说企业智能体最常见的五类生产风险。

**一，身份丢失。**MCP Server 只看到平台的服务账号，不知道真实用户是谁，结果所有人拿到同一份权限。新的企业授权扩展想靠 IdP 解决，但那是可选扩展，客户端支持还不齐。太一的做法：GovernanceContext 带着 Principal 贯穿全链路；渠道入站的租户身份只认 URL 租户段验签 ——报文里的租户字段是攻击面，不是身份来源。

**二，提示注入变成执行注入。**一段恶意文档就能诱导 Agent 去调转账、发信、删除工具。防线不能只靠模型自己识别：工具白名单加参数策略，匹配前先做归一化 —— 全角字符、变体字符先归一再比对，不然黑名单形同虚设 —— 再加高风险动作强制转人工。

**三，长任务没有业务语义。**新规范的 Tasks 提供了任务句柄和取消，但「取消」可能只是个协作意图，订单到底提没提交，得业务系统用幂等和补偿来回答。轮询侧我们还有一条实测教训：判失败要数连续失败次数，不是总轮询次数—— 数总次数，慢任务会被误杀；不数失败，伪造的任务卡会永远转圈。判据永远是「任务表里有没有新行」，不是「工具有没有被调用过」。

**四，Skill 供应链。**脚本可能越权，资料可能过期，文本可能藏着诱导。像管容器镜像一样管它：版本、依赖清单、两道安审、沙盒分级执行。第 04 节展开过，不重复。

**五，观测只有 token，没有业务结果。**token 数只是技术指标，真正该盯的是任务完成率、人工接管率、错误写入率、单位成功任务的成本。这里有个特别容易全军覆没的细节：流式对话的 usage 藏在结束尾帧里，收尾的时候不解析，token 台账就永远是零—— 你以为在观测，其实什么都没记下。太一在审计上还加了一层 SHA256 哈希链：轨迹不但要有，还得改不了。

这八道边界的验收标准就一句话：审计问「这个结论怎么来的」，你能不能一条 SQL 答出来。能，系统就能进生产；不能，就进不了。

给 CTO 的七条建议，都能当场开干

1**先画能力边界，不先画 Agent 数量。**哪些能力只给内部服务用，哪些需要被 AI 动态发现 —— 只有后一类才值得 MCP 化。

2**给 Tool 做风险分级。**只读、可逆写、不可逆写，分别对应自动执行、条件执行、强制审批。这张策略表一天就能画出来。

3**把 Skill 纳入制品库。**所有者、版本、依赖、权限、评测结果，缺一不上架；带脚本的必须过沙盒动态审查。

4**固定协议和 SDK 版本。**Java 2.0 已 GA，Python 和 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时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～