1. 为什么需要跨 CLI 编程 Agent 的会话接力1.1 一个真实到让人抓狂的场景我平时写代码有个习惯终端里同时开着好几个 AI 编程助手。Claude Code 用来做架构梳理和长上下文重构Codex CLI 用来跑一些需要快速迭代的小脚本偶尔还会切到别的 CLI Agent 处理特定任务。问题就出在切这个动作上——每个 CLI Agent 都有自己的会话上下文你在 Claude Code 里聊了半小时的需求背景切到 Codex 就得从头再讲一遍。更别提有时候一个 Agent 的额度用完了想换另一个继续干上下文直接断档那种感觉就像写了一半的文档突然断电还没保存。这个痛点其实非常普遍。现在做 AI 编程的人手里基本都不止一个 CLI Agent。Claude Code 的强项是理解复杂代码库、做多文件重构Codex CLI 在代码生成和快速验证上很顺手还有一些团队自研的 Agent 或者基于开源框架搭的 CLI 工具各有各的适用场景。但它们的会话状态是彼此隔离的没有一个通用的接力棒机制。所谓会话接力说白了就是Agent A 干到一半把当前的对话历史、任务状态、关键上下文打包交给 Agent B 继续干B 能无缝接上不需要人肉复述。这件事听起来简单做起来要解决三个核心问题——会话怎么导出、格式怎么统一、导入后怎么让新 Agent 理解之前的进度。1.2 会话接力的核心价值在哪里先想清楚为什么要做这件事不然容易陷入为了折腾而折腾的陷阱。第一是成本优化。不同 Agent 的计费模型不一样有的按 token 计费有的包月有的有免费额度。一个长任务如果全程用最贵的那个跑成本会很难看。会话接力让你可以在任务的不同阶段选择性价比最高的 Agent。比如前期需求梳理用便宜的核心代码生成用贵的测试用例补充再切回便宜的。第二是能力互补。没有哪个 Agent 在所有任务上都最强。Claude Code 对大型代码库的理解确实好但有时候 Codex 生成的代码更符合某些语言的惯用法。会话接力让你能集各家之所长而不是被单一工具绑死。第三是容错和连续性。Agent 服务偶尔会抽风网络会断额度会用完。如果会话能接力这些都不是问题——换个 Agent 接着干就行任务不会因为工具的问题而中断。第四是团队协作。团队里不同人可能偏好不同的 Agent如果会话能标准化导出和导入那 A 用 Claude Code 做到一半B 可以用 Codex 接着做交接成本大幅降低。1.3 这件事的难度到底在哪很多人第一反应是不就是把聊天记录复制过去吗实际做起来会发现远没那么简单。格式差异是第一个坎。Claude Code 的会话存储格式和 Codex CLI 完全不同字段名、嵌套结构、元数据都不一样。你不能简单地把 JSON 从一个格式映射到另一个格式因为有些信息在源格式里有在目标格式里根本没有对应的位置。上下文窗口是第二个坎。一个跑了很久的会话token 数量可能远超目标 Agent 的上下文窗口。你不可能把全部历史都塞进去必须做摘要和裁剪但裁哪些、留哪些直接决定了接力后 Agent 能不能理解任务。状态语义是第三个坎。会话里不只有对话还有工具调用记录、文件修改历史、当前工作目录状态等。这些隐式状态如果不传递新 Agent 接手后会一脸懵。工具链差异是第四个坎。不同 Agent 支持的工具集不一样Claude Code 能调用的工具和 Codex CLI 能调用的工具未必重合。接力时如果历史里有目标 Agent 不支持的工具调用需要做转换或降级处理。搞清楚了这些难点后面的方案设计就有了方向。2. 整体方案设计与技术选型思路2.1 三种可行路线对比做会话接力业界目前大致有三条路线各有优劣我逐一分析一下。路线一中间格式转换。定义一个通用的会话中间格式类似会话交换格式每个 Agent 的会话先导出成这个中间格式再从中间格式导入到目标 Agent。优点是扩展性好新增一个 Agent 只需要写一对导入导出适配器缺点是中间格式的设计很难做到既通用又不丢信息容易变成最小公倍数式的信息阉割。路线二直接点对点转换。针对每一对 Agent 写专门的转换逻辑。优点是转换质量高可以针对性地处理两个格式之间的差异缺点是组合爆炸N 个 Agent 需要 N×(N-1) 个转换器维护成本高。路线三代理层拦截。在 Agent 和它的后端服务之间加一个代理层拦截所有请求和响应在代理层做会话的持久化和转换。优点是透明Agent 本身不需要改缺点是实现复杂而且涉及网络请求的拦截和重放稳定性和安全性都要仔细考虑。我最终选择的是路线一为主、路线二为辅的混合方案。核心用中间格式做通用转换但对于 Claude Code 和 Codex CLI 这两对高频组合额外做一些针对性的优化处理。这样既保证了扩展性又在关键路径上不牺牲质量。2.2 中间格式的设计原则中间格式是整个方案的地基设计得好不好直接决定成败。我遵循了四条原则。原则一保留原始信息不做有损压缩。中间格式里要完整保留源会话的所有信息包括那些目标 Agent 暂时用不上的字段。用扩展字段的方式存放而不是直接丢弃。这样将来目标 Agent 支持了这些信息或者需要回溯原始会话时数据还在。原则二区分必须和可选。每个字段标注是否必须。导入时必须字段缺失就报错可选字段缺失就用默认值。这样能快速定位格式问题而不是让 Agent 带着残缺的上下文跑。原则三时间线统一。不同 Agent 的时间戳格式、时区处理可能不一样。中间格式统一用 ISO 8601 带时区的格式并且保留原始时间戳作为附加字段。原则四角色和消息类型标准化。把 user、assistant、system、tool 这些角色统一命名工具调用和工具结果用统一的结构表示。这是最容易被忽视但最重要的一点因为角色映射错了Agent 会把工具结果当成用户输入直接跑偏。2.3 技术栈选择实现语言我选了 Python。原因很直接Claude Code 和 Codex CLI 的会话文件都是 JSON 或 JSONL 格式Python 处理这类数据最顺手而且后续要做摘要和裁剪Python 的生态里有现成的文本处理库。如果你更熟悉 Node.js用 TypeScript 实现也完全没问题逻辑是一样的。依赖方面尽量精简核心只用标准库的json、pathlib、datetime摘要功能可选依赖一个文本处理库。我刻意避免引入重型框架因为这东西是要长期维护的依赖越少越不容易烂。存储上中间格式的会话文件我建议用 JSONL每行一个 JSON 对象而不是单个大 JSON。原因是会话可能很长JSONL 支持流式读写追加新消息也方便不用每次重写整个文件。3. 核心细节解析与实操要点3.1 会话文件的定位与解析不同 Agent 的会话存储位置差别很大这是实操中第一个要解决的问题。Claude Code 的会话数据通常存放在用户目录下的配置目录里按项目路径做哈希分目录每个会话是一个独立的文件。Codex CLI 的存储结构类似但路径规则不同。我的做法是写一个会话发现模块针对每个 Agent 定义它的存储根路径和文件匹配规则扫描出所有会话文件并提取出会话 ID、创建时间、最后修改时间、消息数量等元信息形成一个会话索引。这里有个坑要注意不要硬编码路径。不同操作系统、不同安装方式路径都可能不一样。我的做法是通过环境变量和配置文件双重查找优先读环境变量读不到再查常见路径列表最后才报错提示用户手动指定。解析会话文件时要处理格式版本差异。Agent 更新后会话格式可能会变。我的解析器里加了一个版本检测逻辑遇到不认识的格式版本就给出明确提示而不是默默解析出一堆空数据。3.2 消息角色的映射规则角色映射是转换质量的关键。我整理了一张映射表覆盖了常见的情况。源角色中间格式角色目标角色Claude Code目标角色Codex CLIhuman / useruseruseruserassistant / aiassistantassistantassistantsystemsystemsystemsystemtool_calltool_calltool_usefunction_calltool_resulttool_resulttool_resultfunction_call_output映射时最容易出错的是工具调用和工具结果的配对。一次工具调用会有一个调用 ID工具结果里必须带上对应的 ID否则目标 Agent 无法把结果和调用关联起来。我在转换时会校验这个配对关系发现孤儿调用或孤儿结果就记录下来在导入时做特殊处理。还有一个细节连续同角色消息的合并。有些 Agent 会把连续的多条 assistant 消息分开存有些会合并。中间格式统一按不合并处理导入时再根据目标 Agent 的习惯决定是否合并。这样更灵活。3.3 上下文裁剪与摘要策略这是整个方案里技术含量最高的部分。一个长会话可能有几十万 token直接导入目标 Agent 会超上下文窗口。必须做裁剪。我的策略是分层保留。第一层是系统提示和任务定义这部分永远保留因为它是任务的宪法。第二层是最近 N 轮对话N 根据目标 Agent 的上下文窗口动态计算。比如目标窗口是 200K token我预留 50K 给新生成的内容剩下 150K 里拿出 100K 放最近对话50K 放摘要。第三层是早期对话的摘要。用文本摘要的方式把早期对话压缩成一段话放在最近对话之前。摘要要保留关键决策、已完成的步骤、待解决的问题。第四层是工具调用记录的压缩。工具调用往往很占 token但很多中间过程的调用结果对后续任务没用了。我的做法是只保留最近几次工具调用的完整记录更早的只保留调用了什么工具、结果成功还是失败的简要信息。裁剪的 token 计算我用的是近似估算英文按 4 字符 1 token中文按 1.5 字符 1 token。这个估算不精确但足够用来做裁剪决策。如果你追求精确可以接入目标 Agent 的 tokenizer但会增加复杂度和依赖。3.4 文件状态与工作目录的传递这是最容易被忽视但影响很大的一点。Agent 在会话过程中可能修改了文件、创建了新文件、切换了工作目录。这些状态如果不传递新 Agent 接手后会基于错误的文件状态工作。我的做法是在会话导出时额外记录一份文件状态快照当前工作目录、会话期间被修改过的文件列表、每个文件的修改时间。导入时把这些信息作为一条特殊的 system 消息注入告诉新 Agent 当前工作目录是 X以下文件在之前的会话中被修改过...。注意这里不传递文件内容本身只传递文件路径和修改状态。因为文件内容可能很大而且新 Agent 可以直接读取文件系统。传递状态信息就够了。如果两个 Agent 运行在不同的机器或容器里文件系统不共享那就需要额外做文件同步。这种情况我建议用版本控制工具做中转把修改提交到一个临时分支新 Agent 拉取后再继续。4. 实操过程与核心环节实现4.1 环境准备与目录结构先把项目骨架搭起来。我用的目录结构是这样的session-relay/ ├── adapters/ │ ├── claude_code.py │ ├── codex_cli.py │ └── base.py ├── core/ │ ├── schema.py │ ├── converter.py │ ├── truncator.py │ └── summarizer.py ├── cli.py └── config.yamladapters目录放各个 Agent 的适配器每个适配器负责该 Agent 会话格式的读写。core目录放核心逻辑schema 定义中间格式converter 做格式转换truncator 做裁剪summarizer 做摘要。cli.py是命令行入口。config.yaml放配置比如各 Agent 的存储路径、上下文窗口大小等。配置文件的示例agents: claude_code: session_root: ~/.claude/projects context_window: 200000 reserved_tokens: 50000 codex_cli: session_root: ~/.codex/sessions context_window: 128000 reserved_tokens: 30000 relay: recent_turns: 20 summary_max_tokens: 2000 tool_call_keep_recent: 5这个配置结构的好处是新增一个 Agent 只需要加一段配置和写一个适配器核心逻辑不用动。4.2 中间格式的 schema 定义中间格式我用 Python 的 dataclass 定义清晰且类型安全。核心结构如下from dataclasses import dataclass, field from typing import List, Optional, Dict, Any from datetime import datetime dataclass class Message: role: str # user / assistant / system / tool_call / tool_result content: str timestamp: str tool_call_id: Optional[str] None tool_name: Optional[str] None metadata: Dict[str, Any] field(default_factorydict) dataclass class Session: session_id: str source_agent: str created_at: str updated_at: str working_directory: str messages: List[Message] file_snapshot: List[Dict[str, Any]] field(default_factorylist) extra: Dict[str, Any] field(default_factorydict)extra字段用来存放源 Agent 特有的、中间格式没有对应位置的字段。这样保证信息不丢失将来需要时可以回溯。4.3 Claude Code 会话导出适配器Claude Code 的会话文件是 JSONL 格式每行一条消息。适配器的核心逻辑是逐行读取、解析、转换成中间格式的 Message 对象。import json from pathlib import Path from core.schema import Message, Session class ClaudeCodeAdapter: def __init__(self, session_root: str): self.session_root Path(session_root).expanduser() def list_sessions(self): sessions [] for f in self.session_root.rglob(*.jsonl): stat f.stat() sessions.append({ path: str(f), session_id: f.stem, updated_at: stat.st_mtime, }) return sorted(sessions, keylambda x: x[updated_at], reverseTrue) def export(self, session_path: str) - Session: messages [] with open(session_path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue raw json.loads(line) msg self._convert_message(raw) if msg: messages.append(msg) return Session( session_idPath(session_path).stem, source_agentclaude_code, created_atmessages[0].timestamp if messages else , updated_atmessages[-1].timestamp if messages else , working_directory, messagesmessages, ) def _convert_message(self, raw: dict) - Message: role raw.get(role) or raw.get(type, user) role_map {human: user, ai: assistant} role role_map.get(role, role) content raw.get(content, ) if isinstance(content, list): content self._flatten_content(content) return Message( rolerole, contentcontent, timestampraw.get(timestamp, ), metadata{raw_keys: list(raw.keys())}, ) def _flatten_content(self, blocks: list) - str: parts [] for block in blocks: if isinstance(block, str): parts.append(block) elif isinstance(block, dict): if block.get(type) text: parts.append(block.get(text, )) elif block.get(type) tool_use: parts.append(f[tool_use: {block.get(name)}]) elif block.get(type) tool_result: parts.append(f[tool_result: {block.get(tool_use_id)}]) return \n.join(parts)这里有个实操要点content 字段可能是字符串也可能是数组。Claude Code 的会话里简单消息的 content 是字符串带工具调用的消息 content 是结构化数组。适配器必须两种都处理否则遇到工具调用就崩。4.4 Codex CLI 会话导入适配器导入比导出复杂因为要处理格式差异和上下文裁剪。核心流程是读取中间格式会话 → 裁剪 → 转换成 Codex CLI 格式 → 写入会话文件。class CodexCLIAdapter: def __init__(self, session_root: str, context_window: int, reserved_tokens: int): self.session_root Path(session_root).expanduser() self.context_window context_window self.reserved_tokens reserved_tokens def import_session(self, session: Session, target_project: str) - str: from core.truncator import truncate_session from core.summarizer import summarize_early_messages budget self.context_window - self.reserved_tokens truncated truncate_session(session, budget) summary summarize_early_messages(session, truncated) output_lines [] if summary: output_lines.append(json.dumps({ role: system, content: f[会话接力摘要] {summary}, }, ensure_asciiFalse)) for msg in truncated.messages: output_lines.append(json.dumps( self._to_codex_format(msg), ensure_asciiFalse )) target_dir self.session_root / target_project target_dir.mkdir(parentsTrue, exist_okTrue) target_file target_dir / frelay_{session.session_id}.jsonl with open(target_file, w, encodingutf-8) as f: f.write(\n.join(output_lines)) return str(target_file) def _to_codex_format(self, msg: Message) - dict: role_map { user: user, assistant: assistant, system: system, tool_call: assistant, tool_result: tool, } result { role: role_map.get(msg.role, user), content: msg.content, } if msg.tool_call_id: result[tool_call_id] msg.tool_call_id return result导入时要注意目标目录的创建。Codex CLI 不会自动为接力会话创建目录需要适配器自己处理。另外文件名我加了relay_前缀方便区分哪些是接力来的会话哪些是原生会话。4.5 裁剪器的实现细节裁剪器是核心中的核心我单独说一下实现。def estimate_tokens(text: str) - int: chinese sum(1 for c in text if \u4e00 c \u9fff) other len(text) - chinese return int(chinese / 1.5 other / 4) def truncate_session(session, budget): from core.schema import Session system_msgs [m for m in session.messages if m.role system] other_msgs [m for m in session.messages if m.role ! system] system_tokens sum(estimate_tokens(m.content) for m in system_msgs) remaining budget - system_tokens kept [] used 0 for msg in reversed(other_msgs): t estimate_tokens(msg.content) if used t remaining: break kept.insert(0, msg) used t return Session( session_idsession.session_id, source_agentsession.source_agent, created_atsession.created_at, updated_atsession.updated_at, working_directorysession.working_directory, messagessystem_msgs kept, file_snapshotsession.file_snapshot, )裁剪逻辑是从后往前保留因为最近的消息对当前任务最重要。system 消息永远保留因为它们是任务定义。被裁掉的部分交给摘要器处理。这里有个经验裁剪的边界要落在完整的对话轮次上不要从一轮对话中间切断。一轮对话指的是 user 消息加上它对应的 assistant 回复。如果裁剪边界落在 assistant 消息上说明这轮对话不完整应该往前多裁一条。4.6 摘要器的实现摘要器负责把被裁掉的早期对话压缩成一段话。我用的是基于规则的抽取式摘要而不是调用大模型原因是快、免费、可控。def summarize_early_messages(full_session, truncated_session): kept_ids {id(m) for m in truncated_session.messages} dropped [m for m in full_session.messages if id(m) not in kept_ids] if not dropped: return key_points [] for msg in dropped: if msg.role user: text msg.content.strip() if len(text) 100: text text[:100] ... key_points.append(f用户提出{text}) elif msg.role assistant and len(msg.content) 200: key_points.append(f助手给出方案{msg.content[:150]}...) if len(key_points) 15: key_points key_points[:5] [...中间省略...] key_points[-5:] return 早期对话要点\n \n.join(key_points)抽取式摘要的规则是用户消息保留前 100 字助手的长回复保留前 150 字中间太多就省略。这样能保留关键决策点又不至于太长。如果你追求更好的摘要质量可以接入大模型做生成式摘要。但要注意生成式摘要会引入额外的 API 调用成本和延迟而且摘要质量不稳定。我的建议是先用抽取式觉得不够再升级。5. 常见问题与排查技巧实录5.1 导入后 Agent 不认上下文这是最常见的问题。表现是新 Agent 接手后完全无视之前的对话从头开始问需求。排查思路分三步。第一步查角色映射确认导入后的会话里user 和 assistant 的角色没有搞反。如果搞反了Agent 会把之前的助手回复当成用户输入自然就乱了。第二步查消息顺序确认时间线是递增的没有乱序。有些 Agent 对消息顺序敏感乱序会导致解析失败。第三步查 system 消息确认任务定义类的 system 消息被正确保留和放置。system 消息如果被当成普通消息处理Agent 就接收不到任务约束。我踩过的一个坑是Codex CLI 对 system 消息的位置有要求必须放在最前面。我一开始把摘要 system 消息放在了中间结果 Codex 直接忽略了它。后来改成所有 system 消息前置问题解决。5.2 工具调用配对失败表现是导入后 Agent 报错说找不到对应的工具调用或工具结果。原因是工具调用的 ID 在转换过程中丢失或改变了。排查时重点看tool_call_id 字段是否在转换前后保持一致。我的做法是在转换器里加一个校验步骤遍历所有消息检查每个 tool_result 是否都能找到对应的 tool_call反之亦然。发现不配对就记录警告并在导入时把孤儿消息转成普通文本消息避免 Agent 报错。还有一个隐蔽的坑不同 Agent 的工具调用 ID 格式不一样。有的用 UUID有的用递增数字。转换时不要试图翻译ID直接原样保留只要保证配对关系不断就行。5.3 上下文还是超限明明做了裁剪导入后还是报上下文超限。这种情况通常是token 估算不准导致的。我的估算公式是英文 4 字符 1 token、中文 1.5 字符 1 token但实际 tokenizer 的切分更复杂代码、特殊符号、多语言混合的文本估算误差可能到 20%。解决办法是留足安全余量我一般按估算值的 80% 来用也就是估算出来 100K token实际只放 80K 的内容。另一个原因是目标 Agent 的上下文窗口配置不对。有些 Agent 的实际可用窗口比标称的小因为要预留输出空间。我的配置里reserved_tokens就是干这个的一般留 30% 到 40% 给输出。5.4 会话文件写入后 Agent 读不到导入适配器写入了文件但 Agent 启动后看不到这个会话。排查方向是文件路径和命名规则。不同 Agent 对会话文件的命名和存放位置有严格要求。比如有的要求文件名必须是特定格式的 UUID有的要求放在特定哈希目录下。我的做法是先用 Agent 自己创建一个原生会话观察它生成的文件路径和命名然后照着这个规则来写接力会话。还有一个原因是文件权限。如果适配器以某个用户身份运行写出的文件权限不对Agent 进程读不到。检查文件权限确保和原生会话文件一致。5.5 常见问题速查表问题现象可能原因排查方法解决方案Agent 无视历史上下文角色映射错误检查导入后消息的 role 字段修正角色映射表报错找不到工具调用tool_call_id 丢失对比转换前后的 ID保留原始 ID校验配对上下文超限token 估算不准用目标 tokenizer 复核留 20% 安全余量Agent 读不到会话路径或命名不符对比原生会话文件照原生规则命名摘要丢失关键信息抽取规则太激进检查被裁消息调整抽取阈值文件状态不对未传递工作目录检查 file_snapshot注入状态 system 消息5.6 几个独家避坑技巧技巧一先做单向验证。不要一上来就做双向接力先把 Claude Code 到 Codex CLI 这一个方向跑通验证整个链路没问题再扩展其他方向。这样出问题时排查范围小。技巧二保留原始会话备份。转换和导入过程中永远不要修改或删除原始会话文件。所有操作都在副本上进行。我见过有人转换失败把原始会话搞坏了欲哭无泪。技巧三加一个 dry-run 模式。导入前先跑一遍 dry-run只做转换和裁剪输出统计信息消息数、估算 token 数、被裁消息数不实际写入。确认没问题再真正导入。技巧四会话 ID 加时间戳。接力生成的会话 ID 里带上时间戳比如relay_20250101_143022_abc123。这样多个接力会话不会互相覆盖也方便追溯。技巧五定期清理接力会话。接力会话会越积越多占磁盘空间。写个清理脚本定期删除超过一定天数的接力会话。但注意别误删原生会话。6. 扩展方向与进阶玩法6.1 支持更多 Agent当前方案支持 Claude Code 和 Codex CLI扩展到其他 Agent 只需要写一个适配器。适配器要实现两个方法export把该 Agent 的会话转成中间格式import_session把中间格式转成该 Agent 的会话。核心的转换、裁剪、摘要逻辑完全复用。新增 Agent 时重点搞清楚三件事会话文件存在哪、格式长什么样、有什么特殊要求。前两件通过观察原生会话就能搞清楚第三件需要查文档或试错。6.2 自动接力现在是手动触发接力进阶玩法是自动接力。监控当前 Agent 的 token 使用量接近上下文窗口上限时自动导出会话、裁剪、导入到备用 Agent并提示用户切换。这样长任务可以一直跑下去不用人盯着。自动接力的难点是判断接力的时机。太早接力浪费太晚接力上下文已经丢了。我的经验是设置在窗口使用率达到 80% 时触发留 20% 的缓冲。6.3 会话版本管理把接力会话纳入版本管理每次接力生成一个版本记录接力的时间、源 Agent、目标 Agent、裁剪策略。这样可以回溯整个任务的演进过程也方便对比不同 Agent 在同一任务上的表现。实现上可以用 Git 管理会话文件每次接力提交一次。会话文件是文本格式Git 能很好地做 diff 和版本追踪。6.4 团队共享会话把中间格式的会话文件放到共享存储上团队成员可以互相接力。A 用 Claude Code 做到一半导出成中间格式上传B 下载后导入到自己的 Codex CLI 继续做。这样团队协作时工具选择不再是个人的事而是可以灵活切换。这里要注意敏感信息处理。会话里可能包含 API key、密码、内部路径等信息。共享前要做脱敏把敏感信息替换成占位符。我写了一个简单的脱敏规则匹配常见的敏感信息模式自动替换。6.5 会话质量分析接力会话积累多了可以做质量分析。比如统计不同 Agent 在同类任务上的表现分析哪些任务适合哪个 Agent为后续的 Agent 选择提供数据支撑。这个方向偏数据科学但基础数据就是接力过程中产生的会话记录。分析维度可以包括任务完成率、平均对话轮次、工具调用次数、用户干预次数等。这些指标能客观反映 Agent 的能力边界。7. 我个人的一些实操体会这套东西我从有想法到跑通前后折腾了大概两周。中间踩的坑比预想的多但跑通之后确实省事。现在我的工作流是复杂重构用 Claude Code 起头做到上下文快满了就接力到 Codex CLI 继续Codex 额度用完了再接力回来。整个过程不用重复讲需求任务连续性很好。有几个体会比较深。第一中间格式的设计值得多花时间。我一开始图快中间格式设计得很简陋结果扩展新 Agent 时发现信息不够用又回头重构。如果一开始就设计得完整一些后面会省很多事。第二裁剪策略要保守。宁可多留一些上下文也不要裁得太狠。裁太狠导致 Agent 理解不了任务比上下文超限更麻烦。第三测试要覆盖边界情况。空会话、单条消息的会话、全是工具调用的会话这些边界情况我都遇到过处理不好就崩。最后分享一个小技巧如果你只是想快速验证接力效果不用完整实现所有功能先写一个最简单的版本——把源会话的消息原样读出来按目标格式写进去不做裁剪和摘要。跑通这个最小闭环再逐步加功能。这样能快速看到效果也更容易定位问题。这套方案不是银弹它解决的是特定场景下的特定问题。如果你的任务都很短一个 Agent 就能搞定那没必要折腾接力。但如果你经常做长任务、经常在多个 Agent 之间切换那这套东西能实实在在提升效率。工具是为人服务的选择适合自己的就好。
1. 为什么需要跨 CLI 编程 Agent 的会话接力1.1 一个真实到让人抓狂的场景我平时写代码有个习惯终端里同时开着好几个 AI 编程助手。Claude Code 用来做架构梳理和长上下文重构Codex CLI 用来跑一些需要快速迭代的小脚本偶尔还会切到别的 CLI Agent 处理特定任务。问题就出在切这个动作上——每个 CLI Agent 都有自己的会话上下文你在 Claude Code 里聊了半小时的需求背景切到 Codex 就得从头再讲一遍。更别提有时候一个 Agent 的额度用完了想换另一个继续干上下文直接断档那种感觉就像写了一半的文档突然断电还没保存。这个痛点其实非常普遍。现在做 AI 编程的人手里基本都不止一个 CLI Agent。Claude Code 的强项是理解复杂代码库、做多文件重构Codex CLI 在代码生成和快速验证上很顺手还有一些团队自研的 Agent 或者基于开源框架搭的 CLI 工具各有各的适用场景。但它们的会话状态是彼此隔离的没有一个通用的接力棒机制。所谓会话接力说白了就是Agent A 干到一半把当前的对话历史、任务状态、关键上下文打包交给 Agent B 继续干B 能无缝接上不需要人肉复述。这件事听起来简单做起来要解决三个核心问题——会话怎么导出、格式怎么统一、导入后怎么让新 Agent 理解之前的进度。1.2 会话接力的核心价值在哪里先想清楚为什么要做这件事不然容易陷入为了折腾而折腾的陷阱。第一是成本优化。不同 Agent 的计费模型不一样有的按 token 计费有的包月有的有免费额度。一个长任务如果全程用最贵的那个跑成本会很难看。会话接力让你可以在任务的不同阶段选择性价比最高的 Agent。比如前期需求梳理用便宜的核心代码生成用贵的测试用例补充再切回便宜的。第二是能力互补。没有哪个 Agent 在所有任务上都最强。Claude Code 对大型代码库的理解确实好但有时候 Codex 生成的代码更符合某些语言的惯用法。会话接力让你能集各家之所长而不是被单一工具绑死。第三是容错和连续性。Agent 服务偶尔会抽风网络会断额度会用完。如果会话能接力这些都不是问题——换个 Agent 接着干就行任务不会因为工具的问题而中断。第四是团队协作。团队里不同人可能偏好不同的 Agent如果会话能标准化导出和导入那 A 用 Claude Code 做到一半B 可以用 Codex 接着做交接成本大幅降低。1.3 这件事的难度到底在哪很多人第一反应是不就是把聊天记录复制过去吗实际做起来会发现远没那么简单。格式差异是第一个坎。Claude Code 的会话存储格式和 Codex CLI 完全不同字段名、嵌套结构、元数据都不一样。你不能简单地把 JSON 从一个格式映射到另一个格式因为有些信息在源格式里有在目标格式里根本没有对应的位置。上下文窗口是第二个坎。一个跑了很久的会话token 数量可能远超目标 Agent 的上下文窗口。你不可能把全部历史都塞进去必须做摘要和裁剪但裁哪些、留哪些直接决定了接力后 Agent 能不能理解任务。状态语义是第三个坎。会话里不只有对话还有工具调用记录、文件修改历史、当前工作目录状态等。这些隐式状态如果不传递新 Agent 接手后会一脸懵。工具链差异是第四个坎。不同 Agent 支持的工具集不一样Claude Code 能调用的工具和 Codex CLI 能调用的工具未必重合。接力时如果历史里有目标 Agent 不支持的工具调用需要做转换或降级处理。搞清楚了这些难点后面的方案设计就有了方向。2. 整体方案设计与技术选型思路2.1 三种可行路线对比做会话接力业界目前大致有三条路线各有优劣我逐一分析一下。路线一中间格式转换。定义一个通用的会话中间格式类似会话交换格式每个 Agent 的会话先导出成这个中间格式再从中间格式导入到目标 Agent。优点是扩展性好新增一个 Agent 只需要写一对导入导出适配器缺点是中间格式的设计很难做到既通用又不丢信息容易变成最小公倍数式的信息阉割。路线二直接点对点转换。针对每一对 Agent 写专门的转换逻辑。优点是转换质量高可以针对性地处理两个格式之间的差异缺点是组合爆炸N 个 Agent 需要 N×(N-1) 个转换器维护成本高。路线三代理层拦截。在 Agent 和它的后端服务之间加一个代理层拦截所有请求和响应在代理层做会话的持久化和转换。优点是透明Agent 本身不需要改缺点是实现复杂而且涉及网络请求的拦截和重放稳定性和安全性都要仔细考虑。我最终选择的是路线一为主、路线二为辅的混合方案。核心用中间格式做通用转换但对于 Claude Code 和 Codex CLI 这两对高频组合额外做一些针对性的优化处理。这样既保证了扩展性又在关键路径上不牺牲质量。2.2 中间格式的设计原则中间格式是整个方案的地基设计得好不好直接决定成败。我遵循了四条原则。原则一保留原始信息不做有损压缩。中间格式里要完整保留源会话的所有信息包括那些目标 Agent 暂时用不上的字段。用扩展字段的方式存放而不是直接丢弃。这样将来目标 Agent 支持了这些信息或者需要回溯原始会话时数据还在。原则二区分必须和可选。每个字段标注是否必须。导入时必须字段缺失就报错可选字段缺失就用默认值。这样能快速定位格式问题而不是让 Agent 带着残缺的上下文跑。原则三时间线统一。不同 Agent 的时间戳格式、时区处理可能不一样。中间格式统一用 ISO 8601 带时区的格式并且保留原始时间戳作为附加字段。原则四角色和消息类型标准化。把 user、assistant、system、tool 这些角色统一命名工具调用和工具结果用统一的结构表示。这是最容易被忽视但最重要的一点因为角色映射错了Agent 会把工具结果当成用户输入直接跑偏。2.3 技术栈选择实现语言我选了 Python。原因很直接Claude Code 和 Codex CLI 的会话文件都是 JSON 或 JSONL 格式Python 处理这类数据最顺手而且后续要做摘要和裁剪Python 的生态里有现成的文本处理库。如果你更熟悉 Node.js用 TypeScript 实现也完全没问题逻辑是一样的。依赖方面尽量精简核心只用标准库的json、pathlib、datetime摘要功能可选依赖一个文本处理库。我刻意避免引入重型框架因为这东西是要长期维护的依赖越少越不容易烂。存储上中间格式的会话文件我建议用 JSONL每行一个 JSON 对象而不是单个大 JSON。原因是会话可能很长JSONL 支持流式读写追加新消息也方便不用每次重写整个文件。3. 核心细节解析与实操要点3.1 会话文件的定位与解析不同 Agent 的会话存储位置差别很大这是实操中第一个要解决的问题。Claude Code 的会话数据通常存放在用户目录下的配置目录里按项目路径做哈希分目录每个会话是一个独立的文件。Codex CLI 的存储结构类似但路径规则不同。我的做法是写一个会话发现模块针对每个 Agent 定义它的存储根路径和文件匹配规则扫描出所有会话文件并提取出会话 ID、创建时间、最后修改时间、消息数量等元信息形成一个会话索引。这里有个坑要注意不要硬编码路径。不同操作系统、不同安装方式路径都可能不一样。我的做法是通过环境变量和配置文件双重查找优先读环境变量读不到再查常见路径列表最后才报错提示用户手动指定。解析会话文件时要处理格式版本差异。Agent 更新后会话格式可能会变。我的解析器里加了一个版本检测逻辑遇到不认识的格式版本就给出明确提示而不是默默解析出一堆空数据。3.2 消息角色的映射规则角色映射是转换质量的关键。我整理了一张映射表覆盖了常见的情况。源角色中间格式角色目标角色Claude Code目标角色Codex CLIhuman / useruseruseruserassistant / aiassistantassistantassistantsystemsystemsystemsystemtool_calltool_calltool_usefunction_calltool_resulttool_resulttool_resultfunction_call_output映射时最容易出错的是工具调用和工具结果的配对。一次工具调用会有一个调用 ID工具结果里必须带上对应的 ID否则目标 Agent 无法把结果和调用关联起来。我在转换时会校验这个配对关系发现孤儿调用或孤儿结果就记录下来在导入时做特殊处理。还有一个细节连续同角色消息的合并。有些 Agent 会把连续的多条 assistant 消息分开存有些会合并。中间格式统一按不合并处理导入时再根据目标 Agent 的习惯决定是否合并。这样更灵活。3.3 上下文裁剪与摘要策略这是整个方案里技术含量最高的部分。一个长会话可能有几十万 token直接导入目标 Agent 会超上下文窗口。必须做裁剪。我的策略是分层保留。第一层是系统提示和任务定义这部分永远保留因为它是任务的宪法。第二层是最近 N 轮对话N 根据目标 Agent 的上下文窗口动态计算。比如目标窗口是 200K token我预留 50K 给新生成的内容剩下 150K 里拿出 100K 放最近对话50K 放摘要。第三层是早期对话的摘要。用文本摘要的方式把早期对话压缩成一段话放在最近对话之前。摘要要保留关键决策、已完成的步骤、待解决的问题。第四层是工具调用记录的压缩。工具调用往往很占 token但很多中间过程的调用结果对后续任务没用了。我的做法是只保留最近几次工具调用的完整记录更早的只保留调用了什么工具、结果成功还是失败的简要信息。裁剪的 token 计算我用的是近似估算英文按 4 字符 1 token中文按 1.5 字符 1 token。这个估算不精确但足够用来做裁剪决策。如果你追求精确可以接入目标 Agent 的 tokenizer但会增加复杂度和依赖。3.4 文件状态与工作目录的传递这是最容易被忽视但影响很大的一点。Agent 在会话过程中可能修改了文件、创建了新文件、切换了工作目录。这些状态如果不传递新 Agent 接手后会基于错误的文件状态工作。我的做法是在会话导出时额外记录一份文件状态快照当前工作目录、会话期间被修改过的文件列表、每个文件的修改时间。导入时把这些信息作为一条特殊的 system 消息注入告诉新 Agent 当前工作目录是 X以下文件在之前的会话中被修改过...。注意这里不传递文件内容本身只传递文件路径和修改状态。因为文件内容可能很大而且新 Agent 可以直接读取文件系统。传递状态信息就够了。如果两个 Agent 运行在不同的机器或容器里文件系统不共享那就需要额外做文件同步。这种情况我建议用版本控制工具做中转把修改提交到一个临时分支新 Agent 拉取后再继续。4. 实操过程与核心环节实现4.1 环境准备与目录结构先把项目骨架搭起来。我用的目录结构是这样的session-relay/ ├── adapters/ │ ├── claude_code.py │ ├── codex_cli.py │ └── base.py ├── core/ │ ├── schema.py │ ├── converter.py │ ├── truncator.py │ └── summarizer.py ├── cli.py └── config.yamladapters目录放各个 Agent 的适配器每个适配器负责该 Agent 会话格式的读写。core目录放核心逻辑schema 定义中间格式converter 做格式转换truncator 做裁剪summarizer 做摘要。cli.py是命令行入口。config.yaml放配置比如各 Agent 的存储路径、上下文窗口大小等。配置文件的示例agents: claude_code: session_root: ~/.claude/projects context_window: 200000 reserved_tokens: 50000 codex_cli: session_root: ~/.codex/sessions context_window: 128000 reserved_tokens: 30000 relay: recent_turns: 20 summary_max_tokens: 2000 tool_call_keep_recent: 5这个配置结构的好处是新增一个 Agent 只需要加一段配置和写一个适配器核心逻辑不用动。4.2 中间格式的 schema 定义中间格式我用 Python 的 dataclass 定义清晰且类型安全。核心结构如下from dataclasses import dataclass, field from typing import List, Optional, Dict, Any from datetime import datetime dataclass class Message: role: str # user / assistant / system / tool_call / tool_result content: str timestamp: str tool_call_id: Optional[str] None tool_name: Optional[str] None metadata: Dict[str, Any] field(default_factorydict) dataclass class Session: session_id: str source_agent: str created_at: str updated_at: str working_directory: str messages: List[Message] file_snapshot: List[Dict[str, Any]] field(default_factorylist) extra: Dict[str, Any] field(default_factorydict)extra字段用来存放源 Agent 特有的、中间格式没有对应位置的字段。这样保证信息不丢失将来需要时可以回溯。4.3 Claude Code 会话导出适配器Claude Code 的会话文件是 JSONL 格式每行一条消息。适配器的核心逻辑是逐行读取、解析、转换成中间格式的 Message 对象。import json from pathlib import Path from core.schema import Message, Session class ClaudeCodeAdapter: def __init__(self, session_root: str): self.session_root Path(session_root).expanduser() def list_sessions(self): sessions [] for f in self.session_root.rglob(*.jsonl): stat f.stat() sessions.append({ path: str(f), session_id: f.stem, updated_at: stat.st_mtime, }) return sorted(sessions, keylambda x: x[updated_at], reverseTrue) def export(self, session_path: str) - Session: messages [] with open(session_path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue raw json.loads(line) msg self._convert_message(raw) if msg: messages.append(msg) return Session( session_idPath(session_path).stem, source_agentclaude_code, created_atmessages[0].timestamp if messages else , updated_atmessages[-1].timestamp if messages else , working_directory, messagesmessages, ) def _convert_message(self, raw: dict) - Message: role raw.get(role) or raw.get(type, user) role_map {human: user, ai: assistant} role role_map.get(role, role) content raw.get(content, ) if isinstance(content, list): content self._flatten_content(content) return Message( rolerole, contentcontent, timestampraw.get(timestamp, ), metadata{raw_keys: list(raw.keys())}, ) def _flatten_content(self, blocks: list) - str: parts [] for block in blocks: if isinstance(block, str): parts.append(block) elif isinstance(block, dict): if block.get(type) text: parts.append(block.get(text, )) elif block.get(type) tool_use: parts.append(f[tool_use: {block.get(name)}]) elif block.get(type) tool_result: parts.append(f[tool_result: {block.get(tool_use_id)}]) return \n.join(parts)这里有个实操要点content 字段可能是字符串也可能是数组。Claude Code 的会话里简单消息的 content 是字符串带工具调用的消息 content 是结构化数组。适配器必须两种都处理否则遇到工具调用就崩。4.4 Codex CLI 会话导入适配器导入比导出复杂因为要处理格式差异和上下文裁剪。核心流程是读取中间格式会话 → 裁剪 → 转换成 Codex CLI 格式 → 写入会话文件。class CodexCLIAdapter: def __init__(self, session_root: str, context_window: int, reserved_tokens: int): self.session_root Path(session_root).expanduser() self.context_window context_window self.reserved_tokens reserved_tokens def import_session(self, session: Session, target_project: str) - str: from core.truncator import truncate_session from core.summarizer import summarize_early_messages budget self.context_window - self.reserved_tokens truncated truncate_session(session, budget) summary summarize_early_messages(session, truncated) output_lines [] if summary: output_lines.append(json.dumps({ role: system, content: f[会话接力摘要] {summary}, }, ensure_asciiFalse)) for msg in truncated.messages: output_lines.append(json.dumps( self._to_codex_format(msg), ensure_asciiFalse )) target_dir self.session_root / target_project target_dir.mkdir(parentsTrue, exist_okTrue) target_file target_dir / frelay_{session.session_id}.jsonl with open(target_file, w, encodingutf-8) as f: f.write(\n.join(output_lines)) return str(target_file) def _to_codex_format(self, msg: Message) - dict: role_map { user: user, assistant: assistant, system: system, tool_call: assistant, tool_result: tool, } result { role: role_map.get(msg.role, user), content: msg.content, } if msg.tool_call_id: result[tool_call_id] msg.tool_call_id return result导入时要注意目标目录的创建。Codex CLI 不会自动为接力会话创建目录需要适配器自己处理。另外文件名我加了relay_前缀方便区分哪些是接力来的会话哪些是原生会话。4.5 裁剪器的实现细节裁剪器是核心中的核心我单独说一下实现。def estimate_tokens(text: str) - int: chinese sum(1 for c in text if \u4e00 c \u9fff) other len(text) - chinese return int(chinese / 1.5 other / 4) def truncate_session(session, budget): from core.schema import Session system_msgs [m for m in session.messages if m.role system] other_msgs [m for m in session.messages if m.role ! system] system_tokens sum(estimate_tokens(m.content) for m in system_msgs) remaining budget - system_tokens kept [] used 0 for msg in reversed(other_msgs): t estimate_tokens(msg.content) if used t remaining: break kept.insert(0, msg) used t return Session( session_idsession.session_id, source_agentsession.source_agent, created_atsession.created_at, updated_atsession.updated_at, working_directorysession.working_directory, messagessystem_msgs kept, file_snapshotsession.file_snapshot, )裁剪逻辑是从后往前保留因为最近的消息对当前任务最重要。system 消息永远保留因为它们是任务定义。被裁掉的部分交给摘要器处理。这里有个经验裁剪的边界要落在完整的对话轮次上不要从一轮对话中间切断。一轮对话指的是 user 消息加上它对应的 assistant 回复。如果裁剪边界落在 assistant 消息上说明这轮对话不完整应该往前多裁一条。4.6 摘要器的实现摘要器负责把被裁掉的早期对话压缩成一段话。我用的是基于规则的抽取式摘要而不是调用大模型原因是快、免费、可控。def summarize_early_messages(full_session, truncated_session): kept_ids {id(m) for m in truncated_session.messages} dropped [m for m in full_session.messages if id(m) not in kept_ids] if not dropped: return key_points [] for msg in dropped: if msg.role user: text msg.content.strip() if len(text) 100: text text[:100] ... key_points.append(f用户提出{text}) elif msg.role assistant and len(msg.content) 200: key_points.append(f助手给出方案{msg.content[:150]}...) if len(key_points) 15: key_points key_points[:5] [...中间省略...] key_points[-5:] return 早期对话要点\n \n.join(key_points)抽取式摘要的规则是用户消息保留前 100 字助手的长回复保留前 150 字中间太多就省略。这样能保留关键决策点又不至于太长。如果你追求更好的摘要质量可以接入大模型做生成式摘要。但要注意生成式摘要会引入额外的 API 调用成本和延迟而且摘要质量不稳定。我的建议是先用抽取式觉得不够再升级。5. 常见问题与排查技巧实录5.1 导入后 Agent 不认上下文这是最常见的问题。表现是新 Agent 接手后完全无视之前的对话从头开始问需求。排查思路分三步。第一步查角色映射确认导入后的会话里user 和 assistant 的角色没有搞反。如果搞反了Agent 会把之前的助手回复当成用户输入自然就乱了。第二步查消息顺序确认时间线是递增的没有乱序。有些 Agent 对消息顺序敏感乱序会导致解析失败。第三步查 system 消息确认任务定义类的 system 消息被正确保留和放置。system 消息如果被当成普通消息处理Agent 就接收不到任务约束。我踩过的一个坑是Codex CLI 对 system 消息的位置有要求必须放在最前面。我一开始把摘要 system 消息放在了中间结果 Codex 直接忽略了它。后来改成所有 system 消息前置问题解决。5.2 工具调用配对失败表现是导入后 Agent 报错说找不到对应的工具调用或工具结果。原因是工具调用的 ID 在转换过程中丢失或改变了。排查时重点看tool_call_id 字段是否在转换前后保持一致。我的做法是在转换器里加一个校验步骤遍历所有消息检查每个 tool_result 是否都能找到对应的 tool_call反之亦然。发现不配对就记录警告并在导入时把孤儿消息转成普通文本消息避免 Agent 报错。还有一个隐蔽的坑不同 Agent 的工具调用 ID 格式不一样。有的用 UUID有的用递增数字。转换时不要试图翻译ID直接原样保留只要保证配对关系不断就行。5.3 上下文还是超限明明做了裁剪导入后还是报上下文超限。这种情况通常是token 估算不准导致的。我的估算公式是英文 4 字符 1 token、中文 1.5 字符 1 token但实际 tokenizer 的切分更复杂代码、特殊符号、多语言混合的文本估算误差可能到 20%。解决办法是留足安全余量我一般按估算值的 80% 来用也就是估算出来 100K token实际只放 80K 的内容。另一个原因是目标 Agent 的上下文窗口配置不对。有些 Agent 的实际可用窗口比标称的小因为要预留输出空间。我的配置里reserved_tokens就是干这个的一般留 30% 到 40% 给输出。5.4 会话文件写入后 Agent 读不到导入适配器写入了文件但 Agent 启动后看不到这个会话。排查方向是文件路径和命名规则。不同 Agent 对会话文件的命名和存放位置有严格要求。比如有的要求文件名必须是特定格式的 UUID有的要求放在特定哈希目录下。我的做法是先用 Agent 自己创建一个原生会话观察它生成的文件路径和命名然后照着这个规则来写接力会话。还有一个原因是文件权限。如果适配器以某个用户身份运行写出的文件权限不对Agent 进程读不到。检查文件权限确保和原生会话文件一致。5.5 常见问题速查表问题现象可能原因排查方法解决方案Agent 无视历史上下文角色映射错误检查导入后消息的 role 字段修正角色映射表报错找不到工具调用tool_call_id 丢失对比转换前后的 ID保留原始 ID校验配对上下文超限token 估算不准用目标 tokenizer 复核留 20% 安全余量Agent 读不到会话路径或命名不符对比原生会话文件照原生规则命名摘要丢失关键信息抽取规则太激进检查被裁消息调整抽取阈值文件状态不对未传递工作目录检查 file_snapshot注入状态 system 消息5.6 几个独家避坑技巧技巧一先做单向验证。不要一上来就做双向接力先把 Claude Code 到 Codex CLI 这一个方向跑通验证整个链路没问题再扩展其他方向。这样出问题时排查范围小。技巧二保留原始会话备份。转换和导入过程中永远不要修改或删除原始会话文件。所有操作都在副本上进行。我见过有人转换失败把原始会话搞坏了欲哭无泪。技巧三加一个 dry-run 模式。导入前先跑一遍 dry-run只做转换和裁剪输出统计信息消息数、估算 token 数、被裁消息数不实际写入。确认没问题再真正导入。技巧四会话 ID 加时间戳。接力生成的会话 ID 里带上时间戳比如relay_20250101_143022_abc123。这样多个接力会话不会互相覆盖也方便追溯。技巧五定期清理接力会话。接力会话会越积越多占磁盘空间。写个清理脚本定期删除超过一定天数的接力会话。但注意别误删原生会话。6. 扩展方向与进阶玩法6.1 支持更多 Agent当前方案支持 Claude Code 和 Codex CLI扩展到其他 Agent 只需要写一个适配器。适配器要实现两个方法export把该 Agent 的会话转成中间格式import_session把中间格式转成该 Agent 的会话。核心的转换、裁剪、摘要逻辑完全复用。新增 Agent 时重点搞清楚三件事会话文件存在哪、格式长什么样、有什么特殊要求。前两件通过观察原生会话就能搞清楚第三件需要查文档或试错。6.2 自动接力现在是手动触发接力进阶玩法是自动接力。监控当前 Agent 的 token 使用量接近上下文窗口上限时自动导出会话、裁剪、导入到备用 Agent并提示用户切换。这样长任务可以一直跑下去不用人盯着。自动接力的难点是判断接力的时机。太早接力浪费太晚接力上下文已经丢了。我的经验是设置在窗口使用率达到 80% 时触发留 20% 的缓冲。6.3 会话版本管理把接力会话纳入版本管理每次接力生成一个版本记录接力的时间、源 Agent、目标 Agent、裁剪策略。这样可以回溯整个任务的演进过程也方便对比不同 Agent 在同一任务上的表现。实现上可以用 Git 管理会话文件每次接力提交一次。会话文件是文本格式Git 能很好地做 diff 和版本追踪。6.4 团队共享会话把中间格式的会话文件放到共享存储上团队成员可以互相接力。A 用 Claude Code 做到一半导出成中间格式上传B 下载后导入到自己的 Codex CLI 继续做。这样团队协作时工具选择不再是个人的事而是可以灵活切换。这里要注意敏感信息处理。会话里可能包含 API key、密码、内部路径等信息。共享前要做脱敏把敏感信息替换成占位符。我写了一个简单的脱敏规则匹配常见的敏感信息模式自动替换。6.5 会话质量分析接力会话积累多了可以做质量分析。比如统计不同 Agent 在同类任务上的表现分析哪些任务适合哪个 Agent为后续的 Agent 选择提供数据支撑。这个方向偏数据科学但基础数据就是接力过程中产生的会话记录。分析维度可以包括任务完成率、平均对话轮次、工具调用次数、用户干预次数等。这些指标能客观反映 Agent 的能力边界。7. 我个人的一些实操体会这套东西我从有想法到跑通前后折腾了大概两周。中间踩的坑比预想的多但跑通之后确实省事。现在我的工作流是复杂重构用 Claude Code 起头做到上下文快满了就接力到 Codex CLI 继续Codex 额度用完了再接力回来。整个过程不用重复讲需求任务连续性很好。有几个体会比较深。第一中间格式的设计值得多花时间。我一开始图快中间格式设计得很简陋结果扩展新 Agent 时发现信息不够用又回头重构。如果一开始就设计得完整一些后面会省很多事。第二裁剪策略要保守。宁可多留一些上下文也不要裁得太狠。裁太狠导致 Agent 理解不了任务比上下文超限更麻烦。第三测试要覆盖边界情况。空会话、单条消息的会话、全是工具调用的会话这些边界情况我都遇到过处理不好就崩。最后分享一个小技巧如果你只是想快速验证接力效果不用完整实现所有功能先写一个最简单的版本——把源会话的消息原样读出来按目标格式写进去不做裁剪和摘要。跑通这个最小闭环再逐步加功能。这样能快速看到效果也更容易定位问题。这套方案不是银弹它解决的是特定场景下的特定问题。如果你的任务都很短一个 Agent 就能搞定那没必要折腾接力。但如果你经常做长任务、经常在多个 Agent 之间切换那这套东西能实实在在提升效率。工具是为人服务的选择适合自己的就好。
