尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

Cherry Studio 图像生成参数化架构:从注册表数据到厂商请求体的零重复管线

Cherry Studio 图像生成参数化架构:从注册表数据到厂商请求体的零重复管线 人工智能大模型AI 应用交互助手本地部署【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址https://gitcode.com/CherryHQ/cherry-studio点击查看免费下载本篇技术指南围绕 Cherry Studio 的绘图Paintings页面展开系统讲解其图像生成参数image-generation parameters如何由注册表 参数目录catalog数据驱动实现「一次声明、处处投影」的完整链路从渲染进程按模型渲染参数表单到收集用户输入再到主进程将其转换为各家 LLM 厂商格式正确的图像生成请求。读完本文你将掌握IMAGE_PARAM_CATALOG、WireProfile、splitParamValues等核心构件的职责划分并能独立完成「给模型加参数」「加模型」「加厂商」三类扩展——全程无需编写任何 per-vendor UI 代码canonical→wire 的重命名只声明一次。设计目标新增模型等于改数据Cherry Studio 的图像生成参数系统遵循一条核心原则为每个模型声明支持的参数及其约束options/range/default并为每个厂商声明 wire 格式的差异二者各只有一处声明。其收益是新增图像模型甚至整个新厂商是一次数据变更而不是代码变更多个模型共用的新参数只需在目录catalog中增加一行即可同时流向表单、校验、wire 请求体与静态类型厂商 wire 格式的怪癖字段名、嵌套、双键、透传等各自只存在于一个声明式位置。数据链路总览一个 canonical 袋子两个交付适配器整条管线以一个规范参数集paramValuescanonical camelCase 袋子为主干只在末端分叉为两条交付路径。无论哪条路径canonical 袋子本身完全相同不同的只是适配器将其转换为 wire 请求的方式——SDK 交付走WireProfile生成的providerOptions请求体transport 交付则由运输层自行构造专属信封。┌─ RENDERER ────────────────────────────────────────────────────────────────────┐ │ registry per-model supports ──useImageGenerationSupport──▶ form │ │ imageGenerationToFields: SupportSpec.type → control (one map) │ │ user edits → painting.params (canonical camelCase bag) │ │ canonicalGenerate: buildParamsSchema(support,mode) validate / coerce │ │ → paramValues (pure canonical bag; blanks dropped, customSize composed) │ └──────────────────────────── ipcApi.request(ai.image.generate) ───────────────┘ │ { uniqueModelId, prompt, mode, paramValues, inputImages?, mask? } ▼ (model routing is dynamic; paramValues validated coerced by the catalog imageParamsSchema) ┌─ MAIN · AiService.generateImage ───────────────────────────────────────────────┐ │ splitParamValues(paramValues) ──via AI_SDK_NATIVE_BINDINGS──▶ │ │ structured { n, size, seed, aspectRatio, … } (typed ParamValues {n})│ │ vendorBag { the non-native canonical params, camelCase } │ │ │ │ resolveImageTransport(provider, model)? │ │ ├─ NO → SDK delivery ├─ YES → transport delivery │ │ ▼ ▼ │ │ buildVendorProviderOptions getImageGenerationSupport(provider, │ │ (WireProfile wireName) model).modes[mode].vendorTransport │ │ → providerOptions[id] WIRE body → modelDescriptor (typed routing) │ │ native → imageParams (n/size/seed) generateImageViaJob(structured, │ │ vendorBag, modelDescriptor) │ └────────┼────────────────────────────────────────────┼──────────────────────────┘ ▼ ▼ JobManager → imageGenerationJobHandler AI SDK image model transport.submit(input) (SiliconImageModel / ai-sdk/openai-compatible reads canonical camelCase params / ai-sdk/google / aihubmix custom) input.{n,size,seed} input.modelDescriptor spreads providerOptions[id] → HTTP body builds its own envelope (input.* / parameters.* / messages[]), POST, poll │ │ ▼ parse response ▼ poll → parse response image data URLs ◀────────────── back through IPC ──────────▶ renderer整条链路可以切分为两个半场中间以同一套规范词汇表衔接读半场Read half——注册表supports⊗ 目录 → 表单字段 →painting.params写半场Write half——paramValues→splitParamValues→WireProfile引擎 / transport → 厂商 wire 请求体。两个半场之间的契约就是目录catalogcanonical 键集合 每个键的值类型与 wire 名称。表单、校验、参数分区、静态类型全部由它投影而来因此永远不会漂移。单一事实来源每项事实只声明一次事实声明位置被谁消费参数值类型 wire 名称IMAGE_PARAM_CATALOGParamValues、wireName表单、校验、wire 引擎、structured类型每个模型支持哪些参数 约束options/range/default注册表supports表单 buildParamsSchemacanonical → AI-SDK 原生numImages→n、aspectRatio归一化…AI_SDK_NATIVE_BINDINGSsplitParamValuescanonical → 厂商 wire 名称negativePrompt→negative_promptwireName()目录wire或自动 snake_caseWireProfile aihubmix DEFAULT每个提供商的交付方式双键 / 透传 / 兄弟键 / 信封WIRE_REGISTRY 各 transport两个适配器每个模型的端点路由endpoint / sync / 响应族注册表vendorTransport→modelDescriptortransports这份清单中没有任何一项被重复一个 canonical 参数就是一行目录条目一个提供商的 wire 形态就是一个 profile / transport。第一层参数目录原子层单一事实来源是packages/provider-registry/src/schemas/imageParamCatalog.ts。每个CanonicalParamKey只声明一次并携带管线投影所需的全部信息interface ImageParamCatalogEntry { schema: z.ZodTypeAny // 值类型的单一来源 → 表单校验 ParamValues 类型 wire?: string // 厂商 wire 名称覆盖缺省时走自动 camelCase→snake_case } const IMAGE_PARAM_CATALOG { negativePrompt: { schema: optString }, // → negative_prompt (auto) numInferenceSteps: { schema: optInt }, // → num_inference_steps (auto) imageResolution: { schema: optString, wire: size }, // 不规则 → 显式声明 addWatermark: { schema: optBool, wire: watermark }, // … 覆盖全部 CanonicalParamKey缺失/多余键均为编译错误 } as const satisfies RecordCanonicalParamKey, ImageParamCatalogEntry type ParamValues { [K in CanonicalParamKey]?: ParamValueK } // 每个 schema 的 z.infer从源码实现看该文件还内置了两条强不变量穷尽性约束as const satisfies RecordCanonicalParamKey, …让缺失键和未知键都成为编译错误同时导出的IMAGE_PARAM_CATALOG_KEYS配合运行时测试锁定键集合与CANONICAL_PARAM_KEY的一致性。值类型规范化normalizeImageParamNumber只把「有限数字与数字字符串」规范化为数字布尔值与数组保持无效避免在提交时被静默转换成0/1之类的数字optNumber/optInt均通过z.preprocess接入。目录中已声明的 canonical 键覆盖了主流厂商图像模型所需negativePrompt、numInferenceSteps、guidanceScale、cfg、quality、seed、size、aspectRatio、imageResolution、addWatermark、outputFormat、outputCompression、background、moderation、style、styleType、personGeneration、safetyTolerance、promptEnhancement、promptExtend、refMode/refStrength参考图、upscaleFactor/resemblance/detail放大、DashScope 系列的sourceLang/targetLang/function/strength/isSketch、DMXAPI 的sequentialImageGeneration/maxImages等。从原子层投影出三样东西且永不漂移buildParamsSchema(support, mode)packages/provider-registry/src/utils/buildParamsSchema.ts——目录值 schema ⊗ 模型级supports约束enum 成员 / range 边界→ 校验某个模型表单袋子的 zod schema。实现要点是「目录负责类型强转SupportSpec以.refine追加约束」绝不从 spec 重建 zod那会丢失目录的强转能力每个字段.catch(undefined)且对象.loose()保证单个坏值/遗留值不会让整个提交失败迁移期软失败。ParamValues——目录的z.infer类型化的 canonical 袋子不存在手写的参数形状类型。wireName(key)——catalog.wire ?? autoSnakeCase(key)唯一的 canonical→wire 重命名。所有扁平请求体厂商的字段名都从这里派生没有任何厂商重复写negativePrompt → negative_prompt。原生参数numImages/size/seed/aspectRatio不走wireName——它们由AI_SDK_NATIVE_BINDINGS应用层见下文路由因为其目标是 AI SDK 调用选项而不是请求体字段名。注册表 schema模型级supports与路由来源是packages/provider-registry/src/schemas/model.ts的ImageGenerationSupportSchemainterface ImageGenerationSupport { modes: PartialRecordImageGenerationMode, ModeDef // generate | edit | remix | upscale | merge } interface ModeDef { supports: PartialRecordCanonicalParamKey, SupportSpec // 支持哪些参数 每模型约束 vendorTransport?: { endpoint: string; isSync?: boolean } // 异步 / 非 OpenAI 路由 requirePrompt?: boolean // 默认 trueqwen-mt-image、upscalers 为 false } type SupportSpec | { type: switch; default?: boolean } | { type: enum; options: string[]; default?: string; render?: select | chips; columns?: number } | { type: range; min: number; max: number; default?: number; step?: number } | { type: size; minSide: number; maxSide: number; pairedEnumKey?: string } | { type: text; multiline?: boolean }supports只携带每模型的约束支持哪些参数、options/range/default值类型与 wire 名称在目录中控件种类由表单层的imageGenerationToFields依据SupportSpec.type派生。此外ModeDef还支持maxInputImages整数、正数、可选用于限定该模式的输入图数量。从 schema 实现可看到vendorTransport.endpoint被约束为根相对路径/^\/(?!\/)/即/xxx而非完整 URL。模型块的解析遵循覆盖优先规则实现在ProviderRegistryService.getImageGenerationSupportsrc/main/data/services/ProviderRegistryService.tsregistryOverride.imageGeneration ?? presetModel.imageGeneration ?? null // null → 空表单基础条目 →packages/provider-registry/data/models.json厂商无关的官方契约厂商覆盖 →packages/provider-registry/data/provider-models.json以{ providerId, modelId }为键厂商口味参数 / 厂商独占 SKUid 规范化容忍带点号与净化后的 id。读半场注册表 目录 → 参数表单渲染进程的三个步骤拉取——useImageGenerationSupport(providerId, modelId)src/renderer/pages/paintings/hooks/useImageGenerationSupport.ts请求GET /providers/:providerId/models/:modelId*/image-generation-supportDataApi → 主进程同一个ProviderRegistryServiceSWR 缓存。映射——imageGenerationToFields(support, { mode })src/renderer/pages/paintings/form/imageGenerationToFields.ts遍历modes[mode].supports按spec.type分发到specToField——没有 per-vendor 分支SupportSpec.type控件switch开关toggleenumrender:chipschip 行size / aspectRatio / imageResolutionenum默认下拉选择框range滑块size自定义宽×高输入以pairedEnumKey custom为门槛text输入框 / 多行文本域multiline标签——KEY_LABELS同一文件将每个CanonicalParamKey映射到 i18n 标题/提示对键集合穷尽缺标签即编译错误另有OPTION_LABELS对枚举选项值做本地化如auto、quality的 low/medium/high、personGeneration的 DONT_ALLOW/ALLOW_ADULT/ALLOW_ALL、style的photography等选项值原样透传、仅本地化显示文案。表单编辑写入painting.params——一个扁平、以 canonical 键为 key 的袋子。默认值在模型被选中时由computeModelFieldResetsrc/renderer/pages/paintings/utils/computeModelFieldReset.ts提交。写半场paramValues→ 厂商请求1. 校验并收拢为一个 IPC 袋子canonicalGeneratesrc/renderer/pages/paintings/model/canonicalGenerate.ts用buildParamsSchema(support, mode)校验painting.params坏值软失败回退原始值、丢弃空白、把customSize_*组合为size然后通过 IPCai.image.generateschema 见src/shared/ipc/schemas/ai.ts发送一个 canonicalparamValues袋子 modemode是请求属性而非参数见 §5。IPC schema 把paramValues类型化为目录的imageParamsSchema——路由的safeParse产出严格、已强转的ParamValues非目录键被剥离。模型级 options/range 约束已在渲染进程的buildParamsSchema中执行过这里做的是值类型闸门。该文件还包含几个与表单强相关的守卫逻辑仅图片文件计入输入inputImages过滤mode在「有输入图 →edit否则 →generate」间自动推导编辑类模式必须携带输入图否则抛EDIT_IMAGE_REQUIREDmaxInputImages超限抛INPUT_IMAGE_LIMIT_EXCEEDED输入图被编码为data:URL 随 IPC 单独携带它们是文件而不是表单参数。2. 主进程分区splitParamValuesAI_SDK_NATIVE_BINDINGSsrc/main/ai/AiService.ts的generateImage调用splitParamValuessrc/main/ai/utils/imageOptions.ts后者依据AI_SDK_NATIVE_BINDINGSsrc/main/ai/utils/aiSdkNativeBindings.ts把袋子分成两半原生numImages→n、size、seed、aspectRatio归一化一次→structured类型化为ParamValues { n?: number }即 AI SDK 调用选项其余全部→vendorBagcanonical camelCase。空白 /null/undefined在此被丢弃字节一致 wire 守卫auto哨兵值保留到 wire 层再解析为「省略该字段」。AI_SDK_NATIVE_BINDINGS的完整定义源码确认export const AI_SDK_NATIVE_BINDINGS { numImages: { option: n }, // 唯一的重命名numImages → n size: { option: size }, seed: { option: seed }, aspectRatio: { option: aspectRatio, map: (v: unknown) normalizeAspectRatio(typeof v string ? v : undefined) } } as const satisfies PartialRecordCanonicalParamKey, NativeBinding其中normalizeAspectRatio将表单的ASPECT_X_Y枚举或已归一化的X:Y转为 AI SDK 图像选项与 Google/Imagen 接受的${number}:${number}形状幂等X:Y → X:Y空白/不匹配返回undefined从而省略该字段。真正属于 AI SDKImageModelV3CallOptions的只有n/size/aspectRatio/seed四个其余negativePrompt、numInferenceSteps、guidanceScale、quality、background、moderation、style、personGeneration…不是 SDK 的类型化选项其唯一通道是providerOptions即厂商请求体因此一律流经vendorBag→ WireProfile 引擎SDK 交付或 transportsjob 交付绝不进入本表。3. WireProfile 引擎SDK 交付对走 SDK 交付的提供商buildVendorProviderOptionssrc/main/ai/provider/custom/wire/buildImageRequest.ts先经wireName把 canonical 袋子映射为 wire 请求体再按该提供商在WIRE_REGISTRYsrc/main/ai/provider/custom/wire/wireProfile.ts中的注册方式打包interface WireProfile { fields: PartialRecordCanonicalParamKey, WireRule } // forward / map / contribute interface WireRegistration { profile: WireProfile dualOpenAI?: boolean // 在 openai 键下镜像干净请求体gpt-image 家族 passthrough?: boolean // 透传 profile 未命名的 vendor-bag 字段silicon cfg… also?: { key; profile }[] // 兄弟提供商键dmxapi → google.imageConfig }WireRule提供三种字段处理方式to?: string——显式 wire 字段名覆盖wireName(key)例如 Ollama 的numInferenceSteps: { to: steps }、MiniMax 的addWatermark: { to: aigc_watermark }map?: (value, all) JSONValue——值变换例如 Google 的personGeneration转小写ALLOW_ALL → allow_all因为ai-sdk/google的选项 schema 只接受小写contribute?: (value, all) Recordstring, JSONValue——一对多 / 嵌套逃生门例如 Google 的aspectRatio/size组装进imageConfig嵌套块aspectRatioImageConfigRule/imageResolutionImageConfigRule被 google、google-vertex 与 dmxapi 的 google 路由块共享。profile 声明哪些canonical 参数进入请求体名称来自wireName投递方式哪个键、是否透传、兄弟键、嵌套是 registration 的职责——不是 profile 的也绝无重复重命名。buildImageRequest的skipValue会丢弃undefined//null/auto与旧compact()保持字节一致mergeContribution对contribute()结果做嵌套深合并并剔除空叶保证未设置的aspectRatio不会留下imageConfig.aspectRatio。未出现在WIRE_REGISTRY的提供商回退到DEFAULT_DIFFUSION_REGISTRATIONOpenAI 兼容 diffusion 家族passthrough: true。最终产出providerOptions[id]AI SDK 图像模型将其展开进请求体structured则成为类型化调用选项imageParams。SDK 图像模型为以下之一自定义ImageModelV3如src/main/ai/provider/custom/silicon/SiliconImageModel.ts、src/main/ai/provider/custom/aihubmix/aihubmixImageModel.ts、ai-sdk/openai-compatible或ai-sdk/google。它读取wire 请求体——不会二次重命名。WIRE_REGISTRY源码中已确认的注册条目节选provider idprofile投递特性openai/openai-chat/azure/azure-responses/huggingface/newapiOPENAI_WIRE_PROFILEquality/background/moderation/styledualOpenAIcherryin/cherryin-chatOPENAI_WIRE_PROFILEdualOpenAIpassthroughcherryin-chat另以key: cherryin交付因为 wrapper 读取固定键providerOptions[cherryin]googleGOOGLE_WIRE_PROFILE默认键google-vertexGOOGLE_WIRE_PROFILEkey: vertexSDK 读取providerOptions.vertexdashscopeDASHSCOPE_WIRE_PROFILEpassthrough透传modelDescriptor/sourceLang/targetLang等给 transportdoubaoDOUBAO_WIRE_PROFILEkey: bytedancepassthroughai-sdk/bytedance的选项 schema 是 camelCase自行完成厂商命名auto对 Ark 是启用组图的真值因此必须透传保活aihubmixAIHUBMIX_WIRE_PROFILEOpenAI body seeddualOpenAIpassthroughopenai 镜像保持干净厂商键下挂完整袋子dmxapiDMXAPI_WIRE_PROFILEalso: [{ key: google, profile: DMXAPI_GOOGLE_PROFILE }]多后端网关向 google 适配器投递imageConfig块ollamaOLLAMA_WIRE_PROFILE默认键minimaxMINIMAX_WIRE_PROFILE默认键openrouterOPENROUTER_WIRE_PROFILE含outputCompression的contribute仅当outputFormat为 jpeg/webp 时输出output_compression默认键未列出DEFAULT_DIFFUSION_REGISTRATIONpassthrough4. Transport 投递异步 / 定制 wire 形态当resolveImageTransport(provider, model, settings)src/main/ai/provider/custom/imageTransportRegistry.ts返回 transportDashScope / PPIO / ModelScope / OVMS / DMXAPI 定制家族时请求改走任务系统generateImageViaJob→JobManager→imageGenerationJobHandlersrc/main/ai/provider/custom/tasks/imageGenerationJobHandler.ts由 handler 独占 submit/poll 循环、排队与取消。该 job刻意不重启持久化recovery: abandon其唯一消费者是generateImageViaJob中的进程内 awaiterhandle.finishedpayload 未记录消费者身份重启后恢复的任务无人接收结果非终止态 job 在启动时被取消而非恢复。handler 还设置了defaultConcurrency: 2、defaultRetryPolicy: { maxAttempts: 1 }transport 内部已重试瞬时轮询错误job 级重试会导致重复提交并烧掉用户配额、defaultTimeoutMs: 30 * 60_000密钥永不持久化每次执行都通过resolveProviderAiSdkConfig重读 apiKey输入图按 FileEntry id 引用、从 FileManager 读回保证 payload 低于 1MB job 上限。与 SDK 路径其袋子就是请求体不同transport 构建自己的per-model 信封因此它直接接收 canonical camelCase 参数——原生n/size/seed走类型化的ImageGenerationSubmitInput.{n,size,seed}其余经providerParams即vendorBag。没有 wire 命名、没有大小写探测每个 transport 直接读params.negativePrompt、params.promptExtend… 放入自己的结构input.*/parameters.*/messages[]。契约见src/main/ai/provider/custom/imageGenerationModel.ts的ImageGenerationTransportsubmit/poll/cancel与各vendor/vendorTransport.tscreateImageGenerationModel将 transport 包成ImageModelV3maxImagesPerCall: 1doGenerate执行 submit→可选 poll→返回 URL图片 URL 由打过补丁的aiSDK 自动下载为GeneratedFile。5. 路由——modelDescriptor主进程派生transport 依据modelDescriptor { id, endpoint, isSync, mode }路由POST 到哪个端点、是否轮询、用哪个响应族解析器。这是后端路由数据在路由发生处派生AiService持有解析后的(providerId, modelId, mode)调用providerRegistryService.getImageGenerationSupport(...)→modes[mode].vendorTransport构建 descriptor并以类型化字段挂在 job payload /ImageGenerationSubmitInput.modelDescriptor上——绝不混入参数袋子。注册表是vendorTransport的来源且主进程本就托管它渲染进程的 support 拉取只是到同一服务的 IPC 往返所以 descriptor 是纯派生值而非参数。扩展配方给模型加一个参数选取或复用canonical 键。若是新键在IMAGE_PARAM_CATALOG增加一行{ schema, wire? }——仅当厂商名称不是自动 snake_case 形式时才设置wire再补一行KEY_LABELS并按 i18n 工作流完成各语言环境与校验步骤。在模型的supports中以正确的SupportSpecoptions/range/default声明它。对扁平请求体厂商到此为止——表单、校验、类型、wire 名称全部从目录行流出。只有当参数需要定制摆放嵌套块、兄弟厂商键、transport 信封时才需要加WireProfile字段 / transport 行。加一个模型厂商无关的官方模型 → 在models.json写imageGeneration块厂商口味 / 独占 → 在provider-models.json写{ providerId, modelId, imageGeneration }覆盖异步 / 非 OpenAI wire 形态 → 加vendorTransport.endpointisSync并确保对应厂商 transport 认识该模型族。加一个厂商OpenAI 兼容 → 无需定制DEFAULT_DIFFUSION_REGISTRATION引擎 ai-sdk/openai-compatible直接覆盖原生 SDKOpenAI/Google→ 以正确的投递标记dualOpenAI/also/passthrough注册一个WireProfile定制 / 异步 wire 形态 → 实现ImageGenerationTransport在提供商的imageModel(...)上注册并读取 canonical camelCase 参数 input.modelDescriptor。关键文件索引关注点文件参数目录值 wirepackages/provider-registry/src/schemas/imageParamCatalog.ts每模型校验 schemapackages/provider-registry/src/utils/buildParamsSchema.ts注册表 schemasupports/vendorTransportpackages/provider-registry/src/schemas/model.ts基础 / 覆盖模型数据packages/provider-registry/data/models.json、packages/provider-registry/data/provider-models.json解析器override ?? basesrc/main/data/services/ProviderRegistryService.tsSupport 拉取 hooksrc/renderer/pages/paintings/hooks/useImageGenerationSupport.ts注册表 → 表单字段 KEY_LABELSsrc/renderer/pages/paintings/form/imageGenerationToFields.ts切换模型时的默认值填充src/renderer/pages/paintings/utils/computeModelFieldReset.ts校验 构建 IPCparamValues袋子src/renderer/pages/paintings/model/canonicalGenerate.tsTransport 路由提示→ 后端见 §5src/renderer/pages/paintings/model/paintingPipeline.tsIPC payload schemasrc/shared/ipc/schemas/ai.ts主进程入口 原生分区 job 分发src/main/ai/AiService.tssplitParamValuesnative vs vendorBagsrc/main/ai/utils/imageOptions.tsAI-SDK 原生绑定表src/main/ai/utils/aiSdkNativeBindings.tsWireProfile 引擎 投递注册表src/main/ai/provider/custom/wire/buildImageRequest.ts、src/main/ai/provider/custom/wire/wireProfile.ts自定义 transport 契约src/main/ai/provider/custom/imageGenerationModel.ts异步任务 handlersrc/main/ai/provider/custom/tasks/imageGenerationJobHandler.ts共享 transport 工具src/main/ai/provider/custom/transportUtils.ts小结Cherry Studio 的图像生成参数系统把「表单渲染」「值校验」「请求体组装」「静态类型」全部收敛到两个声明式事实之上参数目录canonical 键的值类型与 wire 名称与注册表数据每模型的supports与每模式的vendorTransport。canonicalparamValues袋子贯穿渲染进程与主进程只在最后分叉为WireProfileSDK 交付与ImageGenerationTransport异步 job 交付两条适配路径。任何一层都看不到逐厂商手写的 UI 分支或重复的字段重命名——这正是「新增图像模型等于一次数据变更」这一设计目标的落地形态。赞分享人工智能大模型AI 应用交互助手本地部署【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址https://gitcode.com/CherryHQ/cherry-studio点击查看免费下载相关推荐Cherry Studio 图像生成参数化架构从注册表驱动表单到厂商 Wire 请求的完整数据链路Cherry Studio 图像生成参数化架构从注册表驱动表单到厂商 Wire 请求的完整数据链路 导读 本文深入解析 Cherry Studio 中绘画AI 应用大模型桌面应用本地部署RAGCherry Studio 文件树架构解析从视图注册、数据模型到虚拟化渲染的完整实现指南Cherry Studio 文件树架构解析从视图注册、数据模型到虚拟化渲染的完整实现指南 导读 本文以 CherryHQ/cherry studio 仓库中的人工智能大模型AI 应用交互助手本地部署Cherry Studio 参数流水线Params Pipeline深度解析从请求元组到 Agent.stream() 的组装全流程Cherry Studio 参数流水线Params Pipeline深度解析从请求元组到 Agent.stream 的组装全流程 导读 Cherry StAI 应用大模型桌面应用本地部署RAG创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表