凌晨两点，运维工程师盯着报警面板，手指悬在回滚按钮上。三小时前刚上线的DLP策略，正在阻断某个核心业务的API调用。这不是第一次了——每次调整安全策略，总有人在工作流里踩雷。

Pipelock的解法叫"捕获-重放"（Capture and Replay）。核心思路很简单：让新策略在投产前，先跟历史流量打一架。

打开网易新闻 查看精彩图片

代理层会记录所有裁决痕迹——URL verdicts、响应裁决、DLP裁决、MCP工具策略裁决，还有工具扫描裁决。每条记录包含输入摘要、裁决结果，以及会话和追踪上下文。如果配置了原始托管，加密载荷副舱还能存下完整数据包。

打开网易新闻 查看精彩图片

这些记录进入编译阶段，生成候选合约：对观察到的URL路径、MCP方法形态、参数模式做归一化描述。这里有个关键设计——路径归一化会限制基数。百万次/users/{id}请求不会生成百万条规则，而是被折叠成模式。运维可以手动固定或拆分被错误折叠的路径。

候选合约随后进入影子阶段。代理继续执行线上策略，同时让候选合约并行产出裁决。输出是一份"差异收据"：带签名的记录，标注候选策略与线上策略每一处分歧，以及分歧的严重程度和原因。

打开网易新闻 查看精彩图片

激活阶段分两步：批准（Ratify）和推广（Promote）。运维审查候选合约，把规则标记为执行、仅捕获或拒绝。批准生成contract_ratified证据收据。推广则将批准的合约变为活跃策略，写入带签名的意图和承诺收据，包含目标清单、先前清单、运维密钥和选择器。

整个链条是：观察 → 编译 → 审查 → 影子 → 批准 → 推广。每一步都产出下一步依赖的证据。等策略真正上线时，"惊喜"早被运维提前签收过了。