Tool Store 对齐
1. Tools Store 语义
Tool Store 管「有什么能力、谁能用、什么条件」。不实现业务逻辑,不代理 tools/call。
2. 交互流程图
配置服务存定义。ADK 拿定义去执行,值写在运行时 state。
3. 待解决问题
| 编号 | 问题 | 当前分歧或影响 |
|---|---|---|
| Q1 | Prerequisite 的语义是什么 | 产品关注流程顺序;工程关注前置结果是否满足,而不是仅仅调用过。还未确定是检查结果为真、变量已 set,还是二者组合,以及是否有 TTL |
| Q2 | Sandbox 如何处理 prerequisite | 是提供测试 fixture 预置 state,还是在 Sandbox 中完整执行前置 Tool;会影响测试数据和真实 outbound 次数 |
| Q3 | MCP server 的 onboard 边界 | 研发预配 endpoint/credential 的具体入口、责任团队,以及业务方没有 MCP 时的接入方式 |
| Q4 | 自动 Risk 检测 | 检查哪些字段、如何保证 SLE <5s、R3 如何与 Approval Center 对接 |
| Q5 | Session 语义 | idle、多 session、变量 TTL,以及和长期 Memory 的边界 |
| Q6 | Variable 命名空间 | 业务入口、KB、Skill 之间如何隔离和展示同名变量 |
| Q7 | Derived variable | 谁可以配置、表达式校验范围、是否需要调试能力 |
| Q8 | FE Tool 协议 | 组件注册、版本兼容、错误码、回传 data/displayData、跨业务统一协议 |
4. 配置面:业务语义的实体抽象
Skill
│ 占用
▼
MCPServer ◄──target── Tool ──io──► Variable(名字/来源;值在运行时 state)
研发预配 │
只服务 type=mcp ├── schema:参数长什么样
├── io:参数和 variable 怎么绑
├── target:打到哪
└── risk / status / enable:能不能用Tool 四条业务语义:契约(schema / io)、指向(target)、治理(risk / status / enable)、被谁用(skill)。
- target:mcp 才指向 MCPServer;fe / system 指向组件或本地函数
- skill:Skill 绑了哪些 Tool;改 MCP 前靠它 block
- io:入参从哪条 variable 来、出参存成什么名。index 是扫 io 的视图,值在运行时 state
5. 执行面的实体抽象
ADK 消费的就是配置面那份 Tool。
resolve 列表 本轮能用的 Tool(registered + enable;common 或已占用)
运行时 state variable 的值(bill_amount=120)
执行器 按 type:mcp tools/call / FE long-running / 本地函数
流程闸 call 前查 state(运行时语义,不是查配置库)流程:
一次请求 → resolve 一次(本轮不再换配置)
→ 按 type 做成可 call 的对象
→ call 前:io 填参;过流程闸
→ 打 MCP / FE / 本地
→ call 后:persist_as 写入 stateSandbox 和生产共用执行器和判断条件,只换测试地址和凭证。
6. 两条调用路径
① 登记时 tools/list 写库;之后页面和 ADK 都读库。② resolve 拿列表。③ call 不经过配置服务。
7. 工具执行依赖
数据依赖:B 的入参要用 A 的出参。配在 Tool.io.bound_to。A 没跑成功、state 里没有那个值,B 填不了参。
流程依赖:B 的入参不需要 A,但仍须 A 先成功(核身后再转账)。io 拦不住,必须在 ③ call 前另查。
运行时查 state(kyc_passed=true),不查「调用过」——调失败也有记录。不满足则 PREREQUISITE_NOT_MET。Store 不自动帮跑前置 Tool。
判断不能挂在单次用户请求上(KYC 和转账常跨轮)。
默认挂在 Skill 一次激活;要跨 Skill 再读跨轮 state。配置面只存边、查环、改 MCP/输出则 block。语义未确认(Q1/Q2)。