工具系统
工具只是一个函数吗？
执行函数只是工具的一部分。完整工具还包括给模型看的 schema、参数与输出验证、并发声明、权限与策略扩展点、取消信号、会话事件以及 UI 展示意图。工具系统的价值，是把不可信的模型提议变成受控的真实副作用。
问题 01
一条工具调用经历哪些阶段？
答案：调用先被记录，再解析和校验参数；pre-execute 决定允许、拒绝或询问；单调 guard 只能进一步收紧权限；execute waterfall 包裹真实执行；post-execute 可接受、阻断或替换结果；最终结果冻结、记录并通知观察者。
- 记录调用
tool/call在执行前进入会话，UI 可以立即显示 pending 状态。 - 解析与校验把模型 JSON 转成已验证参数；未知工具或非法参数走规范化错误路径。
- 准入与 Guardwaterfall 处理 allow / deny / ask；guard 只能拒绝，后续插件不能重新放行。
- 包裹执行
tools/execute适合超时、重试和指标；内部调用注册工具的 execute()。 - 结果处理post-execute 检查或替换结果，finalizeContent 执行定义拥有的最终内容约束。
- 提交结果冻结权威结果，触发
tools/result，写入tool/result并把附加上下文排入下一 Step。
问题 02
为什么能力要拆成 Definition、Provider 和 Consumer？
答案：因为“能力是什么”“能力怎样实现”“模型怎样使用”有不同的变化原因。Definition 固定调用语义；Provider 可以在本地、远程或沙箱中实现；Consumer 决定是否以及怎样把它暴露成模型工具。三者分开后，替换后端不需要改模型协议。
由此可以推导：增加“远程 shell”通常只需增加 Provider；增加“只允许读取的命令工具”通常是新的 Consumer；改变请求与结果语义才会触及 Definition。
问题 03
模型一次返回多个工具调用时，能全部并行吗？
答案：只有工具针对本次参数明确返回并发安全，才会进入有上限的滚动并发池；未声明、抛错或不可见的工具都按 exclusive 处理。exclusive 调用形成屏障，前面的并发组必须排空，后面的调用才能开始。
问题 04
工具权限究竟在哪里决定？
答案：没有单一的“权限开关”。工具可见性先限制模型能提议什么；pre-execute 处理会话级允许、拒绝或询问；guard 提供不可逆的最终拒绝；具体 Provider 和文件系统策略再限制真实副作用。每层回答不同问题。
安全边界：提示词不能替代执行时策略。模型遵守规则属于概率行为；Provider、guard 与沙箱限制真实副作用，才是可执行的安全约束。