move runtime_workspace and agent_tool_route stages to completed
This commit is contained in:
@@ -0,0 +1,103 @@
|
||||
# 04A.agent_tool_route 联合评审（四）
|
||||
|
||||
**评审编号：** 04
|
||||
**日期：** 2026-08-07
|
||||
**评审对象：** [04A.agent_tool_route.md](04A.agent_tool_route.md)、[02.technical_implementation_spec.md](02.technical_implementation_spec.md)、[04.runtime_workspace.md](../04.runtime_workspace/04.runtime_workspace.md)、[05.technical_implementation_spec.md](../04.runtime_workspace/05.technical_implementation_spec.md)、[运行时与智能体工具.md](../../设计/02.正式方案/运行时与智能体工具.md)、[lineup-runtime-sdk-architecture.md](../../设计/02.正式方案/lineup-runtime-sdk-architecture.md)、[app_final_design.md](../../设计/02.正式方案/app_final_design.md)，以及当前 `tauri/src/runtime/` 中与 Tool invoke / Tool Router / 回程 outbox 相关的实现。
|
||||
**评审方法：** 以 `04A` 主定义和实施规范为候选基线，联合对照 `04.runtime_workspace` 已冻结的 Runtime 行为、`02.正式方案` 中 Runtime Tool 模型的正式边界，以及当前 Tauri Runtime 的协议 parser / router / outbox 代码，重点检查“文档是否把 04A 的真实改动边界写实”以及“请求侧统一与回程侧兼容是否被错误混写”。
|
||||
**总体结论：** 本轮联合评审发现两处新的 P2 级口径冲突，都会直接影响实现范围和验收判断，但都不是架构方向错误：第一，`04A` 文档先前把工作描述成“仅 Adapter 补齐”，与当前 Runtime 仍主要按旧请求类型接收 MiniApp Tool 调用的实现事实不符；要让 `lineup.v1.tool.invoke` 真正打通，必须补一个最小 Runtime 请求兼容层。第二，`04A` 文档先前把“统一 Agent Tool invoke”表述得过宽，容易让实现者误以为本轮还要把 Runtime 既有 MiniApp Tool 回程 envelope 一并收敛。结合 `04.runtime_workspace` 已冻结实现与当前代码现状，更准确的结论应是：`04A` 统一的是**请求入口**，回程仍沿用 Runtime 已冻结的兼容事实，并由 Adapter 解释为同一条 `call_id` 的 receipts / progress / final result。两项问题均已在本次评审中回填到主定义与实施规范；当前无未解决的 P0～P3 问题。
|
||||
|
||||
## 问题清单（Outline）
|
||||
|
||||
状态标记：🔴 未解决，必须处理；🟡 已提出修复方向，尚未确认或未回填实施权威；✅ 已解决；⚪ 可延期但必须保留记录。P0～P3 必须在当前迭代处理；P4～P5 可以延期，但必须记录延期原因和重新评估条件。
|
||||
|
||||
| 状态 | 优先级 | 编号 | 问题 | 当前结论 / 下一步 |
|
||||
|---|---:|---|---|---|
|
||||
| ✅ | P2 | D04A-07 | `04A` 文档把实现口径写成“仅 Adapter 补齐”，但当前 Runtime 仍主要按旧请求类型接收 MiniApp Tool 调用；若不补一层 Runtime 请求兼容，`lineup.v1.tool.invoke` 无法真正端到端生效。 | 已回填：`04A` 改为“Adapter 为主、附带最小 Runtime 请求兼容补丁”；允许仅在 Runtime parser / router / 测试夹具上补 `lineup.v1.tool.invoke` 接受能力，不改写 `04.runtime_workspace` 已冻结的业务语义。 |
|
||||
| ✅ | P2 | D04A-08 | `04A` 文档把“统一 Agent Tool invoke”描述得过宽，容易误导为本轮还要把 Runtime 既有 MiniApp Tool 回程 envelope 一并统一。 | 已回填：`04A` 当前统一的是请求入口；回程仍沿用 Runtime 已冻结且当前代码仍在发送的兼容事实，Adapter 只按同一 `call_id` 解释，不再新增第三套协议分支。 |
|
||||
|
||||
## 已确认的一致性
|
||||
|
||||
### `app-server` 仍可保持透明传输层
|
||||
|
||||
本次复核没有发现 `lineup-app-server` 需要理解 `lineup.v1.tool.invoke` 业务语义的证据。当前阻塞并不在传输层，而在 Runtime 本地 parser / router 对新请求类型的接受能力。
|
||||
因此，用户此前关于“是否涉及 app-server”的判断仍成立：`04A` 不应扩大为 Go 服务端语义改造。
|
||||
|
||||
### `04A` 的 Runtime 改动属于兼容补丁，不是边界回退
|
||||
|
||||
`04.runtime_workspace` 已冻结的权威仍然是 Runtime 对 revision、schema、activation、foreground gating、operation、outbox 与恢复的唯一裁决。
|
||||
这次要求的 Runtime 变更，只是让它在**请求入口**上接受 `lineup.v1.tool.invoke`；不改变 Tool Router 的核心裁决，也不把 Hermes 私有 contract 拉进 Runtime。
|
||||
|
||||
### 正式方案与当前实现可以通过“概念层 / 兼容层”两级解释保持一致
|
||||
|
||||
`02.正式方案` 中的 `tool.invoke / tool.result / progress` 描述的是统一 Agent Tool 模型。当前 Tauri Runtime 则仍保留 `lineup.v1.*` 兼容信封和已验收的 MiniApp Tool 回程 envelope。
|
||||
因此，本轮正确做法不是宣称“现有代码已经和正式方案一字不差”，而是明确：
|
||||
|
||||
1. `lineup.v1.tool.invoke` 是当前实现中的统一请求入口；
|
||||
2. 当前回程仍是 `04.runtime_workspace` 已冻结的兼容事实；
|
||||
3. 未来若做回程统一迁移，需要单独立项，不应在 `04A` 中顺手扩大。
|
||||
|
||||
## D04A-07：若不补 Runtime 请求兼容，`tool.invoke` 只会停留在 Adapter 内部
|
||||
|
||||
**已解决（2026-08-07，收敛决议）。** `04A.agent_tool_route.md` 与 `02.technical_implementation_spec.md` 已明确：本轮实现主场仍在 Hermes Adapter，但允许在 `lineup-app/tauri/src/runtime/` 中补最小请求兼容层，使 Runtime 接受 `lineup.v1.tool.invoke`。
|
||||
|
||||
### 为什么这是 P2
|
||||
|
||||
当前冲突并不只是“代码还没写”，而是文档口径会直接误导实施范围：
|
||||
|
||||
```text
|
||||
文档口径：04A 仅改 Adapter
|
||||
实际代码：Runtime 主要仍按旧请求类型接收 MiniApp Tool
|
||||
结果：Adapter 即使正确发出 lineup.v1.tool.invoke，也无法端到端命中既有 Tool Router
|
||||
```
|
||||
|
||||
这会让实现者在联调时误判为：
|
||||
|
||||
1. 需要回退到旧请求类型；
|
||||
2. 需要让 Adapter 同时发两种请求；
|
||||
3. 需要扩大到 app-server 语义改造。
|
||||
|
||||
这三种方向都偏离了本轮已经收敛的架构结论，因此必须在当前迭代文档里把 Runtime 的最小兼容补丁正名。
|
||||
|
||||
### 收敛决议
|
||||
|
||||
本轮已确认：
|
||||
|
||||
1. `04A` 仍是 Adapter 主导迭代；
|
||||
2. Runtime 允许补 parser / router / 测试夹具级别的最小请求兼容；
|
||||
3. 该兼容层必须同时保留 `04.runtime_workspace` 既有请求路径，避免回归历史验收；
|
||||
4. 该兼容层不改变 Runtime 的 schema / lifecycle / persistence / result 语义；
|
||||
5. `lineup-app-server` 仍不进入本轮范围。
|
||||
|
||||
## D04A-08：请求统一不等于本轮已完成回程统一
|
||||
|
||||
**已解决（2026-08-07，收敛决议）。** `04A.agent_tool_route.md` 与 `02.technical_implementation_spec.md` 已把描述收窄为：`lineup.v1.tool.invoke` 统一的是请求入口；回程继续沿用 Runtime 已冻结且当前实现仍在发送的兼容事实，Adapter 以同一 `call_id` 解释，不再新增第三套协议分支。
|
||||
|
||||
### 为什么这是 P2
|
||||
|
||||
如果不收窄这层表述，会出现两个危险后果：
|
||||
|
||||
```text
|
||||
后果 A：实现者误以为 04A 必须顺手重构 Runtime 全部 miniapp.tool.progress/result/cancel
|
||||
-> 范围扩张到超出本轮验收与回归预算。
|
||||
|
||||
后果 B：验收者误以为只要代码里仍出现 miniapp.tool.result，就说明 04A 与正式方案冲突
|
||||
-> 会把“兼容事实尚在”误判成“架构方向错误”。
|
||||
```
|
||||
|
||||
这不是语义吹毛求疵，而是直接关系到本轮是否还能保持“最小补丁闭环”的实现策略。
|
||||
|
||||
### 收敛决议
|
||||
|
||||
本轮已确认：
|
||||
|
||||
1. `04A` 不新增新的本地回程协议族；
|
||||
2. Adapter 需要能把现有回程解释为同一条 Agent Tool 调用的 receipts / progress / final result；
|
||||
3. Runtime 既有回程 envelope 是否重命名，不在 `04A` 范围内；
|
||||
4. 若未来推进回程统一，应以新的迭代和新的设计评审承接，而不是在 `04A` 中隐式扩大。
|
||||
|
||||
## 评审关闭条件
|
||||
|
||||
1. D04A-07 与 D04A-08 已回填 [04A.agent_tool_route.md](04A.agent_tool_route.md) 与 [02.technical_implementation_spec.md](02.technical_implementation_spec.md)；
|
||||
2. 后续实现与验收必须按“Adapter 主导 + Runtime 最小请求兼容 + app-server 不动”的边界推进；
|
||||
3. 后续若要推动 Runtime 回程 envelope 统一，必须新增独立设计评审记录，不能在 `04A` 中以顺手修正方式扩容；
|
||||
4. 本评审当前无未解决的 P0～P3。
|
||||
Reference in New Issue
Block a user