双引擎
Previously 是我们自己造的 agent——内核的每一层设计（提示词冻结、同事制、进化回路）都建立在"我们直接和模型对话"的前提上。所以先说结论：自带 API key（BYOK）是推荐路径，云端形态也只有这一种引擎。 本地形态多给了一个兜底选项：桥接你已经在付费的 agent 订阅。
引擎一：自带钥匙（BYOK，推荐）
把你自己的 provider API key 交给内核——写进 config 的 apiKeys，或者在 Web UI 设置页的 byok 区录入——内核就直接与模型对话。
这是能力最完整的一条路：完整的流式输出、全部同事能力、与云端部署完全一致的行为。想要 Previously 设计中的那个体验，选它。
引擎二：桥接你已有的订阅（兜底）
Bridge 模式换一个思路：内核自己不碰模型，而是把模型工作委托给你机器上已登录的 agent CLI：
claude -p --output-format stream-json
codex exec --json
kimi -p --output-format stream-json鉴权搭你既有订阅的 OAuth 便车——client 从头到尾不接触任何 API key。边际成本是零：你已经付过的订阅，就是全部的费用。
诚实的取舍
桥接是兜底方案，不是平级选项。代价我们摆出来：
- 表现不受我们控制。 被桥接的 agent 是它自己的完整产品，有自己的系统提示词、工具集和行为习惯——内核只能通过一次 CLI 调用影响它。它给出的回答风格、遵守指令的程度，可能与 BYOK 有肉眼可见的差距。
- 每次调用要付一次 CLI 冷启动。 进程拉起是有几秒开销的。
- 流式更受限制。 事件和 delta 只能流出 CLI 给得出来的东西：Claude Code 给到 token 级，Codex 和 Kimi Code 则是从它们的输出里推导出的旁白。给不出结构化事件时，界面会诚实地挂上降级提示，而不是假装一切正常。
- 部分能力对 key 有硬性要求。 比如搜索同事的 web 检索固定需要
DEEPSEEK_API_KEY——纯 bridge（零 key）配置下它会明说报错，而不是悄悄退化成瞎答。 - 已在本机真实验证的适配器：Claude Code 2.1.204、Kimi Code 0.34.0；Codex 的形状由 fixture CLI 测试覆盖，我们如实标注。
桥接适合的场景很明确：不想配 key、想零成本先行体验；或者想让自己的订阅物尽其用。只要你开始认真对待这份记忆，我们建议你配上自己的 key。
随时可以换
引擎选择只是 config 里的一段：
{ "brain": { "type": "api-key", "env": "...", "model": "..." } }
{ "brain": { "type": "bridge", "agent": "claude" } }agent 可以换成 codex 或 kimi。换引擎不改记忆格式，不动一片切片——昨天记下的东西，明天换个引擎照样读。
一句话：引擎是你的选择，不是你的捆绑——但只有 BYOK 拿到的是 Previously 本来的样子。