参考git设计agent的思路设想

​ ​

每个节点都是一次ai交互

一次ai交互包含 propmt 和 ai 回答、基于这个 ai 回答所产生的一些工具调用和相关结果

每个节点执行完毕后都会基于这个节点创建当前分支的下一个节点，唯一的例外是中断（例如ai评估完成了，或者用户点击了结束之类的）

使用 Tool Calling​ 功能实现ai的自行分叉和合并，例如合并这个功能其实是结束对话 tools 的调用，但是对于非主分支而言他会执行压缩上下文并生成一个节点合并到主分支，对于主分支就是输出内容给用户。

用于对节点进行分类的标签

分叉则是各个工具的内部自定义逻辑，例如调用 skills 、创建 task、sub agent（在这个场景下 sub agent 其实就是一个分支），只是不同的场景对于分叉这个节点之后的 ai 交互都能够采取不同的上下文合成策略

例如 skills 场景：使用历史上下文+对应 skills 的上下文 创建一个 阻断性节点 然后就是继续执行了

最显然的例子是 压缩会话 ，为了解决上下文长度限制，当上下文长度达到阈值的时候需要对历史会话进行压缩（由 ai 进行摘要）这样就可以得到一个较短的文本用于后续对话，那么对于这个分支而言这个压缩会话的节点就是一个阻断性节点，因为自他之后的节点的上下文是不会包含这个节点之前的节点信息

由于咱们的分叉事实上也具备压缩会话的能力（子分支解决完问题后需要压缩这次的对话然后合并进父分支），所以合并分叉这个操作也属于阻断性节点，但是略有不同的是他阻断的是子分支中的历史节点，避免父分支的后续对话会包含子分支的历史节点信息，但并不会阻断父分支

每个节点的 ai 交互都是需要将上下文发送给 ai 处理的，如何构建上下文是至关重要的。

通过阻断性节点和分叉时的代码定义来合成一个新节点所需要的上下文

所以上下文是不需要存储的，他是基于节点动态计算出来的。