第 6 卷
这背后真正的变化是：你不再把“调用一个工具”理解成简单调一个函数，而是看成穿过一条关卡固定的流水线，每关能做什么、不能做什么，都是结构说了算。谁能拒绝、谁能改写、谁能
只观察，都在流水线中定义好了。
这，就是工具流水线的本质——一次调用是一串职责固定的关卡，每关权限由结构定死，与调用者无关。
流水线管住了工具调用，程序执行本身的隔离却是另一道题——下一讲，我们讲跨平台进程沙箱。
注：本讲 GitHub 链接
调用；第二组把挂载顺序倒过来（先拒绝、后弃权），再跑一次。对比两组输出：挂载顺序变了，结果会跟着变吗？这印证了守卫的哪一条性质？
动手前两个提醒：
两组对照请放进一个独立的函数（比如 compareGuardOrder(root)），再在 main()
的 offBlock() 之后调用它——独立函数里守卫变量想起什么名字都行，不会与 demo 已声明的 offGuard / offPermissive 撞名；
这个函数用 async function 声明（函数声明会提升，写在文件末尾也能被 main() 调用）；若写成 const 箭头函数，要放在 main() 定义之前。
小改动：在 code-mode-demo.ts 的 codeView() 里、“让模型写一段程序，一次跑完”那段 run_code 调用之前，注册一个监听器：
复制代码
| 1 | constoffLog = root.on('tools/post-execute',async(exec, _result, next) => { |
|---|---|
| 2 | console.log(' [post-execute]', exec.name) |
| 3 | returnnext() |
| 4 | }) |
重跑 npm run start:ch06:code，看那段输出里多出来的打印，回答两个问题：打印里一共出现了哪几个工具名？顺序上，外层的 run_code 排在子调用的前面还是后面？为什么
会这样？
一个提醒：看完那段输出后调用 offLog() 注销监听器——不注销的话，后面“守卫管子调用”那一段也会被打上同样的打印。
欢迎把你的运行结果分享出来。如果你觉得这节课对你有帮助，也欢迎分享给其他朋友，我们下节课再见！
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。