前一篇已经把数据流推进到 ConversationViewNode。此时 Runtime 已经完成了历史恢复、实时 Event 合并和业务 Projectio
Agent 的 Server 端很适合使用 Event 表达执行过程：Turn 开始、模型输出、Tool Call、Tool Result、Approval、
一个只在进程内运行的 Agent，可以把一次执行理解为一个函数调用：输入进入，模型与工具循环推进，函数返回，调用方获得结果。进入 Web 以后，这个假设很快失
前两篇得到了一组比较明确的运行时语义： `text Plugin ├── declares dependencies └── produces ef
Cordis 的 API 并不复杂： const root = new Context() await root.plugin(ServiceA) awa
插件系统最容易实现的部分是加载。 给定一个模块： function plugin(ctx) { ctx.registerTool(...) ctx
一个能够调用工具的 Agent Core 并不复杂。最小实现只需要维护消息、请求模型、执行 Tool Call，再把 Tool Result 放回下一次请求。
Pi 的 Session 文件表面上非常简单：一个 JSONL 文件，每一行是一条 JSON 记录。 它没有把一段会话直接存成 messages[]，也没有
前面两篇分别分析了 Pi Session Tree 和 DeepSeek Harness Session Event Log。两者的持久化模型不同，但都遵循一
Pi 的 Session 主要围绕“可分支历史如何恢复成当前 Context”组织。DeepSeek Harness（DSH）选择了更强的持久化边界：Sess