ThinkWatch 企业版 · 面向组织
面向组织的 AI 堡垒机
在统一控制面上，对组织内的每一次 AI API 调用与 MCP 工具调用进行安全管控、审计与治理。
- 自托管
- Docker Compose 或 Kubernetes
- v2.0.0
- BSL 1.1
面板中的用户、密钥和模型仅作示意。
原生兼容
- Claude Code
- Cursor
- Continue
- Cline
- OpenAI SDK
- Anthropic SDK
- 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 与分析集成于单一二进制
ThinkWatch 是单一 Rust 二进制程序，依赖 PostgreSQL、Redis 与 ClickHouse。所有功能由同一控制平面处理，无需拆分微服务或编写粘合代码。
单一端口接入所有支持的模型，可直接替换现有接入。
多格式代理
OpenAI Chat Completions、Anthropic Messages、OpenAI Responses 三种 API 在同一端口提供，Cursor、Continue、Cline、Claude Code 及官方 SDK 无需修改即可接入。
按模型路由：自动或手动
每个已注册模型都有独立的路由配置：Auto 模式（latency-cost / balanced / latency-only）或 Manual 模式（拖拽式流量分配条）。健康感知的故障转移通过熔断器自动剔除不健康节点；决策日志为每个请求记录所选 Provider、原因以及任何回退方案。
多 Provider 与模型级开关
OpenAI、Anthropic、Google Gemini、Azure OpenAI、AWS Bedrock，或任意 OpenAI 兼容端点，请求格式自动转换。可在不影响整个 Provider 的前提下暂停单个模型；每行 gateway_logs 均记录实际的 upstream_model，确保事故复盘准确无歧义。
虚拟 API 密钥
按团队、项目或开发者签发限定范围的 tw- 密钥，支持一键吊销，已吊销的密钥归入独立的归档分页。轮换宽限期内禁止再次轮换，避免应急轮换导致流量中断。明文仅展示一次，存储为 SHA-256 哈希。
限流与预算上限
基于 Redis 的滑动窗口 RPM/TPM 限制，可按密钥、用户或团队设置。Pre-call 预算检查在请求送达上游之前拒绝已超出上限的调用，避免上游 token 在事后扣账前被消耗。硬性预算上限采用 fail-closed 策略；消费达到 50 / 80 / 95 / 100% 时触发预警。
实时成本追踪
按模型计价，含预算告警与团队归因。SSE 零开销转发，token 实时计数。
管理 API 与 OpenAPI 文档
通过程序化接口管理 API 密钥、用户和 Provider。网关附带完整 OpenAPI 规范，可将密钥生命周期集成到 CI 流水线、Terraform 或自有工具链，无需使用控制台。
为组织设计，而非单一用户
大多数 MCP 网关面向「单一用户 + 共享服务账号」的场景设计。ThinkWatch 面向组织设计：每位开发者以本人身份连接上游，每一次工具调用均可追溯到具体用户，整套系统部署在组织自有网络内。
| 能力 | ThinkWatch | SaaS 网关 | DIY mcp-proxy |
|---|---|---|---|
| 按用户的上游 OAuth（无共享服务账号） | ✓ | 共享账号 | — |
| Dynamic Client Registration 一键接入 | ✓ | 部分支持 | — |
| 工具级 RBAC 与用户工具目录 | ✓ | 受限 | — |
| ClickHouse 全量审计（可查询、可转发） | ✓ | 仅托管版 | — |
| 响应缓存按 (user, account_label) 隔离 | ✓ | 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 与按用户的工具目录，确保每位用户仅能看到其角色与上游账号实际可用的工具。Viewer 角色无法通过 MCP 工具获得生产环境的写入权限。
完全自托管
ThinkWatch 是可自托管的单一 Rust 二进制程序，依赖 Postgres、Redis 与 ClickHouse。无 SaaS 锁定，MCP 流量不离开组织网络边界。
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 - 完成设置向导
创建超级管理员账号、配置站点，并可选添加第一个 Provider 和 API Key。
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 工具调用时同样免费。