没有什么配置 DSL 要学。Cetas 会话本来就有文件工具，而 settings 就是一个文件 —— 所以当你不确定某个形状该怎么写时，最快的路是直接描述：
加一个叫 my-gateway 的供应商，接到 https://llm.internal.example/v1，
声明模型 qwen3-32b、上下文 128k，然后把它设成我的模型。agent 会读 settings、完成改动、然后告诉你改了什么。这是选择器覆盖不到的场景的正路：供应商条目、模型元数据、子代理 kind、工作流预算。
为什么这条路是通的
配置就是一个文件里的普通 JSON，而 Cetas 自带一份“怎么配置自己”的手册 —— 所以 agent 是从产品手册回答配置问题，而不是凭它对某家 schema 的记忆瞎猜。这也解释了为什么不要期待它编造供应商专属 key：它本该在不知道形状的时候直说不知道。
要 diff
配置错误审起来很便宜，调试起来很贵。说完需求，再要一次改动内容：
把刚才写的内容 diff 给我看。凡是涉及 providers、workflow、或者当前模型选择的改动，都值得要一次 diff，而不是接受一句“好了”。
用命令回读验证
凡是能用命令确认的，就别用自然语言确认。命令和产品走同一条代码路径把文件读回来：
| 改动 | 用什么验证 |
|---|---|
| 供应商或凭据 | /login <provider> |
| 可用模型 | /model |
| 决策槽位 | /decision |
| 推理档位 | /effort |
| 权限姿态 | /permission |
agent 仍然做不到的事
配置改不动权限。会话是 readonly 时，agent 连 settings 文件也写不了 —— 先 /permission workspace_write，或者你自己改。
另外两条边界值得知道：
- 影响系统提示的改动 —— 指令、供应商身份、技能目录 —— 在下一个会话生效。当前会话还是用它启动时拿到的提示。
- 会话起不来、怀疑配置坏了：settings 坏了不会被自动修复，修好或恢复它，见 Settings 参考。
什么时候用，什么时候别用
用对话：新供应商、模型元数据、子代理 kind、工作流预算，以及任何一次性的、不熟的改动。
直接编辑文件（或在机器之间复制）适用于：给一个团队批量开通、审阅一次改动、对齐一份已知可用的配置 —— 并且优先用 /login 而不是内联 api_key，让密钥留在凭据库里。