一、管线认的是调用，不认调用者

人点的、模型直接调的、程序里写的——三种来源，一套注册表、一套规则。

实测：这些调用最终都落在同一批工具包上（tool-bash／tool-pwsh／tool-fs／tool-fs-search…），没有一条给程序用的旁路。

二、同一入口带来三件事

• 规则只写一遍：审批一条、沙箱一条，不必给每种调用方式各写一遍。
• 可以统一收紧：档位从 workspace-write 改成 read-only，两条路一起收。
• 账本完整：留痕落在同一本流水上，第 6 章的重建才成立。

三、如果不统一会怎样

每种调用方式各写一套规则 → 规则数量随调用方式增长 → 必然有漏。

而一旦有漏，最松的那条路就成了突破口——19 课 4-12 讲的正是【方便的工具反成漏洞】。

四、补丁的作用面也是分层的

7.3.4 的实验 A 想从顶层补丁去改预设内部的 tool-presentation 与 delegation， 结果各打印一行 patch: entry "xxx" not found，只警告并跳过。

这说明系统的分层是明说的：哪一层的东西，就在哪一层的写法里改——管线内外的边界也是同一件事。

五、动手 Demo：为什么不能绕开这条管线

假设程序里的调用能抄近路，会漏掉什么：

lost = ["审批", "沙箱", "超时与溢出", "观察留痕"]
for i, x in enumerate(lost, 1):
    print("  漏掉 %d. %s" % (i, x))
print()
print("  规则只写一遍, 所有调用者受同一套管")

实跑输出：

--------------------------------------------------------------------
为什么不能绕开这条管线
--------------------------------------------------------------------
  假设 PTC 程序里的调用能抄近路，会漏掉什么：

  关口           漏掉之后的后果
  --------------------------------------------
  审批           高风险动作没人确认就跑了
  沙箱           范围没人划，可能写到工作区外
  超时与溢出     一个卡死的调用能拖住整段程序
  观察留痕       事后查不到这次动作，无法重建
  --------------------------------------------

  所以规则只写一遍、**所有调用者都受同一套管**——
  不管调用者是人点的、模型调的，还是程序里写的。

四样漏一样，账就不完整——不完整的账谈不上调试与审计。 管线认调用不认调用者：这是【唯一入口】这四个字的实际含义。 补丁的 not found 警告也从侧面证明：分层是明说的，不装哑巴。

30 秒实验

1. 列出绕过管线会漏掉的四样，各举一个后果。
2. 解释为什么规则要写在进程级而不是会话级。
3. 想想【唯一入口】这四个字省掉了多少重复的规则。

常见误区

1. 错误：程序里调工具是内部调用，不必审批。——纠正：内部调用也是调用——管线不区分来源。
2. 错误：每种调用方式各配一套规则更灵活。——纠正：规则数量会随调用方式爆炸——必有漏，且最松的那条成突破口。
3. 错误：管线的存在让 PTC 变慢。——纠正：治理的成本固定——省下的往返依然省下。

• ☐ 下一节（7.3.4 动手实验：用同一任务比较 Native Tool Calling 与 PTC 的效果）

相关笔记

• PTC 不能绕过安全治理 —— 同一结论的前一站
• PTC 与 Pipeline：为什么不能绕开这条管线 —— 【唯一入口】的出处
• 当心那些使用方便的工具中存在的漏洞 —— 方便与漏洞往往是同一件事
• 🐳 DeepSeek Harness · 索引