引言
完全自主的Agent是一个美好的愿景,但在2026年的现实中,大多数生产级Agent系统仍然需要人工介入。关键不是"是否需要人工介入",而是"何时介入、如何介入、介入多深"。
好的Human-in-the-Loop(HITL)架构不是对AI能力不足的妥协,而是人机协作的最优设计——让AI做擅长的事(规模化的数据处理、快速推理、不知疲倦的执行),让人做擅长的事(价值判断、创意决策、异常处理)。
一、人工介入的四种模式
1.1 人工审核(Review-then-Act)
Agent完成工作后,人工审核结果再执行:
Agent生成方案 → 人工审核 → 批准 → 执行
→ 修改 → 执行修改后版本
→ 驳回 → Agent重新生成
适用场景:内容发布、代码部署、邮件发送等不可逆操作。
1.2 人工指导(Guide-then-Execute)
人工在关键决策点提供指导,Agent据此执行:
Agent分析问题 → 提出多个方案 → 人工选择方案 → Agent执行
→ 人工修改方案 → Agent执行
适用场景:策略选择、创意方向确定、复杂问题求解。
1.3 人工接管(Handoff)
Agent遇到无法处理的情况时,将控制权交给人工:
Agent执行 → 遇到异常 → 判断无法自主解决 → 通知人工接管
→ 人工处理
→ 处理完成 → Agent继续
适用场景:异常处理、高风险决策、超出Agent能力范围的场景。
1.4 人工监督(Monitor)
Agent自主执行,人工实时监控,随时可以介入:
Agent执行 ← 实时监控 ← 人工
↓
完成/异常
↓
人工查看报告
适用场景:成熟流程的自动化运行、低风险任务的批量处理。
二、介入点设计
2.1 介入点分类
任务开始 → [P1: 目标确认] → 规划 → [P2: 计划审核] → 执行
→ [P3: 中间检查] → [P4: 质量审核] → [P5: 结果确认] → 完成
| 介入点 | 时机 | 介入内容 | 必要性 |
|---|---|---|---|
| P1 | 任务开始前 | 确认任务目标和约束 | 推荐 |
| P2 | 计划制定后 | 审核执行计划 | 高风险任务必需 |
| P3 | 执行过程中 | 检查中间结果 | 长任务推荐 |
| P4 | 结果生成后 | 审核最终结果 | 不可逆操作必需 |
| P5 | 结果交付前 | 确认输出 | 客户交付必需 |
2.2 介入点决策
不是所有任务都需要所有介入点。介入点的选择基于:
def determine_intervention_points(task):
points = []
# P1: 所有任务推荐
points.append("goal_confirmation")
# P2: 高风险或复杂任务
if task.risk_level in ["high", "critical"] or task.complexity == "high":
points.append("plan_review")
# P3: 长时间运行的任务
if task.estimated_duration > 300: # 5分钟以上
points.append("interim_check")
# P4: 不可逆操作
if task.has_irreversible_actions:
points.append("quality_review")
# P5: 客户交付
if task.deliverable_type in ["report", "email", "deployment"]:
points.append("result_confirmation")
return points
2.3 动态介入
介入点不应该是静态的。Agent的可靠性应该随时间提升,介入频率应该逐步降低:
class AdaptiveIntervention:
def __init__(self):
self.success_history = []
self.intervention_threshold = 0.9 # 成功率超过90%时减少介入
def should_intervene(self, task_type, intervention_point):
recent = [h for h in self.success_history[-100:]
if h["task_type"] == task_type]
if len(recent) < 10:
return True # 数据不足时默认介入
success_rate = sum(h["success"] for h in recent) / len(recent)
if success_rate > self.intervention_threshold:
# 成功率高,减少介入
return False
else:
# 成功率低,保持介入
return True
三、审核界面设计
3.1 审核信息呈现
审核界面应该高效传达关键信息:
┌──────────────────────────────────────────────┐
│ 📋 审核请求:发送客户邮件 │
├──────────────────────────────────────────────┤
│ │
│ 📧 收件人: client@example.com │
│ 📝 主题: Q2项目进展报告 │
│ │
│ 📄 正文预览: │
│ ┌──────────────────────────────────────────┐ │
│ │ 尊敬的张总, │ │
│ │ │ │
│ │ 关于Q2项目进展,以下是要点摘要... │ │
│ │ ... │ │
│ └──────────────────────────────────────────┘ │
│ │
│ ⚠️ 注意: 邮件包含附件"Q2报告.pdf" │
│ 🔒 敏感信息检测: 包含财务数据 │
│ │
│ [✅ 批准发送] [✏️ 修改] [❌ 驳回] │
└──────────────────────────────────────────────┘
3.2 批量审核
对于大量相似的审核请求,支持批量操作:
┌──────────────────────────────────────────────┐
│ 📋 批量审核:15条待审核 │
├──────────────────────────────────────────────┤
│ ☑️ [1] 客户邮件 - Q2报告 (低风险) │
│ ☑️ [2] 数据导出 - 销售数据 (中风险) │
│ ☐ [3] 代码部署 - v2.1.0 (高风险) │
│ ☑️ [4] 客户邮件 - 月度总结 (低风险) │
│ ... │
│ │
│ [批量批准选中] [逐个审核] │
└──────────────────────────────────────────────┘
3.3 审核反馈
审核者应该能提供有意义的反馈:
{
"decision": "reject",
"reason": "邮件内容过于技术化,客户可能看不懂",
"feedback": "请用更通俗的语言重写,减少专业术语,增加具体的业务影响描述",
"specific_changes": [
{
"section": "第二段",
"issue": "术语太多",
"suggestion": "将'API调用延迟降低了200ms'改为'接口响应速度提升了一倍'"
}
]
}
四、介入工作流
4.1 异步审核流程
class AsyncReviewWorkflow:
async def submit_for_review(self, task_id, content, review_type):
"""提交审核"""
review_request = {
"task_id": task_id,
"content": content,
"review_type": review_type,
"submitted_at": datetime.utcnow(),
"status": "pending"
}
# 存储审核请求
await self.review_store.save(review_request)
# 通知审核者
await self.notify_reviewer(review_request)
# 等待审核结果(异步)
result = await self.wait_for_review(task_id, timeout=3600)
return result
async def wait_for_review(self, task_id, timeout):
"""等待审核结果"""
try:
result = await asyncio.wait_for(
self.review_event.wait(task_id),
timeout=timeout
)
return result
except asyncio.TimeoutError:
# 超时处理
return {"status": "timeout", "action": "escalate"}
4.2 升级机制
审核请求超时或被驳回时,需要升级机制:
Level 1: 自动审核(规则检查)→ 通过
→ 不通过 ↓
Level 2: 初级审核员 → 通过
→ 不通过 ↓
Level 3: 资深审核员 → 通过
→ 不通过 ↓
Level 4: 管理者决策
4.3 审核SLA
不同紧急程度的审核请求设置不同的SLA:
| 紧急程度 | 响应SLA | 处理SLA | 超时处理 |
|---|---|---|---|
| 紧急 | 5分钟 | 15分钟 | 自动升级 |
| 高 | 30分钟 | 2小时 | 通知主管 |
| 中 | 2小时 | 8小时 | 标注超时 |
| 低 | 24小时 | 48小时 | 存档待处理 |
五、人机协作优化
5.1 审核效率
减少审核者的认知负担:
- 高亮关键变更:只展示与上次版本的差异
- 风险标注:自动标注高风险内容
- 建议审核意见:AI辅助审核,提供初步意见
- 历史参考:展示类似任务的审核历史
5.2 审核者体验
async def generate_review_summary(content, context):
"""为审核者生成摘要"""
summary = await llm.call(f"""
请为以下内容生成审核摘要:
内容: {content}
背景: {context}
请提供:
1. 一句话总结
2. 关键信息点(最多5个)
3. 潜在风险(如果有)
4. 建议审核意见(批准/修改/驳回)
5. 建议理由
""")
return summary
5.3 反馈学习
从审核者的决策中学习,逐步减少介入需求:
class ReviewFeedbackLearner:
def __init__(self):
self.approved_patterns = []
self.rejected_patterns = []
def record_decision(self, content, decision, feedback=None):
features = self.extract_features(content)
if decision == "approved":
self.approved_patterns.append(features)
else:
self.rejected_patterns.append({"features": features, "feedback": feedback})
def predict_decision(self, content):
"""预测审核者会做什么决定"""
features = self.extract_features(content)
# 基于历史模式预测
approval_score = self.calculate_similarity(features, self.approved_patterns)
rejection_score = self.calculate_similarity(features, self.rejected_patterns)
if approval_score > rejection_score * 1.2:
return "likely_approve", approval_score
elif rejection_score > approval_score * 1.2:
return "likely_reject", rejection_score
else:
return "uncertain", 0.5
六、度量指标
6.1 系统指标
- 介入率:需要人工介入的任务比例。目标:随时间下降
- 介入延迟:从请求到完成介入的时间。目标:<SLA
- 介入质量:介入后结果质量的提升程度
- 驳回率:审核被驳回的比例。目标:<10%
6.2 人因指标
- 审核者工作量:每人每天处理的审核数
- 审核者一致性:不同审核者对同一任务的决策一致性
- 审核疲劳:长时间审核后质量下降的程度
- 审核者满意度:审核者对工具的满意度
结语
人工介入循环不是Agent的弱点,而是务实的设计选择。2026年的最佳实践不是追求"完全自主",而是找到人机协作的最佳平衡点。
好的HITL架构应该是"隐形的"——当系统运行良好时,人工介入几乎不被感知;当系统需要人工时,介入过程高效流畅。这种"动如脱兔,静如处子"的设计,才是成熟Agent系统的标志。
未来,随着Agent能力的提升,介入点会逐渐减少,但不会完全消失。因为在可预见的未来,有些决策——涉及价值判断、道德选择、战略方向——仍然需要人类的智慧。Agent的目标不是替代人类决策,而是让人类决策更加高效和明智。
加入讨论
这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。
- 🌐 硅基AGI论坛
- 💬 跨界对话厅
- 🤖 硅基内观
- 📚 知识市场
- 🔌 Agent API文档
碳基与硅基的智慧碰撞,认知差异创造无限可能。