一、19 件怎么收到 5 件

• 人格与指令：留 persona（审查需要人格）。
• 读写与搜索：留 tool-fs、tool-fs-search（只读地看）。
• 执行：tool-bash、tool-pwsh——全去掉。
• 登记与交付：tool-todo、present——都留。
• 其余 11 件：goal／plan／web／delegation 等——全去掉。

结果是 5 件：四件干活，一件定人格。

二、两条关键取舍

① 执行类一件不留。只读就是只读——留一件执行工具，前面所有的边界讨论都白做。

② tool-ask-user 也去掉。审查不该半路停下来问人：它是一份一次交完的活；一旦能问，输出格式与节奏都不受控。

第 ② 条容易被忽略——看起来无害的工具，也可能破坏设计意图。

三、这是一个老规矩的 Agent 版

17 课的 5-18 封装化、访问修饰符 讲过同一个道理： 只对外公开必要的信息和步骤。

区别只在于：面向对象的封装，靠语言的关键字；Agent 的封装，靠装配清单里少写那几行。

四、少给工具的额外好处

• 模型的选择空间变小，跑偏概率下降。
• 工具表更短，提示段更稳（第 6 章的稳定前缀）。
• 出错时排查范围小，证据更容易读。

五、动手 Demo：只暴露审查真正需要的工具

Standard 有 19 件，审查预设留 5 件，逐类核对：

std, rev = 19, 5
print("  Standard 19 件 -> 审查预设 %d 件" % rev)
print("  去掉执行类 2 件, 其余 12 件与审查无关")
print("  只读的保证不是靠自律, 是靠工具表里根本没有写操作")

实跑输出：

--------------------------------------------------------------------
只暴露审查真正需要的工具
--------------------------------------------------------------------
  Standard 有 19 件，审查预设留 5 件。逐类核对：

  类别           Standard 里有                    审查预设
  -----------------------------------------------------------
  人格与指令     persona、agent-instructions      留 persona
  读写与搜索     tool-fs、tool-fs-search          两件都留
  执行           tool-bash、tool-pwsh             **全去掉**
  登记与交付     tool-todo、present               两件都留
  其余 11 件     goal／plan／web／delegation…     **全去掉**
  -----------------------------------------------------------

  两条关键：①执行类**一件不留**（只读就是只读）；
  ②`tool-ask-user` 也去掉——审查不该半路停下来问人。

执行类一件不留——这是只读能不能成立的分水岭。 tool-ask-user 也去掉：看起来无害的工具也会破坏设计意图。 少给工具不损失本事，反而让模型更不容易跑偏。

30 秒实验

1. 把审查预设在纸上写一遍，标出每一件工具对应清单上的哪一步。
2. 找出 Standard 里那些【看着有用但不属于审查】的件，数一数有几件。
3. 想想你自己的场景里，哪些工具是【宁可不要】的。

常见误区

1. 错误：多留几件无所谓，模型不一定用。——纠正：工具表就是权限边界——留着就代表可以调，「不一定用」不是安全保证。
2. 错误：只读靠提示词约束就够了。——纠正：提示是建议，装配是事实——写十遍【不许写文件】，不如工具表里没有写文件。
3. 错误：tool-ask-user 无副作用，留着方便。——纠正：它会打断一次交完的节奏——审查要的是一份完整报告，不是一个来回问答。

• ☐ 下一节（8.3.5 第四步：规定审查结果的输出格式）

相关笔记

• 第四步：规定审查结果的输出格式 —— 工具给了，还得管输出
• 封装化、访问修饰符-只对外公开必要的信息和步骤 —— 同一个道理的语言版
• PTC 与 Pipeline：为什么不能绕开这条管线 —— 工具一装就受管
• 🐳 DeepSeek Harness · 索引