一、起因：一个让 AI Agent 干瞪眼的场景
我手头有个的 C++ 项目，开发环境跑在一个叫 ddev 的容器里。
进容器要这条命令：
注意两个细节：
- 要 sudo（要密码）
- 进去之后是个交互式 shell，你得在里面敲 bazel build ...
平时我自己敲没问题。但当我想让 AI Agent 帮我"编译—看报错—改代码—再编译"自动走完整闭环时，它进不去：
-
AI Agent 出于安全策略不能 sudo -
即便绕开 sudo，它每次执行命令都是起一个新 shell，无法保持"我已经在容器里"这个状态
于是我陷入一种荒诞境地：我让 Agent 帮我修编译错误，结果它每次只能干瞪眼说"你把报错贴给我看看"。这不还是回到 ChatGPT 时代的复制粘贴流吗？
写代码的部分 AI 可以包圆，但运行环境是它的盲区——这是当下绝大多数 AI Coding 工具共同的尴尬。
二、市面上都怎么解？(Related Work)
我搜了一圈，业界目前的思路大致分三派：
派系 1：MCP + 持久 Shell（让 Agent "住"在 tmux 里）
代表项目：
- tmux-mcp
系列（Rust/Node 实现都有） - persistent-shell-mcp
（基于 tmux 维持会话） - Term-CLI
（专为 Agent 驱动 SSH/TUI/REPL 设计） - Smart Terminal MCP
思路：把一个 tmux 会话包装成 MCP 服务，Agent 通过 send-keys 发命令、capture-pane 读输出，命令的执行状态跨调用保留。
优点：标准化、生态好、能处理交互式程序。
缺点：要装 MCP server、要在 IDE 里挂载配置、有学习成本。
派系 2：云沙箱（让 Agent 自己起一个新容器）
代表项目：
- E2B、Daytona、Bunnyshell Coding Agent Sandbox
-
Docker Sandbox 自定义模板
思路：Agent 不用进你的环境，直接在云端拉一个干净的容器，里面想 sudo 想 apt 都行。
优点：隔离干净、安全、可重复。
缺点：重，且没法接你已有环境——我那个 ddev 是公司内部镜像、挂着内部代码库和私有依赖，云沙箱拉不动。
派系 3：容器内 SSH
思路：在容器里跑个 sshd，Agent 通过 ssh 直连容器内执行命令。
优点：模型清晰。
缺点：要改容器、要配密钥、要开端口，对已有容器侵入性大。
三、我选的路：60 行 Shell 干掉所有花里胡哨
最后我没选 MCP，没选沙箱，没选 ssh。
因为我意识到一件事：tmux 这个 1985 年就有的老工具，本身就解决了"持久会话 + 远程驱动"这两件事。我只需要把 tmux send-keys 和 tmux capture-pane 包成一个 60 行的 shell 脚本就够了。
核心思想一句话：人来负责"sudo 进容器"这一次性的脏活,Agent 通过 tmux 这个"传声筒"远程指挥已经在容器里的 shell。
架构图
时序对比
传统方式（Agent 干瞪眼）：
用户在 Agent 和容器之间反复复制粘贴
桥接方式（Agent 自主闭环）：
AI Agent 自主闭环编译调试
四、实战：让 AI 在容器里跑通一次 bazel 编译
我在一个真实的 C++ 项目（约 2.6 万个 bazel target）上验证了整套流程。Agent 全程自主完成，我只看着结果。
用户需要做的（全部）
完事，接下来全交给 Agent。
Agent 干了什么
实测数据
全过程我只输入一句话："帮我编译，命令是 bazel build TuringPlugin --config=rtp"
剩下的报错定位、源码诊断、修复决策、回归验证，Agent 全自主。
Agent 在干啥的实时画面
——这一切，AI 自己看到、自己分析、自己改、自己重跑。
五、td.sh 长什么样？
总共不到 80 行 shell，核心命令就 5 个：
底层就是这两个 tmux 命令的封装：
加一点 prompt 检测启发式（看最后一行是不是以 $#> 结尾），齐活。
六、为什么"轻"反而是优势？
复盘一下，这个方案没用任何 MCP、没装任何依赖、没改任何容器配置。回头看，轻反而是它最大的优点：
bash /path/to/td.sh，任何能跑 shell 的 Agent 都能用
这与 MCP 派、沙箱派的核心差异是：
它们试图给 AI 一个"通用环境"，而我只想让 AI 进我已有的环境。
七、什么场景适合这种方案？
✅强烈推荐：
-
你有一个重型本地/远程开发容器（公司内部镜像、挂载私有代码、有特殊网络） -
进容器需要 sudo / 跳板 / VPN 等麻烦操作 -
你希望 AI Agent 在这个容器里直接干活、自主闭环 -
编译/测试任务很长，需要异步执行 + 监视
❌不推荐：
-
你的项目是简单的 npm/pip 项目，AI 直接在主机就能跑 -
你需要给 AI 一个全新隔离环境做实验（这种场景请用 E2B / Daytona） -
你需要严格的权限边界与审计（请用 MCP + 权限层）
八、写在最后：一个小观察
折腾这个方案的时候，我意识到一件事：
当下大量"AI Agent 工具"，都是在试图替代 Linux 几十年沉淀下来的基础设施。但很多时候，正确的做法是把 AI 接到这些基础设施上，而不是另起炉灶。
tmux 是 1985 年的设计，screen 更早。它们解决"持久会话 + 远程驱动"已经几十年了。我们要做的不是让 AI 重新发明 tmux，而是写一个 60 行的胶水让 AI 学会用 tmux。
AI 不需要一个新世界，它需要一双能伸进旧世界的手。
项目代码
完整代码（README + td.sh，加起来约 200 行）：
td.sh：tmux 桥接工具（80 行）
-
README.md：用户操作手册（125 行）
目录结构：
如果你也在折腾"如何让 AI Agent 进我的开发环境"这件事，欢迎交流。
九、团队介绍
我们是阿里国际-智能技术-Lazada搜索工程团队，负责LAZADA、Draza、Gmarket等业务的搜索、导购业务和AE的商品理解业务。团队致力于融合深度学习、大模型、生成式AI及AIGC等前沿技术，在搜索能力和商家AI能力等方向进行全方位升级，持续驱动平台收入与业务高速增长。多年来，我们在多模态LLM推理相关性、生成式召回/排序、智能创意与AI投放管家等核心技术上持续深耕，相关成果已规模化落地。欢迎对共同探索AI驱动的搜索技术新范式！
点击上方名片，关注我们吧～