gate4agent

一套 Rust 栈，把人们本来就在用的厂商 CLI——Claude Code、Codex、Kimi Code、Grok——包起来，变成可以任意位置生成、流式读取、恢复和观察的会话。它是分层的：一层传输核负责持有一个子进程，一层 node 包住一台机器上的全部 provider，一层中继把任意多个 node 接到客户端，一层有状态的 harness 加上任务跟踪与会话续接，以及一个只跟 harness 说话的终端客户端。默认全部只绑回环地址，凭据只从环境变量读，绝不走命令行。

谁做的465 次提交全出自他一人之手，用的是同一个 Gmail 地址。仓库本身归属于另一个账号 ZENG3LD——所有者与提交者不是同一个身份，所以贡献者列表上只有一个人。他还维护着 crates.io 上的 uzor-tui，也就是本项目终端客户端所依赖的那个 crate；README 特意写明：全新 clone 下来的仓库能构建每一个 crate（含 TUI），不需要任何同级检出。

1. 01

   71% 的提交写明了共同作者

   465 次提交里有 328 次带一条写明模型的共同作者尾注——这是本档案记录到的最高比例，对比 AI Comic Builder 的 56%、DeepSeek Harness 的 23%。模型分布也异常宽：Claude Opus 5 占 131 次、Fable 5.1 占 79 次、Fable 5 占 63 次、Opus 4.6 占 49 次、Sonnet 4.6 四次、一次百万上下文的 Opus 5.5，以及孤零零一次 Grok 4.6。这 465 次提交全部挂在同一个账号上，而仓库归属于另一个账号——所以这里的归属问题不是「谁写的」，而是两个身份里哪一个算作者。

2. 02

   分层的作业台：包住 CLI，而不是取代它

   底下那个设计决定是：厂商工具仍然是厂商工具。gate4agent 不重写 agent，它持有进程。provider 由传输核包住；node 把一台机器上的全部 provider，连同文件浏览器、本地 git 和 worktree 一起包住；中继把任意多个 node 接到各自的客户端；harness 坐在一个统一的应用协议后面，加上基于 SQLite 的任务看板、会话抽取与续接，以及技能／插件／MCP 配置的下发。终端客户端只跟 harness 说话，从不直接连中继。层是单向的——provider、node、中继、harness、客户端——README 把方向写成规则而不是画成图。其中一层值得单独点出：observation 层按构造就是只读的，它从 provider 会话里投射出监控事实，而从不包含 prompt、transcript 或凭据。

3. 03

   README 公开了自己哪几条路径是坏的

   多数项目只描述什么能用，这个项目带两张写「什么不能用」的表。provider 矩阵写着：Kimi Code 当前的 PTY canary 会在就绪前退出，因为本地 provider 报了权限错误，因此对它不作任何当前 PTY 生命周期的声明；Grok 有一个被跟踪的 resume 缺口；qwen-code 已接线但未经验证；Gemini 和 OpenCode 的最后一次实机验证在两个次版本之前，已在产品目标之外。测试表按模式再重复一遍，并钉死版本号——Claude Code 2.1.224、Codex 0.144.6、Kimi Code 0.31.1——包括那条「Claude Code 当前的 resume canary 失败」。它还划清了声明的边界：厂商实机测试是可选开启的（--ignored），需要已安装且已登录的 CLI；而普通 cargo test 是密闭的，永远不会碰任何 provider 账号。一份会点出自己失败用例的支持矩阵，比不点的有价值。

4. 04

   四个进程，其中两个端口不在源码里

   要把整套栈跑起来意味着四个进程：一个 node、两个中继和一个 harness。harness 刻意不共用主中继——它通过自己另开的一个中继实例向外连接——README 警告说，省掉那第二个实例，harness 会在启动时以一个光秃秃的连接错误失败。而端点表承认了一件少见的事：只有 node 和主中继的端口是编译进去的默认值，harness 用的两个端口是以命令行约定传入的，所以在源码里搜它们是搜不到的。这种句子能替读者省下一小时，也正是文档通常省略的东西——因为写出来会让设计显得像是意外。

5. 05

   prompt 是 argv，永远不是 shell 字符串

   传输核有一套值得抄的安全姿态。它的启动规划永远产出「一个可执行文件 + 一个参数向量」，从不把 prompt 拼进 shell 命令。输入准备产出有界的、UTF-8 安全的写入，并中和掉文本里内嵌的括号粘贴序列——那是终端层面的「转义引号」。在 Windows 上，经核查的 Claude、Codex、Kimi 的 npm 安装会被解析到它们真正的可执行文件或 JavaScript 入口，好让 prompt 保持为真正的 argv 和 stdin 数据，而不是被某个命令 shim 重新解析一遍；遇到未知的包装器则有意识地回退到 shell。而拥有交互进程、VT100 屏幕模型和有界回放的终端层，从不自动接受工作区信任或更新提示——那些留在屏幕上，由操作者回答。四个各自独立的决定，全都是关于「不要放任生成的文本变成会被执行的东西」。

6. 06

   每个 crate 一份 CLAUDE.md

   仓库根目录有一份 8,719 字节的 CLAUDE.md，另有七个 crate 各带一份自己的——385 到 875 字节不等，分别在 catalog、engine、handle、kernel、node-protocol、PTY 和 types 里。指令住在它所描述的代码旁边，而不是住在顶层一个文件里——这与本档案里其它配了 agent 的项目正好相反：DeepSeek Harness 是一份 17 KB 的指南加一个链接，PocketPilot 是一份会被外部贡献者按条款号引用的文档。按 crate 分文件，是更小的承诺、更频繁地做，而且它匹配这样一个仓库：真正有意思的约束都是局部的——node 协议可以假设什么，PTY 层在 Windows 上被允许做什么。

7. 07

   一个自己写的测试监管进程，因为普通 cargo test 做不到

   Windows 上的终端测试需要标准测试运行器给不了的东西，于是这个项目自带一个：一个无头监管二进制，它会抑制 Windows 故障对话框并强制每测试硬超时——因为卡在对话框上的进程永远不会返回，而一个永远等待的测试套件和一个正在正常工作的测试套件是无法区分的。按它设门的测试若以别的方式运行，会直接拒绝自己。README 还记下了一个构建细节背后的推理：所有构建共用一个 target 目录，因为按运行分目录会复制整棵依赖图且会不断堆积，而重叠的构建只会在 Cargo 的锁上排队，并不会失败。这两件事，多数项目都会当成口口相传的经验。

8. 08

   九个星、零 release、零 issue

   仓库之外没有任何东西碰过它。9 星、1 fork、0 watcher，而在五个半月里没有任何人开过一个 issue 或 pull request——追踪器是空的，这也是为什么本记录没有一条来自它的引用。同样没有 release 也没有 tag：最新的提交是一个 0.4.0 的发布提交，描述为「第一波不再依赖 SQLite 绑定、并为独立构建引入 tokio 宏」，所以版本是靠提交推进的，而不是靠已发布的 release。820 个文件、465 次提交，其中 425 次发生在七月之后，而几乎没有观众。有两件事在项目这一侧让画面复杂起来：三分之一的参考元数据取自另一个项目公开的工具描述，并保留了署名、按修订号钉住，README 把这些条目称为过渡性的技术债而不是支持声明；以及作者维护着它所依赖的终端框架，并直说全新 clone 不需要任何同级检出。这是一个体量大、纪律严的项目，只是还没找到值得它守纪律的人。