基于 Apache Camel 编排智能体与多模态 AI 管道
随着人工智能的普及，系统正从简单的模型调用演变为融合推理、检索与行动的多步骤工作流。智能体 AI（Agentic AI）指以模型作为推理智能体的系统：它自主决定使用哪些工具、查询哪些信息以及以何种顺序执行任务。多模态 AI 进一步具备了在同一流程中处理文本、图像、结构化数据等不同类型输入的能力。这两种模式在企业场景中应用日益广泛，同时也大幅增加了工程落地的难度。 大多数现代 AI 系统并非因为模型能力不足而失败。相反，它们失败是因为模型周围的系统设计得不合理。随着越来越多的团队开始使用大语言模型、向量数据库和视觉模型，同样的问题不断在生产环境中出现：流水线脆弱、故障原因模糊、使用成本高昂，以及管控能力有限。 Fivetran 2026 年基准报告针对 500 位企业领导者开展调研，97% 的受访者表示，流水线故障拖慢了他们的 AI 项目，53% 的工程资源仅用于流水线维护工作。MIT 2025 年 NANDA 报告显示，95% 的生成式 AI 试点无法产生可量化的业务价值，存在缺陷的企业集成方案（而非模型质量问题）被认定为核心症结。标普全球市场财智调查显示，2025 年有 42% 的公司放弃了大部分 AI 计划，高于 2024 年的 17%，平均每家企业在投入实际生产前，放弃了 46% 的概念验证项目。核心问题并非模型的智能水平不足，而是缺少对各类组件的统一管控能力。 本文阐述了如何将智能体与多模态 AI 系统作为可靠软件开展工程化落地，而不只是将其当作实验性产品。我们将使用Apache Camel作为控制系统，LangChain4j作为智能体运行时。我们将研究一个真实的工单分类系统，该系统包含多个关键组件： 基于 LLM 的推理 检索增强生成（RAG） 使用 TensorFlow Serving 的图像分类 用于可靠性和治理的确定性集成模式 最终将得到一个具备企业级运行能力的 AI 流水线。它便于监控、运行稳定，即便部分 AI 组件出现异常，整体运行依旧可预测。 大多数 AI 教程只侧重简单调用模型，但真实的生产系统需要更全面的实现方案，包括对模型的高效管理与可控调度。在企业 AI 工作流中，这意味着决定何时使用大语言模型、选择它可以访问哪些工具、为非 LLM 任务添加可靠的基于规则的模型、平稳处理部分故障以保持系统稳定，以及创建可供合规和审查的结构化输出。正因如此，带有嵌入式智能体的AI 流水线编排变得特别有用。智能体不只是循环运行的大语言模型，而是深度集成在规模化、规范化执行系统中的推理核心。在这种架构中，传统企业系统中成熟可靠的集成方案可继续保障整体系统的稳定性与运行效率。 在大多数传统智能体 AI 实现中，大语言模型同时承担推理引擎与执行控制器的双重角色。LangChain、CrewAI和AutoGen等框架让智能体决定调用哪些工具、管理对话记忆和排序操作，所有这些都发生在智能体运行时内部。这类框架在 API 调用层面提供基础的重试能力，但它们本身并不具备熔断器、负载校验、确定性降级路由等企业级弹性能力。这对于原型和单用户应用来说效果很好，但在生产环境中会暴露出诸多问题。错误处理逻辑需要手动嵌入智能体代码，大幅增加故障排查难度；智能体的决策逻辑与执行流程缺乏清晰边界。尽管LangSmith等外部工具可以增加可观测性，但这种能力并未原生内置在执行架构中。由于核心控制逻辑完全内嵌在 AI 内部，系统的扩容扩展、版本管理与合规治理也随之变得难以落地。 基于集成框架的方案将执行控制逻辑从智能体中剥离，交给成熟可靠的编排层统一管理，以此来改变原有的实现方式。在这种模型中，LLM 智能体依旧负责推理判断与行动决策，而 Apache Camel 这类框架则负责定义执行方式与执行时机。路由转发、重试机制、熔断降级、负载校验以及任务排序均由 Camel 路由统一管控，不再依赖智能体。这种模式能够让工程团队用管理传统企业集成流程的同等管控能力来运维 AI 工作流。图 1 直观展示了两种架构的核心差异。 图 1：传统基于智能体的 AI 与基于集成框架的智能体 AI Apache Camel 通常被视为一种集成框架，但在 AI 密集型系统中，它承担着更具战略性的角色，即充当AI 控制平面。它提供多项核心能力，包括清晰的路由调度、上下文信息补全、依靠熔断器与重试机制实现故障隔离，以及为不确定性流程步骤提供确定性排序。Camel 还明确拆分了推理任务与执行任务。它不会将控制逻辑隐藏在提示词或 SDK 回调中，而是把控制流程下沉至模块化路由，便于测试、监控与迭代维护。在这种架构中，大语言模型负责推理分析，最终的执行决策则由 Camel 统一把控。 然而，将 Apache Camel 应用于基于智能体的 AI 工作负载也存在一些权衡。Camel 是一个基于 Java 的框架，这意味着以 Python（AI 与机器学习生态的主流语言）为主要开发语言的团队将会面临更高的上手门槛，且相较于庞大的 Python AI 工具生态，Java 可用的 AI 类库选择更为有限。Camel 路由十分适合用于结构化、确定性的工作流，但并不适合高度动态的智能体操作，这类场景的执行路径无法预先确定，需要进行多轮大模型推理动态生成。调试封装了 AI 交互逻辑的 Camel 路由也会比调试直接调用大模型的 Python 脚本更为复杂。除此之外，AI 或数据科学领域出身、缺乏企业集成开发经验的团队对基于内容的路由、死信队列、线路监听等企业集成设计模式会相对陌生。但这些局限并不会削弱 Camel 作为一个编排层的价值，但确实也表明它更适合已深度采用 Java 技术架构、追求生产级稳定性而非优先快速搭建原型的企业与团队。 本文介绍的案例研究围绕一个面向实际部署而设计的生产级支持工单分类系统展开。在处理单个工单时，系统会接收工单标题、问题描述、可选截图及相关元数据（如提交人信息与工单编号），并按照既定逻辑输出结构化 JSON 决策结果，其中包含多项内容：工单分类（包含故障、事件、权限申请等类型）、P0 至 P3 四级优先级、责任归属团队、后续处理建议、内部文档引用内容，以及通过图像分析获取的附加参考信息。关键在于这个系统并非以聊天机器人的形式运行，而是一个轻量化、非对话式的自动化流程，无需人机交互界面，确保输出结果具备确定性、易于程序解析，同时支持全流程审计，满足责任追溯与合规监管要求。 前面所描述的支持工单分类系统需要处理结构化与非结构化的混合输入，包括文本描述、元数据字段以及可选的截图附件，各类输入均需采用不同的处理策略。要将工单划分到正确的类别并标定对应优先级，需要结合多类输入进行综合推理，而非单纯依靠关键词匹配。文本内容需要借助检索增强生成能力匹配内部文档，输出有效的上下文与参考引用。截图附件则需要通过视觉模型单独解析，提取报错弹窗、界面异常等关键信息，为分类决策提供辅助。纯规则驱动的系统无法妥善处理这类输入；若不加约束、直接将全部内容交由单一大模型处理又会导致成本不可控、输出结果不稳定。这种业务场景适合使用多模态智能体方案，核心原因在于：系统需要依靠智能体自主判断每个工单应该调用那个模块，并结合图像识别等专项任务专用模型，整体运行在确定性流水线中，确保每一项决策可追溯审计、每一处异常可妥善处理。 图 2 展示了智能体驱动的多模态 AI 流水线的整体控制流程，清晰呈现出 Apache Camel 如何在确定性执行链路中编排大模型推理、检索增强生成与各类模型服务。这个系统由多个核心模块构成：Apache Camel 路由作为核心编排层；LangChain4j 智能体负责逻辑推理与工具选择；Qdrant等向量数据库为 RAG 能力提供支撑；TensorFlow Serving部署并运行ResNet50图像处理模型；同时还接入了兼容OpenAI接口规范的外部大模型服务。智能体不会直接对接底层基础设施，而是通过调用专属工具完成各项操作。每项工具操作均由 Camel 统一调度管理，Camel 的企业集成模式大幅提升 AI 交互的稳定性与可靠性。整个架构遵循一个核心设计原则：由大模型承担推理工作，专用模型负责专项业务处理，再由 Camel 管理整个过程。 图 2：架构概览 系统中的 LangChain4j 智能体只有有限的访问权限。它只能调用少量且定义明确的工具集合。 智能体专注于任务规划，而非具体执行。它负责选定需要调用哪些工具及调用顺序，再由 Camel 落地执行，并统一处理超时、重试与结果校验等问题。这种设计能够规避智能体系统中的一类常见问题：无意义的循环调用工具。 尽管 RAG 通常被视为一项核心 AI 技术，但在实际应用场景中，它更是一个集成难题。在本系统中，文档会在服务启动时被摄取到 Qdrant 中，为提升运行效率，向量嵌入只生成一次；查询请求会筛选出相似度最高的Top-K上下文片段，检索到的内容再通过信息补全流程附加到数据交互链路中。大语言模型不会直接对接向量数据库，而是由 Camel 负责检索整个流程，严格管控负载大小，规范引的用内容，确保上下文注入全程可观测、可约束。由此，RAG 变成了一个可稳定预判的机制，有结构化的路由，并不是临时的逻辑。如图 3 所示，执行流程清晰展示了 Camel 如何管控流程中的每一个环节，包括文档检索、上下文补全，直至最终生成结构化输出。 图 3：执行流程图 从这个项目得到的一个关键结论是：你可以在没有多模态模型的情况下构建多模态系统。我们不是直接将图像传给大语言模型，而是将截图推送给 TensorFlow Serving。由 ResNet50 模型生成内容标签与置信度分数，再将这些结果作为结构化特征数据提供给智能体，智能体基于这些数据进行推理。这种方案成本更低、运行效率更高，也更便于运维管控。大语言模型可以专注发挥自身的核心能力，这一点在生产环境中尤为关键。图 4 展示了支持工单在智能体驱动的流水线中的完整执行路径，包含初始路由分发、智能体推理、RAG 检索、图像分析，再到最终生成结构化输出的全过程。 图 4：支持工单分类序列图 现在我们已经了解了整体架构与执行流程，接下来看看示例应用的项目结构和依赖项配置。 该项目是使用以下技术栈构建的多模块 Gradle 应用程序。 基础设施可通过 Docker Compose 在本地启动：Qdrant 为 RAG 提供向量检索能力，TensorFlow Serving（或轻量模拟服务器）为多模态链路提供图像推理服务。 docker-compose.yml 为简洁起见，这里省略了完整的 Docker Compose 文件（包含网络、数据卷、健康检查优化及启动脚本）。 triage-service 子项目会启动 REST 服务，接收传入工单，并通过以下两条 Camel 路由完成处理流程： DocumentIngestionRouteBuilder.java（启动时将示例文档摄取到向量数据库的路由） TriageRouteBuilder.java（工单分类的主 Camel 路由） AI 相关元素在以下类中实现，由 TriageRouteBuilder 类调用这些类： TriageTools.java（暴露给 LLM 智能体用于工单分类的工具） OpenAiCompatibleChatClient.java（集成 OpenAI API 的 LLM 聊天客户端） QdrantVectorDbClient.java（Qdrant 向量数据库客户端实现） 所有组件的完整源代码可在GitHub 仓库中获取。 读者可以克隆仓库，在本文之外探索完整的实现。 这个项目最有价值的部分之一是从失败中学习，而不仅仅是取得成功。这些挑战为真实世界部署积累了宝贵经验。项目落地过程中遇到诸多实际问题，例如 TensorFlow Serving 的 Docker 镜像和模型版本之间的差异、导致静默连接失败的超大 REST 请求负载（约 900KB 的张量）、模型服务器的冷启动延迟，以及 TensorFlow Serving 中未记录的 HTTP 限制。项目并未刻意掩盖这类问题，而是在架构设计阶段就提前预判并针对性处理，让系统在复杂不确定的环境中具备更强的稳定性与容错能力。 为完成这项任务，Camel 为每一个外部调用封装了Resilience4 j熔断器等防护机制，设置超时和重试策略，并提供降级兜底方案，以此保障核心操作稳定运行。因此，即使图像分类失败，系统依旧能够仅依靠文本分析与 RAG 能力输出可靠的分类结果。这是一个有意的设计选择，充分体现了严谨且具备弹性的工程设计实践。 该系统的架构源于一系列兼顾功能、可靠性与可维护性的审慎设计选择： TensorFlow Serving 选择它是因为模型可用性和生态系统成熟度，尽管存在 REST 限制。 Qdrant 轻量级本地配置、快速迭代和简单的操作模型。 调用工具的智能体优于纯 RAG 因为推理何时进行检索或分类与检索本身同样重要。 无自主循环 每条执行路径都能够确定性地终止。 无微调 重点是系统架构，而非模型优化。 这些约束条件让工程团队（而不仅仅是 AI 专家）能够理解并运维该系统。 智能体与多模态 AI 并非只是未来的构想，而是各类组织当下需要直面的实际架构难题。不要局限于某一种框架或模型，而是建立全新的设计思维：将 AI 组件视为需要严格管控的不可靠依赖，采用成熟可靠的集成模式适配概率性系统，保持推理与执行环节的隔离，围绕局部故障开展设计，而非追求理想化的智能表现。将 Apache Camel 与现代 AI 工具相结合提供了切实可行的发展方向。这种方式既沉淀了多年的集成实践经验，又能充分发挥新技术的价值。归根结底，在生产环境中，稳健可靠的架构远比纯粹的智能更为关键。 【声明：本文由 InfoQ 翻译，未经许可禁止转载。】 查看英文原文：https://www.infoq.com/articles/orchestrating-agentic-multimodal-ai-pipelines-apache-camel/引言
从以模型为中心的 AI 到以系统为中心的 AI
为什么说 Apache Camel 适合用于基于智能体 AI 的工作负载
真实世界的问题：支持工单分类系统
架构概述：确定性流水线中的智能体
实践中的 AI 智能体：是工具，不是魔法
searchDocs(query) ——通过向量数据库提供语义搜索lookupRunbook(team, category)——提供静态操作指南callModelServer(imagePath)——负责图像分类createJiraStub(summary, priority, team)——执行下游操作RAG 的集成难题
无需多模态模型的多模态 AI
代码实操
项目结构
camel-support-triage-agent/├── common/ # DTOs and shared domain model├── infra/ # Docker-based vector DB and model serving├── triage-service/│ ├── routes/ # Camel routes│ ├── llm/ # LLM client abstractions│ ├── tools/ # Agent tools│ └── vectordb/ # Vector DB access├── docs/├── build.gradle
services: qdrant: image: qdrant/qdrant:v1.7.4 ports: ["6333:6333"] healthcheck: test: ["CMD", "curl", "-f", "http://localhost:6333/health"] tensorflow-serving: image: tensorflow/serving:latest ports: ["8501:8501", "8500:8500"] # REST + gRPC volumes: ["./models:/models"] environment: - MODEL_NAME=resnet profiles: ["real"] mock-model-server: image: python:3.11-slim ports: ["8502:8502"]
单个分类流程的日志输出
故障是常态：主动为故障做架构设计
为什么要做出这些权衡
结论