# 升级

从Spring Starter 推进到 Boot 3.4 后，天塌啦，运行时 Spring Data 不兼容了，一查官方 release note, 几个接口从 Deprcated 变成 Removal, 只能升级了下，瞅了下SDK 当时就报这个警告了，没有当回事。

Spring boot 3.4 后 SDK 升级，暨 UI & API/MCP 计划变化太多，快慢，远近https://mp.weixin.qq.com/s/MfcwubIJ-_Ohlx43wUgMBg

尽量少深层API 依赖，如果单纯"上层" 依赖一般还是不动的多，只能动动小手升级：

最近后端几无更新，其实方法论定好后，以spring/java 的稳态，基本按照版本滚动（Rolling Release）就OK了。

# UI

但是难事又来了，交互又是瓶颈，后端搞定前面客户依然看不见，等不及，为啥迟迟不搞前端，一个是因为前端变快、杂、难，二个对前端的理解还没有达到一个临界点，三个就是 timing;

所以现在到这个点了么？大概5/6成，加点AI 这个料酒，烹好就鲜美无比，但烧坏就可能难以下箸。

最终效果

7~8成生成，提效50%
颜值8分上，不好看没人要
极易上手，AI 助手可能都不需要

关于如何做陌生技术领域解决方案的选择的小建议；这个方向上有很多优秀的解决方案解决者如 jhipster, jmix 等，当下大家可能对AI 生成简单的 landing page 都耳闻目染，但是生成式对负责企业前后端解决方案暂且帮助没有那么大，企业解决方案，急需类似 'RAG' 方式，生成非常合规对齐的前后端。解决方案初步论证没有问题，下面就是出 POC + 落地具体项目，问题不大.....

AI Thing

AI 侧 MCP 最近是火得不得了(MCP(Model Context Protocol) 是个什么东东？)，因为manus 沉寂了，DS 暂且没有后面的Rx，各大厂商急于出来跑马圈地（销售易在腾讯云城市峰会发布了「中国首款AI CRM 」& 这些 AI 创业团队，正在钉钉上长出来）。

搜刮几张 Spring AI 里面关于 MCP 的说明图：

其实都是老技术吧，热衷为爱发电的码农们已经搬运了 2000大几MCP: https://smithery.ai/；但是真正挑战是存量海量企业内部的基础设施，不用说各种企业内部研发的软硬件，单纯内外使用的API 就很大一坨了，所以哪些做 CI/CD, git 服务, API gateway，集成是最方便的! 没有 API，LLM 和 AI agent 如何完成任务呢？No AI without APIs！做了可锦上添花的如 jekins, gitee, gitlab, gitea, kong, apisi etc, 一文讲透 MCP-Apifox MCP Server

做 Api Management, gateway 做这部分集成功能估计就2小时，整个研发工具链上很多地方都可以切入，甚至 vite 也搞了一腿：https://github.com/webfansplz/vite-plugin-vue-mcp :-)

最近 YC 上出的项目 https://wild-card.ai/ Connect AI Agent to any API ；如果你细看他的解决方案，两年前 berkeley 的gorilla已经尝试：

https://github.com/ShishirPatil/gorilla

ApiHug 已经在设计Meta 上支持：面向LLM编程设计LLMOP 让你的接口和代码对LLM更友好！

测试端计入MCP Server 是比较简单的，整个服务群集成 MCP 管理还需要点方式，特别是上下文如何带过去？

a16z

然而，我们只是处于智能体原生架构演化的早期阶段。尽管人们对 MCP 充满热情，但在使用 MCP 构建和发布时也存在许多未解决的问题。

下一个协议迭代中需要解锁的一些内容包括：

1. 托管和多租户

支持一对多的 AI 智能体与其工具之间的关系，但是多租户架构（例如 SaaS 产品）需要支持多个用户同时访问共享的 MCP 服务器。
默认使用远程服务器可能是一个近期的解决方案，以便让 MCP 服务器更加可访问，但许多企业也希望托管自己的 MCP 服务器，并分离数据面和控制面。
支持大规模 MCP 服务器部署和维护的简化工具链是下一个可以促进更广泛采用的关键。

2. 身份验证

MCP 目前没有定义客户端如何向服务器进行身份验证的标准机制，也没有提供 MCP 服务器在与第三方 API 交互时安全管理和委托身份验证的框架。
从开发者的角度来看，统一的方法应该涵盖：
- 客户端身份验证：诸如 OAuth 或 API 令牌等标准方法，用于客户端-服务器交互
- 工具身份验证：用于与第三方 API 进行身份验证的助手函数或包装器
- 多用户身份验证：针对企业部署的租户感知身份验证

3. 授权

即使某一工具已经过身份验证，也需要确定谁被允许使用该工具，以及权限控制的粒度程度。
当前的方法依赖于基于 OAuth 2.1 的授权流程，一旦通过身份验证就会授予整个会话的访问权限。

4. 网关

随着 MCP 采用的扩展，网关可以作为认证、授权、流量管理和工具选择的集中式层。
标准化的网关将简化客户端-服务器交互，提高安全性，并提供更好的可观察性，使 MCP 部署更具可扩展性和可管理性。

5. MCP 服务器可发现性和可用性

目前，找到并设置 MCP 服务器是一个手动过程，集成新服务器是一个耗时的过程。
根据 Anthropic 上个月在 AI 工程师会议上的演讲，似乎即将推出 MCP 服务器注册和发现协议。

6. 执行环境

大多数 AI 工作流程需要在顺序中调用多个工具，但 MCP 缺乏内置的工作流程概念来管理这些步骤。
将有状态执行提升为一等公民的概念将使大多数开发人员的执行模型更加清晰。

7. 标准客户体验

在构建 MCP 客户端时如何考虑工具选择：每个人都需要实现自己的 RAG 来处理工具，还是存在待标准化的层次？
除了工具选择，在调用工具方面也没有统一的 UI/UX 模式（我们看到从命令行到纯自然语言的各种形式）。

8. 调试

对于 MCP 服务器开发人员来说，让同一个 MCP 服务器在各个客户端上顺利运行往往很困难。
需要一套新的工具来使本地和远程环境下的开发体验更加流畅。

AI 工具的影响

MCP 的开发体验让我想起了 2010 年代的 API 开发。这种范式是新颖且令人兴奋的，但工具链仍处于初期阶段。如果我们向前看几年，如果 MCP 成为 AI 驱动工作流程的事实标准会发生什么？一些预测：

开发优先公司的竞争优势将从运送最佳 API 设计转变为也运送用于智能体使用的最佳工具集合。如果 MCP 将能够自主发现工具，API 和 SDK 提供商将需要确保他们的工具易于从搜索中发现，并且足够有特色，使智能体能够为特定任务选择它们。这可能比人类开发人员寻找的要更加细粒度和具体。
如果每个应用程序都成为 MCP 客户端，每个 API 都成为 MCP 服务器，可能会出现一种新的定价模式：智能体可能会根据速度、成本和相关性的组合动态选择工具。这可能会导致一个更加由市场驱动的工具采用过程，该过程选择表现最佳和最模块化的工具，而不是最广泛采用的工具。
随着公司需要设计使用清晰、机器可读的格式（如 llms.txt）的工具和 API，以及将 MCP 服务器作为基于现有文档的事实标准，文档将成为 MCP 基础设施的关键部分。
单单拥有 API 已经不够了，但它们仍是很好的起点。开发人员会发现从 API 到工具的映射很少是 1:1 的。工具是更高级的抽象，能在任务执行时为智能体人提供最合适的选择 --- 与其直接调用 send_email（），智能体人可能会选择 draft_email_and_send（）函数，它包含多个 API 调用以最小化延迟。MCP 服务器设计将以场景和用例为中心，而不是以 API 为中心。
如果每个软件默认都成为 MCP 客户端，那么托管模式将发生新的变化，因为工作负载特征将与传统网站托管不同。每个客户端都将是多步骤的，需要执行保证，如可恢复性、重试和长时间运行的任务管理。托管提供商还需要在不同的 MCP 服务器之间进行实时负载平衡，以优化成本、延迟和性能，让 AI 智能体人能在任何给定时刻选择最高效的工具

MCP 已经在重塑 AI 智能体生态系统，但下一波进展将取决于我们如何解决基础性挑战。如果做得好，MCP 可能成为 AI 与工具互动的默认接口，释放出新一代的自主、多模态和深度集成的 AI 体验。

如果被广泛采用，MCP 可能代表着工具构建、使用和货币化的转变。我们很期待看到市场将它带向何方。今年将是关键：我们是否会看到统一的 MCP 市场的兴起？认证是否会为 AI 智能体变得无缝？多步执行是否能被正式纳入协议？