企业官网建设流程全解析

最近在做 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){returncity+"：25℃，晴";}}

然后交给 Spring AI：

Stringresponse=chatClient.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 Server

Agent 不需要特别关心底层到底是：

REST gRPC Shell JDBC SDK

只需要知道：

这里有一个能力，我可以通过 MCP 调用。

所以从架构上看：

MCP 解决的是“连接标准化”。

三、Java 里怎么做 MCP Server？

Spring AI 已经提供了 MCP Client / Server 支持。

假设我们有一个订单查询能力：

@ServicepublicclassOrderMcpTools{@McpTool(description="查询订单状态")publicStringgetOrderStatus(@McpToolParam(description="订单ID",required=true)StringorderId){return"订单 "+orderId+" 已发货";}}

原来的业务代码可能是：

OrderService

通过 MCP 封装以后变成：

OrderService ↓ OrderMcpTools ↓ MCP Server ↓ Claude / Codex / Spring AI Agent

这一步做的事情很明确：

把 Java 业务能力包装成 Agent 可以标准调用的能力。

也就是说，MCP 并没有让系统突然拥有“自主思考”。

它只是解决：

外部能力怎么暴露、怎么发现、怎么调用。

四、MCP 不等于 Agent

这是现在最容易混淆的地方。

假设我们有这样一组 MCP Tools：

searchCode 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 API

Skill 是什么？

这些 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 / Workflow

Agent 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. Agent

Agent 负责理解：

目标是什么？ 下一步做什么？ 什么时候结束？ 失败以后怎么办？

2. Skill

我们可以给 Agent 一个bug-fix-java-serviceSkill，里面规定：

1. 先读取 Issue 2. 再定位相关代码 3. 修改后必须运行测试 4. 禁止直接 push main 5. 必须创建 feature branch 6. PR 必须包含测试结果

这些规则本质上是团队已经积累下来的工程经验。

3. MCP

MCP Server 提供能力：

github.get_issue github.create_branch repo.search repo.modify shell.run_test github.create_pr

Agent 不关心底层到底使用的是 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”真正的分界线。

一张表再看懂四者区别

适合继续深入的几个问题

如果已经理解这几个概念，后面更值得继续研究的是：

1. MCP Server 越来越多以后，Tool 权限怎么治理？
2. Agent 的 Token 和 Tool Cost 怎么统一归因？
3. 哪些 Tool 必须 Human in the Loop？
4. Agent Trace 应该记录到什么粒度？
5. MCP 调用失败以后如何 Retry 和降级？
6. Prompt Injection 之后如何阻止 Agent 调用危险 Tool？
7. 多 Agent 系统需要怎样的 Control Plane？
8. Java / Spring AI 如何实现统一 Agent Event Stream？

这些问题，才会逐渐从“AI Demo”进入真正的Agent Engineering。