面向组织的 AI 堡垒机
在统一控制面上，对组织内的每一次 AI API 调用与 MCP 工具调用进行安全管控、审计与治理。
- 自托管
- Docker Compose 或 Kubernetes
- v3.2.0
- BSL 1.1
原生兼容
- Claude Code
- Cursor
- Continue
- Cline
- OpenAI SDK
- Anthropic SDK
缺少治理的 AI 使用
随着 AI Agent 在工程团队中广泛使用，组织面临日益增加的治理需求。
密钥分散管理
密钥硬编码于 .env 文件、通过聊天工具传递，且很少轮换。
缺乏可见性
无法得知谁调用了哪个模型、消耗了多少 token、产生了多少成本。
缺少访问控制
每位开发者均可直接访问所有模型与 MCP 工具。
合规缺口
AI 辅助代码生成与数据访问缺少审计日志。
成本无法归属
每月的 AI 支出无法解释，也无法归属到具体用户或团队。
ThinkWatch 通过单次部署解决上述问题。
所有 AI 请求均经由统一网关
可直接替换 OpenAI 与 Anthropic SDK 的接入方式。Agent 无需修改现有代码，只需将 base URL 指向 ThinkWatch。
网关、MCP 代理、RBAC 与分析集成于单一二进制
网关、MCP 代理与管理 API 由同一个 Rust 二进制程序提供，依赖 PostgreSQL、Redis 与 ClickHouse，无需拆分微服务或编写粘合代码。
单一端口接入所有支持的模型，可直接替换现有接入。
多格式代理
OpenAI Chat Completions、OpenAI Responses、Anthropic Messages 与 Gemini 四种 API 在同一端口提供。Cursor、Continue、Cline、Claude Code 及官方 SDK 只需更换 base URL 即可接入。
按模型路由：自动或手动
每个模型有独立的路由设置。自动模式按延迟、成功率或两者结合（默认）为上游分配权重；手动模式通过拖拽流量条按固定比例分配。熔断器将故障上游移出轮换，因可重试错误而失败的请求会转发到其他上游，控制台展示每条路由的实时健康状态。
多 Provider 与模型级开关
OpenAI、Anthropic、Google Gemini、Azure OpenAI、AWS Bedrock，或任意 OpenAI 兼容端点，请求格式自动转换。可在不停用整个 Provider 的前提下暂停单个模型；每条请求日志均记录实际提供服务的上游模型。
虚拟 API 密钥
每把 tw- 密钥归属于一位用户，可限定用于 AI 网关、MCP 网关、管理 API 或其任意组合，并可标注成本中心。密钥支持到期时间、闲置超时，以及带宽限期的轮换（宽限期内旧密钥仍可使用）；已吊销和已停用的密钥列在单独的分页中。明文仅展示一次，只存储哈希。
限流与预算
滑动窗口（1 分钟至 1 周）限制请求数或 token 数，按日、周或月设置的预算限制 token 用量（按模型加权）。两者均可设置在用户、API 密钥或角色上，同时作用于模型请求与 MCP 工具调用。请求数在请求前检查；token 与预算在响应后计入，预算用尽后的请求会被拒绝。Redis 不可用时默认不做限制，也可设置为直接拒绝请求。
成本核算
每个请求按平台统一的 token 单价与各模型的权重计价。费用可按模型、用户、Provider 与成本中心汇总，并可按团队筛选，支持导出 CSV 分摊报表和月末预测。预算用量达到 50%、80%、95%、100% 时，每个周期各在审计日志中记录一次预警。
管理 API 与 OpenAPI 文档
API 密钥、用户、Provider 与各项设置均可通过管理 API 管理，使用获准调用管理 API 的 tw- 密钥即可。OpenAPI 规范描述了各个接口，脚本与 CI 流水线无需控制台即可管理密钥的生命周期。
为组织设计，而非单一用户
大多数 MCP 网关面向「单一用户 + 共享服务账号」的场景设计。ThinkWatch 面向组织设计：每位开发者以本人身份连接上游，每一次工具调用均可追溯到具体用户，整套系统部署在组织自有网络内。
| 能力 | ThinkWatch | SaaS 网关 | DIY mcp-proxy |
|---|---|---|---|
| 按用户的上游 OAuth（无共享服务账号） | ✓ | 共享账号 | — |
| 粘贴服务器 URL，经 Dynamic Client Registration 接入 | ✓ | 部分支持 | — |
| 工具级 RBAC 与用户工具目录 | ✓ | 受限 | — |
| ClickHouse 全量审计（可查询、可转发） | ✓ | 仅托管版 | — |
| 响应缓存按用户和账号分别存放 | ✓ | n/a | — |
| 可自托管，单一 Rust 二进制（distroless） | ✓ | 仅 SaaS | 因方案而异 |
| 开箱即用的中英双语界面 | ✓ | 仅英文 | — |
| BSL 1.1：非生产与小规模生产环境免费 | ✓ | 因产品而异 | 开源 |
SaaS 网关 = 托管式 MCP 网关：流量出网，上游访问通常是共享的。DIY = mcp-proxy 或自研中转脚本。各家产品不同，请以你正在评估的那一款为准。
按用户的上游身份
按用户的 OAuth 使 GitHub Issue 由 Alice 创建、Linear 工单分配给 Bob，而非统一归属于 mcp-bot 服务账号。审计轨迹端到端贯通：从 IDE 经由 ThinkWatch 直至上游系统。
基于 Dynamic Client Registration 的接入
对支持 Dynamic Client Registration 的上游，OAuth 握手自动完成。粘贴服务器 URL 并在授权页确认后即可完成连接，无需注册应用，也无需手动复制 client_id/secret。
工具访问控制
工具级 RBAC 与按用户的工具目录，确保每位用户仅能看到其角色与上游账号实际可用的工具。角色可限定为只能使用指定的工具，例如只读工具。
完全自托管
ThinkWatch 以单一 Rust 二进制程序运行在组织自有的基础设施上，依赖 Postgres、Redis 与 ClickHouse。无 SaaS 锁定，MCP 流量由 ThinkWatch 直接发往上游服务器，中间不经过第三方网关服务。
token、密钥与调用的实时可观测性
对组织内 AI 请求的实时可观测。以下面板为使用模拟数据渲染的 React 组件，并非截图，用于展示控制台界面。
- OpenAIus-eastHealthyCB:Closed412 ms99.8%
- Anthropicus-westHealthyCB:Closed538 ms99.6%
- Google Geminius-centralHealthyCB:Closed297 ms99.9%
- Azure OpenAIeastus2DegradedCB:HalfOpen1240 ms96.2%
- AWS Bedrockus-east-1HealthyCB:Closed624 ms99.4%
通过四个步骤从源码运行
以下是 ThinkWatch README 中的开发步骤。生产部署请参阅部署指南，涵盖 Docker Compose、Kubernetes Helm、SSL 与生产加固。
部署指南- 启动基础设施
通过 Docker Compose 启动 PostgreSQL、Redis、ClickHouse 以及其他开发依赖服务。
$ make infra - 生成开发密钥并启动后端
从 .env.example 派生 .env 并填入随机密钥，然后启动网关（:3000）和控制台（:3001）。
$ make dev-secrets$ make dev-backend - 启动 Web 控制台
安装依赖并启动 Vite 开发服务器。
$ cd web && pnpm install && pnpm dev - 完成设置向导
创建超级管理员账号并设置站点名称，向导随后签发第一把 API 密钥。
http://localhost:5173/setup
curl https://gateway.your-org.com/v1/chat/completions \
-H "Authorization: Bearer tw-your-api-key-here" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4o",
"messages": [{"role": "user", "content": "Hello"}],
"stream": true
}' 可直接替换：更换 base URL，并使用虚拟 tw- 密钥。
生产环境免费额度
BSL 1.1 许可证。非生产环境免费；生产环境每月不超过 10,000,000 计费 token 且不超过 10,000 次 MCP 工具调用时同样免费。