Kimi客户端被逆向，发现普通用户看不到的内部入口

知名科技自媒体 @runtimewire 把 Kimi 客户端给逆向了，结果意外发现了几个很有意思的东西。

首先是一个普通用户看不到的隐藏入口： KTH Gateway (Internal) 这是一个给 @Kimi_Moonshot 内部员工使用的入口，里明确要求连接 Moonshot 办公网或 VPN，还需要个人 Bearer Token。 在 Kimi Work 的 About 页面连续快速点击版本号 5 次，这个入口就会出现。

代码显示，这套内部网关同时识别： kimi-* gpt-* codex-* GPT 和 Codex 甚至已经适配了 OpenAI Responses API。 通过 KTH 创建的会话，还会被单独标记并不计入普通 Kimi 会员额度。

KTH 会先从 /v1/models 拉取模型列表，再从 /v1/models/api.json 获取对应模型能力，客户端根据不同模型自动选择不同 Provider。 看起来月之暗面内部已经搭了一层统一的 Model Gateway。

员工面对的是一个入口，至于后面跑的是 Kimi、GPT 还是 Codex，由 Gateway 和客户端处理。 而且这个东西似乎还是最近才加进去的。 RuntimeWire 对比 Kimi Desktop 3.1.5 和 3.1.10 后发现，老版本里还没有 KTH、BYOK 和相关内部网关代码。

接下来作者发现Kimi Desktop 背后其实不只是一个聊天 App。 它启动后会自动安装一个独立的 kimiim-cli.exe，放到 ~/.local/bin，同时还有 kimiim、worker-safety、time-awareness 等一系列可以更新的 SKILL.md。

再结合 Kimi Work 本身已经能够： 读写本地文件、执行 Python 和 Shell、操作带登录状态的浏览器、运行定时任务，以及同时调度大量 Agent。

整个东西拼起来就很清楚了： Model Gateway + 多模型池 + CLI + Skills + 本地执行环境 + Browser + Agent Runtime Kimi Desktop 表面上是一个桌面客户端，下面其实已经是一整套 Agent 基础设施。 我们可能第一次通过一个公开客户端，看到了一个 AI Lab 内部到底是怎么使用 Agent 的。