在过去的几年中，AI Agent 应用的开发方式经历了快速演变。生成式 AI 的高速发展，使得许多我们不久前构建的应用，很快就被视为“遗留系统”。 这正是高速变化时代的典型挑战：知识与工具的迭代频率在短期内异常剧烈，直至逐渐趋于稳定。

以我的经验为例，我们最初为 Unit Mesh 辅助研发体系从零构建了 ChocoBuilder 框架，随后转向基于 Dify/Coze + Shire 本地智能体语言的实践， 近期则进一步为客户搭建了 基于 Spring AI 的 AI Agent 框架体系。

在企业侧，AI Agent 体系的构建面临一系列的挑战，诸如于：

• 如何高效地将企业的现有数据与 API 接入 AI 模型？
• 如何在利用团队既有技能的前提下，避免大规模再培训，就能快速构建智能应用？
• 如何与现有的数据平台、AI 模型和算力资源实现有效协同与整合？

对以 Java 为核心的企业而言，这些挑战又有其独特性：如何将 AI 能力无缝集成到庞大的 Java/JVM 生态中，既兼顾企业既有系统的稳定性， 又能释放生成式 AI 的创新潜力。

AI Agent 应用架构变化

从 2022 年的 LangChain（Chain/Tool/Agent 抽象），到 2023 年的 Semantic Kernel（Skill + Planner 模式），再到 2024 年面向 Java/Spring 生态的 Spring AI，框架演进的核心趋势是：从实验性探索逐渐走向与企业应用体系深度集成，实现从“快速原型”到 “可运维的生产级框架”的过渡。

相似的，开发人员会在不同的场景里试验和构建 AI Agent：

• 直接调用 AI 模型：基于 OpenAI API 或内部 AI 模型平台的简单集成。
• 无知识库问答：利用系统内部数据进行智能问答，尚未涉及外部知识检索。
• 通用 RAG 问答：基于知识检索增强生成（RAG）平台开发，成本与能力要求较高，是大多数企业 AI 应用的主流形式。
• 特定场景 AI Agent：如 AI 辅助研发、自动化开发助手等，针对企业特定业务流程或技术需求定制。

与开发成本巨高的特定场景 AI Agent 相比，业务部门可以直接上手、采购的 AI 平台和通用 RAG 才是主流，也就是 AI 应用平台。

趋势 1：AI 应用平台的低代码“倍增效应”

在企业环境中，低代码并非对专业代码的替代，而是一种强大的倍增器。低代码平台可以快速处理 80% 的通用、重复性任务， 从而让专业开发者能够专注于 20% 的复杂、高价值和性能敏感的逻辑 。

过去，企业知识主要存储在数据中心，由专门的数据团队和平台进行管理。如今，AI 也走上了类似的路径：当需要 RAG 或模型微调时，相关流程都会集成到 AI 应用平台中，其通常具备以下能力：

• 构建 Agents：支持生成式 AI 模型、传统机器学习模型、函数与工具集成等
• 企业数据就绪：数据接入、特征工程、向量索引等
• Agents 的部署与运维：提供 Agent 运行服务、MLOps/LLMOps、数据权限与溯源等
• Agents 的评估与治理：LLM 评测、链路追踪、使用监控、速率限制与 AI 安全防护等

从过去只是提供模型服务，到 Dify、Coze Studio、OneAgent、Copilot Studio 等大量的 B 端 AI 应用平台的崛起，它们已经承接了原来 AI 框架的功能：知识库处理、RAG：检索策略、Embedding、重排策略等，并且可以直接对外提供 AI Workflow 的接口，只需要接入即可。

趋势 2：框架支撑，平台赋能：双轨并行的企业实践

随着越来越多业务直接采用基于 AI 应用平台 的方式，原本依赖 AI 框架（如 LangChain）实现的 RAG 等能力，正在逐渐由平台提供。

如今，很多 AI 应用虽然仍引入 LangChain，但往往只使用 langchain_openai 或 langchain_community 来调用模型接口， 真正的复杂能力已经被平台所吸收。另一方面，像 Copilot Studio 这样的产品，则进一步打通了 低代码与专业开发（ProCode） 之间的鸿沟， 使企业能够在快速构建和部署 AI Agent 的同时，依然保留对核心业务逻辑的精细化控制。

从实践上看，框架与平台并非替代关系，而是分层共存、互为补充：

• 平台通常以内置框架为内核，将框架的最佳实践沉淀为可复用的能力；
• 平台的普及又会反过来推动框架演进，为企业创造更高层次的抽象和更低的使用门槛。
• 框架则在内部承担轻量、可控的开发任务，让企业对模型调用与定制保持灵活度；

即简单的功能可以通过内部框架快速实现，而复杂的编排、协作与落地则交由平台完成，从而实现双轨并行的最佳实践。

趋势 3：流式交互下的 Agent 微服务架构挑战

尽管模型能力提升明显，但在业务场景下仍无法保证 100% 的稳定与准确，因而需要通过 PoC 与渐进式迭代来降低风险。 除此，在将 AI Agent 与现有系统集成的过程中，流式交互带来了新的架构挑战：

1. 响应时延问题：生成式 AI 采用逐 token 输出的方式，完整响应往往需要数十秒，与传统 API 的毫秒级响应差异显著。
2. 连接保持问题：流式 API 通常要求长时间保持连接（约 1 分钟），对现有应用的同步调用模式会带来并发的影响。
3. 系统解耦问题：为避免阻塞和资源占用，需要在前端、Agent 与后端系统之间引入中间层（如事件流、消息队列或网关）进行缓冲和解耦。

在采用 Java 微服务架构里，对于 Python 构建 AI 服务就不存在这个问题了，而如果采用 Java 就需要面临这个挑战：AI 服务和普通应用服务是 否在同一个服务/进程里？？

• 同进程调用直接，但模型的不确定性可能拖垮业务服务，升级耦合度高。
• 独立服务隔离风险，可单独扩缩容和优化流式响应，但需要额外基础设施保障稳定性。

显然，从通用的实践里，直接使用独立服务是一个更好的选择，方便未来重写。

趋势 4：传统 Agent 到 “Agentic AI” 的跃迁

与两年前相比，随着模型对于 Agentic 支持的增强，诸如于推理能力，连续工具调用等。进一步推动了 Agent 向 Agentic AI 的升级，其影响的核心内容包括：

• 代理式推理（Agentic Reasoning）：能够将复杂任务拆解为可管理的子任务，并自主规划执行顺序。
• 工具调用（Tool Use）：Agent 不再局限于预训练知识，而是可动态访问外部 API、数据库或知识图谱，获取实时信息或执行实际操作。

这种转变意味着 AI 不只是“回答问题”，而是成为能够主动协调资源、跨系统执行任务的智能体。在这个背景下，结合 MCP（模型上下文协议）的流行， 企业看到了越来越多的智能可能性：内部的业务服务可以直接转换 AI 能力 —— 诸如直接转换为 MCP Tool。当然，这也不是那么简单的，除了业务本身， 还需要有大量的基础设施，诸如于前面提到的 Agent 的评估与治理。

丰富多彩的 AI Agent 框架

单一框架往往难以满足企业复杂多样的业务需求。例如，一个任务可能同时需要高效的数据检索（RAG）、多智能体协作和与现有业务系统的深度集成。

四类 AI Agent 框架

结合我们使用 Google DeepResearch 的 AI Agent 框架总结，其将其总结为如下的四类：

• 通用编排框架（General Orchestrators）：典型代表是 LangChain。其核心理念是提供一套高度模块化、灵活的“乐高积木”， 允许开发者以链式（Chains）或代理（Agents）的形式自由组合各种组件。它就像一把“瑞士军刀”，为快速原型开发和探索性研究提供了广阔的可能性。
• 多智能体协作框架（Multi-Agent Collaboration）： 以 CrewAI 和 AutoGen 为代表。这类框架的独特之处在于其架构哲学。 它们不将任务视为一个单一流程，而是将其分解为多个具备特定“角色”（role）和“个性”（persona）的智能体之间的协作，从而实现复杂的团队化问题解决。
• 数据与RAG优先框架（Data & RAG-First）：LlamaIndex 是此类别中的佼佼者。这类框架的核心能力在于对外部非结构化或结构化数据的摄取、 索引和检索。它们的设计初衷是解决 LLM 的知识时效性和幻觉问题，通过将外部知识库作为答案来源，确保生成内容的可信度和准确性
• 企业级原生框架（Enterprise-Native）： Semantic Kernel 和 Spring AI 属于此类。它们的共同点是与特定的企业技术栈 （如微软或 Spring 生态系统）深度融合。这类框架将企业级部署所需的稳定性、安全性和可维护性放在首位，通过提供标准化的抽象层和与现有业务逻辑的无缝集成， 降低了 AI 技术在大型组织中落地的门槛。

除此，随着 AI Agent 应用的普及，企业级部署对可观察性（Observability）和安全性（Security）的需求变得日益核心。 智能体的非确定性行为使得传统的调试和监控方法难以应对。因此，像 LangSmith 和 Atla 这样的专门用于跟踪、调试、评估和监控 AI Agent 行为的工具正变得至关重要

企业级框架与平台的核心考量

企业级并非仅指功能完备，更重要的是满足长期可持续性、安全性和可扩展性等非功能性要求。一个强大的 AI 开发框架，如果无法融入现有的企业技术栈管理， 并确保数据安全，那么它在企业环境中将会受到限制。一个理想的企业级 AI 框架和平台应遵循以下四个核心设计原则 ：

• 模块化与分层设计：系统应被分解为独立的功能模块，并按层次组织，以提高灵活性、可维护性和可扩展性。
• 支持多模型能力：平台必须能够无缝集成和管理来自不同提供商的多种AI模型，包括各类LLM及其他机器学习模型，以适应不同业务场景的需求。
• 用户友好的能力编排：平台应提供直观的工具或界面，使开发者和业务人员能够轻松地组合和配置AI能力，以创建复杂的应用或工作流。
• 统一管理：需要一个集中的管理界面，用于处理计费、权限控制、模型版本管理以及安全合规等关键运营任务。

构建企业级 AI 平台往往是一个渐进式、场景驱动的过程。它通常从单一成功用例起步，逐步引入管理和编排能力，最终沉淀为融合多团队经验的完整 AI 生态系统。