如何防止AI Agent“失控“？Evenfire Human-in-the-Loop审批机制完全指南-MJ Magnets

【免费下载链接】evenfire

Evenfire is an intelligence layer platform for running LLM agents that take real actions, on your infrastructure

项目地址：https://gitcode.com/gh_mirrors/ev/evenfire

AI Agent 一旦能执行 shell 命令、发起 HTTP 请求，"失控"就不再是假设。Evenfire 是一个完全开源的 LLM Agent 智能层平台，它的 Human-in-the-Loop 审批机制内置于运行时：任何高危工具调用都会自动暂停，等待人类在桌面端或 Slack、Telegram 里点击"Approve"，任务才继续执行——让 Agent 大胆行动，但每一步都在你的控制之下。

为什么 AI Agent 需要一道"刹车"

大模型会被误导、会幻觉、会"好心办坏事"。当 Agent 拥有shell_exec、http_request这类工具时，一次被注入的提示词就可能让它删除文件、泄露数据。

Evenfire 的安全模型建立在一个简单前提上：永远不完全信任模型。其中第一道防线就是审批门（approval gate）：

高危动作必须等待人类确认。命令执行、出站 HTTP、浏览器控制都被审批拦截——任务会挂起，直到有人在频道里点下批准，且回调经过签名校验。

它不是让你事后审查日志，而是让风险动作在执行前停在一位人类面前。

审批机制如何工作：一个4步闭环

整个流程非常简单，官方文档 tool-call-end-to-end 把它描述为一个时序：

Agent 决定调用工具—— 比如用户说"帮我查一下数据库里有哪些表"，Agent 选择了某个 MCP 工具；
策略命中，任务挂起—— 审批门拦截调用，任务进入waiting_approval状态，等待不消耗执行预算；
人类做出决定—— 在 Desktop App、Slack、Telegram 上点 Approve 或 Deny；
运行时继续或中止—— 批准后工具执行并生成结果；拒绝则任务终止，模型收到拒绝原因。

下面是 Evenfire 桌面端中真实的审批卡点界面：MCP 工具调用被挂起，等待人工批准 🛑

几个值得注意的工程细节：

审批是"挂起"而非"取消"：任务状态持久化在会话存储中，Pod 重启后未决审批依然有效，不会丢单；
一次批准可以覆盖后续调用：可以选择"本次对话内一直有效"、"对该工具长期有效"，或"对整个 MCP Server 有效"，避免反复打断；
超时自动拒绝：通过CLERUM_APPROVAL_TIMEOUT可设置未应答审批的自动拒绝时限，防止任务无限挂起。

哪些工具调用默认需要审批？

Evenfire 的审批默认开启（CLERUM_ENABLE_APPROVAL默认为true），无需任何配置就生效。默认的拦截范围如下：

工具类别	默认行为
所有 MCP 工具（连接器）	一律需要审批，无法通过 per-tool 配置豁免
`shell_exec`（执行命令）	需要审批
`http_request`（出站 HTTP）	需要审批
`cron_manage`（定时任务）	需要审批
`browser_open`/`browser_navigate`	需要审批
`workflow_trigger`（触发工作流）	需要审批（来自 Telegram/Slack/Teams 的任务除外）
其他原生工具（文件读写等）	无需审批

也就是说：能"破坏现场"的工具全部默认设卡，低风险工具保持流畅，这是安全与效率的平衡点。

三种审批配置方式：Default / Required / Skip

在 Control UI 的 Agent 详情页，有一个Per-Tool Approval编辑器，可以为每个原生工具单独设置三档策略：

Default（跳过）—— 使用工具内置的默认值；
Required（强制审批）—— 把原本不需要审批的工具也拦下来；
Skip（跳过审批）—— 把默认需要审批的工具放开。

⚠️ 注意：如果你把shell_exec或http_request设为 Skip，编辑器会弹出风险提示——这不是摆设，而是提醒你确认已有其他防线（比如CLERUM_HTTP_ALLOWLIST域名白名单）。

这些设置最终写入HostCRD 的spec.approval字段（详见 Host CRD 文档），是"配置即代码"的一部分，可以走 Git 评审和 GitOps 流程。

谁有权批准？三种审批人策略

通过spec.approval.defaultPolicy控制审批人的范围：

策略值	含义	适用场景
`cli_only`	只能通过 HTTP / 管理界面审批	无人值守环境
`channel_users`	任何已授权的频道用户都可审批	团队共享的 Agent
`designated_approvers`	仅白名单中的指定审批人	生产环境、敏感操作

在哪里审批？人应该出现在哪

Evenfire 的设计哲学是审批请求跟着人走，而不是让人去找系统：

表面	典型场景
Desktop App	运维人员盯着实时任务，聊天内直接 Approve/Deny
Telegram / Slack	手机上随时处理，按钮一键决策
Control API	自动化集成与测试

批准或拒绝本身就是一次带范围限定的 RPC 调用（host:approval:write），意味着"批准人"也是一个被鉴权的身份，而不是随便一个用户。Slack/Telegram 的回调还会经过签名验证（Telegram secret token、Slack HMAC），防止伪造审批请求。

批准之后，任务无缝继续，执行步骤会以进度形式呈现回聊天界面：

进阶：Guardrails 与审批的联动

除了内置审批门，Evenfire 还支持在 Host 上配置可选的 Guardrails（护栏）规则块，用allow / ask / deny三种决策精细控制每次工具调用：

deny—— 直接拦截，模型收到 "Blocked by guardrail policy"；
ask—— 挂起为一条待审批项，描述为 "Guardrail requires approval"；
allow—— 放行，但仍要过正常的审批门（护栏不能绕过审批）。

判定规则是最严格的决策获胜：deny > ask > allow，一条宽泛的 allow 无法覆盖一条精确的 deny。而且对无人值守任务（cron、内部任务）有一个重要的安全默认：ask会直接变成拒绝——没有审批人可用时，宁可停也不放行。

工作流层面：审批不止于单次工具调用

审批机制同样覆盖了多步工作流（WorkflowRecipe），分两层：

步骤级审批（requiresApproval）：给工作流的某个步骤加上审批门，它会在执行前暂停，等待指定用户或团队成员的显式批准，还支持timeoutSeconds超时自动过期。适合"向客户频道发帖"、"写生产系统"这类不可逆操作；
部署级审批：带有外部出站（egress）绑定的 Recipe 会被风险分级，默认要求操作员审批后才能部署，通知中会列出每个出站目标的主机名、端口和协议，供操作员核实。

聊天频道里的审批回调由 workflow-approval-request-reader 服务统一接收、验签、归一化后再提交给对应运行时，完整链路可参考 Configure approvals。

防止Agent失控的实操清单

基于以上机制，给管理员一份最短清单 ✅：

保持审批默认开启，不要为了"省事"全局关掉CLERUM_ENABLE_APPROVAL；
敏感环境用designated_approvers，把批准权收敛到少数人手中；
MCP 工具一律过审批是平台默认，任何第三方连接器先审批再信任；
要 Skip 某个高危工具时，必须搭配替代防线（如 HTTP 域名白名单），而不是裸奔；
给审批设置超时自动拒绝，避免任务无限挂起或审批疲劳；
无人值守任务里慎用ask规则——它会因"无审批人可用"而失败，这是特性不是 bug；
用 Guardrails 把高频低风险调用设为allow、可疑目标设为deny，把人类的注意力留给真正需要判断的时刻。

总结

Evenfire 的 Human-in-the-Loop 审批机制回答了"如何防止 AI Agent 失控"这个核心问题：不是限制 Agent 的能力，而是在关键动作前插入一个人类决策点。默认开启的审批门、按工具粒度的三档策略、多表面的随时随地批准、超时自动拒绝，再加上 Guardrails 和工作流双层审批，构成了从"单次工具调用"到"整个部署"的完整控制链。

Agent 可以大胆地调用工具、执行任务，而"失控"这件事，从此需要人类点头才能发生。🔐