Manus Branch 的巧思：让同一份上下文长出多条路

Manus Branch 最值得拆的地方，不是它给聊天产品补了一个「复制会话」按钮。Manus 的定位本来就不是只回答问题，而是一个能执行任务、自动化工作流的 action engine。1 对这类产品来说，用户真正舍不得丢的不是聊天记录本身，而是聊天里慢慢攒出来的理解：指令、文件、项目背景、口吻、阶段性结论，以及哪些路已经试过。

Branch 把这份理解当成一个可以继续使用的对象。官方博客的说法很直接：从任意一条历史消息点 Branch，Manus 会打开一个继承此前指令、文件和完整历史的平行 session；原 session 保持不变，新分支可以把同一个起点带到另一条路上。2

很多 AI 工具把「长上下文」理解成一条越来越长的线。Manus Branch 的判断更接近版本控制：上下文不是越堆越好，上下文应该能在某个稳定节点上分叉。

普通聊天里，用户一旦和 AI 共同走过一段复杂任务，后面的选择会变得很尴尬。

继续在同一条线里问，新的方向会把原来的任务搅进去。另开一条新对话，又要重新上传文件、复述背景、解释目标。复制粘贴看起来能救急，实际会丢掉很多细节：哪些限制是硬的，哪些方案已经被否掉，用户为什么更偏向某个口吻。

AI 研究里已经有人把这个问题叫作 context pollution。ContextBranch 论文把线性对话的困境说得很清楚：继续原对话会让探索内容污染上下文，重新开始又会丢掉已经建立的背景。论文提出的 primitives 也是 checkpoint、branch、switch、inject 这一组近似版本控制的动作。3

Manus Branch 的巧思，是把这个研究问题压成了一个普通用户能理解的动作：从这里分出去。

官方博客列出的继承范围很具体：新分支会带走 branch point 之前的 instructions、uploaded files 和 full conversation history；原对话不被删除、不被改写；同一个消息点可以反复分出多条路。2 这让上下文的身份变了。上下文不再是越用越脏的一段聊天，而像一份已经整理过的项目材料，可以被不同输出反复调用。

会议纪要的例子最容易看出差别。同一份会议记录，可能要变成团队待办、经理汇报和下周评审的 slide outline。普通做法是在一条对话里连续要求三个版本，模型会在「待办」「汇报」「幻灯片」之间来回混线。Manus 的做法是从会议纪要完成的节点开三条分支，每条分支只服务一个输出，会议记录本身作为共同起点留在每条分支里。2

这个设计反常识的地方在于，Manus 没有鼓励用户把所有东西交给一个越来越全能的 agent。Branch 承认 agent 也需要干净的工作面。把同一份上下文拆给多条分支，不是降低自动化程度，而是让自动化更少互相干扰。

Branch 容易被误解成「复制一个历史对话」。如果只是复制，产品价值并不大。真正的设计点在于隔离。

Manus 写得很明确：每个 branch 都有一份 isolated copy of the context，不同方向不会 bleed into each other；新 session 还会有「Branched from」breadcrumb，方便用户知道它从哪里开始。2 这两个小设计合在一起，解决的是同一个问题：探索需要自由，但自由不能把主线弄乱。

很多 AI 产品在处理分叉需求时，会把分叉藏在 prompt 里。用户会说「给我三个方案」「分别从 A/B/C 三个角度写」。模型确实能一次吐出三个版本，但三个版本往往共享同一个输出节奏，也很难继续深入。用户想追问第二个方案时，第一和第三个方案还留在上下文里，后续回答会被它们牵扯。

Branch 把「三个方案」从一条回答里的三段文字，变成三条可以继续工作的路线。路线一可以做投资人 brief，路线二可以做内部分析，主线还可以继续收集市场研究资料。官方博客把这种模式叫 running-record pattern：主 session 像一份持续增长的项目日志，具体交付物从当前节点分出去做，主线继续保留完整记忆。2

这个隔离层也给用户留了责任边界。Branch 目前只支持 standard Manus chat sessions，不支持 Web Builder sessions。2 这条限制看似只是功能范围，实际说明 Manus 没有把所有高风险生成场景都塞进同一套分支逻辑。普通任务和可运行网站构建的状态不同，后者可能牵涉代码、预览、发布和依赖，分叉带来的合并与回退问题更复杂。

Branch 的代价也在这里。分支越多，用户越需要理解自己站在哪一条线里。Manus 用 breadcrumb 帮用户追溯来源，但没有自动替用户决定哪条分支该成为主线。这个留白是合理的：AI 可以复用上下文，AI 不该替用户悄悄合并判断。

Manus Branch 给 AI 产品的启发，不是每个聊天框都要加一个树状导航。更稳的原则是：当用户已经和 AI 共同建立了一份复杂理解时，产品要把这份理解做成可保存、可分叉、可回到原点的对象。

这个原则可以迁移到很多场景。研究工具里，一份资料库可以分出「写报告」「做演示」「列待办」三条路。设计工具里，一个产品 brief 可以分出不同视觉方向。代码工具里，一个修复方案可以分出保守补丁和重构方案。重点不是多线程本身，而是每条线程都从同一个可信上下文出发，同时不污染其它线程。

Manus Branch 也提醒产品设计师，长上下文不是万能解法。上下文窗口越长，越容易把旧的尝试、废掉的方案和临时口吻都带进来。真正有用的长上下文，应该能被切开、命名、追溯和隔离。

Manus Branch 最有意思的地方在这里：它没有把 agent 做成一个永远往前滚的聊天黑洞，而是在一条对话里加了「从这里另走一路」的出口。AI 产品想让用户放心交给它更多工作，不能只靠更大的上下文窗口。用户还要知道，已经攒下来的理解不会被浪费，新的尝试也不会把原来的判断弄脏。