BYOK 设计工作流:用你自己的密钥运行 Claude、Codex 或 Qwen
大多数 AI 设计工具都会在你花掉的每一个 token 上悄悄加一道差价。Open Design 的立场恰恰相反——自带模型密钥,直接向服务商付费,并完全掌控推理在哪里运行。下面讲讲 BYOK 这一层到底是怎么工作的。
如果你在 2026 年用过托管式 AI 设计产品,多半已经注意到账单在悄悄往上走。一层订阅费,叠加按席位的收费,再叠加一道没人公开的推理加价。这笔账故意算不清楚。
Open Design 不运行推理。我们在 token 上没有差价。整个工作流都是围绕 自带密钥(BYOK) 构建的——你把 daemon 指向任意一个兼容 OpenAI 的端点,粘贴你自己的 API 密钥,就完成了。
这篇文章会解释我们为什么做出这个选择、它在底层是怎么工作的,以及它在日常工作流中究竟改变了什么。如果你想了解背后更宏观的理念论证,我们为什么把 Open Design 构建成一个 skill 层、而不是一款产品 是配套的姊妹篇——这一篇则是上手实操版。
这里说的「BYOK」到底是什么意思
在 AI 工具领域,「BYOK」其实有两种定义,它们并不是一回事:
- 表面 BYOK——工具允许你粘贴一个密钥,但推理仍然经过它们的服务器,会记录你的 prompt,还可能施加速率限制。
- 真正的 BYOK——工具直接从你的机器(或你的基础设施)调用模型服务商。你的 prompt 从不接触厂商的服务器。厂商不抽取任何差价。
Open Design 属于第二种。daemon 用你的密钥、从你的机器,向你配置的任意端点发起 HTTP 调用。我们不做代理。我们不记录。我们看不到你的 prompt。
这个调用实际去了哪里
当 daemon 拿到一个任务时,它会组装 prompt——把该任务相关的 SKILL.md 和 DESIGN.md 文件拉进来——然后向你设置的 base URL 发起一次 HTTP 请求。响应流式回到你的机器,agent 把产物写到磁盘,整个循环就这样。这条链路里没有 Open Design 的服务器。发现你 skill 的那个 daemon,也同时掌管着这次网络调用,所以「它在哪里运行?」是一个设置项,而不是一场销售对话。
兼容 OpenAI 的适配器
2026 年大多数 AI 推理端点都讲 OpenAI Chat Completions API。我们把它当作最大公约数的协议。如果你的服务商讲这套(几乎所有服务商都讲),那它默认就被支持——不需要插件,也不用等待针对单个服务商的集成。
你可以把它指向哪些服务商
| 服务商 | 典型 base URL 形态 | 适合用于 |
|---|---|---|
| OpenAI | https://api.openai.com/v1 | gpt-image-2、gpt-5.x,最强的通用环节 |
| Anthropic | OpenAI 兼容垫片,或专用的 Claude 适配器 | 偏审美的精修、长篇 brief |
| DeepSeek | https://api.deepseek.com/v1 | 高性价比的长上下文起稿 |
| Groq | 服务商 base URL | 低延迟的草稿迭代循环 |
| OpenRouter | https://openrouter.ai/api/v1 | 任意前沿模型,一套计费关系 |
| 自托管 vLLM / TGI / Ollama | 你自己的主机,例如 http://localhost:11434/v1 | 完全本地、涉客户机密的工作 |
| Qwen / Kimi / Hermes | 服务商 base URL | 带 OAI 兼容端点的区域性模型 |
这份清单不是硬编码的白名单——它只是大家通常会用到的那些。任何能回应 Chat Completions 形态的端点都能用。
两个字段,然后重启
配置就是两个字段:
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…
把它们放进 .env.local,重启 daemon,你就切到了另一个模型。为某个敏感项目切换到本地的 Ollama 机器,也是同样的两行:
OPENAI_BASE_URL=http://localhost:11434/v1
OPENAI_API_KEY=ollama
没有需要更新的模型注册表,没有需要重新关联的账户,没有迁移。密钥和端点就是全部的操作面。
这对设计工作为什么重要
设计工作流有一种特定的成本结构,而托管推理产品恰恰应付不来:
- 迭代才是工作的基本单位。一次真正的设计环节意味着 30–50 个 prompt 循环,而不是三个。托管套餐在 50 次循环这道坎上会硬性限流。
- 长上下文是常态。一份严肃的 brief 涉及品牌文档、过往作品、系统规范和参考图像。这种上下文会远远撑爆托管 UI 里的 token 预算。
- 选模型应当是随手的。有些环节想要又快又便宜的模型。有些想要当下最强的。有些想要为敏感内容上一个本地模型。托管产品替你选好了一个。
BYOK 把这三点全解决了。你按 token 付费,你来选模型,你不会被限流。
迭代不再被定量配给
这一点会悄无声息地改变你的工作方式。当每多一次循环都要从套餐里被计量扣除时,你会开始自我审查——你拿了第三稿,因为第四稿感觉太贵。在 BYOK 上,多跑一个环节的边际成本只是模型服务商那边的几美分,于是这个决定重新回到了「为了作品」而不是「为了表盘读数」。第三稿通常正是设计变好的地方;一个对迭代征税的工具,恰恰是在对那一步关键步骤征税。
那成本呢?
一个常见的担忧:「如果我直接付费,难道不会更贵吗?」
实际上,不会。下面是我们内部使用中一个典型的设计工作日:
| 任务 | Token | 服务商 | 成本 |
|---|---|---|---|
| Brief 录入(3 份文档) | 30K 输入 | Claude Sonnet | $0.09 |
| 初稿环节 | 80K 输入 + 20K 输出 | Claude Sonnet | $0.54 |
| 5 个迭代循环 | 250K 输入 + 80K 输出 | Claude Sonnet | $1.95 |
| 最终精修 | 50K 输入 + 30K 输出 | Claude Opus(一个环节) | $1.35 |
| 当日合计 | 约 $3.93 |
这一天产出了一套 deck、两个落地页变体,外加一次品牌探索。托管方案的等价物——假设是月费 $30 的「creator」套餐加超量费——同样的工作大约要 $50,给你更少的迭代次数,还把你锁死在一个模型上。
如果你想更省,把 Claude Sonnet 换成 DeepSeek V3.2,这一天的花费就降到 $1 以下。重点不在于哪个模型才对——而在于价格/质量这个旋钮握在你自己手里,而不是被烤进某个订阅档位里。
隐私与合规
BYOK 之所以重要还有第二个原因:prompt 里包含着你客户的品牌。
托管推理意味着把品牌文档、尚未公布的产品名、内部定价、未发布的创意,统统经由第三方的服务器来回传输。大多数公司对此都有自己的看法。有些公司对此甚至有合同约束。
有了 BYOK,prompt 的往返就只发生在你的笔记本和你早已审查过(或自托管)的模型服务商之间。Open Design 不在这条链路里。我们没有可被传唤的日志,没有可被泄露的攻击面,没有需要解释的审计缺口。
「无日志」在实践中给你买来了什么
对于代理机构的工作、受监管的行业,或者任何未发布的内容来说,这是唯一站得住脚的立场。如果一次安全审查问「我们的品牌资产去了哪里?」,答案是「去了我们合同里的那家模型服务商,别无他处」——而不是「去了一个我们无法掌控的厂商仪表盘」。自托管一个 Ollama 或 vLLM 端点会把它收得更紧:字节根本不会离开你的网络。这正是 BYOK 现实检验 中探讨的同一组权衡,那篇文章很坦诚地讲了哪些地方仍有毛刺——本地模型和前沿模型在审美上并不可互换,而 prompt 注入这块攻击面要由你自己来扛。
如何在项目进行中切换服务商
BYOK 一个被低估的好处,是在项目过程中做服务商套利:
- 起稿——在提问环节和首轮迭代上用便宜的模型(DeepSeek V3.2、Qwen 3)
- 精修——在审美起决定作用的中段环节切到 Claude Sonnet 或 GPT-5
- 敏感内容——为涉客户机密的 prompt 换上一个本地 Ollama 模型
- 最终精修——在当下最强的模型上烧掉一个环节(Opus、GPT-5 Pro)
在 Open Design 里,切换就是在 .env.local 里改两行。没有迁移,没有重新上手,没有套餐升级。
针对一份 brief 的一条实操路由
具体来说,一份单页落地页 brief 可能这样跑:
# draft + first iterations — cheap and fast
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…
# then, for the passes where taste decides the outcome:
OPENAI_BASE_URL=https://api.anthropic.com/v1 # via the compat shim
OPENAI_API_KEY=sk-ant-…
同样的 skill、同样落在磁盘上的设计系统、同样的产物——只有工作流背后的引擎换了。因为 skill 和 system 不过是文件(SKILL.md 和 DESIGN.md),你的整套配置没有任何一部分被绑死在某个特定模型上。这才是「拥有工作流」的真正含义:工具让到一边,而模型只是一个你随 brief 需要而更改的参数。
动手试试
克隆这个仓库,在 .env.local 里设好 OPENAI_BASE_URL 和 OPENAI_API_KEY,运行 pnpm tools-dev。daemon 会使用你把它指向的任意端点、你付费的任意模型、按你想要的任意节奏运行。
这就是 BYOK 故事的全部。没有特别的档位,没有升级流程,没有跟我们之间的计费关系。你付费给模型服务商,你保管你的密钥,你保管你的 prompt。我们提供这一层。
延伸阅读
- 我们为什么把 Open Design 构建成一个 skill 层、而不是一款产品——选择交付一个薄薄的层、而非一款托管应用,背后的赌注
- BYOK 现实检验:会出问题的 5 件事——自带密钥诚实的权衡取舍与毛刺所在
- 31 个 skill、72 个 system:Open Design 库是怎么运作的——无论你跑哪个模型都保持不变的那些
SKILL.md/DESIGN.md文件