8.1 KiB
04A.agent_tool_route 联合评审（四）
评审编号： 04
日期： 2026-08-07
评审对象： 04A.agent_tool_route.md、02.technical_implementation_spec.md、04.runtime_workspace.md、05.technical_implementation_spec.md、运行时与智能体工具.md、lineup-runtime-sdk-architecture.md、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。
因此，本轮正确做法不是宣称“现有代码已经和正式方案一字不差”，而是明确：
lineup.v1.tool.invoke是当前实现中的统一请求入口；- 当前回程仍是
04.runtime_workspace已冻结的兼容事实； - 未来若做回程统一迁移，需要单独立项，不应在
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
当前冲突并不只是“代码还没写”，而是文档口径会直接误导实施范围：
文档口径：04A 仅改 Adapter
实际代码：Runtime 主要仍按旧请求类型接收 MiniApp Tool
结果：Adapter 即使正确发出 lineup.v1.tool.invoke，也无法端到端命中既有 Tool Router
这会让实现者在联调时误判为：
- 需要回退到旧请求类型；
- 需要让 Adapter 同时发两种请求；
- 需要扩大到 app-server 语义改造。
这三种方向都偏离了本轮已经收敛的架构结论，因此必须在当前迭代文档里把 Runtime 的最小兼容补丁正名。
收敛决议
本轮已确认：
04A仍是 Adapter 主导迭代；- Runtime 允许补 parser / router / 测试夹具级别的最小请求兼容；
- 该兼容层必须同时保留
04.runtime_workspace既有请求路径，避免回归历史验收； - 该兼容层不改变 Runtime 的 schema / lifecycle / persistence / result 语义；
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
如果不收窄这层表述，会出现两个危险后果：
后果 A：实现者误以为 04A 必须顺手重构 Runtime 全部 miniapp.tool.progress/result/cancel
-> 范围扩张到超出本轮验收与回归预算。
后果 B：验收者误以为只要代码里仍出现 miniapp.tool.result，就说明 04A 与正式方案冲突
-> 会把“兼容事实尚在”误判成“架构方向错误”。
这不是语义吹毛求疵，而是直接关系到本轮是否还能保持“最小补丁闭环”的实现策略。
收敛决议
本轮已确认：
04A不新增新的本地回程协议族；- Adapter 需要能把现有回程解释为同一条 Agent Tool 调用的 receipts / progress / final result；
- Runtime 既有回程 envelope 是否重命名，不在
04A范围内； - 若未来推进回程统一，应以新的迭代和新的设计评审承接，而不是在
04A中隐式扩大。
评审关闭条件
- D04A-07 与 D04A-08 已回填 04A.agent_tool_route.md 与 02.technical_implementation_spec.md；
- 后续实现与验收必须按“Adapter 主导 + Runtime 最小请求兼容 + app-server 不动”的边界推进；
- 后续若要推动 Runtime 回程 envelope 统一，必须新增独立设计评审记录，不能在
04A中以顺手修正方式扩容； - 本评审当前无未解决的 P0～P3。