最近在做 AI Agent 相关项目时我发现几个词出现频率越来越高Skill、MCP、Agent、Tool、Workflow、Control Plane。问题是这几个概念经常被混在一起。有人把 MCP 叫 Agent。有人把 Skill 当成 Tool。还有人搭了一个 MCP Server就说自己已经做出了 Agent 平台。但如果真正开始用 Java、Spring AI 做工程项目会发现它们其实根本不在同一层。我目前更倾向于用下面这套结构理解Skill → 知道怎么做 MCP → 知道怎么连接外部能力 Agent → 决定接下来做什么 Control Plane → 管理整个执行过程如果再展开一点用户目标 ↓ Agent ↓ Skill / Workflow ↓ Tool Calling ↓ MCP / 本地 Tool / API ↓ 外部系统 Control Plane 横跨整个执行过程 身份 / 权限 / Trace / Cost HITL / Guardrail / Retry 审计 / 风险 / Evaluation这篇就从 Java 开发者的角度把这几层一次拆清楚。一、先从最简单的 Tool Calling 讲起Agent 系统的最小原子其实不是 MCP。而是Tool。比如我们做一个天气查询工具publicclassWeatherTools{Tool(description查询指定城市天气)publicStringgetWeather(Stringcity){returncity25℃晴;}}然后交给 Spring AIStringresponsechatClient.prompt().user(北京今天适合跑步吗).tools(newWeatherTools()).call().content();模型可能先判断用户问的是实时天气 ↓ 需要调用 getWeather ↓ 得到天气结果 ↓ 继续生成最终答案这里有一个很重要的点真正执行 Tool 的不是模型而是你的应用。模型更像是在返回{tool:getWeather,arguments:{city:北京}}最终要不要执行执行什么代码用什么身份执行拥有什么权限执行结果能不能继续交给模型这些仍然由应用层控制。这一点是后面理解 MCP 和 Control Plane 的基础。二、MCP 是什么本质上是 Tool 的标准接口层如果只有一个 Java 项目直接写Tool没什么问题。但很快就会遇到一个现实问题。假设公司里已经有GitHub Tool 数据库 Tool Jira Tool 文件系统 Tool 内部搜索 Tool 订单系统 Tool 企业知识库 Tool难道每一个 Agent 项目都重新集成一遍显然不合理。这就是 MCP 的价值。MCP全称Model Context Protocol可以把它理解成AI 应用访问外部工具和资源的一套标准协议。以前可能是Agent A ├── GitHub SDK ├── MySQL SDK ├── Jira SDK └── Search SDK Agent B ├── GitHub SDK ├── MySQL SDK └── Jira SDK使用 MCP 后更像┌── GitHub MCP Server Agent ─ MCP ──┼── Database MCP Server ├── Jira MCP Server └── Search MCP ServerAgent 不需要特别关心底层到底是REST gRPC Shell JDBC SDK只需要知道这里有一个能力我可以通过 MCP 调用。所以从架构上看MCP 解决的是“连接标准化”。三、Java 里怎么做 MCP ServerSpring AI 已经提供了 MCP Client / Server 支持。假设我们有一个订单查询能力ServicepublicclassOrderMcpTools{McpTool(description查询订单状态)publicStringgetOrderStatus(McpToolParam(description订单ID,requiredtrue)StringorderId){return订单 orderId 已发货;}}原来的业务代码可能是OrderService通过 MCP 封装以后变成OrderService ↓ OrderMcpTools ↓ MCP Server ↓ Claude / Codex / Spring AI Agent这一步做的事情很明确把 Java 业务能力包装成 Agent 可以标准调用的能力。也就是说MCP 并没有让系统突然拥有“自主思考”。它只是解决外部能力怎么暴露、怎么发现、怎么调用。四、MCP 不等于 Agent这是现在最容易混淆的地方。假设我们有这样一组 MCP ToolssearchCode createBranch modifyFile runTest createPullRequest它是不是一个 Agent不是。这只是一组能力。就像锤子 螺丝刀 电钻 扳手放在桌子上并不会自动变成一个装修工。真正的 Agent 至少需要具备这样一个循环理解目标 ↓ 判断下一步 ↓ 选择 Tool ↓ 执行 ↓ 观察结果 ↓ 判断任务是否完成 ↓ 继续下一步比如用户说帮我修复订单服务里的空指针异常并提交 PR。Agent 可能这样执行1. 搜索 Issue / 日志 2. 定位相关代码 3. 阅读调用链 4. 找到潜在空指针 5. 修改代码 6. 运行测试 7. 测试失败 8. 分析失败原因 9. 再次修改 10. 测试通过 11. 创建 Pull Request这里 MCP 解决的是怎么调用 searchCode 怎么调用 modifyFile 怎么调用 runTest 怎么调用 createPullRequest但什么时候调用 先调用哪个 失败以后怎么办 什么时候算任务完成这些属于 Agent 的决策过程。所以为了帮助理解可以简单记成MCP 提供“手”Agent 提供“脑”。当然这只是帮助理解的类比不是严格的协议定义。五、Skill 又是什么Skill 又是另外一层。如果 Tool 是一个原子能力那么 Skill 更接近一套可复用的工作经验、规则和 SOP。例如我们定义一个release-java-serviceSkill里面约定1. 检查 git status 2. 执行 mvn test 3. 检查版本号 4. 更新 CHANGELOG 5. 创建 tag 6. 构建 artifact 7. 创建 GitHub Release那么这里Tool 是什么执行 mvn 读取文件 修改文件 创建 Git Tag 调用 GitHub APISkill 是什么这些 Tool 应该按照什么经验、规则和步骤组合。所以Tool 原子能力 Skill 可复用经验 / SOP这也是为什么我更喜欢把 Skill 理解为Agent 的工程经验包。而不是简单翻译成“技能”。六、Skill 和 Workflow 有什么区别Skill 和 Workflow 也经常被混在一起。我通常会这样区分。Workflow 更强调确定的流程例如A ↓ B ↓ C ↓ D程序会按照预先设计好的流程执行比如读取代码 ↓ 运行测试 ↓ 生成报告 ↓ 发送通知这个流程通常比较固定。Skill 更强调经验和规范比如 Java 服务发布 Skill 可能规定必须先运行测试 必须检查版本号 测试失败必须停止 生产发布必须人工确认 禁止直接修改 main 分支但是实际执行时是否需要额外检查、失败以后先检查哪里、是否需要重新生成 CHANGELOG、是否需要重新运行集成测试Agent 仍然可以动态决定。所以可以先这样理解Workflow 流程编排 Skill 可复用经验与规则 Agent 动态决策者实际生产系统里这三者往往会同时存在。七、把 Tool、MCP、Skill、Agent 放到一张图里到这里关系就比较清楚了用户目标 ↓ Agent ↓ Skill / Workflow ↓ Tool Calling ↓ ┌─────────────┴─────────────┐ ↓ ↓ 本地 Tool MCP ↓ ┌────────┼────────┐ ↓ ↓ ↓ GitHub DB Jira一句话总结Tool 我能做什么 MCP 我怎么标准化连接这些能力 Skill 这类事情通常应该怎么做 Agent 当前到底应该做哪一步但到这里还不够因为真正进入生产以后会出现另外一堆问题。八、Control Plane 到底是什么如果只是在自己电脑上跑一个 Agent你可能暂时感觉不到 Control Plane 的必要性。但是一旦进入生产环境100 个 Agent 500 个 Tool 几十个 MCP Server 20 个模型 多个业务系统问题马上就变了。真正难的问题不再只是Agent 会不会调用 Tool而是谁调用了什么 调用花了多少钱 为什么失败 这个 Agent 是谁 它为什么拥有这个 Tool 权限 它能不能访问生产数据库 这个 MCP Server 当前健康吗 需要人工审批吗 一次任务用了多少 Token 哪个模型成本最高 某次调用链为什么耗时 30 秒 哪一步产生了错误结果这些问题就是 Control Plane 开始出现价值的地方。九、Control Plane 不是一个统一协议这一点需要特别说明。Control Plane 并不像 MCP 一样是一个统一的 Agent 协议标准。它更像是一种工程架构抽象。这个词在 Kubernetes、网络和分布式系统里已经非常常见。例如 Kubernetes 可以粗略理解成Data Plane 负责真正执行工作 Control Plane 负责调度、状态和治理Agent 系统也可以借用这个思路Agent Control Plane ┌────────────────────────────┐ │ Identity / Auth │ │ Tool Permission │ │ Trace │ │ Token / Cost │ │ Guardrail │ │ HITL │ │ Retry │ │ Evaluation │ │ Audit │ │ Policy │ └────────────────────────────┘ ↓ Agent Runtime ↓ MCP / Tool / API / WorkflowAgent Runtime负责真正把任务跑起来。Control Plane负责控制、观察和治理 Agent 的整个运行过程。十、为什么 MCP 越普及反而越需要 Control Plane因为 MCP 在解决一个问题让更多 Tool 更容易被 Agent 使用。但 Tool 越多治理问题越严重。例如一开始 Agent 只有search风险很小。后来逐渐增加database.query github.create_pr slack.send_message k8s.restart payment.refund问题就完全不同了。你必须考虑Agent A 可以用哪些 Tool Agent B 可以用哪些 Tool 测试环境允许调用什么 生产环境允许调用什么 refund 超过 1000 元是否必须人工确认 delete / deploy / payment 是否属于高风险操作 MCP Tool 调用有没有完整 Trace 某个 Token 是否允许写操作 出现异常以后能不能回放整个执行过程所以可以这样总结MCP 解决连接问题Control Plane 解决规模化治理问题。十一、一套完整 Java Agent 系统应该怎么分层如果使用 Spring Boot Spring AI我目前更倾向于这样理解┌─────────────────────────────┐ │ Application │ │ Chat / API / Scheduler │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ Agent │ │ Planning / Decision / Loop │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ Skills │ │ SOP / Rules / Instructions │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ Tool Calling │ │ Spring AI Tool Calling │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ MCP Client Layer │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ MCP Servers │ │ GitHub / DB / Jira / Files │ └─────────────────────────────┘然后在整个运行链路旁边再增加Agent Control Plane ├── Trace ├── Cost ├── Token ├── Permission ├── Guardrail ├── HITL ├── Retry ├── Evaluation └── Audit这基本就是一套生产级 Agent 系统需要考虑的主要部分。十二、用 Java Bug Fix Agent 把所有概念串起来假设我们现在做一个Java Bug Fix Agent用户输入修复订单服务 #1024 Bug并提交 PR。接下来看看每一层分别负责什么。1. AgentAgent 负责理解目标是什么 下一步做什么 什么时候结束 失败以后怎么办2. Skill我们可以给 Agent 一个bug-fix-java-serviceSkill里面规定1. 先读取 Issue 2. 再定位相关代码 3. 修改后必须运行测试 4. 禁止直接 push main 5. 必须创建 feature branch 6. PR 必须包含测试结果这些规则本质上是团队已经积累下来的工程经验。3. MCPMCP Server 提供能力github.get_issue github.create_branch repo.search repo.modify shell.run_test github.create_prAgent 不关心底层到底使用的是 GitHub SDK、Shell 还是 HTTP API它只通过标准 Tool 能力完成操作。4. Agent 执行一次完整任务可能变成get_issue ↓ search ↓ create_branch ↓ modify ↓ run_test ↓ 测试失败 ↓ 分析失败原因 ↓ modify ↓ run_test ↓ 测试成功 ↓ create_pr这就是典型的 Agent Loop。5. Control Plane与此同时Control Plane 可以记录Trace ID: 8f3... Agent: bug-fix-agent Model: xxx Total Token: 84,321 Cost: $x.xx Tool Calls: github.get_issue repo.search github.create_branch repo.modify shell.run_test repo.modify shell.run_test github.create_pr High Risk Operation: create_pr → approved Duration: 4m 21s如果第二天发现这个 Agent 提交的代码有问题至少可以知道当时用了哪个模型 读取了哪些上下文 调用了哪些 Tool 每个 Tool 参数是什么 哪一步失败过 人工批准了什么 最终产生了什么 Diff这就是 Control Plane 真正的价值让 Agent 不再是一个无法解释的黑盒执行器。十三、Java 开发者到底应该先学哪个如果现在开始学习 Agent我建议顺序不要反过来。第一阶段Tool Calling先搞懂模型为什么决定调用函数 参数怎么生成 Tool 在哪里真正执行 执行结果怎么返回模型 Tool 出错以后怎么办Spring AI 的Tool很适合用来入门。第二阶段MCP理解Client Server Tool Resource Transport Auth然后自己尝试用 Java / Spring AI 写一个 MCP Server例如订单查询 MCP、GitHub MCP、数据库 MCP、内部知识库 MCP。第三阶段Agent Loop开始理解Plan Act Observe Retry Stop不要把LLM 一个 Tool就直接叫成完整 Agent 系统。第四阶段Skill / Workflow开始考虑如何把团队已有的经验和 SOP 固化给 Agent例如代码 Review Skill Bug Fix Skill Java Release Skill Incident Response Skill 数据库迁移 Skill第五阶段Control Plane一旦 Agent 开始进入真实业务系统就必须继续考虑Trace Cost Permission HITL Guardrail Evaluation Audit否则系统很容易Demo 能跑生产不敢用。十四、最后用四句话总结如果看完整篇只想记住四句话Skill Agent 应该怎么做 MCP Agent 怎么连接外部能力 Agent 谁来动态决定下一步做什么 Control Plane 谁来保证这些 Agent 可控、可观测、可治理它们不是竞争关系而是一套 Agent 工程里不同层次的问题。最终组合起来大致是User Goal ↓ Agent ↓ Skill ↓ Tool Calling ↓ MCP ↓ External Systems ← Agent Control Plane → Trace / Cost / Auth / HITL Guardrail / Audit / Evaluation很多 Agent Demo 最后无法进入生产并不是模型不够聪明。而是系统只做了LLM Tool却没有继续考虑权限 成本 失败 可观测性 审计 人工介入 风险边界所以我现在越来越觉得真正的 Agent 工程不是让模型会调用更多 Tool。而是在 Agent 能力越来越大的同时仍然能够回答几个非常基本的问题它现在在做什么 为什么这么做 允许它做什么 它花了多少钱 哪一步失败了 谁批准了危险操作 出了问题以后怎么追踪 一次错误最多能影响到哪里这可能才是 Java 开发者从“会接大模型”走向“会做生产级 Agent”真正的分界线。一张表再看懂四者区别概念主要解决的问题可以怎么理解Tool系统具体能执行什么原子能力MCPTool 怎么标准化连接能力接口层Skill一类任务通常应该怎么完成经验 / SOPAgent当前应该执行哪一步动态决策者Workflow固定步骤如何编排流程Control PlaneAgent 如何被治理控制与治理层适合继续深入的几个问题如果已经理解这几个概念后面更值得继续研究的是MCP Server 越来越多以后Tool 权限怎么治理Agent 的 Token 和 Tool Cost 怎么统一归因哪些 Tool 必须 Human in the LoopAgent Trace 应该记录到什么粒度MCP 调用失败以后如何 Retry 和降级Prompt Injection 之后如何阻止 Agent 调用危险 Tool多 Agent 系统需要怎样的 Control PlaneJava / Spring AI 如何实现统一 Agent Event Stream这些问题才会逐渐从“AI Demo”进入真正的Agent Engineering。