人机协作模式：实用指南

团队在 AI 采用上失败，不是因为模型不够强，而是因为没人决定 谁做什么——于是人类要么重新检查一切（省不下时间），要么盲目盖章（错误上线）。协作模式就是解决方案：人类与模型之间明确、可重复的工作分工。以下是覆盖大多数真实工作流的六种模式，以及选择它们的决策规则。

自治阶梯

下面的每种模式都位于一个 AI 自治程度递增的阶梯上。设计问题从来不是“AI *能* 多自治”——而是“未检测到的错误代价有多大”。高影响半径 → 低阶梯。

AI 作为审稿人     — 人类做工作，AI 评审
AI 作为起草者     — AI 生成初稿，人类负责编辑
人在回路 (HITL)   — AI 执行，人类批准每个关键步骤
人在环上 (HOTL)   — AI 自由执行，人类监控并抽样
完全委托          — AI 在硬约束内端到端负责任务

模式 1：AI 作为审稿人

人类撰写；模型根据明确的检查清单进行评审。这种反转通常的起草/评审分工，在判断密集的地方（写作）保持人类所有权，在覆盖范围重要的地方（检查）使用模型。代码审查机器人、合同条款检查器和提交前的论文审查都属于此类。

重要的实现细节：强制结构化发现，而不是散文。“看起来不错，有小建议”是评审表演。要求基于行的发现并附带严重性，以便人类可以逐一处理——参见 Zod vs Pydantic for AI validation 中的结构化输出技术。

模式 2：AI 作为起草者，人类作为编辑者

这是内容、邮件、规范和样板代码的工作马模式。两条规则区分了从中受益的团队和没有受益的团队：

人类必须是真正的编辑——能够在该领域区分好坏的人。起草加速专家；它掩盖了新手错误。

编辑率是你的健康指标。 如果编辑者经常重写 >50%，则起草提示/上下文有误；如果编辑率接近 0%，则存在橡皮图章风险，应考虑有意地（而非疏忽地）向上移动阶梯。

模式 3：人在回路 (HITL)

AI 执行多步骤工作，但在关键操作处暂停等待批准。这是接触生产系统、资金或客户的智能体的标准模式。代码中的审批门：

python
RISK_TIERS = {
    'read_data':   'auto',     # 仅记录日志
    'draft_email': 'auto',
    'send_email':  'approve',  # 人类门控
    'update_crm':  'approve',
    'issue_refund': 'approve_senior'
}
async def execute(action, payload):
    tier = RISK_TIERS.get(action, 'approve')      # 未知 → 门控，故障安全
    if tier == 'auto':
        return await run(action, payload)
    decision = await request_approval(action, payload, tier,
                                      context=agent.reasoning_summary())
    if decision.approved:
        return await run(action, payload)
    agent.observe(f'Rejected by {decision.reviewer}: {decision.reason}')  # 反馈，不要只是停止

需要防范的两种失败模式：审批疲劳（对太多琐碎操作设置门控，人类停止阅读——按风险分级，而非统一处理）和无上下文的审批（展示智能体的推理和将要变更的差异，否则审批又成了表演）。

模式 4：人在环上 (HOTL)

AI 无需每个操作的门控即可运行；人类监控仪表板、抽样输出并拥有终止开关。适用于高数量/低影响半径的工作：支持工单分类、内容标记、监控摘要。不可妥协的条件：始终可用的暂停控制、带有跟踪分歧率的抽样人工审计，以及当置信度下降或输入看起来不像训练分布时自动降级到 HITL。

模式 5：升级链

不是阶梯的一级，而是跨阶梯的路由器：AI 处理简单的 80%，将困难的 20% 升级并附带完整上下文。经典版本是支持分流；同样的结构适用于文档处理和代码分类。质量标准：升级的案例必须比原始状态*更好*——总结历史、尝试过的解决方案、具体障碍——否则人类会学会不信任队列。

模式 6：结对工作

交互式、对话式协作——AI 结对编程是典型场景。人类拥有意图和架构；模型拥有记忆和打字速度。区分高效结对与挣扎的是规范质量：经验丰富的结对者预先加载约束（“Python 3.12，无新依赖，必须保持向后兼容”），而不是一次一个地迭代。此模式的工具比较见 Cursor vs GitHub Copilot 和 Windsurf vs Devin vs SWE-agent（针对自主端）。

选择：三个问题

错误代价？ 可逆且廉价 → 阶梯 4-5。不可逆或面向客户 → 阶梯 1-3。

你的人类真的能判断输出吗？ 如果不能，任何模式在大规模下都不安全——先修复专业知识或缩小任务范围。

数量？ 每天几十个 → 起草或结对。每天数千个 → 人在环上或升级链；逐项人工审查在数学上无法跟上。

每季度重新评估：随着信任数据的积累（批准率、审计分歧），任务应该*赢得*向上移动阶梯的权利——基于测量移动，而非凭感觉。

常见问题

多智能体系统如何适配？ 同样的阶梯，应用于系统边界：一组智能体从协作设计角度看仍然是一个“AI”。参见 CrewAI vs AutoGen。

如何衡量模式是否有效？ 将质量指标（错误率 vs 人类基线）与成本指标（每项任务的人类分钟数）配对。只有当一种模式在某一指标上优于基线而不在另一指标上落后时，它才算获胜。

问责制呢？ 只有当你能够为每个输出指定负责的人类时，模式才可部署。“AI 决定的”是架构异味——阶梯 4-5 仍然有一个负有审计职责的负责团队。

---

*最后更新：2026 年 6 月。*