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。
This commit is contained in:
@ -50,7 +50,7 @@ test('任何无 id 的消息都不回响应', async () => {
|
||||
assert.equal(out, null);
|
||||
});
|
||||
|
||||
test('tools/list 只暴露 name/description/inputSchema(多带的字段会被客户端拒绝)', async () => {
|
||||
test('tools/list 只暴露 name/description/inputSchema/annotations(多带的字段会被客户端拒绝)', async () => {
|
||||
const out = await handleMessage({ jsonrpc: '2.0', id: 2, method: 'tools/list' }, makeCtx());
|
||||
assert.equal(out.result.tools.length, 2);
|
||||
for (const t of out.result.tools) {
|
||||
@ -58,6 +58,23 @@ test('tools/list 只暴露 name/description/inputSchema(多带的字段会被
|
||||
}
|
||||
});
|
||||
|
||||
test('★ annotations 必须透传(ZCode 靠它算风险等级,plan 档据此放行)', async () => {
|
||||
// 漏传的后果不是「少个提示」而是「工具在该档下全被拒」:
|
||||
// ZCode 的 MCP 工具 needsApproval 恒为真,只有 plan 档的
|
||||
// 「!destructive → allow」能放行,而 destructive 正是从 annotations 读的。
|
||||
const ctx = {
|
||||
tools: [{ name: 'read_inbox', description: 'd', inputSchema: {}, annotations: { readOnlyHint: true, destructiveHint: false } }],
|
||||
call: async () => 'x'
|
||||
};
|
||||
const out = await handleMessage({ jsonrpc: '2.0', id: 3, method: 'tools/list' }, ctx);
|
||||
assert.deepEqual(out.result.tools[0].annotations, { readOnlyHint: true, destructiveHint: false });
|
||||
});
|
||||
|
||||
test('★ 反向对照:没有注解的工具不该凭空多出 annotations 字段', async () => {
|
||||
const out = await handleMessage({ jsonrpc: '2.0', id: 4, method: 'tools/list' }, makeCtx());
|
||||
assert.equal('annotations' in out.result.tools[0], false);
|
||||
});
|
||||
|
||||
test('tools/call 成功时回 content 文本数组', async () => {
|
||||
const out = await handleMessage(
|
||||
{ jsonrpc: '2.0', id: 3, method: 'tools/call', params: { name: 'read_inbox', arguments: {} } },
|
||||
|
||||
Reference in New Issue
Block a user