Goal zh

目标

上游同会话目标追踪系统在 Edge 中的适配。

上游参考：Goal

上游提供了什么

目标子系统让模型为当前会话创建一个持久目标，并跨多轮自主工作直到目标达成或受阻。由三个服务端插件和一个客户端插件组成：

• GoalService（ctx.goals）— 状态管理：创建、编辑、暂停、恢复、完成、阻塞、清除。所有变更作为 goal/change 事件提交。
• ToolGoal — 注册三个模型工具和系统提示词策略段。
• GoalRoundDriver — 监听 turn 结束，自动注入续跑提示。
• dsh-client-ui-goal — GoalBar 和目标变更节点。

所有目标状态都是事件溯源的：goal/change 事件是唯一的 source of truth。

Edge 改了什么

直接复用 — 全部 goal 插件

四个 goal 插件和 SessionProjectionCache 全部原封安装。模型工具、提示词注入、续跑逻辑、状态管理、GoalBar UI 和投影缓存完全是上游代码。

传输桥 — Goal 投影推送

GoalService 注册了 'goal' 投影。Edge 通过通用的 onChanged 桥捕获变更——覆盖 goal、title 和所有未来的投影键——在 flush 后以 WebSocket 帧推送。

传输桥 — GoalBar RPC 路由

GoalBar 的编辑/暂停/清除按钮发送 Typert RPC 请求。Edge 通过通用的 TypertGatewayService 自动路由到 GoalService。

Edge 没有改什么

• 目标生命周期、工具定义、系统提示词策略、续跑逻辑
• GoalBar UI 行为、goal/change 事件格式、权限检查
• 投影缓存写入时机、清理和冷快照恢复

性能特征

Goal 投影推送开销

模型调用 create_goal 或 update_goal 时，GoalService 追加 goal/change 事件。投影注册表的 drive() 同步计算新值，onChanged 回调缓冲之。缓冲条目在 flush 后 drain 并广播。

对于非 goal 事件（绝大多数），goal 投影的 apply() 返回相同的状态引用，onChanged 不触发。非 goal 事件的额外开销：零。

GoalBar RPC 延迟

用户点击 GoalBar 的编辑/暂停/清除时，请求路径：浏览器 → HTTP POST → handleTypertRpc → TypertGatewayService.invoke() → SRC 反射 → GoalService.edit() → 响应。SRC 反射每个 endpoint 扫描一次并缓存。GoalService 方法是同步的状态变更 + 事件追加。DO 内典型往返：个位数毫秒。

冷会话 goal 恢复

路径	触发条件	代价
活跃 agent 快照	Session 有活跃 agent	O(1) — 内存读取
缓存快照	冷 session，有缓存	O(1) — 同步领域读取
冷快照	冷 session，无缓存	O(尾部事件数) — 持久化尾读 + 重放

上游 SessionProjectionCache 管理写入时机（节流 write-behind）和清理（session/disposed）。缓存条目通过 storageDomain 存储，参与上游领域生命周期。

架构总结

组件	分类	Edge 代码
GoalService + ToolGoal + Driver + UI	直接复用	四行 ctx.plugin() 调用
SessionProjectionCache	直接复用	一行 ctx.plugin() 调用
Goal 投影推送	传输桥	通用投影桥
GoalBar RPC 路由	传输桥	通用 Typert 网关

关键观察：Goal 在 Edge 中需要零业务逻辑代码。每一行 Edge 拥有的代码都是通用传输基础设施——投影推送和 RPC 路由——同样服务于所有其他子系统。投影缓存、生命周期清理和冷 session 恢复完全由上游处理。