【引言：从 HITL 到 HOTL，AI 代理的交互范式正在改变】

随着 AI 代理（AI agents）在软件产品中变得更强大、也更普遍，团队开始重新思考：在系统运行过程中，人类究竟应该如何与这些代理交互。过去，许多 AI 系统采用“人类在环”（Human-in-the-Loop，HITL）控制——也就是人类必须主动参与或批准关键决策。
而今天，一个明显的趋势正在形成：行业正在转向“人类在回路上”（Human-on-the-Loop，HOTL）架构——AI 代理以更高自治运行，人类更多扮演监督者，只在必要时介入。

只要建立正确的权限、规则与护栏，这种演进就能带来显著的效率与可扩展性提升，同时维持安全与信任。

本文将讨论：

• 为什么行业正在从 HITL 转向 HOTL，以及这对“工具集成策略”意味着什么

• 为什么静态、硬编码的工具集成越来越不适合现代 AI 应用

• 为什么像 MCP（Model Context Protocol）这样的新协议提供了更可扩展的解决方案

• 为什么 MCP 网关对集中化权限与工具访问控制至关重要

• Peta 如何支持“按需启用”的人类在环介入，让团队获得两全其美：默认自治 + 关键时刻有人把关

============================================================

【范式变化：Human-in-the-Loop vs. Human-on-the-Loop】

一、HITL：人类在环（Human-in-the-Loop）
HITL 指人类直接参与 AI 的决策循环。在 HITL 设计中，AI 代理可能会提出行动建议或输出结果，但在继续执行之前，必须由人类“编辑/审核者”审查并批准。
这种方式最大化控制力，常用于高风险领域（例如医生审核 AI 的诊断建议、财务人员审核 AI 发起的交易）。代价则是可扩展性与速度：每个决策都需要人类输入，系统无法做到真正的 7×24 小时高吞吐运行。人类成为工作流中的“检查点”，容易形成瓶颈。

二、HOTL：人类在回路上（Human-on-the-Loop）
HOTL 将人类定位为监督者，而不是持续参与者。在 HOTL 架构中，AI 代理自主完成“感知-决策-行动”循环；人类通过告警或仪表盘监控进展，只在异常或关键调整时介入。换句话说，AI 拥有更高自治权，单个操作者可以并行监督多个代理，而不是逐步微操每一个动作。
HOTL 保留“人类安全网”：当事情出错、或需要伦理判断时，人类仍能介入；同时避免“每次常规决策都要人审”的低效。它本质上是在更高自治与必要监督之间做平衡：以效率为中心，但不放弃控制力。

实践中的例子包括：

• 内容审核系统自动过滤大部分内容，只把边界案例交给人工审核

• 运维代理自动处理标准任务，遇到超出权限或异常情况才呼叫人类

三、为什么行业转向 HOTL
驱动这一转变的原因很直接：AI 代理能力提升 + 系统需要规模化运行。现代 LLM 代理能够进行复杂推理、与多个工具/API 交互、独立完成大量任务。如果仍要求人类审批每一步，就会抵消绝大部分效率收益。
因此团队更愿意让人类扮演“监督者”：在明确护栏下，信任 AI 自动处理低风险决策，把人力留给真正关键时刻。

但 HOTL 的前提是：必须定义清晰边界——哪些动作可自治，哪些情形需要告警或暂停，代理如何在需要帮助时发信号。自治越高，权限、规则与安全网就必须越清晰，才能让人类依然有信心、也依然掌控系统整体结果。

============================================================

【为什么 AI 代理需要更高自治（但必须带护栏）】
对工程团队与产品负责人而言，让代理更自治的吸引力非常明确：速度、可扩展性、持续运行。自治代理可以全天候工作，实时响应事件或用户请求；它还能并行处理大量常规操作，这是再大的人工团队也难以做到的。比如：客服代理要分流数千条咨询，或运维代理要实时处理基础设施告警，这些都非常适合 HOTL。

此外，很多场景需要“人类反应速度达不到的即时决策”。例如网络安全代理发现威胁时可能需要立即隔离攻击面：HOTL 允许代理在预设规则内立刻行动；而 HITL 可能因为等待审批而错过窗口期。
通过让代理在批准边界内独立行动，组织能同时利用 AI 的速度优势与人类的监督保障。

但自治也带来合理担忧：安全、伦理、可控性。没有公司希望 AI “失控乱跑”造成伤害或高成本错误。于是，HOTL 系统必须配套治理与护栏，典型包括：

一、权限范围（Permission scopes）
明确每个代理允许做什么：能调用哪些工具/API，能访问哪些数据，能做哪些改动。自治必须限制在批准的“沙箱动作集合”中。

二、策略与规则（Policies and guidelines）
为代理设定行为规则或目标，例如禁止删除数据、采购不得超过预算阈值等。

三、自动安全检查（Automated safety checks）
在代理或其环境中实现自动检查，拦截明显不合理/违规动作（访问禁区资源、生成不允许内容等），并自动停止。

四、监控与告警（Monitoring and alerts）
将代理活动（或高影响动作）上报到监控系统，使人类清楚正在发生什么；当行为偏离预期范围时及时告警。

五、回退到人类介入（Fallback to human intervention）
当情境超出代理权限或风险过高时，代理应暂停并请求人工输入；这时“人类在回路上”会针对该事件短暂切换成“人类在环”。

建立这些护栏并不容易，尤其是自治越高，越需要精确设计“运行包络线”。而其中很大一部分护栏，最终会落到：代理如何集成外部工具与系统、以及在什么控制下集成。由此引出下一部分：传统工具集成方式为什么正在失效。

============================================================

【静态工具集成的问题：为什么硬编码越来越不适合】
早期 AI 代理（以及很多现存实现）依赖“静态配置”的工具集成：开发者在构建时或通过静态配置文件，把代理接到特定工具/API 上。比如：写死一个“Google Calendar API 工具”用于排期，或写死一个“数据库查询工具”用于取数。每个集成本质上是一段自定义代码（或 prompt 工程），让 AI 以预定义方式调用该工具。

这种方式在原型阶段尚可，但当代理生态增长时会快速变得笨重且脆弱：

一、碎片化与一次性集成（Fragmentation and one-off integrations）
每新增一个数据源或 API，都要写一个新的 connector 或函数，长期积累成“补丁式拼图”：Jira 一个、Salesforce 一个、内部数据库一个……维护与扩展成本急剧上升。正如 Anthropic 指出：每个新数据源都需要定制实现，使真正互联的系统很难规模化。

二、缺乏标准化（Lack of standardization）
不同工具有不同接口与调用约定，代理难以用一致方式发现可用动作，也难以用一致方式调用。prompt 或代码复杂度升高，替换/新增工具也更困难。

三、强耦合（Tight coupling）
静态集成往往埋在代理代码或 prompt 模板里。任何变化（更新密钥、调整权限）都可能需要改代码或重新部署代理，劳动密集且易出错。

四、扩展与治理困难（Scaling issues）
当工具与代理数量增加，静态配置导致重复：多个代理以略不同方式接同一工具。缺乏公共层意味着难以协同升级或统一修复安全问题；审计每个代理拥有什么访问权限也变得困难，因为权限散落在各处代码中。

总结：静态工具集成不匹配现代 AI 部署的动态性与持续演进需求。你需要更灵活、标准化的方式把代理连接到工具与数据。这正是 MCP 出现的意义。

============================================================

【新思路：模型上下文协议（MCP）】
MCP（Model Context Protocol）是一个开放标准，旨在用统一、灵活的方式解决集成问题：让 AI 代理连接外部工具、API 与数据源更可扩展。你可以把 MCP 理解为 AI 模型与软件服务世界之间的通用接口/中间层。
代理只要会“说 MCP”，就能与任何提供 MCP 接口的工具或数据源交互，从而用更可持续的架构替代今天碎片化的自定义集成。

一、MCP 的核心机制
协议定义：

• AI（客户端）如何发现某个 server 提供哪些工具/动作

• 如何调用这些动作

• 如何结构化交换信息与上下文

实践中，开发者可以为不同资源搭建 MCP server（例如：暴露 Google Drive 操作的 server、暴露内部数据库查询的 server），然后让兼容 MCP 的客户端（例如特定版本的 Claude 或其他 agent 框架）按需连接使用。

二、MCP 的关键价值：标准化工具暴露与调用
官方文档强调：MCP 标准化了模型发现、选择与调用工具的方式，帮助开发者从简单聊天机器人走向可靠、可执行的应用，而无需为每个集成重复造轮子。
这意味着代理不需要为每个新服务写定制逻辑：它可以列出可用工具、理解输入/输出、并以统一协议调用。一个常用类比是：MCP 像 AI 应用的“USB-C 接口”——用一个标准口接入多种外设（工具/数据源）。

三、采用 MCP 的产品与工程收益

• 更快接入新工具：新增系统只要提供 MCP server（或复用现成 server），代理即可通过统一协议对接，不必改代理代码

• 统一开发体验：团队可以围绕 MCP 构建 SDK 与测试方法，而不是在代理代码里处理每个外部 API 的差异

• 更好的上下文共享：MCP 不只是调用工具，也能以模型更适配的结构提供上下文数据，使代理跨工具使用时更连贯

• 更容易插入安全与合规：协议统一后，更容易在集中层做权限、日志与策略，而不是散落在自定义代码的黑盒里

结论：MCP 将代理与具体工具集成解耦，从“静态紧绑定”转向“动态可插拔”。
但这也带来新挑战：当代理能看到大量工具时，如何控制每个代理到底能做什么？如何按需启用/禁用、调整配置而不改代理？这就引出 MCP 网关。

============================================================

【用 MCP 网关实现“安全自治”（Enable Safe Autonomy）】
MCP 网关是一层管理层，位于 AI 代理（MCP 客户端）与多个 MCP server（工具）之间，通常承担以下关键职责：

一、聚合与发现（Aggregation and Discovery）
网关把多个 MCP server 聚合在一个入口后面。代理只需要连接网关，就能访问多来源工具，配置大幅简化。比如 Red Hat 团队基于 Envoy 构建的 MCP 网关，就可将多个 MCP server 聚合到单一端点，让 AI 通过统一接口访问多种工具。

二、集中权限控制（Centralized Permission Control）
这是最核心的价值：对“哪些代理/用户可以调用哪些工具、哪些子动作（读/写）”做精细控制。
基础 MCP 协议默认并不提供基于身份的工具过滤，往往会出现“代理能看到 server 上所有工具”，即便用户并无权限。
智能网关通过“基于身份的工具可见性与调用限制”解决这个问题：财务代理只看到财务相关工具，IT 代理只看到 IT 相关工具；同一工具也可以限制为只读。这样能确保每个代理在自己的权限范围内行动。

三、运行时配置与灵活性（Runtime Configuration and Flexibility）
网关让权限与工具配置可以“动态改变”，无需改代理或重新部署。发现某工具有风险？可一键撤销；需要开启新能力？只需在网关里给权限，代理下次拉取工具列表就能看到。
这对团队运维意义重大：更快迭代，也更容易安全回滚。

四、安全与密钥管理（Security and Secret Management）
成熟网关通常同时是安全 Vault 与代理：密钥不下发给代理，代理只拿到访问网关的 token。网关在与后端通信时才使用真实凭证。这样即使代理被攻破，后端密钥也不会泄露。
同时网关能记录每次工具调用，形成审计链路，满足合规与调试需求。

五、协议翻译与策略执行（Protocol Translation and Policy Enforcement）
不同后端可能使用 OAuth、API key、PAT 等不同鉴权方式，网关可在中间做统一处理，让代理不必处理多套 auth。
网关也可执行高层策略：限流、配额、以及对敏感动作要求审批（下一节会讲）。

总结：MCP 网关是自治代理的“指挥中心”。团队可以在一个地方配置：哪些代理能访问哪些工具、在什么条件下可访问、哪些需要人工审批。
这种集中治理不仅更安全，也能减少工程师重复做运维杂活：代理不再是需要“单独照顾的特殊生物”，而是受同一套规则约束的服务客户端。

============================================================

【可选的人类监督：用 Peta 实现“例外才 HITL”】【
即便护栏再完善，总会有必须引入人类判断的场景：代理遇到新情况、或某些高风险动作按公司政策必须签字。一个优秀的 HOTL 系统应该能“优雅降级”：默认 HOTL，只在例外场景临时切换为 HITL，而不是把 HITL 作为默认模式。

以 Peta 的 “Desk” 组件为例，它提供一个面向审批的人类在环入口：

• 你可以把某些工具/动作标记为“需要人工批准”

• 代理平时可自治拉取数据或执行低风险变更

• 但当代理尝试执行高风险动作（如电汇、群发客户邮件等），请求会被拦截并转为可读的审批请求

• 审批请求可通过 Slack/Teams 等发给人类：
  “Agent X 想执行 Action Y，参数如下——是否批准？”

• 人类可快速批准/拒绝/修改

• 只有批准后，网关才允许继续执行

• 全程不暴露敏感凭证，人类只是在控制平面上做决策，执行仍由系统安全完成

这种“按例外 HITL”的模式优势很明显：

• 给不可预测与高风险时刻提供安全阀

• 同时把人类工作量降到最低：只有真正需要时才介入

• 团队可实现“95% 自动化 + 5% 人工兜底”的效率与稳健兼得

从工程角度，它还让监督逻辑模块化：你不必在每个 agent 代码里硬写审批流程，只要在网关/策略层声明“该操作敏感，需要审批”，系统就能统一处理。
这使团队可以随时间调整监督力度：

• 代理在某任务上可靠后，可取消审批让其全自动

• 代理出现问题时，也可立即收紧策略增加审批点
  全程无需重写 agent。

从产品管理角度，这也更容易获得风控部门的认可：你能明确展示“AI 在做 X 或 Y 前一定会请求审批”，且每个动作都可审计可追溯。
这是一种非常有说服力的折中：几乎获得自动化的全部生产力收益，又保留关键时刻的最终决定权。

============================================================

【结论：用信心释放自治代理能力】
从 HITL 到 HOTL 是 AI 代理发展的自然演进。随着 AI 更复杂、更强大，让人类审核每一步既不可行，也没必要。HOTL 让代理以机器速度与规模运行，同时保留人类监督作为安全网。通过明确“何时介入、如何介入”，组织可以实现强协同：AI 处理重复、快速的工作；人类在关键时刻提供判断与指导。

但要做到这一点，自治必须配套权限、集成与治理的基础设施。把静态工具调用塞进 agent 的方式已经不够灵活、不够安全，也难以在多代理环境中管理。
采用 MCP 这样的开放框架能让 AI-工具集成标准化与规模化：新增能力更像“插入新设备”，而不是对 agent 代码做外科手术。

在 MCP 之上，MCP 网关提供关键的控制与协调层：它规定“有哪些工具可用，以及使用规则是什么”。通过网关，团队可以：

• 控制谁/什么能访问哪些工具

• 安全管理凭证

• 统一记录审计与观察使用

• 动态调整配置并快速回滚

它把原本可能失控的自治代理生态变成可组织、可治理的系统。工程师与管理员也能更安心：代理不会越权；若试图越权，网关会阻止或触发人工审批。

最后，像 Peta 这样的方案表明：走向 HOTL 并不意味着放弃 HITL，而是更聪明地使用 HITL——只在例外与高风险时启用。用“可选的人类在环介入”把控制力放在真正关键的时刻，这种模块化监督对敏感领域尤为重要：符合风险管理逻辑，也更利于组织接受与规模化落地。

总之，HOTL 的兴起与 MCP 的出现，让 AI 代理更自治、更可集成、也更可治理。工程团队能更快构建更丰富的能力；产品团队能更快把代理扩展到更多场景；组织领导者也能通过护栏与审计机制负责任地使用 AI。
我们正在学习如何让 AI 承担更有意义的工作，同时把人类放在“知情监督者与协作者”的位置上——这既兴奋，也关键。

============================================================

【脚注与参考资料（Footnotes & References）】

• Red Hat —— 对 Human-on-the-Loop（HOTL）的定义：强调 AI 自治运行 + 人类监督

• Nafiul Khan（Medium）—— 对 Human-in-the-Loop 的描述：人类作为“编辑/审核者”，控制力最强但可扩展性较差

• DeepScribe —— 对 HOTL 系统的解释：AI 独立工作，人类仅在需要时介入，在效率与监督之间平衡

• Anthropic —— 指出静态集成的问题：每新增数据源都要定制实现，难以规模化；MCP 以统一协议替代碎片化集成

• Red Hat —— MCP 标准化模型发现与调用工具的方式，避免为每个集成重复造轮子

• OpenAI —— 将 MCP 类比为“AI 的 USB-C”：标准化连接工具与数据源的方式

• Red Hat —— MCP 网关可将多个工具 server 聚合在一个端点后统一访问，并引出跨工具安全问题

• Red Hat —— 标准 MCP 默认不按用户过滤工具（工具可能全部可见），因此需要网关实现细粒度访问控制

• Red Hat —— 网关中的基于身份的工具过滤：代理只看到自己被允许使用的工具

• Peta（Challenge）—— 没有控制平面，很难对每个代理、每个动作实施策略（例如只读 vs 写入）

• Peta —— Peta Console 支持集中定义：哪些代理/用户可访问哪些工具、哪些动作需要人工审批

• Peta —— Peta Core 网关密钥保存在服务端，仅向代理发放短期 token，避免凭证暴露

• Peta —— 基于策略的访问：可在不重部署代理的情况下撤销或变更权限（网关即时生效）

• Peta —— 完整审计：每次工具调用都记录代理身份，用于合规与调试

• Peta —— Peta Desk 为高风险操作提供人类在环审批界面（Slack 等渠道可审批/拒绝）

• Reddit —— 讨论将 Peta 描述为“可自托管的 MCP vault + 网关”，支持按代理策略与可选人工审批