凌晨三点，你的AI编程助手在无人值守的状态下修改了核心代码库。它提交了一个看起来毫无问题的PR，结果第二天生产环境直接崩溃。你疯狂翻查终端历史记录，却只能看到零散的操作片段——模型到底收到了什么指令？它为什么会做出那个致命决定？这时候你才发现，原来你从未真正"看见"过AI代理的完整思考过程。

这不是科幻情节，而是2026年每个使用Claude Code、Codex CLI或其他AI编程代理的团队都可能面对的真实困境。这些智能体不再是演示用的玩具，它们常驻在你的代码仓库里，拥有shell访问权限，能编辑文件、运行测试、提交代码。当其中一个做出了你未曾预料的事情——无论是删错了文件、在同一个失败的测试上反复死循环，还是烧掉整个下午的计算资源——终端回滚根本不能作为证据。它只是一种不完整的呈现，甚至可能是误导。

你真正需要的是"线上数据"：实际发送给模型的请求、实际返回的内容，以及代理在回合之间执行的操作。这份记录同时也是一个评估套件的起点，因为捕获到的会话就是一个回归测试，你可以针对下一个模型版本或下一条提示词重放它。问题在于，每个测试框架都假设自己直接与它的服务提供商通信，而几乎没有任何框架让这种替换变得容易。

那么问题来了：你的AI代理会话，到底能不能被录下来？

答案取决于两个核心问题。第一个，能不能把测试工具指向一个代理？第二个，流量到达之后，它的线上格式能不能被理解？这两个问题看似简单，却决定了你将来某天急需的那次会话是否存在。本文将基于2026年9月4日最新验证的实测数据，带你逐一拆解Claude Code、Codex CLI以及各类Agent框架的录制可行性。

先说说最理想的情况。Claude Code是目前所有工具中被拿来对照衡量的基准案例，原因很简单——它读取ANTHROPIC_BASE_URL这个环境变量。你只需要把这个变量指向录制器，启动智能体，会话就会逐轮抵达：提示词、工具调用、文件编辑，以及它们之间模型的回复。整个过程不需要改一行代码，不需要装任何插件，就一条命令加一个环境变量的事。

实测中，我们针对一次真实的bug修复做了端到端验证。一个真实仓库、一个真实缺陷、一个从第一条提示词一路运行到修复成功的完整会话。结果很有意思——这个第一个真实智能体就打破了四个任何测试夹具都未曾产生的问题。这四者事后均已被修复，但这其实也在坦率地说明一件事：合成流量并不能让你准备好面对真实智能体独自面对一段代码库时会做的事情。真实世界的复杂程度，远超实验室环境。

使用API密钥登录的Codex CLI情况几乎一样。通过OPENAI_BASE_URL环境变量把它指向记录器，即可获得完整会话。 harness的运行方式没有任何变化，你平时怎么用，录的时候就怎么用。这种基于环境变量的路由方式，是所有路径中最简单的一种。子进程会继承父进程的环境，因此即使编程智能体本身不配合，派生出编程智能体的网关也会被自动捕获。只要在那个负责生成的进程中设置一次base-URL变量，它启动的每个代理都会自行到达记录器。如果你通过CI流水线、编排器或Agents SDK运行代理，那么你已经走在这条路径上了。

所有这些情况下的记录器都是OrcaReplay。安装方式极其简单，运行 npm i -g orcareplay 即可，需要Node 20或更高版本，没有原生依赖，无需编译，也无需构建。它捕获的正是OrcaRouter在模型目录中所路由的同一智能体流量。换句话说，你不需要为了录制再搭一套基础设施，它本身就是现有路由体系的自然延伸。

但现实从来不是只有理想情况。有些harness会在源代码中硬编码提供商URL，既没有环境变量，也没有配置文件或标志位。你设置了ANTHROPIC_BASE_URL，但没有任何代码会去读取它。这种情况下是不是就彻底没戏了？倒也未必。如果记录器能够启动这个agent，那就仍然存在一条途径，而且正是很多人最担心的那条——TLS拦截。

先别急着皱眉。这里的TLS拦截和你在企业防火墙里见到的那种可不一样。选择加入意味着主动选择，默认情况下它是关闭的。只有当你为某次运行显式启用它时，记录器才会生成一个仅属于该次运行的证书颁发机构。这个CA只受记录器启动的那个代理信任，它被交给那一个进程，不会安装到你的系统钥匙串中，也不会为下次运行留存。当运行结束时，该CA即被删除。代理照常连接到其硬编码主机，记录器响应请求，于是会话建立时的表现就好像该URL一直是可以配置的一样。

这里有一个非常关键的设计细节：路由刻意拒绝读取的内容，与它实际读取的内容同样重要。OrcaReplay只读取允许列表上的主机，除此之外一概不读。允许列表之外的主机不经读取便被隧道传输，仅记录为一个地址和一个字节数——这证明代理确实联系了某个对象，却未曾留下通信内容的哪怕一个字节。这一边界是有意的设计决策，而不是一个尚未触及的局限。同样的原则贯穿于OrcaRouter的代理防火墙，其中允许列表本身就是产品，而不是记录行为产生的副产品。你的数据隐私，从架构层面就得到了保障。

不过TLS拦截有个硬前提：只有当录制器启动代理时，拦截才会生效。已经运行在容器内的代理从未收到该次运行的证书颁发机构，因此它不会信任录制器的应答。这就引出了第三种场景——不在本机上的代理。

容器拥有自己的环境。你在shell中设置的base-URL变量无法传递到容器内部，宿主机上的记录器也无法启动一个已经存在于其他位置的进程——例如VPS上、CI流水线中，或是测试框架在你不知情的情况下构建的沙箱里。基于启动的捕获在这里之所以失败，并不是因为代理难以处理，而是因为记录器根本接触不到它。

针对这种情况，可以使用orca attach。它可以记录一个无法由记录器启动的agent，例如容器中或VPS上的agent。方向反转了：不再是记录器启动agent并把环境传给它，而是附加到一个已在运行的agent上并加以记录。Attach解决的是把流量送到记录器的问题，至于这些流量能否成为你可回放的会话，仍取决于线格式是否被理解。挂接一个能说记录器所识别格式的代理，你就能获得可回放的会话。挂接一个不能识别的，你就会撞上那堵墙——而在有意测试时发现这堵墙，比在事故中途才发现要便宜得多。

最后一种情况可能是最让人意外的：同一个二进制文件，登录方式不同，可录制性就完全不同。使用API密钥登录的Codex CLI可以通过设置OPENAI_BASE_URL来捕获，这前面已经说过了。但如果你让同一个CLI使用ChatGPT订阅登录，情况就彻底变了——它会停止与OpenAI端点通信，转而以你的身份进行认证，与其自身的后端通信。这时候没有可改写的源地址，base-URL变量虽然仍然存在，但无论你把 它指向何处，那个地址都不会成为harness实际使用的服务端点。

失败的是第二个问题，不是第一个。字节可以被移动，记录器甚至能看到它们。但对话面向的是一个记录器无法代替的后端，而且其流程不是记录器所理解的API格式。没有可以生成的重放，因为没有记录器能够成为的源点。对于通过订阅登录的框架，如今最诚实的答案就是：它无法被录制。有益的教训是，登录方式本身就是决定可录制性的一部分。如果你需要录制内容用于评估或审计跟踪，那就用API密钥来运行要录制的会话，订阅登录则留给纯交互式工作。

把上面的内容整理成一张清晰的决策图，大概是这样的：

Claude Code使用API密钥登录，通过ANTHROPIC_BASE_URL路由到记录器，今天就可以录制，答案是"可以"。Codex CLI使用API密钥登录，通过OPENAI_BASE_URL路由到记录器，同样今天就可以录制，答案也是"可以"。使用硬编码提供商URL的harness，无论用什么方式登录，只要由记录器启动并可选启用TLS拦截，今天就可以录制，答案还是"可以"。容器内或VPS上的agent，无论用什么方式登录，通过orca attach附加录制，只要线路格式被理解，答案依然是"可以"。

唯一完全没有通向记录器路径的组合，是Codex CLI使用ChatGPT订阅登录——没有可配置的路由，今天无法录制，答案是"不行"。

所以结论其实很清楚。在采用任何AI编程代理工具之前，先问自己那两个问题：能不能指向代理？流量格式能不能被理解？答案很容易获得，而它们决定了你将来某天急需的那次会话是否存在。不要等到第一次事故之后才想起来问——那时候可能已经太晚了。

对于已经运行在生产环境的团队，建议立即做一次录制可行性审计。检查你的Agent框架是否读取base-URL环境变量，检查你的CI流水线是否能在启动时注入录制器地址，检查你的容器化部署是否支持orca attach模式。这些检查不需要改动业务代码，只需要在配置层面做几个尝试。花半小时确认录制路径是否通畅，可能在未来某个深夜为你省下数小时的故障排查时间。

AI代理正在从辅助工具演变为代码库的共同作者。与任何合作者一样，你需要了解它做了什么、为什么这么做、以及如何在必要时回溯它的决策过程。会话录制不是可选的奢侈品，而是AI驱动开发流程中的基础审计能力。今天就开始建立这套能力，明天你会感谢现在的自己。

来源说明：本文中的每一项行为和具体数据——ANTHROPIC_BASE_URL和OPENAI_BASE_URL的捕获路径、fixture运行后出现的四处故障及其修复、TLS证书生命周期、允许列表与隧道行为、orca attach机制、安装要求——均来自我们针对文中点名的各个harness的验证运行，最近一次验证日期为2026年9月4日。我们未引用任何第三方基准数据，所有结论均来自第一手实测。