corespeed 2小时前 · 2026-10-05 10:27:12 · 2 阅读

推出 Smart Approval：为 AI Agent 操作设立的审批关卡

本月早些时候发布 CoreSpeed 时，我们称它为 agent 的操作系统：一个集中管理 agent 能做什么、能花多少钱、以及记录它们工作成果的地方。我们还说过，下一个模块是审批。今天它正式上线了，以公开测试版的形式。Smart Approval 负责决定你的 agent 可以做什么：把需要人来把关的操作拦下来交给人类，其余的直接放行。

观看 Smart Approval 发布视频

调用与执行之间的一道闸门

现在，agent 通过 CoreSpeed 发起的每一个工具调用，在执行前都要经过一道检查点——无论是发 Slack 消息、退款，还是合并 PR。Smart Approval 就是这道检查点：它是「agent 决定行动」和「行动真正发生」之间的中间件。

四个 agent（Sam 笔记本上的 Claude Code、Priya 笔记本上的 Codex、用 agent SDK 搭建的支持机器人，以及一个夜间定时任务）都把工具调用发到 Smart Approval。它持有团队规则「超过 $500 的退款要先问我」，让 Jev 对每笔写入操作进行判断，并在调用到达 Stripe、Slack、GitHub、Gmail 或 Intercom 之前给出放行、询问或拒绝的答复。选择询问时，会向该 agent 的负责人发送一张卡片。

因为它坐在这个位置上，而不是内嵌在某个 agent 里，所以是谁发起的调用并不重要。这台笔记本上的 Claude Code、另一台上的 Codex、你用 SDK 搭的支持机器人、凌晨三点无人值守运行的定时任务——全都走同一道闸门、受同一套规则约束。规则只需写一次，对整个团队生效。大多数调用照常执行，什么都不变；只有规则中点名的那些操作，才会停下来等人处理。

Claude 不是已经有这功能了吗？

有一部分功能是重叠的，值得说清楚。Claude Code 的 auto 模式会在每次工具调用前跑一个分类器，而且可以配置：你可以描述自己信任的基础设施，用自然语言添加自己的规则，并通过 managed settings 推送给所有开发者。Codex 的 Approve for me 也类似，用一个审查 agent 加一份自己的策略文件。如果你的 agent 就是团队笔记本上的编码 agent，直接用这些就够了。

它们只是客户端内部的护栏。Smart Approval 则是在工具调用之前设的一道关卡，这一区别体现在三个地方：

所有 agent，同一套规则。 自动模式的规则只约束 Claude Code，Codex 有自己的规则，而你自建的支持机器人和夜间任务完全没有规则。我们的关卡位于工具调用执行处，因此所有 agent 都必须遵守同一套规则。
"询问人类"是最终裁决，而非变通手段。 自动模式的分类器只回答"允许"或"阻止"。若你设定"超过 500 美元的退款需人工批准"，大额退款会被拦截：Claude 会被告知原因并尝试其他路径，你需输入包含该退款信息的批准指令来解除拦截。暂停等待真实提示的规则匹配工具名称或命令前缀，要么拦截所有退款，要么全不拦截。而在 Smart Approval 中，"询问"本身就是一种结果：1200 美元的退款会暂停等待点击确认，40 美元的则直接放行，且没有任何成员能为自己的调用放宽该规则。
始终有人在响应。 开箱即用状态下，当 Claude Code 需要人工介入时，它会在会话内提问；若以无头模式运行，无人能答的问题将直接判为拒绝。你可以编写 hook 将提示转发到 Slack，确实有人这么做，但这是你需要为每个 agent 构建并维护的代码。Smart Approval 替所有人处理这件事：卡片会送达 agent 所服务的成员，通过 Slack、邮件或仪表盘，每项决定均记录在团队的活动日志中。

谁来决策

每次写操作都会提交给 Jev，即 TypeSafe 的 System One 模型，同时附带你的规则和调用数据。聊天模型通过散文式推理得出答案，而 System One 模型则一次遍历回答一组固定问题，每个答案均附带校准后的概率。读操作永远不会到达该模型。

Jev 看到的内容包括：你的规则（超过 $500 的退款请求需先询问；默认宽松模式）、调用详情（stripe__stripe_api_write，创建 $1,200.00 退款）、调用方身份（Sam 的客服机器人）以及近期使用记录；绝不会读取 Agent 的对话内容。Jev 回答两个问题：你的规则要求对该调用做什么（允许 4%、询问 93%、拒绝 3%，置信度 0.91）？是否有人在试图诱导 Agent 绕过检查，即提示注入（2%）？答案是“询问”：调用暂停，卡片发送给 Sam。低置信度会触发询问，看起来像注入攻击的允许操作也会触发询问。

目前我们使用 Jev 主要基于三个原因。首先，它足够快，能实时拦截每次写操作：判定过程最多耗时几秒，Agent 几乎无感。其次，其输出为数值，使得将数值转化为最终决策的阈值具有确定性和可审计性；低置信度的回答会转化为询问请求，而非盲目猜测。最后，由于 Jev 仅回答类型化问题，我们只向其发送可信任的事实（你的规则、调用详情、发起者身份），绝不传递 Agent 的对话内容。

实际形态

只需一行策略描述，并指定卡片的落地位置：

审批设置，步骤 1，规则：Agent 应就哪些事项询问你？策略内容为：在发放超过 $500 的退款前询问我。下方，当某操作未被规则覆盖时：宽松（已选中）、均衡、严格、锁定。

客服 Agent 审核一笔退款申请，试图发放 $1,200。调用在执行前被拦截，卡片发送至 Slack 中的审批人。（客户信息和资金均为演示数据。）

智能体：CoreSpeed · Stripe，发起退款 · 需要审批。我确认了一笔 $1,200 的重复扣款并申请退款。根据你的 $500 策略，CoreSpeed 暂停了这次调用以等待审批。Slack 通知：CoreSpeed，有一项操作正等待你处理。

Slack 中的 CoreSpeed 卡片：有一项操作正等待你处理。你工作区中的一个智能体想要调用 stripe__stripe_api_write。你的策略要求此项操作需先征询你的意见。目前尚未执行任何操作。批准并运行、拒绝、在控制台中查看。

只有人才能按下这个按钮：智能体无法批准自己的调用，它的 Slack 工具也无法发送卡片或写入你的审批频道。你批准之后，那笔退款就会继续执行，智能体从暂停的地方接着往下跑：

智能体：CoreSpeed · Stripe，退款完成。那笔 $1,200 的重复付款已退还给 Maya。

下一步计划

Jev 只是第一个裁决者，不会是唯一的。接下来，策略会变成一份可以像代码一样版本管理的规范，每条规则都可以指定由谁裁决：Jev、某个 LLM、你自己的分类器，或者纯确定性逻辑。裁决之后的流程保持不变：工具执行前同样会暂停，Slack 里同样会收到卡片，同样只需一键放行。

卡片本身也会更智能。目前它只显示工具名称和调用参数，具体数值要去控制台查看。接下来，每张卡片都会根据其调用定制生成，比如退款卡片会直接在你审批的地方显示客户和金额。

立即上手

Smart Approval 今天起向所有 CoreSpeed 组织开放公测。默认关闭，你需要到控制台 → Approvals 手动开启，在此之前你的智能体不会有任何变化。完整文档见 corespeed.io/docs/approvals，也欢迎到 Discord 告诉我们你的使用体验。

CoreSpeed。智能体负责干活，决定权在你手中。Smart Approval，公测中。

原始来源： corespeed