1. 为什么我们需要重新审视 AI 应用开发的工程化底座做 AI 应用开发的人都有一个共同的感受模型能力越来越强但把模型能力变成稳定可用的产品中间的鸿沟反而越来越大。我最早做 AI 应用的时候一个简单的问答机器人代码里硬编码几个提示词调一个模型接口前端套个对话框就上线了。那时候觉得挺简单。但后来需求开始膨胀——要接多个模型供应商做容灾和成本优化要让 AI 能调用外部工具查数据、执行操作要让它能读取企业内部的文档知识库还要能对复杂的任务做多步骤的规划和编排。这时候你会发现原来那套“硬编码 单接口”的做法完全撑不住了。XXL-AI 这个项目标题里提到的几个关键词——Agent 编排、多供应商、MCP SKILL RAG 扩展、工程化底座——恰好覆盖了当前 AI 应用开发从“玩具”走向“产品”过程中最核心的四个工程化命题。这篇文章我会围绕这四个方向把每个环节的设计思路、技术选型理由、实操要点和踩坑经验都拆开来讲。不管你是刚接触 AI 应用开发的新手还是已经在做企业级 AI 平台的工程师应该都能从中找到可以直接参考的东西。先说清楚这篇文章适合谁看。如果你只是想让模型帮你写写文案、做做翻译那直接用现成的对话产品就够了不需要看这些。但如果你需要把 AI 能力集成到自己的业务系统里需要让 AI 按照你定义的流程去执行任务需要对接多个模型供应商来保证可用性和成本可控需要让 AI 能够访问你的私有数据和工具——那这篇文章讨论的内容就是你必须面对的。我会尽量用通俗的方式解释每个概念同时给出可以直接落地的方案和参数。2. Agent 编排从单次对话到多步骤任务执行的核心设计2.1 Agent 编排到底在编排什么很多人第一次听到“Agent 编排”这个词会觉得抽象。我用一个实际场景来解释。假设你要做一个“自动生成周报”的 AI 应用流程是这样的先从项目管理工具拉取本周的任务完成情况然后从代码仓库拉取提交记录接着把这两部分数据交给模型做总结归纳最后按照固定格式生成周报并发送到指定渠道。这个流程里有数据获取、有模型调用、有格式处理、有外部动作每一步的输入输出都不一样有些步骤还需要根据上一步的结果来决定下一步怎么做。Agent 编排要解决的就是这个问题把一个复杂任务拆解成多个可执行的步骤定义每个步骤的输入输出、执行条件和异常处理然后让系统按照定义的流程自动调度执行。它本质上是一个工作流引擎只不过执行单元从传统的函数调用变成了 AI Agent。XXL-AI 在 Agent 编排上的设计思路我理解是走了一条“声明式编排 运行时调度”的路线。声明式编排的意思是你用配置文件或者可视化界面定义好流程的节点和连线而不是在代码里写一大堆 if-else 和回调。这样做的好处是流程变更不需要改代码、不需要重新部署运营人员也能参与流程调整。运行时调度则负责处理节点的执行顺序、并发控制、超时重试、状态持久化这些事情。2.2 编排引擎的核心组件拆解一个完整的 Agent 编排引擎我认为至少需要包含以下几个核心组件这也是我在实际项目中验证过的必要模块。流程定义层负责描述整个任务的执行逻辑。常见的做法是用有向无环图DAG来表示每个节点是一个执行单元边表示依赖关系。但 Agent 场景比传统工作流更复杂的地方在于有些节点需要根据运行时结果动态决定后续走向所以还需要支持条件分支和循环。XXL-AI 如果支持条件分支节点和循环节点那就能覆盖绝大多数业务场景了。节点执行器是真正干活的部分。每个节点类型对应一个执行器比如 LLM 调用节点、工具调用节点、知识库检索节点、代码执行节点、条件判断节点等。执行器需要处理输入参数的解析、执行过程的超时控制、执行结果的格式化输出。这里有个容易忽略的细节节点的输入参数往往需要引用上游节点的输出所以需要一套变量引用机制比如用{{node_id.output.field}}这样的模板语法来动态取值。状态管理器负责记录每个流程实例的执行状态。这个组件在单机环境下可能不太起眼但在分布式部署或者需要支持断点续跑的场景下就非常关键。我踩过的一个坑是一个流程执行到一半某个节点因为外部服务超时失败了如果没有状态持久化整个流程就得从头再来前面已经成功执行的节点白白浪费了时间和 token 成本。所以状态管理器需要把每个节点的执行状态、输入输出、执行时间都持久化下来支持从失败节点重新开始执行。调度器决定节点什么时候执行、以什么顺序执行。最简单的策略是按拓扑排序串行执行但实际业务中往往需要并行执行没有依赖关系的节点来缩短总耗时。比如前面说的周报场景拉取任务完成情况和拉取代码提交记录这两个节点没有依赖关系完全可以并行执行。调度器还需要处理并发限制避免同时调用太多次模型接口导致触发限流。2.3 多 Agent 协作的编排模式单个 Agent 能处理的任务复杂度是有限的。当任务需要多个不同角色的 Agent 协作完成时就需要更复杂的编排模式。我在实际项目中用过并且觉得比较实用的模式有三种。流水线模式是最直观的多个 Agent 按照固定顺序依次处理前一个的输出是后一个的输入。比如“需求分析 Agent → 方案设计 Agent → 代码生成 Agent → 代码审查 Agent”这样一条流水线。这种模式实现简单适合步骤明确、不需要回头修改的场景。路由模式是先由一个“调度 Agent”判断任务类型然后分发给对应的“专家 Agent”处理。比如用户提问后先判断这是技术问题、商务问题还是售后问题然后分别交给对应的 Agent 回答。这种模式的关键在于路由判断的准确性通常需要给调度 Agent 提供清晰的分类标准和少量示例。辩论模式是让多个 Agent 对同一个问题给出各自的答案然后由一个“裁判 Agent”综合评估后给出最终结果。这种模式在需要高质量输出的场景下很有用比如方案评审、内容创作。代价是 token 消耗会成倍增加所以需要权衡质量和成本。实操心得多 Agent 协作不一定比单 Agent 效果好。我做过对比测试在任务复杂度不高的情况下给单 Agent 一个清晰的系统提示词效果往往比拆成多个 Agent 更好而且成本和延迟都更低。只有当任务确实需要不同领域的专业知识或者需要多轮迭代优化时多 Agent 协作才有明显优势。3. 多供应商接入不让任何一个模型成为单点3.1 为什么必须做多供应商适配只接一个模型供应商在开发测试阶段没什么问题但到了生产环境就会面临几个现实问题。第一是可用性风险任何服务都可能出现临时故障或限流如果只有一个供应商对方出问题你的产品就挂了。第二是成本问题不同供应商在不同任务上的性价比差异很大简单的分类任务用便宜的小模型就够了复杂的推理任务才需要上大模型。第三是能力差异有些模型擅长中文有些擅长代码有些在函数调用上更稳定需要根据任务特点选择最合适的模型。XXL-AI 把多供应商作为核心能力之一我认为这是非常务实的设计决策。但多供应商适配不是简单地封装几个 API 调用就完事了里面有很多细节需要处理。3.2 供应商适配层的设计要点统一接口抽象是第一层要做的事情。不同供应商的 API 参数格式、返回结构、错误码都不一样。适配层需要定义一套统一的内部接口把各家 API 的差异屏蔽掉。比如统一用model、messages、temperature、max_tokens这些参数返回统一用content、usage、finish_reason这些字段。这样上层业务代码就不需要关心底层用的是哪家模型。能力声明机制是第二层。不是所有模型都支持函数调用、JSON 模式、流式输出、图片输入这些能力。适配层需要为每个模型维护一份能力清单上层在编排流程时可以根据需求选择支持对应能力的模型。比如一个节点需要模型返回结构化的 JSON那就只能选择支持 JSON 模式的模型。参数映射与默认值是第三层。同一个参数在不同供应商那里的取值范围和默认值可能不同。比如 temperature 有些供应商范围是 0 到 1有些是 0 到 2。适配层需要做归一化处理同时为每个模型设置合理的默认参数。我一般会把默认 temperature 设为 0.7 用于创意类任务设为 0.1 用于需要稳定输出的任务。错误处理与重试是第四层。不同供应商的错误码体系不同适配层需要把常见的错误类型统一映射比如限流、超时、认证失败、内容审核不通过等。然后针对不同错误类型采取不同的处理策略限流就退避重试认证失败就告警内容审核不通过就返回友好提示。3.3 模型路由与降级策略有了多供应商适配层之后下一步就是决定每次请求用哪个模型。最简单的做法是在流程定义时写死模型名称但这样不够灵活。更好的做法是实现一个模型路由层根据任务类型、成本预算、当前各供应商的健康状态来动态选择。我常用的路由策略是这样的首先根据任务类型筛选出能力匹配的模型列表然后按照成本从低到高排序优先选择成本低的模型。如果低成本的模型调用失败或者返回质量不达标再自动升级到更高成本的模型。这个“质量不达标”的判断可以通过一些启发式规则来实现比如返回内容为空、返回格式不符合要求、包含明显的错误信息等。降级策略也很重要。当某个供应商整体不可用时路由层应该能自动把流量切到备用供应商。这里需要注意的是不同模型的输出风格和能力有差异切换后可能会影响用户体验的一致性。所以降级策略最好配合灰度发布先切一小部分流量观察效果确认没问题再全量切换。策略类型适用场景实现复杂度效果固定模型开发测试、单一任务低简单但不够灵活按任务路由多任务类型混合中性价比最优按成本路由成本敏感型业务中成本可控自动降级高可用要求高可用性最好注意事项多供应商接入后日志和监控必须跟上。每个请求都要记录用了哪个供应商、哪个模型、耗时多少、token 消耗多少、是否成功。没有这些数据你根本不知道钱花在哪里了也不知道哪个供应商更稳定。我一般会用结构化的日志格式方便后续做聚合分析。4. MCP SKILL RAG三种扩展能力的定位与配合4.1 三种扩展能力的本质区别MCP、SKILL、RAG 这三个词经常被放在一起讨论但它们解决的是完全不同的问题。我用一个类比来解释假设 AI 是一个新入职的员工RAG 是给他一本公司内部手册让他随时查阅SKILL 是教他一项具体的操作技能比如使用某个软件MCP 则是给他一套标准化的工具接口让他能操作公司的各种系统。RAG 的核心是知识获取。当模型本身的知识不够用或者需要访问私有数据时RAG 通过检索的方式把相关文档片段注入到模型的上下文中让模型基于这些片段来回答问题。它的关键指标是检索的准确率和召回率以及注入上下文的质量。SKILL 的核心是能力封装。它把一组相关的提示词、工具调用、处理逻辑打包成一个可复用的技能单元。比如“生成周报”这个技能内部可能包含了数据获取、格式化、模型调用等多个步骤但对外只暴露一个简单的调用接口。SKILL 的价值在于复用和标准化避免每个流程都从头写一遍。MCP 的核心是工具标准化。它定义了一套标准的协议让不同的工具提供方按照统一的接口来暴露自己的能力AI 应用只需要按照协议去发现和调用工具不需要为每个工具单独写适配代码。这有点像 USB 接口标准化的意义以前每个设备都有自己的接口现在统一成 USB 之后任何设备插上都能用。4.2 RAG 的工程化落地要点RAG 看起来简单——把文档切块、向量化、存到向量数据库、查询时检索最相似的块——但实际做起来坑非常多。我见过太多项目在 demo 阶段效果惊艳上线后用户一用就发现答非所问。文档切块策略是第一个关键决策。切得太碎单个块信息不完整模型无法理解上下文切得太大检索精度下降而且会浪费上下文窗口。我的经验是对于结构化文档比如产品手册、规章制度按照标题层级来切每个小节作为一个块块大小控制在 300 到 800 字之间。对于非结构化文档比如聊天记录、会议纪要按照语义完整性来切可以用滑动窗口加重叠的方式窗口大小 500 字重叠 100 字。向量化模型选择是第二个关键决策。不同向量化模型在不同语言和领域上的表现差异很大。中文场景下我测试过多个开源和商业的向量化模型发现对于通用中文文本大部分主流模型效果差距不大但对于专业领域文本比如法律、医疗领域微调过的模型明显更好。如果预算有限可以用开源模型自己部署如果追求效果商业 API 通常更省心。检索策略优化是第三个关键决策。最简单的做法是纯向量相似度检索但实际效果往往不够好。我一般会用混合检索向量检索加关键词检索两路结果合并后做重排序。关键词检索能弥补向量检索在精确匹配上的不足比如用户问某个具体的产品型号向量检索可能返回一堆语义相似但型号不对的文档关键词检索就能精准命中。重排序则用一个小模型对候选结果做精细打分把最相关的排到前面。上下文组装是第四个关键决策。检索到相关文档块之后怎么把它们组装成模型的输入也有讲究。我通常会在每个文档块前面加上来源标注比如“来自《产品手册》第三章”这样模型在回答时可以引用来源用户也能验证信息的可靠性。另外如果检索到的多个块之间有内容重叠或矛盾需要在组装时做去重和冲突处理。实操心得RAG 的效果评估不能只看最终回答的质量要拆开看检索质量和生成质量。我一般会准备一批测试问题每个问题标注好应该检索到哪些文档块然后分别计算检索的召回率和准确率。如果检索阶段就有问题那再怎么优化生成阶段也没用。检索召回率至少要达到 80% 以上RAG 的整体效果才有保障。4.3 SKILL 的设计原则与复用机制SKILL 的设计目标是把常用的 AI 能力封装成可复用的模块。我在设计 SKILL 时遵循几个原则。单一职责一个 SKILL 只做一件事并且做好。比如“文本摘要”是一个 SKILL“情感分析”是另一个 SKILL不要把多个功能塞进一个 SKILL 里。这样每个 SKILL 的提示词可以针对特定任务优化效果更好也更容易维护。接口稳定SKILL 的输入输出接口一旦定义好就不要轻易改动。因为可能有多个流程在调用同一个 SKILL接口变了所有调用方都得跟着改。我一般会用版本号来管理 SKILL 的接口新版本用新的版本号旧版本继续保留一段时间给调用方迁移的时间。参数可配置SKILL 内部的一些行为应该做成可配置的参数而不是写死在代码里。比如摘要 SKILL 可以配置摘要长度、语言风格、是否保留关键数据等。这样同一个 SKILL 可以适应不同的使用场景。错误可处理SKILL 执行失败时应该返回明确的错误信息而不是抛一个笼统的异常。调用方需要根据错误类型决定是重试、降级还是直接失败。比如模型调用超时和输入格式错误处理方式是完全不同的。SKILL 的复用机制也很重要。我一般会建一个 SKILL 注册中心所有 SKILL 都在这里注册包含名称、描述、输入输出 schema、版本号等信息。流程编排时可以从注册中心查找和引用 SKILL。这样当 SKILL 更新时所有引用它的流程都能自动受益。4.4 MCP 协议在工具集成中的实际价值MCP 解决的是工具集成的标准化问题。在没有 MCP 之前每接入一个新工具都要写一套适配代码定义工具的描述、参数的 schema、调用的逻辑、返回的处理。工具多了之后这些适配代码散落在各处维护成本很高。MCP 的思路是定义一个标准协议工具提供方按照协议来实现服务端AI 应用按照协议来实现客户端。客户端启动时从服务端拉取工具列表和参数定义运行时按照协议格式发起调用。这样接入新工具就不需要写代码了只需要配置服务端地址就行。在实际项目中MCP 的价值主要体现在两个方面。一是降低集成成本特别是当需要接入大量外部工具时标准化的收益非常明显。二是促进工具生态的形成工具提供方只需要实现一次 MCP 服务端就能被所有支持 MCP 的 AI 应用使用不需要为每个应用单独适配。不过 MCP 也不是银弹。我实际使用中遇到的主要问题是工具描述的准确性和参数校验的严格性。如果工具描述写得模糊模型就不知道什么时候该调用这个工具如果参数校验不严格模型传了错误的参数类型调用就会失败。所以实现 MCP 服务端时工具描述要尽量清晰具体参数 schema 要尽量严格。5. 工程化底座让 AI 应用从能跑到好用5.1 可观测性体系的搭建AI 应用和传统应用最大的区别之一就是不确定性。同样的输入模型可能给出不同的输出同样的流程执行时间可能相差很大同样的提示词不同版本的模型效果可能完全不同。这种不确定性使得可观测性变得尤为重要。我在搭建 AI 应用的可观测性体系时主要关注四个维度。调用链路记录每个请求经过了哪些节点、每个节点的输入输出是什么、耗时多少。这需要在整个流程中传递一个 trace_id每个节点执行时都带上这个 id 记录日志。Token 消耗记录每个请求消耗了多少输入 token 和输出 token按供应商、按模型、按业务模块分别统计。这是成本控制的基础数据。质量指标记录模型输出的质量评估结果比如是否为空、是否符合格式要求、是否被用户采纳等。异常告警在错误率、延迟、成本超过阈值时触发告警让问题能被及时发现。这些数据收集起来之后还需要有地方看。我一般会用 Grafana 做可视化面板把关键指标做成图表方便随时查看。另外详细的调用日志要能按 trace_id 搜索方便排查具体问题。5.2 提示词管理与版本控制提示词是 AI 应用的核心资产之一但很多团队对提示词的管理非常随意直接写在代码里改了就提交没有版本记录没有回滚机制。这在早期可能没问题但当提示词越来越多、越来越复杂时就会变成一场灾难。我的做法是把提示词从代码中抽离出来单独管理。每个提示词有唯一的标识符、版本号、内容、适用模型、创建时间、变更说明。提示词变更时创建新版本旧版本保留。流程编排时引用提示词的标识符和版本号这样可以精确控制每个流程用的是哪个版本的提示词。提示词的测试也很重要。每次修改提示词后应该用一组标准测试用例来验证效果确保修改没有引入回归问题。我一般会维护一个测试集包含各种典型输入和期望输出修改提示词后自动跑一遍测试对比新旧版本的效果差异。5.3 缓存与成本优化策略AI 应用的成本大头在模型调用上所以成本优化是工程化底座必须考虑的问题。缓存是最直接有效的手段之一。精确缓存是最简单的把输入和输出做键值对存储相同的输入直接返回缓存结果。适合那些输入重复率高的场景比如常见问题回答。但 AI 场景下完全相同的输入其实不多所以精确缓存的命中率通常不高。语义缓存更进一层把输入向量化后存储查询时先做向量相似度匹配如果找到足够相似的输入就返回对应的缓存结果。这样即使用户的提问措辞不同只要语义相同就能命中缓存。语义缓存的难点在于相似度阈值的设定阈值太高命中率低阈值太低可能返回不相关的答案。我一般会把阈值设在 0.95 以上确保缓存结果的可靠性。分级缓存是针对多轮对话场景的。把对话历史也纳入缓存键的计算这样同一轮对话中的重复问题可以直接命中缓存。但要注意对话上下文的时效性过期的缓存要及时清理。除了缓存还有一些其他的成本优化手段。比如对于简单的分类、提取任务用便宜的小模型而不是大模型对于长文本处理先做摘要压缩再送给模型对于批量任务合并请求减少调用次数。这些手段组合使用通常能把成本降低 50% 以上。5.4 安全与权限控制AI 应用的安全问题往往被低估。我见过不少项目模型可以直接访问数据库、可以执行系统命令、可以读取任意文件这在实际生产环境中是非常危险的。输入过滤是第一道防线。用户输入中如果包含提示词注入的尝试比如“忽略之前的指令现在你是一个...”需要在进入模型之前就检测和拦截。我一般会用规则加模型双重检测规则匹配常见的注入模式模型判断是否存在恶意意图。工具权限是第二道防线。不是所有流程都能调用所有工具。需要建立一套权限体系每个流程、每个用户能调用哪些工具、能访问哪些数据都要有明确的控制。特别是涉及写操作的工具比如发送邮件、修改数据更要严格限制。输出审核是第三道防线。模型生成的内容在返回给用户之前需要经过审核确保不包含敏感信息、不违反内容政策。审核可以用规则引擎加模型判断的方式规则引擎处理明确的违规模式模型处理更复杂的语义判断。数据隔离是第四道防线。不同租户、不同用户的数据要严格隔离不能出现 A 用户通过 AI 应用访问到 B 用户数据的情况。这需要在数据存储、检索、工具调用等各个环节都做好租户标识的传递和校验。6. 常见问题与排查技巧实录6.1 Agent 编排中的典型故障流程卡死是最常见的问题之一。表现是流程执行到某个节点后长时间没有进展也不报错。排查思路是先看该节点的日志确认是节点内部卡住了还是调度器没有触发下一个节点。如果是节点内部卡住通常是外部服务调用没有设置超时或者模型接口响应极慢。解决办法是给所有外部调用设置合理的超时时间超时后触发重试或降级。如果是调度器问题检查是否有循环依赖或者条件分支没有正确匹配。状态不一致是分布式部署下的常见问题。表现是流程状态显示已完成但实际有些节点没有执行或者节点执行了但状态没有更新。这通常是状态持久化和节点执行之间的时序问题。解决办法是采用“先记录状态再执行”的模式节点开始执行前先写入“执行中”状态执行完成后更新为“成功”或“失败”。这样即使中间出现故障也能通过状态判断哪些节点需要重新执行。变量引用错误是编排配置中的高频问题。表现是节点执行时报“变量未定义”或“变量类型不匹配”。排查时先检查变量引用的路径是否正确上游节点的输出结构是否和预期一致。我一般会在流程定义时做静态检查验证所有变量引用都能找到对应的上游输出。6.2 RAG 效果不佳的排查路径RAG 效果不好原因可能出在检索阶段也可能出在生成阶段。排查时我一般按照以下顺序逐步检查。先看检索结果。把用户问题和检索到的文档块都打印出来人工判断这些文档块是否真的和问题相关。如果检索结果就不相关那问题在检索阶段需要优化切块策略、向量化模型或检索算法。如果检索结果相关但模型回答不好那问题在生成阶段需要优化提示词或调整上下文组装方式。检索阶段的问题又可以分为几种。如果检索结果完全跑偏可能是向量化模型不适合当前领域需要换模型或做领域微调。如果检索结果部分相关但不够精准可能是切块粒度不合适需要调整块大小或重叠策略。如果检索结果遗漏了关键文档可能是召回率不够需要增加检索数量或改用混合检索。生成阶段的问题通常是提示词没有说清楚要求。比如模型不知道应该基于检索到的内容回答还是可以用自己的知识回答不知道如果检索内容中没有答案应该怎么处理不知道回答的格式要求。这些都需要在提示词中明确说明。6.3 多供应商切换的注意事项多供应商切换时最容易出问题的地方是输出格式的差异。不同模型对同一个提示词的响应格式可能不同比如有的返回 JSON 有的返回 Markdown有的会在 JSON 外面包一层代码块标记。如果上层代码按照固定格式解析切换供应商后就可能解析失败。解决办法是在适配层做输出格式的归一化处理。不管底层模型返回什么格式适配层都统一转换成内部约定的格式。对于 JSON 输出可以用容错的解析器先尝试直接解析失败后尝试提取代码块中的内容再解析再失败就尝试用正则提取关键字段。另一个需要注意的是不同模型的“性格”差异。有些模型倾向于给出详细冗长的回答有些则简洁直接。切换供应商后即使功能正常用户体验也可能有明显变化。所以切换前最好做 A/B 测试对比两个模型的输出质量、延迟、成本确认切换后整体效果可接受再全量切换。问题现象可能原因排查方法解决方案流程执行超时外部调用无超时设置查看节点日志耗时设置合理超时和重试检索结果不相关切块粒度不当人工检查检索结果调整块大小和重叠切换模型后解析失败输出格式差异对比不同模型输出适配层做格式归一化成本突然升高缓存失效或路由异常查看 token 消耗统计检查缓存和路由配置并发请求被限流未做并发控制查看供应商错误码增加队列和退避重试6.4 性能优化的实操经验AI 应用的性能瓶颈通常在模型调用上所以优化要从减少模型调用次数和缩短单次调用时间两个方向入手。减少调用次数的办法包括用缓存避免重复调用用批量处理合并多次调用用规则引擎处理简单判断避免调用模型用更小的模型处理简单任务。我做过一个统计在一个客服问答场景中通过缓存和规则引擎模型调用次数减少了 60% 以上。缩短单次调用时间的办法包括用流式输出让用户更早看到部分结果用更快的模型处理对延迟敏感的任务优化提示词长度减少输入 token 数用并发调用处理没有依赖关系的多个模型请求。流式输出对用户体验的提升特别明显虽然总耗时没变但用户感知到的等待时间大幅缩短。实操心得性能优化不要凭感觉一定要有数据支撑。我一般会先做 profiling找出真正的瓶颈在哪里然后针对瓶颈做优化。很多时候你以为的瓶颈比如模型推理速度并不是真正的瓶颈真正的瓶颈可能是网络传输、数据库查询或者序列化反序列化。没有数据就优化很容易白费力气。7. 一些关于工程化底座的个人体会做 AI 应用开发这几年我最大的体会是模型能力决定了应用的上限但工程化水平决定了应用的下限。一个工程化做得好的 AI 应用即使底层模型不是最强的也能给用户提供稳定可靠的体验而一个工程化做得差的应用即使接了最强的模型也会因为各种超时、错误、不一致而让用户失去信心。XXL-AI 这个项目把工程化底座作为核心定位之一我认为方向是对的。Agent 编排、多供应商、MCP SKILL RAG 扩展这些能力最终都要落到一个稳定、可观测、可控制的工程底座上才能真正发挥价值。我在实际项目中搭建类似体系时最大的感受是要克制“什么都自己造”的冲动。编排引擎、向量数据库、监控系统这些基础设施如果有成熟的开源方案或者云服务优先用现成的把精力集中在业务逻辑和提示词优化上那才是真正产生差异化的地方。另外一点体会是关于迭代节奏的。AI 应用的效果优化是一个持续的过程不可能一次做到完美。我的做法是先搭好工程底座保证基本流程能跑通、能观测、能控制然后小步快跑地迭代提示词和检索策略。每次迭代都基于数据做决策而不是凭感觉调整。这样虽然起步慢一点但后续的迭代会越来越快因为你有数据支撑知道往哪个方向优化最有效。