Kun 扩展开发指南：模型 Provider、账号与认证体系的完整实现-北京尧图网络

人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载本文基于 docs/extensions/providers-and-accounts.en.md 展开并结合 Kun 仓库的 Extension API 源码、示例扩展与测试验证。适合希望为 Kun 接入自有模型服务的扩展开发者阅读你将掌握如何在 Manifest 中声明模型 Provider 与认证方式、如何实现 Provider Adapter 与流式协议、如何管理账号生命周期与凭据安全以及如何让扩展在 GUI 与 headlesskun serve环境下行为一致。Kun 允许一个扩展实现完整的自定义模型传输层custom model transport而无需创建新的 Agent runtime。Kun 会把一次模型请求归一化通过RemoteModelClient路由到扩展的 Node Host再把校验过的规范化 stream 写回既有的 AgentLoop、工具与用量路径。这意味着扩展侧只需聚焦「如何与上游模型服务对话」会话调度、工具执行、权限审批与用量记账都由 Kun 核心接管。三个独立概念Provider Definition、Account 与 Provider BindingKun 把模型接入拆分为三个互不混淆的记录这是整个体系的基石记录描述是否包含秘密Provider Definition传输方式、模型/能力、认证方式、拥有者否Account用户在该 Provider 下的一个命名账号、认证类型、状态、credential reference否秘密存放在 Credential StoreProvider Binding一次 thread/profile/role 使用的 provider account model否Binding 必须自洽coherentProvider A 不能绑定 Provider B 拥有的 account/model。当账号缺失时系统返回account-required绝不会自动选择另一个账号。这一约束在源码层被强制实现——kun/src/services/extension-provider-account-store.ts中的validateBinding会在 probe、listModels、stream 之前逐一校验 provider/account/model 的归属任何不匹配都会抛出 opaque 错误opaqueProviderError/opaqueAccountError参见 kun/src/services/extension-provider-account-store.ts。权限模型与入口约束扩展声明 Provider、读取账号、发起认证流程都需要显式权限manifestpermissions字段Provider 贡献必须声明 Nodemain并持有providers.register权限查看脱敏后的账号元数据需要accounts.read使用某个账号发起请求需要accounts.use:providerId请求创建/更新/删除账号流程需要accounts.manage:providerId若自定义签名确实需要读取原始秘密材料需要accounts.secrets.read:providerId——仅 Node 端可用且需单独的高风险确认见下文「Authenticated Fetch 与 Secret Read」由 Broker 代发的上游请求还需要network:hostname。一个关键设计约束模型 Provider、认证 handler 和动态模型发现必须在没有 browser/Webview 内容的环境下也能运行。browser永远不是 headless 回退方案这保证了扩展 Provider 在 GUI 关闭时仍可被kun serve、定时任务或 CLI 使用。在 Manifest 中声明 Provider下面是最小可用的 Manifest 示例完整继承自原文档。它声明了一个模型 Provideracme-models关联一个 API Key 认证源acme-auth{ main: dist/extension.js, activationEvents: [ onProvider:acme-models, onAuthentication:acme-auth ], contributes: { modelProviders: [ { id: acme-models, displayName: Acme Models, authenticationProviderId: acme-auth, credentialHosts: [api.acme.example], models: [ { id: reasoning-small, displayName: Reasoning Small, capabilities: { input: [text], output: [text], reasoning: true, tools: true, parallelTools: true, streaming: true } } ] } ], authentication: [ { id: acme-auth, displayName: Acme Account, type: api-key, apiKey: { header: Authorization, prefix: Bearer } } ] }, permissions: [ providers.register, accounts.read, accounts.use:acme-models, accounts.manage:acme-models, network:api.acme.example ] }精确的 capability/auth 元数据以 Manifest Schema 为准packages/extension-api/schema/kun-extension.schema.json。结合源码 packages/extension-api/src/providers.ts 与 packages/extension-api/src/accounts.tsSchema 约束要点包括Providerid必须匹配^[a-z][a-z0-9-]*$164 字符displayName最长 128 字符credentialHosts支持*.domain通配前缀最多 64 项models数组最多 512 个模型每个模型的capabilities中input/output支持text、image、audio、video、file五种 modality另含reasoning、tools、parallelTools、streaming布尔能力以及可选的maxContextTokens、maxOutputTokens认证声明按类型做必填校验oauth2-pkce必须提供clientId、redirectUri、authorizationUrl、tokenUrldevice-code必须提供clientId、deviceAuthorizationUrl、tokenUrlAPI Key 认证默认注入Authorization: Bearer key可自定义header与prefix。命名空间规则Provider 与模型 ID 必须稳定注册时与扩展身份合成 namespaced identity源码中通过extensionProviderId(extensionId, id)实现见 kun/src/adapters/model/extension-model-provider.ts。扩展 Provider 不能占用 built-in 或其它扩展的 ID。注册时序上认证 Provider 必须先于模型 Provider 注册——register()会先检查对应 authentication provider 是否已存在且 owner 匹配否则直接抛错见 kun/src/adapters/model/extension-model-provider.ts。credentialHosts 与网络安全边界credentialHosts是「允许附加认证材料的接收方」的独立白名单一个宽泛的network:*权限并不能替代它。authenticatedFetch要求目标 URL 同时匹配network:hostname授权与当前 Provider 的credentialHosts。其它安全策略远程目标必须使用 HTTPS只有显式声明的 loopback 目标允许 HTTP且每个解析出的地址都必须仍是 loopback重定向由 Broker 以 manual 模式逐跳返回每一跳都重新检查并剥离响应中的 credential/cookie header生产 transport 会解析全部地址拒绝任何 special-use 或 mixed DNS 应答并把获准地址 pin 到实际连接Kun 发起的 OAuth device、token exchange 与 refresh 请求使用同一套策略测试可以注入 fake fetch但它不代表生产环境的 SSRF/DNS-rebinding 防护水平。静态与动态模型目录Kun 会把 Manifest 中的静态模型与 Adapter 的listModels(binding)动态结果合并成一个Provider-owned catalog。动态条目不能逃出 Provider 命名空间无效/重复模型会被确定性拒绝或去重。如果动态发现失败合法的静态模型仍然保留但永远不会借用另一个 Provider 的模型。相关实现可参考mergedProviderModels与诊断记录逻辑kun/src/adapters/model/extension-model-provider.ts。Provider Adapter 生命周期一个 Provider adapter 需要实现五个方法接口定义见 packages/extension-api/src/providers.ts方法职责说明probe(binding, context)验证连接/账号返回规范化成功或 Provider error不启动 Agent turn返回{ ok, latencyMs?, message?, details? }listModels(binding, context)返回动态模型返回ProviderModel[]与静态模型合并stream(request, context)处理完整规范化请求以AsyncIterable形式 yield 有序事件cancel(requestId)取消指定请求按 requestId 取消可与stream并发执行countTokens(request)可选精确 token 计数缺失时由 Kun 核心估算不算 adapter 失败注册方式是通过context.modelProviders.registerProvider(declaration, adapter)完成把返回的Disposable加入context.subscriptions。当扩展被禁用、Host 退出或 disposal 时Kun 会 cancel/fail 所有在途请求并释放 correlation state——源码中disposeRegistration会 abort 所有 active request 并尽力调用 adapter 的cancel见 kun/src/adapters/model/extension-model-provider.ts。仓库自带的示例扩展 examples/extensions/streaming-model-provider/src/extension.ts 演示了一个完整的DemoStreamingAdapterprobe通过listAccounts检查账号是否connectedstream逐段 yieldtextDelta检查取消标志后 yieldusage与completed并实现cancel与countTokens。其 Manifestexamples/extensions/streaming-model-provider/kun-extension.json同时声明了 API Key 与 OAuth PKCE 两种认证源和两个 Providerecho-api-key、echo-oauth是「一次认证、双 Provider」的参考样板。规范化请求Normalized RequestProvider 收到的是一个**公开、版本化public versioned**的对象ModelProviderRequestSchema见 packages/extension-api/src/providers.ts包含opaque request ID生效的 provider/account/modelbindingsystem/mode 指令instructions稳定前缀与模型可见的 history itemsmessages含system/developer/user/assistant/tool五种角色text/image/audio/video/file 等模型支持的附件表示已广告的工具 schemastools含name、description、inputSchemareasoning/sampling/生成控制generationtemperature(0~2)、topP(0~1)、maxOutputTokens、stop(≤16 项)、reasoningEffort(low/medium/high)、toolChoice一个account handle默认不是原始凭据。请求对象不包含Kun 内部 class、TurnItem对象身份、runtime token、文件系统凭据或 JavaScriptAbortSignal。取消是对同一 request ID 的独立操作调用cancel(requestId)。如果选中模型没有声明某 input modality、tool mode 或 generation control请求会在发送到 transport 之前以 capability error 拒绝assertModelRequestCapabilities。流事件协议与规则v1 协议只接受七种有序、版本化事件textDeltareasoningDeltatoolCallDeltatoolCallCompleteusagecompletederror协议规则每条都可在 kun/src/adapters/model/extension-model-provider.ts 的 stream 校验循环中找到对应实现每个请求的sequence必须从 0 开始单调递增Host/Kun 按序严格校验跳号即报错分片工具调用toolCallDelta按callId独立组装并行调用保留 first-seen 顺序完整工具参数必须满足对应工具 Schema才能写入 history每个请求最多一个 terminal 事件completed或error成功的completed必须在此之前或与之同时提供至少一个已知usage字段缺失/空 usage 是 protocol error。独立的usage事件与completed内联 usage 只按最后一个累计快照记账一次源码中lastUsage的覆盖逻辑即为此设计未知字段不编造reasoning/cache-write token 与任意三字母币种costcurrency必须成对出现的成本会保留未知事件、错误顺序、超限 payload/事件数、第二个 terminal 或畸形调用会终止协议且不提交无效的 assistant/tool historyterminal/cancel 之后到达的事件一律丢弃。一个最小 stream 示意完整继承自原文档async function* stream(request) { yield { type: textDelta, requestId: request.requestId, sequence: 0, delta: Hello } yield { type: usage, requestId: request.requestId, sequence: 1, usage: { inputTokens: 12, outputTokens: 1 } } yield { type: completed, requestId: request.requestId, sequence: 2, finishReason: stop } }finishReason的合法值为stop、length、tool_calls、content_filter、othererror事件带code、message、retryable与可选details。事件字段的精确约束以同版本 SDK 类型为准不要手工拼装。组装与提交细节Kun 按callId组装并行toolCallDelta分片并依 first-seen 顺序提交最终参数必须是 JSON object、匹配已广告工具及其 input Schema分片与显式toolCallComplete不一致时fail closed。成功 terminal 只有在确认没有 late/duplicate 事件之后才会提交。持续有 RPC stream event 的长请求会刷新 idle watchdog——健康的长请求不受固定 60 秒总时限约束只有超过 idle limit 仍无活动才超时。异步迭代要求async-iterator 的消费/ack 必须遵守 backpressure绝不要把无界上游流整体缓存后再处理。取消、超时与背压用户中断或模型超时后Kun 会调用cancel(requestId)停止向 UI/Agent history 投影晚到事件并在 cancellation grace 后释放状态。Adapter 应当同时中止上游 HTTP 请求、读取循环与计时器——示例扩展中cancel()把 requestId 记入#cancelled集合stream循环每次迭代检查该集合实现协作式取消。默认 Host stream 窗口为 32 个未确认事件或 4 MiB以先到达者为准平台 policy 可以收紧。消费者落后时应当暂停上游读取而不是继续堆积。超过 queue、payload 或 idle 限制时以 Provider protocol/limit error 失败且只影响该扩展本身不会波及其它 Provider 或 built-in 模型。用量与工具调用只报告上游确实返回的 usage。Kun 把可用字段归一化进主用量/记账路径并保留 Provider/model/account/run 归属attribution。估算值不能冒充 Provider 原生的 cache hit/miss 或 cost——要么标记为 estimate要么省略工具调用分片必须携带稳定的 call ID。并行调用的分片可以交错但不同调用的 name/arguments 绝不能混在一起Provider 只负责生成tool call真正的执行仍会经过 Kun ToolHost、pinned catalog、权限、审批、预算与取消机制。绝不静默回退Never Silently Fall Back当显式 Binding 的 Provider、account 或 model 出现以下任一情况时Kun在不把对话发送给其它 transport 的前提下直接失败unknown / uninstalled / disabled / incompatiblecircuit-open熔断开启或 Host 崩溃账号 missing / expired / interaction-required模型属于另一个 Providercapability 不足stream/protocol 失败。Kun 不会切换到默认 Provider、另一个账号、或另一个 Provider 的同名模型。正确做法是修复 Binding 或恢复原 Provider然后由用户/调用者显式重试。示例扩展的stream中对MODEL_NOT_FOUND与ACCOUNT_UNAVAILABLE直接 yield error正是这一原则的体现。数据披露与脱敏日志扩展 Provider 会收到完整的模型可见请求对话历史、system/mode 指令、附件与工具 schemas。安装权限确认与首次选择 Provider 时Kun 会展示 Provider owner 与数据类别如果新版本扩展了权限或输入能力扩展将保持禁用直到用户重新确认。Adapter 的错误/日志默认只能保留extension、Provider、model、account ID、request ID、operation、规范化 category、retryability 与脱敏摘要。禁止记录完整 prompt、附件 body、authorization header、原始 adapter error payload 或 secret。Kun 会把常见的 authentication、authorization、rate-limit、invalid-request、unavailable、adapter-failure 映射为固定错误码原始code/message/details不进入 history 或持久化诊断。源码中ExtensionModelProviderDiagnostic的category枚举authentication/authorization/rate_limit/invalid_request/unavailable/adapter_failure/protocol即对应这一规范化模型见 kun/src/adapters/model/extension-model-provider.ts。用户选择与持久化 BindingExtension Center 中的Provider 账号卡片是核心拥有的选择入口。流程为用户连接账号 → 选择该账号实际可用的模型 → 点击「审阅并保存绑定」。Kun 会在 Main-owned protected window 中展示扩展 owner、精确扩展版本、Provider、模型、opaque account reference以及 Provider 可能收到的四类数据完整对话历史、system/mode 指令、附件、工具 schemas。确认之前不持久化任何内容、不发送任何模型内容。确认后Kun 原子写入一条记录到extensions/provider-bindings.json存储路径定义见 kun/src/services/extension-provider-account-store.tsproviderId accountId modelId ownerExtensionId ownerExtensionVersion dataAccessDigest账号字段只是 opaque reference——API key、access/refresh token、OAuth code、授权 header永远不会进入 Binding。Binding 默认按当前 workspace 隔离未选择 workspace 时写入 global scope。Binding 出现在 Kun 模型选择器中的前提全部满足扩展仍是用户确认过的同一版本并在该 workspace 中 enabled/trustedproviders.register、accounts.read、accounts.use:providerId权限仍然有效Provider Host 已注册且账号状态为connected选中模型仍属于该 Provider由当前权限与模型能力计算出的 disclosure digest 与用户确认一致。版本、权限或输入能力的变化会使旧确认失效、要求重新审阅账号删除、Provider disable/crash、模型移除或 workspace grant 撤销都会让 Binding显式 unavailable——Kun 绝不将其修复成默认 Provider、另一个账号或同名模型。主聊天在创建 thread/turn 时携带该 opaque account reference扩展 Agent profile 声明相同 Provider/model 但省略 account 时Kun 会在相同 workspace scope 解析用户已批准的账号没有有效 Binding 时在创建 Agent run 之前返回account-required而不是回退。模型选择器不会把扩展 Provider 写入旧的 built-in Provider 凭据设置只读取上述核心 Binding因此 GUI 重启、headlesskun serve与扩展 Agent 遵循同一套 provider/account/model 所有权规则。账号状态与列表一个 Provider 可以有多个命名账号。公开账号对象只包含AccountSchema见 packages/extension-api/src/accounts.ts稳定的 account ID/referenceProvider ID用户 label认证类型api-key/oauth2-pkce/device-code/custom状态connected、expired、interaction-required、error或unavailable安全的非秘密 metadata以及protection状态system/encrypted-fallback/unavailable。重命名 label 不会改变 reference 或既有 Binding列表永不包含 API key、access/refresh token、client secret、cookie 或 credential blob。账号的公开状态还可映射为 Provider 健康状态available/degraded/unavailable/interaction-requiredProviderStatusSchema。账号创建与三种认证流程扩展可以请求账号流程但凭据只在Host-owned 的受保护界面protected surface收集——该界面不加载扩展的 Webview/content script。成功后扩展只得到一个 account reference。公开的context.authenticationAPI 提供listAccounts、createSession、getSession、cancelSession、deleteAccount、authenticatedFetch与高风险的revealSecret。账号流程使用 session ID 轮询/订阅五种状态pending、completed、cancelled、expired、failed。约束包括Webview不能直接提交原始凭据Node Host 的 session 结果不会取得 authorization URL、device user code 或 protected-form 内容pending会话返回可操作的引导说明由 Kun 自己的账号管理界面继续只有 Main-owned protected surface 能拿到并显示短期交互材料用户可在 Extension Center 的受保护账号管理中重命名账号、原子替换 API key 或删除账号重命名与换 key 都保留稳定 account ID 与既有 Binding扩展 SDK 从不接收新 key每次受保护操作都会绑定 extension/provider/account/operation digest 并写入不含秘密的审计记录。API Key用户在受保护表单中输入 key → Kun 存入 Credential Store普通设置中只写 reference → Provider 可用该 account reference 执行脱敏 probe。替换 key 时原子更新 credential、保持 account ID、清除旧内存副本。probe 失败不得把 key 写入日志、state 或事件。OAuth 2.0 Authorization Code PKCEAccount Broker 生成并验证 state/PKCEcallback 只匹配发起交易的 transaction。缺失、过期、重放或不匹配的 callback 一律拒绝且不保存 secret。Code exchange 与 access/refresh token 的存储都在核心完成用户取消返回cancelled不创建账号。示例扩展 examples/extensions/streaming-model-provider/kun-extension.json 展示了完整的 OAuth 声明clientId、redirectUrikun-extension://协议、authorizationUrl、tokenUrl、scopes。Device Authorization受保护界面显示 verification URL 与 user codeBroker 遵守 Provider 的 interval、slow-down 与 expiry保持一个有界 transaction支持取消。成功后清除 transient code 并存储凭据过期/取消不创建账号。Token 刷新与 Credential Store同一账号的并发 refresh 会合并为一次并原子替换 token。refresh token 被拒绝时账号变为interaction-required/expired依赖请求显式失败、不切换账号。若上游 refresh 成功但安全持久化失败Kunfail closed不提交部分 token 状态。Credential Store 优先使用操作系统凭据设施不可用时只允许「已认证的加密回退authenticated encrypted fallback」并向用户暴露非秘密的 degraded-protection 状态。两者都不可用时拒绝保存新 secret——不存在 plaintext-at-rest 回退。普通 settings、thread、extension state、IPC 与 logs 中只能出现 opaque reference。受代理的 authenticatedFetch 与高危 Secret Read优先使用 Broker 代发的认证请求authenticatedFetch五步流程扩展提供获准的 account handle 与允许的 URL/requestBroker 校验 extension/provider/account/network scope必要时执行 refreshBroker 注入认证返回剥离 credential header 的有界响应。扩展自行提供的冲突Authorization/credential 字段会被移除或拒绝绝不与已存储凭据合并。每个手动 redirect hop 与每次 token/refresh 请求都会重新执行 DNS/address policy——先前的 hostname 校验结果不能被复用来连接新解析出的地址。该策略只覆盖 Broker 发起的直接连接不约束 Node adapter 自己fetch/socket 的行为也不声称能阻止一个合法公网服务在应用层代转请求。只有 Node adapter 因自定义签名确实需要原始秘密时才申请accounts.secrets.read:providerId请求体仅含accountId与operation。每次成功/拒绝都产生脱敏审计Webview/content script 永远不能读取秘密secret 只在最小 operation scope 内使用不缓存、不记录、不回传 UI。隔离、删除与缺失 ProviderBroker 从 Host channel 推导调用者身份强制执行 Provider ownership 与 account scope。一个扩展不能枚举或使用另一个扩展的 private Provider 账号除非核心明确提供 shared-provider permission。Provider 扩展被 disable/uninstall 后相关 account 与 binding 变为unavailable秘密不会被自动删除thread/profile 的 binding 保留用于恢复/诊断Kun 不会改绑其它 Provider。用户显式删除账号时Kun 删除 credential、invalidates sessions并把依赖项置为account-required删除确认前应展示受影响的 Bindings。Headless 运行有效的已存储账号可在 GUI 关闭时由kun serve、定时任务或 CLI 使用/刷新。需要 login、consent 或 secret-unlock 交互时返回稳定的interaction-required与可操作的 continuation既不会挂起也不会隐式打开 renderer。这让扩展 Provider 天然支持无人值守的自动化场景。旧凭据迁移Legacy Credential MigrationGUI 首次读取旧版kun-settings.json或兼容的旧文件名时会为每个 Provider profile 与 Kun runtime override 建立独立的稳定 source ID然后按固定顺序迁移在设置文件旁创建权限收紧的一次性回滚备份*.pre-extension-credential-migration.json先把secret 写入受保护的 Credential Store创建或复用kun.core账号并在provider-bindings.json写入providerId accountId modelId在legacy-credential-migrations.json写入仅含 salted digest、opaque reference 与secure-committedphase 的恢复记录原子重写普通 settings从 Provider profile/runtime override 中移除明文GUI 管理的 Kunconfig.json也只写credentialSourceId绝不写入 key 或 credential-derived headersettings 落盘成功后把恢复记录推进到settings-committed下一次启动按 account reference 从安全存储解析请求凭据。细节语义均有测试覆盖见 kun/src/services/legacy-provider-credential-migration.test.ts同一 Provider 的相同 legacy secret 复用一个账号不同 secret如 Provider profile 与 runtime override 不同保留为不同账号与 BindingProvider 暂时缺失时账号与 Binding 保持unavailableProvider 恢复后重新解析不删除、不改绑迁移完成后从旧备份重新引入的明文不能覆盖安全存储中更新的 credential受保护流程替换 key 时保留稳定 account ID普通 settings 写入失败时回滚本次 pending 更新原文件保持权威可读且不写 completed marker进程在安全提交后中断 → 下次启动按 phase 重试或回滚进程在 settings 原子写后、marker 完成前中断 → 从已存在的安全 account/binding 完成 markermarkers、account records、Bindings 与 logs 永不包含 secret。为兼容现有同步核心 Provider 调用本 release cycle 的 Electron Main 进程会把账号凭据临时投影到内存中的 legacy settings shape——该投影不会写回普通文件也不是 Extension API扩展始终只能看到 account reference 与脱敏元数据。下一个不再支持该 legacy shape 的 major 版本会移除这条兼容读路径详见状态与兼容迁移与权限与秘密。官方测试清单与验证建议原文档给出了覆盖全流程的测试清单扩展作者可对照自测对应测试文件可参考 kun/tests 与 kun/src/services/extension-host-broker.accounts.test.ts 等probe / listModels / 静态动态 catalog 合并text / reasoning / 并行分片 tool call / usage / terminal 全事件路径错误顺序 / 超限 payload / 超时 / 背压 / 取消与 late eventHost crash / circuit 与显式 no-fallback多模态能力拒绝capability rejection多账号、重命名 / 删除 / 缺失 BindingAPI-key 拒绝、PKCE state/replay、device interval/expiry/cancel并发 refresh 与 secure-store 失败fail closedauthenticated-fetch 的 header 处理与 secret-read 审计/脱敏headless 成功与interaction-required迁移幂等性、回滚备份与 unavailable Provider 保留。小结Kun 的 Provider/Account/Binding 三层模型把「模型传输」从 Agent 运行时中彻底解耦扩展只需在 Manifest 中声明 Provider 与认证、实现五个方法的 Adapter、按七事件流协议 yield 规范化事件即可获得与 built-in Provider 同等的路由、用量、工具执行、权限审批与安全边界。对扩展作者而言最重要的三条纪律是Binding 必须自洽、绝不静默回退、秘密永不进入扩展可见的任何普通状态——这既是协议约束也是源码中每一处校验与脱敏逻辑共同保障的安全基线。赞分享人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载相关推荐在 Kun 中实现自定义模型 Provider账号、认证与持久 Binding 完整指南在 Kun 中实现自定义模型 Provider账号、认证与持久 Binding 完整指南本指南基于 docs/extensions/providers an人工智能AI Agent自主智能体桌面应用MCP ClientsKun 扩展模型 Provider 深度解析让第三方扩展注册完整模型传输层的设计规范与实现Kun 扩展模型 Provider 深度解析让第三方扩展注册完整模型传输层的设计规范与实现本文基于 Kun 扩展平台的设计规格文档 extension mo人工智能AI Agent自主智能体桌面应用MCP ClientsKun 扩展平台的账户与机密体系Provider/Account/Binding 三记录分离、Account Broker 与受保护凭证存储的实现解析Kun 扩展平台的账户与机密体系Provider/Account/Binding 三记录分离、Account Broker 与受保护凭证存储的实现解析本文以人工智能AI Agent自主智能体桌面应用MCP Clients上一篇OpenMAIC 幻灯片视频元素生成规范VideoElement 字段详解与 mediaRef 引用机制下一篇OpenCV终极指南如何快速上手这个全球最火的开源计算机视觉库创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Kun 扩展开发指南：模型 Provider、账号与认证体系的完整实现

相关推荐

codeforces-go 仓库题解精讲：LeetCode 2140「解决智力问题」的两种一维 DP 递推写法（查表法与刷表法）

总结 10.09

C语言核心知识点全解析

更多资讯

AI论文写作工具深度测评：从大纲生成到智能降重的完整实战记录

自建埋点分析系统成本揭秘：自研、开源ClkLog与商业产品怎么选？

Java面向对象实战：智能家居控制系统如何设计才能优雅可扩展

双有源桥DAB扩展移相控制（EPS）原理与电压闭环实现

Claude长期记忆解决方案：用向量数据库构建外部记忆层

Spring生态修炼指南：从IoC/AOP到微服务与AI集成

今日更新

再见，SSE！你好，Streamable HTTP！轻松开发 Streamable HTTP MCP Server 并接入 TaoToken

工业软件标准化路线图：国产替代的落地施工图

VCMI安卓版实操指南：原生运行英雄无敌3的3步技术落地

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？