企业官网建设流程全解析

说实话，第一次看到 opencode 这个项目时，我并没有太当回事。终端里跑 AI 编程助手的方案已经有好几个了，多一个不多。但真正把它装下来、用了一段时间，又翻了源码之后，我的看法变了。opencode 最吸引我的不是它又接了多少个模型，而是它在工程实现上做对了几件很本质的事：双会话内核、事件溯源、以及一套非常干净的工具调用抽象。这篇文章不打算写“怎么装、怎么用”的入门教程，那类文章已经很多了。我想聊的是代码背后的设计逻辑：opencode 的整体工程全景是怎样的，“双会话内核”到底解决了什么问题，事件溯源是怎么让整个会话状态变得可以回放和恢复的。不管你是想自己改 opencode 做二次开发，还是单纯想理解一个现代 AI Agent 工具应该怎么设计，这篇应该都能给你一些参考。我把这当作上篇，先把骨架讲清楚。

1. 为什么要拆 opencode：终端里的 AI 副驾到底在解决什么问题

先对齐一下认知。opencode 是一个开源终端原生 AI 编程辅助工具，定位上很像 Claude Code、Aider、Codex CLI 那一类东西。你给它一个任务，它会读取项目结构、查看文件、写代码、跑命令，通过多轮工具调用逐步推进目标。和那些 IDE 插件最大的区别是，它运行在终端里，不绑定某个编辑器，能直接用命令行启动，也能通过 SSH 在远程开发机上跑。

但这只是表面。真正让我决定把它拆开看的，是它解决了一组非常实际的问题。

第一，上下文的组织问题。终端 Agent 的工具调用会产生大量的中间过程：读文件、搜代码、执行命令、看输出、修改文件。这些过程如果全部塞进模型上下文，很容易就把窗口打爆。opencode 用双会话机制把这些流量分开处理，类人脑工作记忆和长期记忆的分工，一个管眼前的任务，一个管任务执行的完整轨迹。

第二，状态的可恢复问题。AI 编程任务往往要跑很久，一次执行可能持续十几分钟甚至更久。如果中途断了、电脑重启了、或者你换了一台机器，会话状态怎么恢复？opencode 引入事件溯源，把会话变成一条可追加、可回放的事件流，任何时刻断掉都能从事件流重建现场。这一点做过分布式系统的人会特别亲切。

第三，模型可插拔的问题。AI 编程工具最怕被某个模型厂商绑架。opencode 从架构上就把模型提供商抽象出来了，Anthropic、OpenAI、DeepSeek、本地模型，全部通过统一的 provider 接口接入。你可以随时切换模型，甚至在同一场对话里用多个模型各司其职。

适合看这篇文章的人，我大致分成三类：一是已经在用 opencode 或其他终端 Agent，想理解背后原理的老用户；二是想在 opencode 基础上做二次开发、扩展工具、接入私有模型的开发者；三是对 Agent 工程实现感兴趣，想从具体项目里学习架构设计的同行。如果你只是想要快速上手，那直接看官方 README 就够了，没必要往下读。但如果你想把这套工具用到极致，遇到问题能自己排查，甚至自己改源码，那这篇文章值得读完。

我读的是 opencode 的 0.8.x 时代的源码。这个项目迭代速度极快，很多内部命名和模块位置可能已经变了，但核心设计思想通常不会变。下面讲的都是原理层面的东西，理解了原理，哪怕代码结构变了你也能快速定位。

2. 工程全景：opencode 到底由什么组成

先看一张整体的功能地图（这里不画图，用文字描述层级）。opencode 从架构上看可以分成五层：CLI 入口层、会话管理层、事件溯源层、模型供给层、工具执行层。

CLI 入口层就是你在终端敲opencode命令后进入的交互界面，它负责处理用户的输入、渲染输出、管理快捷键和界面布局。这一层是整个项目最“轻”的部分，它做的事情是把用户输入转换成事件，把模型输出渲染成界面。

会话管理层是核心中的核心，也就是标题里说的“双会话内核”。它维护着两类会话的生命周期，管理消息流、上下文窗口、工具调用循环。这一层决定了 Agent 的行为逻辑，也是 opencode 区别于“一个带聊天的 API 客户端”的关键分水岭。

事件溯源层负责把所有发生的事记录下来。任何一次用户输入、任何一条模型回复、任何一个工具调用的结果，都会作为事件被追加到持久化存储里。这一层是整个项目可靠性的基础。你 Ctrl+C 之后，下次再启动 opencode，它还能记得你刚才聊到哪儿，靠的就是这一层。

模型供给层是连接外部大模型的抽象层。它定义了一套统一的接口，把不同厂商的 API 差异屏蔽掉了。不管是官方 API、OpenAI 兼容接口、还是本地跑的自托管模型，在 opconv 这一层看来都是提供“消息流”和“工具调用”能力的黑盒。

工具执行层则是 Agent 的“手脚”。opencode 内置了一套工具，包括读文件、写文件、执行命令、搜索代码、访问网页等。每一个工具都符合统一的 schema 定义，模型通过 JSON 格式的调用指令来请求工具执行，执行结果再作为上下文反馈给模型。这五层之间通过事件总线通信，各自独立，又互相配合。

2.1 从启动到对话：一个请求的完整路径

为了把上面的分层讲清楚，我走一遍完整流程：你在终端启动 opencode，敲下一段任务描述，回车，然后看着它在项目里执行操作。

第一步，CLI 接住输入，把它包装成一条用户消息事件，发送到会话管理层。会话管理层此时会检查当前是否存在活跃的会话，如果有，就把这条消息追加进去。

第二步，会话管理层从事件溯源层加载当前会话的上下文。这一步不是简单地把所有历史消息原样丢给模型，它做的是“压缩 + 截断 + 定制化组装”。比如很早之前的文件内容可能已经被摘要替换，工具调用的完整输出可能只保留关键片段。这也是双会话机制发挥作用的地方。组装好的上下文会被打包成一个请求。

第三步，请求被发送到模型供给层。模型供给层根据当前配置的提供商、模型名称、参数（温度、max_tokens、工具开关等）把请求转换成对应 API 的格式。模型返回的内容也不是直接渲染到屏幕上，而是作为一条 assistant 消息事件回到会话管理层。

第四步，会话管理层解析 assistant 消息。如果模型只回答了文本，那这条文本直接渲染给用户看就完事了。如果模型返回的是工具调用请求，会话管理层会把工具调用请求发送给工具执行层，让具体的工具去执行（比如写文件、跑命令）。工具执行的结果会作为一条 tool_result 事件回到会话管理层，再打包进上下文，继续发给模型。这个循环会一直持续，直到模型给出最终答案或者达到最大迭代次数限制。

第五步，所有上述事件都同步写入了事件溯源层。你看到的每一屏输出，背后都对应着一串已经持久化的事件记录。

这条链路里，每层都只干自己的事情。CLI 不负责逻辑，会话层不懂 API 细节，模型层不碰文件系统，工具层不关心上下文怎么拼。这样的好处是，每一层都可以独立替换和测试。比如你想换一套全新的终端 UI，只动 CLI 层就行；你想接入某个私有协议的后端模型，只需在模型供给层加一个适配器。

2.2 模型供给层：不止一个 provider

opencode 支持很多模型提供商，这也是搜索热词里那么多人问“opencode 和 deepseek hermes 哪个好”“opencode go 套餐额度怎么算”的原因。从架构上看，模型供给层定义了一个Provider接口，核心方法就几个：生成消息流（streaming completion）、工具调用（tool call）、模型列表查询等。

不同提供商的实现类各做各的适配。比如 Anthropic 的实现会走 Anthropic 的消息 API，处理工具调用相关的字段；OpenAI 兼容的提供商则走 chat/completions 接口。你需要理解的关键点是，模型供给层承担的不只是 API 请求转发，它还负责把不同模型的“性格差异”抹平。

举例来说，有些模型在工具调用时返回的格式很规范，有些则比较随意；有些模型支持 prompt caching，有些不支持。这些细节如果暴露给上层，会话管理层就得写一堆条件判断。所以 opencode 的策略是，在 Provider 适配器内部把不同模型的输入输出归一化成统一的内部格式。上层永远面对的是同一套消息结构，底层无论接的是 GPT 还是 Claude 还是 DeepSeek，对会话层来说没有区别。

这带来一个直接好处：你可以在一个会话里切换模型，而且切换时不需要重置上下文。因为上下文是内部统一的格式，发给 A 模型时转成 A 的格式，发给 B 模型时转成 B 的格式。我实际用的时候经常这样操作：先用一个便宜的模型做代码搜索和文件定位，等到真正要写复杂逻辑时再切到更强的模型。这种“模型路由”的策略在 Anthropic 官方客户端里是做不到的，但在 opencode 里是天然支持的。

2.3 工具调用层：Agent 的“手”和“眼”

工具层是 Agent 真正能干活的保障。opencode 的工具系统设计我得单独拎出来讲，因为它和很多框架不一样。

opencode 的每个工具都是一个独立模块，定义极其简单：一个描述、一个输入 schema、一个执行函数。描述告诉模型“这个工具是干什么的、什么时候该用我”；输入 schema 规定了模型调用工具时必须传的参数格式；执行函数则接收参数，真正去完成操作，返回结果。就这么简单。

系统里比较核心的工具包括：

• read_file：读取指定文件的内容，支持行号标注，方便模型定位代码。
• edit_file：对文件内容做精准编辑，通常是基于字符串匹配或正则。
• bash：在沙箱里执行 shell 命令，返回标准输出和标准错误。
• grep_search：在项目里做内容搜索，相当于把 ripgrep 的能力暴露给模型。
• web_search和web_fetch：让 Agent 能查资料、读文档。

你可能会问，这有什么特别的？很多框架的工具系统也是这么设计的。关键在于工具调用的循环控制。opencode 在工具层和会话层之间做了一个调度器（dispatcher），它负责安排工具调用的执行顺序，并且对连续的工具调用做合并优化。

举个例子，模型如果想搜索代码，先搜foo，再搜bar，这个调度器不会把两轮搜索之间的中间结果作为一个完整的上下文回合让模型处理。它会批量执行多个工具调用，然后把结果合并成一条消息一次性返回给模型。这就大大减少了模型请求的次数，也减少了上下文占用的 token。对使用 API 计费的用户来说，这是实打实地省钱。

工具层还有一个安全设计是“内置分别在沙箱中执行 Bash”。沙箱不是 Docker 那样的强隔离，而是更偏防护性质的约束。你在配置里允许哪些命令、拒绝哪些命令、哪些目录可写，都能控制。Agent 的能力边界在工具层就被框住了，而不是等它在模型层“自觉”。

3. 双会话内核：两套会话，各管一摊

这是 opencode 最核心的设计之一。我第一次在源码里看到session和agent_session两类模型对象时，第一反应是“这不大材小用吗”，但真正跑起来才明白，这个区分是解决 Agent 工程“上下文爆炸”和“控制权混乱”这两大顽疾的关键。

先说一个背景问题：Agent 的执行过程是有“树状结构”的。用户给一个主任务，Agent 可能拆出多个子步骤，每一步又有若干工具调用，工具调用可能失败，需要重试。在这个过程里，模型其实扮演着两个角色。第一个角色是“对话者”，它要理解用户在说什么，要做规划，要给出最终答案。第二个角色是“执行者”，它要在工具链的反馈中不断调整动作，下一轮该读哪个文件、该改哪一行。

如果这两个角色混在同一个上下文里，会发生什么？你会看到对话历史里塞满了“读取了 foo.go 的 120-200 行”“执行了 go test，失败”“又执行了 go test，成功”这类中间噪音。模型每做一次决策，都要在这些噪音里翻找真正重要的信息。用户的原始诉求反而被淹没了，模型甚至会忘记自己最开始要干什么。这就是“上下文爆炸”的典型症状。

3.1 什么是“双会话”

opencode 的做法是，把上面两个角色拆成两个会话，各自维护独立的状态。

第一个是用户会话（user session），我更喜欢叫它“任务会话”。它保存的是用户与 Agent 之间的高层对话，包括用户的每一次输入、Agent 的最终回复、以及关键时刻的规划摘要。它面向“人”，给人的阅读体验是连贯的、有逻辑的。你在 opencode 界面里按上下键切换历史消息，看到的其实就是这条用户会话流。

第二个是代理会话（agent session），它保存的是 Agent 实际执行过程的完整轨迹，包括每一次工具调用请求、每一次工具执行结果、模型中间产生的思考片段、错误重试记录。它面向“机器”，记录的是“事情是怎么一步一步被做完的”。这条流又长又碎，但对排查问题极其有用。

这两个会话在时间线上是交叉发生的：用户发一条消息，可能触发 Agent 执行十几次工具调用，最后回一条总结。这条用户消息会进入用户会话，那十几条工具调用记录则全部进入代理会话，Agent 的总结再回到用户会话。两者通过关联 ID 互相引用。这样设计带来的第一个直接好处是：用户会话可以保持精简，代理会话可以无限膨胀而不影响模型的上下文调用。

3.2 会话生命周期与状态管理

理解了双会话的概念，再来看生命周期就顺理成章了。我把它拆成三个阶段。

创建阶段。你在终端启动 opencode，它会自动创建一个用户会话，分配一个session_id。此时代理会话还没有真正建立，它是在你发出第一个任务时才初始化的。为什么这么设计？因为很多用户只是打开 opencode 问个简单问题，根本不需要完整工具链。如果一开始就建代理会话，白白浪费资源。

执行阶段。任务开始后，代理会话进入活跃状态。这个阶段所有的工具调用、模型中间输出、异常重试，都记录在代理会话里。每次模型请求的上下文组装，也是基于代理会话的完整轨迹来做压缩和摘要。而用户会话只记录任务的起点和终点状态，中间过程尽量少记录。

切换/恢复阶段。这是双会话设计最优雅的地方。你正在跑一个长任务，突然想切出去看别的文件或问一个无关的问题，怎么办？在单会话设计里，这会污染主任务的上下文。在 opencode 的双会话里，这个问题天然解决：你直接开一个新用户会话，新会话独立于之前的代理会话。原任务的代理会话状态完整保存在事件溯源层，随时可以回来继续。甚至你可以同时挂几个任务会话，像浏览器里开多个标签页一样，每个标签页对应一个独立的代理执行环境。这在实操中非常实用，我经常同时开三个会话，一个在改后端，一个在理前端样式，一个在查文档，相互完全隔离。

关于上下文组装，opencode 在把代理会话的历史发送给模型前，会做一层“提炼”。它不会把工具输出的原始文本全部塞进去，而是通过摘要机制把长输出缩短，再结合 token 配额做截断。所以你即使把上下文窗口设得很大，它也会优先保留决策链里“真正影响下一步动作”的信息。

3.3 为什么需要两条事件流

这里回到“事件溯源”这个主题。有了双会话，事件流自然也要分开。opencode 在持久化时有两种 event stream，一种是面向用户会话的，一种是面向代理会话的。它们之间存在引用关系，但写入是独立的。

这带来三个非常实际的好处。

一是渲染与推理解耦。终端 UI 读取用户会话流来渲染历史。它根本不需要去解析那些工具调用细节，渲染速度快、逻辑简单。而需要做会话恢复时，代理会话流才是主角，它包含了重建 Agent 状态的完整信息。

二是权限与控制分离。用户查看历史记录时，只应该看到用户会话层面的内容；而开发者做调试时，则需要完整的代理执行时间线。两条流各自对应不同的访问场景，不存在“一条流里信息太多无法筛选”的问题。

三是故障恢复更精确。假设 Agent 执行到第 17 次工具调用时崩溃了。单会话流要想恢复，只能把整条流重放，直到第 17 次调用；双会话流允许我们只重放代理会话，用户会话里的消息内容不需要动。后者显然更高效率，也更清晰。

有一点需要强调：双会话不是说把“历史”和“当前”分成两个存储，而是从逻辑上区分人机对话和机器执行这两个视角。物理存储上它们可以共用一个事件库，甚至可以共用一张表，区别主要在事件类型和归属 ID 上。理解这一点你就明白，双会话并不是什么高不可攀的设计，它只是在建模型阶段多问自己一句：“这份数据，是给人看的，还是给机器看的？”

4. 事件溯源：把聊天变成可回放的时间线

接下来是标题里的第三个关键词“事件溯源”。这个词在软件架构领域不是一个新概念，微服务里有事件溯源，DDD 里也有事件溯源。但把它用在 AI Agent 的会话管理上，opencode 的做法很有参考价值。

事件溯源的核心思想很简单：不保存系统的“当前状态”，而是保存导致当前状态的所有“状态变更事件”。你需要知道当前状态时，就把这些事件从头到尾重放一遍，在内存里重新计算出来。类比一下：银行账本不直接保存“你卡里现在有 100 块”，而是保存“6 月 1 日存入 500”“6 月 2 日消费 400”这条流水。你要知道余额，把流水加一遍就出来了。

opencode 在会话管理上就用了这个思路。

4.1 事件溯源的基本思路

在常规的聊天软件里，每次对话结束后系统保存的是一个完整的“聊天记录对象”，包含所有消息的数组。新消息来了就往数组里 push 一条，整个对象重新持久化。这种方式简单直观，但有几个问题：并发写入时容易丢失更新；历史版本无法回溯；很难搞清楚“某个状态是怎么演变成这样的”。

事件溯源完全不一样。opencode 不保存“当前会话状态”这个快照，它保存的是一条不可变的事件流水。任何一个行为，不管是用户输入、模型回复、工具调用开始、工具调用结束、会话切换，还是错误信息，都会变成一个事件对象，追加到流水末尾。事件一经写入就不可修改，只能追加。这保证了流水记录的完整性和真实性。

要重建某个时刻的会话状态，只需要从流水开头重放，把事件应用到初始状态上。这就相当于你看一遍监控录像，就能知道案发时发生了什么。不需要依赖任何“快照备份”来恢复现场。

4.2 opencode 里的 event log 结构

具体到实现上，opencode 的每个事件都包含几个要素：事件 ID、事件类型、发生在哪个会话、时间戳、关联的上一个事件 ID、以及事件内容。内容字段是 JSON 格式的，不同类型的事件内容结构不同。

我把 opencode 里比较常见的事件类型整理了一个表格：

这里值得注意的细节是，会话状态不是单个 JSON 对象，而是通过事件回放重建得到的。这意味着事件流水本身就有“官方历史记录”的权威性。你不用担心内存里的会话状态和持久化状态不一致，因为“一致”的定义就是从事件流重放出来的结果。

4.3 从事件流重建会话状态

我实际遇到过一种情况：某个任务跑到一半断网了，Agent 所在的远程服务器也跟着断开。重新连上后，我本来以为会“一切归零”，结果 opencode 提示恢复上次的会话，继续上一步操作。这个能力的底层就是事件溯源。

重建过程大概是这样的：启动时，opencode 读取该会话的事件流水，从头重放。每次遇到user_message事件，就在当前会话状态里追加一条用户消息；遇到assistant_message，就追加一条助手消息；遇到tool_call，就把它标记为“待执行的请求”；遇到tool_result，就把对应的请求和结果关联起来。整个过程就像在内存里重新演了一遍当天的对话。等最后一条事件重放完，当前会话状态就完整无缺地复原了。

这不是什么黑魔法，代码逻辑其实就是个简化的 kafka 消费逻辑。但把这个逻辑想清楚，我在写自己的自动化工具时也受益匪浅：如果你的系统想做“断点续跑”“操作审计”“历史回溯”，事件溯源就是最简单可靠的底层模型。

还有一件事值得提：opencode 会定期对事件流做压缩（compaction）。事件流如果无限增长，重放会越来越慢。压缩不是删减事件，而是把一段早期的细粒度事件合并成一个摘要事件，相当于把“详细的监控录像”浓缩成“案情摘要”。重放时遇到摘要事件，就直接用摘要作为那个时间点的状态，不必展开。这是在性能和完整性之间做的平衡。

5. 实操中的关键细节与常见问题

讲了这么多原理，下面落到实操层面。我这几周高强度使用 opencode，踩过的坑、总结的经验、以及被问得最多的问题，集中整理在这一节。

5.1 安装与版本选择

opencode 的安装方式比较多，官方推荐的是curl -fsSL https://opencode.com/install | bash或通过 npm 全局安装。但这里有一个很多人没注意到的坑：安装脚本拉取的版本可能不是最新版本，而且不同的安装路径对应的版本管理策略不太一样。

我个人的建议是，如果网络条件允许，尽量直接用二进制安装方式。它会自动下载对应平台的产物，并且内置更新检查命令opencode upgrade。如果你用 npm 安装，版本更新可能依赖 npm registry 的同步延迟，有时官方已经发新版了，npm 上还是旧的，导致你升级了半天发现功能没变化。

装完之后第一件事，不要急着配模型，先运行opencode --version确认版本。我遇到过几个用户装的是 0.7.x 甚至更老的版本，很多下面的操作对不上，就是因为版本差太多。最新版的配置项和会话存储路径都有变化，看文档时一定要先确认文档对应的版本。

5.2 免费额度与模型配置

搜索热词里有一个非常有意思的提示语："opencode's free tier can only be used from within opencode"。这是 opencode 官方免费套餐的限制：免费额度只能从 opencode 终端环境内访问，不能单独申请 API key 走外部请求。这个设计让一批想“白嫖”免费模型 API 的用户很失望，但从项目运营角度看很合理：免费额度本质是引流和体验用的，不是公开 API。

实际配置模型时，我建议你把opencode.json（或opencode.jsonc）里的 provider 段好好读一遍。很多人直接复制网上的配置，连provider的 baseURL 都懒得核对，结果模型加载了一堆，真正请求时全报连接错误。

一个稳妥的配置顺序是：先配好一个你最常用的 provider（比如 Anthropic 或 DeepSeek），跑通一个简单任务；再逐步加其他 provider。不要一上来就配十几个模型，出问题时你根本分不清是哪个 provider 的 key 失效、哪个模型名拼错了。

还有一个被问很多的问题：“opencode go 套餐是每种模型分开计算额度吗？”据我了解，opencode 的套餐计划通常是按统一账户维度计算额度，不是按模型分池。也就是说，你用 Claude 还是用 GPT，消耗的是同一个账户的总量配额。但 OpenAI 兼容 API 那一类，如果你接入的是第三方聚合平台，那要看的其实是第三方平台自己的计费规则，跟 opencode 本身没关系。

5.3 与 VSCode 联动

“VSCode 怎么和 opencode 工作”也是一个高频问题。这里必须说清楚：opencode 本身是终端工具，不是 VSCode 插件。但你可以通过几种方式在 VSCode 里使用它。

最简单的一种，是在 VSCode 的集成终端里启动 opencode。这样你可以一边在编辑器里改代码，一边在终端里让 Agent 做扫描、解释、生成改动。这种方式不需要装任何插件，只是把终端窗口换了个宿主。

第二种方式，是用 opencode 的 server 模式。opencode 内置了一个 TCP 服务器能力，你可以在后台启动它，然后通过 HTTP 请求发送任务。很多社区的 VSCode 扩展就是基于这个协议做的。如果你用这种模式，要注意安全配置：server 模式默认不设鉴权，绝不能暴露到公网，否则任何人都有可能通过端口直接操纵你的项目文件。这个风险我反复强调过。

第三种方式是配合 Claude Code 或其他的扩展桥接工具。搜索热词里也有“jev 如何接入到 calude code”这种问题。这类桥接工具一般把 opencode 的模型路由能力接到 Claude Code 的界面里，让它能用 opencode 支持的模型。桥接本质上是一个适配层，它本身不修改 opencode 的会话逻辑，所以双会话和事件溯源这些机制在桥接场景下依然生效。

5.4 常见报错排查

我把这段时间遇到的高频报错整理成一张速查表：

排查这类问题，我的通用思路是：先看错误发生的层次。CLI 层的报错通常和界面、命令参数有关；会话层的报错通常和上下文、会话恢复有关；模型层的报错通常暴露 provider 原始错误信息；工具层的报错则会指出哪个工具执行失败以及失败原因。定位到层次后，去看对应的事件日志。opencode 的日志目录里记录了一切，遇到诡异问题第一反应不要瞎猜，先去翻事件日志，十次里有八次能直接定位。

6. 再聊几句我的实际体会

项目源码翻到这里，“双会话”和“事件溯源”这些概念其实都不是 opencode 发明的,但它把这两样东西组合起来用在 AI Agent 会话管理上，并且组合得很顺滑，这本身就值得称道。我自己在做企业级的 AI Agent 工具设计时，也借鉴了这套思路：做事的人群和对话的人分开，记录操作事件而不是保存易变的状态快照。这让整个系统在长时间运行、故障恢复、审计追踪几个纬度上都变得更加从容。

其次，opencode 还在快速演进，很多当前的设计到下个版本可能就被重构了。比如它对上下文压缩策略一直在优化，工具沙箱的权限模型也一直在加强，会话存储格式也在调整。所以当你读到这篇文章时，个别内部结构可能已经不完全是文中描述的样子。这其实恰恰证明了一件事：架构设计在变化中保持核心原则，比任何具体实现都更重要。双会话的内核和事件溯源的思想，短时间内应该不会被推翻，因为它们在解决真实问题，而不是炫技。

最后给想动手折腾的朋友一个建议：不要满足于在 opencode 里调配置、换模型。花一个下午把源码目录结构捋一遍，然后试试给它写一个自定义工具。你不需要改核心逻辑，只需要按照它的工具接口规范注册一个函数，这个过程会帮你把整个事件流、工具调用循环、会话状态管理的概念全部串起来。等你真的亲手把一个自定义工具跑进 opencode 的工具链里，你对终端 AI 副驾的认知会进入一个全新的层次。到那时候，这篇上篇里讲的骨架，你就真正消化透了。