多Agent系统中的用户干预（Human-in-the-Loop）设计

一、核心设计原则

1.1 最小化干预原则

设计目标： 尽量减少不必要的用户干预，只在关键节点请求用户输入。

关键策略：

置信度阈值机制：只有当Agent对决策的置信度低于阈值（如0.7）时才请求干预
预设默认选项：为每个干预请求提供合理的默认选择，用户可以选择快速确认
批量确认：将多个小决策合并为一次干预请求，减少打断频率
安全操作自动批准：对于低风险、高置信度的操作，自动执行无需确认

判断逻辑：

flowchart TD A[检查操作] --> B{是否为敏感操作?} B -->|是| C[需要干预] B -->|否| D{置信度 < 阈值?} D -->|否| E[自动执行] D -->|是| F{是否为安全操作
且置信度高?} F -->|是| E F -->|否| C style C fill:#ffebee style E fill:#e8f5e9

1.2 上下文完整性原则

设计目标： 在请求用户干预时，提供完整的上下文信息，帮助用户做出明智决策。

关键要素：

执行状态展示：当前任务进度、已完成步骤、待执行任务
决策选项说明：每个选项的详细描述、预期影响、推荐理由
历史信息：相关的前置任务结果、用户之前的偏好选择
预期影响：不同选择对后续任务和最终结果的影响

1.3 非阻塞式干预原则

设计目标： 用户干预不应该阻塞整个系统，应该支持部分任务继续执行。

关键机制：

任务暂停和恢复：只暂停需要干预的任务，其他独立任务继续执行
并行任务独立干预：不同任务组的干预请求互不影响
超时自动处理：设置合理的超时时间，超时后使用默认选项或暂停等待

1.4 状态可恢复原则

设计目标： 用户干预后，系统能够从暂停点恢复执行，保持状态一致性。

关键机制：

状态快照：在干预点保存完整的执行状态（Plan状态、执行上下文、已完成任务结果）
决策历史记录：记录所有干预请求和用户响应，支持审计和回滚
状态恢复：从快照恢复执行状态，应用用户决策，无缝继续执行

二、干预机制设计

2.1 干预类型

系统支持三种主要的干预类型：

graph LR A[干预类型] --> B[决策型干预
decision] A --> C[信息补充型干预
info_needed] A --> D[确认型干预
confirmation] B --> B1[选择报告风格] B --> B2[选择执行方案] C --> C1[明确目标受众] C --> C2[提供研究范围] C --> C3[澄清需求] D --> D1[发布内容] D --> D2[删除数据] D --> D3[调用付费API] style B fill:#e3f2fd style C fill:#fff3e0 style D fill:#ffebee

1. 决策型干预（decision）

场景：需要用户在多个选项中选择
示例：选择报告风格（技术深度/通俗易懂/混合）、选择执行方案
特点：提供明确的选项列表，每个选项有详细说明

2. 信息补充型干预（info_needed）

场景：Agent缺少关键信息，需要用户提供
示例：明确目标受众、提供研究范围、澄清需求
特点：提供输入表单，支持文本、选择、多选等输入类型

3. 确认型干预（confirmation）

场景：敏感操作需要用户明确确认
示例：发布内容、删除数据、调用付费API
特点：必须用户明确确认，无默认选项，可提供预览功能

2.2 干预工具函数设计

核心设计：所有用户干预都通过工具函数实现，Agent 通过调用工具来触发干预。

干预工具函数类型：

决策型工具函数 ：request_user_decision(options, context, timeout, default)
- 参数：选项列表、上下文信息、超时时间、默认选项
- 返回：用户选择的选项ID
- 用途：让用户在多个选项中选择
信息补充型工具函数 ：request_user_input(prompt, input_type, validation, timeout)
- 参数：提示信息、输入类型、验证规则、超时时间
- 返回：用户输入的内容
- 用途：获取用户提供的信息
确认型工具函数 ：request_user_confirmation(action, preview, timeout)
- 参数：操作描述、预览内容、超时时间
- 返回：确认结果（true/false）
- 用途：敏感操作需要用户明确确认

工具函数内部实现：

保存当前执行状态快照
生成干预请求并发送给用户界面
更新任务状态为 waiting_intervention
等待用户响应或超时
返回用户响应或默认值

任务状态扩展：

新增状态：waiting_intervention - 等待用户干预

任务状态转换：

stateDiagram-v2 [*] --> pending: 任务创建 pending --> executing: 开始执行 executing --> completed: 执行成功 executing --> failed: 执行失败 executing --> waiting_intervention: 调用干预工具 waiting_intervention --> executing: 工具返回用户响应 waiting_intervention --> paused: 超时且无默认选项 paused --> executing: 用户后续处理 completed --> [*] failed --> [*] note right of waiting_intervention 等待用户干预状态由工具函数触发支持超时处理 end note

2.3 干预时机设计

常见的干预时机主要有：

时机1：Agent 推理过程中的 Tool Call
时机2：任务间插入的确认任务

对于这两种干预时机，我们最好统一到 Tool Call 一种上，因为在做任务规划时，我们通常是描述多 Agent 中各个 Agent 具备的能力，而不会说 Agent 之外还可以在执行任务的时候可以直接调用那些函数或命令，这样可能会增加任务调度的复杂度。当然，以后也可以尝试往这方面进行设计。

核心设计理念：统一到 Tool Call

所有用户干预都通过 Tool Call 触发，这样可以将干预时机统一到 Agent 的工具调用机制中，简化系统设计。

两种干预时机：

时机1：Agent 推理过程中的 Tool Call

场景：Agent 在执行任务时，通过推理判断需要用户干预，主动调用干预工具。

实现方式：

Agent 在推理过程中，根据上下文和任务需求，决定调用干预工具
干预工具在工具函数内部实现用户干预逻辑
工具函数返回用户响应后，Agent 继续执行

示例流程：

scss 复制代码

Agent 推理 → 判断需要用户选择 → 调用 request_user_decision() 工具
→ 工具函数触发用户干预 → 等待用户响应 → 返回用户选择 → Agent 继续执行

时机2：任务间插入的确认任务

场景：一个任务完成后，需要在执行下一个任务前进行用户确认（如大纲完成后确认再写正文）。

实现方式：

在 Plan 中插入一个专门的确认任务
确认任务由对应的 Agent 执行（如大纲确认由写作 Agent 执行）
Agent 执行确认任务时，会调用确认工具函数
工具函数触发用户干预，获取用户确认后返回

示例流程：

markdown 复制代码

1. 任务1完成（生成大纲） 
2. 确认任务（确认大纲）
3. 写作Agent执行确认任务： Agent推理调用 confirm_outline() 工具 → 工具函数触发用户干预
→ 用户确认大纲 → 返回确认结果 
4. 继续执行任务2（撰写正文）

统一设计优势：

所有干预都通过 Tool Call 触发，机制统一
不需要在任务配置中单独标记干预点
Agent 可以根据上下文灵活决定是否需要干预
工具函数可以封装复杂的干预逻辑

干预工具函数设计：

graph LR A[Agent推理] --> B{需要干预?} B -->|是| C[调用干预工具] B -->|否| D[继续执行] C --> E[工具函数执行] E --> F[触发用户干预] F --> G[等待用户响应] G --> H[返回用户响应] H --> I[Agent继续执行] style C fill:#e3f2fd style F fill:#fff3e0 style H fill:#e8f5e9

2.4 干预流程

统一到 Tool Call 的流程：

flowchart TD A[Agent执行任务] --> B[Agent推理] B --> C{需要调用工具?} C -->|普通工具| D[执行工具函数] C -->|干预工具| E[调用干预工具函数] E --> F[工具函数内部:
保存状态快照] F --> G[生成干预请求
包含上下文、选项、预期影响] G --> H[更新任务状态为
waiting_intervention] H --> I[发送干预请求给用户界面] I --> J{等待用户响应} J -->|用户响应| K[验证响应格式] J -->|超时| L{是否有默认选项?} L -->|是| M[使用默认选项] L -->|否| N[暂停任务
等待后续处理] K --> O[工具函数返回用户响应] M --> O O --> P[Agent接收工具返回结果] P --> Q[Agent继续推理和执行] Q --> R[记录干预历史] style E fill:#e3f2fd style J fill:#fff4e1 style L fill:#fff4e1 style O fill:#e8f5e9

超时处理：

如果有默认选项：自动使用默认选项，工具函数返回默认值
如果没有默认选项：工具函数抛出超时异常，任务暂停等待后续处理

三、状态管理机制

3.1 状态快照

快照内容：

classDiagram class StateSnapshot { +String task_id +Plan plan_state +ExecutionContext execution_context +List~TaskResult~ completed_tasks +List~Task~ pending_tasks +InterventionRequest intervention_point +DateTime timestamp +save() +load() } class Plan { +List~TaskGroup~ task_groups +String plan_id +Dict context } class ExecutionContext { +String user_input +Dict history_results +Dict intermediate_variables } class InterventionRequest { +String intervention_type +List~Option~ options +Dict context } StateSnapshot --> Plan StateSnapshot --> ExecutionContext StateSnapshot --> InterventionRequest

保存时机：

在检测到需要干预时立即保存
支持多个干预点的多个快照（通过task_id区分）

3.2 状态恢复

恢复流程：

flowchart LR A[加载状态快照] --> B[恢复Plan状态] B --> C[恢复执行上下文] C --> D[应用用户决策] D --> E[更新任务状态为completed] E --> F[记录用户决策为任务结果] F --> G[继续执行下一个任务] style A fill:#e1f5ff style D fill:#e8f5e9 style G fill:#fff4e1

状态一致性保证：

快照包含完整的执行状态，确保恢复后状态一致
用户决策作为任务结果保存，后续任务可以访问
支持多个干预点的状态管理，互不干扰

3.3 干预历史

记录内容：

干预类型、干预请求内容、用户响应
响应时间戳、用户响应耗时
应用决策后的执行结果

用途：

审计和问题追踪
学习用户偏好，优化默认选项
分析干预频率和效果，优化干预策略

四、用户体验设计

4.1 干预请求展示

关键信息：

标题：清晰说明需要用户做什么（如"请选择报告风格"）
当前状态：任务执行进度、当前步骤、已完成任务数
选项列表：每个选项包含ID、标签、详细描述、推荐标记
预期影响：不同选择对后续任务的影响说明
超时提示：显示剩余时间，超时后的默认行为

展示格式：

markdown 复制代码

[干预请求]
标题：请选择报告风格

当前进度：
- 已完成：2/5 任务
- 当前步骤：生成报告大纲

选项：
1. [推荐] 技术深度报告（5000字）
   面向技术人员，包含技术细节和实现方案
   
2. 通俗易懂报告（3000字）
   面向普通用户，使用通俗语言和案例
   
3. 混合风格报告（4000字）
   兼顾技术和通俗，适合广泛受众

预期影响：
- 选择技术深度：后续将深入技术细节，生成时间较长
- 选择通俗易懂：后续将简化技术内容，生成时间较短
- 选择混合风格：平衡技术和通俗，生成时间中等

[剩余时间：5分钟，超时将使用默认选项：混合风格]

4.2 进度可视化

展示内容：

总体进度百分比
任务组状态（已完成/进行中/待执行）
当前任务组和任务
已完成任务的简要结果

可视化形式：

进度条显示总体进度
任务列表显示每个任务的状态
高亮显示当前等待干预的任务

4.3 响应机制

响应方式：

点击选项按钮（决策型）
填写表单提交（信息补充型）
确认/取消按钮（确认型）

响应验证：

验证响应格式是否正确
对于重要决策，可要求二次确认
提供清晰的错误提示

五、应用场景

5.1 内容创作系统

场景描述： Leader Agent创建计划：[搜索资料, 生成大纲, 确认大纲, 撰写文章, 审核内容, 确认发布]

干预时机设计：

干预时机1：生成大纲过程中的风格选择

实现方式：

写作Agent在执行"生成大纲"任务时，通过推理判断需要用户选择报告风格
Agent调用 request_user_decision() 工具函数
工具函数触发用户干预，显示风格选择选项
用户选择后，工具函数返回选择的风格
Agent根据用户选择的风格继续生成大纲

工具调用示例：

ini 复制代码

Agent推理：需要确定报告风格 → 调用 request_user_decision(
    options=[
        {"id": "technical", "label": "技术深度", "description": "面向技术人员..."},
        {"id": "popular", "label": "通俗易懂", "description": "面向普通用户..."},
        {"id": "mixed", "label": "混合风格", "description": "兼顾技术和通俗..."}
    ],
    context={"task": "生成大纲", "progress": "1/4"},
    default="mixed"
)

干预时机2：大纲完成后确认再写正文

实现方式：

在Plan中插入"确认大纲"任务，由写作Agent执行
写作Agent执行确认任务时，调用 confirm_outline() 工具函数
工具函数显示大纲内容，请求用户确认
用户确认后，工具函数返回确认结果
如果用户需要修改，可以返回修改建议，Agent根据建议调整大纲

工具调用示例：

ini 复制代码

Agent执行"确认大纲"任务 → 调用 confirm_outline(
    outline_content=m大纲内容,
    preview=true,
    timeout=600
)

干预时机3：发布前的确认

实现方式：

在Plan中插入"确认发布"任务，由发布Agent执行
发布Agent调用 request_user_confirmation() 工具函数
工具函数显示内容预览，请求用户确认发布
用户确认后，工具函数返回确认结果

设计要点：

大纲方向选择提供3个选项，默认推荐混合风格
发布确认必须用户明确确认，无默认选项
提供内容预览功能
所有干预都通过工具函数触发，机制统一

5.2 研究系统

场景描述： Researcher Agent执行研究任务时，发现需要明确研究范围和深度。

干预时机设计：

干预时机：研究过程中的信息补充

实现方式：

Researcher Agent在执行研究任务时，通过推理判断缺少关键信息
Agent调用 request_user_input() 工具函数获取研究范围
Agent调用 request_user_decision() 工具函数让用户选择研究深度
工具函数触发用户干预，获取用户输入
用户提供信息后，工具函数返回用户输入
Agent根据用户输入继续执行研究任务

工具调用示例：

ini 复制代码

Agent推理：缺少研究范围 → 调用 request_user_input(
    prompt="请提供研究的时间范围（如：2020-2024年）",
    input_type="text",
    validation={"pattern": "\\d{4}-\\d{4}"},
    timeout=300
)

Agent推理：需要确定研究深度 → 调用 request_user_decision(
    options=[
        {"id": "overview", "label": "概览", "description": "简要概述..."},
        {"id": "medium", "label": "中等深度", "description": "详细分析..."},
        {"id": "deep", "label": "深度研究", "description": "深入研究..."}
    ],
    default="medium"
)

设计要点：

使用信息补充型工具函数
提供输入提示和示例
支持用户输入自定义范围
所有干预都通过工具函数触发

5.3 敏感操作确认

场景描述： Publisher Agent准备发布内容到多个平台。

干预时机设计：

干预时机：发布前的确认

实现方式：

Publisher Agent在执行发布任务时，调用 request_user_confirmation() 工具函数
工具函数显示内容预览和发布平台列表
请求用户明确确认是否发布
用户确认后，工具函数返回确认结果
Agent根据确认结果执行发布或取消操作

工具调用示例：

bash 复制代码

Agent执行发布任务 → 调用 request_user_confirmation(
    action="发布内容到多个平台",
    preview={
        "content": "文章内容预览...",
        "platforms": ["微信公众号", "知乎", "CSDN"]
    },
    timeout=1800
)

设计要点：

使用确认型工具函数，必须用户明确确认
提供内容预览功能
超时时间较长（30分钟），无默认选项
所有干预都通过工具函数触发

六、最佳实践

6.1 干预频率控制

原则： 不要过度请求用户干预，保持系统自动化程度。

实践：

每个任务组最多1-2次干预
使用置信度阈值，只有低置信度决策才请求干预
批量决策：将多个小决策合并为一次干预请求

6.2 干预时机选择

原则： 在合适的时机请求干预，避免打断用户工作流。

实践：

任务内干预：Agent在执行任务过程中，通过推理判断需要干预时调用干预工具
任务间干预：在Plan中插入确认任务，由Agent执行确认任务时调用确认工具
在关键决策点请求干预，而不是每个小决策
提供"稍后处理"选项，允许用户延迟决策

统一实现方式：

所有干预都通过工具函数触发
Agent根据上下文和任务需求，灵活决定是否调用干预工具
对于任务间的确认，通过插入确认任务实现，确认任务中的Agent会调用确认工具

6.3 默认选项设计

原则： 为每个干预请求提供合理的默认选项。

实践：

基于历史数据和用户偏好设置默认选项
明确标注推荐选项
允许用户快速确认默认选项

6.4 错误处理

原则： 妥善处理用户响应错误和超时情况。

实践：

验证用户响应格式，提供清晰的错误提示
超时后使用默认选项或暂停任务
记录所有干预历史，支持问题追踪

七、技术实现架构

7.1 系统架构

7.2 核心组件

干预工具函数（Intervention Tools）：

request_user_decision(): 决策型干预工具
request_user_input(): 信息补充型干预工具
request_user_confirmation(): 确认型干预工具
工具函数内部实现：
- 保存状态快照
- 生成干预请求（包含上下文、选项、预期影响）
- 管理干预状态和超时处理
- 返回用户响应

StateManager：

保存状态快照（Plan状态、执行上下文、任务结果）
从快照恢复执行状态
管理多个干预点的状态

ResponseHandler：

验证用户响应格式
应用用户决策到执行上下文
更新任务状态
记录干预历史

TaskExecutor：

执行任务
支持Agent调用工具函数
当工具函数触发干预时，暂停任务等待用户响应
工具函数返回后，继续执行任务

7.3 数据流（统一到 Tool Call）

sequenceDiagram participant Agent participant TE as TaskExecutor participant IT as InterventionTool participant SM as StateManager participant UI as UserInterface participant User participant RH as ResponseHandler Agent->>TE: 执行任务 TE->>Agent: 提供工具列表 Agent->>Agent: 推理判断需要干预 Agent->>IT: 调用干预工具函数 IT->>SM: 保存状态快照 IT->>IT: 生成干预请求 IT->>UI: 发送干预请求 IT->>TE: 更新任务状态为waiting_intervention UI->>User: 显示干预请求 User->>UI: 用户响应 UI->>RH: 传递用户响应 RH->>RH: 验证响应格式 RH->>IT: 返回用户响应 IT->>SM: 应用用户决策 IT->>Agent: 返回工具函数结果 Agent->>Agent: 继续推理和执行 IT->>SM: 记录干预历史

关键点：

Agent通过工具调用触发干预，而不是通过任务配置
工具函数内部处理所有干预逻辑
Agent接收到工具返回结果后，继续正常执行
对于任务间的确认，通过插入确认任务实现，确认任务中的Agent会调用确认工具

八、最后总结

用户干预（Human-in-the-Loop）是多Agent系统中确保输出质量和用户满意度的关键机制。

核心设计要点：

统一到 Tool Call：所有干预都通过工具函数触发，机制统一，实现简单
两种干预时机 ：
- Agent 推理过程中调用干预工具
- 任务间插入确认任务，确认任务中的 Agent 调用确认工具
最小化干预：只在关键节点请求用户输入，使用置信度阈值和默认选项
上下文完整：提供完整的上下文信息（执行状态、选项说明、预期影响）
非阻塞执行：支持部分任务继续执行，不阻塞整个系统
状态可恢复：通过状态快照和恢复机制，确保从暂停点无缝继续执行
用户体验优先：设计友好的干预界面，提供清晰的进度展示和选项说明

关键机制：

统一到 Tool Call：所有干预都通过工具函数触发，机制统一
两种干预时机 ：
- Agent推理过程中调用干预工具
- 任务间插入确认任务，确认任务中的Agent调用确认工具
三种干预类型：决策型、信息补充型、确认型
状态快照和恢复机制
超时处理和默认选项
干预历史记录和学习

未来优化方向：

学习用户偏好，减少重复干预
智能推荐最佳选项
支持批量干预和模板化响应
增强干预历史分析和优化