发布了什么，以及它实际上启用了什么
ori 的安装命令为 curl -fsSL https://openrouter.ai/labs/ori/install.sh | bash。您使用 OpenRouter 凭据登录并通过它运行您的测试框架。OpenRouter 对其解决的问题直言不讳：“当使用像 OpenRouter 这样的网关时，为了在 Claude Code 中获得与使用 Anthropic 原生框架相同的开箱即用体验，您需要设置非常多的环境变量。”该 CLI 还会适应您正在运行的内容——“在 ori claude 中，我们会检测您的 --model 标志，并将设置切换为最适合您所使用模型的最佳状态。”
与此同时，OpenRouter 的 Claude Code 食谱（cookbook）记录了如何通过三个环境变量将 CLI 重定向到兼容 Anthropic 的端点。一旦配置妥当，您可以继续使用通过额度计费的 Claude 模型，或者将 Opus、Sonnet 和 Haiku 的“插槽”替换为更便宜的开源模型——GLM-5.2、DeepSeek V4、Qwen3-Coder、Kimi。
Google 的网关方法从基础设施端瞄准了相同的行为：在 OpenAPI 3.x 规范中配置虚拟模型名称，将其指向包括 Gemini、Claude 和 OpenAI 的 OSS-GPT 模型在内的后端，并在不硬编码端点或运行您自己的代理的情况下路由流量。
价格也在向同一个方向推动。OpenAI 自己的团队已经公开表示，GPT-5.6 Luna 降价 80% 是永久性的，而非促销活动。同周的行业分析指出，这一降价发生在 Anthropic 的 Fable 5 以每百万输出 token 50 美元的价格推出几天后。请将这些具体数字视为 2026 年 8 月初的数据，并在围绕它们进行规划之前检查当前价格——但方向是毋庸置疑的：模型 choice 正在成为一项针对具体任务的决策，而现在的工具链已经默认您会频繁进行这种选择。
为什么切换模型会重置您的上下文
模型在调用之间不携带状态
每个请求都是自包含的。模型对您项目的任何所谓“了解”，都是随着该请求的上下文窗口一起到达并随之离开的。Cursor 自己的文档清楚地说明了这一普遍情况：“大型语言模型在补全之间不保留记忆。”路由的改变并不能改变这一点——网关只是转发请求，它不会积累知识。
每个厂商的记忆功能都是独占的
您使用的工具现在确实拥有真正的记忆功能，而且它们确实很有用。但它们也都锁死在各自的产品中：Claude 的记忆条目、ChatGPT 的合成跨聊天记忆、Codex 的本地记忆文件、IDE 的规则目录。将请求路由到不同的后端，这些记忆都不会随之迁移，因为它们从一开始就不是请求的一部分。
您的框架配置不是您的上下文
这是 ori 容易让人犯的错误。当环境变量、模型插槽和推理设置都为您处理好时，切换感觉非常彻底——工具启动了，模型响应了，一切看起来都配置好了。但实际上移动的只是管道。您的代码库积累的知识、决策、死胡同、某个模块看起来不对但必须保持原样的原因，哪儿也没去。
便宜的模型让问题变得更明显，而不是更隐蔽
路由的经济合理性是真实存在的：将常规工作发送给便宜的模型，将昂贵的技术留给难题。但是，一个没有上下文的便宜模型产生的工作需要您去纠正，而纠正它所花费的人力时间正是您试图节省的。只有当便宜的模型从与昂贵模型相同的理解开始时，节省的效果才会显现。
人们尝试过的方法
重新粘贴简报。 在每个会话的顶部放一大块项目上下文。这很有效且通用，这也是为什么几乎每个人都这么做的原因。它也在每一次调用中都会消耗 token，而且它只是一个摘要——每次有人把它改写得更短时，具体细节就会流失。
指令文件。 AGENTS.md、.cursor/rules、CLAUDE.md、.trae/rules。这些是适用于应始终生效的规则的正确工具，而且大多数框架都会读取它们，无论背后是哪个模型，这使它们成为最便携的选择。它们不是知识库：没有人想手动维护一个每周都在增加的 900 行前导说明，而且每次请求都加载规则意味着您每次请求都要为此付费。
所有工作都使用同一个模型。 最简单的解决方法——避免切换。但这也意味着要为琐碎的工作支付高昂的费用，并且无法使用实际上最适合特定任务的模型。
每个工具独立的记忆功能。 在所有地方都开启记忆并寄予希望。结果是您会得到几个逐渐偏离的局部画面，并且在最糟糕的时刻发现它们已经分道扬镳。这与多个智能体在没有共享记忆的情况下工作时出现的失败是一样的。
对仓库进行检索。 有用，总比没有好。检索能找到与查询相似的文本；但它无法保存您在六月份做出的决定或您已经拒绝的方法，这就是为什么仅靠检索并不是记忆的原因。
解决方案：将上下文保留在路由器无法触及的层中
如果模型现在是一个可替换的组件，那么上下文就不能再存在于模型内部。将知识放在它自己的层中，并让您路由到的任何模型从中读取——就像 ori 让您选择的任何模型使用相同的测试框架一样。
MemoryLake 正是为技术栈中的这一位置而构建的：将记忆作为其独立的层，可通过 MCP 或 API 访问，与上一次回答的是哪个模型无关。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出您的第一次请求。
步骤 2：上传您的第一批记忆
加载每个模型都需要的内容，无论哪个模型在值班：架构说明、API 契约、决策日志、运行手册以及代码中不明显的约定。文档、图像和其他文件都存放在同一个地方。
步骤 3：连接您的 AI 和智能体
让 Claude、Codex、OpenClaw 和其他智能体通过 MCP 进行访问。对于您通过网关而不是原生 MCP 客户端访问的任何内容，通过 API 检索相关的记忆，并将其包含在路由器转发的请求中。路由改变了，但模型对您项目的了解没有变。
这在实践中改变了什么
第一个效果是路由决策变得纯粹是经济上的。目前，选择更便宜的模型有一个隐藏的成本——上下文重建税——这就是为什么即使对于不需要昂贵模型的工作，团队也会悄悄地留在昂贵模型上的原因。消除这一税费，那么“哪个模型适合这项任务”就完全可以仅根据价格和能力来回答，而这正是整个路由生态系统所建立的前提。
第二个效果是新模型的发布不再具有颠覆性。在过去的几个月里，已经有六到七个值得切换的前沿模型发布。如果评估一个新模型意味着要重建它对您代码库的理解，您就会在玩具问题上评估它，学不到任何有用的东西。如果上下文是共享的，您只需将其指向相同的记忆，就能在一下午内获得真实的对比。
第三个效果是混合团队之间的一致性。如果一个便宜的模型处理您的测试脚手架，而一个前沿模型处理架构，它们应该基于对系统的相同理解来工作。否则，便宜模型的输出会与昂贵模型的设计相冲突，并且必须有人去发现这一点。
多模型设置的最佳实践
将规则和知识保存在不同的地方
指令文件在不同的测试框架和模型之间具有很好的便携性——将它们用于必须始终适用的规则。相反，将不断增长的项目知识库放在记忆层中，这样您就不用为每次请求支付庞大的前导说明费用，也不用手动编辑每周都在变化的文件。
写下您路由的原因，而不仅仅是路由到哪里
“测试生成转到便宜的模型”是一个很容易被凌晨 2 点值班的人默默推翻的决定。而“测试生成转到便宜的模型，因为前沿模型在我们的测试套件上的优势衡量下来低于 3%”则能保留下来，并告诉下一个人需要重新衡量什么。
重新路由时重新验证事实
模型能力、上下文限制和价格每月都在变化，本文中的具体细节截至 2026 年 8 月初。在您确定路由策略之前，请在源头检查当前的数字。迄今为止，从每一次模型切换中获得的普遍教训——无论是 Opus 5、DeepSeek V4 还是 GPT-5.6——都是您真正关心的基准是您自己的代码库。
结论
工具链在本周赶上了步伐。ori 使得在任何模型上运行 Claude Code、Codex、OpenCode 或 Hermes 变成了一行命令安装的事，而网关级别的路由在基础设施层也实现了同样的效果。模型选择现在是一项针对具体任务的决策，过去导致很少切换模型的阻力已基本消失。
没有解决的是日常最重要的事情。模型在调用之间不保留状态，每个厂商的记忆功能无法跨厂商使用，而且一个配置完美的测试框架仍然会将您的代码库交给一个陌生人。在项目知识存在于您路由的模型之外的独立层之前，每一次切换都会让您失去已有的上下文——而您切换到的便宜模型则会把省下来的钱花在犯错上。