Tingly Box：本地 AI 代理网关——统一 API + 智能路由 + IM 远程控制

> 来源: github.com/tingly-dev/tingly-box

> 作者: tingly-dev（Tingly Inc.）

> 许可: MPL-2.0 + 商业双许可

> 语言: Go + Node.js

> 研究时间: 2026-03-31

🎯 一句话版本

Tingly Box 是一个本地跑的 LLM 网关（Go 写的），一个端点统一 OpenAI/Anthropic/Google 的 API，按成本/速度智能路由，还能通过 Telegram/钉钉/飞书远程控制——面向 vibe coder 和独立开发者的"AI 中控台"。

🔧 核心功能

安装极简

npx tingly-box@latest

默认跑在 localhost:12580，自带 Web UI。

工具集成

支持 Claude Code（1-click config）、OpenCode（1-click config）、Xcode（手动配置）。

任何支持 OpenAI 兼容端点的工具都能用——Cherry Studio、VS Code 扩展、自定义 agent 等。

📱 远程控制：最有特色的功能

通过 IM 平台远程控制你的 AI agent：

用例：手机上执行任务、团队共享 agent、离开工位时监控和控制 agent。

这和 OpenClaw 的多 channel 支持很像——但 Tingly Box 是从 proxy/gateway 角度切入的。

🧠 智能路由：源码深度分析

读完 internal/smart_routing/ 和 internal/loadbalance/ 全部源码后的发现：

架构：两层设计

请求进入
  ↓
[Smart Routing Layer] — 基于规则匹配，决定"这个请求该走哪组 provider"
  ↓
[Load Balancing Layer] — 在匹配到的 provider 组内，用策略选一个
  ↓
发送到实际 provider

第一层：Smart Routing（规则引擎）

核心是一个规则引擎，每条规则由多个条件（Ops）+ 一组后端服务（Services）组成。条件之间是 AND 逻辑——所有条件都满足才匹配。

可以检查的 7 个维度：

实际例子——按内容类型路由：

- description: "图片请求走多模态模型"
  ops:
    - position: latest_user
      operation: type
      value: "image"
  services:
    - provider: google
      model: gemini-2.5-flash
      weight: 1

- description: "长 context 走便宜模型"
  ops:
    - position: token
      operation: ge
      value: "50000"
  services:
    - provider: deepseek
      model: deepseek-chat
      weight: 1

- description: "含代码相关 system prompt 走 Claude"
  ops:
    - position: context_system
      operation: contains
      value: "code review"
  services:
    - provider: anthropic
      model: claude-sonnet-4-6
      weight: 1

关键细节：

• Token 估算很粗糙：len(text) / 4（每 4 字符 ≈ 1 token）
• 支持 OpenAI / Anthropic / Anthropic Beta 三种请求格式的解析
• 规则按顺序评估，第一个匹配的规则生效（不是最优匹配）

第二层：Load Balancing（服务选择）

匹配到规则后，每条规则关联一组 Services，用以下策略选一个：

第三层：Health Monitor + 性能追踪

loadbalance/ 里的 ServiceStats 追踪：

但：这些指标目前主要用于观测（Web UI 展示），还没有用于自动路由决策。Token-Based routing 标注为 coming soon。

评价

说了"Smart Routing, Not Just Load Balancing"——确实不只是负载均衡。它能根据请求内容（模型名、消息内容、token 量、是否有图片、是否用工具）做条件路由，这比 Nginx 的 upstream 或 LiteLLM 的 router 更灵活。

但离"智能"还有距离：

• ❌ 不会自动学习路由策略（需要手动写规则）
• ❌ 不会根据延迟/成本实时调整（Token-Based 未实现）
• ❌ 不做语义分析（contains/regex 是字符串匹配，不是 NLU）
• ❌ 没有 fallback/retry 逻辑（匹配失败 = 失败）
• ✅ 但基础设施到位——性能指标已经在采集，等填上 Token-Based 策略就能做成本优化

本质上是一个基于规则的请求分发器 + 性能监控仪表盘，不是 AI 驱动的智能路由。

🏗️ 技术栈

后端: Go 1.25+
前端: Node.js 20+ / pnpm
GUI:  Wails3 (Go + Web)
端口: 12580
数据: 本地文件系统 (~/.tingly-box)
容器: Docker 支持 (ghcr.io/tingly-dev/tingly-box)

🌍 竞品对位

差异化：Tingly Box 最独特的是"本地 GUI + IM 远程控制"的组合——面向一个人同时用多个 AI 模型的独立开发者。

💡 与我们的关联

1. 和 OpenClaw 有重叠也有互补

OpenClaw 是 agent runtime（执行任务），Tingly Box 是 proxy gateway（路由请求）。理论上可以组合使用——OpenClaw 的模型请求通过 Tingly Box 路由，获得智能路由和成本优化。

2. IM 远程控制的方向一致

Tingly Box 支持 Telegram/钉钉/飞书远程控制 agent，OpenClaw 也支持多 channel。区别是 OpenClaw 的 channel 是一等公民（对话式），Tingly Box 的 IM 更像是管理面板的延伸。

3. OAuth 复用 Claude Code quota 很聪明

很多人有 Claude Code 的 Max plan 但 API quota 是分开的。Tingly Box 让你通过 OAuth 复用 Claude Code 的 quota——这是实际的成本节省。

4. 上下文压缩 coming soon

和我们刚研究的 ACON/SUPO 是同一个方向。如果 Tingly Box 的 context compression 做好了，可以在 proxy 层自动压缩所有 agent 的 context，对所有下游工具透明。

5. 但还太早期

• "LLM proxy made by vibe coder for vibe coder" 的早期 tagline 说明了定位
• v0.260306.0 有 critical bug（protocol + remote control）
• 上下文压缩还没做
• 中国社区产品（钉钉/飞书优先，微信群）
• MPL-2.0 + 商业双许可——有商业化意图

📊 评分

报告由深度研究助手自动生成 | 2026-03-31

来源: GitHub