GET /v1/messages/{message_id}/suggested?user=abc-123
Authorization: Bearer {API_KEY}

Path 参数

• message_id (string, 必填)：消息 ID（来自你上一次 /chat-messages 的返回）。 Dify Docs+1

Query 参数

• user (string, 必填)：终端用户标识；必须和创建这条消息时传的 user 一致。注意：Service API 与 WebApp 的会话互不共享。

{
  "result": "success",   // 固定为 success
  "data": [
    "示例：能给我一个带图表的简要总结吗？",
    "示例：还有哪些边界情况需要考虑？",
    "示例：可否生成一份可复制到PPT的要点列表？"
  ]                      // 字符串数组：下一轮建议问题列表（通常返回若干条）
}

返回结构为 result + data[]，其中 data 是建议问题字符串数组。若你的应用/模型未启用该能力，可能返回空数组。

先用 blocking 方式发一条消息拿到 message_id（同一个 user）→ 立刻用这个 message_id 调用建议问题接口。

• message_id 必须来自刚刚这次 /chat-messages（Service API），且 user 完全一致；否则会 404。
• 如果你的应用没有开启/支持“建议后续问题”，data 可能返回空数组；在 Dify 的应用配置里可开启“建议后续问题”。

注意全局模型的有效性

Dify 在你得到一条 AI 回复后，会把最近几轮对话（含本轮）截取成一个小上下文（官方实现通常取最近 3 条、≤≈3000 tokens），再用一段“内部提示词（prompt）”让同一应用配置的 LLM产出 3 条可继续追问的建议，最后通过接口返回给你。

• 触发：当一条消息生成完成后（你拿到 message_id），前端或服务端会再调用建议问题接口：GET /messages/{message_id}/suggested?user=...。docs.dify.ai
• 上下文裁剪：系统从会话里取最近几条消息（社区实践是近 3 条，并做 token 限幅，约 ≤3000 tokens），避免把整段长聊天都喂给模型。星尘