Hook 与插件治理：可扩展但不失控
这一章回答一个工程问题：你如何开放扩展点，同时保证主链路稳定、可诊断、可裁决。
入口：
1) 注册期治理：冲突不覆盖，必须拦截并留诊断
建议做到：
- gateway method / http route / command 冲突时明确拒绝
- 同 ID 多来源时按固定优先级裁决，并输出原因
- memory slot 等排他能力必须单选，避免运行时语义不确定
2) 执行期治理：两种 Hook 运行模型
- 观察型（void）：并行执行，吞吐优先；单个 hook 失败不拖垮主流程
- 可修改（modifying）：按 priority 顺序执行；合并规则稳定且可预期
3) 主链路注入点：放对位置比“能注入”更重要
建议至少覆盖四个点：
- Agent 启动前（prepend context / system prompt 等）
- 工具调用前（改参/阻断，形成“最后一道闸”）
- 工具调用后（审计/指标，成功与失败路径都触发）
- Agent 结束（汇总快照、耗时、结果）
4) 故障隔离：默认 catchErrors
工程建议：
- 默认 catchErrors=true：单插件报错只记日志
- 需要定位问题时再临时关掉 catchErrors，让问题暴露得更快
验收清单
- priority 高的 hook 先执行，可修改结果可预测。
- 观察型 hook 并行且不阻塞主回复。
- before_tool_call 支持阻断与改参；after_tool_call 在失败路径也触发。
- 注册冲突会产出可读 diagnostics，而不是静默覆盖。