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