Kilo CLI 接入指南：配置文件、目录作用域与模型路由

CLI 版本决定配置入口

Kilo CLI 的官方页面注明适用于 1.0 及以后版本，交互式 Provider 入口是 /connect。 先在自己的机器查看版本和帮助，再匹配文档。这里没有安装或运行客户端，也没有验证真实网关。

CLI 不通过扩展侧栏选择工作区，而是从启动目录读取项目配置。给同一个端点配置成功后，换目录仍可能得到不同模型，这通常需要检查作用域，不能直接归因于密钥失效。

分清全局和项目文件

当前官方推荐全局文件 ~/.config/kilo/kilo.jsonc，项目使用 kilo.jsonc 或 .kilo/kilo.jsonc；两种项目入口同时存在时，后者优先。旧名称文件在相应位置也可能被合并，但不再回退读取旧的 .opencode 目录。

个人凭证不要写进仓库。先在全局登记服务，再检查项目里是否覆盖了 Provider 或模型。不要通过删除所有配置来排错，保留一份不含凭证的备份更便于比较。

声明最小模型路由

官方自定义模型格式使用 provider_id/model_id，把端点选项放在 Provider 下，把模型定义放在 models 下。 以下为原创最小示例，所有地址和凭证均为占位，并无真实接口；它不能证明本站已提供 API：

{
  "model": "openai-compatible/YOUR_MODEL_ID",
  "provider": {
    "openai-compatible": {
      "options": {
        "baseURL": "https://80321.cn/v1",
        "apiKey": "YOUR_API_KEY"
      },
      "models": {
        "YOUR_MODEL_ID": { "name": "项目模型" }
      }
    }
  }
}

这个示意针对 OpenAI 兼容入口。若服务要求 Responses 或 Messages，重新核对相应 Provider 配置，不能只替换地址。正式使用还需补上服务商确认的上下文与输出限制。

区分终端认证和调用错误

修改配置后重新启动 CLI，核对会话显示的模型是否为预期路由。 使用一份无敏感信息的小项目，只让 Agent 解释文件。随后逐项检查工具调用与流式返回，暂不允许自动运行脚本。

若交互会话可用、自动化任务失败，检查启动进程是否继承了正确环境与工作目录。不要把 Key 作为命令行参数反复粘贴；这会扩大历史记录和进程信息的暴露面。错误报告只保留脱敏路径、模型 ID 和状态，不上传整份配置。

限制 Agent 与共享数据

配置文件和 Provider 凭证的保存位置不是同一概念，官方建议用环境变量承载实际凭证，避免提交到版本控制。 使用团队批准的注入方式，并限制该凭证可访问的模型和预算。只在隔离副本中试验新端点，逐次审核文件修改、终端命令和 MCP 工具权限，不能把模型接通当作工具安全验收。