1. 项目概述Hindsight 到底是做什么的直接说结论Hindsight 是我用 Dify 工作流搭建的一套“多智能体事后复盘分析系统”。名字取的是英文里“后见之明”的意思——事后看一件事总觉得结论清晰、因果分明但事情正在发生的时候大多数人都处于信息过载的状态。这套系统的核心目标就是把“事后才看得出来的规律”通过 AI 主动挖出来让你对那些已经发生的对话记录、项目日志、会议纪要产生真正有价值的复盘而不是翻一遍就归档吃灰。我在最开始构思这个项目的时候脑子里只有一个很模糊的场景每周项目复盘会上大家都要花半小时回忆“这周到底发生了什么”然后各自凭印象说几句最后写出来的复盘报告千篇一律。真正的问题在于所有的事实都在聊天记录、工单系统、会议录音转写稿里躺着但没有人有精力把它们逐条重新读一遍。Hindsight 要解决的就是把这个“重新读一遍”的过程交给多个 AI Agent 并行完成让它们在旧材料里找出被忽略的偏差、风险、模式和盲区。这套东西适合谁用三类人我觉得最有价值一是需要每周做项目复盘的技术负责人二是需要从客服对话里挖用户真实诉求的产品经理三是对 Dify 低代码平台有兴趣、想看看多 Agent 编排到底能玩出什么花样的开发者。不管你属于哪一类只要手上有历史文本数据就能在半天内照着本文把它跑起来。2. 核心架构与方案选型2.1 为什么选 Dify 而不自己写代码刚开始我其实是想用 LangChain 直接写一个 Python 服务的。但真正动手以后我发现大部分时间不是在写业务逻辑而是在处理“怎么把三个 Agent 串起来”“怎么管理每个 Agent 的输出”“怎么调试某一个节点的输入输出格式”这些都是非常重复且容易出错的工程工作。后来换成 Dify整个开发节奏完全不一样了——节点拖拽连接变量名自己起中间结果随时可以预览调试一个工作流就像在拼乐高而不是在修水管。更重要的是Dify 自带的提示词编排页面可以直接针对不同 Agent 写独立的 System Prompt还能为每个节点单独选择不同的模型。这意味着我可以让“事实提取者”用一个响应速度快的轻量模型让“模式发现者”用一个推理能力更强的旗舰模型而不是全程被一个模型的性能拖住。这种“按需分配模型”的能力自己写代码要额外做一层路由逻辑在 Dify 里是开箱即用的。还有一个现实原因Dify 支持私有化部署也支持通过 API 对接各种国产模型服务。这一点对我来说非常关键。很多企业数据不适合丢到海外大模型服务里Dify 配置本地模型或国内合规模型服务的路径很顺畅这样整套复盘系统可以直接部署在客户内网环境。对于一个偏“企业知识管理”方向的项目来说数据链路是否干净往往直接决定了这个项目能不能落地。2.2 多智能体协作的设计思路Hindsight 的核心并不复杂你可以把它理解成一个 AI 版的分析师团队。团队里一共有四个角色每个角色分工不同读同一份材料但产出完全不同的结论。第一个角色是“事实提取者”。它负责把原始材料里的客观信息一条一条摘出来包括时间、人物、金额、决策点、交付物、责任人。这个角色不需要判断好坏只需要“照着原文摘录”所以它的核心要求是忠实度而不是创造力。第二个角色是“模式发现者”。它拿到事实提取者输出的结构化清单以后开始寻找隐藏的规律——哪些类型的工单总是在周五下午出现哪个环节的平均处理时长在悄悄变长哪类需求在最近三周反复被不同客户提到。这个角色需要强推理能力和横向联想能力是整个系统里最“聪明”的一环。第三个角色是“质疑者”。这个角色是我后来才加的但却是整个系统里最有价值的设计。它负责挨个审查模式发现者提出的假设看每一条结论是否有原文依据是否存在逻辑跳跃是否有替代解释。为什么要加这个角色因为大模型在自由分析的时候很容易一本正经地胡说八道尤其是面对开放性任务时它倾向于编造看起来很合理但实际上没有依据的结论。质疑者的存在相当于给前面的分析装了一道质检阀门。第四个角色是“总结者”。它把前三者的输出融合成一份结构化的复盘报告包括事实摘要、发现的风险点、值得关注的趋势以及下一步行动建议。报告不是一堆散点而是一个能直接贴进周报的完整文档。这四个角色在 Dify 工作流里的执行顺序很讲究事实提取和模式发现可以先并行质疑者必须等前两者输出以后才能启动总结者放在最后。这种依赖关系如果自己写代码要用异步任务队列来处理但在 Dify 里就是节点之间的连线关系而已。2.3 备选方案对比LangChain / Coze / Dify在正式定下 Dify 之前我并行评估过另外两条路线。简单做一个对比方便你根据自己的情况选维度DifyLangChainCoze开发上手速度快拖拽式编排慢需要写大量代码快但平台绑定较强私有化部署支持 Docker 部署需要自建全套环境不支持本地部署模型调度灵活性每个节点可独立选模型最灵活有约束国内版模型有限调试与可观测性节点级输入输出可视化需要自己搭日志调试方便但闭环程度一般适合场景企业内部工具、中小团队深度定制的研究者快速 Demo、公开应用我自己最后的选择是 Dify。LangChain 的灵活性的确最强但对于一个“希望能长期维护、能被团队里不懂代码的人改配置”的项目来说Dify 这种可视化维护方式的优势太明显了。Coze 我试用过一段产品交互做得确实流畅但私有化部署这一条满足不了我这边客户的数据出境和合规问题直接一票否决。3. 工作流搭建实操节点级配置与参数说明3.1 前提准备部署 Dify 社区版Hindsight 是基于 Dify 社区版搭建的部署方式非常常规需要一台 Linux 服务器安装了 Docker 和 Docker Compose。Dify 官方仓库拉下来以后直接进入 docker 目录执行docker compose up -d就能启动整套服务包括 API 服务、Web 前端、PostgreSQL、Redis、向量数据库等一组容器。我建议服务器配置不低于 4 核 8G因为 Dify 全家桶本身就占内存后面还要在容器里对接外部模型 API。如果只是本地跑着玩2 核 4G 也能跑但加载知识库和跑长文本分析的时候会明显感觉卡。部署完以后访问服务器的 IP 加端口就是控制台第一步先注册管理员账号然后进入「工作流」页面创建新应用这一步没什么需要特别注意的。接入大模型有两种方式。一种是 Dify 自带的模型供应商列表里选择服务商并填入 API Key比如硅基流动、阿里云百炼、智谱 AI 等国内服务商都在列表里。另一种是通过 Ollama 接入本地开源模型适合想在完全离线环境里跑通整套流程的场景。我自己在开发阶段用的是云端 API 组合部署到客户环境时换成内网的私有模型网关整体切换过程就是改一个模型供应商配置Dify 这一点做得确实省心。3.2 全局变量与开始节点配置创建好空白工作流以后第一步是配置「开始节点」。这个节点决定了用户调用工作流时需要传入什么参数。Hindsight 只需要两个入参raw_text必填字符串类型用户粘贴或上传的原始文本内容。analysis_depth选填枚举类型可选quick或deep默认是quick。analysis_depth这个变量是我后期加的。因为不是每一次分析都需要让四个角色全部跑一遍。日常快速复盘只需要事实提取加总结者就能产出可用的摘要模式发现和质疑者适合周期性深度复盘时再开启。用条件分支控制流程可以省掉不少 API 成本。开始节点之后我加了一个「文本处理」节点作用是做基础的文本清洗去掉多余的空行和重复空格把全角字符统一转半角顺便对超长文本做截断。Dify 内置的文本处理节点提供了常用的 JINJA2 模板语法你可以直接用{{ raw_text | truncate(8000) }}这样的表达式把超长文本处理到一个可接受的 Token 范围内。3.3 三个 Agent 节点的提示词设计接下来是核心部分三个 LLM 节点的提示词。我直接把我在生产环境里跑得很稳的版本放出来你可以在此基础上改。事实提取者节点系统提示词 你是一名严格的事实提取员。你将收到一份原始材料。你的任务是提取所有客观事实只包括时间、人物、组织、金额、数量、决策、交付物、异常事件。每条事实必须能在原文中找到对应表述不得推理、不得归纳、不得下结论。如果原文信息不完整标注“未明确”。 输出格式Markdown 表格 | 编号 | 类别 | 事实内容 | 原文依据 | | 1 | 时间 | 3月12日 | 原文第一段 |模式发现者节点系统提示词 你是一名资深商业分析师。你将收到一份事实清单。你的任务是 1. 发现事实之间的相关性指出哪些事件经常同时出现或先后出现 2. 识别趋势判断哪些指标在上升或下降 3. 找异常点指出哪些事实不符合整体模式 4. 最多输出5条关键发现每条必须引用事实清单中的编号作为证据 5. 禁止输出没有证据支撑的推测。 输出格式 - 发现一[结论]依据事实#2、事实#7 - 发现二[结论]依据事实#5质疑者节点系统提示词 你是一名持怀疑态度的评审专家。你将收到一份事实清单和一份分析结论清单。你的任务是 1. 逐条检查每条结论是否有充分的事实支撑 2. 指出逻辑谬误、过度推断、以偏概全的地方 3. 对每一条结论给出“支持”、“部分支持”、“证据不足”的判定 4. 如果证据不足给出一个合理的替代解释。 输出格式 - 结论一判定部分支持 - 理由虽然事实#3和事实#7显示相关性但样本量不足无法排除随机波动。 - 替代解释...这三个节点的模型选择上事实提取者我用的是响应快的轻量模型模式发现者用推理能力强的旗舰模型质疑者用中等规模的模型即可。你也可以理解为“花小钱办细活花大钱办难活花中钱办把关活”。3.4 条件分支与汇总节点的连接逻辑三个 Agent 节点做完以后需要把它们连接成能跑通的完整流程。流程是这样的开始节点 - 文本清洗 - 条件分支分析深度判断 - 如果 analysis_depth quick - 直接运行事实提取者 - 总结者 - 结束 - 如果 analysis_depth deep - 并行运行事实提取者、模式发现者 - 都完成后再运行质疑者 - 最后运行总结者 - 结束Dify 的「并行执行节点」可以做这一步。我原本以为并行会带来很多复杂的并发逻辑实际上 Dify 已经把并行节点的输入输出都管理好了它们会分别读取开始节点传入的变量然后在各自的节点内部完成运行。模式发现者需要读取事实提取者的输出二者有依赖关系所以不能直接并行。我的做法是先用并行节点同时发起“事实提取者”和“初步模式发现者”其中“模式发现者”实际上读取的是文本清洗后的原始文本而不是事实清单。这样虽然模式发现者少了结构化事实输入的辅助但可以在后期用汇总节点把事实清单合入再让质疑者交叉验证。如果你的分析目标更看重事实链条也可以改成串行事实提取完成后把结果作为模式发现者的上下文变量传入这样分析质量更稳但耗时更长。调试的时候Dify 的节点详情面板非常有用。你可以在每次运行后点开任意一个节点看到那一刻的输入输出 JSON。我强烈建议你在配完所有节点以后先用一段几百字的测试文本跑一遍逐个节点点开检查输出确保前一个节点的输出变量名跟下一个节点的输入变量名完全对上。这个习惯能帮你省掉后面至少两个小时的排查时间。4. 核心细节解析与实操要点4.1 长文本的切片与 Token 开销控制复盘分析面对的真实材料往往很长。比如一个月的客服对话记录可能有几十万字一个季度的项目日志整理出来也是动辄十几万字。直接把全部文本塞进上下文任何一个模型都会超限即使不超限API 花费也会让你心疼。我采用的策略是把长文本按语义切片分批送入事实提取者。切片的方式很简单粗暴按固定 Token 数分割文本我一般设置 2000 Token 一段段落之间保留 200 Token 的重叠区域防止语义在切割处断裂。Dify 的文本处理节点支持自定义 JINJA2 模板你可以写一个简单的循环把长文本拆成数组然后再用并行节点分别处理每个切片。这个方案看起来简单但有一个隐藏问题多切片并行处理后怎么把分散的事实清单汇总成一份全局清单我的做法是在汇总节点里系统提示词中写清楚你是一名档案管理员。请将以下几份事实清单合并为一份去重后的事实清单。注意 1. 相同事件只保留一条 2. 保留详细信息最完整的那条 3. 不同切片的信息可以互为补充合并时尽量合并同类项 4. 保留每条事实的原文依据字段。实际上跑下来模型对多个切片的聚合效果是稳定的不太会有信息丢失。依赖关系清晰以后整个工作流跑完一次深度复盘的时间也能控制在 2 分钟以内这还是在三个角色顺序执行的情况下。4.2 提示词中的角色隔离与格式约束我在调试过程中踩过最大的坑是不同 Agent 的输出格式互相污染。举个例子模式发现者输出的是分析结论列表但偶尔会在末尾带一段总结性的话。总结者拿到这份输出作为输入时会把那段总结当成正文的一部分最终生成的报告里出现“重复总结导致内容糅杂”的现象。这个问题在 Dify 工作流里尤其容易出现因为你把“一个模型的输出”直接作为“另一个模型的输入”格式上的偶然偏差会被放大。后面我用两种手段解决一是强制每个 Agent 输出严格的结构化格式凡是符合格式以外的内容在提示词里明确要求“不要输出任何其他文字”。二是在两个节点之间加一个「参数提取器」节点把前一个节点的输出重新解析为指定的字段。Dify 的参数提取器本质上是使用模型按 JSON Schema 解析输入所以只要提示词里定义了清晰的字段名模型就会乖乖把内容映射到 JSON 字段里。后续节点读取时只需要取某个字段的值而不是直接吞掉整段文本。这个“角色隔离 参数提取”的组合是我认为 Hindsight 项目里最值得借鉴的工程经验。它解决的不是某一个模型的能力问题而是多 Agent 协作时的结构化通信问题。4.3 分析的深度与成本平衡前面提到analysis_depth参数我用它来控制执行哪些节点。这里有一个非常现实的成本逻辑事实提取者消耗的 Token 数跟输入文本长度成正比这是基础开销不管你怎么优化都躲不掉模式发现者和质疑者消耗的 Token 数则取决于事实清单的长度以及模型生成的输出长度这一部分相对可控。我实测过一组数据输入 8000 字的项目周报quick 模式跑一遍大约消耗 2 万 Token成本几乎可以忽略deep 模式跑一遍大约消耗 6 万到 8 万 Token如果使用旗舰级模型会是一笔可感知的开销。所以我的建议是日常例行复盘用 quick 模式关键节点季度复盘、年度总结、重大项目收尾用 deep 模式。没必要每次分析都上全套豪华阵容。另外还有一个性价比很高的技巧模式发现者用的模型可以不用最新最强的那一档。因为模式发现者做的事情是“搜索相关性”它对逻辑深度的要求没有质疑者那么高但对信息覆盖面的要求高。选一个上下文窗口大、价格适中的模型反而比一味追求“聪明”更划算。质疑者才是真正需要强推理能力的角色因为它的任务不是发现而是击穿。5. 常见问题与排查技巧实录5.1 某个 Agent 输出为空或报错这是我最常遇到的运行异常。正常排查路径是先点开出错节点的运行日志看上游节点的输出是否正常传入。绝大多数情况下问题出在变量名不匹配。Dify 工作流中的每个节点输出都会自动生成一个变量名如果你在下一个节点的提示词里手动拼写变量名拼错一个字符运行时就会取到空值。我的建议是所有跨节点的变量引用都不要手动打字。在 Dify 的提示词编辑器里直接点右侧的“引用变量”按钮插入变量系统会自动插入正确的变量名及引用语法。这个习惯能直接消除一半以上的运行失败问题。5.2 分析结果存在幻觉和编造再好的提示词约束也无法完全阻止大模型编造事实。特别是在事实提取者面对模糊的表达时模型总会倾向于“脑补”细节。模块里加入质疑者最早就是为了对抗这种方法论层面的风险。但在实操中质疑者也不是万能的——它可能对一条原本有依据的结论过度质疑把正常的判断也推翻。我提供了两个补充手段一是在提示词中要求模型对任何关键结论标注“原文依据”后续人工检查时可以直接对照二是准备一个可选的“交叉验证”节点直接从原始材料中抽取与某个结论相关的上下文片段再让模型判断结论与上下文的吻合度。这个节点不是每次运行都开启只在报告最终被用于正式决策时手动触发一次。5.3 API 超时与重试如果使用外部大模型 API工作流运行过程中偶尔会出现超时。Dify 在模型供应商配置中提供了超时时间和重试次数的参数我通常把超时设置为 120 秒重试次数设置为 2 次。即使这样配置长文本并发场景下仍可能有一两个节点卡住。遇到这种情况我一般直接重新运行一次工作流因为 Dify 的每个节点都是幂等的重跑不会产生副作用成本也就多一次 API 调用。5.4 同一份材料跑两次结果不一致怎么办大模型天然具有随机性尤其在分析类任务中哪怕采样温度设置为 0不同次数的运行结果仍会有细微差异。如果你的场景需要可复现的结果建议在所有生成节点中把 Temperature 设置为 0并把 Top P 设置为 1这样能最大限度压缩随机性。不过我要说句实话对于复盘类任务结果有细微差异并不是问题。Hindsight 的价值在于“提供可讨论的分析角度”而不是“给出唯一的标准答案”。你真正要关注的是每个角色之间的逻辑一致性而不是字面的一致性。6. 扩展方向与个人体会Hindsight 跑通以后我最大的感受是这个项目天然的扩展空间比我想象中大得多。它目前只吃“文本”这一种输入但业务世界里更多的是图片、音频、视频。Dify 已经支持文件解析和音视频转写接入理论上可以把会议视频流、纸质文档扫描件全部吸收进来形成统一的知识输入层。另外如果给这个工作流加一个知识库检索节点就能对“公司历史复盘”的结论做二次检索让每一次新分析都站在历史分析的肩膀上而不是每次都从零开始。这个演进方向的价值比单纯把提示词调得更好要重要得多。回到项目本身我想掏心窝子说一句Hindsight 本质上是一个“结构化归纳”工具它不负责替你思考它负责让思考建立在对所有事实的完整回顾之上。我在使用过程中发现最消耗精力的不是配置工作流而是设计“质疑者”的角色定位——因为你要让它既大胆又克制既敢质疑又有所依据这本身就是对人判断力的一种延伸。如果你也想搭一套类似的东西我的建议是从最小闭环开始一个事实提取者加一个总结者先跑一周再根据输出的质量逐步把模式发现者和质疑者加进来。边跑边调才是这类项目最稳妥的生长方式。