一、问题：太听话的 Agent 反而不靠谱

使用者痛点：需求模糊导致大量返工、时间浪费、业务风险增大。

先看一个真实场景：

使用者：帮我写一个商机分析报告
至于Agent，→ 调用商机查询工具
→ 调用数据统计工具
→ 生成报告模板
→ 输出一份 5000 字的通用报告
使用者这方面。不是这种，我要的是风险评估报告，不是概况报告
从Agent来看，好的，我重新生成...
→ 重新调用工具
→ 换一个模板
→ 输出风险评估报告
使用者这方面，也不是这种，我要的是针对特定客户的...
至于Agent，...

问题出在哪？按理说，Agent 假设太多了。

使用者说了“商机分析报告”。Agent 假设：
├── 假设：分析对象是所有商机 → 实际是某个特定客户
├── 假设：报告类型是概况 → 实际是风险评估
├── 假设：报告深度是概要 → 实际需要详细分析
├── 假设：输出格式是文本 → 实际需要表格 + 图表
└── 假设：时间范围是本月 → 实际是本季度

每一个假设都可能错，每个错误都代表着返工。传统 Agent 的模式是“先干再说”，Grill Me 的模式是“先问清楚再干”。

二、什么是 Grill Me 模式

Grill 直译为“烤/盘问”。在 AI Agent 语境下指的是 Agent 在执行任务之前，主动向使用者提出一系列结构化问题，澄清需求边界和隐含约束。

传统模式 vs Grill Me 模式
至于传统模式，使用者 → → Agent → → 输出
↓ 使用者发现不对
↓ 重新描述需求
↓ Agent 重新执行
Grill Me 模式：
使用者 → → Agent → → 使用者回答
↓ Agent 确认理解
↓ → 输出

Grill Me 的三个主要环节

• 需求分析
  • 解析使用者指令
  • 识别模糊点和缺失信息
  • 生成待澄清问题列表
• 反问澄清
  • 按优先级排序问题
  • 提供默认选项降低回答成本
  • 控制问题数量
• 确认执行
  • 综合使用者回答。更新任务理解
  • 生成执行计划
  • 向使用者确认计划
  • 执行任务

三、什么时候该 Grill，什么时候该直接干

使用者痛点：对简单任务频繁被拦截提问会感到拖慢，对复杂任务却缺少必要的澄清导致返工。

决策矩阵

├── 输出有多种可能形态
├── 缺关键参数
├── 错误执行返工成本高
├── 涉及不可逆操作
└── 指令中出现模糊词

四、如何让 Agent 学会反问

至于策略一，System Prompt 指令

SYSTEM_PROMPT = """你是一个任务规划助手。在执行任何任务之前，你必须：
1. 分析使用者指令。识别可能模糊或缺失的信息。2. 提出最多 {MAX_QUESTIONS} 个澄清问题。3. 等待使用者回答后再执行。说起来，如果使用者指令足够明确，可以跳过反问直接执行。老实说，说到反问规则，- 问题必须是选择题或填空题，不要开放式提问。- 每个问题提供推荐选项。怎么说呢，- 按关键性排序，最关键的放第一个。- 如果只需要问 {MAX_QUESTIONS} 个问题，不要问超过 {MAX_QUESTIONS} 个。"""

效果：L​LM 有时会忘记反问或提太多无关问题，需要进一步约束。

至于策略二，结构化反问 Schema

使用上一篇文章的 Schema 来保证反问质量：

// 定义结构化输出
public record GrillResult(
@Description boolean needGrill,@Description List ambiguities,@Description List questions,@Description String plan) {}
public record ClarifyQuestion(
@Description String question。@Description String type,@Description List options,@Description int recommendedIndex,@Description int priority) {}

调用流程：

// 第一步先：Grill 分析
var grill = chatClient.prompt
.user
.call
.entity;// 接下来：判断是否需要反问
if ) {
// 展示结构化问题给使用者，等待回答
return renderQuestions);} else {
// 直接执领域务逻辑
return executeTask);}

Sche​ma 带来的好处：

策略三的观点是，对话状态机管理

更工程化的做法是在后台维护状态机，实现 “反问→回答→再分析→执 行” 的完整闭环。

Agent 状态机
│ ├─ IDLE ：等待使用者指令
│ │ └─ 收到指令 ➜ ANALYZE
│ ├─ ANALYZE ：分析需求，决定是否反 问
│ │ ├─ 需求明确 ➜ EXECUTE
│ │ ├─ 需求模糊 ➜ ASK
│ │ └─ 需求矛盾 ➜ CLARIFY
│ ├─ ASK ：向 使用者提 问
│ │ └─ 收到回答 ➜ ANALYZE
│ ├─ CLARIFY ：指出 矛盾。请求确认
│ │ └─ 使用者确认 ➜ EXECUTE
│ └─ EXECUTE ：执 行任 务
│ ├─ 成功 ➜ DONE
│ └─ 失败 ➜ ANALYZE

public enum AgentState {
IDLE,// 等待输入
ANALYZE,// 分析需求
ASK,// 反 问澄清
CLARIFY,// 指出矛盾并请求确认
EXECUTE,// 执行任务
DONE // 完成
}
public class GrillMeAgent {
private AgentState state = AgentState.IDLE;private List pendingQuestions;private Map answers = new HashMap<>;private final ChatClient chatClient;public Response handle {
return switch {
case IDLE,ANALYZE -> startAnalyze;case ASK -> processAnswer;case EXECUTE -> execute;怎么说呢，default -> Response.error;}，}
private Response startAnalyze {
this.state = AgentState.ANALYZE;var grill = chatClient.prompt
.user
.call
.entity;if ) {
this.state = AgentState.ASK;this.pendingQuestions = grill.questions;return Response.questions);} else {
this.state = AgentState.EXECUTE;return execute);}
}
private Response processAnswer {
// 简单解析，将答案映射到对应的问题上
for;i++) {
answers.put.question,parseAnswer);老实说，}
// 重回 ANALYZE
评估是否还需追问
this.state = AgentState.ANALYZE;return startAnalyze);}
...
}

五、反 问提 问 的艺术

好 问题 vs 坏 问题

 ❌ 坏 问题
├─ “你想 怎么 做？”
├─ “有什么 特殊 要求 吗？”
├─ “请详细 描述你的需求”
└─ “这个 问题 本身 就需要 使用者 大量 思考”
✅ 好 问题
├─ “分析 对象 ：A) 全部 商机 B) 指定 客户 ”
├─ “时间 范围 ：A) 本周 B) 本月 C) 本季度”
└─ “请仅选择 上述 字母，就可以完成”。怎么说呢，

主要 原则： 把认知负担从 使用者 转移 到 Agent。Agent 列举所有可能性，使用者只需做选择。

提 问 优先级 框架

 提 问 优先级
│ ├─ P0 ：不可逆后果
│ │ └‑ “此 操作 将 删除 所有 数据，确认 范围 是？”
│ ├─ P1 ：主要 参数 缺失
│ │ ├‑ 分析 对象 缺失
│ │ ├‑ 输出 格式 未 指定
│ │ └‑ 主要 限制 未 明确
│ ├─ P2 ：影响结果 的 模糊 点
│ │ ├‑ 时间 范围
│ │ ├‑ 深 度／详细 程 度
│ │ �└‑目标受众
│ �└‑ P3 ：锦上添花 的 参数
│ �└‑语言 偏好
| �└‑ 风格 偏好

批量 提问信 vs逐个 提问信

 批量 提问信
├‑ 好处 ：一次 性 完成 所有 信息 收集。
减少交互轮次
├‑ 场景 ：各 个 问题 相互 独立
└‑ 示例 :
“在 开始 前，请 确认 以下 信息 :
• 分析 对象 : A) 全部 B) 指定 客户 （ 推荐 : XX 科技 )
• 报告 类型 : A) 概况 B) 风险评估 （ 推荐 ) C)机会 推荐
• 时间 范围 : A) 本周 B) 本月 （ 推荐 ) C)本季度”
逐个 提问信
├‑ 好处 ：每个 问题 可 基于 上一次 回答
├‑ 场景 ：有 强依赖关系 的 多 步骤 对话
└‑ 示例 :
从Q1来看，“分析 对象 是？”
从A1来看，“指定 客户”
说到Q2，“哪个 客户？”
至于A2，“XX 科技”
至于Q3，“XX 科技 的 哪个 项目？”
**实践 建议** : 默认 使用 批量 提问信，仅 在 必须 动态 引导 时 使用逐个 提问信。

六、实战：一个完整的 Grill Me Agent

场景 ：技术 文档 写作 Agent

使用者 痛点 : 文档 类型、受众、篇幅 等信息 常 被 漏 掉，导致 多 次 重写。

public class DocWritingAgent {
private final ChatClient chatClient;// 步骤1️⃣  :  Grill  分析  请求
public GrillResult analyzeRequest{
var prompt = """
说到使用者请求，{request}
分析该请求并列出所有需要澄清的信息。技术文档通常涉及:
- 文档类型
- 主要主题
-目标读者
-输出格式
-篇幅要求
""";return chatClient.prompt
.user.param)
.call
.entity;}
// 步骤2️⃣  : 渲染结构化提问供前端展示
public String renderQuestions{
var sb=new StringBuilder;sb.append，for;i++){
var q=questions.get;sb.append.append.append).append;if，=null &&!q.options.isEmpty){
for.size;j++){
var prefix=)?" ★ ":"   "，sb.append.append).append ")
.append.get);if) sb.append;sb.append，}
}
sb.append;}
sb.append，return sb.toString;老实说，}
// 步骤３️⃣  : 综合答案并执 行
public String executeWithAnswers(String originalRequest。List questions,List answers){
var fullReq=buildFullRequest;return chatClient.prompt
.user
.call
.content;}
private String buildFullRequest(String orig。List qs,List ans){
var sb=new StringBuilder;sb.append.append;for，i++){
sb.append.append.question)
.append.append).append;说起来，}
return sb.toString;}
}

实际交互效果

再看使用者。“帮我写一份技术方法文档”
Agent的观点是，“在开始之前，请确认以下信息：
★ A) 程序设计方案
B) 接口规范文档
C) 技术评审文档
•目标读者是谁？A) 技术团队内部
★ B) 技术管理层
C)业务方
•主要主题方向？A) 微服务架构设计
★ B) 数据权限方案
C) 性能调整方法
•预期篇幅？A) 精简版
★ B) 标准版
C)详细版
直接回复选项字母即可，如：“A B B B”
再看使用者，“A B B B”
Agent这方面。“收到，已确认:
- 类型: 程序设计方案
- 阅读者: 技术管理层
- 主要主题: 数据权限方案
- 篇幅: 标准版
正在生成文档…”

七、Grill Me 的进阶：自适应反问

痛点： 固定规则无法覆盖所有业务场景；过多或不足的问题都会影响体验。

三层自适应策略

自适应反问策略 |
├─ 第一层 : 快速判断
|  • 基于关键词匹配判 定任务类型；|  • 简单查询类 ✅ 跳过；|  • 生成/设计类 ✅进入第二层；|
├─ 第二层 : LLM轻量 分析
|  • 用小模型 检测 参数缺失 与 模糊点；|  • 输出 needGrill+模糊列表；|  • false ⇒ Direct Execute；|  • true ⇒进入第三层；|
└─ 第三层 : 完整结构化 Grill Me
• 根据上下文 动态生成选择题与推荐；• 控制总数 ≤ {MAX_QUESTIONS};S​plit Benefit:`轻量阶段过滤掉80%简单请求。只在真正需要时启动完整 Gr​Ill 流程，大幅降低费用与延迟。`

上下文积累避免重复提问 

public class ContextAwareGrillAgent {
private UserContext context;不过，public GrillResult analyzeWithContext{
var prompt = """
至于使用者请求，{request}
从已知上下文来看。•角色:{role}
•常用输出格式:{format}
•上次分析对象:{lastTarget}
再看•偏好语言，{language}
请基于已有信息仅询问信息缺口，不要重复已知内容。"""，return chatClient.prompt
.user
.param
.param)
.param)
.param)
.param))
.call
.entity;}
}


对比展示：


无上下文，每次全套提問。❌重复劳动，

有上下文，仅补齐新增缺口。✅提高效率，


八、Grill Me 的代价和缓解措施 

交互成本比较

无 Grill Me总交互轮次总耗时返工概率Token 增幅LLM 调用次数适用场景



典型流程：
① 输入指令
② 自动执 行
③ 若结果错误需手动纠正 &
④
执 行 

加入 Grill Me：
① 输入指令
② 程序提出澄清问题
③ 使用者回复
④ 完整执 行并产 出结果 

* 前提条件*: ** Gr​​ ill ** 的提問必須精准；若問題無關則會增加交互成本。老实说，COST AND LATENCY IMPACTS





…老实说，

...


对比项
无 GrillMe
有 GrillMe'


LLM 调用次数
1
≈₂ 次 ' /
...
…