withHuman：为AI Agent构建人工审批层

AI Agent 正在从演示走向生产环境，但一个关键问题始终悬而未决：当 Agent 自主调用工具、执行操作时，谁来把关？withHuman 给出的答案是——在 Agent 和真实世界之间插入一层人工审批，让规则处理常规操作，让人处理风险操作。

为什么 AI Agent 需要审批层

Agent 的核心能力是自主调用工具——写文件、发请求、改数据库、执行命令。能力越强，误操作的成本也越高。一个配置失误的 Agent 可能删掉生产数据，一个理解偏差的调用可能触发不可逆的外部操作。

传统做法是在 Prompt 里加约束，或者给 Agent 设定固定的权限白名单。但这两条路都有明显短板：Prompt 约束不可靠，模型可能在长上下文中“遗忘”指令；固定白名单则过于僵硬，无法适应动态任务。

withHuman 的切入点很直接：不试图让 Agent 变“聪明”，而是在工具调用真正执行之前拦截它。常规调用由规则自动放行或拒绝，高风险调用则推送给团队中合适的人做决策。这相当于给 Agent 装了一个可编程的审批中间件。

AI Agent（人工智能代理） 是指能够自主感知环境、进行推理决策并调用外部工具执行任务的大语言模型驱动系统。与传统聊天机器人只能生成文本不同，Agent 具备"行动能力"——它可以读写文件、调用 API、操作数据库、执行 Shell 命令等。这种自主性来自大模型的工具调用（Tool Calling / Function Calling）机制：模型根据任务目标自行决定调用哪个工具、传什么参数。

正因为 Agent 的输出直接作用于真实系统，其错误成本远高于纯文本生成。一次误判可能造成数据删除、资金划转、服务中断等不可逆后果。业界因此提出"人机协同（Human-in-the-Loop）"模式，在自动化流程的关键节点引入人工确认。withHuman 正是这一模式在 Agent 工具调用环节的产品化实现，它将"人类监督"从抽象原则落地为可配置的审批中间件。

核心机制：拦截、判断、路由

withHuman 的工作流程可以拆成三步。

拦截发生在 Agent 发起工具调用的瞬间。withHuman 在调用真正落到目标系统之前截获请求，这意味着即使 Agent “决定”执行某个危险操作，实际操作也不会未经审批就发生。

判断由规则引擎完成。团队可以定义哪些调用属于常规操作、可以直接放行，哪些需要人工确认。规则是一套，但适用于公司内运行的所有 Agent——这是 withHuman 强调的“One set of rules for every agent”。

路由决定谁来审批。有风险的调用不会丢进一个无人盯守的队列，而是发送给团队中对应的负责人。这个设计思路跳出了“全自动 vs 全人工”的二元对立，转向按风险分级处理。

规则引擎是审批层的决策核心，通常由一组条件表达式构成，对每次工具调用进行匹配评估。典型规则维度包括：工具名称（如 db.delete、file.write）、参数特征（如目标路径是否属于生产目录）、调用频率、发起 Agent 的身份等。规则可以设计为允许列表、拒绝列表或需人工确认三类结果。

路由（Routing） 则解决"审批请求该发给谁"的问题。在企业场景中，不同操作对应不同责任人——数据操作应由数据团队审批，代码部署应由运维或研发负责人确认。路由机制通常基于规则标签、团队分组或值班表来分发审批请求，并可设置超时升级策略，避免请求长期滞留。判断与路由分离的设计，使得同一套拦截逻辑可以复用于多个团队，同时保持责任归属的清晰。

跨框架兼容：一个开放协议解决碎片化

企业面对的现实是 Agent 技术栈高度碎片化。有人用 Claude Code，有人用 Codex，有人用 LangGraph 或 Pydantic AI 搭建自己的 Agent。如果审批层只能适配某一种框架，价值就大打折扣。

withHuman 选择通过一个开放协议（AAP）来实现跨框架兼容。官方描述中明确提到支持 Claude Code、Codex，以及用 LangGraph、Pydantic AI 等方式构建的 Agent。

这种协议优先的策略有两层意义。对开发者来说，不需要为了接入审批层而重写 Agent 逻辑；对企业来说，一套规则可以覆盖所有 Agent，避免了每个框架各建一套审批流程的运维负担。

开放协议（Open Protocol） 在此处指一种独立于具体框架的标准化接口规范，任何 Agent 框架只要按此规范发出工具调用请求，审批层就能统一拦截和处理。withHuman 所采用的 AAP（Agent Approval Protocol） 即属此类。

没有开放协议时，审批功能往往需要针对每个框架单独开发适配器，形成 M×N 的集成复杂度（M 个框架 × N 个审批系统）。协议优先的做法将其降为 M+N：框架实现协议客户端，审批层实现协议服务端，双方解耦。这与 MCP（Model Context Protocol）等标准化尝试的思路一致——通过约定接口降低生态碎片化带来的集成成本，也让企业安全策略可以跨技术栈统一实施。

开源 + 托管：两种部署路径

withHuman 采用开源加托管版本的组合。开源版本让团队可以自行部署、审计代码、按需定制——这对安全敏感的团队尤其重要，因为审批层本身就是一个信任节点。托管版本则降低了上手门槛，适合不想自己维护基础设施的团队。

产品在 Product Hunt 上获得了 80 票、排名第 7，分类归入 Open Source、Developer Tools、Artificial Intelligence。制作人还提供了 PRODUCTHUNT 优惠码，可免费使用 Scale 版本三个月。

审批层的边界在哪里

withHuman 解决的是 Agent 安全落地中的一个具体环节，但它也引出一些值得思考的问题。审批规则的颗粒度如何把握？规则太松，审批层形同虚设；规则太紧，Agent 的自动化价值被人工审批拖累。此外，当多个 Agent 并发执行大量工具调用时，审批队列的处理效率能否跟上，也是一个实际挑战。

另一个值得关注的维度是审批层自身的可靠性。如果 withHuman 出现故障或延迟，Agent 的操作是被阻塞还是被放行？这个降级策略的选择，直接关系到审批层是安全兜底还是单点故障。

从产品定位看，withHuman 瞄准的是一个正在浮现的真实需求：Agent 能力越强，人类对“可控性”的需求就越迫切。审批层不是要限制 Agent，而是让团队在享受自动化的同时保留关键决策的控制权。这个思路能否成为 Agent 基础设施的标准组件，取决于它能否在安全性和效率之间找到可持续的平衡点。

降级策略（Fallback Strategy） 是审批层可靠性的关键设计维度，指当审批组件本身出现故障、超时或网络不可达时系统所采取的行为。常见策略有两种：Fail-Open（故障时放行）优先保障业务连续性，但可能让风险操作绕过监督；Fail-Closed（故障时阻塞）优先保障安全，但会造成 Agent 任务停滞，甚至影响上游业务。

多数安全敏感系统倾向 Fail-Closed，并辅以超时自动升级、备用审批通道等缓解措施。选择哪种策略取决于操作的可逆性与影响范围——例如删除生产数据这类不可逆操作，通常应默认阻塞；而读取类等低风险操作则可考虑放行。这一权衡与规则颗粒度问题共同构成了审批层落地的核心工程挑战。