企业部署 AI Agent 或数字员工以后，一个很容易出现的误区是：
Agent 越自动，价值就越高。
但真实企业环境并不是所有业务都适合完全自动执行。
查询订单和修改订单，风险不同。
生成审批建议和直接审批通过，风险不同。
分析生产异常和直接修改生产参数，更不是同一级别的操作。
因此，企业 AI Agent 更现实的方向不是“所有事情都交给 AI”，而是：
让 Agent 自动完成适合自动化的步骤，在关键节点由人确认，再继续执行后续任务。
这种模式通常被称为 Human-in-the-loop（HITL，人参与闭环）。
对于企业即时通讯（IM）来说，它天然适合作为 AI Agent 人机协同和人工确认的入口：Agent 可以把需要授权的业务动作发送给正确人员，由人确认后再继续执行。
Human-in-the-loop 可以简单理解成：
AI 负责分析和执行，人负责关键判断和最终授权。
例如一个采购 Agent 发现某种原材料库存不足。
它可以自动完成：
查询库存；
查询未来生产计划；
查询在途采购；
计算缺口；
找到采购负责人。
然后在企业即时通讯中发送：
A 原料预计 3 天后低于安全库存，按照当前生产计划预计缺口 2.6 吨，建议增加采购 3 吨。
并提供：
确认采购｜调整数量｜暂不处理
员工点击“确认采购”以后，Agent 再继续调用采购系统创建申请。
完整链路就是：
业务事件 → Agent 分析 → 形成处理建议 → 企业即时通讯通知人员 → 人工确认 → Agent 继续执行
这就是典型的 Human-in-the-loop。
Agent 的特点是能够围绕目标拆解任务、选择工具并连续执行。
例如：
检查今天异常订单，把高风险订单通知负责人。
其中很多步骤可以自动完成：
查询订单；
查询库存；
分析风险；
查找负责人；
生成摘要；
发送提醒。
但如果任务变成：
自动取消这些高风险订单。
业务风险就明显提高。
订单取消可能影响客户、库存、收入、生产计划和合同履约。
因此，企业 Agent 不应该只区分：
自动执行 / 不允许执行
更合理的是根据风险划分不同执行策略。
| 操作类型 | 示例 | 建议方式 |
|---|---|---|
| 只读、低风险 | 查询订单、查库存、查知识库、汇总数据 | 自动执行 |
| 可逆、低影响 | 普通提醒、生成待办、整理报告 | 可自动执行 |
| 重要业务变更 | 修改订单、流程状态调整 | 人工确认后执行 |
| 高风险操作 | 付款、合同签署、关键生产控制 | 高级审批或禁止 Agent 自动执行 |
一个基本原则是：
风险越高、影响越大、越难撤销的操作，越应该保留人工确认节点。
很多人会认为：
既然最终还需要人点确认，那 Agent 的意义是不是降低了？
其实恰恰相反。
传统流程可能是：
员工自己查询数据；
自己比对信息；
自己打开多个系统；
自己判断；
自己填写单据；
最后再点击确认。
加入 Agent 以后，可以变成：
Agent 自动查询和分析；
Agent 自动准备业务数据；
Agent 自动生成建议；
员工只确认关键动作；
Agent 再完成后续执行。
所以 AI Agent 人工审批并不是让所有步骤重新回到人工。
它真正实现的是：
把人工从“大量操作”压缩成“少量关键判断”。
这也是 AI Agent 人机协同最现实的价值之一。
企业不能只给 Agent 一个粗粒度权限：
允许访问 ERP。
因为 ERP 中可能同时存在：
查询订单；
修改订单；
取消订单；
修改价格；
查询财务数据。
这些操作风险完全不同。
更合理的方式，是把 Agent 权限拆到具体工具。
例如订单 Agent 可以拥有：
查询订单：自动允许
查询库存：自动允许
生成异常报告：自动允许
通知负责人：自动允许
修改订单：人工确认
取消订单：禁止或高级审批
所以 Agent 权限模型应该从：
能不能访问一个系统
进一步变成：
可以调用哪些工具，以及每个工具以什么授权方式执行。
这也是企业 AI Agent 权限控制与普通 AI 问答最大的区别之一。
如果 Agent 需要人工确认，最简单的方法可以是发一句：
是否同意执行？
然后让员工回复：
同意。
但真实企业业务通常还需要展示完整上下文。
例如：
订单：SO10086
客户：XX科技
金额：126,000 元
风险：库存不足
Agent 建议：调整交付时间 2 天
下面提供：
同意建议｜修改方案｜查看订单｜驳回
员工不需要重新进入 ERP 查完整数据，就可以完成判断。
点击按钮以后，事件回调给 Agent。
因此：
消息卡片不仅可以展示 Agent 的业务结果，也可以成为 Agent 向人申请业务授权的操作界面。
这使企业即时通讯中的交互式消息卡片从“业务展示”进一步变成 Human-in-the-loop 的人工确认入口。
真正企业级的人工确认还需要解决几个问题：
谁有资格确认；
确认的到底是哪一个业务动作；
确认时用户看到了哪些信息；
确认以后 Agent 可以执行到什么范围；
整个确认和执行过程是否能够记录。
例如一个生产 Agent 发出操作请求。
某个员工虽然收到了消息，但并不意味着他一定拥有确认权限。
系统还需要结合：
人员身份；
组织关系；
岗位职责；
业务权限；
Agent 工具权限
判断这个人是否能够完成授权。
因此，Human-in-the-loop 实际上是：
Agent 权限 + 人员权限 + 工具权限 + 消息交互
组合形成的一套受控执行机制。
Agent 一个任务可能包含多个不同风险级别的步骤。
例如：
帮我处理这个异常订单。
Agent 可能拆成：
查询库存；
调整订单；
通知客户；
修改生产计划；
生成补充协议。
员工确认“处理异常订单”，并不等于后续所有动作都获得无限授权。
更合理的方式是设置不同授权检查点：
查询和分析：自动执行
订单修改：人工确认
正式客户通知：再次确认
合同或资金动作：高级授权
所以 Human-in-the-loop 更准确地说是：
在 Agent 的任务执行链中，根据风险设置不同级别的授权检查点。
而不是在任务开始前问一次：
是否允许 AI 做所有事情？
Agent 最终需要找到具体的人做判断。
而企业即时通讯本身已经具备：
账号；
组织；
部门；
群组；
机器人；
消息触达；
人员身份。
因此，它可以把：
“这个任务需要谁确认”
转化成：
“把确认请求发送给组织中有权限的人员”。
例如：
采购任务找采购负责人；
生产异常找生产负责人；
合同任务找业务负责人或法务。
确认结果再通过机器人和事件回调返回 Agent。
于是形成：
Agent → 找到授权人员 → 企业即时通讯发起确认 → 用户操作 → Agent 继续执行
企业不需要为了 Agent 再单独建设一套人员和消息体系。
小天互连首先是一套企业级私有化即时通讯平台。
小天互连可以作为 AI Agent Human-in-the-loop 的人工确认入口，通过机器人、组织身份、消息卡片和事件回调，把需要授权的业务动作交给对应人员确认。
例如 ERP 或 MES 产生业务事件后，可以形成：
业务系统产生事件 → Agent 获取并分析数据 → 判断需要人工确认 → 小天互连根据组织关系找到授权人员 → 机器人发送交互式消息卡片 → 用户确认或调整 → 事件回调 Agent → Agent 调用业务系统继续执行
在这条链路中：
Agent 负责分析、判断和任务执行；
业务系统负责真实业务动作；
小天互连负责身份、组织触达、机器人消息和人工交互。
因此：
小天互连的消息卡片不仅可以展示 Agent 结果，也可以成为 AI Agent 请求人工确认和业务授权的交互入口。
企业还可以根据业务工具和风险等级设计三类策略：
自动执行
人工确认后执行
禁止 Agent 执行
所以小天互连中的 AI Agent 控制重点不仅是：
AI 能不能执行。
还包括：
AI 在什么条件下可以执行，以及由谁授权以后才能继续执行。
企业规划 Human-in-the-loop 时，可以重点看五个问题。
第一，哪些工具允许 Agent 自动执行？
低风险、只读和可逆操作可以尽量自动化。
第二，哪些操作必须人工确认？
重要修改、高风险和不可逆操作需要更加严格。
第三，谁有资格确认？
需要结合组织、岗位和业务权限，而不是只看谁收到了消息。
第四，人工确认时是否有足够上下文？
员工应该能够知道 Agent 为什么提出这个建议，以及操作会产生什么影响。
第五，确认和执行过程是否能够追踪？
需要明确：
谁进行了确认；
确认了什么操作；
Agent 后续调用了哪些工具；
最终业务结果是什么。
这些问题，比简单增加一个“确认”按钮，更能够判断企业 Agent 是否真正可控。
企业数字员工并不一定意味着彻底替代员工。
更现实的模式是：
AI 自动完成大量分析、查询和低风险工作；
人只处理真正需要判断和授权的节点。
这样，员工的工作就从：
查询数据；
搬运信息；
填写内容；
重复执行操作，
逐渐变成：
判断、授权和处理例外。
因此，Human-in-the-loop 并不是企业 AI 自动化失败后的补丁。
它本身就是企业级 Agent 的重要架构能力。
Agent 负责提高执行效率。
人负责关键判断和最终授权。
企业即时通讯负责在正确的时间，把需要判断的事情送给有权限的人。
对于小天互连来说，机器人、组织身份、消息卡片和事件回调可以共同形成这一人机协同通路，让 AI Agent 在保持业务效率的同时，把关键业务决策继续留在企业可控范围内。
