会话机制：多任务并行的核心能力

为什么这是 Qoder 的核心优势

Qoder 最大的差异化能力之一，就是多会话同时进行编码。

对比同类工具：Trae 和 CodeBuddy 都只支持单一会话，切换任务时必须中断当前对话，之前的上下文全部丢失。而 Qoder 采用 Tab 机制管理会话，你可以同时打开多个会话并行处理不同任务，每个会话的上下文完全独立：

• 会话 A： 正在重构支付模块
• 会话 B： 审查同事的 Pull Request
• 会话 C： 研究某个开源库的源码

会话之间互不干扰，各自独立保存上下文。在大型项目中，你不再需要因为切换任务而损失当前对话的上下文状态——这是 Qoder 在多任务并行上最实在的效率提升。

会话输入框的几个关键配置

每个会话底部都有一个输入框，旁边提供了几个直接影响会话行为的配置项。

模式选择

输入框旁边有一个模式切换器，支持三种模式：

• Ask 模式（纯问答）：AI 只回答问题，不修改代码。适合快速提问、理解代码、查找资料
• Agent 模式（智能体）：AI 可以读文件、搜代码、执行终端命令、修改文件。适合大多数开发任务
• 专家团模式（多角色协同）：多个 AI Agent 分工协作，适合架构重构等复杂任务

模型选择

可以选择当前会话使用的模型。支持内置的各家模型，也可以通过配置接入第三方的 CodePlan 等私有部署服务。切换模型后，当前会话后续的对话全部使用新模型，不影响其他会话。

上下文窗口设置

模型右侧可以调整上下文窗口大小：

• 默认 20K：大多数日常任务够用
• 手动调大（如 100K）：处理大型重构、跨工程修改时需要更大上下文，效果更好，但 token 消耗也更快

原则是：上下文越长，AI 对项目整体的理解越完整，输出质量越高。 但上下文越长，每次请求的 token 消耗也越大，需要根据任务复杂度权衡。

上下文压缩

在会话右下角有一个压缩按钮，作用是对当前会话的上下文做"瘦身"——把冗余的历史信息压缩成精炼的结构化摘要，同时保留关键上下文。

当你发现对话轮次较多、AI 响应变慢或开始遗漏早期信息时，使用上下文压缩可以恢复会话的健康状态，而不需要启动一个全新的会话。

什么时候启动新会话

当你发现一个问题在对话中反复绕、AI 开始"忘记"早期约定的内容、或者上下文已经明显膨胀时，就是启动新会话的信号。

正确的做法不是继续在旧会话里追问，而是让当前会话生成一份问题总结，然后带着这份总结启动新会话。

实战经验：开发与测试分离

以我自己的习惯为例，代码编写和测试是两个不同领域的工作，不要混在一个会话里。我通常的做法是开两个会话并行：

• 会话 A（开发）：专注编写功能代码
• 会话 B（测试）：把开发好的代码发给 AI，让它编写测试并执行

当测试发现问题时，直接把测试失败的信息粘贴到会话 A，让它在开发上下文中修复代码。修复后回到会话 B 重新测试。

这样两个会话各司其职，各自的上下文都保持专注和聚焦。开发会话不会因为测试的讨论而膨胀，测试会话也不会被开发逻辑干扰。

千万不要在一个会话里持续输入不同类型的任务。 比如在同一会话里先写代码、再调样式、再写测试、再看日志——上下文会迅速膨胀到不可控的程度，AI 的响应质量急剧下降。这时候你花在等待和纠错上的时间，远超启动一个新会话的成本。

小技巧：让 AI 帮你总结上下文，无缝衔接

你不需要自己手动写总结。直接告诉 AI：

「请帮我重新整理当前的问题，保留问题背景、说明、当前进度、遇到的难点等信息，总结为一个文档。我要新启动一个会话继续处理。」

AI 会基于对话历史自动生成一份结构化总结，内容包括：

• 背景：这个任务的来龙去脉
• 当前进度：已经完成了哪些工作
• 遇到的难点：卡在了什么地方，尝试了哪些方案未果
• 下一步计划：建议的解决方向

把这份总结保存到项目里，在新会话中引用它，AI 就能快速恢复上下文，从断点处继续工作。

实战经验：这个技巧的关键是不要等到上下文完全爆炸才行动。我通常在以下时机主动触发总结：

• 一个问题经过 5-8 轮对话还在反复讨论
• 发现 AI 开始引用早期的错误约定（上下文腐化的信号）
• 当前问题的复杂度超出了最初预期，需要重新规划

早一步总结，比晚一步总结效果好得多——AI 的记忆还新鲜，总结更精准。

启动新会话的收益

• 注意力聚焦：这是最容易被忽略的优势。Transformer 架构的自注意力机制（Self-Attention）需要在上下文窗口内对每个 token 与其他所有 token 做注意力计算。上下文越长，模型的"注意力预算"越分散——原本应该聚焦在你的核心问题上，却被分配去关注 50 轮前的闲聊、过时的代码片段或已废弃的方案。新会话让模型从零开始，注意力 100% 集中在当前任务上，响应质量显著提升。
• 上下文干净：旧会话的上下文被"压缩"为一份精炼的结构化文档，关键信息无损保留，冗余信息被剔除。
• Token 消耗大幅降低：所有历史不再重复发送，运行速度明显提升。

同样的 token 预算，用一个干净的新会话解决一个聚焦的问题，远比在一个膨胀的旧会话里反复拉扯高效。这也是很多资深用户的习惯——不惧怕启动新会话，懂得及时做上下文压缩。

理解上下文

前面介绍了会话怎么用、什么时候用，这些经验背后都指向同一个核心概念——上下文。理解它，你才算真正懂了会话机制。

什么是上下文

上下文（Context） 指的是当前会话中 AI 能看到的所有信息。包括：

• 你发的每一条消息
• AI 回复的每一段代码和文字
• AI 每次搜索代码、读取文件、执行命令的结果
• AI 已经修改过的文件内容

所有这些内容累积在一起，构成了 AI 理解当前任务的"记忆"。每次你发送新消息，AI 都会把整个上下文重新读一遍——不仅仅是新消息，而是从对话开始到现在所有的内容。

所以上下文越长，AI 知道的信息越多，但消耗的 token 也越多、响应也越慢。这就是为什么管理好上下文是高效使用 Qoder 的关键技能。

会话的底层逻辑：上下文隔离

从设计角度来说，会话的核心价值在于上下文隔离。

每次对话的上下文都会持续增长——你发的每一条消息、AI 回复的每一段代码、每一次工具调用结果，全部累积在会话中。随着上下文增长，会出现两个问题：

1. 上下文腐化（Context Rot）：Anthropic 的研究表明，随着上下文中的 token 增多，模型的注意力预算被分散，准确回忆早期信息的能力反而下降。越聊到后面，AI 越容易"遗忘"前面的关键约定。
2. Token 消耗剧增：每次请求都要把整个历史重新发送给模型，LLM 还需要将每个 token 与其他所有 token 做逐一比对，成本随上下文长度呈二次方增长。一个聊了 50 轮的会话，token 消耗可能是新会话的 10 倍甚至更高，而实际有效信息可能只占 10%。

所以正确的使用方式是：一个会话只解决一个具体问题。 当问题边界清晰、上下文可控时，AI 的响应质量最高、消耗最低。

压缩机制的背后原理与潜在问题

前面提到了上下文压缩按钮，但压缩并不是"无损"的——每种压缩方式都有它的代价。理解下面的压缩策略和它们各自的风险，能帮你做出更好的判断。

以下内容来自微软 Agent Framework 的设计分析，它定义了 5 种压缩策略：

1. 滑动窗口（SlidingWindowCompactionStrategy）

保留最近 N 轮对话，丢弃更早的内容。

options.AddStrategy<SlidingWindowCompactionStrategy>(o => {
    o.WindowSize = 10;          // 保留最近 10 轮
    o.KeepFirstMessage = true;  // 保留第一条系统消息
});

• 潜在问题：窗口大小难以确定。设小了会过早丢弃早期的关键约定，设大了压缩效果不明显。而且早期做出的架构决策如果被丢弃，后续 AI 可能"反悔"或偏离方向。

2. LLM 摘要（SummarizationCompactionStrategy）

使用 LLM 自己将历史对话总结为一段摘要，用摘要替换原始对话。

options.AddStrategy<SummarizationCompactionStrategy>(o => {
    o.SummaryPrompt = "请总结以下对话的核心内容";
});

• 潜在问题：这是信息保留效果最好的策略，但也是成本最高的——需要额外一次 LLM 调用。摘要的质量取决于模型本身，如果模型总结时遗漏了关键细节（比如某个接口签名、某条配置路径），后续工作就会出错。越长的对话，摘要损失的信息越多。

3. 裁剪已完成消息（TrimCompletionCompactionStrategy）

删除已经被处理完成的工具调用消息，只保留最终结果。

• 潜在问题：丢失了中间状态。如果需要回溯"AI 是怎么得出这个结论的"，中间的工具调用日志已经不可见了。调试问题时尤其麻烦。

4. 合并相似消息（MapCompactionStrategy）

将连续的相似消息合并为一条。

• 潜在问题：合并会丢失消息边界。多条系统指令合并后，AI 可能无法区分每一条指令的生效范围，导致执行顺序错乱。

5. 只保留最新消息（LatestMessageCompactionStrategy）

只保留最新的一条或多条消息，其余全部丢弃。

• 潜在问题：这是压缩最激进的策略。完全丢失历史上下文，AI 对任务的背景理解归零。只适合无状态的简单查询，不适合任何需要持续上下文的开发任务。

总结：在 Agent 框架层面，这些压缩策略通常会组合使用——先用滑动窗口丢弃太旧的内容，再对保留范围内的消息做摘要。但无论哪种组合，信息的损失都是不可避免的。这也是为什么我强调与其依赖压缩，不如主动拆分会话——压缩是事后补救，拆分是事前预防。