配置与 profile
Vyane 的四层配置优先级、profile 是什么、profiles.toml 与 providers 字段怎么写。
Vyane 要把一个任务派给某个模型执行，得先知道四件事：找谁要 endpoint 和额度（provider）、用什么请求形态说话（protocol）、跑在哪个执行壳里（harness）、用哪个模型（model）。这些不写死在代码里，而是从配置文件读。这一页讲配置体系怎么组织、优先级怎么排、profile 是什么、字段怎么写。
四层优先级
配置来自四个地方，越靠上越优先，冲突时上面的赢：
| 层级 | 位置 | 装什么 | 是否可信 |
|---|---|---|---|
| 命令行 flag | dispatch --profile xxx 等 | 单次调用临时指定 | — |
| 项目级 | 仓库里的 .vyane/（profiles.toml / review.yaml / workflow 脚本） | 跟着某个 repo 走的配置 | 不可信 |
| 用户级 | ~/.config/vyane/profiles.toml + ~/.config/vyane/secrets.env | 你本机的默认 provider、key、profile | 可信 |
| 系统级 | /etc/vyane | 全机器默认 | 🚧 规划中，未实装 |
加载逻辑是这样跑的（config.py 的 load_config）：先读用户级配好底子，再把项目级叠在上面覆盖，命令行 flag 最后一锤定音。profiles.toml 也可以换成 .json / .yaml，按文件后缀自动认格式，查找顺序是 profiles.toml → profiles.json → profiles.yaml → profiles.yml，取第一个存在的。
项目级 .vyane/ 被当作不可信来源
一个来路不明的 repo 可能在自己的 .vyane/profiles.toml 里，把某个 provider 的 base_url 指向攻击者的服务器，或者让 api_key_env 去读你环境里的 GITHUB_TOKEN / AWS_* 这类跨域密钥，再把它当成 Bearer token 发出去。所以 Vyane 对项目级配置做了两道防线：base_url 覆盖直接忽略（只能用内置或用户级设的地址），api_key_env 只允许指向长得像 provider 凭证的变量名（以 _API_KEY / _TOKEN 之类结尾、且不在跨域密钥黑名单里）。用户级 ~/.config/vyane/ 是你自己写的，不受这些限制。想让某个 provider 真正换地址或换 key，写在用户级，别写在项目级。
密钥放哪
密钥不进 profiles.toml，而是走环境变量：profile 里用 api_key_env 写变量名（比如 "SOME_PROVIDER_API_KEY"），真正的值放在 ~/.config/vyane/secrets.env。仓库里有个 .env.example 模板，照着复制一份改就行：
mkdir -p ~/.config/vyane
cp .env.example ~/.config/vyane/secrets.env
chmod 600 ~/.config/vyane/secrets.env特殊部署想临时换文件，设 VYANE_ENV_FILE=/path/to/env 即可，它比 secrets.env 优先。不要依赖仓库根目录下的 .env（新部署已不走这条路）。secrets.env 里装的是 daemon token、各 provider 的 key 这类敏感值——这一页不列具体变量，需要清单直接看 .env.example。
profile 是什么
profile 就是一套命名好的「provider + protocol + harness + model」组合。 与其每次调用都手写这一堆参数，不如把常用的几套存下来、起个名字，用的时候一句 --profile <名字> 带出来。
[providers.*]：顶层默认表，写每个 provider 的通用设置（不分 profile）。[profiles.<名字>.providers.*]：某个 profile 专属的覆盖。同名 provider，profile 里写的字段盖过顶层默认，没写的字段继承顶层。
举例：你在顶层把 some-provider 的 harness、model 定好，再开两个 profile —— 一个 daily 用便宜快的模型、一个 deep 用最强模型，两者只需在各自 profile 里覆盖 model 这一个字段，其余共用顶层默认。
profiles.toml 例子
下面全是占位值，照着结构改：
# ~/.config/vyane/profiles.toml
# 默认激活哪个 profile（不带 --profile 时用它）
active_profile = "daily"
# ---- 顶层 provider 默认表 ----
# 这里定义的是「不分 profile」的通用设置。
[providers.example-cli]
provider = "example-vendor" # 谁给 endpoint / 额度 / 计费
adapter_provider = "claude" # 用哪个 adapter 类驱动（旧 registry key）
harness = "claude-code" # 执行壳：claude-code / codex-cli / ...
chat_transport = "anthropic_messages" # 请求形态（= protocol）
model = "example-model-standard" # 默认模型 ID
base_url = "https://api.example.invalid" # 占位，非真实地址
api_key_env = "EXAMPLE_API_KEY" # 只写变量名，值放 secrets.env
[providers.example-http]
provider = "example-http-vendor"
adapter_provider = "http-vendor" # 直连 HTTP adapter 的 registry key
chat_transport = "openai_chat"
default_model = "example-http-model" # default_model 是 model 的别名
api_key_env = "EXAMPLE_HTTP_API_KEY"
# extra 里的输出上限只对直连 HTTP adapter 生效
[providers.example-http.extra]
max_tokens = 8192
# ---- profile: daily（默认，日常快档）----
[profiles.daily]
description = "日常小改动，便宜快的模型"
[profiles.daily.providers.example-cli]
model = "example-model-fast" # 只覆盖 model，其余继承顶层
# ---- profile: deep（攻坚，最强模型）----
[profiles.deep]
description = "架构 / 硬 bug，最强模型档"
[profiles.deep.providers.example-cli]
model = "example-model-max"用的时候：
# 用默认 active_profile（这里是 daily）
vyane dispatch "改个小 bug"
# 临时指定 deep profile
vyane dispatch "重构这个模块" --profile deepprofile 只是把参数打包，不改变执行语义
profile 里的每个字段最终都会解析成「四层」里的一维（provider / protocol / harness / model）。想弄懂这四维分别是什么、为什么这么切，看 四层模型。profile 只是让你不用每次重打这些参数。
codex harness 的 provider 是自包含的
用 codex-cli harness 的 profile（比如经中转跑 GPT-5.x），Vyane 会把 profile 里的 base_url / wire_api / api_key_env 用 -c model_providers.<名>.* 内联注入给 codex——也就是说 profile 是唯一事实源，不受本机 ~/.codex/config.toml 当前 provider 选择影响。早先的版本只传 model 名、endpoint 依赖本机 codex config；现在两者已经解耦。安全上这个内联注入仍受项目级信任边界约束——不可信 .vyane/ 的 base_url 不会被注入（同上文两道防线）。
字段参考
[providers.*] 和 [profiles.*.providers.*] 的字段
两处用的是同一套字段（profile 里的会盖过顶层同名 provider）：
| 字段 | 含义 | 说明 |
|---|---|---|
provider | provider 身份 | 谁给 endpoint / key / 额度 / 计费 |
adapter_provider | 用哪个 adapter 类驱动 | 旧 registry key，不是供应商身份;有本机 CLI 类(codex / claude / opencode)和直连 HTTP 类(各云端 vendor 的 key)两种 |
chat_transport | 请求形态（= protocol） | openai_chat / openai_responses / anthropic_messages / gemini_rest / cli_wrap；可写别名 protocol |
harness | 执行壳 | claude-code / codex-cli / opencode / direct-chat 等，决定工具 / 文件 / shell / MCP / session |
model | 模型 ID | 别名 default_model；两者等价 |
model_provider | 模型归属 provider | 可选，模型侧的归属标注 |
base_url | endpoint 地址 | 项目级配置里会被忽略，只有用户级能覆盖 |
api_key_env | 装 key 的环境变量名 | 只写变量名，值放 secrets.env；项目级只允许 provider 凭证形状的名字 |
wire_api | Codex provider 元数据 | 仅 Codex 用；Codex 从 ~/.codex/config.toml 读，Vyane 不当 CLI flag 传 |
extra | 额外参数 | 目前只对直连 HTTP adapter 生效，且只认输出上限类键（max_tokens / max_completion_tokens / max_output_tokens）；CLI adapter 拿不到任意自定义 flag |
extra_env | 额外环境变量 | 注入子进程；项目级配置会挡掉危险变量（PATH、代理、CA、provider 凭证等） |
[profiles.<名字>] 本身的字段
| 字段 | 含义 |
|---|---|
description | 一句话说明这个 profile 干嘛用 |
providers | 这个 profile 下的 provider 覆盖表（结构同上） |
category_bindings | 按意图类别（如 code-gen / review）绑定偏好模型 / prompt 模板 / 额外参数 |
auto_prompt_append | 是否按类别自动追加 prompt，默认 true |
顶层其它键
profiles.toml 顶层除了 [providers.*] 和 [profiles.*]，还认这些键：active_profile（默认激活哪个 profile）、routing（自定义路由规则）、disabled_providers（禁用某些 provider）、caller_override、auto_exclude_caller、broadcast（broadcast 默认目标）。写错顶层键名时，加载会打一条 warning 提示可能是拼写错误——但不会中断。