|
|
3a6d572020
|
feat(zcode): 工具加 MCP 注解 + headless 档位映射改为 plan（否则一个工具都用不了）
## 逆出 ZCode 的 MCP 权限判定，并据此让工具真的可用
逐字逆自 CLI 产物：
Ari(): annotations.readOnlyHint === true → riskLevel "low"
annotations.destructiveHint === true → riskLevel "high"
needsApproval = true ← **硬编码为真，与注解无关**
checkBuildMode(): needsApproval || destructive || sideEffectScope !== "none" → ask
checkPlanMode(): permissionName === "mcp" && !destructive → allow
两条合起来的结论不直观但很关键：
- **build 档下每一个 MCP 工具都要审批**（needsApproval 恒真），而 headless
模式没有交互式审批客户端 ⇒ 全被拒。实测：模型连 read_inbox 都调不动，
只能从提示词里猜；更糟的是它**绕道**用 Bash 去读网关的 sqlite WAL 文件
（它自己在回信里如实交代了这件事）。
- **plan 档下只要不声明 destructive，MCP 工具直接放行**。
于是两处改动：
1. `lib/tools.mjs` 给每个工具加真实注解（读类 readOnlyHint，写类
destructiveHint:false——它们确实不破坏任何东西）；`lib/mcp-rpc.mjs` 透传
annotations。**漏传不是"少个提示"，而是工具在该档下全被拒**。
2. `src/turn-mode.mjs` 的 workspace 档映射从 build 改为 **plan**。
build 在本环境等于「什么都不能做」，那不是保守而是不可用；plan 才是真的
fail-closed：危险的自带工具被平台直接拒，能用的只有我们声明为非破坏性的工具。
日志会明确写出为什么退档。可用 `AGENTMAIL_ZCODE_MODE_MAP` 覆盖
（平台修好钩子后只改配置就能恢复 build，不必等发版）。
## 真模型验证
场景 A 的判据同时加强：**正文本标记只出现在邮件正文里**（驱动的提示词只带主题
与 mail_id），所以模型必须真的读信才可能答对。通过 —— 约 20-30 秒一轮。
反过来说，早先那版「通过」是假的：标记在主题里，模型从提示词抄一遍就行。
## 仍然做不到的（见 README 已知缺口）
授权桥（PermissionRequest 钩子）在本版本（3.10.2 / CLI 0.16.5）**不可用**：
有时根本不触发，触发时在 ~5ms 内失败且**命令从未被 spawn**
（用「钩子写 marker 文件」的副作用验证，process 与 command 两种类型都一样）。
所以 workspace 档「危险操作问人」目前在 headless 下无法实现。
单元 329/329。
|
2026-09-12 16:49:28 +08:00 |
|
