AI Agent正在从“会聊天的工具”变成“能执行的系统”。当AI开始帮用户审批、分单、生成方案、调用工具甚至跨系统协作时，产品经理真正要设计的，已经不只是一个对话框，而是一套人机协作的控制机制。本文从Human in the loop、Human on the loop和Human out of the loop三种模式出发，讨论产品经理如何判断：哪些环节必须人工确认，哪些环节只需要人工监督，哪些环节可以完全自动化，以及如何把这种判断落成可解释、可观测、可审计、可回滚的Agent产品架构。

过去一年，很多AI产品的讨论都围绕一个问题展开：怎么让模型更聪明？

但真正落到业务里，你会发现另一个问题更棘手：模型足够聪明以后，我们到底该让它做多少事？

让AI自动回复客服消息，看起来没问题；让AI自动给客户退款，就开始让人不安。让AI总结合同风险，很有价值；让AI直接代表公司签署合同，就明显越界。让AI帮销售生成拜访纪要，是效率工具；让AI自动承诺交付周期，可能就是事故现场。

这背后不是单纯的技术能力问题，而是产品控制权问题。

在AI Agent时代，产品经理需要重新回答一个经典问题：人在系统里到底扮演什么角色？

是每一步都要参与的审核者，还是只在异常时介入的监督者？是AI的操作员，还是AI系统的治理者？甚至在某些标准化任务里，人是否可以完全退出实时运行回路？

这正是Human in the loop（人在回路中，以下简称HITL）、Human on the loop（人在回路上，以下简称HOTL）和Human out of the loop（人在回路外，以下简称HOOTL）要解决的问题。

AI Agent自主性控制谱系

一、先把三种“人在回路中的位置”说清楚

很多团队讨论人机协作时，只谈HITL和HOTL。但如果不把HOOTL一起放进来，判断就会不完整。

因为真实业务不是只有“人工审批”和“人工监控”两种状态。还有大量低风险、高频、标准化、可回滚的任务，最合理的设计恰恰是让系统自动完成，而不是让人每次都看一眼。

所以，我更建议把三者理解成一条连续谱。

1. HITL，是人在回路中。AI可以生成、判断、推荐、执行部分动作，但在关键决策点上，必须等待人的输入、确认、修正或升级处理，系统才能继续往下走。
2. HOTL，是人在回路上。AI在明确边界内自主运行，人不逐条审批，但通过监控、抽检、告警、审计和暂停机制监督系统表现，并在异常出现时介入。
3. HOOTL，是人在回路外。AI在预先定义好的边界内自动完成决策和执行，运行时不需要人工确认，也不依赖实时人工监督。人只在规则配置、周期复盘、系统升级或事故追溯时介入。

这三种模式的区别，不是“人重要不重要”，而是“人的判断发生在什么时间点，以什么方式影响系统”。

这也是为什么文章不能只停留在HITL/HOTL。产品经理真正要回答的是：这一步需要预防、检测，还是可以自动化？

只有先区分这三种位置，产品经理才能进一步判断：哪些AI动作需要在执行前被拦住，哪些动作可以先执行再监督，哪些动作可以在明确边界内自动完成。

二、HITL：不是加一个审核按钮，而是把人的判断设计进流程

很多团队一提到HITL，第一反应是：那就在AI输出后加一个人工审核吧。

这其实把HITL想窄了。

HITL不是简单地在人和AI之间塞一个审批节点，而是一种系统设计模式：人的判断被设计进流程，并且会改变流程结果。

例如，在智能客服场景中，AI可以先判断用户意图、生成回复草稿、推荐补偿方案。但当问题涉及金额退款、账户封禁、投诉升级时，系统必须把任务交给人工坐席或主管确认。这个确认不是形式上的，它决定流程是否继续、以什么方式继续，也决定后续模型是否要从这次修正中学习。

这才是HITL。

它适合三类场景。

第一，错误代价高。比如金融风控、医疗辅助诊断、合同审查、内容合规、客户赔付。这里的“错”不是一个字段填错，而是会带来资金损失、合规风险和信任损耗。

第二，输入变化大。比如复杂客诉、非标采购、企业服务交付、法律咨询。业务上下文经常变化，很多判断依赖历史关系、语气、例外条款和隐性规则。

第三，系统需要持续学习。比如数据标注、模型训练、客服意图分类、内容推荐调优。人在回路中不仅是为了兜底，也是为了把人类修正变成系统能力的一部分。

HITL的关键不是“有没有人点过同意”，而是这个人是否有足够信息、足够权限和足够时间做出有效判断。

这点非常重要。很多所谓HITL其实只是“形式化审核界面”：系统给审核员一个“通过/拒绝”按钮，却没有告诉他 AI 看到了什么、为什么这么建议、这次动作的影响是什么、有什么替代方案、出了问题能不能回滚。这样的HITL看起来合规，实际上并不构成有效监督。

欧盟可信 AI 指南把human agency and oversight放在可信AI的关键要求之一，并把human-in-the-loop、human-on-the-loop、human-in-command都视为实现人类监督的方式。这给产品经理一个很好的提醒：人工审核不是UI控件，而是治理机制。

三、HOTL不是放任AI，而是把人从操作员变成监督者

但如果所有AI动作都进入HITL，系统很快会从“智能助手”退化成“人工排队系统”。在高频、可回滚、风险可控的流程里，产品经理真正需要的不是逐条审批，而是持续监督。这就是HOTL的价值。

很多人会觉得HOTL就是“AI先执行，人事后看报表”。如果只是这样，风险仍然很高。因为很多AI错误不会以显性故障呈现，而是逐渐扩散成运营成本、用户不满和信任损耗。

真正的HOTL，是让AI在明确边界内自主运行。人类不逐条审批，但通过监控、抽检、告警、审计和暂停机制监督系统表现，并在异常出现时介入。

这时候，人不再是每个任务的处理者，而是整套自动化系统的治理者。

例如，电商平台可以让AI自动识别低风险售后单、自动分配工单、自动补全文案、自动推荐处理方案。人工运营不需要看每一张单，但需要看到异常率、用户二次投诉率、退款金额波动、某类商品问题激增、模型置信度下降等信号。一旦指标越过阈值，系统要能自动告警、暂停某类自动处理，或把相关任务切回人工。

这就是HOTL。

它适合高频、稳定、可回滚、低到中风险的流程，比如批量信息抽取、常规工单路由、标准化质检、库存补货建议、营销素材初筛、舆情监测、运营数据清洗等。

HOTL追求的是规模化效率，但前提是产品经理把监督机制设计清楚。

没有仪表盘、没有告警阈值、没有抽检规则、没有审计日志、没有一键暂停，所谓HOTL就只是缺少有效约束的自动执行。这并不代表系统成熟，反而可能带来失控风险。

四、HOOTL：不是没有治理，而是让治理退出单次执行

进一步看，并不是所有任务都值得被持续监督。对于低风险、高频、标准化、可回滚的动作，哪怕HOTL也可能显得过度设计。此时，真正合理的选择不是让人盯着系统跑，而是把人退出单次执行回路，把治理放到规则、指标和复盘中。这就是HOOTL。

需要强调的是，HOOTL并不意味着系统永远不受人控制。

它的含义是：在某个具体运行回路里，人不参与实时决策，但仍然可以在系统设计阶段定义规则，在上线前做评估，在运行中看聚合指标，在问题发生后追溯日志，在版本迭代时调整策略。

换句话说，HOOTL不是“没有治理”，而是“治理不发生在每一次任务执行时”。

它适合极低风险、完全标准化、失败可重试、错误可快速修复的场景。

比如：

• 内部知识库自动打标签。
• 重复数据自动去重。
• 日志格式自动清洗。
• 低敏感度运营报表自动生成。
• 库存低水位提醒自动触发。
• 无外部承诺的草稿类内容自动归档。

在这些场景里，如果还要求每一步都人工确认，自动化反而会把处理压力转移给人工。这不是安全，而是低效。

但是，HOOTL有自己的边界。

第一，动作必须低风险。错误不能直接影响用户权益、资金、合规或外部承诺。

第二，结果必须可回滚。系统做错了，能快速撤销、重跑、补偿或覆盖。

第三，流程必须可观测。即使人不在实时回路里，也要知道系统做了什么、何时做的、为什么这么做、成功率如何。

第四，策略必须可收紧。当异常率上升、业务环境变化、监管窗口到来时，系统应该能从HOOTL自动降级到HOTL，甚至局部切回HITL。

所以，HOOTL不是自动化的终点，而是自动化在低风险区间里的默认形态。

HOOTL的正确打开方式：自动化也要有边界

真正危险的不是HOOTL，而是把高风险任务伪装成低风险任务，然后放进HOOTL。

五、如何判断三种模式：预防、检测，还是默认自动化？

前面三种模式解决的是概念边界，但产品经理真正落需求时，需要把它们转化成可判断、可配置、可复盘的决策规则。

判断一个流程该用HITL、HOTL还是HOOTL，不要先问“我们信不信AI”。

更好的问题是：如果AI做错了，我们希望在什么时候发现？发现以后还能不能修？

• HITL是预防模型。它把人工判断放在动作发生之前，目标是在错误影响用户、资金、合规或品牌之前拦住它。
• HOTL是检测模型。它允许系统先执行，再通过监控和抽检发现偏差，目标是在问题扩大前识别并修正它。
• HOOTL是自动化模型。它假设某类任务的风险足够低、规则足够稳定、修正成本足够小，所以不需要把每次执行都变成监督事件。

这三种模式没有绝对优劣，只有适用边界。

• 如果错误影响很低、修正成本很低，HOOTL往往更合理。比如AI把一个内部知识库标签分错了，运营改回来即可。逐条人工审核反而会拖慢效率。
• 如果错误影响中等、任务量很大、异常比例较低，HOTL往往更合理。比如常规工单路由、低风险售后建议、运营数据清洗。人需要看趋势、看异常、看抽检结果，而不是看每一条任务。
• 如果错误影响很高、修正成本很高，就应该使用HITL。比如AI判断一笔交易是否欺诈、是否冻结账户、是否拒绝用户贷款申请。事后发现错误并不等于问题解决，因为用户信任、合规证明、财务对账和内部追责都已经产生了额外成本。

产品经理可以用一个简单矩阵来判断。

大多数真实业务不会只用一种模式。更常见的设计是：低风险任务自动跑，中风险任务监控跑，高风险节点人工确认。

有了这样的规则，三种人机协作模式才不会停留在概念标签，而能进入权限配置、风险评分、审批节点和运行策略。

这也是为什么HITL、HOTL、HOOTL不能只作为流程标签存在。到了Agent阶段，AI不只是生成内容，而是能够调用工具、修改状态、跨系统执行任务。此时，“人在哪里”就从交互问题变成了架构问题。

六、Agent时代，“人在哪里”变成了架构问题

现在很多AI产品的演进方向，正在从Chat走向Workflow、Skill、Multi-agent和Agent Network。

早期ChatGPT更像一个问答界面。用户输入问题，AI输出答案，人天然在回路中，因为每一步都是人主动触发的。

但到了Agent阶段，AI不再只是生成文本，而是可以调用API、操作浏览器、读写文件、发消息、查日历、执行代码，甚至多个Agent之间可以分工协作。此时，人类不再天然掌握每一步。

这会带来一个变化：产品经理不能只设计“AI能做什么”，还要设计“AI做到哪里必须停下来”。

例如，一个企业采购Agent可以自动收集供应商报价、比较历史合作记录、生成谈判策略、草拟合同条款。但它不能在没有授权的情况下自动下单付款。一个个人助理Agent可以重排行程、生成邮件草稿、提醒冲突，但不能擅自取消重要会议或代表用户发出敏感承诺。

Agent越能执行，越需要边界。

Anthropic在关于构建有效Agent的文章中，把workflow和agent做了一个重要区分：workflow是按照预定义路径编排LLM和工具，agent则是让模型动态决定如何行动、使用哪些工具、如何完成任务。这个差异对产品经理很关键。因为一旦系统从workflow走向agent，控制权就不再只藏在流程图里，而是藏在工具权限、策略引擎、运行时监控和失败恢复机制里。

这也是为什么HITL、HOTL、HOOTL不只是AI风控概念，而是未来Agent产品的基础架构模型。过去产品经理设计的是按钮、页面和流程；现在还要设计权限、阈值、暂停点、解释卡片、责任链、反馈回路和trace。

因此，HITL、HOTL、HOOTL不能只停留在产品策略层。它们最终要落到Agent的执行架构里：谁来判断风险，谁来限制权限，谁来记录过程，谁来触发人工介入，谁来决定系统是否可以继续自动执行。接下来要讨论的运行时路由、可观测性、Harness，本质上都是为了回答这个问题。

HITL/HOTL/HOOTL运行时路由器

七、运行时路由：让每一次 AI 动作都被识别、评分和记录

如果把 HITL/HOTL/HOOTL 只停留在概念层，需求文档里通常只会出现一句话：高风险场景进入人工审核。

这句话不够。

真正可落地的产品方案，应该把它设计成一套运行时路由系统：每一次 AI 动作在执行前，都要被识别、评分、路由、记录。

一个比较通用的链路是：

用户请求进入系统后，Agent先完成意图识别和任务规划；系统根据动作类型、工具权限、金额、用户等级、历史投诉、模型置信度、命中的业务规则、上下文敏感度等信息生成风险评分；随后控制层决定这次动作是自动执行、进入监控执行、进入人工确认、提高抽检比例，还是直接拒绝执行。

这套系统至少包括六个技术组件。

第一，动作分类器。它要识别Agent准备做的动作是什么：只是生成建议，还是要调用工具；只是写入内部草稿，还是要触达外部用户；只是读取数据，还是要修改状态。

第二，风险评分器。它不能只看模型置信度，还要看业务影响、可回滚性、权限边界、异常历史、用户敏感度和合规要求。模型很自信，不代表动作可以放行。

第三，策略引擎。它决定不同风险等级如何路由：L1/L2 可以 HOOTL，L3 进入 HOTL，L4/L5 进入 HITL，某些高波动周期临时提高复核比例。

第四，工具权限层。Agent不能因为“会推理”就自动获得工具权限。不同工具应该有不同授权级别，比如只读、草稿写入、内部写入、外部发送、资金动作、法律承诺。

第五，审计与追踪层。系统要记录输入、上下文、模型版本、提示词版本、工具调用、参数、输出、人工确认、异常告警、回滚动作。没有这些记录，事后就只能靠猜。

第六，反馈学习层。人工拒绝、人工修正、异常样本、用户投诉、回滚事件，都应该进入规则库、评测集、训练数据或提示词迭代流程。

如果这些组件没有产品化，HITL就会变成低效的人工审批，HOTL就会变成形式化监控面板，HOOTL就会变成不可解释的自动化。

八、可观测性：让HOTL和HOOTL真正可控

传统软件出了问题，我们通常看日志、指标和链路追踪。

Agent出了问题，只看这些还不够。

因为Agent的失败不一定是接口500，也不一定是服务超时。它可能是选错工具、重复调用工具、忽略约束、误解用户意图、引用了过期知识、在多步推理中偏离目标，或者在看似成功的情况下给出了错误结果。

所以，Agent产品需要的是“行为可观测性”。

OpenTelemetry已经开始为GenAI定义语义规范，把chat、invoke_agent、invoke_workflow、execute_tool、retrieval等操作作为可观测对象。OpenAI Agents SDK也内置tracing，会记录一次agent run中的LLM generation、tool call、handoff、guardrail和custom event。这些不是工程团队的内部玩具，而是产品经理理解Agent运行质量的基础设施。

一个合格的Agent可观测体系，至少要回答这些问题：

• 这次任务拆成了几步？
• 每一步调用了哪个模型、哪个工具、哪个知识源？
• 每次工具调用的输入参数是什么，返回结果是什么？
• 哪一步触发了guardrail？
• 哪一步进入人工确认？
• 人工为什么批准、拒绝或修改？
• 失败是模型问题、工具问题、知识问题、权限问题，还是策略问题？
• 同类失败最近是否在上升？

这些问题回答不了，HOTL就没有基础。因为人站在回路上，看到的不能只是“成功率98%”，而要能钻到trace里看到系统到底如何做出这个结果。

Agent可观测性：trace、tool call、guardrail与审计

产品经理在这里要做的，不是替工程师设计日志字段，而是定义“什么信息必须被看见”。

例如，客服Agent的观测指标不应该只有响应耗时和自动处理率，还应该包括：人工介入率、二次投诉率、退款建议通过率、不同意图的置信度分布、规则命中分布、敏感动作拦截率、被人工改写的原因分类。

采购Agent的观测指标也不应该只有节省时间，还应该包括：供应商匹配准确率、异常报价识别率、合同条款风险命中、越权工具调用拦截、人工修改的谈判策略类型、最终采购结果与AI建议的一致性。

可观测性做得越细，人的位置就越清楚。

• 没有trace，HITL只是临近执行前的形式化确认。
• 有trace，HITL才能变成有证据的判断。
• 没有指标，HOTL只是事后查看报表。
• 有指标，HOTL才能变成真正的系统治理。
• 没有审计，HOOTL只是不可解释的自动化。
• 有审计，HOOTL才能在低风险任务里放心放行。

可观测性回答的是“系统运行时发生了什么”，但产品经理还需要进一步回答“这些信息如何转化成具体的产品机制”。因此，在需求设计层面，HITL、HOTL、HOOTL需要被拆成一组可配置、可验证、可复盘的规则。

九、产品经理如何设计一套人机协作机制？

如果把HITL/HOTL/HOOTL落到需求文档里，可以从七个问题开始。

1. 先定义AI的动作等级

不要笼统写“AI自动处理”。产品经理需要把AI动作拆成不同风险等级。

• L1：只生成建议，不触发动作。典型如摘要、分类建议、话术草稿。
• L2：可执行低风险动作。典型如打标签、分派工单、补全字段。
• L3：可执行可回滚动作。典型如发送内部通知、生成任务、调整非关键配置。
• L4：涉及用户权益、资金、合规或外部承诺。典型如退款、封号、审批拒绝、合同发送。
• L5：不可逆或高影响动作。典型如资金划拨、法律文件签署、医疗处置建议确认。

L1到L2可以进入HOOTL或HOTL，L3需要看回滚成本和外部影响，L4和L5通常必须HITL。

2. 再定义人工介入触发器

“需要时人工介入”是一句不可执行的需求，产品经理必须把“需要时”写成规则。

常见触发器包括：模型置信度低于阈值、金额超过阈值、用户等级较高、负面情绪明显、涉及监管关键词、历史投诉次数过多、系统检测到异常模式、同类错误率上升、用户主动要求人工、AI多次尝试失败、工具调用参数异常、RAG检索结果冲突、外部系统返回异常。

触发器越清楚，人工介入越不会停留在主观判断。

3. 给人类一个可判断的解释界面

很多AI审核流程低效，不是因为人不愿意审，而是因为系统只给了一个“同意/拒绝”按钮，却没有给足判断依据。

一个合格的人工确认页面，至少要回答三件事：AI准备做什么？AI为什么建议这么做？如果这么做，可能影响什么？

对于高风险动作，还应该展示证据来源、历史记录、相似案例、规则命中项、可选方案和回滚方式。否则人工审核只是把责任转移给人工，而不是帮助人做更好的判断。

HITL人工审核页：要把判断依据产品化

4. 把人工反馈变成系统资产

HITL最容易失败的地方，是人类每天都在修正AI，但系统没有学习。

客服改了AI的分类，模型下次还是分错；审核员拒绝了AI的建议，规则库没有更新；运营标记了异常样本，训练集没有沉淀。久而久之，团队会觉得AI没有减少工作，反而制造了新工作。

所以，产品设计里必须明确：人工修正会进入哪里？

是进入训练数据集，还是规则库？是更新提示词模板，还是调整路由逻辑？谁负责复盘？多久评估一次？哪些反馈自动生效，哪些需要二次审核？

没有反馈闭环的HITL，只是人工兜底和重复修正。

有反馈闭环的HITL，才是增强智能。

5. 给HOTL设计“刹车”

HOTL的核心不是看报表，而是能在异常时控制系统。

产品经理至少要设计三种刹车。

第一，自动刹车。当错误率、投诉率、异常率超过阈值，系统自动降级或暂停某类自动化。

第二，人工刹车。运营、审核、管理员可以一键暂停某个Agent、某个场景、某类动作。

第三，策略刹车。对于节假日、监管窗口、重大活动、新业务上线等高波动周期，系统可以自动提高人工复核比例。

HOTL不是少管，而是把管理做成机制。

6. 给HOOTL设计“边界条件”

HOOTL的产品需求不能只写“自动执行”。

更完整的写法应该是：

• 在什么条件下可以自动执行？
• 自动执行失败后重试几次？
• 哪些错误自动修复，哪些错误升级到人工？
• 多久抽检一次？
• 哪些指标异常会触发降级？
• 系统版本变更后是否需要重新进入HOTL观察期？

这一步很关键。因为HOOTL一旦上线，真正决定风险的不是“有没有人参与”，而是边界条件是否足够具体。

7. 把评测集当成产品资产

很多团队上线Agent时，只看演示是否顺畅。

但Agent的风险往往藏在边界样本里。

产品经理应该和算法、工程、运营一起维护一套评测集：高频正常样本、低频异常样本、恶意输入样本、合规敏感样本、历史事故样本、人工纠错样本。

每次模型、提示词、工具、知识库、路由策略变化，都应该跑一次评测。否则你不知道系统能力是真的提升了，还是只是换了一种方式犯错。

从这个角度看，评测集就是Agent产品的回归测试。

十、四层控制回路：从单点审核到系统治理

如果要在企业AI产品里真正落地，我更建议从“三层回路”升级为“四层控制回路”。

第一层，任务回路：面向具体业务动作。比如AI生成退款建议，人工确认后执行。这一层主要解决HITL。

第二层，运行回路：面向系统执行过程。比如工具调用、权限校验、策略路由、失败重试、自动降级。这一层决定HOOTL和HOTL能不能安全运行。

第三层，运营回路：面向流程质量。比如监控自动处理率、错误率、人工介入率、用户投诉率、模型置信度分布、异常样本分布。这一层主要解决HOTL。

第四层，治理回路：面向组织责任。比如谁可以调整阈值，谁可以授权Agent调用工具，谁可以查看审计日志，谁对高风险动作负责，谁负责周期复盘。这一层决定AI产品能不能在企业里长期跑下去。

很多AI产品只做了第一层，所以看起来“有人工审核”；也有些产品只做了第三层，所以看起来“有监控面板”。但真正能规模化的系统，必须四层都有。

因为AI Agent不只是一个功能，而是一种新的业务执行单元。只要它能跨系统行动，就一定会触碰权限、责任、审计和组织协作。

企业Agent产品的四层控制回路

十一、产品经理的角色变化：从设计流程到分配控制权

过去，产品经理习惯设计“用户如何完成任务”。

现在，我们还要设计“AI如何替用户完成任务，以及用户如何控制AI”。

这意味着产品经理的关注点会发生变化：

• 从功能清单，转向动作边界。
• 从页面流程，转向决策流程。
• 从用户点击，转向系统自治。
• 从异常提示，转向异常治理。
• 从体验效率，转向效率、风险和责任的平衡。
• 从页面埋点，转向Agent trace。
• 从版本上线，转向持续评测。

未来的AI产品不是越自动越好，而是该自动的地方足够自动，该停下来的地方必须停下来，该解释的时候解释清楚，该追责的时候找得到链路。

HITL、HOTL、HOOTL的真正价值，不是证明“人类仍然重要”，而是帮助我们把人的重要性放在正确的位置。

• 在极低风险、完全标准化的地方，让AI进入HOOTL，自动执行、自动重试、周期复盘。
• 在低到中风险、高频、可回滚的地方，让AI进入HOTL，人站在回路上看趋势、调策略、管异常。
• 在高风险、高价值、强上下文的地方，让人进入HITL，做判断、给反馈、承担最终责任。

这不是人与AI谁替代谁的问题，而是产品系统如何重新分配控制权的问题。

AI Agent时代，最好的产品经理不只是会写Prompt的人，也不是盲目追求自动化的人，而是能回答这三个问题的人：

1. 这一步，AI可以自己走吗？
2. 如果可以，人应该站在哪里？
3. 如果人不在实时回路里，系统如何证明自己仍然可控？

当这些机制被放在一起时，我们会发现：人机协作模式并不是孤立的交互设计，而是需要一套统一的运行底座来承载。这个底座，正是Agent产品中的Harness。

十二、Harness不是技术细节，而是Agent产品的控制底座

到这里，我们已经讨论了三种人机协作模式，也讨论了运行时路由、可观测性、权限和审计。但这些能力不应该散落在不同模块里，而应该被收束到一套统一的Agent运行底座中。这个底座，可以理解为Harness。

前面讨论的HITL、HOTL、HOOTL，本质上解决的是“人如何参与Agent 的执行”。但在真实产品中，这些机制不能只停留在页面和流程层面。

当Agent开始调用工具、访问业务数据、修改系统状态，甚至跨系统完成任务时，产品经理还需要一套更底层的控制结构，来管理它能看到什么、能调用什么、能自动做到哪一步、什么时候必须停下来。这个控制结构，就是Agent的Harness。

因此，对于AI产品经理来说，Agent产品设计不能停留在“用户问什么，模型答什么”。真正要设计的是：Agent能看到什么，能调用什么，能自动做到哪一步；哪些动作必须等待人工确认，哪些动作可以自动执行但需要被监督；一旦出错，系统如何发现、解释、追责和回滚。

在这个视角下，HITL、HOTL、HOOTL就不再是简单的交互模式，而是Harness中的三类控制策略。

HITL是Harness中的强审批机制。它适用于高风险、不可轻易回滚、涉及资产、权限、合规或客户影响的动作。Agent可以分析、建议、生成方案，但真正执行前必须停下来，把决策权交还给人。例如删除关键数据、提交合同、批量发送客户通知、调整生产系统配置，都不应只由模型判断。

HOTL是Harness中的监督与干预机制。它适用于中等风险、可自动推进但需要被观察的任务。Agent可以持续执行，但产品要提供过程可视化、状态提醒、异常告警和人工接管入口。人不是每一步都点确认，而是在系统偏离目标、风险升高、置信度下降时介入。

HOOTL是Harness中的自动化执行机制。它适用于低风险、高频、边界清晰、可验证、可回滚的任务。此时人不参与单次执行，而是通过规则、权限、日志和指标来治理系统。例如生成日报草稿、同步低敏数据、整理知识库标签、跑固定检查流程，都可以在明确边界内自动完成。

所以，三种模式的差异，不是“人多一点还是少一点”，而是Agent的执行权被怎样分配、限制和治理。面向B端场景，Agent产品的成熟度，不只看模型是否聪明，更要看Harness是否能把聪明的执行者放进一套可控的组织流程里。

Harness解决的是Agent如何被约束，但Agent为什么持续行动，还需要另一个变量：Goal。当Agent的交互单位从单轮Prompt变成长期Goal，人机协作模式的重要性会进一步上升。

十三、从Prompt到Goal：Agent产品正在从“听指令”走向“追目标”

如果说Harness解决的是“Agent如何被约束”，那么Goal解决的就是“Agent为什么持续行动”。

过去，多数AI产品是prompt-driven的。用户给出一条指令，AI完成一次响应；用户继续给下一条指令，AI再往前推进。

近期Codex CLI中出现的/goal这类目标型命令，虽然还不是一个充分标准化的行业范式，但已经释放出一个值得产品经理关注的信号：Agent的交互对象，正在从“下一步指令”转向“最终目标”。它的意义不在于多了一个slash command，而在于Agent的控制对象正在发生变化。

换句话说，用户不再只是告诉AI下一步怎么做，而是告诉Agent最终要完成什么。随后，Agent需要围绕这个目标持续规划、执行、检查结果、修正路径，并在任务没有完成时继续推进。这类刚刚浮出水面的目标驱动型交互，说明Agent产品正在从“会话式AI”进入“目标型Agent”的阶段。

也正是在这个变化中，HITL、HOTL、HOOTL的价值会更加突出。因为当Agent开始持续追目标，它的执行链路会变长，跨越的系统会更多，错误积累和权限误用的风险也会放大。高风险目标必须在关键动作插入HITL；中风险目标可以自动推进，但需要HOTL监督；低风险目标才适合在HOOTL下自动完成。

Goal提升的是Agent的持续执行能力，Harness提供的是Agent的控制边界。只有Goal没有Harness，容易演变为缺少约束的自动执行：系统很努力，但没人知道它会把努力用在哪里。只有 Harness没有Goal，又容易停留在工具编排：流程看似严密，但Agent缺少围绕目标持续推进的能力。Goal+Harness+人机协作分层，才是可治理的Agent产品架构。

因此，Codex/goal的意义并不只属于编程工具。它提示我们：未来Agent产品的核心竞争力，可能不只是模型能力，而是目标、权限、监督、审计和回滚组成的控制系统。当AI不再只是回答问题，而是持续追目标时，产品经理真正要回答的问题是：人应该在哪些节点介入，系统应该在哪些地方停下，哪些执行可以放心交给机器，哪些结果必须能被解释和追回。

Mermaid架构图：Goal、Harness与三种人机协作模式

Goal提升持续执行能力，Harness提供控制边界，HITL/HOTL/HOOTL 决定不同风险等级下的人类站位。

结语：当Agent开始追目标，产品经理要重新分配控制权

AI Agent的前沿变化，不只是模型越来越强，而是系统开始具备持续追目标、跨工具执行和自我推进的能力。

Goal让Agent知道要去哪里，Harness约束Agent能怎么去，而HITL、HOTL、HOOTL则决定人在不同风险等级下应该站在哪里。

因此，未来AI产品经理真正要设计的，不只是Prompt，也不只是工作流，而是一套目标、权限、监督、审计和回滚共同组成的控制系统。

当AI不再只是回答问题，而是开始替用户执行任务时，产品经理必须回答三个问题：

这一步，AI可以自己走吗？

如果可以，人应该站在哪里？

如果人不在实时回路里，系统如何证明自己仍然可控？