ChatGPT、Codex实战：主任务还在跑，又想继续提问怎么办？Side Chat为什么比硬塞上下文更稳

使用Codex做长任务时经常会遇到一种非常典型的场景主任务还在运行。比如帮我定位这个接口偶发超时的问题修改代码并跑完相关测试。Codex已经开始读取Repository ↓ 分析调用链 ↓ 检查日志 ↓ 修改代码 ↓ 运行测试这时候你突然又想到一个问题顺便帮我看看这个模块为什么不用Redis或者这个异常是不是和上个月的数据库改动有关甚至只是你刚才为什么决定改这个文件很多人的第一反应是直接继续往当前Thread里发消息。看起来只是补充一句话。但长任务里这种“小问题”很容易变成Context Pollution。Codex现在已经提供/side以及/btw来开启临时Side Chat。官方定义很明确Side Chat会从当前对话创建一个临时分支拥有独立Transcript同时不会切走主对话在Side Chat里仍然能够看到Parent Chat是否还在运行。(developers.openai.com)所以Side Chat真正解决的并不只是主任务运行时也能问问题。它解决的是一个更重要的Agent工程问题Context Routing。一、长任务最怕的不是Context少而是Context越来越“不纯”假设主任务目标非常清楚Goal 修复登录接口偶发401Codex当前已经建立了一条推理链401 ↓ Token Refresh ↓ Cookie ↓ Session ↓ 测试这时候你突然问顺便分析一下整个认证架构有没有必要重构。新问题虽然和认证有关但任务层级已经完全不同。原任务是Bug Fix。新问题是Architecture Review。如果直接塞进主Thread当前上下文就从Find Root Cause ↓ Fix ↓ Verify扩展成Find Root Cause Architecture Design Long-term Refactor Current Fix结果很可能出现一个问题Agent开始重新解释Goal。原本只需要修Bug最后变成既然认证体系存在结构问题我顺便重构一下。这就是典型的Goal Drift。二、上下文污染并不一定表现成“忘记东西”很多人理解Context Pollution会认为信息太多以后模型把前面忘了。实际上更常见的问题不是忘记。而是Context里同时存在多个竞争目标。例如Goal A 修复Bug然后加入Question B 为什么这个架构这样设计继续加入Question C 如果改成Redis会不会更好再加入Question D 顺便检查一下安全问题。最后Context变成Bug Fix Architecture Redis Security每个问题单独都合理。组合起来以后Agent却需要不断判断当前到底哪个目标优先这会增加Decision Noise。三、Side Chat真正做的是把“临时问题”从主任务里切出去官方现在对/side的描述是开启一个临时分支用来做Focused Follow-up而不打断Main Chat Transcript。(developers.openai.com)使用方式非常简单/side或者直接/side 这个方案有没有明显风险Codex会创建一个独立Side Chat。关键点在于Side Chat拥有自己的Transcript。也就是说主任务Main Thread ↓ Bug Investigation ↓ Code Change ↓ Tests旁边可以出现Side Chat ↓ Architecture Question两条Context不需要完全混在一起。这就是Context Isolation。四、为什么Side Chat不是普通“新开一个聊天”乍一看既然要隔离为什么不直接/new因为Side Chat和New Thread解决的问题不同。官方现在的CLI行为里/new会创建一个新的Chat/fork会复制当前Chat形成新的独立Chat而/side是从当前Chat创建一个临时的、Ephemeral Fork完成Focused Detour后再回到Parent Chat。(developers.openai.com)可以简单理解成/new New Task/fork Alternative Path/side Temporary Question这三个动作的语义完全不同。五、什么时候应该使用Side Chat最典型的第一类就是1. 解释当前决策主Agent正在工作修改 auth/session.ts你突然想知道为什么你改的是Session而不是Token Refresh这个问题和当前任务高度相关但它并不应该改变任务Goal。非常适合/side 为什么选择修改Session而不是Refresh Token主任务继续Execute ↓ TestSide Chat负责Explain Decision两者互不干扰。六、第二类临时技术问题例如主任务正在修支付Bug你突然看到Promise.all()想问这里如果有一个Promise失败其他任务会怎样这属于Knowledge Question。它可能帮助你理解代码但并不是当前Task必须执行的步骤。如果直接放主ThreadAgent可能开始分析Promise检查其他调用甚至顺手重构。而Side Chat可以让它停留在Explain Only。七、第三类风险确认主任务已经给出一个方案Migration ↓ New Schema你想问这个方案会不会存在数据回滚风险这种问题非常适合Side Chat。因为你的真实意图是检查当前计划。而不是立刻修改当前计划。Side Chat先回答Risk Analysis如果最后发现风险确实成立再把结论带回Main Thread。这个过程比Main Thread ↓ 突然插入风险问题 ↓ Agent自动重规划更加可控。八、第四类读代码但不希望影响执行方向比如主任务完成订单模块的Feature。执行过程中你看到pricing-engine/突然想知道这个Pricing Engine历史上为什么拆成单独模块这是一个Exploration Question。非常适合Side Chat。因为它可能需要读取更多文件但不应该让主任务自动扩大Scope。九、什么时候不要用Side ChatSide Chat并不是所有Follow-up都应该使用。第一种不适合真正改变Goal。例如原任务修复支付Bug。你现在决定不修了直接重构整个Payment Service。这已经不是Side Question。而是Goal Change。应该回Main Thread明确告诉AgentStop current plan. New goal: Refactor payment service.或者直接开新Thread。十、真正改变Execution的指令应该进入Main Thread例如不要修改数据库。停止当前测试。只修改backend。新增一个Acceptance Criterion。这些内容都会直接改变Execution Boundary所以应该进入Main Context。因为主Agent接下来必须持续记住它。如果这种规则只存在Side ChatMain Thread未必会把它当作新的长期执行约束。所以可以记住Temporary Question → Side ChatPersistent Instruction → Main Thread十一、什么时候应该直接New Thread如果问题已经形成一个完整的新任务不要Side。例如主任务修复认证Bug你突然想到顺便重新设计一下整个权限系统。这不是临时问题。应该/new permission redesign原因是新任务会拥有自己的GoalScopeFilesVerificationDecision History。如果硬塞在Side Chat里Side Chat自己也会越来越长最终又出现Side Context Pollution。十二、什么时候应该Fork而不是Side还有一种情况你不是想问一个问题。而是想探索另一个方案。例如主Agent选择方案A 修改Cache Strategy你想同时试方案B 数据库层解决这种情况更适合/fork官方现在的/fork会复制当前Chat到一个新的Chat ID保留原Transcript然后你可以并行探索另一个方向。(developers.openai.com)所以Side Ask而Fork Explore Alternative这是非常重要的区别。十三、可以把四种动作理解成Context Routing以后碰到一个新想法可以先判断它属于什么。类型1当前任务需要永久记住例如不能修改Database。使用Main Thread类型2只是问一下例如为什么这里使用Queue使用Side Chat类型3形成了新的独立任务例如单独分析一下Queue性能。使用New Thread类型4想尝试另一条执行路线例如同一个Bug换另一套方案试试。使用Fork最终就是New Input ↓ Does it change current execution?如果Yes → Main如果No继续问Just a question? → Side如果是新任务→ New如果是Alternative Path→ Fork这就是一套非常实用的Context Router。十四、Side Chat为什么特别适合长任务OpenAI对Codex App的定位已经非常明确现在的Agent越来越能够处理复杂、长时间运行的任务开发者也开始同时监督多个Agent和多个Thread。(openai.com)任务持续时间越长人产生临时问题的概率就越高。假设一个任务只运行30秒用户大概率等它结束再问。但如果任务运行30分钟甚至更久中途自然会不断产生新的问题新的想法新的怀疑。如果这些内容全部进入Main Thread长任务Context会持续膨胀。所以Side Chat本质上就是为Long-running Collaboration提供的一种Context分流机制。十五、为什么官方还在持续优化Side Chat可见性近期Codex更新里OpenAI还专门改进了线程运行过程中Side Chat和Queued Prompt的可见性。(developers.openai.com)另外Codex移动端也已经支持从选中的Transcript文字直接发起Side Chat并支持/side prompt直接带初始问题开启Side Conversation。(developers.openai.com)这其实说明主Agent持续执行时用户“边看边问”的交互正在变成一个越来越重要的工作模式。未来人与Agent的协作不会只是Send Prompt ↓ Wait ↓ Get Result而更接近Agent Running ↓ Human Observing ↓ Side Questions ↓ Agent Continues十六、Main Thread应该尽量保持什么内容一个稳定Main Thread最好主要保留四类信息。Goal最终要解决什么Constraint什么不能做Execution Decision当前准备怎么做Verification怎样判断完成也就是Goal ↓ Boundary ↓ Plan ↓ Evidence其他临时问题能不进入主Context就不要全部塞进去。这样主Agent始终比较容易回答我现在到底在完成什么十七、Side Chat真正减少的是Decision Noise假设Main Context里有100条消息。其中80条都直接服务于Task。20条只是解释假设随手问题技术讨论。Agent每次继续Reasoning都需要在这些信息之间重新判断哪些是Instruction哪些只是Question哪些仍然有效。这就是Decision Noise。如果Side Chat把其中20条切出去Main Thread会更接近Signal而不是Signal Noise这和我们之前讲的Context Engineering本质上是一回事不是让Agent看到最多信息而是让它看到最相关的信息。十八、但Side Chat也不能无限开Side Chat本身虽然是临时Context但如果使用过度人自己也会开始混乱。例如Side A RedisSide B SecuritySide C ArchitectureSide D Tests最后你会发现真正关键的Decision散落在多个Side Chat里。所以一个Side问题结束以后如果它产生了影响Main Task的重要结论应该把结论重新带回Main Thread。例如Side Chat得出当前方案会破坏Backward Compatibility。那么Main Thread应该明确补充New Constraint: 必须保持Backward Compatibility。这叫Promote Conclusion。十九、Side Chat最关键的技巧带回结论不带回整段讨论这是一个非常实用的原则。不要把Side Chat几十轮内容全部复制回主线程。只需要带回Decision Constraint Evidence例如Side Chat讨论了半天RedisDatabaseConsistencyCache。最后结论只有暂时不引入Redis因为当前Bug和Cache无关。Main Thread只需要知道Decision: No Redis change.而不需要重新塞回所有分析过程。所以Side Exploration ↓ Compressed Decision ↓ Main Thread比Side Exploration ↓ Copy Everything ↓ Main Thread稳定很多。二十、可以建立一个简单的Side Chat使用规则以后主任务运行时出现一个新问题先问三个问题。1. 这个信息会改变当前Execution吗会Main Thread2. 只是为了理解当前任务吗是Side Chat3. 它已经可以独立成为一个Task吗是New Thread / Fork可以记成Change Execution → Main Explain / Explore → Side New Goal → New Alternative Execution → Fork二十一、一个真实例子假设Main Task修复订单接口性能问题。Codex正在执行Analyze ↓ DB Query ↓ Index ↓ Benchmark这时候你连续想到4个问题。问题1不允许改变API返回结构。这是Constraint。应该Main问题2为什么这个Query没有使用已有Cache只是理解问题。应该Side问题3单独研究一下整个Cache设计有没有问题。已经是独立任务。应该New问题4保留当前Index方案但同时试一下Query Rewrite。这是Alternative Path。应该Fork四个输入看起来都和当前任务有关。但它们实际上应该进入四条不同的Context Path。二十二、Side Chat反映的是Agent协作方式正在变化早期AI协作One Chat One Everything所有内容都塞在一个Conversation。但Agent开始处理更长任务以后这种模式很难继续扩展。更合理的结构正在变成Project ↓ Main Thread ├── Side Question ├── Side Question ├── Fork └── New Task也就是说Conversation开始出现Topology。不同Context承担不同职责。这已经不只是Chat UI设计。而是在形成一种新的Agent Work Structure。最后Codex主任务还在跑时真正的问题不是我还能不能继续发消息而是这条新消息应该进入哪一条Context如果所有内容都进入Main Thread任务会越来越容易出现Goal DriftContext PollutionDecision NoiseScope Expansion。Side Chat真正有价值的地方是让Main Task继续保持Goal Boundary Execution Verification而把Explanation Temporary Question Risk Exploration放到独立Context里。官方现在的/side就是围绕这个场景设计它创建一个独立的临时Transcript同时保留Parent Chat运行状态让用户可以在主任务继续工作的同时进行Focused Detour。(developers.openai.com)所以真正成熟的Codex使用方式不应该是所有问题都问同一个Thread。而应该逐渐建立Context Routing。可以最终记住这四句话改变任务 → Main 临时提问 → Side 新的任务 → New 另一条路线 → Fork当任务越来越长、Agent越来越自主以后真正决定稳定性的已经不只是Context Window有多大。而是你有没有把正确的信息送进正确的Context。这才是Side Chat比“继续硬塞上下文”更值得使用的真正原因。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的AI会员订阅渠道。