前言
在codex和cc中，agent会主动调用subagent去进行任务分配，这样的操作在一定程度上可以减轻编码时长时间带来的负面影响
比如最经典的上下文窗口爆炸，本质不是你的模型不好，而且对话、思考带来的负面影响
- 探索的错误
- 临时意见
- tools的输出
- “我突然有个想法”等等
但是在Pi中原生没有subagent没有繁杂的调度处理，上下文虽然可以用compact进行压缩，但是会有精度的损失。
我们该如何更好的管理上下文和处理复杂任务的出错情况呢？开发者给了我们tree命令
关于结构
首先你要知道，在codex和cc中对话通常是一个时间线，你可以理解成是一个直线把对话串联起来了，但是Pi不一样，他是一个树结构
结构大概类似
- 每个消息都有一个id和parentId
- 你在的位置是一个活动位置
/tree允许你把这个位置移动到其他的位置
所以你也许可以想到了，我可以在一个很长的对话中，通过该命令转到一个也许是错误的发生点上
所以我们可以拥有一个树
- 主线
- 探索
- 回归
- 检查
- 等等
那你也许可能会说，这样的话，ai在这么大的树里面搜索，上下文还会爆炸。所以开发者对这个进行了限制：llm只能看见当前所在树枝上的上下文
也许用过的人还会知道另一个命令是fork，这两个还是有点区别的
tree vs fork
简单来说
/tree针对于一个对话文件/fork是从一个位置新创一个对话文件
所以我在日常使用中时，如果想在一个对话中工作或者是创建临时分支时我会使用tree，如果我想把一个临时的想法转成一个长期的任务时会用frok
tree的作用
最大的作用是，你用/tree去交换分支，pi可以选择性的帮你总结分支并且进行下去
这样的好处是如果有一些部分是错误的，你可以不抛弃前面的上下文，而是直接利用新分支进行继续，这样会减少很多繁琐的内容。
举个简单的例子
A├─ B ─ C ─ D└─ E ─ F这是你目前的样子，你从D到F
- 你有A的上下文
- BCD被你遗弃
- 你可以选择是否把BCD部分总结下来
理论上来说，这样的新分支会比原来的错误分支更好
但是依旧会有一些缺点，比如/tree只会改变对话的位置，但是修改的文件不会回退，所以要和git联系起来一起用
和subagent的区别
我认为他在一定程度上起到了subagent的作用，如
- 通过分支来进行角色分离
- 独立的思维线路
- 上下文的分割
- 按需按序工作
但是还有一些方面是不能实现的，如
- 并行执行
- 单独的工具策略
- 不同的模型
- 更加严格的边界
所以他是subagent的一个极致简略的替代品
这个时候自然就有些推荐的情况了
Spike-and-return pattern
针对场景：不确定方法，快速试验
- 主线上用
/tree迁移到前面的点形成分支 - 进行探索
- 有用输出形成文件
/tree切回主线- 读取有效文件进行分析
Analyst branch + implementer branch
使用场景：一个对话里面角色分离
- 分析者
- 实现者
这和subagent的区别就是不是并行并且在一个上下文里面，但是却有角色隔离的效果
Summary-assisted context carryover
使用场景：长探索但是只要关键点
我们可以在一个分支里面进行探索后形成一个摘要传回去，这样的情况多用于使用了大量工具和输出量很大的情况
tree vs rewind
rewind是cc里面的命令，有一定的重叠
| 特性 (Feature) | pi /tree | Claude Code /rewind |
|---|---|---|
| 主要模型 (Primary model) | 导航对话树分支 | 时间旅行至检查点 |
| 对话行为 (Conversation behavior) | 切换叶节点并从该分支继续 | 恢复到早期的对话状态 |
| 代码/文件回滚 (Code/file rollback) | 未内置于 /tree 中（需使用 git） | 回滚流程围绕检查点恢复选项设计 |
| 分支承接摘要 (Branch carryover summary) | 内置选项，在切换时可选择进行分支摘要 | 更侧重于检查点，而非分支本身 |
| 适用场景 (Best for) | 持续的分支管理 + 上下文净化 | 快速撤销/从错误路径中恢复 |
所以如果你从cc转到pi，把这个理解成一个长对话的导航器就行
部分信息可能已经过时