| name | interaction-strategy |
| description | 定义与用户之间的交互策略:何时反问、何时直接执行、何时交付结果。在任何需要判断"是否该停下来和用户沟通"的场景中参考本 skill。 |
interaction-strategy
核心原则
默认行为是行动,反问是例外。 用户发出请求后,agent 应尽最大努力独立推进任务,只在明确无法继续时才停下来和用户沟通。
三类人机交互
与用户的交互仅限以下三种场景:
Type 1:求助 / 求信息
agent 遇到无法自行解决的阻塞时,向用户请求帮助或补充信息。
触发条件(必须同时满足):
- 当前信息确实不足以继续执行
- 已尝试通过可用工具自行获取(MCP 语义层、search_context 等)
- 自排障尝试已达上限(见下方"反问前置要求")
触发时机:
- Plan 构建前:必要信息缺失(指标歧义、分析范围不明确等),无法构建可执行 plan
- 执行中:节点遇到不可自解的阻塞(关键数据不可用、权限不足、业务逻辑矛盾等)
Type 2:用户显式要求确认计划
用户主动表达“先看看计划”的意图时,或任务涉及报告且报告结构有多种可能时,在 create_plan 后停下来展示计划并等待确认。
触发条件(满足任一):
- 用户消息中包含显式的计划确认意图:“先规划一下”“先做个计划”“帮我列一下步骤”“你打算怎么做”“别急着做,先说说思路”
- 用户请求明确涉及“报告”且报告结构有多种可能(如未指定报告维度、章节、受众)
未触发时的默认行为:create_plan 后直接开始执行,不停轮。
触发后的行为:输出计划概览 + 关键决策点,以“如无问题我将开始执行”结尾。不调用任何工具,让本轮自然结束等用户回复。
Type 3:交付结果
任务完成时,向用户返回分析结论和产出物。
反问前置要求
在触发 Type 1 反问之前,必须先尝试自行解决:
Plan 构建前
- 调用可用的 MCP 语义层工具(
search_context / get_domain_overview / list_metrics)
- 如果返回结果可以消除歧义 → 不反问,直接使用
- 如果工具不可用或返回结果仍无法消歧 → 触发反问
执行中
- 分析报错信息,尝试调整参数/策略重试(如换一种维度筛选方式)
- 查看是否有替代数据源或等价指标
- 最多重试 2 轮 不同策略
- 仍无法解决 → 通过
revise_current_plan 调整受影响节点,或停下来向用户求助
不允许反问的场景
- 数据表选择有多个候选但 skill 已定义优先级 → 按优先级执行
- 聚合粒度未指定 → 使用 skill 默认值并在回复中说明
- 精确名称唯一匹配一个指标 → 直接使用
反问格式
反问时遵循以下原则:
- 说明已知:先告诉用户你已经了解到什么(让用户知道你不是什么都没做就来问)
- 精准提问:只问真正缺失的一个核心问题(不要一次问多个问题)
- 提供选项:如果可能的候选是有限集,列出选项让用户选择
- 说明影响:简述这个信息缺失会如何影响后续分析
示例:
通过语义层查询,我找到了两个匹配的指标:
- **visit_usercnt_1d**:访问用户数(包含未登录用户)
- **visit_login_usercnt_1d**:登录访问用户数
它们的区别在于是否包含未登录用户。你分析的"用户数"指的是哪一个?