Flutter AI 应用鸿蒙化实战：openai_core 适配指南

这段时间把项目里的 AI 对话能力往鸿蒙 NEXT 上搬，折腾最深的就是 openai_core 这个 Flutter 三方库。Flutter 生态里做 OpenAI 集成的库不少，openai_core 算是最接近官方 SDK 的一套封装，请求构造、流式响应、函数调用这些都处理得很干净，日常开发写起来非常顺手。但一提到鸿蒙化，问题就来了——它不是简单改改依赖重新编译就能上车的，而是要重新想清楚平台通道怎么走、密钥和模型配置这类 AI 推理资产怎么在鸿蒙侧安全落地、流式输出怎么从系统底层回传到 Flutter 层，以及整套模型集成链路该怎么在 HAP 包体里活得舒坦。

这篇东西就是要把这套适配过程完整摊开来讲，适合两类人看：一类是手头有 Flutter AI 应用想迁移到鸿蒙 NEXT 的开发者，另一类是正准备把 openai_core 接入新项目、希望一开始就避开平台坑的 Flutter 玩家。我会把适配前的方案选型、核心 API 映射、推理资产管控、模型集成实战和排查清单全部过一遍，你直接把步骤抄走就能少走不少弯路。

1. 适配背景与整体思路拆解

1.1 openai_core 在鸿蒙上到底卡在哪

先说清楚一个容易误判的点：openai_core 本身是一个纯 Dart 实现的库，核心逻辑全部跑在 Dart 层，理论上只要 Flutter 引擎能在鸿蒙上跑，它就应该能工作。但实际情况远没那么乐观。

鸿蒙 NEXT 从 5.0 开始不再兼容 Android APK，Flutter 应用要想跑在上面，必须使用 OpenHarmony 的 flutter_flutter 分支重新编译。这套分支目前对 Flutter 标准库的支持已经很完善，大部分 Dart 语法和 dart:async、dart:convert 都没问题。真正卡脖子的地方在 Flutter 的插件机制——openai_core 虽然不直接依赖 Android/iOS 原生代码，但它在构建生态中的上层依赖（比如 http、web_socket_channel、path_provider 这类常见的 IO 和网络工具包）在鸿蒙端是没有现成实现的。

也就是说，直接 flutter run 会看到两种典型报错：一种是找不到对应 ohos 平台的原生插件实现，另一种是运行时报 MissingPluginException。这不是 openai_core 本身的问题，而是 Flutter 插件生态还没有完全覆盖鸿蒙平台，凡是走 MethodChannel、EventChannel 的插件，鸿蒙侧都得单独适配。

另外还有个隐藏较深的坑：Flutter 3.27 之后默认启用的 Impeller 渲染引擎。鸿蒙分支对 Impeller 的支持比 Android 晚，如果你的项目用了大量自定义着色器或者复杂的毛玻璃效果，在真机上可能遇到渲染异常。我们适配时为了降低风险，在鸿蒙构建配置里临时切回了 Skia 渲染，等后续引擎版本稳定再切回来。

1.2 为什么不能直接照搬 Android 适配方案

最开始我也想着省事，直接把 Android 那套 Kotlin 插件代码挪到鸿蒙上用。试了两天就放弃了，原因非常具体：

第一，原生语言和 SDK 完全不同。Android 插件用 Java/Kotlin 写，跑在 ART 虚拟机里，鸿蒙插件必须用 ArkTS 写，运行在方舟运行时上。两边连类加载机制都不一样，没法直接复用。

第二，网络能力底层不同。Android 上 openai_core 走的是 OkHttp 或者 HttpURLConnection，鸿蒙侧最顺手的是 @ohos.net.http 模块。虽然都支持 HTTPS，但连接复用、超时控制、Cookie 管理这些 API 对不上，甚至流式读取 SSE 数据的方式也完全不同——Android 用 OkHttp 的 enqueue 回调，鸿蒙这边要用 http.Request 的 on('dataReceive') 事件逐块拿数据。

第三，密钥存储方案天差地别。Android 有 EncryptedSharedPreferences 和 Keystore，鸿蒙对应的是 Asset 安全能力，也就是常说的 Asset Store Kit。你要用 Android 的 API 在鸿蒙上保护 API Key，门都没有。

第四，包体形态和构建链路不同。Android 插件最终产物是 AAR，鸿蒙只认 HAP 和 HPS（HarmonyOS Package Service）。Flutter 鸿蒙分支会通过 ohpm install 管理原生依赖，构建脚本里 apply plugin 的写法和 Gradle 完全两套逻辑。网上有人用 Flutter AAR 方式集成，那是把 Flutter 引擎打进既有 Android 工程的做法，用在鸿蒙上概念就错了。

所以真正合理的技术路线是这样的：保留 openai_core 在 Dart 层的模型定义和业务封装，把涉及平台能力的地方（网络发送、证书校验、安全存储、文件读取）抽出来，走 Flutter 的 MethodChannel 和 EventChannel，由 ArkTS 原生侧实现。简单说就是「Dart 管业务，ArkTS 管平台」。

提示：不要试图一次性把所有能力都适配完。建议按「对话补全 → 流式输出 → 函数调用 → 图片生成」的顺序逐步接入，每完成一个环节就在真机上验证，不然排查问题时会非常痛苦。

2. 核心细节：API 映射、流式响应与基础能力落地

2.1 先盘点 openai_core 到底干了哪些活

openai_core 在设计上把 OpenAI 的能力基本都封装了一遍：Chat Completion、Streaming、Function Calling、Embedding、Image Generation、Fine-tuning、Audio 等。对我们这种做智能助手应用的团队来说，最核心的是前三项。

在适配之前，我把要用的能力做了一个清单，避免一会儿改一会儿漏：

• Chat Completion：构造 ChatCompletionRequest，携带 model、messages、temperature、max_tokens 等参数，发起请求后一次性返回完整回复。
• Streaming：同样是补全请求，但 stream=true，服务端按事件流逐块返回，客户端要逐块解析增量内容并实时渲染。
• Function Calling：在请求里声明 tools，模型在需要时返回 function call 的结构化参数，客户端执行本地函数后再把结果回传给模型，形成多轮工具调用链路。
• Embedding：把文本转成向量，用于本地语义检索和记忆系统。
• Image 和 Audio：锦上添花的能力，本期适配先放着。

清单列出来后，我发现这些能力的底层依赖高度重合：都需要 HTTP 请求能力、都依赖 JSON 编解码、都可能涉及密钥读取。也就是说，只要把底层平台通道打好，业务层面的封装几乎不用改。

2.2 Dart 方法与 ArkTS 能力映射表

适配过程本质就是做一张「翻译对照表」。我把自己实际用的映射关系整理如下，你接项目时可以照着补全：

这张表的核心逻辑是：凡是 openai_core 内部通过 package:http 发出的请求，在鸿蒙适配层都替换成 @ohos.net.http；凡是需要读取敏感信息的地方，都替换成鸿蒙安全存储。业务层的请求体序列化逻辑全部保留，因为它跟平台无关。

2.3 流式响应在鸿蒙侧的实现细节

流式响应是最容易翻车的地方，因为 SSE（Server-Sent Events）的数据是分块到达的，每块不一定是一个完整 JSON。我第一次接的时候直接用 httpRequest.on('headersReceive') 之后再去读 body，结果发现 @ohos.net.http 的响应体默认是一个整体字节数组，流式场景根本不适合。

正确做法是用 http.Request 的 on('dataReceive') 事件，这个事件的回调会拿到二进制 chunk，你需要自己维护一个累加缓冲区，按换行符切割事件数据，再解析成 data: {...} 格式。我在 ArkTS 侧写了一个简单的 SSE 解析器，核心逻辑如下：

typescript复制// ArkTS：SSE 流式解析器（简化版）
let buffer: ArrayBuffer | null = null;
let eventList: string[] = [];

httpRequest.on('dataReceive', (data: ArrayBuffer) => {
  // 把新数据追加进缓冲区
  buffer = buffer ? appendBuffer(buffer, data) : data;
  let text = util.TextDecoder.create('utf-8').decodeToString(buffer);
  // 按空行分割 SSE 事件
  let events = text.split('\n\n');
  buffer = encodeIntoBuffer(events.pop() ?? ''); // 最后一段可能不完整，保留
  for (let event of events) {
    let lines = event.split('\n');
    let dataField = '';
    for (let line of lines) {
      if (line.startsWith('data:')) {
        dataField += line.substring(5).trim();
      }
    }
    if (dataField === '[DONE]') {
      eventChannel.send('__done__');
    } else {
      eventChannel.send(dataField);
    }
  }
});

Dart 侧通过 EventChannel.receiveBroadcastStream() 接收事件，每个事件就是一段 JSON 字符串，交给 openai_core 的流式解析逻辑处理。这里有个性能细节：不要在每收到一块数据就刷新 UI，建议在 Flutter 侧做一个 50ms 左右的分帧缓冲，等增量数据积累到一个小批次再 setState，否则快速流式输出时 UI 会非常卡顿。

2.4 本地模型与云端模型的取舍

适配过程中总有人问，既然鸿蒙 NEXT 现在也推本地 AI 推理（MindSpore Lite、盘古端侧模型这些），是不是可以把 openai_core 替换掉？我的回答是：看场景。

如果产品主打的是轻量级意图识别、关键词抽取、本地文本分类，端侧模型确实更省成本，延迟低、不依赖网络，体验也稳。但如果要做开放式问答、复杂推理、长文本生成，云端大模型能力比端侧要强太多，openai_core 这种云端集成方案还是主流。

更实际的做法是混合路由：把用户请求先做一层本地意图分类，判断是简单任务还是复杂任务。简单任务走端侧规则或者本地模型，复杂任务才走 openai_core 上云。这样既控制了成本，又保证了复杂场景的质量。鸿蒙 SDK 里已经提供了端侧推理相关的接口，Flutter 侧可以通过 MethodChannel 把文本丢给端侧模型，拿回结构化结果后再决定是否上云。这部分代码不复杂，但能明显降低 API 调用量。

3. AI 推理资产与安全管控实战

3.1 API Key 和敏感配置不在 .env 里裸奔

很多 Flutter 工程的常见做法是把 .env 文件塞进项目，用 flutter_dotenv 读出来。这在纯 Android/iOS 时代勉强能用（其实也不安全），到了鸿蒙必须改掉。原因有两个：

一是 HAP 包会携带资源文件，.env 被打进去之后，反编译 resources 目录直接能看到明文密钥；二是鸿蒙应用有安全检测和隐私合规要求，明文存储敏感凭据会被上架审核打回。

我的做法分三步：

第一步，密钥不落库。把 openai_core 的 apiKey 通过构建参数注入，在写代码时保证源码里不出现真实密钥，开发环境全部用 Mock Key。

第二步，真机密钥放 Asset Store Kit。首次启动时，应用通过后台接口拿一个加密的密文，写入鸿蒙的 Asset 安全区。运行时 ArkTS 侧读取 Asset 后通过 MethodChannel 返回，openai_core 初始化时再注入。这样即使 HAP 被拿去做静态分析，也拿不到有效密钥。

对应 ArkTS 侧的写入和读取逻辑大概是这样：

typescript复制// ArkTS：Asset Store Kit 存取 API Key
import { asset } from '@kit.AssetStoreKit';

async function saveApiKey(plainKey: string): Promise<void> {
  let alias = 'openai_api_key';
  await asset.add({
    alias,
    values: {
      secret: plainKey,
    },
    accessibility: asset.AssetAccessibility.DEVICE_FIRST_UNLOCKED,
    sync: false,
  });
}

async function loadApiKey(): Promise<string | null> {
  try {
    let result = await asset.query({
      alias: 'openai_api_key',
    });
    // result 里取到的是密文
    return result[0]?.values?.secret as string;
  } catch (e) {
    return null;
  }
}

第三步，证书校验。在 MethodChannel 初始化时，把 HTTPS 证书指纹的哈希值传给 ArkTS 侧，@ohos.net.http 请求时校验服务端证书指纹。这一步能有效防止中间人抓包，比单纯信任系统证书安全得多。

3.2 Token 计量与成本可视化

AI 推理资产不只是模型和密钥，token 用量是要长期盯着的「资产消耗」。openai_core 的响应里通常带 usage 字段，但如果你每次请求完只把它打印到控制台，成本根本控不住。

我在项目里做了一个很轻量的方案：Dart 侧拦截所有 chat completion 响应，把 prompt_tokens、completion_tokens、total_tokens 三个值剥离出来，通过 MethodChannel 交给 ArkTS 侧，按「应用版本 + 日期 + 模型名」三个维度聚合，写入本地数据库。然后开一个 Provider 把每日累计用量暴露给 UI，开发期内置一个「今日已调用 N 次 / 已消耗约 M 万 token」的小卡片，一眼就能看到花费。

这里有一个容易漏掉的点：流式响应里每个 chunk 都不带 usage，只有最后一个 chunk 会返回完整的 token 统计。所以做流量统计时，千万别在每个 chunk 里累加 usage，那样会把 token 数算重好几倍。正确做法是等 EventChannel 收到 __done__ 信号后，解析最后一个 JSON 块，取 usage 字段。

我还顺手做了「预算守护」：ArkTS 侧每累计 1000 次请求或者单日 token 超过阈值，就主动向 Flutter 推一个全局事件，触发 UI 弹窗提示「今日调用量已达限额」，同时可以把后续请求自动降级到本地模型。这个机制非常管用，尤其适合团队内部测试多个 AI 功能并行调用的阶段，能避免月底收到意料之外的账单。

3.3 模型参数预设的资产管理

模型参数（temperature、max_tokens、top_p、presence_penalty）这些不是写死就完事的。每个功能模块对模型行为的期望完全不同：客服场景要低 temperature 保证稳定，创意写作要稍高 temperature 保证多样性。如果把所有请求都统一用一个参数组，效果总差那么一点。

我的处理方式是把每个场景的参数预设做成一个资产文件，集中管理。比如在项目里建了一个 assets/ai_configs/ 目录：

json复制{
  "scene": "customer_service",
  "model": "gpt-4o-mini",
  "temperature": 0.3,
  "max_tokens": 512,
  "top_p": 1.0,
  "presence_penalty": 0.0,
  "frequency_penalty": 0.0,
  "context_window_turns": 8
}

运行时 Dart 侧按场景名加载资产，把它映射成 openai_core 的请求参数。好处有两个：一是产品调参时不用改代码，直接改 JSON；二是鸿蒙打包时这些资产会被当成普通资源放进 HAP，只要 Git 仓库里不存真实密钥，合规和协作都没问题。

注意：max_tokens 设置需要根据上下文长度做动态计算。如果历史对话已经很长，还固定用 512 的 max_tokens，可能在请求层就超出模型的 context window 被拒绝。我的经验是让客户端计算历史消息的字符总数，换算成约等于 token 数（中文场景 1 字约等于 0.7～1 token），用 context_window - history_tokens 作为动态 max_tokens，这样能最大化利用上下文空间。

4. 模型集成实战：从普通对话到函数调用

4.1 三步跑通第一个对话补全

适配完底层通道后，我在项目里做了集成验证，确认 openai_core 在鸿蒙上能完整跑通对话补全。步骤很直白：

第一步，初始化 openai_core。注意这里不要直接填 apiKey 字符串，而是用一个异步获取函数：

dart复制class AiClientManager {
  static late OpenAICore client;

  static Future<void> init() async {
    final apiKey = await SecureTokenBridge.getApiKey(); // 走 MethodChannel 读 Asset
    final baseUrl = await SecureTokenBridge.getBaseUrl(); // 可配置网关地址
    client = OpenAICore(
      baseUrl: baseUrl,
      apiKey: apiKey,
      organization: null,
    );
  }
}

第二步，构造并发送对话请求。openai_core 的模型定义很规整，直接复用官方 ChatCompletion 的字段：

dart复制final request = ChatCompletionRequest(
  model: 'gpt-4o-mini',
  messages: [
    ChatCompletionMessage(role: 'system', content: '你是一位鸿蒙开发助手，回答简洁精准。'),
    ChatCompletionMessage(role: 'user', content: '如何在 HarmonyOS NEXT 上使用 Flutter 开发应用？'),
  ],
  temperature: 0.3,
);

final response = await AiClientManager.client.chatCompletion(request);
print(response.choices.first.message.content);

第三步，验证返回结果并统计 usage。这一步我在上面提过，要显式把 response.usage 提出来交给 token 统计模块。ChatCompletionResponse 里的 usage 字段对应 prompt_tokens、completion_tokens 和 total_tokens，你可以在接口层统一拦截。

这三步跑通后，基础对话能力就具备了。这时候不要急着加花活，先在鸿蒙真机上连续发 20～30 个请求，观察内存有没有上涨、重复请求是否正常释放。别忘了打开 DevEco Studio 的崩溃日志开关，一旦发现 undefined symbol 或者 Cannot find module 这类报错，基本就是 ArkTS 侧的模块导出问题，要回去检查 Index.ets 的导出配置。

4.2 流式对话体验优化与中断控制

一次性返回在开发阶段够了，但用户实际聊起来体验很一般。Prompt 一旦超过 200 字，完整回答可能要等好几秒，这个阶段没有反馈，用户会觉得应用卡死。所以要接流式。

调用方式上，openai_core 提供了流式接口，只需要在请求里把 stream: true 传上，然后监听返回的事件流：

dart复制final request = ChatCompletionRequest(
  model: 'gpt-4o-mini',
  messages: messages,
  stream: true,
);

await for (final event in AiClientManager.client.streamChatCompletion(request)) {
  if (event.choices.isNotEmpty) {
    final delta = event.choices.first.delta?.content ?? '';
    // 分帧更新 UI
    streamController.add(delta);
  }
}

这段代码在 Android 上很常见，但在鸿蒙上能否流畅运行，完全取决于 EventChannel 怎么从 ArkTS 往 Dart 灌数据。我在调试中发现两个问题：

一个是「数据频率过高」。如果 ArkTS 侧收到一个 SSE chunk 就立刻往 Dart 推，Flutter 端的 EventChannel.receiveBroadcastStream() 处理不过来时会出现 backpressure，表现为 UI 文本跳动、卡顿。解决办法是在 Dart 侧收到事件后不直接渲染，而是塞进一个 buffer，用 Timer.run + setState 合并渲染，每 50ms 批量刷新一次。

另一个是「中断失灵」。用户点击停止生成时，很多人只用 cancel() 取消 Dart 侧的订阅，但 ArkTS 侧的原生请求并不知道，还在继续接收网络数据，白白消耗流量和电量。正确做法是在 Dart 侧取消的同时，立刻通过 MethodChannel 调一个 openai_stream_cancel 方法，让 ArkTS 侧主动调用 httpRequest.off('dataReceive') 并断开连接。

4.3 鸿蒙场景下的函数调用：让模型能操作 App

函数调用（Function Calling）是我们产品最依赖的能力，用户说「帮我把明天上午的日程加进去」，模型负责把这句话转成结构化参数，应用负责真正创建日历事件。这个能力在鸿蒙适配里没有新增太多平台代码，核心是把 openai_core 的 tools 声明透传好，并在模型返回 tool_calls 时正确回传执行结果。

我在代码里的做法是定义一个工具注册表，用一个 Map 绑定「工具名」和「Dart 执行函数」：

dart复制final tools = [
  Tool(
    type: 'function',
    function: ToolFunction(
      name: 'create_calendar_event',
      description: '在本地日历创建日程事件',
      parameters: {
        'type': 'object',
        'properties': {
          'title': {'type': 'string', 'description': '日程标题'},
          'startTime': {'type': 'string', 'description': '开始时间，ISO8601格式'},
          'durationMinutes': {'type': 'integer', 'description': '持续时间'},
        },
        'required': ['title', 'startTime'],
      },
    ),
  ),
];

final request = ChatCompletionRequest(
  model: 'gpt-4o-mini',
  messages: messages,
  tools: tools,
);

final response = await AiClientManager.client.chatCompletion(request);
final toolCalls = response.choices.first.message.toolCalls;

拿到 toolCalls 后执行本地函数，再把结果以 tool 角色的消息回传，形成第二轮对话。需要注意的一点是：openai_core 的 ToolCall 数据结构里，参数是一个字符串化的 JSON，你需要用 jsonDecode 解析后再传给 Dart 执行函数。如果直接拿字符串去拼参数，十有八九会失败。

为了让函数调用在鸿蒙上更「原生」，我还做了个增强：把部分功能桥接到 ArkTS 侧的系统能力。比如创建日历事件这个事，Dart 层只做参数校验，真正调用系统日历的代码放在 ArkTS 里，通过 MethodChannel 传动作参数。这样既保留了 openai_core 的模型逻辑，又不越过鸿蒙系统能力的边界，后续做权限申请、隐私说明都方便。

5. 常见问题排查与避坑清单

5.1 高频问题速查表

适配和集成过程中，我踩了一堆坑，下面这张表是把最典型的问题和解决方案按「症状 → 原因 → 解法」整理出来的速查表，建议直接贴进你自己的排查文档里：

5.2 这几个坑值得单独拿出来说

第一个是「鸿蒙模拟器与真机的网络行为不一致」。模拟器环境下网络请求往往表现正常，一到真机就各种连接失败。这不是玄学，而是真机的网络权限、隐私弹窗、HTTPS 证书校验逻辑比模拟器严格得多。我建议从第一天起就在真机上调试 AI 请求链路，模拟器只用来验证 UI 布局。别问我为什么这么强调，问就是我曾在模拟器上跑通了所有功能，结果在真机上一轮轮排查权限弹窗排查到深夜。

第二个是「Flutter 与 ArkTS 的状态同步」。项目里如果之前用了 flutter provider 管理状态，到了鸿蒙侧要特别注意跨语言的同步问题。我试过在 Dart 侧用 Provider 管理聊天消息，同时需要把部分状态同步到 ArkTS 侧（比如聊天面板快捷动作的状态），直接双向同步会搞出很多一致性问题。更好的做法是：Dart 侧是唯一数据源，ArkTS 侧所有需要状态的场景都通过 MethodChannel 主动向 Flutter 请求，而不是在两边各维护一份状态副本。这样写出来的代码虽然多几行样板，但排查问题时思路清晰得多。

第三个是「ArkTS 和 Dart 谁更流行」这类话题的干扰。平时刷到这种讨论，很容易让人冲动地把项目核心逻辑用 ArkTS 重写一遍。我的建议是不要被「原生化」的冲动绑架。Flutter 层的代码跨端复用价值极高，鸿蒙侧只需要做薄薄的能力封装层。你要比的不是谁语法更流行，而是哪一层代码能让你在安卓、iOS、鸿蒙三端同时少写 70% 的重复劳动。哪怕是鸿蒙原生开发现在越来越成熟，对一个已有 Flutter 代码资产的项目来说，保持「Flutter 业务 + ArkTS 平台能力」的结构依然是最稳妥的路线。

5.3 针对鸿蒙元服务形态的准备

如果你上架时不只是做独立 HAP，还想把 AI 能力做成鸿蒙元服务（元服务是一种免安装的轻量形态），那需要做两个调整。第一个是包体瘦身：元服务对包大小有严格限制，超过限制根本发布不了，所以 openai_core 相关的原生 so 库只能按目标架构精简，模型资源能云端化的绝不打包。第二个是生命周期适配：元服务的生命周期比全量应用更严格，后台运行时间受限，流式对话期间要做前台长时任务的申请，否则用户切换桌面再回来，AI 对话可能已经断了。

我在做元服务适配时，实际把 openai_core 的依赖裁了一截，只保留 Chat Completion 和 Streaming，音频和图片生成全部走服务端 API，客户端不落模型文件。这样 HAP 体积直接少了一半，启动速度也快了。你的项目如果偏内容生成类，也可以按这个思路做能力裁剪。

6. 适配收尾的几点体会

最后再分享几个个人感悟，算是从这次鸿蒙化适配里真正沉淀下来的东西。

第一个体会是「平台通道的日志一定要从第一天就做」。我在 MethodChannel 两侧都加了统一的 JSON 日志格式，Dart 侧调用时打印方法名、参数摘要、耗时；ArkTS 侧收到请求后打印事件类型、数据大小。后期排查问题几乎全靠这套日志，节省了巨量时间。如果你嫌日志影响性能，至少在生产环境关掉日志的详细开关，但保留错误信息输出。

第二个体会是「密钥管理没有尽头」。即使已经迁移到 Asset Store Kit，密钥轮换机制也一定要提前设计好。我规划的是每个应用版本用不同的 Asset alias，服务端下发密钥时附带版本号，客户端读取时如果版本号落后就主动拉新。这套逻辑不需要很复杂，但能避免「密钥泄露后只能连夜发版」的被动局面。

第三个体会是「给 openai_core 留一个降级口」。鸿蒙生态迭代快，模型网关、系统能力、网络策略都在变化。我没有在业务的每个调用处直接用 openai_core 的实例，而是包了一层 AiGateway，内部先走本地规则引擎判断是否命中缓存，再决定是否走 openai_core 上云。这样即使某天 openai_core 的某个接口在鸿蒙上出了兼容问题，我也能在网关层快速切换掉，而不是四处改业务代码。

适配 openai_core 这件事，说白了就是把「AI 推理资产」这个概念落到一个具体平台上。模型、密钥、token 用量、上下文记忆、工具箱调用，每一类资产都要有清晰的所有权和存取路径。跑通一次只是起点，真正有价值的，是你通过这些细节把整套 AI 集成链路变成团队里的公共能力。希望这篇指南能让你在鸿蒙 NEXT 上少踩几个坑，把精力省下来打磨产品本身。