跳转到主要内容
当一个模型回复时，它不只是返回文本——它发出 tool_calls：带有真实的、 模型选中参数的具体调用。智能体防火墙 的 response 执行面恰好检查那些，就在它们离开模型那一刻、在它们到达你的 智能体循环之前。这是你过滤模型实际决定要做什么、用它实际挑选的参数的 那个执行面。 本页涵盖在 response 执行面上过滤的用例——何时选它而非 inbound、它增加的那一个判定变化， 以及它在一个流上的行为。关于完整的规则词汇表和判定语义，参见 规则 schema 与 判定。

​
1. 过滤 LLM 工具响应调用，参数在范围内

inbound 执行面 看到你声明的工具——只有 名称，还没有调用时参数。response 执行面看到模型发出的 tool_calls， 它们携带模型选中的参数。那正是在这里过滤的全部理由：它是唯一看到一个 客户端执行（非 MCP）工具的实际调用 + 参数的执行面，所以 参数子句、序列和运行状态规则 全都落在 response 上。 一行说清这个区分：
执行面看到用它来
inbound声明的工具定义让一个工具对模型不可见
response发出的 tool_calls + 参数过滤模型实际做出的调用
所以 inbound 回答哪些工具存在；response 回答模型用其中一个做了 什么。当一个工具在某些请求中正当出现但它的某一次特定调用危险时——或 当你只控制智能体循环而非声明的工具集时——使用 response（或把 stage 留空以覆盖两者）。
一条没有 stage 的规则在每一个执行面上运行，包括 response。仅当一条 规则应该只检查发出的调用时才钉到 response——例如一个在 inbound 执行面 上反正没东西可匹配的参数子句。参见 执行面。

​
2. 一个具体示例

总体上允许 shell.exec，但在它的 command 参数看起来具破坏性那一刻就把它 从模型的回复中剥除。在你的工作区控制台中，打开一条策略（或 创建一条）并添加一条钉到 response 执行面的规则： 
{
  "label": "block destructive shell calls",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
参数匹配器存在于 args_match_json 中——一个持有 {"clauses":[…]} 的 JSON 字符串，每个子句是一个 path / op / value 三元组（op 是 eq、 contains、regex、gt、lt 之一）。控制台表单为你构建它；这里展示原始 形态，以便字段名毫不含糊。 该工具仍被声明——模型仍能提议 shell.exec——但当发出的调用携带一个破坏性 command 时，防火墙在你的智能体看到之前就把那个 tool_call 从回复中移除。 一个良性的 shell.exec（比如 ls -la）原封不动地通过。这就是 response 执行面存在的目的——那个”允许工具，对调用设门”的模式；参数子句正是让它成为 可能的东西。
规则按优先级顺序评估，首个匹配生效。把一个窄的 allow 例外放在比一个宽 的 deny 更低的 priority 数字上，这样该例外先运行。参见 规则优先级。

​
3. 一个判定在 response 执行面上做什么

response 执行面检查每个发出的 tool_call 并就地重写回复。被保留的调用被 逐字节转发；只有匹配到的调用改变：
匹配到的 tool_call 在它到达你的智能体之前被从模型的响应中移除。与一个 inbound 拒绝——返回带有码 firewall_blocked 的 HTTP 400——不同， 一个 response 执行面的拒绝不会让请求失败；回复的其余部分（其他工具 调用、任何文本）照常通过，只是那个违规调用单纯缺席。
该调用参数中匹配到的子串被替换为引擎脱敏后的参数，清理后的调用被 转发——当工具没问题但模型把一个密钥或 PII 值放进了一个参数时很有用。 Sanitize 只脱敏工具调用参数；它绝不触碰工具返回的内容。如果引擎 没有东西可替换，该调用被剥除（故障关闭）。参见 脱敏响应。
人工介入挂起在 inbound 执行面上开启，而非 response。因此，一条首先 在一个发出调用上匹配的 pending_approval 规则被剥除（故障关闭） ——保留它会转发一个未经审查、没有人工决策的调用。把 HITL 挂起编写为在 inbound 上触发；参见 审批。
allow 和 audit 都转发该调用；audit 是通常的 default_verdict ——记录一切，不拦截任何东西，直到你准备好执行。
cap_cost 和 pending_approval 在这个执行面上是 inbound 概念。 cap_cost 在 response 上是惰性的（模型已经运行），而 pending_approval 解析为一次剥除而非一次挂起。把成本上限和 HITL 挂起放在 inbound 执行面上 ——参见 封顶成本 与 审批。

​
4. 流式：先挂起，再过滤

在一个非流式回复上，整个响应被一次性解析和过滤。在一个流上，一个模型的 tool_calls 作为逐索引的增量跨许多 SSE 帧到达——而一旦一个增量被转发， 你的智能体就已经拿到了它，它无法被收回。所以网关挂起工具调用帧：它们 绝不在流中途被转发。在流结束时，防火墙组装每个调用（名称 + 完整参数）、 评估它，并只发出幸存的调用。
内容帧仍照常流式传输——文本 token 在到达时就抵达你的客户端。只有 tool_call 帧被扣住以供评估，所以一个被拒绝或被脱敏的调用在组装好的工具调用被交付 之前就被过滤掉。判定和规则语义与非流式执行面完全相同。关于帧级细节，参见 流式内部机制 与 提供商流式。

​
5. 安全地上线它

控制台 Test 标签对一个样本工具调用运行一条策略，并返回判定、匹配到 的规则和原因——不派发任何内容，不持久化任何内容。在绑定一个密钥之前， 确认你的 glob 和参数子句匹配你想要的调用。参见 测试规则。
打开 影子模式，那么每个执行性判定 ——包括一个 response 执行面的拒绝——都被降级为 audit，原因前缀为 [shadow] would …。你在它改变任何一个回复之前，对照真实流量准确衡量 该规则本来会剥除什么。
每一次评估都写入一个带有判定、执行面、工具和匹配规则的防火墙事件。按 执行面 response 过滤 事件日志 以 查看你的规则在你预期的发出调用上触发。参见 分析。

​
6. 绑定策略以及谁能配置它

一条策略在某个密钥解析到它之前什么都不做。在控制台中通过在 密钥 上设置 firewall_policy_id 来 绑定，或将该策略设为工作区默认。解析：密钥绑定的策略（当它存在且已启用 时），否则工作区默认值——而一条被禁用的绑定策略会回退到工作区默认值。 参见 管理策略。 所有配置都在控制台中于你的会话下运行（/api/workspace/firewall/*）：
操作角色
读取策略、预设、discovered tools、SimulateMember
Dry-run（Test）、读取事件日志和运行汇总Developer+
创建 / 编辑 / 删除规则和策略Developer+

​
相关

验证参数

让 response 执行面过滤变得精确的参数子句。

脱敏响应

从一次调用的参数中脱敏密钥而非剥除它。

防火墙执行面

response 与 inbound、mcp 和 egress 如何对比。

拦截工具

inbound 对应物：在模型被提供一个工具之前拒绝它。

危险工具调用

response 过滤应对的威胁。

防火墙参考

完整的规则 + 匹配参考。