docs/pi-live-provider-sync-requirements-zh.md
Pi 会读取 ~/.pi/agent/models.json 中的 providers,并把同名显式供应商配置与自己的内置供应商、内置模型合并。当前 CC Switch 会跳过 anthropic、openai、deepseek 等 Pi 内置供应商 ID,导致 Pi 已经加载了显式配置,但 CC Switch 页面没有对应的已启用卡片,也无法正常移除、编辑或重新启用。
这类供应商是否属于 CC Switch 可管理范围,应只由配置来源决定,不能再由供应商 ID 或认证类型决定。
整体行为与 OpenCode 的累加式供应商管理保持一致:
| OpenCode | Pi |
|---|---|
opencode.json.provider | models.json.providers |
| 显式 provider 同步为 CC Switch 卡片 | 显式 provider 同步为 CC Switch 卡片 |
/connect 认证由 OpenCode 管理 | /login 与 auth.json 由 Pi 管理 |
| 添加和移除 provider 节点 | 启用和移除 provider 节点 |
| 数据库保留未添加供应商 | 数据库保留未启用供应商 |
| 不管理当前供应商 | 不管理默认供应商和默认模型 |
Pi 额外需要支持同名内置供应商的显式覆盖:只要供应商节点存在于 models.json.providers,无论 ID 是否为 anthropic、openai、deepseek 或其他 Pi 内置 ID,都必须按普通显式供应商处理。
models.json.providers 是 Pi 当前启用的显式供应商集合。models.json 时,卡片显示为已启用。models.json 后,刷新供应商页面即自动同步,不要求二次确认。PI_BUILTIN_PROVIDER_KEYS 或等价集合不能参与配置归属判断,也不能用于跳过 live provider 同步。边界按配置来源划分:
models.json.providers 中的显式配置由 CC Switch 管理。/login 写入 auth.json 的凭证始终由 Pi 管理,无论其类型为 OAuth 还是 API Key。auth.json 中的凭证。auth.json 凭证、没有 models.json.providers 节点的供应商,不生成 CC Switch 卡片。auth.json。models.json;用户通过 Pi /login 保存的 API Key 仍属于 Pi 原生认证状态。models.json.providers.<providerId>。auth.json。models.json.providers.<providerId>。auth.json、环境变量或 Pi 原生登录状态。所有配置写入复用现有原子文件更新能力,并保留与目标供应商无关的内容。
models.json 中显式保存的模型。models.json。piProviderPresets、models.json.providers 和 Pi 内置模型目录是三个独立数据源,不互相替代。
优先复用 OpenCode 已有能力:
live_config_managed 或等价状态;主要修改范围:
不增加数据库 Schema,也不建立新的 ownership 状态。
明确不做:
/login 凭证管理;auth.json 管理;models.json.providers 中分别加入带 API Key 的 anthropic、openai 和 deepseek,刷新后均出现已启用卡片。/model 能显示并使用这些显式配置激活的模型。auth.json 凭证和相关环境变量时重启 Pi,被显式配置激活的模型不再可用。/login 写入的 OAuth 或 API Key 凭证不被读取或修改。auth.json 内容与文件状态完全不变。