T3 Code 中途换模型：哪些上下文会带过去，怎样接着做

一个任务做到一半，想换另一个模型继续。T3 Code 里的旧消息还看得到，新 Agent 却重新找文件、问已经回答过的问题，甚至没接上刚才失败的测试。

先查当前请求实际带了哪些历史，以及关键文件和附件是否能取得。聊天窗口保存了记录，并不意味着新提供方收到了每条记录、每个工具结果和原来的运行状态。对于较长对话，T3 Code 会按可用空间选择历史；最重要的要求值得在切换后的第一条消息里重申。

本文主要处理跨提供方切换时的上下文交接，也涉及采用同类交接方式的会话重启与部分 Fork。它不把同一提供方里的每次模型或参数调整都当成重建会话。依据是 2026 年 11 月 9 日查阅的 T3 Code v0.1.7 正式版，当天最新正式版查询仍返回此版本。

聊天记录、交接历史和运行状态，分别是什么

官方 Portable handoffs 说明描述了三种会转交对话背景的场景：切换提供方、通过可迁移方式重启会话，以及提供方无法原生续接的 Fork。

短对话在额度足够时可以完整转交。长对话优先考虑最近的请求与回答、最初的请求，以及相关活动文字。被选中的消息保留完整文字、先后顺序和用户／助手角色，失败或中断轮次中的部分工作也可以成为交接材料。

内容	交接时怎样处理	接手后怎样核对
已保存的聊天与活动记录	留作可查历史，首轮不一定全发	缺具体事实时，按相关轮次或记录继续读取
被选中的历史消息	按原顺序转交完整文字，并标明来源	检查旧约束、已做修改和结果是否被理解
当前新请求	与历史分开，不为塞入历史而缩短	把必须遵守的要求写清楚，保持请求精简
部分活动文字，如命令结果	可参与历史选择，长条目可能未入选	缺报错细节时回读对应结果
原提供方的内部推理、工具调用状态	不通过这种文字交接复制	检查仍在运行的命令或后台工作
旧消息中的附件	附件本体不随历史交接复制	需要时重新附上，或确认新 Agent 能读到文件

这套交接是选择已有记录，不是先让一个模型重写整篇摘要。文件变化记录也不等于文件内容；看到“修改过 src/export.ts”，仍需要读取当前文件，才能知道代码实际变成了什么。

工作目录是另一个需要核对的对象。尤其在 Fork、新线程或远程机器之间切换时，先确认路径和分支，具体见 T3 Code 的线程与 Worktree 选择。有了正确的任务背景，也仍可能站在错误的目录里。

历史为什么没有全部进入下一轮

模型的可用空间还要容纳当前请求、附件、指令、工具和后续工作。T3 Code 的历史选择与预算实现因此同时限制交接额度和目标会话剩余空间。

v0.1.7 的初始历史额度默认是 16,000，服务端可用 T3CODE_CONTEXT_HANDOFF_TOKEN_CAP 调整。这个设置只控制交接历史的上限，不能增大模型本身的上下文窗口。该版本保守地按 UTF-8 字节估计文本占用，并计入来源说明和 JSON 转义；模型实际分词与最终账单需要另外核对。

如果没有可用的模型容量信息，代码使用 128,000 的窗口回退值。它是估计时的假设，不能证明自定义模型或当前服务真的提供这么大的窗口。已有上下文、图片和其他附件也会压缩能留给历史的位置。

因此，不建议遇到接力失败就先把历史上限调大。先检查具体错误、目标模型的实际容量和本轮附件，再决定要减少什么。上下文超限说明解释了这些输入如何共同占用空间。

一个离线样例：长日志被跳过，短消息保持原文

我们从正式版源码提取原始选择函数，用五条合成记录做了检查，没有发送模型请求：

合成历史项	在该样例中的选择结果
最初的 CSV 导出目标	保留完整文字
较早的文件位置回复	保留完整文字
一条超过历史额度的长命令日志	未入选，记录其条目标识
最近的继续请求	保留完整文字
最近的失败用例说明	保留完整文字

默认额度下，四条短消息按原顺序保留，长日志整条未入选，没有被改写成一段新摘要。去掉长日志再运行时，四条消息全部保留。这个结果只验证选择函数的行为；它没有验证真实提供方接收、附件重发或线程回读的完整流程。

官方文档说明，交接会带上省略历史的查找线索，Agent 可以用 T3 的线程读取工具继续取已保存消息和活动，包括长条目的后续部分。需要旧报错时，可以要求它定位那一条结果；没必要把整份构建日志再次粘进当前请求。

切换后的第一条消息，先让它核对这几件事

先保存实际任务进度：目标、不能改的行为、当前文件、已经做过的验证和下一步。原 Agent 给出的交接说明要与文件及执行记录对照，不能仅凭一句“都完成了”往下走。

随后在 T3 的模型／提供方选择中切到目标连接，发送一条范围清楚的继续请求。例如，把下面占位内容替换成你自己的事实：

继续当前任务，先只读核对，不修改文件或重复执行写操作。

目标与验收：<要解决的问题，以及怎样算完成>
必须保留：<接口、行为、已否决方案及原因>
当前工作区：<运行机器、目录、分支和提交>
已有改动：<文件与具体内容；未跟踪文件另列>
验证状态：<实际执行的命令、结果，以及尚未验证的部分>
附件与后台工作：<需要读取的文件；仍在运行或状态不明的任务>

请先核对相关文件和所需历史，说明：
1. 目前已经确认了什么。
2. 哪条信息仍缺失，需要从哪里取得。
3. 下一步最小动作是什么，怎样判断它成功。

缺少的信息标为待确认，不要凭旧摘要补造执行结果。

这段内容是给接手 Agent 的任务说明，不是 T3 配置文件。重点是让它先找到当前代码、真实验证结果和一个明确的下一步。

如果只是“忘记刚才的要求”，文件仍然正确，不必先恢复检查点。确实需要撤销代码时，再按对话回退与文件恢复说明选择范围，避免把仍要保留的修改一起撤掉。

继续失败时，按现象分开处理

能回复，但说不清先前结论。 选一个具体缺失项，例如失败用例名或禁止修改的字段，让 Agent 回读对应记录并核对文件。合理重读一个函数很正常；反复从仓库根目录重新搜同样的信息，才需要继续检查交接内容。

需要旧截图，却只知道附件名称。 确认附件本体已经附到这次请求，或者目标 Agent 有权限读取指定文件。不要把聊天里仍有缩略图当成新模型已经看到了图片，也不要为方便重发而把私有素材上传到公开地址。

提示 Insufficient context allowance 或输入过长。 v0.1.7 的用户说明称：目标会话空间不足时，T3 会尝试新建提供方会话，以受限历史自动继续当前请求；若新会话连当前请求和附件都放不下，需要缩短本轮输入或选择经确认容量更大的模型。当前请求不会被悄悄裁短来迁就历史。实际提供方仍可能拒绝输入，自动恢复也不是所有错误都适用。

Issue #23142是一个旧 nightly、Factory Droid／Cursor 场景的容量报告，后续有另一位使用者补充相似现象，维护者回复则明确说缺少对应环境，未完成验证。截至查阅日仍为 Open。本文采用正式版当前文档与代码解释预算，不把报告中的倍数估计或早期行为当成所有模型的现状。

切换等待时，还有后台任务在跑。 官方交接说明明确说，恢复会保留运行中的后台工作。先等它完成，或者在知道影响的前提下停止，再重试交接。不要只因新 Agent 没接住对话，就重新执行一次迁移、部署或其他有副作用的命令。

切换很慢。 记录版本、历史体量和具体等待阶段，不能仅凭“记录很长”就认定模型慢。Issue #23820讨论的是历史选择器对注定放不下的日志仍做序列化的开销；对应 PR #23821于 11 月 8 日合并，但本文核对的 v0.1.7 标签仍没有这条提前跳过逻辑。作者的局部耗时测量不能代表整个切换过程，本文也没有做切换速度测试。

怎样判断这次真的接上了

接手 Agent 能指出当前改动、仍未通过的验证、必须保留的约束，并完成约定的下一步，才说明任务继续得对。只会复述旧消息，或者只返回一次模型回答，都不足以完成这项验收。

使用 Nbility 时，可以按接入基础确认新连接的地址、协议与模型，再核对实际请求记录。请求记录用于确认调用；上下文是否齐全，仍要看 T3 的交接材料与后续行为。若要核对切换后的用量，继续看 T3 Usage 与账单范围，不要把界面历史条数直接换算成 Token 或费用。

把最关键的要求放进当前请求，把可查事实留在文件与记录里，再让新 Agent 从一个明确动作继续。这样即使历史只选了一部分，你也能看清缺了什么、该从哪里补。