如果你最近经常用 `GitHub Copilot CLI`、`Claude Code`、`Gemini CLI`、`OpenCode` 这类工具，应该很容易遇到一个特别真实的问题：
你让它跑一个任务，可能要 10 分钟、20 分钟，甚至更久。中间它突然卡在一个 `y/n`、权限确认、密码输入，或者某个需要人工判断的步骤上。于是整个流程就变成了
**你必须一直盯着终端。**
我做 Open Relay，最初就是因为这个体验太别扭了。
一方面，大家都在说 AI Agent 可以自主执行、长时间工作；另一方面，我们现实里的使用方式却还是“人肉守着终端，等它来喊你”。
所以我做了 **Open Relay（命令行名叫 `oly`）**。它想解决的，恰好就是这个问题。
一句话概括：
**我想把长时间运行、可交互的 CLI 任务，变成“可托管、可恢复、可审计、可远程接管”的会话。**
它不是一个“又一个终端美化工具”，而更像是 **AI Agent 时代的 CLI 基础设施**。
## 我到底想解决什么问题？
传统 CLI 工作流的问题，在 AI Agent 场景下会被放大：
- 任务一跑就是几十分钟
- 中途可能弹出确认、密码、审批、选择菜单
- 终端一关，任务可能就断了
- 你离开工位时，很难知道它有没有卡住
- 出现需要人介入的节点时，缺少一个顺手的“接管入口”
`tmux`、`zellij` 当然能解决一部分“会话持久化”问题，但它们的产品目标并不是 **监督 AI Agent**。
我对 Open Relay 的定位一直很明确：
**它不是终端复用器替代品，而是面向 Human-in-the-Loop 的 agent supervision relay。**
我不是要把终端分屏、窗口管理做得更炫；我关注的是：
- 任务能不能在后台持续活着
- 人能不能随时重新接管
- 系统能不能判断“现在可能需要你输入了”
- 整个过程能不能留下审计痕迹
- 一台机器上的 Agent，能不能被另一台机器上的人远程监督
- 一个 Agent 能不能监督另一个 Agent
## Open Relay 是怎么做的？
它的核心思路很简单，但非常实用：
**把 PTY 会话的所有权，从当前终端，交给一个后台 daemon。**
也就是说，真正拥有这个交互式进程的，不再是你眼前开的那个 terminal tab，而是 `oly` 的后台守护进程。
于是能力就自然出来了：
- 你可以启动一个 CLI 任务后立刻 detach
- 关掉终端，任务继续跑
- 之后随时 `attach` 回去
- 没接回去之前，也可以先看日志
- 如果只是需要按个回车、输个 `yes`，甚至不用 attach，直接注入输入就行
- 它还能检测“像是卡在 prompt 上了”，主动提醒你
README 里有一句我自己很喜欢的话：
> Run any CLI like a managed service.
这句话其实就是我想表达的产品本质：
**把原本一次性的 CLI 进程，提升成可管理的长期会话。**
## 我最想做的，不只是“能后台跑”
Open Relay 不是只做了一个 detach/reattach。
从一开始，我想搭的就是一整套 **“人监督 Agent，Agent 也可以监督 Agent”** 的运行模型。
比如：
- 一个代理可以长时间自主执行任务
- 它遇到不确定的步骤，可以升级给“监督代理”
- 监督代理如果仍然不确定，或者需要更高权限，再升级给人
- 人不需要一直坐在终端前，只在关键节点介入
我觉得这才是未来真实可行的协作方式。
不是所有任务都要全自动，也不是所有风险都靠人全程盯着。更现实的模式是：
**让系统先自动跑，把“真正值得打断人类”的时刻筛出来。**
而 Open Relay 做的，就是这个模式最底层的执行基座。
## 从技术上看，我为什么觉得它不是“玩具”？
我在 `README.md`、`SPEC.md`、`ARCHITECTURE.md` 和 `ARCHITECTURE_PTY.md` 里写了不少细节，因为这个项目从一开始就不是停留在点子层面。
**我是真的在认真处理 PTY / 终端里那些最容易把产品做崩的边缘问题。**
### 1. Daemon 持有 PTY，客户端只是代理
我采用的是 daemon-side PTY ownership，会话由 daemon 持有，CLI 和 Web 只是连接与控制入口。
好处非常直接：
- 终端断开不影响任务继续
- 多个客户端可以同时 attach
- 后续做网页终端、远程节点代理也顺理成章
### 2. 有 ring buffer，可回放最近输出
我不是简单把输出刷到屏幕上，而是维护一个内存环形缓冲区，并把日志落盘。
所以当你重新 attach 时，不会面对一个“突然开始直播”的黑盒，而是可以先看到最近发生了什么，再进入实时流。
对 AI Agent 场景来说，这特别重要。因为很多时候你不是要“看现在”，而是要先补上“刚才错过了什么”。
### 3. 会做 prompt 检测和通知
在规格设计里，我会结合两类信号来判断“现在可能需要输入”：
- 最近输出里出现 prompt-like 模式
- 一段时间没有新输出
这比单纯看进程是否存活，更接近真实状态。
换句话说，我关注的不是“程序还在不在”，而是：
**它是不是在等你。**
### 4. 认真处理了终端模式和转义序列
文档里我专门提到：
- `DECCKM` 光标键模式跟踪
- bracketed paste 模式跟踪
- 跨 chunk 的 escape sequence 正确性
- OSC/CPR/DA 等终端查询拦截和响应
- Windows ConPTY 的特殊兼容处理
因为如果你想做“可恢复的交互式 CLI 会话”，真正难的不是命令入口，而是复杂、脏、平台差异极大的终端字节流处理。
## 它为什么不是 tmux 的替代品？
很多人第一反应会问：这不就是另一个 `tmux` 吗？
我的回答通常是：
`tmux` 解决的是 **人类终端会话的持久化和复用**；
Open Relay 解决的是 **Agent CLI 任务的托管与监督**。
两者有交集，但不在一个抽象层。
`tmux` 更像“终端空间管理器”；
`oly` 更像“长运行 CLI agent session manager”。
它不强调窗口、pane、screen buffer，而是强调：
- 会话生命周期
- 可注入输入
- 可审计日志
- prompt 检测
- 远程监督
- 多节点联邦
如果说 `tmux` 是给“我本人在终端里工作”设计的，
那 Open Relay 更像是给“**我让一个 agent 在终端里替我工作**”设计的。
## 我觉得它最适合哪几类人？
### 1. 高频使用 AI Coding Agent 的个人开发者
如果你经常让 agent 跑代码生成、重构、测试、构建、修 bug，这个项目会很自然地切中你的痛点。
尤其是那种任务长、中途偶尔需要确认、你又不想一直盯着它的情况。
### 2. 做平台工程、自动化运维的人
这类人真正关心的不是“有没有一个更酷的 terminal UI”，而是：
- 会话是否持久
- 事件是否可追溯
- 权限边界是否清晰
- 远端节点是否可以统一接入
我设计 primary/secondary federation，也是朝这个方向走的。
### 3. 想做“人类审批 + Agent 执行”工作流的人
比如：
- 自动化代码修改，但关键步骤要人批准
- 批处理脚本长期运行，中间遇到风险动作要停下来问
- 一个 agent 负责执行，另一个 agent 负责监督升级
这时候，Open Relay 提供的就是一层很顺手的基础能力。
## 它现在已经能怎么用？
上手路径其实很直接：
```bash
oly daemon start
oly start --title "code is cheap" --detach copilot
oly ls
oly logs
oly input --text "yes" --key enter
oly attach
oly stop
```
你可以把它理解成：
1. 先启动一个后台守护进程
2. 把 CLI 任务扔进去跑
3. 平时靠 `ls` 和 `logs` 看状态
4. 需要介入时，用 `input` 或 `attach` 接管
5. 结束时再 `stop`
这个交互模型我一直希望做得足够克制。它没有试图发明一套全新的开发方式，而是在尽量保留 CLI 原有习惯的基础上，补上“托管”和“监督”这两层能力。
## 一个我很坚持的设计：默认不内建公网监听
很多人做远程控制工具，第一反应是“直接内置一个网络服务”。
但 Open Relay 的思路不是这样。
我更倾向于：
- daemon 本身保持本地访问
- 远程访问通过用户自己控制的 tunnel
- 外面再套一层 auth gateway
- 所有动作都要可归因、可审计
这不是保守，而是我觉得更成熟。远程访问这件事，本来就不该假装“一个二进制解决所有安全问题”，而是要结合你自己的身份系统、网络边界和权限规则。
## 为什么我还会继续做它？
因为它踩在一个很明确的趋势上：
**以后会越来越多的工作，不是人直接敲命令，而是人发起、监督、接管 Agent 在 CLI 里的长流程执行。**
而我们今天的终端工具链，其实还没有完全准备好迎接这件事。
我们有 shell，有 terminal，有 tmux，有 IDE 插件，但缺的那一层是：
**一个对“长运行、可交互、可监督、可恢复的 agent session”足够友好的基础设施。**
Open Relay 想补的，就是这层。
## 最后
如果你对下面这些关键词感兴趣：
- AI Agent
- Human-in-the-Loop
- 长时间 CLI 任务托管
- 可恢复交互式会话
- PTY / terminal runtime
- 远程监督与节点联邦
欢迎来看看 **Open Relay / `oly`**。
我现在最想把它做好的，不是“功能清单再多几项”，而是把这个问题真的解决透。
很多项目是在“造一个更炫的界面”，而 Open Relay 更像是在补齐 **AI Agent 时代缺失的运行时基础设施**。
