使用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：
修复登录接口偶发401

Codex当前已经建立了一条推理链：

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
↓
Test

Side Chat负责：

Explain Decision

两者互不干扰。

---

六、第二类：临时技术问题

例如主任务正在：

修支付Bug

你突然看到：

Promise.all()

想问：

这里如果有一个Promise失败，其他任务会怎样？

这属于：

Knowledge Question。

它可能帮助你理解代码，

但并不是当前Task必须执行的步骤。

如果直接放主Thread，

Agent可能开始：

分析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 Chat？

Side Chat并不是所有Follow-up都应该使用。

第一种不适合：

真正改变Goal。

例如原任务：

修复支付Bug。

你现在决定：

不修了，直接重构整个Payment Service。

这已经不是Side Question。

而是：

Goal Change。

应该回Main Thread明确告诉Agent：

Stop current plan.
New goal:
Refactor payment service.

或者直接开新Thread。

---

十、真正改变Execution的指令，应该进入Main Thread

例如：

不要修改数据库。

停止当前测试。

只修改backend。

新增一个Acceptance Criterion。

这些内容都会直接改变：

Execution Boundary

所以应该进入：

Main Context。

因为主Agent接下来必须持续记住它。

如果这种规则只存在Side Chat，

Main Thread未必会把它当作新的长期执行约束。

所以可以记住：

Temporary Question
→ Side Chat

Persistent Instruction
→ Main Thread

---

十一、什么时候应该直接New Thread？

如果问题已经形成一个完整的新任务，

不要Side。

例如主任务：

修复认证Bug

你突然想到：

顺便重新设计一下整个权限系统。

这不是临时问题。

应该：

/new permission redesign

原因是新任务会拥有自己的：

Goal；

Scope；

Files；

Verification；

Decision 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
Redis

Side B
Security

Side C
Architecture

Side 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讨论了半天：

Redis；

Database；

Consistency；

Cache。

最后结论只有：

暂时不引入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 Thread

---

2. 只是为了理解当前任务吗？

是：

Side Chat

---

3. 它已经可以独立成为一个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 Drift；

Context Pollution；

Decision Noise；

Scope 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会员订阅渠道。