第一次听到 hindsight 这个词是在一次项目复盘会上。当时我们做的客服机器人总是重复同一个错误客户说发票抬头写错了下一次它还是会照旧填错。后来我在 Dify 上搭了一个叫 hindsight 的小工具专治这种“没记性”。简单说就是给 AI 应用装一个“后视镜”让它在跑完一次任务之后自动回头看看刚才哪里做得不好、哪里值得记下来然后把结论沉淀成经验下次遇到类似问题时直接拿出来用。这个工具解决的是大模型应用里最容易被忽略的问题没有记忆、没有反思、没有进步。它适合正在用 Dify 做 Agent、客服机器人、内容生成工具的人也适合那些已经跑通业务流但总觉得 AI“差点意思”的团队。hindsight 不改变你现有的对话逻辑只是在旁边加了一条复盘链路帮你把每一次交互变成下一次的养料。1. 项目为什么选 hindsight 这个方向1.1 不做复盘的大模型应用就是在裸奔用过 ChatGPT 或者各种大模型 API 的人都知道模型本身是没有状态的。你调用一次接口它给你一次输出它不会记得你上次问过什么更不会记得上次它自己答错了什么。很多团队在 Dify 上搭了客服、搭了文档助手跑起来一看功能是通的但用一个月就会发现AI 翻来覆去犯同样的错。我见过一个很典型的场景某项目的 AI 助手负责帮销售写报价单客户明确说过“我们公司不走增值税专用发票”但 AI 下一次还是按默认模板生成含税报价。不是模型不行是它根本不知道“上次那个客户说过什么”。这种问题靠加大模型本身解决不了你需要的是一个独立于对话流程之外的“事后复盘机制”——也就是 hindsight。hindsight 的核心思路很简单每次交互结束之后把这场对话里的关键信息、AI 的决策路径、客户反馈的结果都记录下来让一个专门的 LLM 节点负责做反思生成“这次哪里做对了、哪里做错了、下次应该怎么做”的经验摘要。然后这些摘要进入经验库在下一次对话开始时被检索出来作为参考上下文喂给主模型。这套逻辑放到人身上就是“吃一堑长一智”。放到大模型应用里就是让 AI 每一次犯错都能留下痕迹并且在下一次犯同样错误之前被拦住。1.2 为什么落地在 Dify 而不是自己写代码我最早想自己写一套复盘服务代码结构大概是接消息队列、写会话存储、调 LLM、把结果存向量数据库、再写一个定时任务去捞数据。听上去不复杂但真做起来全是脏活。会话日志怎么结构化向量库怎么选型变量怎么在多次调用之间传递Webhook 怎么对接到现有机器人每一块都得写代码、测试、部署一个周末根本搞不完。后来我把视线转到 Dify理由很直接它把 LLM 应用开发里最常用的几个部件都做成了可视化节点而且支持工作流编排。你可以在一个画布上拖出“对话开始”“LLM”“知识检索”“变量赋值”“HTTP 请求”这些节点把复盘逻辑串起来。最关键的是Dify 自带知识库功能可以直接当作经验库用也支持会话变量能在多轮对话里临时保存结构化数据。这意味着我不需要额外搭一个 Redis 或者 MongoDB光靠 Dify 内置能力就能跑通最小闭环。我并不是说写代码方案不可行。如果团队有后端人力、需要高并发、要跟公司内部系统深度集成那自研是更稳的路。但如果你像我们一样只是想验证“AI 能不能通过复盘变聪明”Dify 是性价比最高的选择。它允许你先把逻辑跑通再决定要不要把某一段拆出来做成独立服务。hindsight 这个项目本质上就是一个跑在 Dify 上的“应用层记忆系统”它只需要依赖 LLM 和向量检索不需要碰业务系统底层。2. hindsight 的核心模块与数据设计2.1 三步走的处理链路采集、复盘、沉淀hindsight 整体分三段我把它们叫做采集器、复盘器、经验库。采集器负责在每一轮对话或任务结束时把关键的会话数据汇总成结构化文本。这里不是让你把用户说的每句话都原样存下来而是要有选择地提取。我会在 Dify 的工作流里先放一个 LLM 节点专门做“事件抽取”把“客户对价格有异议”“AI 提供了错误发票类型”“用户反复追问同一个问题”这类事件从原始对话里捞出来输出成 JSON。这样后面复盘器拿到的就是干净的数据而不是一堆噪声。复盘器是核心。它会读取采集器输出的 JSON再结合当前任务的目标做判断。比如客服场景里复盘器的 Prompt 会要求它评估三个维度用户意图是否被正确理解、AI 的回复是否直接解决了问题、整个流程有没有浪费轮次。复盘器输出的不是一句“这次还可以”而是一段结构化的复盘结论包含问题标签、原因分析、改进建议、可复用的经验话术。经验库就是 Dify 的知识库。复盘器生成的结论会通过“知识库写入”或者 HTTP 接口存进去。下次用户发起新对话时我在主流程里加一个知识检索节点先查一下历史复盘记录里有没有相似问题有的话就把对应经验作为上下文带给模型。这样 AI 就真的可以做到“不在同一个坑里跌倒两次”。2.2 会话变量与数据结构怎么定在 Dify 里搭 hindsight第一步不是画工作流而是把变量结构想清楚。变量没定义好后面所有节点都会卡壳。我用的主要变量有三个conversation_log数组类型保存这次会话里抽取出的关键事件。每个元素包含三个字段event_type事件类型、content事件内容、timestamp发生时间。decision_points数组类型保存 AI 在对话里做过的关键决策点。字段有question用户原话、ai_replyAI 当时的回复、result后续用户态度比如满意/继续追问/直接离开。lesson_output文本类型复盘器最后生成的格式化经验摘要。为什么用数组而不是把一堆东西拼成一个大字符串因为后面做知识检索和代码节点解析时数组可以直接被 LLM 和 Python 处理。字符串要反复切割很容易出错。Dify 的变量面板里直接支持数组类型配置成本很低。event_type 我规范成了四类requirement用户明确需求、objection用户对回复不满意或提出反对、correction用户纠正了 AI 的错误、positive_feedback用户明确表示认可。复盘器看到objection和correction会重点分析看到positive_feedback会把对应的回复方式记成“有效经验”。这个分类标准从一开始就要定好不然后面经验库里的内容会很乱。2.3 经验库为什么用知识库而不是普通数据库有人会问复盘结论存普通数据库里不行吗当然行但你需要自己写检索逻辑而且很难处理“语义相似”。比如今天有一条经验是“客户不接受自动续费需要先确认到期日期再推荐套餐”下次用户说“你们别自动扣钱”普通数据库按关键词匹配很难召回这条记录但向量检索能通过语义关联找到。Dify 的知识库天然支持向量检索你把复盘结论作为文档传进去系统会切块、向量化然后在工作流里用“知识检索”节点去查询。我在 hindsight 里把知识库的检索top_k设为 5score阈值设在 0.6 左右。太低会带进无关经验太高容易漏掉有用信息。这个参数需要根据你自己的对话数据慢慢调。还有一点很重要知识库里的经验要带“时效性”。一个月前的复盘经验可能已经不适用了所以我写入知识库时会在标题里加上日期范围并且在检索后用代码节点过滤掉超过 30 天太老的经验。Dify 知识库本身有元数据功能但我在初期为了省事直接把时间信息写在正文第一行效果也够用。3. 在 Dify 里搭建 hindsight 工作流3.1 完整流程编排从触发到写库hindsight 的工作流我分了两种触发方式。第一种是在原有的对话助手工作流后面串联一个“复盘子流程”对话结束或用户离开后自动触发。第二种是通过 API 接口触发适合用来处理历史会话日志——比如你手头有一批旧的客服聊天记录想让 hindsight 一次性把经验提取出来。整个流程的顺序是这样的接收会话数据。如果是实时对话从会话变量里取如果是历史日志通过 API 传入 JSON。调用 LLM 节点做事件抽取把原始对话转成结构化的conversation_log和decision_points。把抽取结果传给复盘 LLM 节点生成复盘结论。将复盘结论格式化成知识库文档格式写入 Dify 知识库。如果有需要通过 HTTP 节点把复盘报告推送到通知群。第 2 步和第 3 步我分开做了两个 LLM 节点而不是一个节点干完。原因是事件抽取和复盘反思对 Prompt 的要求完全不同。抽取节点需要严格的 JSON 输出不能有废话复盘节点需要更开放的推理空间。混在一起会让输出格式不稳定经常出现“该输出的没输出不该输出的编了一堆”。3.2 关键节点配置参数与提示词先看事件抽取节点。模型我用了我们公司日常用的主力模型比较便宜稳定参数设置如下temperature0.1。抽取任务不需要创造性越低越稳定。max_tokens500。一次抽取一般不会太长给太多反而容易让模型啰嗦。response_formatjson_object。Dify 的 LLM 节点支持指定 JSON 输出格式必须打开不然你会收到一大段带废话的文本。这个节点的 Prompt 我写得比较硬要求只输出 JSON不要任何解释你是会话事件抽取器。下面是一段用户与AI助手的对话记录。 你的任务 1. 识别对话中的关键事件包括用户需求、异议、纠正、正向反馈。 2. 识别AI关键决策点包括用户的原始问题、AI回复、用户后续反应。 输出格式要求 {events: [{event_type: requirement, content: 事件描述, timestamp: ...}], decisions: [{question: ..., ai_reply: ..., result: 满意/继续追问/离开}]} 只输出JSON不要输出任何解释或Markdown标记。复盘节点的配置则不一样。temperature我调到了 0.4因为复盘需要一点推理弹性完全粗暴的低温度会让模型只停留在“复述事实”而不会给出真正有洞察的分析。max_tokens设成 1000复盘结论通常需要比较长的输出。复盘 Prompt 我参考了很多反思类 Agent 的做法最终定成这个模板你是一个项目复盘专家。请根据以下会话事件和AI决策点回答四个问题 1. 这次交互的核心目标是否达成 2. AI在哪一步做得不够好根因是什么 3. 如果重来一次应该在哪个节点采取什么不同策略 4. 提炼一条可以复用的经验要求具体、可操作。 对话事件{{events}} 决策点{{decisions}} 输出格式 ## 结论 ## 问题分析 ## 改进建议 ## 可复用经验这个模板最大的好处是“可复用经验”被单独列为一段方便我直接写入知识库。前三个部分给人工复盘看第四部分给 AI 下次检索用。3.3 用代码节点做数据清洗Dify 工作流里的代码节点非常有用尤其是做数据清洗和格式转换。我在事件抽取节点后面加了一个 Python 代码节点干三件事把 LLM 输出的 JSON 字符串转成真正的数组对象、截断过长的字段、过滤掉明显无效的事件。这里给一个简化版的代码示例import json def main(input_data: dict) - dict: raw_text input_data.get(raw_events, []) try: data json.loads(raw_text) except json.JSONDecodeError: data {events: [], decisions: []} # 只保留有效事件类型 valid_types {requirement, objection, correction, positive_feedback} events [] for item in data.get(events, []): event_type item.get(event_type, ) if event_type not in valid_types: continue content item.get(content, )[:200] if not content: continue events.append({ event_type: event_type, content: content, timestamp: item.get(timestamp, ) }) # 截断AI回复防止上下文过长 decisions [] for item in data.get(decisions, []): decisions.append({ question: item.get(question, )[:100], ai_reply: item.get(ai_reply, )[:300], result: item.get(result, unknown) }) return {events: events, decisions: decisions}这段代码不复杂但能挡住很多坑。比如 LLM 偶尔会把 JSON 包在 Markdown 代码块里解析会报错再比如模型抽取出 50 条事件每条都超长不带入后续节点token 成本直接翻倍。代码节点就是做“防御性处理”的最好位置。3.4 定时复盘怎么实现实时对话里的复盘可以靠工作流触发但历史日志的复盘需要一个定时任务。Dify 本身没有内置 Cron 调度器我用的方案是写一个简单的 Python 脚本挂在服务器上每天凌晨调用 Dify 的 workflow 运行 API把前一天导出的对话日志传进去。大致逻辑像这样import requests import json url https://your-dify.example.com/v1/workflows/run headers { Authorization: Bearer YOUR_DIFY_API_KEY, Content-Type: application/json } payload { inputs: { raw_conversation: json.dumps(read_yesterday_logs()) }, response_mode: blocking } r requests.post(url, headersheaders, jsonpayload) print(r.json())这个方案只适用于每日复盘量不大、几秒钟能跑完的场景。如果你每天有几万条会话要复盘就得改成异步队列Dify 的streaming模式配合回调来拿结果。我在实际项目中一天大概几百条会话阻断式调用完全扛得住。4. 实际效果与问题排查实录4.1 一次真实复盘报告样例让我给你看一份脱敏后的复盘报告这是我们某次客服对话跑完后生成的## 结论 用户最终完成了订单修改但过程中出现了一次明显误导。 ## 问题分析 AI 在用户咨询“能不能改地址”时未主动提示地址修改仅在下单后 30 分钟内生效。用户在下单 2 小时后发起请求因此无法直接修改只能取消重下。AI 直接告知“可以修改”造成用户操作失败。 ## 改进建议 当用户提出修改类需求时先检查当前订单状态再判断是否支持修改。若超出时效需在首句给出明确拒绝原因并提供替代方案。 ## 可复用经验 用户提出任何修改诉求时先确认订单状态和时间窗口再给答复不要直接说“可以”要加上前置条件说明。这份报告直接进了知识库。下一次再有用户问“改地址”检索节点会把“可复用经验”这段捞出来主模型就会先问“您下单多久了”而不是直接说能改。这个改进是实打实的不是玄学。4.2 踩过的坑变量串场、知识库重复、模型乱总结开发过程中踩了挺多坑挑三个典型的分享。第一个坑是会话变量串场。Dify 里的会话变量按会话隔离听起来没问题但在一些并发场景下用户切换会话太快事件抽取节点读到的变量还是上一个会话的残留。后来我在工作流一开始就增加了一个“重置变量”的代码节点把数组清空再往下走。第二个坑是知识库重复写入。每次触发复盘都会向知识库写一条记录但如果同一个会话被重复触发比如 Webhook 重试知识库里就会出现一模一样的内容检索时权重被重复数据带偏。解决办法是在写入知识库之前先按会话 ID 去知识库里查一次如果已经存在就不写了。Dify 的 API 支持按元数据过滤我把会话 ID 写在了文档元数据里。第三个坑是复盘模型乱总结。刚开始我用高温参数跑复盘模型经常脑补出对话里根本不存在的“用户情绪”甚至生成一些错误的因果推断。后来我把复盘节点里的temperature调低到 0.4并且在 Prompt 里加了“只能基于给定事件分析禁止推测没有依据的事实”这句话情况好了很多。我把常见问题和解决方案整理成了一张表方便你参考问题现象根因解决办法事件抽取输出格式不稳定未开启 JSON 模式在 LLM 节点打开response_format为json_object知识库重复写入Webhook 重试导致流程重复执行写入前按会话 ID 去重复盘结论中出现虚构内容温度过高、Prompt 约束不足调低 temperature添加禁止推测指令检索不到历史经验经验库内容格式不统一统一知识库文档标题与正文结构长对话复盘 token 超限整段对话直接塞给 LLM先做事件抽取只让复盘节点看结构化事件4.3 调优复盘效果的三条经验除了修 bug我更想分享三条让 hindsight 真正好用的经验。第一只复盘最近 N 轮。一整段几个小时的对话塞给复盘节点不仅贵而且模型容易抓不住重点。我现在只在会话达到 10 轮或者用户明确表达不满意时才触发复盘且每次最多取最近 20 条事件。宁可多触发几次也不要让模型看超长文本。第二给经验分级。不是所有复盘内容都值得进入知识库。我给复盘节点加了一个“是否可复用”的判断字段只有correction和objection类事件对应的经验才写入日常正常对话的复盘直接丢弃。这样知识库里的内容质量会高很多检索也更准。第三人工抽检不能省。不要完全相信 AI 的复盘。我每周会抽查 10 条复盘记录看看哪些经验是真正有效的。如果发现某条经验不准确就手动删掉。这个习惯坚持几周后经验库的准确率有明显提高。另外我调参的时候还发现一个小技巧在 Dify 工作流里给复盘节点加一个“人工确认”输出变量值为auto或manual。如果后续想接入人工审核不用改整个流程只要在写入知识库前加一个判断manual就走待审核队列。这个设计一开始就做好后面能省很多事。最后分享一个我特别喜欢的小技巧。hindsight 的复盘结果不止可以存知识库还可以通过 Dify 的 HTTP 节点推送到企业的微信群机器人或飞书群。我每天设置早上 9 点推送一条“昨日经验汇总”我只要看一眼就知道前一天 AI 犯了哪些错、沉淀了几条新经验。这个习惯让我整个项目团队都对 AI 的“成长过程”有了感知大家也更愿意持续去调教它。如果你已经搭好了 hindsight建议一定试试这个推送动作效果比想象中好很多。
在Dify上搭建hindsight：为大模型应用装上复盘记忆系统
第一次听到 hindsight 这个词是在一次项目复盘会上。当时我们做的客服机器人总是重复同一个错误客户说发票抬头写错了下一次它还是会照旧填错。后来我在 Dify 上搭了一个叫 hindsight 的小工具专治这种“没记性”。简单说就是给 AI 应用装一个“后视镜”让它在跑完一次任务之后自动回头看看刚才哪里做得不好、哪里值得记下来然后把结论沉淀成经验下次遇到类似问题时直接拿出来用。这个工具解决的是大模型应用里最容易被忽略的问题没有记忆、没有反思、没有进步。它适合正在用 Dify 做 Agent、客服机器人、内容生成工具的人也适合那些已经跑通业务流但总觉得 AI“差点意思”的团队。hindsight 不改变你现有的对话逻辑只是在旁边加了一条复盘链路帮你把每一次交互变成下一次的养料。1. 项目为什么选 hindsight 这个方向1.1 不做复盘的大模型应用就是在裸奔用过 ChatGPT 或者各种大模型 API 的人都知道模型本身是没有状态的。你调用一次接口它给你一次输出它不会记得你上次问过什么更不会记得上次它自己答错了什么。很多团队在 Dify 上搭了客服、搭了文档助手跑起来一看功能是通的但用一个月就会发现AI 翻来覆去犯同样的错。我见过一个很典型的场景某项目的 AI 助手负责帮销售写报价单客户明确说过“我们公司不走增值税专用发票”但 AI 下一次还是按默认模板生成含税报价。不是模型不行是它根本不知道“上次那个客户说过什么”。这种问题靠加大模型本身解决不了你需要的是一个独立于对话流程之外的“事后复盘机制”——也就是 hindsight。hindsight 的核心思路很简单每次交互结束之后把这场对话里的关键信息、AI 的决策路径、客户反馈的结果都记录下来让一个专门的 LLM 节点负责做反思生成“这次哪里做对了、哪里做错了、下次应该怎么做”的经验摘要。然后这些摘要进入经验库在下一次对话开始时被检索出来作为参考上下文喂给主模型。这套逻辑放到人身上就是“吃一堑长一智”。放到大模型应用里就是让 AI 每一次犯错都能留下痕迹并且在下一次犯同样错误之前被拦住。1.2 为什么落地在 Dify 而不是自己写代码我最早想自己写一套复盘服务代码结构大概是接消息队列、写会话存储、调 LLM、把结果存向量数据库、再写一个定时任务去捞数据。听上去不复杂但真做起来全是脏活。会话日志怎么结构化向量库怎么选型变量怎么在多次调用之间传递Webhook 怎么对接到现有机器人每一块都得写代码、测试、部署一个周末根本搞不完。后来我把视线转到 Dify理由很直接它把 LLM 应用开发里最常用的几个部件都做成了可视化节点而且支持工作流编排。你可以在一个画布上拖出“对话开始”“LLM”“知识检索”“变量赋值”“HTTP 请求”这些节点把复盘逻辑串起来。最关键的是Dify 自带知识库功能可以直接当作经验库用也支持会话变量能在多轮对话里临时保存结构化数据。这意味着我不需要额外搭一个 Redis 或者 MongoDB光靠 Dify 内置能力就能跑通最小闭环。我并不是说写代码方案不可行。如果团队有后端人力、需要高并发、要跟公司内部系统深度集成那自研是更稳的路。但如果你像我们一样只是想验证“AI 能不能通过复盘变聪明”Dify 是性价比最高的选择。它允许你先把逻辑跑通再决定要不要把某一段拆出来做成独立服务。hindsight 这个项目本质上就是一个跑在 Dify 上的“应用层记忆系统”它只需要依赖 LLM 和向量检索不需要碰业务系统底层。2. hindsight 的核心模块与数据设计2.1 三步走的处理链路采集、复盘、沉淀hindsight 整体分三段我把它们叫做采集器、复盘器、经验库。采集器负责在每一轮对话或任务结束时把关键的会话数据汇总成结构化文本。这里不是让你把用户说的每句话都原样存下来而是要有选择地提取。我会在 Dify 的工作流里先放一个 LLM 节点专门做“事件抽取”把“客户对价格有异议”“AI 提供了错误发票类型”“用户反复追问同一个问题”这类事件从原始对话里捞出来输出成 JSON。这样后面复盘器拿到的就是干净的数据而不是一堆噪声。复盘器是核心。它会读取采集器输出的 JSON再结合当前任务的目标做判断。比如客服场景里复盘器的 Prompt 会要求它评估三个维度用户意图是否被正确理解、AI 的回复是否直接解决了问题、整个流程有没有浪费轮次。复盘器输出的不是一句“这次还可以”而是一段结构化的复盘结论包含问题标签、原因分析、改进建议、可复用的经验话术。经验库就是 Dify 的知识库。复盘器生成的结论会通过“知识库写入”或者 HTTP 接口存进去。下次用户发起新对话时我在主流程里加一个知识检索节点先查一下历史复盘记录里有没有相似问题有的话就把对应经验作为上下文带给模型。这样 AI 就真的可以做到“不在同一个坑里跌倒两次”。2.2 会话变量与数据结构怎么定在 Dify 里搭 hindsight第一步不是画工作流而是把变量结构想清楚。变量没定义好后面所有节点都会卡壳。我用的主要变量有三个conversation_log数组类型保存这次会话里抽取出的关键事件。每个元素包含三个字段event_type事件类型、content事件内容、timestamp发生时间。decision_points数组类型保存 AI 在对话里做过的关键决策点。字段有question用户原话、ai_replyAI 当时的回复、result后续用户态度比如满意/继续追问/直接离开。lesson_output文本类型复盘器最后生成的格式化经验摘要。为什么用数组而不是把一堆东西拼成一个大字符串因为后面做知识检索和代码节点解析时数组可以直接被 LLM 和 Python 处理。字符串要反复切割很容易出错。Dify 的变量面板里直接支持数组类型配置成本很低。event_type 我规范成了四类requirement用户明确需求、objection用户对回复不满意或提出反对、correction用户纠正了 AI 的错误、positive_feedback用户明确表示认可。复盘器看到objection和correction会重点分析看到positive_feedback会把对应的回复方式记成“有效经验”。这个分类标准从一开始就要定好不然后面经验库里的内容会很乱。2.3 经验库为什么用知识库而不是普通数据库有人会问复盘结论存普通数据库里不行吗当然行但你需要自己写检索逻辑而且很难处理“语义相似”。比如今天有一条经验是“客户不接受自动续费需要先确认到期日期再推荐套餐”下次用户说“你们别自动扣钱”普通数据库按关键词匹配很难召回这条记录但向量检索能通过语义关联找到。Dify 的知识库天然支持向量检索你把复盘结论作为文档传进去系统会切块、向量化然后在工作流里用“知识检索”节点去查询。我在 hindsight 里把知识库的检索top_k设为 5score阈值设在 0.6 左右。太低会带进无关经验太高容易漏掉有用信息。这个参数需要根据你自己的对话数据慢慢调。还有一点很重要知识库里的经验要带“时效性”。一个月前的复盘经验可能已经不适用了所以我写入知识库时会在标题里加上日期范围并且在检索后用代码节点过滤掉超过 30 天太老的经验。Dify 知识库本身有元数据功能但我在初期为了省事直接把时间信息写在正文第一行效果也够用。3. 在 Dify 里搭建 hindsight 工作流3.1 完整流程编排从触发到写库hindsight 的工作流我分了两种触发方式。第一种是在原有的对话助手工作流后面串联一个“复盘子流程”对话结束或用户离开后自动触发。第二种是通过 API 接口触发适合用来处理历史会话日志——比如你手头有一批旧的客服聊天记录想让 hindsight 一次性把经验提取出来。整个流程的顺序是这样的接收会话数据。如果是实时对话从会话变量里取如果是历史日志通过 API 传入 JSON。调用 LLM 节点做事件抽取把原始对话转成结构化的conversation_log和decision_points。把抽取结果传给复盘 LLM 节点生成复盘结论。将复盘结论格式化成知识库文档格式写入 Dify 知识库。如果有需要通过 HTTP 节点把复盘报告推送到通知群。第 2 步和第 3 步我分开做了两个 LLM 节点而不是一个节点干完。原因是事件抽取和复盘反思对 Prompt 的要求完全不同。抽取节点需要严格的 JSON 输出不能有废话复盘节点需要更开放的推理空间。混在一起会让输出格式不稳定经常出现“该输出的没输出不该输出的编了一堆”。3.2 关键节点配置参数与提示词先看事件抽取节点。模型我用了我们公司日常用的主力模型比较便宜稳定参数设置如下temperature0.1。抽取任务不需要创造性越低越稳定。max_tokens500。一次抽取一般不会太长给太多反而容易让模型啰嗦。response_formatjson_object。Dify 的 LLM 节点支持指定 JSON 输出格式必须打开不然你会收到一大段带废话的文本。这个节点的 Prompt 我写得比较硬要求只输出 JSON不要任何解释你是会话事件抽取器。下面是一段用户与AI助手的对话记录。 你的任务 1. 识别对话中的关键事件包括用户需求、异议、纠正、正向反馈。 2. 识别AI关键决策点包括用户的原始问题、AI回复、用户后续反应。 输出格式要求 {events: [{event_type: requirement, content: 事件描述, timestamp: ...}], decisions: [{question: ..., ai_reply: ..., result: 满意/继续追问/离开}]} 只输出JSON不要输出任何解释或Markdown标记。复盘节点的配置则不一样。temperature我调到了 0.4因为复盘需要一点推理弹性完全粗暴的低温度会让模型只停留在“复述事实”而不会给出真正有洞察的分析。max_tokens设成 1000复盘结论通常需要比较长的输出。复盘 Prompt 我参考了很多反思类 Agent 的做法最终定成这个模板你是一个项目复盘专家。请根据以下会话事件和AI决策点回答四个问题 1. 这次交互的核心目标是否达成 2. AI在哪一步做得不够好根因是什么 3. 如果重来一次应该在哪个节点采取什么不同策略 4. 提炼一条可以复用的经验要求具体、可操作。 对话事件{{events}} 决策点{{decisions}} 输出格式 ## 结论 ## 问题分析 ## 改进建议 ## 可复用经验这个模板最大的好处是“可复用经验”被单独列为一段方便我直接写入知识库。前三个部分给人工复盘看第四部分给 AI 下次检索用。3.3 用代码节点做数据清洗Dify 工作流里的代码节点非常有用尤其是做数据清洗和格式转换。我在事件抽取节点后面加了一个 Python 代码节点干三件事把 LLM 输出的 JSON 字符串转成真正的数组对象、截断过长的字段、过滤掉明显无效的事件。这里给一个简化版的代码示例import json def main(input_data: dict) - dict: raw_text input_data.get(raw_events, []) try: data json.loads(raw_text) except json.JSONDecodeError: data {events: [], decisions: []} # 只保留有效事件类型 valid_types {requirement, objection, correction, positive_feedback} events [] for item in data.get(events, []): event_type item.get(event_type, ) if event_type not in valid_types: continue content item.get(content, )[:200] if not content: continue events.append({ event_type: event_type, content: content, timestamp: item.get(timestamp, ) }) # 截断AI回复防止上下文过长 decisions [] for item in data.get(decisions, []): decisions.append({ question: item.get(question, )[:100], ai_reply: item.get(ai_reply, )[:300], result: item.get(result, unknown) }) return {events: events, decisions: decisions}这段代码不复杂但能挡住很多坑。比如 LLM 偶尔会把 JSON 包在 Markdown 代码块里解析会报错再比如模型抽取出 50 条事件每条都超长不带入后续节点token 成本直接翻倍。代码节点就是做“防御性处理”的最好位置。3.4 定时复盘怎么实现实时对话里的复盘可以靠工作流触发但历史日志的复盘需要一个定时任务。Dify 本身没有内置 Cron 调度器我用的方案是写一个简单的 Python 脚本挂在服务器上每天凌晨调用 Dify 的 workflow 运行 API把前一天导出的对话日志传进去。大致逻辑像这样import requests import json url https://your-dify.example.com/v1/workflows/run headers { Authorization: Bearer YOUR_DIFY_API_KEY, Content-Type: application/json } payload { inputs: { raw_conversation: json.dumps(read_yesterday_logs()) }, response_mode: blocking } r requests.post(url, headersheaders, jsonpayload) print(r.json())这个方案只适用于每日复盘量不大、几秒钟能跑完的场景。如果你每天有几万条会话要复盘就得改成异步队列Dify 的streaming模式配合回调来拿结果。我在实际项目中一天大概几百条会话阻断式调用完全扛得住。4. 实际效果与问题排查实录4.1 一次真实复盘报告样例让我给你看一份脱敏后的复盘报告这是我们某次客服对话跑完后生成的## 结论 用户最终完成了订单修改但过程中出现了一次明显误导。 ## 问题分析 AI 在用户咨询“能不能改地址”时未主动提示地址修改仅在下单后 30 分钟内生效。用户在下单 2 小时后发起请求因此无法直接修改只能取消重下。AI 直接告知“可以修改”造成用户操作失败。 ## 改进建议 当用户提出修改类需求时先检查当前订单状态再判断是否支持修改。若超出时效需在首句给出明确拒绝原因并提供替代方案。 ## 可复用经验 用户提出任何修改诉求时先确认订单状态和时间窗口再给答复不要直接说“可以”要加上前置条件说明。这份报告直接进了知识库。下一次再有用户问“改地址”检索节点会把“可复用经验”这段捞出来主模型就会先问“您下单多久了”而不是直接说能改。这个改进是实打实的不是玄学。4.2 踩过的坑变量串场、知识库重复、模型乱总结开发过程中踩了挺多坑挑三个典型的分享。第一个坑是会话变量串场。Dify 里的会话变量按会话隔离听起来没问题但在一些并发场景下用户切换会话太快事件抽取节点读到的变量还是上一个会话的残留。后来我在工作流一开始就增加了一个“重置变量”的代码节点把数组清空再往下走。第二个坑是知识库重复写入。每次触发复盘都会向知识库写一条记录但如果同一个会话被重复触发比如 Webhook 重试知识库里就会出现一模一样的内容检索时权重被重复数据带偏。解决办法是在写入知识库之前先按会话 ID 去知识库里查一次如果已经存在就不写了。Dify 的 API 支持按元数据过滤我把会话 ID 写在了文档元数据里。第三个坑是复盘模型乱总结。刚开始我用高温参数跑复盘模型经常脑补出对话里根本不存在的“用户情绪”甚至生成一些错误的因果推断。后来我把复盘节点里的temperature调低到 0.4并且在 Prompt 里加了“只能基于给定事件分析禁止推测没有依据的事实”这句话情况好了很多。我把常见问题和解决方案整理成了一张表方便你参考问题现象根因解决办法事件抽取输出格式不稳定未开启 JSON 模式在 LLM 节点打开response_format为json_object知识库重复写入Webhook 重试导致流程重复执行写入前按会话 ID 去重复盘结论中出现虚构内容温度过高、Prompt 约束不足调低 temperature添加禁止推测指令检索不到历史经验经验库内容格式不统一统一知识库文档标题与正文结构长对话复盘 token 超限整段对话直接塞给 LLM先做事件抽取只让复盘节点看结构化事件4.3 调优复盘效果的三条经验除了修 bug我更想分享三条让 hindsight 真正好用的经验。第一只复盘最近 N 轮。一整段几个小时的对话塞给复盘节点不仅贵而且模型容易抓不住重点。我现在只在会话达到 10 轮或者用户明确表达不满意时才触发复盘且每次最多取最近 20 条事件。宁可多触发几次也不要让模型看超长文本。第二给经验分级。不是所有复盘内容都值得进入知识库。我给复盘节点加了一个“是否可复用”的判断字段只有correction和objection类事件对应的经验才写入日常正常对话的复盘直接丢弃。这样知识库里的内容质量会高很多检索也更准。第三人工抽检不能省。不要完全相信 AI 的复盘。我每周会抽查 10 条复盘记录看看哪些经验是真正有效的。如果发现某条经验不准确就手动删掉。这个习惯坚持几周后经验库的准确率有明显提高。另外我调参的时候还发现一个小技巧在 Dify 工作流里给复盘节点加一个“人工确认”输出变量值为auto或manual。如果后续想接入人工审核不用改整个流程只要在写入知识库前加一个判断manual就走待审核队列。这个设计一开始就做好后面能省很多事。最后分享一个我特别喜欢的小技巧。hindsight 的复盘结果不止可以存知识库还可以通过 Dify 的 HTTP 节点推送到企业的微信群机器人或飞书群。我每天设置早上 9 点推送一条“昨日经验汇总”我只要看一眼就知道前一天 AI 犯了哪些错、沉淀了几条新经验。这个习惯让我整个项目团队都对 AI 的“成长过程”有了感知大家也更愿意持续去调教它。如果你已经搭好了 hindsight建议一定试试这个推送动作效果比想象中好很多。
