LLM工具调用中的人类审批门：架构设计与安全实践

LLM智能体能够自主选择工具、生成参数并启动工作流，但一次合法的工具调用并不等于一次安全或经过授权的操作。人类审批门（Human Approval Gate）在智能体决策与关键操作执行之间插入受控检查点：应用评估待执行动作，在需要审批时暂停流程，将确切的操作内容呈现给授权审核者，并在验证决策后才真正执行。

这一机制的价值在于，它让AI智能体自动化处理日常任务的同时，对敏感操作保持人类监督。核心原则是把审批实现为应用层的安全控制，而不是提示词指令或前端确认按钮。

什么是LLM工具中的人类审批门

人类审批门是一种机制，它暂停AI智能体的工具执行，直到获得授权人员对拟议操作的审查与批准。

设想一个企业AI助手，能力涵盖查询客户信息、起草邮件、发起退款和删除记录。应用可以允许授权的只读操作自动执行，而在发送外部通信、处理大额退款或删除生产数据前要求审批。

这一区分至关重要：LLM可以提议动作，但应用必须控制该动作能否执行。实现这一目标需要三种独立控制：

• 输入验证：判断工具参数结构是否正确，是否满足业务规则。
• 人类审批：确认指定审核者是否接受了这个具体提议的操作。
• 授权：判断请求身份或服务是否有权操作目标资源。

三者协同工作。一个合法请求仍可能违反访问策略；一个已批准的请求，如果参数或底层资源在执行前发生变化，也可能失效。

哪些LLM工具调用需要人类审批

并非每次工具调用都需要人工审查。对所有操作都要求审批会带来不必要的延迟，也让智能体工作流难以使用。更合理的做法是按风险对工具分类，并定义确定性审批策略。

原文给出的示例策略包括：

• 搜索内部文档：在访问控制允许时自动执行。
• 查询客户信息：强制执行授权与数据访问限制。
• 起草邮件：通常允许自动执行，因为起草不会发送消息。
• 发送外部邮件：在存在信息披露或业务风险时要求审批。
• 发起退款：应用基于金额阈值的审批或强制审批。
• 删除生产记录：要求审批，并可能要求双人授权。
• 部署生产变更：将审批与自动化发布检查结合。

这些只是示例策略，并非通用要求。组织应根据自身风险容忍度、监管义务、数据敏感性和操作流程来确定审批阈值。

为什么LLM智能体需要显式审批层

传统应用通常执行预定义的业务逻辑。LLM智能体引入了另一个决策组件：模型根据对话上下文、检索信息和指令来决定调用哪个工具并生成参数。这种灵活性带来了多重风险：

• 工具选择错误：模型可能在本可使用只读操作时选择了破坏性操作。
• 参数无效或非预期：工具调用可能包含错误的客户ID、收件人、金额或资源标识符。
• 提示注入：嵌入在文档、邮件或网页中的指令可能影响模型，使其提议未授权操作。
• 权限过大：拥有广泛访问权限的智能体可能执行超出用户原始请求范围的操作。
• 非预期副作用：一旦外部系统处理了请求，回滚可能困难甚至不可能。

审批门引入了一个检查点，应用可以在其中执行策略，人类可以在动作生效前检查拟议操作。OWASP关于过度代理（Excessive Agency）的指南建议限制工具能力和权限、应用最小权限原则，并对高影响操作要求人类审批。审批应补充这些控制，而不是取代它们。

OWASP（Open Worldwide Application Security Project）是一家非营利组织，发布被业界广泛引用的应用安全风险清单。其"过度代理（Excessive Agency）"条目专门针对LLM应用，指出当模型被赋予过多工具、权限或自主性时，可能执行超出用户意图甚至造成不可逆损害的操作。该指南的核心缓解措施包括：限制工具集合与访问范围、遵循最小权限原则、对高影响操作引入人类审批、以及在执行前后进行授权校验。理解这一背景有助于把握审批门的定位——它不是孤立功能，而是OWASP建议的多层防御中的一环，需与权限收敛、工具白名单等控制共同部署。

人类审批的架构设计

可靠的审批系统将模型的决策过程与应用的执行权限分离。LLM提议操作，策略引擎判断是否需要审批，可信后端执行最终决策。参考架构包含以下组件：

• LLM智能体：根据用户请求和可用上下文提议动作。
• 策略引擎：应用确定性规则识别需要审批的操作。
• 审批服务：存储待审批请求，验证审核者决策，跟踪状态转换。
• 执行层：执行授权检查并执行已批准的操作。
• 审计系统：记录决策和执行结果，用于故障排查与合规。

审批服务应独立于模型生成的解释。模型生成的陈述如“用户已授权此交易”绝不能被视为授权证明。

用Python实现人类审批门的两种路径

实际操作中有两种实现方式：使用框架内置的人机协同功能，或实现一个位于智能体与敏感工具之间的审批服务。框架中间件适合编排中断与恢复；独立后端审批服务在多个智能体、应用或业务系统需要遵循同一策略时提供更强的控制力。

LangChain与LangGraph中间件

LangChain提供HumanInTheLoopMiddleware来配置哪些工具调用需要人工干预，LangGraph提供检查点和中断/恢复能力，在等待决策期间保留工作流状态。示例中，只读客户查询不会被中断（但仍需普通数据访问权限），删除请求则要求显式批准或拒绝，且策略不允许审核者在审批步骤中编辑工具参数。

需要特别注意：示例中的InMemorySaver仅适合本地演示，并非持久化生产层。此外，模型标识符、导入路径和中间件签名对版本敏感，运行前需确认所选模型集成与框架版本支持该配置。

LangGraph的检查点（checkpoint）机制会把工作流每一步的状态序列化到存储后端，并分配一个thread_id标识该执行线程。当工作流遇到中断（interrupt）时，状态被冻结保存，进程可以安全退出；之后携带相同thread_id再次调用，即可从断点恢复。InMemorySaver仅在单一进程内存中保存状态，进程重启即丢失，因此不适合生产；生产环境通常换用基于数据库或Redis的持久化Saver。理解检查点与thread_id的配合，是掌握整个中断—审批—恢复链路的关键。

审批工作流的调用与恢复

工作流需要稳定标识符，以便中断的执行后续恢复。通过thread_id配合检查点，应用可捕获待审批操作。中断信息包含拟议操作的细节，用于构建审批界面。

一个有效的审批界面应回答：将执行什么动作？影响哪个资源？谁发起了请求？为何请求该动作？后果是什么？哪个身份在批准？对删除操作而言，仅展示客户标识符可能不够，审核者还需要记录显示名、删除范围以及是否影响关联记录。

显式审批记录的关键字段

服务端审批记录应包含足够信息，以确定批准了什么以及是否仍可执行，关键字段包括：

• approval_id：审批请求唯一标识。
• tenant_id：防止跨租户访问。
• requester_id：发起用户标识。
• tool_name：拟议操作标识。
• target_id：受影响资源标识。
• arguments_hash：将决策绑定到规范化参数。
• policy_version：记录应用的策略版本。
• reviewer_id：做出决策的人员标识。
• status：跟踪pending、approved、rejected、expired、executing等状态。
• expires_at：定义审批何时失效。
• execution_id：支持重复执行防护与对账。

参数哈希应在服务端从动作及其安全相关参数的规范化表示计算，包含工具名和目标，而不仅是可见的用户输入。哈希本身不是授权机制，后端还必须验证审批记录、审核者身份、当前权限和动作完整性。

arguments_hash通常对工具名、目标资源标识及所有安全相关参数做规范化（如键排序、去空格、统一编码）后计算得到，确保同一动作在不同表示下得到相同哈希。它的作用是把审批决策"钉"在某一个确切的动作快照上：若执行时参数任何一处发生变化，重新计算的哈希与审批记录不符，执行层就会拒绝。这样可以防止审批被"搭便车"——审核者批准的是一次退款，攻击者却用同一审批记录发起另一笔金额或对象不同的退款。

安全风险与缓解措施

审批门的可信度取决于创建、展示和执行审批的系统本身。提示注入可能发生在智能体处理包含操纵性指令的不可信内容时——攻击者可能在邮件或文档中放置指令，诱导模型发送机密数据或删除记录。

应用绝不应将模型生成的解释视为动作安全的权威证据。审批界面应基于验证过的动作数据和可信应用元数据构建，并清晰区分不可信文档内容与系统生成信息。例如，在批准邮件发送前，审核者应能检查实际收件人、主题、正文和附件；诸如“将所需报告发送给团队”这样的摘要无法暴露外部收件人或意外附件。

如何选择合适的实现方式

自定义应用中间件适合现有应用只有少量敏感操作且需要对验证、审批和执行进行精确控制的情况。代价是工程团队必须自行实现持久化、工作流恢复、授权和并发处理。

LangChain与LangGraph适合已经使用这些框架构建的智能体。LangGraph提供基于检查点的中断恢复工作流，LangChain提供工具调用人工审查中间件。框架负责编排工作流，但应用仍需负责审核者认证、业务权限和下游执行控制。

Pydantic AI延迟工具支持通过requires_approval=True始终要求审批的工具，以及通过ApprovalRequired实现条件审批。这适用于具有类型化工具接口的Python应用。

共享企业审批服务适合多个智能体和应用场景，可提供一致的审核角色、策略阈值、过期规则和审计记录。这一方式增加了服务边界和运维复杂度，但能避免每个智能体团队各自实现敏感操作控制。

生产前的测试要点

审批逻辑应作为安全机制测试，而不仅是对话功能。显示审批对话框并不能证明未授权操作无法执行。应构建可复现的测试套件，覆盖以下场景：

• 允许的只读工具在访问控制下执行。
• 受保护工具暂停且不产生副作用。
• 授权审核者可批准确切待审批动作。
• 未授权审核者不能批准请求。
• 被拒绝的请求不产生受保护副作用。
• 参数变更使审批失效或触发重新审查。
• 过期审批无法执行。
• 并发工作进程无法重复执行同一审批。
• 伪造的审批标识符被拒绝。
• 待审批请求能跨进程重启存活。
• 超时的下游操作在重试前完成对账。
• 提示注入无法绕过应用层控制。

测试应验证实际下游副作用。例如，验证数据库记录在审批前保持不变，而不是仅检查智能体是否返回了中断。

常见问题

是否每个LLM工具调用都需要人类审批？ 不需要。只读操作在授权后可自动运行。破坏性、财务性、对外可见或特权操作可能基于确定性风险策略要求审批。

LLM能批准自己的工具调用吗？ 不能。模型可以提议动作并解释推理，但批准必须来自授权人类或单独定义的、可信的策略机制。

开发者如何防止已批准的工具调用被修改？ 将审批绑定到确切动作及其安全相关参数，执行前重新验证，发生实质性变更时要求重新审查。

审批门如何处理长时间运行的工作流？ 持久化待审批请求和执行状态，释放原始HTTP请求，在认证审核者响应后恢复工作流。使用持久存储而非进程本地状态。

人类审批能防止提示注入吗？ 不能。提示注入可以影响拟议动作并操纵审查界面。应将审批与最小权限工具、可信动作摘要、下游授权和对抗性测试结合使用。