智能体AI架构与人在回路中的管控：检查点应放在哪里

本指南面向负责设计或审查智能体架构（上线前）的CTO和工程负责人，以及决定工作流中哪些部分可由智能体独立运行的技术产品负责人。我们的AI智能体与工作流自动化指南帮助判断任务是否需要智能体；我们的AI智能体安全与人类审批控制指南则针对单个审批门控的注入防护与合规自动化决策问题。本页介于两者之间：在已有智能体且确认需要门控之后，本页设计门控在控制循环中的位置，以及系统在等待期间的存活方式。若提议的工具调用涉及ERP、CRM或财务系统，我们的MCP服务器指南将设计服务器及其前置审批边界。

本指南目录

• 控制循环中有三个人工介入位置，而非一个
• 选择模式
• 构建检查点位置矩阵
• 状态与检查点设计：暂停期间必须存活的内容
• AI与检查点设计的交汇点
• 已有的交付记录与尚无记录的内容
• 备选方案与选择标准
• 本指南的局限性
• 常见问题
• 下一步

控制循环中有三个人工介入位置，而非一个

智能体运行感知-决策-行动循环：读取上下文、提议工具调用，并（在门控适用时）等待决策后再执行。大多数团队默认采用一种检查点形式——一条阻塞至有人回应的聊天消息——因为它是最容易率先构建的。但在规模化时它也是最慢的，而且正如我们的安全与审批指南所指出的，这种形式会训练审批者停止认真阅读。实际上存在三种形式，架构应在其中做出主动选择，而非沿用默认：

• 同步阻塞。运行在门控步骤处停止；该运行中下游的任何步骤都不会继续，直到有人作出回应。
• 异步队列。门控操作被写入队列或持久化承诺；运行继续执行其他独立工作，智能体（或下一次运行）在收到回应时获取答案。
• 乐观执行加补偿操作。步骤立即执行，并将预先构建的撤销操作（退款、撤回发送、回滚）加入队列；人工事后审查并在必要时触发撤销。

选择模式

状态与检查点设计：暂停期间必须存活的内容

同步门控可以将状态保存在运行中的进程里，因为等待期间不会发生其他事情。但异步和乐观模式不行：进程可能重启、工作节点可能宕机、等待可能持续数小时。持久化执行平台和智能体框架都收敛到同一个答案——将状态持久化到进程内存之外，以运行或线程ID为键，并从运行暂停的确切位置恢复，而非重放。对于智能体检查点，最重要的四个字段是：智能体已读取的输入（包括任何检索上下文，当运行涉及知识库时，如我们的RAG架构指南所述）、确切的提议工具调用及其参数、审批响应绑定到的稳定运行或线程标识符，以及幂等键——因为恢复的运行通常会从顶部重新进入暂停步骤，不能重复副作用（如扣款或重复消息）。LangChain的中断-恢复模型在暂停时持久化完整状态快照并在恢复时还原；云工作流回调模式（例如AWS Step Functions风格的任务令牌）使暂停步骤保持可见且计费-空闲状态，而非占用活跃线程；持久化承诺模式（如Restate的awakeables）将审批绑定到可在进程重启后存活的回调ID。这不是产品背书：Netbase与主流商业和开源AI工具及模型合作，按项目选用，并围绕项目已有的编排层设计检查点。

已有的交付记录与尚无记录的内容

• 已有内容。Netbase已为未具名客户交付AI项目，包括上述审核和聊天机器人记录，其中智能体的输出或操作在面向人工的队列或CRM工作流中等待或同步。Netbase遵循自身的安全实践（安全代码审查、传输中TLS和静态AES加密、基于角色的访问控制、管理仪表板的MFA、漏洞扫描和渗透测试），并持有ISO 27001认证和针对自身运营的SOC 2 Type II证明；详见安全与合规。
• 尚无内容。Netbase尚无已发布记录说明暂停智能体运行的恢复时间、队列深度、审批率或事件计数，也无记录说明特定交付所使用的编排框架或工作流引擎。Netbase的认证覆盖其自身运营，不延伸至客户系统。

备选方案与选择标准

上述矩阵中的四个标准同样决定这些方案的选择：最坏情况的可逆性、业务可接受的延迟、基于真实案例的实测置信度，以及是否存在经过测试的补偿操作。

本指南的局限性

• 本指南描述架构模式，而非特定框架的保证；每个编排层和工作流引擎对中断、回调和持久化承诺模式的实现略有不同，引用的来源记录的是其自身产品的行为，而非通用标准。
• 本指南为通用工程指导，而非法律建议；智能体决策是否需要根据《欧盟人工智能法》或GDPR进行人工监督，是我们的AI智能体安全与人类审批控制指南所涵盖的法律评估，而非本指南。

下一步

请分享您正在设计的智能体、它提议的操作以及决策可以安全等待多长时间，我们将预约方案评审，帮助您确定检查点位置并设计恢复所需的状态。您也可以查看AI自动化与智能体或更多Netbase洞见。

相关服务与解决方案