一、为什么要把大模型服务化1.1 第 7 讲留下的启动器问题第 7 讲我们用 AidGen 的 C 接口把 Qwen2.5 搬上了犀牛派 X1跑通了多轮对话。当时我们说得很清楚那个 C 程序只是一个启动器负责把引擎拉起来、跑通对话这一薄层。问题也随之而来——你的业务代码大概率是 Python、是 Web 前端、是各种脚本它们没法直接去调一个 C 可执行文件里的函数。更现实的是第 7 讲的程序是一次启动、一个进程、一个对话。如果你有三个 Python 脚本都想用这个大模型难道各启一个 C 进程、各加载一份模型端侧内存根本扛不住。这正是服务化要解决的把大模型从某个进程里的内部对象变成一个常驻的、可被多方调用的本地服务。1.2 服务化到底解决了什么把 LLM 做成一个本地 HTTP 服务收益是结构性的不是锦上添花模型只加载一次服务启动时把权重和 KV Cache 结构建好之后所有客户端共享这一份不用每个调用方重复加载。语言解耦只要会发 HTTP 请求Python、Java、Node、甚至浏览器里的 JavaScript 都能调C 彻底退到幕后。接口标准化如果服务说的是OpenAI 兼容那套接口你现成的、为云端 OpenAI 写的一大堆代码几乎不用改就能平移过来。进程隔离服务挂了不影响你的业务进程业务崩了也不动模型排查边界清晰。一句话服务化把端侧大模型从一个能跑的 Demo变成一个能集成进产品的能力。这一讲我们就把第 7 讲的本地大模型用 AidGenSE 封装成一个对外的本地服务。1.3 本讲目标与硬件准备读完本讲你应该能第一理解 AidGenSE 相对 AidGen 多出来的服务层是什么、为什么选 OpenAI 兼容接口第二把 Qwen2.5 通过 AidGenSE 起成一个监听本地端口的服务第三用 Python 的requests或openaiSDK 调通包括流式接收第四处理服务化带来的新坑端口、绑定地址、并发、上下文。硬件上沿用第 7 讲的犀牛派 X1QCS8550——跑 LLM 仍然需要它的 NPU 算力与内存水位。模型也沿用第 7 讲从 Model Farm 下载的 Qwen2.5-0.5B-Instruct。如果你第 7 讲的模型已经部署好本讲可以直接在它基础上加服务层。1.4 进程内嵌 vs 独立服务再权衡一次第 7 讲 6.7 节我们对比过进程内嵌入和独立服务两种集成思路当时的结论是服务化更灵活。这里把账算细一点免得你选错。进程内嵌入引擎就在你主程序里延迟最低、少一层网络但绑定单一语言、模型随进程份数翻倍、崩了互相拖累独立服务多一跳本地 HTTP 的开销毫秒级本地回环可忽略换来语言无关、模型共享、故障隔离。对一个模型、多个消费方这种端侧常见形态服务化几乎总是更划算——本地回环的延迟代价远小于多加载一份模型的内存代价。二、AidGenSE 在工具链中的位置2.1 站在 AidGen 肩上的服务层回忆一下工具链的分层AidLite 是统一推理底座AidGen 在它之上做生成式推理KV Cache、自回归、对话模板。AidGenSE 则再往上叠一层——把 AidGen 的推理能力包装成一个网络服务。客户端: Python / Web / 其他语言AidGenSE 服务层: OpenAI 兼容 HTTPAidGen 生成式推理AidLite 统一推理底座CPU / GPU / NPU所以你之前建立的认知全部继续生效底层还是 AidLite 调度算力中间还是 AidGen 管生成AidGenSE 只是在最外面加了一个HTTP 门面。它不替代 AidGen而是给 AidGen 装上了一个标准接口让不会 C 的代码也能用。2.2 为什么选 OpenAI 兼容接口市面上本地大模型服务不少接口各不相同。AidGenSE 选择对齐 OpenAI 的 HTTP 接口/v1/chat/completions这一套原因很务实这是当前事实上的行业通用约定围绕它有海量的现成客户端、SDK、教程和示例代码。你的项目如果之前是对着云端 OpenAI 写的切到本地 AidGenSE 往往只需要改一个base_url指向本机业务逻辑零改动。这也是端侧落地的一个通用思路——尽量复用已有的标准接口而不是发明一套私有协议。私有协议意味着所有调用方都要专门适配标准接口意味着生态里的工具开箱即用。当然兼容通常指核心字段对齐具体支持到哪个程度哪些参数生效、哪些被忽略以 AidGenSE 当前版本文档为准。2.3 aidllm CLI 与服务的两种用法AidGenSE 提供命令行工具aidllm它通常有两种角色一是交互式对话在终端里直接和模型聊适合快速验证模型能不能用二是启动服务把模型起成一个后台 HTTP 服务供程序调用。本讲的重点是后者但前者很有用——服务起不来时先用 CLI 交互模式确认模型本身能加载、能出 token可以帮你把模型问题和服务问题分开排查。具体子命令与参数以aidllm --help和官方文档为准。2.4 本地服务与云端 OpenAI 的边界把接口做成 OpenAI 兼容容易让人产生它就是本地版 OpenAI的错觉。要清醒接口兼容不等于能力等价。本地服务跑的是 0.5B、1.5B 量级的小模型能力和云端的大模型不在一个层级它也没有云端那种弹性并发同时来太多请求会排队甚至超时。所以本地 AidGenSE 的定位依然是云端补充——处理那些数据不出本机、断网也要能用、调用量不巨大的场景。选型时那句老话仍然适用这数据敢不敢出本机、这网络靠不靠得住。三、接口与模型8888 端口背后3.1 /v1/chat/completions 与流式 SSEOpenAI 兼容接口的核心是聊天补全接口/v1/chat/completions。你发一个 JSON里面带messages消息列表含 system/user/assistant 角色和model等字段服务返回模型的回复。如果请求里streamtrue服务就用SSEServer-Sent Events逐 token 推送——这对应第 7 讲说的流式生成只是这次 token 是通过 HTTP 响应一条条推给客户端而不是 C 回调。理解 SSE 很关键它不是一次性返回完整 JSON而是保持连接、不断下推形如data: {...}的片段每个片段含一小段增量文本最后以data: [DONE]收尾。客户端要按这个格式逐行解析、拼接增量。第 6.3 节会给出完整的解析代码。3.2 模型格式与加载.gguf / .bin / .aidem端侧大模型有几种常见的权重格式AidGenSE/AidGen 侧可能遇到.gguf、.bin、.aidem等具体支持范围以官方文档为准。你不必深究每种格式的内部结构但要明白两点一是格式要和引擎匹配从 Model Farm 下载时选的就是适配 AidGen/AidGenSE 的版本别拿别处的权重硬塞二是格式往往已包含量化信息比如 INT8/INT4文件名或配套说明里会标注。加载时服务会按格式解析权重、构建推理图这一步是启动开销的大头。3.3 多轮对话的会话状态谁管这是个容易踩的认知坑HTTP 服务本身是无状态的服务端不会替你记对话历史。多轮对话的记忆靠客户端每次把完整messages列表包含之前的每一轮一起发上来。也就是说第 7 讲 6.3 节讲的历史怎么攒在服务化场景下从 C 程序内部挪到了你的客户端代码里。你要自己维护一个消息数组每轮把用户输入和模型回复 append 进去下次请求整体发送——同时要控制它不超过上下文长度 cl否则报错或被截断。会话管理这份责任服务化后仍在调用方。3.4 并发与上下文长度的服务级约束服务化了就要考虑多个客户端同时来的情况。端侧服务的并发能力有限每个进行中的请求都占一份 KV Cache 内存并发越高、上下文越长内存压力越大。本地服务不像云端能弹性扩容超出承受就会排队、变慢甚至报错。工程上的对策一是限制同时接入的客户端数量二是控制每个请求的上下文长度三是把长上下文和高并发当成一对要权衡的资源而不是各自无限要。具体并发上限以你的真机实测与版本为准。3.5 服务化调用的时延构成与优化方向服务化之后一次调用的总时延可以拆成几段搞清楚每一段才知道该优化哪。大致是网络往返本地回环毫秒级、跨机看网络质量 排队等待前面有请求在跑时你得等 首 token 延迟模型从收到请求到产出第一个 token 生成时长后续 token 逐一出完。本地回环下网络几乎可忽略真正的重头仍是模型本身的首 token 与生成。所以优化方向和第 7 讲一致小模型、小 cl 直接压低首 token 与生成而排队这一段只和并发有关——客户端一多后来的就得等前一个生成完。如果你发现单客户端很快、多客户端明显变慢瓶颈多半在排队而非网络这时要么限并发、要么接受排队、要么换算力更高的平台。把时延拆开看能避免把模型慢误诊成网络慢。3.6 看懂一次完整的请求与响应把接口字段看全调的时候心里才有底。一次典型的非流式响应长这样字段以实际返回为准{id:chatcmpl-local-001,object:chat.completion,created:1717000000,model:qwen2.5-0.5b-instruct,choices:[{index:0,message:{role:assistant,content:边缘计算是把计算放到靠近数据源的设备上……},finish_reason:stop}],usage:{prompt_tokens:24,completion_tokens:57,total_tokens:81}}几个字段值得记住choices[0].message.content是模型回复本体finish_reason告诉你生成是正常结束stop还是被长度截断length——出现它说明撞了 max_tokens 或上下文上限usage里的 token 统计能帮你估算上下文占用prompt_tokens就是你发上去的历史有多长、completion_tokens是这次生成了多少。流式时每个片段结构类似只是message换成delta、且通常不带完整usage。读懂这些字段排查回复被截断上下文占用异常就有抓手了。四、环境调研安装与版本对齐4.1 安装 AidGenSE和第 7 讲装 AidGen 一样AidGenSE 也通过aid-pkg安装具体包名以 AidLux 当前文档为准形态类似aid-pkg -i aidgense-sdk或随 AidGen 一并提供sudoaid-pkg updatesudoaid-pkginstallaidgense-sdk# 包名以文档为准装完后aidllm命令应可用用which aidllm或aidllm --help确认。老规矩装完用aid-pkg installed核对 AidGenSE 在列、版本正确。4.2 版本对齐服务 / 模型 / QNN版本纪律在工具链里反复强调服务化也不例外。这里要三方对齐AidGenSE 服务的版本、底层 AidGen/AidLite/QNN 的版本、以及模型所适配的版本。比如某模型标注需 AidGen X 及以上 QNN Y你的服务和底层都得满足否则轻则起不来、重则输出乱码。建议把模型 → AidGenSE 版本 → QNN 版本并进第 7 讲那张版本总表一处维护。版本对齐看着枯燥却是端侧从能跑到稳定跑的分水岭。4.3 端口与防火墙服务默认监听一个本地端口常见为8888具体以文档/配置为准。起服务前确认两件事一是这个端口没被别的进程占用用ss -tlnp或netstat查二是如果你打算从局域网内别的机器访问比如开发机上的浏览器调板子上的服务要确认服务绑定的是0.0.0.0而不是仅127.0.0.1且板子防火墙没拦这个端口。只允许本机访问的话绑127.0.0.1更安全。端口与绑定地址是服务化最常翻车的两个点提前想清楚。五、操作步骤把 Qwen2.5 跑成本地服务下面以把第 7 讲的 Qwen2.5-0.5B-Instruct 起成一个 OpenAI 兼容本地服务为例讲流程。具体命令、参数、配置项以 AidGenSE 当前版本文档为准这里讲不变的逻辑。5.1 准备模型目录确认第 7 讲的模型还在/home/aidlux/models/qwen2.5-0.5b-instruct/目录内含权重、配置、对话模板。服务要按这个路径加载模型——再次强调路径一律用绝对路径理由同第 7 讲坑点 7.1服务以不同工作目录启动时相对路径极易解析错。5.2 启动服务用aidllm把模型起成服务示意如下具体子命令与参数以文档为准# 示意以 OpenAI 兼容服务方式加载模型监听 8888aidllm serve\--model/home/aidlux/models/qwen2.5-0.5b-instruct\--host0.0.0.0\--port8888\--context-length2048启动后终端会输出加载日志看到服务已监听 8888之类的提示说明起来了。如果卡在加载阶段多半是内存不足模型太重或 cl 太大或路径/模板问题回到第 7 讲的排查思路。5.3 验证服务存活服务起来后先用最轻的方式探活。直接对聊天接口发一个极短请求或在终端用aidllm的交互模式确认模型能对话。探活通过说明模型能加载 服务能响应这条链路通了再进入正式的客户端开发。这一步相当于第 2 讲的先跑官方示例验环境——先把成功路径跑通再往上叠自己的代码。5.4 调整上下文与并发服务启动参数里的上下文长度--context-length和并发相关配置要根据你的场景调。回忆第 7 讲cl 越大 KV Cache 越吃内存。服务化后这个账要乘以并发数。建议先用保守的 cl如 1024/2048把服务跑稳确认多客户端能正常收发再按需上调并实测内存占用是否还有余量。别一上来就开大 cl 高并发那是端侧服务最常见的起得来、跑不久的根源。六、关键代码Python 客户端 流式服务起来了现在用你最熟悉的 Python 来调。下面三种方式从简到全。6.1 requests 最小调用最朴素的方式用requests直接 POST 聊天接口非流式importrequests urlhttp://127.0.0.1:8888/v1/chat/completions# 板子本机跨机换成板子 IPpayload{model:qwen2.5-0.5b-instruct,messages:[{role:system,content:你是一个有帮助的本地助手回答简洁准确。},{role:user,content:用一句话解释什么是边缘计算。},],stream:False,}resprequests.post(url,jsonpayload,timeout120)dataresp.json()print(data[choices][0][message][content])字段结构对齐 OpenAI 的聊天接口请求带messages响应从choices[0].message.content取回复。具体的可用字段、是否需鉴权头以 AidGenSE 文档为准。6.2 openai SDK 调用如果你装了openai这个 Python 包可以用它调本地服务——只需把base_url指向本机fromopenaiimportOpenAI clientOpenAI(base_urlhttp://127.0.0.1:8888/v1,api_keynot-needed)# 本地服务通常不校验 keyrespclient.chat.completions.create(modelqwen2.5-0.5b-instruct,messages[{role:user,content:用一句话解释什么是 NPU。}],)print(resp.choices[0].message.content)这就是 OpenAI 兼容的价值你为标准接口写的代码改个base_url就能从云端平移到本地。api_key本地服务一般不校验给个占位即可。6.3 流式接收SSE 解析体验上流式远好于干等整句。用requests按 SSE 逐行解析增量importrequests,json urlhttp://127.0.0.1:8888/v1/chat/completionspayload{model:qwen2.5-0.5b-instruct,messages:[{role:user,content:讲一个三句话的短故事。}],stream:True,}withrequests.post(url,jsonpayload,streamTrue,timeout120)asr:forlineinr.iter_lines(decode_unicodeTrue):ifnotlineornotline.startswith(data:):continuedataline[len(data:):].strip()ifdata[DONE]:breakdeltajson.loads(data)[choices][0][delta].get(content,)print(delta,end,flushTrue)print()要点streamTrue让requests保持连接按行读挑出data:开头的行[DONE]表示结束每个片段的增量文本在choices[0].delta.content。边收边打印就是打字机效果。6.4 多轮对话的客户端历史管理服务无状态历史要客户端自己攒。维护一个消息列表每轮 appendfromopenaiimportOpenAI clientOpenAI(base_urlhttp://127.0.0.1:8888/v1,api_keynot-needed)messages[{role:system,content:你是一个有帮助的本地助手。}]defchat(user_input):messages.append({role:user,content:user_input})respclient.chat.completions.create(modelqwen2.5-0.5b-instruct,messagesmessages)answerresp.choices[0].message.content messages.append({role:assistant,content:answer})# 把回复也并入历史returnanswer注意这正是 3.3 节说的服务不记历史你每次都得把完整messages发上去。messages会越攒越长撞上 cl 上限时要做截断或摘要思路同第 7 讲 6.3否则报错或遗忘。6.5 封装成可复用的 client 模块产品里别让每个脚本都重复写请求细节封装一个模块统一收口# local_llm.py —— 本地大模型客户端封装fromopenaiimportOpenAIclassLocalLLM:def__init__(self,base_urlhttp://127.0.0.1:8888/v1,modelqwen2.5-0.5b-instruct):self.clientOpenAI(base_urlbase_url,api_keynot-needed)self.modelmodel self.messages[{role:system,content:你是一个有帮助的本地助手。}]defask(self,text,max_history10):self.messages.append({role:user,content:text})# 控制历史长度防止超出上下文self.messages[self.messages[0]]self.messages[-max_history:]respself.client.chat.completions.create(modelself.model,messagesself.messages)answerresp.choices[0].message.content self.messages.append({role:assistant,content:answer})returnanswer别处只要from local_llm import LocalLLM; llm LocalLLM(); llm.ask(...)就能用。把 base_url、model、历史管理、异常处理都收进这一层业务代码就干净了。6.6 从 Web 前端调用浏览器里的流式与跨域不少端侧应用的操作界面就是一个 Web 页面直接从浏览器调本地服务也很常见。浏览器里发非流式请求用fetch即可要流式可以用fetch的ReadableStream逐块读响应体或用EventSource原生支持 SSE但它只支持 GET而聊天接口通常是 POST所以更通用的是 fetch ReadableStream。这里有个专门的坑——跨域CORS如果你的网页和服务不在同一个源主机或端口不同浏览器会拦截跨域请求需要服务端在响应头里放行如Access-Control-Allow-Origin。AidGenSE 是否默认放行、如何配置以官方文档为准若不支持可让网页与服务同源部署或在前面加一层反向代理统一源。浏览器直连本地服务很顺手但这层页面别随便暴露到不可信的网络里。七、坑点7.1 端口被占用 / 服务起不来启动报地址已占用或起不来先查端口用ss -tlnp | grep 8888看是不是已有进程占了 8888可能是上次没退干净的服务。对策kill 掉旧进程或换个端口再起。7.2 跨机访问不通绑定地址本机curl 127.0.0.1:8888通但从开发机访问板子 IP 不通——多半是服务只绑了127.0.0.1。对策起服务时把 host 设为0.0.0.0并确认板子防火墙放行了该端口。只在本机用就保持127.0.0.1更安全。7.3 流式中断 / 连接被掐流式收到一半断了常见原因网络抖动跨机时、服务端因内存不足崩了、或客户端读超时设太短。对策跨机优先保证网络稳定客户端给足timeout服务端崩溃去查内存cl / 并发是不是开大了。7.4 上下文超长报错聊着聊着服务报错或回复异常很可能是messages累积超过了 cl。对策客户端做历史截断 / 滑动窗口 / 摘要6.4、6.5别指望服务端替你兜底。这条和第 7 讲cl 是内存墙上的门是同一个问题在服务化场景的重现。7.5 模型路径 / 版本不对服务起不来或输出乱码回到老三样模型路径是不是绝对路径、对话模板和模型是否匹配、服务/模型/QNN 版本是否对齐4.2。服务化只是加了网络层底层这些坑一个都没少。八、验证curl Python 多轮对话8.1 curl 冒烟测试不写代码先用 curl 冒烟curl-shttp://127.0.0.1:8888/v1/chat/completions\-HContent-Type: application/json\-d{ model: qwen2.5-0.5b-instruct, messages: [{role: user, content: 你好请自我介绍。}] }能返回带choices的 JSON说明服务链路通了。curl 是排查是服务的问题还是我代码的问题的最快手段——curl 通而代码不通问题就在你的客户端代码。8.2 首 token 延迟与吞吐服务态服务化后第 7 讲那两个指标依然要测但多了一层网络。用流式请求计时记录发出请求到收到第一个 token 的时间首 token 延迟以及整个生成耗时除以 token 数吞吐。本地回环的网络开销是毫秒级所以这两个指标主要还是由模型尺寸、cl、并发决定。以真机实测为准。8.3 多客户端并发服务化的核心价值是一个模型、多方调用所以必须验证并发。开两三个 Python 进程同时调服务观察是否都能正常返回、响应是否变慢、内存是否暴涨、有没有排队或报错。这一步能帮你摸清端侧服务的真实并发承受力为产品定义同时支持几个客户端提供依据。8.4 异常对照表服务化后出问题的现象也能反推病因。一张速查表“连接被拒绝” → 服务没起或端口不对7.1、5.3“本机通、跨机不通” → 绑定地址或防火墙7.2、4.3“聊着聊着报错” → 历史超 cl7.4、6.4“返回乱码/忽略指令” → 模型模板或版本问题7.5、4.2“流式半途断开” → 内存不足或网络/超时7.3“并发一上来就卡死” → 并发超内存承受3.4、8.3。先对号入座再翻对应章节比盲改快得多。8.5 服务健壮性超时、重试与降级把服务接进产品就要假设它会偶尔出问题客户端得有韧性。三条基本策略一是超时给每次请求设上限比如首 token 等 30 秒、整体等 120 秒别让一次卡死拖住整个业务二是重试对网络抖动类的失败做有限次重试并带退避但对模型真的崩了别无限重试那只会雪上加霜三是降级当本地服务持续不可用时产品要有兜底——提示用户稍后再试或在业务允许且合规的前提下回退到云端接口。把这三条收进 6.5 的封装层你的客户端就从能调通升级到扛得住。量产阶段的进程守护与崩溃自愈第 12 讲会系统展开。九、FAQQ1AidGenSE 和 AidGen 是什么关系AidGen 是生成式推理框架C 接口AidGenSE 在它之上加了一个 OpenAI 兼容的 HTTP 服务层。要做被程序调用的大模型服务用 AidGenSE要自己用 C 深度集成才直接碰 AidGen。Q2本地服务需要联网吗不需要。服务跑在板子上客户端通过本机回环或局域网访问全程数据不出设备。这正是端侧服务化对隐私、离线场景的意义。Q3一定要装 openai 这个 Python 包吗不一定。requests直接发 HTTP 也能调6.1、6.3。装openai只是图它封装得好、且和你已有的 OpenAI 代码兼容。Q4api_key 要填什么本地服务通常不校验 key给个占位字符串即可。如果文档说明需要鉴权按文档配置。Q5能从外网访问这个服务吗技术上把端口暴露到公网可行但强烈不建议——本地服务一般没有完善的鉴权与防护暴露公网有风险。需要远程访问请走内网穿透或加一层带鉴权的网关并做好安全配置。Q6多轮对话为什么要每次发完整历史因为 HTTP 服务无状态服务端不记对话。上下文靠客户端每次把完整messages发上来维持。这也是为什么历史管理和 cl 控制落在调用方。Q7和直接用 llama.cpp 的 server 比呢思路一致都是本地 OpenAI 兼容服务差别在底层AidGenSE 复用 AidGen/AidLite 的高通 NPU 调度与端侧优化。选它是为了和工具链其余部分AidLite、AidGen保持一致的后端与调度。Q8服务能同时挂多个模型吗取决于 AidGenSE 的能力与内存。端侧内存有限挂多个大模型很容易爆。具体是否支持多模型、如何配置以官方文档与真机实测为准。Q9首 token 很慢正常吗端侧小模型的首 token 延迟比云端高是常态受模型尺寸、cl、并发影响。先看是否在你的体验预算内再按第 7 讲的调优顺序先尺寸、再 cl、再系统压。Q10服务怎么开机自启 / 常驻把启动命令做成 systemd 服务或开机脚本即可注意用绝对路径、配好依赖环境。量产化的进程守护、崩溃自愈等话题第 12 讲会系统讲。十、结论这一讲我们把第 7 讲的本地大模型真正变成了可调用的服务用 AidGenSE 在 AidGen 之上加了 OpenAI 兼容的 HTTP 门面让 Qwen2.5 在犀牛派 X1 上以标准接口对外提供对话能力。你也亲手用 Python 的requests和openaiSDK 调通了它包括流式接收和客户端侧的多轮历史管理。更重要的是一个认知转变服务化没有消除任何底层约束反而把会话状态、并发、上下文长度这些责任更明确地交到了调用方手里。接口变成 HTTP 了但模型尺寸、cl、内存这套端侧账一笔都没少。理解这一点你才不会以为套了个 OpenAI 接口就成了云端。到这里Linux 侧的能力已经很完整了——视觉AidCV/AidStream、推理AidLite、大模型AidGen/AidGenSE都在 Linux 这一边跑起来了。但回忆第 1 讲这套融合系统的另一半是 Android你的 App、你的界面、你的传感器很可能在 Android 侧。Linux 上跑好的 AI 能力怎么高效地喂给 Android 用两边隔着系统边界怎么低延迟地交换数据下一讲我们就来解决这个最后一公里——用 AidConnect 打通 Android 与 Linux 之间的数据通道。本文 AidGenSE 的定位、OpenAI 兼容接口、aidllm 用法、模型格式与端口等来自 AidLux 官方文档并发上限、首 token 延迟与吞吐等指标参考端侧 LLM 的一般规律精确值以真机实测与当前版本文档为准。文中命令、字段、代码为结构示意具体以 AidGenSE SDK 与官方文档为准。