人工确认与多 Agent 协作

学习目标

在有外部影响的操作前保存可审阅提案。
将批准绑定到具体参数，避免批准后内容被替换。
判断多 Agent 协作是否带来可测量的收益。

前置要求：工具执行边界与可恢复工作流。本节离线示例不会发送邮件、发布内容或修改外部服务。

人工确认应当确认什么

“是否继续？”缺少足够信息，用户不知道自己批准了什么。好的提案包含操作、目标对象、具体内容与预期影响。例如发送邮件前展示收件人、主题和正文，而不是仅展示“发送一封邮件”。

程序应在批准时暂停执行，并保存待审内容。如果内容之后变化，需要重新审阅，不能沿用旧批准。批准记录还应关联任务、审批人和有效期。

把提案变成稳定快照

下面使用标准 JSON 序列化和 SHA-256 摘要判断提案是否变化。这不是身份认证方案，也不是防止攻击者篡改数据库的完整机制。它只演示“批准对象必须与执行对象一致”。

保存为 approval.py 并运行：

import hashlib
import json

def snapshot(proposal):
    payload = json.dumps(proposal, ensure_ascii=False, sort_keys=True, separators=(",", ":"))
    digest = hashlib.sha256(payload.encode("utf-8")).hexdigest()
    return payload, digest

def prepare(proposal):
    payload, digest = snapshot(proposal)
    return {
        "status": "pending", "payload": payload,
        "digest": digest, "approved_digest": None,
    }

def approve(record, reviewed_digest):
    if record["status"] != "pending" or record["digest"] != reviewed_digest:
        raise ValueError("提案已变化或状态不允许审批")
    record.update(status="approved", approved_digest=reviewed_digest)

def simulate_execute(record):
    actual = hashlib.sha256(record["payload"].encode("utf-8")).hexdigest()
    if record["status"] != "approved" or actual != record["approved_digest"]:
        raise ValueError("缺少匹配的批准")
    proposal = json.loads(record["payload"])
    record["status"] = "completed"
    return {"mode": "simulation_only", "would_execute": proposal}

proposal = {
    "action": "send_email", "to": "reviewer@example.com",
    "subject": "研究简报草稿", "body": "这是一封不会实际发送的教学邮件。",
}
record = prepare(proposal)
print("待审阅：", record["payload"])
reviewed_digest = record["digest"]
approve(record, reviewed_digest)  # 演示审批事件；真实应用由已认证用户触发。
print(simulate_execute(record))

本例把批准调用写在脚本中，仅为了演示状态转移。真实系统不能让模型自己调用“批准”来满足人工审批要求。审批接口应检查已验证身份、任务权限、提案版本和过期时间。

暂停不是失败

工作流遇到人工确认节点时，可以进入 awaiting_approval 状态并释放计算资源。批准后从该节点恢复，拒绝后保留原因并终止或回到编辑阶段。超时也应有明确状态，不能无限显示“正在执行”。

即使已批准，执行前仍要检查业务条件。例如库存、权限或目标资源可能在等待期间发生变化。批准不等于绕过执行时校验。

多 Agent 应该解决具体分工问题

研究员负责收集证据，撰写者负责组织简报，审核者检查引用，是一种可能的分工。但三个角色不必一开始就是三个独立 Agent，也可以先是一个工作流中的三个节点。只有任务可以独立执行，或角色上下文确实冲突时，再尝试拆分。

交接内容应包含目标、输入证据、输出契约、未解决问题和预算。不要只让角色互相“讨论直到满意”，因为满意没有可操作的终止标准。更多模型调用也会增加延迟、费用和误差传播，需要与单 Agent 基线比较。

练习与验收

在批准之后修改 record["payload"]，确认执行被拒绝。再尝试不批准直接执行，以及重复执行已完成记录。

三种不合法路径都不能执行。
审阅内容与执行内容一致。
用户拒绝和审批过期有可设计的状态。
为一个研究任务写出研究员和审核者的交接契约。

常见误区

哈希不是身份验证；如果任意人都能改批准记录，摘要无法保护审批流程。多 Agent 也不是自动的质量保证，审核者可能重复同样的错误。要用独立证据和评估结果判断收益。

人工确认与多 Agent 协作

学完这一课，你将能够