波仔
🐳 第七章 从Tool Call到Agent Runtime
📄 一句话概括

程序里写的每一次工具调用，照样从统一管线那道门走——审批、沙箱、超时、留痕一样不少：PTC 换的是【谁在编排】，不是【谁在把关】。

📝 本节和前面几节的关系

上一节讲了 PTC 的好处。好处越大的改动越要追问一句：它绕不绕开规矩？这一节的答案是不绕。

一、两种调用，在管线眼里是同一种东西

模型直接发的 Tool Call 与程序里调的 Tool Call，注册在同一个注册表上。

实测：tool-bash／tool-pwsh／tool-fs 这些工具包，不管谁调用，都从这几处挂上来。

二、规矩挂在哪个平面

规则类插件（审批／沙箱／超时／留痕）挂在进程级的宿主平面上。 PTC 的运行时与呈现方式挂在会话级。

下层管得住上层，反过来管不着——3.2.2 讲作用域时立的规矩，在这里正好用上。

三、如果真绕开了会怎样

四样里任意漏一样，账就不完整——不完整的账，谈不上调试与审计。

四、这不是为难 PTC

4.6 就下过结论：管线的定位是所有动手路径的唯一入口。

PTC 是新写法，不是新出口——多一条写法，不多一条后门。

五、动手 Demo：程序里的每一次调用，一样要过闸

一段 PTC 程序里写 3 次调用，看它们怎么被管：

calls = ["read_file", "read_file", "run_shell"]
for i, c in enumerate(calls, 1):
    print("  第 %d 次 %-12s -> 过审批/沙箱/超时/留痕" % (i, c))
print()
print("  管线的定位: 所有动手路径的唯一入口")

实跑输出：

--------------------------------------------------------------------
程序里的每一次调用，一样要过闸
--------------------------------------------------------------------
  一段 PTC 程序里写了 3 次工具调用，看它们怎么被管：

  程序里的调用          过不过统一管线     谁在管
  --------------------------------------------------------------------
  第 1 次 read_file     过                 审批 + 沙箱 + 超时 + 留痕
  第 2 次 read_file     过                 同上
  第 3 次 run_shell     过                 同上，沙箱档位决定能不能跑
  --------------------------------------------------------------------

  理由：管线是所有动手路径的**唯一入口**（4.6 讲过一面）。
  PTC 换的是【谁在编排】，**不是【谁在把关】**。

三次调用过三次闸——程序里的调用没有豁免权。 规矩写在宿主平面，调用方式写在会话平面——下管上，不是上管下。 留痕完整，第 6 章的【可重建】才站得住。

30 秒实验

  1. 数一数一段 3 次调用的 PTC 程序要过几遍管线。
  2. 在配置树里找出审批与沙箱这两个规则类插件的位置。
  3. 想想为什么规则写在进程级、而呈现方式写在会话级。

常见误区

  1. 错误：程序里调工具就不用审批了。——纠正：一样过统一管线——调用者换了，门没换。
  2. 错误：PTC 是更高级的写法，权限应该更宽。——纠正：写法与权限是两件事——权限由沙箱档位定，与谁在编排无关。
  3. 错误：限制 PTC 会拖慢效率。——纠正：治理的成本是固定的——省下的是往返，不是关口。
自测三问（点开对答案） 1. 程序里的调用过不过统一管线？ —— 过。**管线认的是调用，不认调用者**——三次调用过三次闸。 2. 规则为什么挂在宿主平面？ —— 因为规则是**进程级**的，PTC 的运行时在会话级——**下层管得住上层**。 3. 如果绕开管线会漏掉哪四样？ —— 审批、沙箱、超时、留痕——**任意漏一样账就不完整**。

相关笔记