审批配置

你已经有审批系统了。模块2构建了可辨识联合类型，包含interactive、background和delegated模式。这回答了一个问题：who决定

它没有回答另一个问题：具体适用what策略

CI 运行时使用mode: "background"自动审批命令。好吧。但你也要屏蔽任何写入.env，无论用什么模式。你希望bash命令被更严格的操作系统级沙箱包裹，无论使用什么模式。这些规则不符合可辨识联合类型。他们住在一层之下。

本课奠定了第二层（基于事件的拦截），并展示了两种模型的交汇点。事件图层在构建过程中是概念性的，但现在就值得看看形状，这样你需要时可以接线。

学习成果

你可以描述两种审批模式，识别哪一种适合哪种使用场景，并解释它们如何在生产Harness中组合使用。

两个模型

配置模型就是你现在的配置：

type ApprovalConfig =
  | { mode: "interactive" }
  | { mode: "background" }
  | { mode: "delegated"; trust: string[] };

设定在启动时。在一次治疗过程中不会改变。答案who decides。

事件模型是下面的层：

harness.on("tool_call", async (event) => {
  const { toolName, input } = event;

  if (toolName === "write" && input.path.endsWith(".env")) {
    return { block: true, reason: "Cannot modify .env files" };
  }

  if (toolName === "bash") {
    event.input.command = `sandbox-exec -p '(deny default)' ${input.command}`;
  }

  return { block: false };
});

每工具调用都有火。扩展可以阻挡、修改或穿透。答案what 策略 apply。

何时使用哪种

使用场景	配置	活动
CI运行，自动审批所有内容	`mode: "background"`	过度杀戮
子 Agent从父 Agent那里继承信任	`mode: "delegated"`	关卡错了
块写入特定文件	太粗糙了	文件级策略
操作系统级沙箱中的封装命令	无法修改输入	输入修改
项目专用安全规则	仅限全球	每个项目扩展

配置层是整个会话的操作模式。事件层用于细粒度、通常针对项目特定且常可插拔的策略。它们有些重叠。它们不会互相替代。

它们如何结合

真正的Harness同时使用：

const approval = createApproval({ mode: "interactive" });

harness.on("tool_call", async (event) => {
  if (event.toolName === "write" && event.input.path.endsWith(".env")) {
    return { block: true, reason: "Protected file" };
  }
});

配置里写着“交互模式，人工审批”。事件处理者说：“无论人类如何审批，都不要碰.env。”该事件在配置后但工具运行前触发。纵深防御。

这很重要，因为操作模式和策略往往来自不同的地方。模式由负责控制Harness的人决定（CI、开发人员、委派子 Agent）。策略由项目设定（.env敏感，构建目录为唯读，任何涉及生产凭证的内容都需要系统层面的沙箱）。一个配置旋钮无法同时处理两种决策而不容易打结。

**注意：事件层插入模块11**

我们将在第11模块的扩展性工作中构建实际事件总线，生命周期事件是主要扩展点。审批事件是生命周期事件的一种特定类型。一旦总线存在，审批拦截器就是几行代码，订阅tool_call。

随行教学缺少什么

你目前构建的Harness包含配置层。它还没有事件图层。没关系。配置层涵盖了课程需要教授的大部分情况。

添加事件图层的做法如下：

在Harness（模块11）中构建一个小型类型事件发射器
在每个工具运行前，从Agent 循环发出tool_call事件
让订阅者返回{ block, reason }或修改输入
把一个阻止写入硬编码文件的用户接线，作为烟雾测试

工作量不大。它不在这个模块里，因为前提条件（事件、扩展）属于扩展性故事的其他部分。当你进入模块11时，基于事件的审批成为事件总线有用的唯一具体例子。

动手试试

这是一个概念课。自我检视：

对于上表中的五个用例，请决定哪种模式最适合
勾勒出一个两种模式同时适用的单一用例。每一层都做什么？
找出你参与过的一个项目，事件审批本来会发现真正的错误。规则会是什么？

提交

这节课没有代码。事件层出现在模块11。

完成标准

[ ] 你可以描述配置方法及其解答
[ ] 你可以描述事件的方法及其解决方案
[ ] 你可以根据具体用例选择哪一个
[ ] 你可以勾勒出两者如何结合进行纵深防御

**注意：建立一个风险评分自动审批系统**

二元认可和拒绝的做法很粗糙。试试一个riskScore(command)函数，返回一个从0到100的数字。评分因子：写入磁盘加30，网络访问加20，文件删除加50，修改配置加40，只读0。设定一个门槛，比如说40。下面是自动审批的。用户提示词上方。把每次自动审批记录下来，方便之后审计。添加--risk-threshold标志，方便用户调整舒适度。现在想办法用不同于rm -rf /的方式给rm -rf /tmp/test评分，而不只靠关键词评分。

审批配置 ​

学习成果 ​

两个模型 ​

何时使用哪种 ​

它们如何结合 ​

随行教学缺少什么 ​

动手试试 ​

提交 ​

完成标准 ​