企业官网建设流程全解析

1. 四个框架的定位差异与选型逻辑

1.1 先搞清楚它们各自解决什么问题

把 Spring AI、LangChain4j、AgentScope、Embabel 放在一起比较，最容易犯的错误就是拿“功能清单”逐项打勾。我见过太多团队这么干，最后选出来的框架跟实际业务场景根本不匹配。正确的做法是先理解每个框架的设计哲学和它想解决的核心问题。

Spring AI 的定位非常明确：它是 Spring 生态对 AI 能力的标准化封装。如果你已经在用 Spring Boot 做业务系统，Spring AI 提供的价值是让你用熟悉的依赖注入、自动配置、声明式客户端等方式接入大模型能力。它的核心抽象是 ChatClient、EmbeddingClient、VectorStore 这些接口，设计思路跟 Spring Data、Spring Cache 一脉相承。换句话说，Spring AI 不是让你去构建复杂的 Agent 系统，而是让你的 Spring 应用“顺便”具备 AI 能力。

LangChain4j 的野心更大。它是 LangChain 理念在 Java 世界的实现，核心目标是提供一套完整的 LLM 应用开发工具链。从 Prompt 模板管理、对话记忆、RAG 检索增强、工具调用到 Agent 编排，LangChain4j 都有对应的模块。它的 AiServices 抽象允许你把一个接口直接声明成 AI 服务，框架自动帮你处理 Prompt 组装、模型调用、结果解析这些脏活累活。适合需要快速搭建中等复杂度 AI 应用的场景。

AgentScope 走的是另一条路。它从多智能体协作出发，核心关注点是 Agent 之间的消息传递、角色定义、协作流程编排。AgentScope 2.0 版本在 RAG as a Service 和企业级实战方面做了不少增强。如果你的业务场景需要多个 AI 角色分工协作——比如一个负责需求分析、一个负责代码生成、一个负责测试验证——AgentScope 的抽象层次会更贴合这种需求。

Embabel 相对小众，它的设计理念偏向于“AI 工作流引擎”。它试图把 AI 能力编排成可配置的工作流，让非技术人员也能通过配置来定义 AI 的处理流程。这个定位在需要频繁调整 AI 处理逻辑的业务场景中有独特价值。

1.2 选型决策的核心维度

我在实际项目中总结了一套选型判断框架，主要看四个维度：

第一，你的技术栈现状。如果团队已经在用 Spring Boot 全家桶，Spring AI 的接入成本最低。它的自动配置机制能让你在 application.yml 里写完配置就能用，不需要额外搭建基础设施。LangChain4j 虽然也提供了 Spring Boot Starter，但它的核心抽象跟 Spring 的编程模型有差异，团队需要额外学习一套概念体系。

第二，你的 AI 应用复杂度。简单的对话问答、文本分类、Embedding 检索，Spring AI 完全够用。需要多轮对话管理、复杂 RAG 流程、工具调用链，LangChain4j 的模块化设计更有优势。多 Agent 协作、角色扮演、复杂任务分解，AgentScope 是更自然的选择。

第三，团队的学习成本承受能力。Spring AI 对 Spring 开发者几乎零学习成本。LangChain4j 需要理解 Chain、Memory、Retriever 这些概念，大概需要一到两周的熟悉期。AgentScope 的多智能体抽象需要转变思维方式，学习曲线更陡。

第四，社区活跃度和长期维护预期。Spring AI 背靠 VMware/Spring 生态，长期维护有保障。LangChain4j 社区活跃，更新频率高。AgentScope 由阿里团队主导，在国内有较好的社区支持。Embabel 相对小众，选型时需要评估长期维护风险。

1.3 一个常见的选型误区

很多团队在选型时会陷入“功能越多越好”的陷阱。看到 LangChain4j 支持的功能比 Spring AI 多，就觉得应该选 LangChain4j。但实际上，功能多意味着抽象层次多、学习成本高、出问题时排查链路长。

我经历过一个项目，团队用 LangChain4j 做了一个简单的客服问答系统，结果因为 Chain 的嵌套层次太深，一个简单的 Prompt 修改需要改三个地方才能生效。后来换成 Spring AI，代码量减少了百分之四十，维护效率反而更高。

选型的核心原则是：用最简单的工具解决当前的问题，同时预留升级路径。如果 Spring AI 能满足你未来半年的需求，就不要因为“以后可能需要”而选择更复杂的框架。框架迁移的成本远低于过度设计带来的持续维护成本。

2. 核心能力横向对比与实操验证

2.1 模型接入与配置管理

四个框架在模型接入方面的设计思路差异很大，直接影响到日常开发体验。

Spring AI 的模型接入通过 Starter 机制实现。你只需要在 pom.xml 中引入对应的 Starter，然后在 application.yml 中配置 API Key 和模型参数即可。比如接入 OpenAI：

spring: ai: openai: api-key: ${OPENAI_API_KEY} chat: options: model: gpt-4o temperature: 0.7

这种配置方式对 Spring 开发者来说非常自然。切换模型提供商时，只需要替换 Starter 依赖和配置项，业务代码基本不需要改动。Spring AI 还支持通过 ChatClient 的 builder 模式在代码中动态调整参数，灵活性足够应对大多数场景。

LangChain4j 的模型接入需要通过 ChatLanguageModel 接口手动构建实例：

ChatLanguageModel model = OpenAiChatModel.builder() .apiKey(System.getenv("OPENAI_API_KEY")) .modelName("gpt-4o") .temperature(0.7) .build();

这种方式更灵活，但也意味着更多的样板代码。LangChain4j 同样提供了 Spring Boot Starter，可以简化配置，但核心的模型实例管理还是需要开发者自己控制生命周期。

AgentScope 的模型配置围绕 Agent 展开。每个 Agent 可以配置独立的模型参数，这在多 Agent 场景下很有用——比如让负责创意生成的 Agent 用高 temperature，让负责事实核查的 Agent 用低 temperature。配置方式偏向代码化，通过 Agent 的构造函数传入模型配置。

Embabel 的模型配置走的是工作流定义路线。你需要在工作流配置文件中声明每个节点使用的模型和参数，框架根据配置自动路由请求。这种方式适合需要频繁调整模型策略的场景，但灵活性受限于框架支持的配置项。

2.2 RAG 能力的实现差异

RAG 是目前 AI 应用中最常用的模式之一，四个框架在这方面的支持程度差异明显。

Spring AI 提供了完整的 RAG 基础组件：DocumentReader、TextSplitter、EmbeddingClient、VectorStore、Retriever。你可以像搭积木一样组合这些组件。比如一个典型的 RAG 流程：

// 读取文档 List<Document> documents = new TextReader(resource).get(); // 分割文本 TextSplitter splitter = new TokenTextSplitter(500, 100); List<Document> chunks = splitter.apply(documents); // 向量化并存储 vectorStore.add(chunks); // 检索 List<Document> relevant = vectorStore.similaritySearch( SearchRequest.query(question).withTopK(5) );

Spring AI 的 RAG 组件设计得很干净，每个环节的职责清晰。但它的 TextSplitter 策略相对基础，对于复杂文档结构（如表格、代码块）的处理需要自己扩展。

LangChain4j 的 RAG 支持更加成熟。它提供了多种 DocumentLoader（支持 PDF、Word、网页等格式）、多种 TextSplitter（按段落、按句子、递归分割等）、以及 EmbeddingStore 的多种实现（内存、Redis、PgVector 等）。LangChain4j 还内置了 RetrievalAugmentor，可以自动完成“检索-增强-生成”的完整流程：

RetrievalAugmentor augmentor = DefaultRetrievalAugmentor.builder() .contentRetriever(EmbeddingStoreContentRetriever.builder() .embeddingStore(embeddingStore) .embeddingModel(embeddingModel) .maxResults(5) .minScore(0.7) .build()) .build(); AiServices.builder(Assistant.class) .chatLanguageModel(model) .retrievalAugmentor(augmentor) .build();

这种声明式的 RAG 配置大大减少了样板代码。LangChain4j 还支持 QueryTransformer、ContentAggregator 等高级组件，可以处理更复杂的检索场景。

AgentScope 2.0 在 RAG as a Service 方面做了专门优化。它把 RAG 能力封装成独立的服务，Agent 可以通过标准接口调用。这种设计在多 Agent 场景下很有优势——多个 Agent 可以共享同一个 RAG 服务，避免重复建设。AgentScope 的 RAG 服务支持动态知识库切换，适合需要根据不同任务加载不同知识库的场景。

Embabel 的 RAG 能力集成在工作流中。你可以在工作流的任意节点插入检索步骤，检索结果自动传递给后续节点。这种方式适合把 RAG 作为工作流的一个环节来使用，但缺乏对检索策略的细粒度控制。

2.3 Agent 编排能力的实战对比

Agent 编排是当前 AI 应用开发的热点，也是四个框架差异最大的领域。

Spring AI 在 Agent 编排方面相对克制。它提供了 ToolCallback 机制，让模型可以调用预定义的工具函数。但 Spring AI 本身不提供多 Agent 协作、任务分解、角色管理等高级编排能力。如果你需要这些，得自己在上层实现。Spring AI Alibaba 在这方面做了一些扩展，提供了 NL2SQL 等场景化能力，但整体上 Spring AI 的定位还是“AI 能力提供者”而非“Agent 编排框架”。

LangChain4j 提供了 AiServices 和 Chain 两套编排机制。AiServices 适合定义单个 AI 服务接口，Chain 适合构建线性的处理流程。LangChain4j 也支持 Tool 调用和简单的 Agent 循环，但在多 Agent 协作方面支持有限。如果你需要复杂的 Agent 协作，LangChain4j 需要配合其他框架使用。

AgentScope 是四个框架中唯一原生支持多 Agent 协作的。它提供了 Msg、Agent、Pipeline 等核心抽象。你可以定义多个 Agent，每个 Agent 有自己的角色描述、模型配置、工具集，然后通过 Pipeline 编排它们的协作流程：

Agent planner = new Agent("planner", "负责分解任务"); Agent executor = new Agent("executor", "负责执行具体任务"); Agent reviewer = new Agent("reviewer", "负责审核结果"); Pipeline pipeline = new SequentialPipeline(planner, executor, reviewer); Msg result = pipeline.run(new Msg("user", "完成一个数据分析报告"));

AgentScope 2.0 还支持更复杂的协作模式，如辩论、投票、层级协作等。它的消息传递机制设计得很灵活，支持同步和异步两种模式。在企业级实战中，AgentScope 的分布式部署能力也是一个加分项。

Embabel 的 Agent 编排走的是可视化工作流路线。你通过配置文件定义工作流的节点和连线，每个节点可以是一个 Agent、一个工具调用、或者一个条件判断。这种方式降低了编排的技术门槛，但灵活性和表达能力受限于框架的设计。

2.4 可观测性与调试体验

AI 应用的可观测性经常被忽视，但在实际运维中至关重要。

Spring AI 集成了 Micrometer 和 Spring Boot Actuator，可以自动暴露模型调用的耗时、Token 消耗、错误率等指标。配合 Spring Boot 的日志体系，排查问题比较方便。Spring AI 还支持通过 ChatClient 的 advisor 机制插入自定义的拦截逻辑，方便做请求响应日志。

LangChain4j 提供了 ChatModelListener 接口，可以监听模型调用前后的状态。它的日志输出比较详细，包括完整的 Prompt 和响应内容。但在指标暴露方面需要自己集成 Micrometer 或其他监控系统。

AgentScope 的可观测性围绕 Agent 的消息流转设计。它记录了每个 Agent 的输入输出、处理耗时、状态变化等信息。在多 Agent 场景下，AgentScope 提供了消息追踪能力，可以看到一条消息在多个 Agent 之间的流转路径。这对调试复杂的协作流程很有帮助。

Embabel 的可观测性主要体现在工作流的执行状态上。你可以看到每个节点的执行结果和耗时，但细粒度的模型调用信息需要额外配置。

3. 不同业务场景下的选型建议

3.1 Spring Boot 业务系统集成 AI 能力

这是最常见的场景：已有的 Spring Boot 业务系统需要增加 AI 功能，比如智能客服、文档摘要、语义搜索等。

首选 Spring AI。理由很直接：接入成本最低，与现有技术栈无缝集成。你不需要改变项目的依赖注入方式、配置管理方式、测试方式。Spring AI 的 ChatClient 可以像其他 Spring Bean 一样注入到 Service 中，EmbeddingClient 和 VectorStore 也可以直接使用。

我做过一个餐饮 SaaS 系统的 AI 集成，需求是给商户提供智能菜品描述生成和评价情感分析。用 Spring AI 大概两天就完成了核心功能开发。ChatClient 负责生成描述，EmbeddingClient 配合 PgVector 做评价的语义聚类。整个过程中没有引入任何新的编程范式，团队其他成员也能快速理解和维护。

如果这个场景用 LangChain4j，虽然功能上完全能实现，但需要额外引入 Chain、Memory 等概念，代码风格跟现有 Spring 代码不一致，增加了团队的认知负担。

3.2 中等复杂度的 AI 应用开发

如果你的项目核心就是 AI 能力，需要构建包含多轮对话、RAG、工具调用的完整应用，LangChain4j 是更合适的选择。

LangChain4j 的 AiServices 抽象能大幅减少样板代码。你只需要定义一个接口：

interface CustomerServiceBot { @SystemMessage("你是一个专业的客服助手，用友好的语气回答用户问题") String chat(@MemoryId String sessionId, @UserMessage String message); }

框架自动处理对话记忆、Prompt 组装、模型调用、结果解析。配合 RetrievalAugmentor，RAG 流程也能声明式地配置好。LangChain4j 的模块化设计让你可以按需引入组件，不会像 Spring AI 那样受限于框架的抽象层次。

LangChain4j 的 RAG 能力在四个框架中最成熟。它支持的文档格式最多，分割策略最丰富，向量存储的集成最广泛。如果你的应用核心是知识库问答，LangChain4j 能帮你省下大量底层开发时间。

3.3 多 Agent 协作与复杂任务分解

当你的业务需要多个 AI 角色分工协作时，AgentScope 的优势就体现出来了。

我参与过一个智能投研报告生成的项目，需求是让 AI 自动完成“数据收集-数据分析-报告撰写-事实核查”的完整流程。用 AgentScope 定义了四个 Agent，每个 Agent 负责一个环节，通过 Pipeline 串联。AgentScope 的消息传递机制让 Agent 之间的数据流转很自然，每个 Agent 可以独立配置模型和工具。

AgentScope 2.0 的企业级实战能力也值得关注。它支持 Agent 的分布式部署，可以把不同的 Agent 部署在不同的服务实例上，通过消息队列通信。这在需要横向扩展的场景下很有价值。

但 AgentScope 的学习曲线确实更陡。你需要理解它的消息模型、Agent 生命周期、Pipeline 编排等概念。如果团队没有多 Agent 开发经验，建议先从小规模场景开始验证。

3.4 需要频繁调整 AI 处理流程的场景

Embabel 的定位比较特殊，它适合那些 AI 处理流程需要频繁调整、且希望非技术人员也能参与配置的场景。

比如内容审核场景，审核规则经常变化，用 Embabel 可以把审核流程定义成工作流，运营人员通过修改配置就能调整审核策略，不需要开发人员介入。但这种灵活性的代价是表达能力的限制——复杂的分支逻辑、动态的 Agent 选择等，Embabel 的支持有限。

3.5 选型决策速查表

4. 实操中的常见问题与避坑经验

4.1 依赖冲突与版本管理

Spring AI 和 LangChain4j 都依赖大量的第三方库，版本冲突是常见问题。Spring AI 通过 Spring Boot 的依赖管理机制统一版本，相对省心。LangChain4j 的模块较多，不同模块之间的版本需要手动对齐。

我的经验是：使用 LangChain4j 时，在 pom.xml 中显式声明 langchain4j-bom 的 dependencyManagement，统一管理所有 LangChain4j 模块的版本。这样可以避免模块间版本不一致导致的运行时错误。

AgentScope 的依赖相对独立，冲突较少。但它对 Java 版本有要求，AgentScope 2.0 需要 Java 17 及以上。如果项目还在用 Java 8 或 11，需要先升级 JDK。

4.2 模型调用的超时与重试

AI 模型调用的延迟波动很大，超时和重试策略直接影响用户体验。

Spring AI 通过 RestClient 或 WebClient 发起模型调用，可以配置连接超时和读取超时。建议读取超时设置在 30 到 60 秒之间，具体取决于模型和 Prompt 长度。重试策略建议使用指数退避，避免短时间内大量重试压垮模型服务。

LangChain4j 的模型调用超时通过 ChatLanguageModel 的配置项设置。它内置了简单的重试机制，但功能有限。对于生产环境，建议在 AiServices 外层包装自己的重试逻辑，结合熔断器使用。

AgentScope 的模型调用超时可以在 Agent 级别配置。在多 Agent 场景下，建议给每个 Agent 设置不同的超时时间——负责简单任务的 Agent 超时短一些，负责复杂推理的 Agent 超时长一些。

4.3 RAG 检索质量优化

RAG 的检索质量直接决定最终回答的准确性。四个框架都提供了基础检索能力，但优化需要自己动手。

分块策略是关键。我试过固定大小的分块、按段落分块、按语义分块，效果差异很大。对于技术文档，按标题层级分块效果最好；对于对话记录，按对话轮次分块更合理。LangChain4j 提供了 DocumentByParagraphSplitter、DocumentBySentenceSplitter 等多种策略，建议根据文档类型选择。

混合检索往往比纯向量检索效果好。向量检索擅长语义匹配，但对关键词精确匹配不敏感。结合 BM25 等关键词检索做混合排序，能显著提升召回质量。LangChain4j 支持自定义 ContentRetriever，可以集成 Elasticsearch 等支持混合检索的存储。

重排序是提升精度的有效手段。先检索出较多候选（如 20 条），再用重排序模型精选出最相关的几条（如 5 条）传给模型。LangChain4j 的 ScoringModel 接口可以集成 Cohere Rerank 等重排序服务。

4.4 多 Agent 协作中的消息管理

AgentScope 的多 Agent 协作中，消息管理是最容易出问题的地方。

消息格式要统一。不同 Agent 之间传递的消息建议使用统一的结构，包含发送者、接收者、消息类型、内容、时间戳等字段。AgentScope 的 Msg 类提供了基础结构，但业务相关的元数据需要自己扩展。

避免消息风暴。多个 Agent 互相发送消息时，容易出现消息指数级增长。建议在 Pipeline 层面设置消息数量上限和超时时间，防止无限循环。

状态管理要清晰。每个 Agent 可能有自己的状态（如对话历史、任务进度）。AgentScope 提供了状态管理机制，但需要开发者明确哪些状态需要持久化、哪些可以丢弃。我的经验是：只持久化跨会话需要保留的状态，会话内的临时状态尽量放在内存中。

4.5 常见问题速查表

4.6 性能优化的几个实用技巧

Prompt 缓存。如果系统 Prompt 很长且固定，可以利用模型的 Prompt 缓存能力减少 Token 消耗和延迟。Spring AI 和 LangChain4j 都支持在请求中标记可缓存的 Prompt 部分。

批量 Embedding。向量化大量文档时，使用批量接口比逐条调用效率高得多。LangChain4j 的 EmbeddingModel 支持批量输入，建议每批 50 到 100 条。

异步调用。多个独立的模型调用可以并行执行。Spring AI 的 ChatClient 支持返回 CompletableFuture，LangChain4j 也提供了异步接口。在多 Agent 场景下，AgentScope 的异步消息传递能显著提升吞吐量。

向量索引优化。向量检索的性能跟索引类型和参数密切相关。PgVector 的 HNSW 索引在召回率和速度之间平衡得比较好，建议设置 m=16、ef_construction=64 作为起点，根据实际数据量调整。

4.7 从 Spring AI 迁移到 LangChain4j 的注意事项

有些团队一开始用 Spring AI 快速验证，后来发现需要更复杂的 RAG 或 Agent 能力，考虑迁移到 LangChain4j。这个过程有几个坑需要注意。

模型配置的迁移。Spring AI 的配置在 application.yml 中，LangChain4j 的模型实例需要手动构建。建议把模型配置抽取成独立的配置类，方便统一管理。

对话记忆的迁移。Spring AI 的 ChatMemory 和 LangChain4j 的 ChatMemory 接口不同。迁移时需要把历史对话数据转换成 LangChain4j 的格式。如果历史数据量大，建议写一个转换工具批量处理。

RAG 流程的重构。Spring AI 的 RAG 是手动组合组件，LangChain4j 是声明式配置。迁移时不是简单的代码替换，而是流程的重新设计。建议先在测试环境验证新的 RAG 流程效果，确认后再切换。

测试用例的适配。两个框架的 API 不同，单元测试和集成测试都需要调整。建议在迁移前先补充端到端的集成测试，确保迁移后功能行为一致。

5. 框架组合使用的可能性

5.1 Spring AI 加 LangChain4j 的混合方案

Spring AI 和 LangChain4j 并不是互斥的。在实际项目中，我见过一些团队同时使用两者：用 Spring AI 处理与 Spring 生态紧密集成的部分（如配置管理、监控指标），用 LangChain4j 处理复杂的 RAG 和 Agent 逻辑。

这种混合方案的关键是明确边界。比如：Spring AI 的 ChatClient 负责简单的对话调用，LangChain4j 的 AiServices 负责需要 RAG 增强的复杂问答。两者共享同一个模型配置和向量存储。

但混合使用也带来了依赖管理和概念一致性的问题。如果团队规模不大，建议还是选一个主力框架，避免维护两套体系。

5.2 AgentScope 作为编排层

另一种常见的组合是：用 Spring AI 或 LangChain4j 提供基础的 AI 能力，用 AgentScope 做上层编排。

AgentScope 的 Agent 可以调用外部的 AI 服务。你可以把 Spring AI 的 ChatClient 封装成 AgentScope 的工具，让 Agent 在需要时调用。这样既利用了 Spring AI 的生态优势，又获得了 AgentScope 的多 Agent 协作能力。

这种架构的复杂度较高，适合对 AI 应用有长期规划、团队技术储备充足的场景。对于大多数项目，我还是建议先用单一框架把核心功能跑通，再根据实际需求考虑是否引入编排层。

5.3 选型后的技术演进路径

无论选择哪个框架，都建议预留技术演进的空间。具体做法包括：

抽象模型调用层。不要在业务代码中直接依赖具体框架的 API，而是定义自己的 ModelService 接口，框架相关的实现放在独立的适配器类中。这样将来更换框架时，只需要替换适配器实现。

标准化 Prompt 管理。Prompt 是 AI 应用的核心资产。建议把 Prompt 模板统一管理，不要散落在代码各处。可以使用数据库或配置中心存储 Prompt，方便版本管理和动态调整。

可观测性先行。在项目初期就接入监控和日志系统，记录模型调用的关键指标。这些数据是后续优化和选型评估的重要依据。

小步验证。不要一次性把所有 AI 功能都押在一个框架上。先选一个非核心场景做试点，验证框架的稳定性、性能和开发效率，再决定是否扩大使用范围。

5.4 一个真实的选型复盘

最后分享一个我参与过的项目选型过程。项目背景是给一个法律咨询平台开发智能问答系统，需求包括：法条检索、案例匹配、多轮咨询、答案引用来源。

最初团队想用 LangChain4j，因为它的 RAG 能力最成熟。但在 PoC 阶段发现两个问题：一是法条文档的结构化程度很高，LangChain4j 的通用分块策略效果不理想；二是多轮咨询需要跟踪用户意图的变化，LangChain4j 的 Memory 机制不够灵活。

后来改用 Spring AI 加自定义 RAG 流程。用 Spring AI 的 VectorStore 做基础检索，自己实现了基于法条编号的分块策略和基于用户意图的检索路由。多轮咨询的状态管理用 Spring 的 Session 机制实现。最终效果比预期好，开发周期也比用 LangChain4j 短。

这个案例说明：框架的能力清单只是参考，实际效果取决于跟业务场景的匹配度。有时候用简单框架加自定义实现，比用复杂框架加大量配置调整更高效。

5.5 给不同阶段团队的建议

初创团队或 AI 新手团队：从 Spring AI 开始。它的学习成本最低，能让你快速看到效果，建立对 AI 应用开发的直观理解。等遇到 Spring AI 解决不了的问题时，再考虑其他框架。

有 AI 开发经验的团队：根据项目需求在 LangChain4j 和 AgentScope 之间选择。如果核心是 RAG 和对话，选 LangChain4j；如果核心是多 Agent 协作，选 AgentScope。

企业级平台团队：可以考虑组合方案。用 Spring AI 做基础能力层，用 AgentScope 做编排层，用 LangChain4j 补充特定的 RAG 能力。但前提是团队有足够的技术储备来维护这套体系。

需要快速交付的项目：选 Spring AI。它的开发效率最高，代码量最少，出问题时排查也最简单。不要为了“技术先进性”而选择更复杂的框架。

需要长期演进的平台：选 LangChain4j 或 AgentScope。它们的抽象层次更高，扩展性更好，适合作为长期技术底座。但要做好持续学习和版本升级的准备。

我在实际项目中的体会是，框架选型没有绝对的对错，关键是匹配团队能力和业务需求。与其花大量时间做框架对比，不如选一个看起来合理的，快速做出原型，用实际效果来验证。毕竟，AI 应用开发的核心挑战在于 Prompt 工程、数据质量和业务理解，框架只是工具。工具趁手就好，不必追求最新最全。