更换模型时实际会迁移什么
首先要了解 GLM-5.3 是什么，因为这决定了答案。Z.ai 表示："我们在 GLM-5.3 上所做的全部工作就是扩展后训练（post-training）"——它使用与 GLM-5.2 相同的基座模型，所有的提升都来自于后训练。报告的提升是真实且具体的：Terminal-Bench 3.0 从 4.6 提升到 28.3，DeepSWE v1.1 从 46.2 提升到 66.9，Agents' Last Exam (CLI) 从 23.8 提升到 28.5，Z.ai 还声称 "在我们的内部 Z.ai Code Bench 上，比 GLM-5.2 提升了 50%"。关于最后一个数字，有两个坦率的说明：Z.ai Code Bench 是 Z.ai 自己的私有基准测试，该公司称其减少了"来自公开测试集的污染风险"，且同一章节提到"GLM-5.3 仍落后于 Claude Fable 5，后者在 Max 努力程度下达到 39.5%"。权重也尚未发布——"我们将在发布两周后、安全评估和加固完成后释放权重。"
这些都不会改变你的智能体所掌握的知识。更换模型只是改变了进行推理的实体，它不会触及推理所读取的底层基础。Z.ai 自己的开发者文档在关于记忆的页面中也说明了这一点，该页面对这一机制的描述比大多数厂商文档都要好："记忆使编程智能体能够跨任务和会话保留上下文，减少重复输入并提高执行效率，" 并且，对于它作为主要示例的工具，"每个会话都从一个全新的上下文窗口开始。知识主要通过持久的指令文件跨会话传递。"
因此，迁移清单可以清晰地分为两类。
免费迁移，因为它们存在于你的仓库或主目录中。 指令文件——CLAUDE.md、AGENTS.md、.cursor/rules，或者你的工具读取的任何内容。路径范围规则。技能。MCP 服务器配置（这是一个指向服务器的配置文件，而不是模型能力）。你的 git 历史记录、测试套件、构建命令。如果你的智能体对项目的了解记录在 diff 可以显示的地方，那么模型更换对它来说是无感的。
不会迁移，且没有任何提示。 前一个模型在运行会话中积累的任何内容——它制定的计划、它排除的死胡同、你一小时前给它的纠正。这些都是上下文，而无论你接下来使用哪个模型，上下文都会随着会话的结束而结束。工具写入本地、工具特定记忆库的任何内容也会留在原处：它仍然在磁盘上，但它是为了不同的配置而编写的，如果你在更换模型的同时也更换了工具，它根本不会被读取。
尴尬的中间地带。 自动生成的记忆文件介于两者之间。它们是文件，所以得以保留，但它们是作为与另一个模型的会话压缩而编写的，其有用性取决于这些记录是持久的事实（"API 测试需要一个本地 Redis 实例"）还是对某个模型行为的反应（"提醒它不要重新格式化整个文件"）。第一种值得保留。第二种则是你即将带入一个从未有过该习惯的新模型中的噪音。
手动迁移
分为两个步骤，按此顺序进行。第一步是必选项——跳过它，你的请求将直接失败。
Step 1: 在更改模型 ID 之前修复思考配置
GLM-5.3 更改了请求格式的默认值，Z.ai 将其标记为破坏性变更。公告指出："GLM-5.3 支持三种思考努力程度：low、high 和 max。GLM-5.3 不再支持禁用思考。" 文档中的迁移说明非常明确——"需要迁移：如果您的应用程序当前使用 thinking.type: "disabled"，请在将模型 ID 更新为 glm-5.3 之前，将其更改为 enabled 并将 reasoning_effort 设置为 low。否则，请求将失败。"
先更改配置，再更改模型 ID。颠倒这个顺序会导致请求失败，看起来就像服务中断一样，而且默认的 reasoning_effort 是 max（Z.ai 推荐将其用于编程，但它与之前在关闭思考状态下运行的流水线并不直接匹配）。如果你是将此接入现有工具而不是你自己的代码，Z.ai 的文档指出 "GLM Coding Plan 同时支持 Anthropic 和 OpenAI 协议"，每个协议有独立的基础 URL——Anthropic Messages 端点为 https://api.z.ai/api/anthropic——因此工具端的更改通常是基础 URL 加上密钥。Team Plan 用户应注意文档中注明的限制："Team Plan 密钥与其他 Z.AI 的 API 密钥不可互换。"
Step 2: 盘点文件之外存在的内容
这是人们常常跳过的一步，也是一周后会为此付出代价的一步。在切换之前，静下心来对照仓库写下四个问题的答案。不要只在脑子里想——写在文件里。
智能体知道哪些没有写在任何地方的内容？ 你在对话中纠正过的、但没有提交的每一个规范。在会话中途提出的每一个"我们这里不这样做"。如果你唯一的记录是即将结束的会话，那么它就消失了。
你否决了什么，为什么？ 被否决的方法是任何项目中价值最高、持久性最低的知识。新模型根本不知道你已经尝试过基于队列的版本并放弃了它，因此它会再次热情地提出这个方案。写下否决决定和原因，因为原因才是阻止这种循环的关键。
哪些指令是针对旧模型的，而不是针对你的项目的？ 现在就清理这些指令。为了绕过某个模型的习惯而存在的指令，充其量是累赘，最坏的情况是产生主动误导——它们在教一个新模型去防范一个它根本不存在的问题。Z.ai 的记忆页面提到了相关的警告：智能体"会阅读并尝试遵守它们，但当规则模糊、不清晰或冲突时，无法保证严格遵守。" 堆积如山的陈旧规避方案正是导致指令冲突的根源。
有哪些内容分散在不同的机器上？ 如果你在笔记本电脑和工作站上工作，请检查你的工具生成的记忆是否是机器本地的。大部分都是。更换模型是一个很好的契机，让你意识到智能体积累的一半知识只存在于一台电脑上——这与为什么 Claude Code 会在不同机器间遗忘中讨论的问题相同，而且它不会自己变好。
一旦这个盘点清单作为文件存在于仓库中，更换模型就真正变成了一个配置更改。如果没有它，你就只能依靠自己的记忆，去回想那些你已经外包给工具好几个月的事情。
更好的方法：一个记忆层，适用于任何模型
上述盘点方法是有效的，你应该做一次。但你不应该每次都这样做——如果 GLM-5.3 的发布节奏代表了某种信号，那么"每次"现在意味着每隔几周。另一种选择是，不要再将智能体的知识视为你正在运行的任何模型的属性，而是给它一个独立的归宿，让任何模型都可以读取。
这就是 MemoryLake 的用途：一个供你的工具连接的记忆层，这样关于你项目的知识就会保存在一个地方，而其背后的模型则变成了一个可更换的部件。今天切换到 GLM-5.3，下个月再切换回其他模型；记忆不会移动，因为它从未存在于模型内部。设置只需三个步骤。
Step 1: 创建 API 密钥
登录 MemoryLake 并创建一个 API 密钥。这是你的工具用来读取和写入记忆的凭证，也是唯一不针对特定编辑器的设置步骤——这正是关键所在，因为我们的最终目标是构建一个生命周期超越你当前工具选择的记忆层。
Step 2: 上传你的第一批记忆
上传你刚刚写好的盘点清单，以及实际解释你项目的文档：架构说明、决策日志、入职文档、以及直到现在都没人写下来的设计约束。这就是"我们为什么否决它"这类条目的归宿，因为它们是一个全新模型最需要、也最不可能推断出来的条目。保持条目简短且符合事实；记忆层之所以有价值，在于其可检索性，而不是篇幅长短。
Step 3: 连接你的 AI 和智能体
连接你实际使用的工具。MemoryLake 通过 MCP 和 API 暴露记忆，因此具有原生 MCP 支持的智能体（包括 Claude Code、Codex、OpenClaw 等）可以通过指向 MCP 服务器进行连接，其他任何工具都可以通过 API 读取相同的记忆。如果你在这些工具之一中运行 GLM-5.3，这一步会让更换模型变得毫无波澜：智能体继续读取它昨天读取的相同记忆，只是换了一个不同的模型来进行读取。有关 MCP 端的详细步骤，请参阅如何使用 MCP 设置跨 AI 记忆。
一个坦率的限制：MemoryLake 只存储你或你的智能体放入其中的内容。它不会深入到前一个模型已结束的会话中去恢复那里说过的话，它也不能替代你写下自己的规范。它消除的是重复解释，而不是决策本身。
这在实践中改变了什么
实际的差异会在你第三次或第四次更换模型时显现出来，而不是第一次。
模型选择变得可逆。 目前，大多数团队将更换模型视为一种承诺，因为切换回来意味着要重建两次上下文。当上下文存在于模型之外时，你可以在一个仓库上运行 GLM-5.3 一周，将其与你之前使用的模型进行对比，然后切换回来，而无需在任何方向上付出代价。鉴于 GLM-5.3 的权重在发布时仍需两周时间，保持这一选择的开放性显然具有重要价值。
基准测试不再是决策的全部。 Terminal-Bench 的数据确实能反映出一些真实的能力。但它们无法告诉你模型是否知道你的计费模块是承重的核心。将这两者分开的团队能做出更好的模型决策，因为他们可以根据模型自身的优点来评估模型，而不是根据他们会损失多少项目知识来评估。
Token 消耗降低，原因很简单。 Z.ai 自己对 GLM-5.3 效率的描述是，它"在每个努力程度上都提供了比 GLM-5.2 明显更强的智能体编程结果，同时消耗更少的输出 Token。" 检索到的记忆从另一端推动了相同的方向：一个能够查找你规范的智能体不需要将这些规范粘贴到每个提示词中。如果你一直在向你的助手重复解释上下文，这种习惯会带来可衡量的成本。
模型更迭带来的动荡不再具有破坏性。 这是本季度第四或第五个值得关注的编程模型发布。那些将每一次发布都视为升级而不是迁移的团队，正是那些知识层不再与厂商的会话存储绑定的团队。
在不丢失上下文的情况下切换模型的最佳实践
一次只改变一个变量。 更换模型或更换工具，不要在同一个下午同时进行这两项操作。当某些性能下降时，你希望知道是哪项更改导致的。
更换后重新阅读你的指令文件。 针对特定模型的规避方案会隐形地积累。新模型是你删除它们的最廉价机会，而删除它们可以显著提高模型对剩余规则的遵守程度。
验证加载了什么，不要凭空假设。 无论你使用什么工具，通常都有一种方法可以列出哪些指令和记忆文件进入了会话。切换后检查一次。一个被默默卸载的规则文件，看起来就像一个不再遵守指令的模型。
将持久的事实与会话反应分开。 "使用 pnpm，绝不使用 npm" 是持久的。"停止重写整个文件" 是对某个模型行为的反应。将它们归档在同一个地方会导致指令文件失效。
刻意设置努力程度。 GLM-5.3 默认值为 max，Z.ai 推荐在编程时使用 max。如果你的工作负载主要是简短的查找，low 的存在是有原因的——如果你是从 thinking: disabled 配置迁移过来的，文档中注明的等效起点就是 low。
将否决决定作为一等公民（first-class entries）记录下来。 除非否决决定写在它能读取的地方，否则你使用的任何模型都会提出你已经排除的方案。这一个习惯比任何配置调整都能节省更多的时间。
结论
GLM-5.3 是对你的配置是否具有可移植性的一次非常干净的测试。你的工具不需要发生任何改变，因此没有什么可以隐藏答案：如果你的智能体对项目的了解在更换模型后得以保留，那么它就被记录在某个持久的地方；如果不能，那么它一直以来都只存在于会话中。
在更改模型 ID 之前修复思考配置，进行一次盘点，并将结果放在不与当前赢得基准测试的任何模型绑定的地方。这样，下一次发布（很快就会有一次）就只是配置文件中的一行，而不是一周的重复解释。如果你正在同时权衡几次这样的更换，在不丢失上下文的情况下在 AI 模型之间切换介绍了通用模式，并且还有针对 Kimi K3 和 GPT-5.6 的特定模型指南。