大模型已成为驱动各行业智能化转型的核心引擎，货拉拉基于自身在物流领域 AI 落地的深厚积累，率先布局并打造了货拉拉的大模型应用一站式开发平台 -- 悟空平台。依托悟空平台，交付 AI Workflow、AI Agent、多模态知识引擎、AI 插件等功能积木，已在十几个部门落地数十上百个 AI 场景。证实了货拉拉在大模型落地之路上的坚定步伐和成果。
如今，随着公司业务持续扩张、场景日益复杂，以及用户对智能化体验要求的不断提升，原有的大模型应用体系面临着新的机遇和挑战。如何在已有的基础上，进一步拓展能力边界，使其更好地服务于企业的实际业务需求，成为了我们亟待攻克的关键课题。
正是在这样的背景下，功能拓界与业务赋能，成为了悟空下一阶段的核心战略，下面我将详细介绍。
在货拉拉大模型应用与开发初期，我们面临多项挑战，例如，如何统一结构化和非结构化企业知识、如何动态组合业务逻辑和大模型等，针对这些挑战，我们做了针对性突破：构建了一套多模态知识引擎，提供了一套自研的 AI Workflow 引擎等，在前文中已有详细介绍，在此不做赘述。
尽管货拉拉大模型应用已取得阶段性进展，但随着业务愈发深入，场景愈发复杂，我们面临着新一轮的问题与挑战。
截至当前，悟空平台已托管 7k+ 个 AI 应用，这些 AI 应用类型涉及 AI Workflow、Single-Agent、Multi-Agent、LangChain、LangGraph 等，覆盖十几个业务部门的场景点。如何保证如此多的 AI 应用稳定、可靠、互不影响，即应用安全问题，成为了重中之重。
在一些复杂业务场景，例如 DeepSearch、BI 问数、AI 选车等，业务流程复杂，单次推理调用，可能涉及数十个节点环节执行，且中间涉及多次不同大模型的调用、MCP 运行、Agent 决策等，并且对整体推理耗时有要求。AI 应用的推理性能逐渐到达了一个瓶颈。
复杂流程推理慢：基于 DAG 的串行化流程，在推理时严格遵循串行化，会让流程耗时呈线性增加
资源不均衡占用：AI 应用流量不同于传统服务，具有周期性、临时性、突发性的特点，极易造成服务资源不均衡
大模型负载爆满：随着业务和调用量上涨，模型负载飙升，如何在业务内部和业务间平衡使用负载，也是一个老大难问题
场景适配成本较高：不同业务部门协议、接口、能力差异大，现有 AI Tool 注册机制难以直接适配
插件开发部署困难：AI 插件的使用依赖传统服务部署流程，悟空现无法支持多语言的插件托管。
平台架构扩展不足：现有平台架构可能难以支撑应用数量和类型的爆发式增长，平台本身的扩展性成为了成为了瓶颈
综上现状，推动货拉拉大模型应用开发进行功能拓界与业务赋能，具有极强的必要性和战略意义。
为了应对当前平台架构本身的不足，在原有单服务架构基础上，我们完成了平台架构拆分，采用微服务架构， 按照功能模块划分服务，服务间通信交互，职责清晰。
为应对运行安全、资源不均衡等问题，悟空引入 Serverless 无服务器应用，实现 AI 运行时态沙盒，解决了环境隔离和资源抢占的现象。此外，悟空保持前沿技术引进，通过推动货拉拉 MCP 市场，整合不同部门能力统一输出，以应对场景适配成本高的问题。最后，悟空平台联动信息安全、风控等多方部门，构建了 AI 应用全方位的安全检测和拦截体系，确保企业安全。
基于 DAG 的并行推理 AI Workflow 引擎
悟空支持的自研 AI Workflow 引擎，提供灵活、通用、上手快、运行稳定的 AI 流程编排能力，可快速构建可扩展的企业级 AI 应用。但面对复杂业务，其推理性能和速度已经到达了瓶颈。
AI 工作流的并行推理在 dify 和中也有相似能力介绍，并行推理允许多个工作流节点或分支在同一时间内共同触发执行，并行节点/分支间不存在依赖关系，能够同时执行任务，更好的提升 AI 工作流的整体运行效率。实现原理是基于 DAG 图算法，结合节点依赖变量驱动，配合动态标记剪枝完成。
包含以下使用并行推理模式：
1.基础并行
基础并行是指 开始->并行结构->结束 三层关系，也是并行推理的最小单元，这种模式最为直观，用户输入变量后，工作流能够同时运行多个节点。
2.嵌套并行
嵌套并行是指 开始->并行结构 -> 并行结构-> .... -> 并行结构->结束 多层关系，适用于内部复杂的流程。比如需要先完成请求外部 API，在将响应结果整合后同时交给下游多个节点执行。
3.迭代并行
迭代并行用于在业务有循环逻辑或批处理逻辑，可以在循环体和批处理体内支持编排并行结构，加速一轮迭代内各节点执行效率，以及多轮迭代间的并发执行效率。
4.条件/意图并行
条件分支并行是根据指定条件运行不同的并行结构，此外也支持多个条件同时命中运行多个并行结构。
悟空也扩展了意图节点的能力，可根据命中用户意图，运行不同的并行结构，甚至也可以同时命中多个意图选项，同时运行多个意图下的并行结构。
2.2 大模型流量调度
悟空平台已存在七千多个 AI 应用，日均承载了数百上千万次 AI 应用调用，而 AI 应用的行为与性能又高度依赖模型服务，模型服务受限于底层算力资源，普遍存在较低的接口限流阈值，且相比传统 API 服务，其响应延迟（RT）和调用成功率波动较大，服务可用性相对不稳定，对上层 AI 应用的连续性和体验构成挑战。
模型调用的挑战有三个：
模型多：一个 AI Workflow 中可能使用多个大模型，这些大模型节点分散在工作流的运行链路中，且这些模型供应商不同，规范也不同、调用方式也可能不同。
模态多：一个 AI Workflow 中可能包含语言模型、图像理解模型、图像生成模型、语音模型、Embedding 模型等，用于处理不同的输入模态，模态间数据模式和协议缺乏统一标准
场景多：不同业务场景对 AI 应用需求差异显著，有的要求稳定性，有的需要强限流，有的需要逻辑容错，有的只在固定时段高峰调用。
面对 AI 应用和模型调用的挑战，解法就是统一模型服务的流量调度，从重要性上最源头划分核心业务和普通业务，所有业务 Workflow 运行中模型节点的流量都会走到流量调度模块，在流量调度模块，完成鉴权、模态加载、风险拦截等前置动作。根据是否核心，判断模型流量走普通 Model Endpoint 或核心专属的 Endpoint。
此外，针对有低时延要求的业务，提供模型的 TPM 保障，可根据配置或定时策略，手动或自动的开启 TPM 保障。对于稳定性要求高的业务，提供可自定义的逻辑容错策略和模型的 fallback 机制。
例如，某个业务 Workflow 的逻辑容错和 fallback 策略如下：
在实际业务场景中，有部分业务诉求是基于业务自身事件触发时，开始 AI Workflow 的推理。
例如，员工通过企业办公软件（飞书）在群组中发送了消息，需要监听消息推送事件，运行 AI Chat 工作流；或是研发提交了一个 Gitlab Merge Request，触发了 Gitlab MR Webhook，运行 AI 代码审查工作流；甚至是推送了一条 Kafka Message，当 Consumer 到 Message 时，运行 AI 工作流。
悟空已支持/正在支持的事件类型：
消息触发：通过通用的办公软件和其他终端交互软件，实现单聊/群组消息触发 AI 工作流
Kafka 事件触发：Kafka 关联下游 AI 工作流，通过推送事件到 Kafka，AI 工作流实时消费时间，并基于事件内容作为输入运行
Webhook 触发：提供自定义的 Webhook 地址，接收外部系统的 HTTP 请求后运行工作流，支持与外部系统的无缝集成
定时触发：按固定时间间隔（每小时、每天）或 Cron 规则运行 AI 工作流，比较适合周期性任务
API：通过同步（流式/非流式）和异步提交 API，手动触发工作流运行
2.4 构建全方位的安全拦截
企业 AI 使用，安全是一切的基石。企业 AI 使用中涉及法务约束、算法备案、数据合规、涉敏涉政、文本检测、多模态识别、审计留存等环节，都需要做好安全配套把关和拦截能力。其中 AI 运行时动态的知识、图片、离线文件、代码、环境、依赖、日志等处理环节和数据，尽量不出内网，按需隔离。需要出内网，做好检测和拦截机制。
"All problems in computer science can be solved by another level of indirection" -- Butler Lampson在计算机科学中，任何问题都可以通过一个抽象层解决。
MCP（Model Context Protocol，模型上下文协议）是一项开放标准协议，旨在搭建大模型和外部工具之间的信息传递通道。通过 MCP 协议，开发者不用为每个外部工具编写复杂的接口，即可接入海量第三方工具。MCP 技术细节相信各位读者都很熟悉，在此不做赘述。
针对货拉拉内各部门和业务的协议、接口、能力差异大、AI 插件接入成本较高的问题，MCP 通过统一、标准、易集成等优点，成为了悟空 AI Agent 使用 Tools 的首选。
这里我们基于悟空 Supervisor 模式的 Multi Agent 使用场景，探寻货拉拉 AI Agent + MCP 的交互方式：
此外，在 AI Workflow 中，大模型也可关联 MCP 使用，将单一的模型升级为基于 ReAct 模式的 Agent，再结合工作流模式，也能达到 Multi Agent 的另类实现：
3.2 MCP市场
基于 MCP 能力，可以将业务逻辑交还给业务，业务负责自身领域 MCP 的开发，平台提供 MCP 的注册，并在 Agent 和 Workflow 中使用业务注册的 MCP List 即可。此外基于 Serverless 技术，平台也在支持将 MCP Package 打包成 Saas，托管在平台中。这样将货拉拉内部的业务服务和可用的开源 package 整合，形成了货拉拉内部的企业级 MCP 市场，推动部门团队间的能力复用。
在前文中我们简单介绍了应对 AI 应用运行的可观测性，但比较简陋基础，而为了应对日趋复杂的 AI 业务，我们对原有的观测工具做了功能升级，形成一个专注于 AI 应用开发和运维的平台级工具，用于解决 AI 应用开发和使用过程中面临的各种挑战，提供从开发、调试、观测、追踪的生命周期管理能力。
悟空提示词评测基于结构化评估框架，对评估对象进行全面质量监控和优化，核心在于建立多种评估策略（如 LLM 评委、人工评委）以及多维度指标，包括质量、性能、成本，确保评估对象在各方面都能达预期。
在 AI 应用的开发与使用过程中，请求调用链错综复杂，悟空的观测功能可以追踪并记录环节之间的调用顺序，帮助业务分析推理行为、定位问题或优化性能，实现从 “黑盒模型” 到 “透明决策” 的跨越。
4.3 追踪
一次 AI 推理调用的 Context 日志长度很可能大于 1MB，涉及复杂业务或多模态 AI，AI 的上下文长度更是暴涨，日增量存储接近 1TB，传统 Kafka+Flink 流式处理，以及基于 CK or ES 的实时搜索引擎已经不满足追踪使用现状了。因此基于 Apache Amoro 湖仓技术，实现了日志的流写批读，以及后续成本计算、业务统计等 ETL 过程。
AI 应用推理过程中可能涉及代码执行、API 调用、MCP 使用、文件读写等步骤，而之前的悟空 AI 应用对应 Application Json Schema 配置，本质上运行的是同一套服务代码，这就导致这些步骤被服务环境、运行依赖、语言版本等差异性限制。具体痛点如下：
环境隔离：单服务或单功能沙盒（如 E2B、Browserbase 等）需要 AI 应用跨沙盒通信，增加延迟和复杂度
定制困难：不同 AI 应用需要预装不同的技术栈，传统服务提供统一的预置镜像，无法满足个性化诉求
无法隔离：既要让 AI 应用拿到真实服务能力（API、MCP、DB），又要强隔离避免越权和数据外泄
悟空基于函数计算和 Serverless 打造了一套面向 AI 应用运行态的虚拟 Sandbox 接口，按照应用和工具粒度，实现 AI 运行时的主要资源隔离和安全隔离，提升了 AI 应用任务执行的效率。
通过 SQL 查数据的需求非常广泛，无论是研发定位，运营分析，还是管理者查指标，底层都是通过实时或准实时数仓获取的，基于悟空实现了智能问数场景的落地，支持指标查询、口径查询、同比环比、对比分析、趋势分析。覆盖货拉拉 5 条业务产线。
针对货拉拉数据平台上 3k+工具，打造一个能理解自然语言、自主调度工具的智能体（Agent） ，实现精准懂需求、智能配工具、自动跑流程，彻底改变用户与数据工厂的交互方式。
近半年，我们完成了之前制定的三个目标工作：1. AI 业务挖掘与赋能、2. Workflow 扩展、3. 大模型广场丰富。
而随着货拉拉落地的 AI 应用越来越多，以及货拉拉大模型应用开发平台搭建与交付过程中，我们非常认同的是，AI 应用在企业落地 90% 的工作都是工程架构设计（软件工程），只有 10% 是真正的大模型。在这 90%的工作中，我们还有非常多可探索的方向。
粤ICP备14082021号
免费POC，
零成本试错
