1.4 KiB
1.4 KiB
当前行为与缺口
当前实现
requestCrossConversationReply()是sendCrossConversationMessage()的expectReply包装，因此公开工具合并不需要新增通信机制。- 正式 MCP 与 Codex App 备用 dynamic tools 各自复制 description 和 inputSchema。
server.js已经导入正式CCWEB_MCP_TOOLS，可以直接按白名单派生备用定义， 无需增加新的契约模块。- pending reply 已持久化 requestId、来源/目标、hopCount 和 replyText，可向后兼容地新增
originalRequest。 - 来源忙碌时 ready reply 会保留，空闲后由 flush 逻辑投递；该行为必须保持。
已观察失败
- 模型在明确要求“完成后汇报/最终验收”的任务上调用了单向发送工具。
- 同一模型此前使用过自动回传工具，说明仅靠两个工具名称仍不能稳定表达选择规则。
- 某次自动回传正文只是“完成定位、准备修改”，目标后来继续执行；来源续跑需要明确检查完整性。
设计结论
- 工具选择必须从“选两个近似工具”改为“调用一个工具时填写必填枚举”。
- 新公开契约不提供默认值；内部兼容层可宽容旧调用。
- 目标与来源的运行提示都必须携带通信模式和关联上下文。
- 提示优化无法完全替代任务完成协议；本任务不扩大到生命周期重构。