我把 Kiro Gateway 装到本机并跑通了

这次我没有折腾 Docker，也没有走复杂的多账户配置，直接按 jwadow/kiro-gateway 的中文文档，在本机用 Python 原生方式装起来了。目标很简单：把 Kiro 的模型能力暴露成一个兼容 OpenAI 的本地网关，后面可以直接接 Cherry Studio、Cline、Cursor、Open WebUI，或者任何支持 OpenAI API 的客户端。

先说结论

这套东西是能跑通的，而且只要你本机已经登录过 Kiro 或 Kiro CLI，安装门槛其实不高。真正的关键不在 pip install，而在于你有没有现成的 Kiro 凭据，以及你是否愿意把服务长期托管在本机。

我这次机器上的环境很完整：

Python 3.14.4
git 2.54.0
本机已安装 kiro
~/.aws/sso/cache/ 下已有 Kiro 认证文件

这意味着最麻烦的一步，其实已经提前完成了：认证。

为什么我选了原生 Python 方案

文档给了 Docker 和原生 Python 两种路径。我最后选原生，不是因为 Docker 不行，而是因为这次目标是尽快装通、验证模型列表、再挂成常驻服务。

原生方式的好处很直接：

出问题时更容易看日志
改 .env 更快
凭据文件直接复用宿主机已有登录状态
验证 /health 和 /v1/models 更省事

如果只是本机自用，原生方式的摩擦确实更低。

实际安装过程

我做的步骤基本就是这几步：

克隆仓库
创建独立虚拟环境
安装 requirements.txt
写最小 .env
启动 main.py
验证接口
用 launchd 托管成用户级服务

.env 我只保留了最关键的几项：


PROXY_API_KEY="你自己的随机字符串"
KIRO_CREDS_FILE="~/.aws/sso/cache/kiro-auth-token-cli.json"
SERVER_HOST="127.0.0.1"
SERVER_PORT="8000"

这里有一个细节很重要：我没有用 REFRESH_TOKEN 手填，而是直接让网关读取本机现成的 Kiro 凭据文件。这样做的好处是省事，坏处也很明确：你的网关生命周期，会绑定到本机这份 Kiro 登录状态上。

启动之后，第一件事不是看网页

很多人装完一个服务，第一反应是先开 /docs。我这次没有这么做，先看的反而是初始化日志。

原因很简单：服务起来，不等于模型真的能用。

我重点确认了几件事：

它有没有成功读到凭据文件
它识别成了哪种认证类型
token 有没有刷新成功
模型缓存有没有初始化成功
/v1/models 能不能真的返回模型列表

从实际日志看，这次流程是通的：

成功加载凭据文件
成功刷新 token
成功拉取模型
成功初始化账户系统

这说明它不是“空壳启动”，而是真的能代理请求。

模型列表也验证了

我用带鉴权的 /v1/models 做了实测，拿到了可用模型列表。当前返回里包括：

claude-sonnet-4.5
claude-haiku-4.5
claude-sonnet-4
claude-3.7-sonnet
glm-5
deepseek-3.2
minimax-m2.1
minimax-m2.5
qwen3-coder-next

这一步很关键，因为它说明“安装成功”不是一句空话，而是客户端已经可以拿这个 endpoint 当成 OpenAI 兼容接口用了。

常驻运行这件事，比安装本身更值得注意

真正有意思的地方，其实不是装，而是怎么让它稳。

我一开始试了普通后台进程方案，但当前执行环境会回收那类进程，结果服务刚起来就掉了。后面我改成 launchd，把它注册成用户级 LaunchAgent，这才稳定下来。

为什么我觉得这一点比安装还重要？因为很多“我装好了”的状态，其实只是当前终端窗口还开着。一旦会话结束，服务就没了。对本地代理网关来说，这种成功没有意义。

换成 launchd 之后，好处很明确：

登录用户后可自动拉起
进程退出后会自动重启
日志路径固定，排查更直接
不依赖某个 shell 会话活着

如果你是长期自用，而不是临时试验，这一步几乎是必做项。

我最后实际装成了什么

这次不是“理论可行”，而是已经在本机装好并跑起来了。当前服务信息如下：

服务地址：http://127.0.0.1:8000
健康检查：http://127.0.0.1:8000/health
文档地址：http://127.0.0.1:8000/docs

我做过实际验证：

/health 返回 healthy
/v1/models 带鉴权可正常返回模型列表
当前可见模型包括 claude-sonnet-4.5、claude-haiku-4.5、glm-5、deepseek-3.2 等

如果你已经把服务限制在 127.0.0.1，这基本就是一个只给本机自己用的代理层。

本地文件位置

我把这次实际用到的文件路径也记下来，后面排查会更直接：

配置文件：kiro-gateway/.env
项目目录：kiro-gateway
launchd 服务文件：~/Library/LaunchAgents/com.ldd.kiro-gateway.plist
标准输出日志：~/Library/Logs/kiro-gateway/stdout.log
错误日志：~/Library/Logs/kiro-gateway/stderr.log

如果服务出问题，我第一反应会先看日志，而不是先怀疑客户端。

最终可用的接入方式

跑通之后，本地入口就是：


http://127.0.0.1:8000/v1

请求时把 PROXY_API_KEY 当成 api_key 用就行。

如果你接的是 OpenAI 兼容客户端，基本都能按这个思路配：


base_url = http://127.0.0.1:8000/v1
api_key = .env 里的 PROXY_API_KEY

这次我实际生成并正在使用的 api_key 是：


a59a3de46d289eee5552f71671fa63a0994db12909ed0ce1

这串 key 我这里直接写出来，是因为当前服务只绑定在 127.0.0.1，就是本机自用。如果你后面把监听地址改成 0.0.0.0，或者再套反向代理暴露出去，这串 key 最好立刻换掉。

常用管理命令

我最后保留的常用命令就是这几个：


launchctl kickstart -k gui/$(id -u)/com.ldd.kiro-gateway
launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/com.ldd.kiro-gateway.plist
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.ldd.kiro-gateway.plist
tail -f ~/Library/Logs/kiro-gateway/stdout.log

含义也很直接：

kickstart：重启当前服务
bootout：卸载这个 LaunchAgent
bootstrap：重新加载这个 LaunchAgent
tail -f：实时看日志

对本地常驻服务来说，知道怎么重启和怎么看日志，比知道怎么第一次安装更重要。

这套方案适合谁

我觉得它很适合下面这几类人：

已经在用 Kiro，但想把模型能力接给别的客户端
想统一本地 AI 工具入口，不想每个客户端各配一套
想保留 Kiro 的模型资源，同时继续用自己熟悉的工作流

但它也不是完全没有成本。

你要接受的限制

这套方案能用，不代表它没有脆弱点。

我认为最现实的限制有三个：

第一，它依赖本机登录态。如果 Kiro CLI 的 token 过期、失效，或者登录状态被清掉，网关也会跟着失效。

第二，它本质上是一个代理层。代理层意味着多一层故障点。Kiro 认证、网络、模型可用性、客户端兼容性，任何一层出问题，最后都可能表现成“调用失败”。

第三，它更适合个人自用，不适合默认暴露公网。虽然我这次把真实地址、key 和命令都记下来了，但前提是它只监听本地 127.0.0.1。如果你要把它变成局域网服务或公网入口，那就不是同一个安全级别的问题了。

关于 token 续期

这次网关当前用的是：


~/.aws/sso/cache/kiro-auth-token-cli.json

这一点非常关键，因为这意味着它的可用性跟你本机的 Kiro CLI 登录状态直接绑定。

如果这个 token 到期后，Kiro CLI 没自动续上，网关就会失效。最直接的恢复方式不是重装网关，而是重新登录一次：


kiro

很多人碰到这种问题会先怀疑服务本身，但实际更常见的根因是底层登录态已经失效。

我的看法

我对这类项目的判断一向很直接：如果它只是“看起来能用”，那没什么价值；只有当它能稳定接入你现有工作流时，它才算有意义。

这次 kiro-gateway 给我的印象是，它不是那种只适合截图发推的项目，而是真的能落到日常使用里。前提是你得把认证、常驻运行和日志这三件事处理好。

安装本身反而是最简单的一部分。

最后

如果你本机已经有 Kiro 登录态，这个网关值得试一下。它最实际的价值，不是“又一个 AI 项目”，而是把 Kiro 的能力接到了一个更通用的接口层。

这件事一旦打通，后面你切客户端、换工作流、接脚本，都会轻松很多。