Agent

一个 2024 年 3 月就提出的 Agent 支持请求，两年后才进入正式路标。在 AI 领域，两年约等于一个纪元。 背景：Spring AI 的速度与节奏 2026 年 6 月 12 日，Spring AI 2.0.0 正式 GA。这是一个标志性节点——Spring 生态完成了 AI 工程化的基础设施铺设：ChatClient API、Tool Calling、MCP 协议支持、Vector Store 抽象、Advisors 管道、Structured Output……该有的积木块都有了。 但如果你一直在关注 AI 应用开发，你会发现一个明显的缺口：Agent。 LangChain 2023 年就推出了 Agents 模块。LangGraph 把有状态的多步 Agent 编排做成了核心卖点。AutoGen、CrewAI、OpenAI Swarm、Dify、Coze……Agent 框架百花齐放。Python 生态已经把 Agent 从概念跑到了生产落地。 而 Spring AI 呢？在这方面的动作可以用两个字概括：沉默。 看看这些时间节点： 2023 年 10 月：社区开发者提交 #607，带来了基于 Spring AI 的 Agent 框架（spring-ai-collab），官方没有采纳 2024 年 3 月：#403 提出Agent 支持，原文是"Implement Agent like in Langchain with different methods, such as CoT, ReACT"——两年零三个月后才进入 2.1.x milestone 2025 年 8 月：#4017 再次追问"Spring AI 是否有 Agent 计划？ReAct、plan-exec-replan、reflection 这些在 Python 生态已经成熟"，官方回应：在考虑中 2025 年 10 月：PR #4622 引入 ToolCallAdvisor 和 StructuredOutputValidationAdvisor——这是 Agent 雏形，但还远不是 Agent 框架 2026 年 6 月：2.0.0 GA，Agent 支持被正式放入 2.1.x 路标 两年。 在 AI 领域，两年意味着什么？GPT-3.5 → GPT-4 → GPT-4o → o1 → o3 → GPT-4.1，整整三代模型迭代。Claude 从 1 到 3.7 Sonnet。开源阵营从 LLaMA 1 跑到了 DeepSeek R1。整个 Agent 概念从 ReAct 论文（2022年）演进到了 AI Employee、Devin、Computer Use。 ...

今天，几乎所有的 AI Agent 都需要"动手"——写代码、查数据库、操作文件系统、调用 API。Agent 不能只思考，必须行动。而行动，就需要工具。 目前，Agent 获取工具有两条路径：CLI（命令行） 和 MCP（Model Context Protocol）。这不是两种"人机交互方式"的对比——在 Agent 场景下，人是退到幕后的。这是同一个 Agent 的两种工具接入模式，它们决定了 Agent 能做什么、怎么做、以及做的时候有多安全。 这篇文章要回答一个核心问题：当 Agent 需要操作外部世界，CLI 和 MCP 分别给了它什么？两者如何共存？ 一、Agent 需要什么样的工具接口 在讨论 CLI 和 MCP 之前，先理解 Agent 对工具接口的核心需求： 可发现性：Agent 需要知道"我能做什么" Agent 的第一个问题永远是：我现在有哪些工具可用？ 如果 Agent 不知道自己有 git 命令，它就不会尝试提交代码。如果 Agent 不知道有一个"查询订单数据库"的 MCP Tool，它就不会去查。工具的可发现性决定了 Agent 能力的天花板。 可组合性：Agent 需要把多个工具串起来 Agent 很少只用一个工具完成任务。“查一下最近的 bug 报告，然后写个修复，再跑一遍测试”——这涉及数据库查询、文件编辑、命令执行三个工具的组合。 工具之间能否无缝组合，决定了 Agent 是"能干活"还是"只能做单步操作"。 可靠性：Agent 需要可预测的执行结果 Agent 做决策的前提是：如果我调用这个工具，我会得到什么。工具返回结果的格式越确定，Agent 的推理越可靠。 一个返回结构化 JSON 的工具，和一个输出格式随心情变化的命令行工具，对 Agent 来说是天壤之别。 安全性：Agent 需要被约束 Agent 拿到工具就像人拿到车钥匙——你希望它开车去超市，不希望它飙车撞墙。工具接口的设计决定了你能给 Agent 多大的自由度，以及出事时能不能兜住。 ...

2026年2月，一个让开发者困惑的消息：OpenAI 收编了 OpenClaw。 困惑的点在于——这项目看起来没技术含量：调用 LLM API、连 WhatsApp、操作文件，哪一项不是现成的技术？凭什么 Meta、xAI 都要抢，扎克伯格亲自下场？ 更让人不解的是，Peter Steinberger 本人也说：这只是一个周末业余项目，用 Codex 几个月就写出来了。 如果技术不是重点，那巨头到底在抢什么？ 一、一个反直觉的开场 在回答这个问题之前，让我们先看一个有趣的平行案例。 Sam Altman 在回顾 OpenAI 十年历程时说过一句话： “我觉得站在创新前沿的代价就是你会犯很多蠢错误，因为你深陷战争迷雾之中。” 这句话看似在解释失败，实则揭示了创新的本质——真正有价值的发现，往往来自"在黑暗中摸索直到找到光"。 OpenAI 的成功产品 ChatGPT，按 Altman 自己的说法，“确实是个意外”。他们原本计划用 GPT-4 发布聊天产品，但担心"同时推出会像是通过了图灵测试"，才先用 GPT-3.5 试水。 这个"意外"改变了世界。 这个故事和 OpenClaw 有什么关系？ 关系在于：两者都揭示了一个被忽视的真相——在 AI 时代，技术正在快速商品化，真正稀缺的是对场景的洞察力。 二、Peter 的选择：一个清醒的判断 2026年2月14日，情人节。Peter Steinberger 在博客上宣布加入 OpenAI。 很多人困惑：OpenClaw 不是正火吗？GitHub 19.6 万颗星，三个月。三大云争相上线一键部署，网易直接推出国产版。整条产业链两周内形成。 这么火，为什么要走？ Peter 的解释是：他想让他妈妈也能用上 Agent，加入 OpenAI 是最快的路。 这个解释很坦诚，但它掩盖了一个更深的逻辑：OpenClaw 所在的那一层，正在被吸收。 不是 OpenClaw 不好。恰恰相反，正因为 OpenClaw 太好了，它证明了"个人 Agent 编排"这件事是可行的，于是 OpenAI、Anthropic、Google 都开始亲自下场做同样的事。 当最顶级的玩家开始认真做一件事，独立创业者就没有空间了。 Peter 选择加入 OpenAI，某种程度上是一个清醒的判断：与其在一个正在被吸收的层里继续建造，不如去更高的地方。 ...

前言 AI Agent 正在成为软件架构的重要组件。但如何让 Agent 能够被远程访问，是一个容易被低估的技术决策。 不同的协议选择，会直接影响： 用户体验：延迟、流畅度 开发成本：实现难度、调试复杂度 运维成本：资源占用、可扩展性 应用场景：能做什么、不能做什么 本文从技术角度深度分析几种主流协议，帮助你做出最佳选择。 协议全景图 ┌─────────────┬──────────────┬──────────────┬─────────────┐ │ 协议 │ 连接类型 │ 通信模式 │ 适用场景 │ ├─────────────┼──────────────┼──────────────┼─────────────┤ │ HTTP/REST │ 短连接 │ 请求-响应 │ API 服务 │ │ WebSocket │ 长连接 │ 全双工 │ 实时交互 │ │ SSE │ 长连接 │ 单向推送 │ 流式输出 │ │ gRPC │ 长连接 │ 全双工 │ 内部服务 │ │ SSH │ 长连接 │ 终端交互 │ CLI 工具 │ └─────────────┴──────────────┴──────────────┴─────────────┘ 一、HTTP/HTTPS + RESTful API 1.1 工作原理 最传统的方式。客户端发送 HTTP 请求，服务器返回 Agent 的响应。 ...