1. 项目概述：从“一机一用”到“一机多用”的AI开发工作流革命

如果你和我一样，把Claude Code当作主力开发工具，那你肯定也体验过它那个“实验性频道系统”带来的又爱又恨的感觉。爱的是，这个想法本身太棒了——把Claude直接“塞进”你的手机聊天软件里，让你能随时随地跟你的AI开发伙伴对话，就像在Telegram或Slack里@一个同事那么简单。这简直是远程办公和移动开发的梦想场景。但恨的是，它的实现目前还相当“骨感”：一个聊天机器人（Bot）只能绑定一个终端会话。你关掉终端，会话就没了；你想同时处理前端和后端两个项目？对不起，你得去创建两个独立的Bot。没有会话管理，没有路由，更没有持久化。这就像给你一辆顶级跑车，却只配了一把钥匙，而且每次熄火都得重新配。

在过去几个月里，我深度依赖Claude Code进行开发，但经常被这种“一对一”的僵化模式困扰。我可能同时在维护三到五个项目，灵感可能在任何时候、任何地点（比如沙发上、咖啡馆里）迸发。我需要的是一个能从手机端统一管理所有项目会话的“控制中心”，而不是为每个项目都单独准备一个聊天窗口。于是，我决定不再等待官方更新，自己动手，在Claude Code现有的频道协议之上，构建了一个名为 Oh My Team 的路由层。它的核心目标很简单： 一个Bot，管理无限个独立的Claude Code会话 ，并且让这些会话像服务一样在后台持久运行。

2. 核心痛点与设计哲学：为什么简单的“转发”不够

在深入技术细节之前，我们得先搞清楚Claude Code现有频道系统的局限性到底在哪，以及为什么一个单纯的“消息转发器”解决不了问题。这决定了Oh My Team的整体架构设计。

2.1 剖析Claude Code频道协议的“单会话”限制

Claude Code的频道功能，本质上是通过 模型上下文协议（Model Context Protocol, MCP） 建立的一个双向通信管道。你的聊天平台（如Telegram Bot）实现一个MCP服务器，Claude Code客户端连接上来，两者就能交换消息、工具调用和权限请求。问题在于，这个连接是 独占且状态绑定 的。

  1. 会话与进程强绑定 ：一个Claude Code进程（即一个终端窗口里运行的那个会话）在启动时，会连接到配置好的一个MCP服务器地址。这个连接一旦建立，就固定了。你无法通知这个Claude进程：“嘿，现在请处理另一个聊天线程里的问题。”
  2. 缺乏会话标识 ：协议本身没有设计“会话ID”或“线程ID”的概念。所有从同一个MCP服务器来的消息，都会被Claude视为同一个会话的延续。这意味着，如果你简单地让一个Bot把不同聊天线程的消息都转发给同一个Claude实例，所有对话历史会混杂在一起，导致上下文污染，Claude会彻底混乱。
  3. 生命周期同步 ：终端关闭 -> Claude进程退出 -> MCP连接断开。没有持久化机制，无法实现“关闭电脑，会话仍在云端运行；打开手机，无缝接续”。

所以，解决方案不能只是一个“智能路由器”，它必须是一个 会话工厂 和 生命周期管理器 。我们需要为每一个独立的对话线程（无论是Telegram的论坛主题还是Slack的线程）动态创建并维护一个独立的Claude Code会话实例。

2.2 Oh My Team的三大设计支柱

基于以上分析，Oh My Team确立了三个核心设计目标，这构成了项目的三大支柱：

  1. 会话路由与隔离 ：核心是一个轻量级路由器，作为所有流量的总入口。它的任务是根据消息来源的“线程ID”，将其精准路由到对应的、独立的Claude会话桥接器（Bridge）上。确保项目A的代码上下文绝不会泄露到项目B的对话中。
  2. 会话持久化与托管 ：利用 tmux 或 screen 这类终端复用器，让每个Claude会话运行在一个独立的、可分离的虚拟终端中。这样，即使你关闭了本地SSH连接或笔记本电脑，会话仍在服务器后台稳定运行。你需要一个中心化的“枢纽”来管理这些 tmux 会话的启动、停止、列表和重连。
  3. 多智能体协同工作流 ：单一智能体负责从需求分析、研究、编码到自查的全流程，就像让一个人同时担任产品经理、架构师、开发、测试和运维，其效率和客观性都有局限。Oh My Team内置了 12种专业化智能体角色定义 。你可以通过一个指令，让多个智能体在同一个项目的不同 tmux 窗格中并行工作，各司其职，相互校验。

这个设计的关键在于“关注点分离”。路由器只管转发，枢纽（Hub）只管管理，而真正干活的每个项目会话都是完全独立的。这样做带来了一个巨大的优势： 零额外令牌成本 。因为管理指令和项目对话走的是完全不同的路径，你的项目对话消息不会被重复发送到一个庞大的“总控”上下文中，从而避免了令牌的浪费。

3. 系统架构深度解析：从消息到代码的旅程

让我们拆开Oh My Team的引擎盖，看看一条从手机发出的消息，是如何最终变成Claude在终端里执行的代码的。整个架构遵循了“简单、清晰、可扩展”的原则。

3.1 核心组件交互图

整个系统的数据流可以用以下路径清晰表示：

[你的手机] -> [Telegram/Slack 平台] -> [平台适配器] -> [路由器 (Router)] -> [特定会话的桥接器 (Bridge)] -> [Claude Code 进程]
      ^                                                                                                   |
      |                                                                                                   v
      +----------------------- [权限确认循环] <------------------------- [权限请求] --------------------+

3.2 组件职责详解

3.2.1 路由器：流量调度中心

路由器是整个系统的大脑，它是一个用TypeScript编写、运行在Bun上的HTTP服务器，默认监听8800端口。它的核心职责是维护一个 会话注册表 ，这是一个内存中的映射表，记录了：

  • thread_id (或 topic_id ): 聊天平台中唯一标识一个对话线程的ID。
  • bridge_url : 对应于此线程的桥接器服务器的本地地址（例如 http://localhost:8801 ）。
  • session_metadata : 会话的元信息，如项目路径、创建时间、状态等。

当平台适配器收到一条新消息时，它会提取出 thread_id ，并将其连同消息内容一起POST到路由器的 /message 端点。路由器查表，找到对应的 bridge_url ，然后将消息转发过去。如果找不到（比如是一个全新的线程），路由器会返回一个标准响应，提示用户需要先通过枢纽创建会话。

这种设计的巧妙之处在于，路由器本身 不处理任何业务逻辑 ，也不存储任何项目对话历史。它只是一个无状态的转发器，这使得它非常轻量且稳定。

3.2.2 平台适配器：连接外部世界的桥梁

平台适配器是系统与外部聊天平台通信的抽象层。我定义了一个约150行的 ChannelAdapter 接口，任何实现了该接口的模块都能让Oh My Team支持新的平台。目前已经实现了两个：

  • Telegram适配器 ：利用Telegram Bot API的“论坛主题”功能。每个论坛主题被视为一个独立的会话线程，主题ID自然成为 thread_id 。普通群组也可以通过消息线程来模拟。
  • Slack适配器 ：使用Slack的Socket Mode实现实时通信。每个频道（Channel）下的消息线程（Thread）被视为独立会话。

添加新平台（如Discord）理论上只需新建一个适配器文件，实现 start() , stop() , sendMessage() 等几个关键方法即可，体现了良好的扩展性。

3.2.3 桥接器：协议翻译官

这是最关键的组件之一。 每个活跃的Claude Code会话都对应一个独立的桥接器进程 。它是一个标准的MCP服务器，实现了Claude Code频道协议所期望的所有端点（如 /messages , /tools/call ）。

它的工作流程是：

  1. 启动时，动态生成一个未占用的本地端口（如8801），并启动HTTP服务。
  2. 向路由器注册自己，告知路由器：“所有发往 thread_id=abc 的消息，请送到 http://localhost:8801 。”
  3. 等待Claude Code客户端连接。你需要在启动项目会话时，将Claude Code的频道配置指向这个本地地址。
  4. 当收到路由器转发的用户消息时，它通过MCP协议转发给已连接的Claude Code客户端。
  5. 当收到Claude Code返回的响应或工具调用请求时，它再通过适配器原路发送回对应的聊天线程。

每个桥接器都是独立的，这意味着每个Claude Code进程都有自己完全隔离的上下文、对话历史和工具调用状态。

3.2.4 枢纽会话：命令行管理界面

枢纽本身也是一个特殊的Claude Code会话，它运行着一个名为“Hub”的智能体。这个会话连接到一个固定的、用于管理的聊天线程（例如Telegram论坛的“General”主题，或Slack频道的根消息）。

它的作用类似于一个“命令行控制台”。你在这个管理线程里输入诸如 start ~/projects/my-app 的指令。Hub智能体接收到后，实际上是在其运行的终端里执行相应的 omt hub CLI命令。这些命令会：

  1. 在后台创建一个新的 tmux 会话。
  2. 在该 tmux 会话中启动一个新的Claude Code进程，并为其创建一个新的桥接器，配置好连接。
  3. 将这个新桥接器注册到路由器。
  4. 反馈“会话 my-app 已启动”的消息给你。

通过这种方式， 管理逻辑被完美地封装在了Claude Code内部 ，你无需记忆复杂的CLI命令，直接用自然语言管理即可，体验非常统一。

3.3 权限处理的巧思：异步安全门

Claude Code的一个重要安全特性是，在执行潜在风险操作（如写入文件、运行Shell命令）前，会向用户请求权限。在终端里，这会弹出一个交互式提示。但在异步的聊天频道中，这成了一个挑战。

Oh My Team的解决方案既优雅又安全：

  1. 当Claude Code通过桥接器请求权限时（例如：“想要运行命令 rm -rf / ”），桥接器会捕获这个请求。
  2. 桥接器生成一个唯一的请求ID（如 abc123 ），并将请求内容格式化后，通过平台适配器发送到 对应的项目聊天线程 （而不是管理线程）。
  3. 消息看起来像这样： 
    [权限请求] Claude 想要执行：
操作：运行 Bash 命令
命令：npm install express
请回复：yes abc123 以允许，或 no abc123 以拒绝。
  4. 你在手机上的项目聊天线程里直接回复 yes abc123 。
  5. 平台适配器收到回复，路由器将其路由到正确的桥接器。
  6. 桥接器验证ID后，将许可结果传回Claude Code，Claude Code继续执行。

这个过程保证了权限确认与操作请求发生在 同一个对话上下文 中，避免了混淆，也符合安全审计的要求。

4. 从零开始部署与实战操作指南

理论说得再多，不如动手搭一个。以下是我推荐的部署和日常使用流程，基于一台云服务器（Ubuntu 22.04）和Telegram平台。

4.1 基础环境准备与核心安装

首先，确保你的服务器有Node.js环境（推荐18+），然后安装Bun（一个更快的JavaScript运行时）和Oh My Team。

# 1. 安装Bun
curl -fsSL https://bun.sh/install | bash
source ~/.bashrc # 或 ~/.zshrc，重载shell配置

# 2. 通过Bun全局安装Oh My Team
bun install -g oh-my-team

# 3. 验证安装
omt --version

注意 ：虽然Oh My Team也可以通过npm安装 ( npm i -g oh-my-team )，但我强烈推荐使用Bun。Bun的启动速度和运行效率在处理大量HTTP路由和并发桥接器时优势明显，能带来更流畅的体验。

4.2 初始化配置与Telegram Bot设置

接下来进行初始化配置，这是一个交互式向导过程。

# 4. 运行初始化向导
omt hub init

向导会询问几个关键问题：

  • 通信平台 ：选择 telegram 。
  • Telegram Bot Token ：这是关键。你需要先通过 @BotFather 创建一个新的Telegram Bot。创建成功后，BotFather会给你一个长字符串，格式类似 1234567890:ABCdefGhIJKlmNoPQRsTUVwxyZ 。将它粘贴到这里。
  • Telegram 群组/论坛ID ：你需要一个Telegram群组，并 务必开启“论坛主题”功能 （在群组设置中）。然后，将你的Bot添加到这个群组，并授予管理员权限。获取群组ID的简单方法是，在群组里发一条消息，然后访问 https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates ，在返回的JSON中找到 chat.id 字段，通常是一个负数。将这个数字填入。
  • 服务器公网IP和端口 ：路由器需要被Telegram服务器回调，所以如果你的服务器在防火墙或NAT后，需要确保 8800 端口（或你自定义的端口）能被公网访问。向导会尝试自动检测，但最好手动确认。

初始化完成后，会在 ~/.config/oh-my-team 目录下生成配置文件 config.json 。

4.3 启动系统与创建第一个项目会话

配置好后，就可以启动整个系统了。

# 5. 启动枢纽和路由器
omt hub start

这个命令会做三件事：

  1. 启动路由器（在8800端口）。
  2. 启动Telegram适配器，并设置Webhook。
  3. 在一个新的 tmux 会话中启动枢纽Claude Code进程。

现在，打开你的Telegram群组，你应该能看到Bot已经在线。在默认的“General”主题（或你设置的根话题）里，尝试发送：

start ~/projects/my-awesome-api

几秒钟后，Bot会回复“Session ‘my-awesome-api’ started successfully.”。同时，它会自动创建一个新的论坛主题，主题名就是 my-awesome-api 。这个新主题，就是你与这个特定项目Claude会话的专属聊天室。

4.4 连接Claude Code客户端到桥接器

这是最后一步，也是最容易出错的一步。我们需要让本地的Claude Code客户端连接到刚刚为项目创建的桥接器。

  1. 在服务器上，查看刚创建会话的桥接器信息：

    omt hub list

    输出会显示所有运行中的会话及其对应的本地桥接URL，例如 http://localhost:8802 。

  2. 在你的 本地开发机 上，配置Claude Code。编辑Claude Code的频道配置文件（位置通常在 ~/.config/claude-code/channels.json 或通过App的Settings设置）。添加一个新的频道配置：

    {
  "name": "My Awesome API (Remote)",
  "url": "http://<你的服务器IP>:8802", // 注意是服务器IP和具体端口
  "type": "custom"
}

    重要提示 ：这里填的是服务器的 公网IP 和桥接器的 具体端口 ，不是路由器的8800端口。每个会话的桥接器端口都不同。

  3. 保存配置，在Claude Code客户端中选择这个新的频道。如果一切顺利，连接状态会显示为已连接。

现在，奇迹发生了。你可以在Telegram的 my-awesome-api 主题里直接聊天：“帮我写一个Express.js的health check端点”。这条消息会经过路由器->桥接器->到达你本地（或服务器上）运行的Claude Code客户端，Claude处理后的回复和代码，会原路返回到这个Telegram主题里。而你本地的Claude Code终端界面，也会同步显示这一切。

4.5 多智能体团队协作实战

Oh My Team的另一个杀手锏是内置的多智能体工作流。假设你正在 my-awesome-api 项目中，需要实现一个复杂的OAuth 2.0授权流程。

在项目的Telegram主题中，你不再只是和单一的Claude对话，而是可以召唤一个专家团队：

/oh-my-team:team 设计并实现基于OAuth 2.0和RBAC的用户认证授权模块

发送这条指令后，Oh My Team会做以下事情：

  1. 在当前项目的 tmux 会话中，自动创建多个窗格。
  2. 在每个窗格中，启动一个独立的Claude Code进程，但每个进程都被赋予了一个特定的“角色”和系统提示词。
  3. 你可能会看到：
    • 窗格1 (Explorer) ：正在搜索和总结现有的OAuth 2.0最佳实践、安全陷阱。
    • 窗格2 (Librarian) ：在检查项目现有的代码库，寻找与认证相关的配置和模式。
    • 窗格3 (Hephaestus-1) ：正在主攻核心认证逻辑的代码实现。
    • 窗格4 (Hephaestus-2) ：同步为实现的代码编写单元测试和集成测试。
    • 窗格5 (Reviewer) ：实时审查其他窗格产出的设计文档和代码，提出改进意见。

所有智能体的输出，都会汇总到你当前的Telegram主题中。你可以像项目经理一样，在手机上阅读他们的“工作报告”和讨论，并给出下一步指令。最常用的指令可能是 /oh-my-team:review-work ，它会启动一个由5个独立审查员组成的专项小组，从目标验证、质量保证、代码质量、安全性、上下文挖掘五个维度对现有代码进行交叉审计，只有当所有5个审查员都通过时，才算审查完成。这极大地减少了单一智能体“自查盲区”带来的错误。

5. 高级配置、故障排查与经验分享

任何系统在实际使用中都会遇到问题。以下是我在长期使用和开发中积累的一些关键技巧和常见问题的解决方案。

5.1 网络与安全配置要点

  • 使用反向代理和HTTPS ：将路由器（端口8800）暴露在公网存在安全风险。最佳实践是使用Nginx或Caddy作为反向代理，配置HTTPS，并设置严格的防火墙规则（如只允许Telegram/Slack的IP段访问）。这不仅能加密通信，还能隐藏后端端口。 
    # Nginx 示例配置片段
server {
    listen 443 ssl;
    server_name your-domain.com;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    location / {
        proxy_pass http://localhost:8800;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        # 重要：验证Telegram/Slack的Webhook来源IP
        # allow from Telegram IP ranges;
        # deny all;
    }
}
  • 管理令牌安全 ：Bot Token是最高权限密钥。切勿提交到版本控制系统。使用环境变量或安全的密钥管理服务来存储。 omt hub init 向导支持从环境变量读取，如 TELEGRAM_BOT_TOKEN 。

5.2 性能优化与资源管理

  • 桥接器端口管理 ：默认情况下，桥接器端口从8801开始递增。如果同时运行大量会话，注意端口范围。可以通过配置修改起始端口和范围。
  • 会话资源限制 ：每个Claude Code会话都会消耗内存和CPU。对于长期运行的后台会话，可以考虑使用 systemd 或 supervisor 来管理 omt hub 进程，并设置资源限制和自动重启。更简单的方法是，在服务器上使用 tmux 运行 omt hub start ，然后detach，它就会在后台稳定运行。
  • 日志与监控 ：Oh My Team的日志默认输出到控制台。对于生产使用，建议重定向到文件，并使用 tail -f 或 journalctl 进行监控。关键的日志模块是 router 和 bridge ，关注连接错误和消息转发失败。

5.3 常见问题排查速查表

问题现象 可能原因 排查步骤
Bot在Telegram无响应 1. omt hub start 未运行。
2. Webhook设置失败或端口被阻。
3. 服务器防火墙/安全组未开放8800端口。		 1. 运行 omt hub status 检查进程。
2. 查看路由器日志 tail -f ~/.local/state/oh-my-team/logs/router.log 。
3. 在服务器上 curl http://localhost:8800/health ， 再从外网 curl http://<公网IP>:8800/health 。
Claude Code客户端连接失败 1. 桥接器URL配置错误（IP或端口）。
2. 服务器防火墙未放行桥接器端口。
3. 桥接器进程已崩溃。		 1. 用 omt hub list 确认准确的桥接器URL。
2. 在服务器上 curl 该桥接器URL的 /health 端点。
3. 检查对应会话的桥接器日志。
权限请求未弹出/不生效 1. 消息未路由到正确的桥接器。
2. 权限请求ID不匹配或超时。		 1. 确认你是在 项目主题 （而非General主题）内回复权限请求。
2. 检查桥接器日志，看是否收到并转发了权限回复。权限请求默认超时时间为2分钟。
tmux 会话意外退出 1. Claude Code进程自身崩溃。
2. 服务器资源不足（内存OOM）。		 1. 检查 tmux 会话内的Claude Code错误信息： omt hub attach <session-name> 。
2. 检查系统日志 /var/log/syslog 或 dmesg 查看OOM记录。考虑为会话设置内存限制。
多智能体指令无效 1. 未在已激活的项目会话主题内使用。
2. Hub智能体未正确加载多智能体技能定义。		 1. 确保指令发送在由 start 命令创建的主题内。
2. 重启枢纽会话：在General主题发送 restart hub ，或运行 omt hub restart 。

5.4 个人实战心得与进阶技巧

  1. 为不同项目类型预设提示词 ：Oh My Team的会话启动命令可以接受额外的环境变量或参数。我创建了一个简单的包装脚本，根据项目类型（如 node , python , go ）自动注入不同的Claude Code系统提示词，让新会话一开始就具备特定的上下文和角色。

    # 示例：~/bin/start-project
#!/bin/bash
PROJECT_PATH=$1
PROJECT_TYPE=$2
case $PROJECT_TYPE in
  node)
    export CLAUDE_CODE_SYSTEM_PROMPT="You are a senior Node.js backend engineer..."
    ;;
  python)
    export CLAUDE_CODE_SYSTEM_PROMPT="You are a Python data science expert..."
    ;;
  *)
    export CLAUDE_CODE_SYSTEM_PROMPT="You are a helpful programming assistant..."
    ;;
esac
omt hub add $PROJECT_PATH

    然后在Telegram里发送 start ~/projects/data-pipeline python 即可。

  2. 利用 tmux 进行高级调试 ： omt hub attach <name> 让你能直接跳进会话的 tmux 。在这里，你可以直接与Claude Code的终端交互，这对于调试复杂的工具调用失败或查看原始输出非常有用。快捷键 Ctrl+B, D 可以退出而不终止会话。

  3. 会话状态持久化与备份 ：虽然Claude Code的对话历史本身不持久，但你可以通过定期保存 tmux 会话的脚本来实现某种程度的“快照”。或者，更根本的方法是，将重要的对话结论和生成的代码块，通过Hub智能体自动提交到项目的Git仓库中，实现工作进度的固化。

  4. 令牌成本控制 ：这是使用任何AI辅助工具都需要关注的。Oh My Team的架构优势在于隔离。但要注意，每个独立的智能体（在多智能体模式下）都会消耗自己的令牌。对于不需要持续深度思考的看守性任务，可以考虑使用更低成本的模型（如果Claude Code未来支持模型切换），或者设定更简洁的审查提示词。

构建和使用Oh My Team的过程，让我深刻体会到，好的工具不是要替代原有工作流，而是无缝地增强它。Claude Code的频道协议本身设计得很扎实，限制主要在于产品层面的“一对一”假设。通过一个轻量级的路由和会话管理层，我们就能突破这个限制，释放出移动端、多任务、持久化协同的潜力。而将多智能体工作流与终端管理相结合，更是打开了一扇新的大门——它不再是简单的问答，而是组织起一个随时待命的、专业化的虚拟团队。

Logo
亚马逊云科技技术品牌专区

更多推荐

Kiro Editor 开发实战：使用 Cargo 构建、测试与性能优化指南

欢迎来到这篇终极指南，我们将深入探索如何使用Rust构建高性能的终端文本编辑器Kiro Editor。无论你是Rust新手还是经验丰富的开发者，这篇完整教程将带你了解如何利用Cargo工具链进行高效的开发、测试和性能优化，打造一款快速、轻量且功能强大的UTF-8文本编辑器。## 什么是Kiro Editor？Kiro Editor是一款使用Rust编写的极简终端文本编辑器，它最初是著名编辑

avatar 亚马逊云科技技术品牌专区

近期零基础学量化，先按基础差异拆学习顺序

读者应明白，拆解学习顺序时要先看自己的基础缺口，再决定哪一段需要放慢。不同流程阶段都有不同检查任务，学习路线要能反映这些差异。

avatar 亚马逊云科技技术品牌专区

2026年量化工具选择，要跟着能力基础走

读者应理解，选择工具前要先判断自己的能力基础和当前任务。工具应该帮助自己补上当前最关键的缺口，而不是替代学习顺序本身。

avatar 亚马逊云科技技术品牌专区