让代理记住同一个终端现场，SWE-ReX 提供可持续的 shell 会话

自己给 AI 代理接终端时，很快会遇到一个问题：上一条命令设置的变量，下一条还能用吗？调试器已经打开，后续输入该发到哪里？SWE-ReX 解决的就是这种“执行现场”问题，把命令放进可持续交互的 shell 会话，再把输出和状态交回代理。

它是运行时组件，适合正在做代理工具的人；不会单凭安装就替你写出一个软件。最值得看的材料是官方使用教程，因为它用两条简单命令，把一次性执行与持续会话的区别直接展示出来。

先设置，再读回：状态在哪里

教程先启动一个 Deployment，拿到 runtime，用 execute() 运行一次性命令。然后创建 Bash session，在 run_in_session() 中设置 MYVAR，再在同一个会话读取它。

这不是模型记住了变量值，而是同一 shell 环境还在。教程的预期输出展示了读回的 test，同时保留退出码等执行信息。对于代理而言，后续决策应依据真正返回的观察，而不是从上一步命令文字猜一个结果。

这种持续现场也适用于 ipython、gdb 等交互工具。你可以把后续输入发给已经打开的会话，而不必每次重启程序、重新建立状态。多个会话可以分别承担不同任务，例如一个跑服务，一个做诊断；它们的编号与生命周期就成了代理基础设施的一部分。

换到容器，任务逻辑继续用

教程接下来保留同一个 run_some_stuff 函数，只把 LocalDeployment 换成 DockerDeployment。启动时准备容器，在里面运行服务，再由 RemoteRuntime 连接执行。官方样例同样返回 Hello world、变量值和退出码。

这份材料解释了框架的实际价值：开发者把“任务怎样使用终端”写一次，部署层再决定终端在哪里。它不要求每次换 Docker 或云环境，都把上层代理的执行逻辑重写一遍。

架构文档将两层说得很清楚：Deployment 负责准备和停止环境；Runtime 负责会话、文件读写与命令。远端服务把请求转交给 LocalRuntime，两边保持对应接口，连执行异常也可以回传。

持续会话，不等于默认隔离

教程开头特别说明，LocalDeployment 示例会直接在本机运行，没有沙箱。只有选择并正确配置容器或其他隔离部署，才有相应执行边界。命令能跑到远端，也不证明它只拥有你期望的权限；环境和资源仍由开发者安排。

框架采用 MIT 许可，但 Docker、云机器和模型调用分别有自己的条件。它提供的是可观察的执行接口，不是对任意命令的正确性背书，更不会替上层决定什么时候已经修好问题。

我会在自建代理确实需要持续终端、调试器或可替换运行环境时引入它。先用变量例子确认状态如何保留，再把一个真实任务接进来，比一开始只谈“大规模代理基础设施”更容易知道它解决了哪一步。