昨天能用的模型，今天为什么不能直接恢复？
保存上次选中的模型，下次打开时继续使用，这是很自然的产品体验。但保存下来的首先是一项偏好。它不能保证提供方今天仍支持这个模型，更不能保证当前账号有资格调用。
真正困难的地方在于另一面：如果今天查不到模型目录，是否应该把所有旧偏好都拒绝？这听起来更保守，却可能让旧版客户端失去原本可用的恢复能力。
Orca 的一项候选修复，把这两个问题放到了同一个写入入口。我们执行了八组输入的前后对照，看到的并非一条“全部从严”的规则，而是对明确否定和缺少证据的区别处理。
接受一个设置，不代表能用它工作
Orca 是连接多个 Agent 执行工具的桌面应用。PR #19946记录了一次 Claude structured session 实验：设置一个未列出的模型 ID 可以成功返回，后续轮次却产生错误和零 token。旧配置恢复也能走到同一入口，因此不一定是用户输入错误。
这些真实 CLI 现象来自上游作者的报告。本轮没有重新启动 Claude，也没有把那些 token 数据算作我们的观测。我们的实验问题更窄：候选守卫能否在明确不支持时阻止 setModel，同时保留合理的正常与兼容路径？
这项修复截至本轮核查仍未合入。它是可审查的候选实现，不是已发布产品的完整保证。
八组输入，真正数写入调用
我们固定 Orca 的基线提交 027acb4efa2e6b226d40df266b86367423946d62 和候选提交 a13c8452e70f214b50ea37149c6f6485bc149f6f，用 Node 24.16.0 执行模型设置、恢复与目录解析的原函数体。TypeScript 类型被移除，模块依赖在实验中显式注入；连接是记录调用的替身，返回预设目录。
这不是完整桌面端测试。它能直接看到是否调用了写入方法、旧偏好有没有留在状态中、恢复是否记录了跳过项。它不能观察真实提供方是否采用设置或成功推理。
| 输入与入口 | 基线写入次数 | 候选写入次数 | 候选结果 |
|---|---|---|---|
| 目录明确未列出，普通修改 | 1 | 0 | 拒绝，并给出模型名称 |
| 已退役的旧模型，恢复 | 1 | 0 | 跳过 model，清除旧偏好 |
| 目录列出的模型别名 | 1 | 1 | 允许写入 |
| 别名对应的完整模型 ID | 1 | 1 | 允许写入 |
| 目录查询抛错 | 1 | 1 | 保留兼容路径 |
| 空目录 | 1 | 1 | 保留兼容路径 |
| 只有 default 占位行 | 1 | 1 | 保留兼容路径 |
| 有效模型，恢复 | 1 | 1 | 正常恢复 |
八组条件各跑两个版本，共十六条观测。最重要的差别在前两行：候选代码在写入之前拒绝了明确未列出的模型；其余路径继续调用写入方法。正常输入没有因为增加校验而全部失效。
图 1：目录证据与写入决定。来源：本轮 runs/orca.json。“允许写入”仅指执行到 setModel 调用，不代表账号已获授权或真实推理通过。
为什么“未知”不能直接改名为“不支持”
一份有效目录列出了可选模型，其中没有旧 ID，这给拒绝提供了具体依据。目录接口不可用、查询失败或没有可识别条目，则没有给出同样的证据。
候选代码把后一组情况留在兼容路径上。它并未宣称这些模型受支持，而是没有依据这次目录检查禁止写入。调用之后仍可能成功，也可能在别的层次失败。
这个选择尤其影响恢复。普通修改中的拒绝可以显示给用户；恢复函数则捕获该类拒绝，将字段记入跳过集合，并让旧偏好退出保存的 options。如果把目录未知一律当成否定，旧 CLI 上很多原本可用的偏好就可能被静默跳过。
这不是“遇到任何安全检查失败都应该放行”的一般规则。这里讨论的是模型目录兼容性，不是秘密访问、付费额度或外部写入权限。不同问题需要自己的未知状态处理合同。
别名也说明校验不能只做字符串集合相等。目录可能以 sonnet 命名一行，同时给出完整 resolvedModel。保存的值采用完整 ID 时，仍应匹配这项已列出的模型。我们的别名对照保留了这条正常路径。
发现、可用与采用，要问不同的问题
MCP Server Cards 提案 #2127提供了相邻的设计选择：静态卡片说明远程服务器是谁、在哪里、支持哪些协议版本，但不承担随用户和会话变化的工具与能力声明。当前提案文本为 Final，PR 仍 OPEN，而且属于可选扩展轨道。
两者不能简单视为同一种实现。MCP 处理连接前发现；Orca 处理一次具体模型设置。但它们都提醒客户端：过去保存的一条声明，不能直接回答现在这个主体能做什么。
即便模型目录列出了某个 ID，还剩两道不同的问题。其一是当前账号或凭证有没有使用资格；其二是提供方是否实际采用该设置并完成工作。本轮检查没有回答这两道问题。目录是能力信息，设置方法返回是调用结果，成功推理又是另一条证据。
这次工程对照启发的下一步，是为“实际采用”找到可检查的观察点：成功回合中的模型用量元数据是否足够，还是应使用更直接的提供方确认？上游报告指出，无效模型也可能出现在初始化帧里，因此初始化时回显某个 ID 本身还不够。后续真实运行实验可以对照请求的模型、初始化信息与成功回合的模型记录，检验它们是否一致，以及是否能发现回退。我们尚未执行这组实验，也没有据此认定存在静默回退缺陷。
恢复应保留记忆，也应允许偏好过时
对自己的 Agent 客户端，可以先写三类验收：当前目录明确支持时正常恢复；明确不支持时阻止写入并记录跳过原因；目录未知时执行已经约定的兼容策略。再补上完整 ID 与别名、交互修改与启动恢复这两组差异。
对 CodeFlowMu/FCoP，本轮将这项合同送入开发评审。产品侧仍需核对当前 Host 如何取得目录、如何区分账号资格和实际采用、现有恢复记录能否解释跳过原因。我们尚未据此确认产品缺陷，也没有把“加一张能力快照表”指定为唯一实现。
好的恢复会延续用户意图，也会承认环境已经变化。上一次选中的模型可以作为候选；它是否仍可用，需要今天适用的证据。