基于Dify和RAG构建智能复盘Agent：从设计到实践

去年年底我开始折腾一个叫“hindsight”的个人项目，起因很朴素：我的团队每个月做项目复盘，但每次复盘会都开得像追悼会——大家凭记忆你一言我一语，最后纪要写了一大堆，下次该踩的坑一个没少踩。我觉得这事不对，复盘的意义在于“后见之明”，但大多数人根本没把“后见之明”变成“可复用的经验”。后来我在 Dify 平台上把这个想法落地成了一个 AI Agent，专门做结构化的复盘反思、失败归因和经验沉淀。这篇文章就把这个项目的完整设计思路、实现过程、踩坑记录全部拆开揉碎了讲清楚，适合正在做 Agent 应用、知识库 RAG、或者对 AI 辅助团队协作感兴趣的朋友参考。

先啰嗦一句背景，为什么这事儿值得做。当时我面临三个痛点：第一，复盘材料散落在飞书文档、聊天记录、项目周报里，想查一个历史决策的上下文，翻半天都翻不全；第二，复盘输出全靠个人自觉，写得好不好、全不全面看心情，缺乏统一的结构化模板；第三，复盘结果和实际执行脱节，总结完就完了，没有形成可检索、可关联、可复用的知识资产。所以我在想，能不能用大模型 + 知识库做一个智能复盘助手，让它接手“整理历史信息、关联相似经验、输出结构化复盘、给出改进措施”这套流程。这就是“hindsight”项目的起点。

1. 项目整体设计与思路拆解

1.1 “hindsight”到底是什么

从定位上看，“hindsight”是一个基于大语言模型和 RAG 检索增强生成的知识型 Agent，跑在 Dify 平台上。它的核心功能是：你给一段项目原始记录（比如一段会议纪要、几行失败经过、一个事故报告），它会先检索你沉淀好的私有知识库，把历史上类似的项目、相近的问题、之前总结过的经验捞出来，然后按照一套固定的复盘框架生成结构化输出——“目标是什么、实际结果是怎样、偏差在哪里、根因是什么、下次要怎么改”。

为什么叫“hindsight”？因为这个词的本义就是“事后洞察”。我们做复盘本质上就是在用事后视角重新解读当时的信息和决策，而大模型最擅长的恰恰就是“给一段混乱的信息，让它按某种逻辑重述”。但是单纯用大模型做这件事有一个致命缺陷：它只能靠训练时的通用知识来发挥，不了解你团队的具体语境，也不知道你上个季度踩过的那个坑的细节。所以必须把 RAG 加上——让 Agent 在生成之前，先从你自建的知识库中检索相关历史经验，作为上下文注入。这一下就把一个“泛泛而谈的 AI 顾问”变成“懂你们团队历史的 AI 复盘助手”。

从适用场景来说，这个项目可以服务三类需求：个人知识管理场景，比如整理自己的周记、日记、失败笔记，让 AI 帮你找出反复出现的思维盲区；团队协作场景，比如复盘会议前置准备，让 AI 先把历史资料梳理好，会上直接聚焦讨论；内容创作场景，比如写经验分享文章时，让 AI 帮你从历年材料中提取有共鸣的案例。我目前深耕的是第二种场景，但设计架构时考虑了通用性。

1.2 为什么选 Dify 而不是自己搭应用

选型这件事我犹豫了挺久。最初想的是直接调 OpenAI API + LangChain 自己写一套，但评估完工作量之后放弃了。因为我需要的不是一个技术 Demo，而是一个团队里非技术人员也能上手维护的长期工具。自研框架意味着要有人一直维护、要处理数据库、要写管理后台、要管模型密钥——这些都是隐形成本。

Dify 打动我的点在于它把“应用编排、知识库管理、模型管理、日志追踪”都集成好了。尤其是可视化的工作流编排，我可以把“检索历史 → 生成复盘 → 结构化输出 → 提取待办”这些节点拖拽连接起来，改逻辑不需要重新部署，直接在画布上调整即可。这对一个以内容沉淀为目标的项目来说是压倒性的优势。

另一个考虑是数据隐私和部署形态。Dify 是开源的，可以社区版自托管部署到内网，我们的项目资料、复盘记录不会经过第三方平台，这对企业内部敏感信息来说非常重要。而且 Dify 的知识库支持多种向量检索方案，包括内置的向量数据库，也支持接入外部向量库如 Weaviate、Qdrant，扩展空间很大。

当然 Dify 也不是没有缺点，后面我会专门讲几个实际踩到的坑，但整体上，选它作为落地平台是性价比最高的方案。

1.3 整体架构与核心链路

整个项目的架构可以拆分五个核心组件，链路是“输入 → 预处理 → 检索 → 生成 → 落库”。

第一环是输入源管理。我接入了两种输入方式：手动输入（直接在对话窗口粘贴项目复盘素材）和文件上传（支持 Markdown、TXT、PDF 格式的过程文档）。第二种方式主要给团队里习惯写长文档的同事用。

第二环是知识库构建。我用 Dify 的知识库模块建了三个独立的库：历史项目复盘库（存放过去所有项目的复盘记录）、最佳实践库（存放团队总结出的做事方法论）、行业资料库（存放外部收集的相关案例）。三个库分开建的原因后续细讲，现在先记住这个划分。

第三环是 Agent 工作流。这是整个应用的“大脑”，包含“意图识别 → 知识检索 → 生成反思 → 输出结构化报告 → 提取后续动作”五个节点。这里需要说明的是，Dify 的工作流分两种模式：简单编排（适合直接问答）和高级编排（支持多节点串联），我这个项目用的是高级编排。

第四环是模型层。我同时配置了多个模型：快速响应模型（用于意图识别和轻量处理）、深度推理模型（用于根因分析和反思生成）。用不同模型跑不同节点的原因是成本和响应速度的权衡，后面我会给出实测对比数据。

第五环是输出和复盘报告落库。Agent 生成的复盘报告通过 HTTP 请求节点写入我部署的 PostgreSQL 数据库，同时生成一份 Markdown 文件归档到网盘目录，方便团队成员随时查阅。

整个链路设计思路的核心有两条：一，知识库与生成模型解耦，保证任何一次生成都有可追溯的资料支撑；二，流程节点可插拔，未来想加入“情绪分析”“风险预测”等功能，直接在画布里加节点就行，不用动底层代码。

2. 核心细节解析与实操要点

2.1 复盘提示词：决定输出质量的命门

这个项目最核心的“软细节”就是提示词设计。我试过很多版本，踩过不少坑，最后沉淀下来一套还算稳定的复盘提示词框架，分享出来供参考。

先看我的核心 System Prompt：

你是一名资深的项目复盘顾问，擅长用“目标—结果—偏差—归因—改进”五段式框架分析项目执行过程。 你的任务是基于用户输入的原始项目资料，结合知识库检索到的历史经验，输出一份高质量的复盘报告。 要求如下： 1. 先复述原始输入中的核心目标和关键事件，确保信息理解准确； 2. 对比实际结果与原始目标，找出关键偏差点； 3. 对每个偏差点进行根因分析，从“流程设计、执行能力、外部依赖、信息判断”四个维度排查； 4. 归因必须区分“可控因素”和“不可控因素”，可控因素给出具体改进措施，不可控因素给出应对预案； 5. 检索知识库中与此项目相似的历史案例，用“此前遇到过类似问题，当时的处理方式是……”的格式关联引用； 6. 输出必须严谨客观，避免责任归咎和个人情绪； 7. 最终输出一份结构化报告，包含以下部分： - 项目摘要 - 目标回顾 - 结果与偏差分析 - 根因分析 - 历史经验关联 - 改进措施（按优先级排序） - 待办事项列表

这个提示词经历了三个迭代版本。第一版太笼统，只说“请帮我复盘以下项目”，结果输出大量正确的废话，比如“建议加强团队沟通”这种没有执行力的内容。第二版引入了“可控/不可控”分析维度，质量明显改善，但历史经验关联做得很差，因为当时知识库还没接通。第三版加上了检索指令和四维度归因框架，才达到现在这个效果。

一个重要心得：提示词里每一条指令都要对应一个“可验证的输出”。比如“从流程设计、执行能力、外部依赖、信息判断四个维度排查”，这就是强制 Agent 在每个偏差点都输出四个子项，你一眼就能看出它有没有在糊弄。“历史经验关联”这条指令也同理，如果你没有给它明确的知识库检索入口，它要么编造案例，要么说“知识库中没有相关内容”——实际测试中，加了明确的检索指令后，相关内容关联率从 22% 提升到了 76%。

2.2 知识库构建：历史经验的质量比数量重要

知识库是“hindsight”的另一个支柱，但很多人会把知识库当成垃圾桶，什么都往里扔，结果检索出来的内容杂音极大，反而拉低了生成质量。

我最终用的是三分库策略，每个库独立管理、独立设置检索参数。

第一个库叫“历史复盘库”，存放的是历次项目复盘的结构化报告。这类文档的格式相对统一，所以我把分段长度设为 500 字，重叠区设为 50 字，检索权重侧重“语义相似度”。这个库解决的核心问题是“我们以前有没有遇到过类似的问题，当时是怎么处理的”。

第二个库叫“最佳实践库”，存放的是团队归纳的方法论、操作手册、流程规范，比如《需求评审检查清单》《事故应急流程 V2》这类文档。这类文档的价值在于事前的预防，所以分段长度设为 300 字，重叠区设为 30 字，保证每条知识的粒度足够细、便于精确匹配。

第三个库叫“行业案例库”，存放外部资料，比如行业报告、论文摘录、优秀团队的公开复盘文章等。这些资料往往篇幅长、信息密度大，分段长度我用的是 800 字，重叠区 100 字，检索权重偏“全文关键词匹配”。

知识库构建中有一个特别容易忽视的细节：你要给每个知识库设置不同的索引权重和检索阈值。Dify 默认的相似度阈值是 0.2，这个值太低了，会导致很多语义上沾边但实际不相关的段落被捞出来当作“经验依据”，生成报告时就会出现“牛头不对马嘴”的引用。我实测后把历史复盘库的阈值设为 0.42，最佳实践库设为 0.50，行业案例库设为 0.36，效果改善非常明显。

另一个细节是文档预处理。我最初直接把原始周报扔进知识库，结果因为格式混乱、含大量表格和图片链接，解析质量很差。后来我写了一个简单的预处理脚本，把所有文档统一转成 Markdown 格式，删除无关的表格样式和链接，只保留正文文本，再按章节结构拆分上传。处理后检索准确率有了质的提升。

2.3 Agent 工作流编排：每一环都要有容错设计

Dify 的高级编排工作流可以看作一个可视化管道，你需要设计每一个节点以及它们之间的连线。我的工作流分为七个节点：

第一是“输入节点”，接收用户的原始素材。这里需要注意的是，用户输入的内容可能很长，超出模型上下文限制，所以我加了一个判空逻辑——如果输入为空或者少于 20 个字，直接提示用户补充信息，不走后续流程。

第二是“意图识别节点”，用快速模型判断用户输入属于“复盘请求”“资料补充”“查询历史”还是“闲聊”。这个节点看起来简单，但价值很大，它避免了用户不小心发一句“好的”就触发整套复盘流程，白白消耗一次生成的费用和时间。

第三是“知识检索节点”，这是整个链路的枢纽。它同时查询三个知识库，并对每个库设置不同的 topK 值。历史复盘库我设为 4，最佳实践库设为 3，行业案例库设为 2。检索结果会在后续节点里以“[引用资料]”的格式注入提示词上下文。

第四是“生成复盘节点”，使用深度推理模型。这里有一个关键设计：该节点的输入不仅包含用户原始素材和知识库检索结果，还包含了“意图识别节点”输出的意图类型，不同类型调用不同的复盘模板。如果意图是“项目复盘”，用五段式完整框架；如果是“事故分析”，则调整为“时间线还原 + 直接原因 + 根本原因 + 应急措施 + 长期对策”的模板。

第五是“结构化提取节点”，用来从生成内容中提取待办事项、责任人和优先级。这个我用的是函数调用方式，让模型返回 JSON 格式的待办列表。

第六是“落库节点”，通过 HTTP 请求把复盘报告和待办列表写入外部数据库。

第七是“输出节点”，把最终报告推给用户，同时附带一个下载链接。

整个工作流的容错设计有两个要点。第一，每个节点都加了错误处理分支，比如知识检索节点超时或返回空结果时，会走“无检索结果提示语”分支，而不是直接报错中断。第二，深度推理模型偶尔会出现输出格式不合规的情况，导致结构化提取节点失败，我为此增加了一个重新生成逻辑——如果提取结果校验失败，自动回退到“直接透传原文”模式，保证用户至少能看到完整报告，不会白等。

3. 实操过程与核心环节实现

3.1 从零搭建 hindsight Agent 的具体步骤

接下来是最干的干货部分。如果你也想复刻一个类似的 Agent，可以直接照着下面的步骤走。我以 Dify 社区版 Docker 部署为例，整个过程大约需要两三个小时。

第一步是部署 Dify 平台。官方仓库提供了 docker-compose.yml，直接拉代码后在项目根目录执行：

git clone https://github.com/langgenius/dify.git cd dify docker compose up -d

启动完成后浏览器访问 http://localhost/install 配置管理员账号。这里要注意的是，Dify 依赖多个组件同时启动，首次启动可能需要等待 2-3 分钟，如果某个容器启动失败，可以通过docker compose logs查看具体日志。我踩过的一个坑是服务器内存不足——Dify 全家桶跑起来要占差不多 4GB 内存，如果你用的是 2GB 的小机器，需要提前加 swap 或者在配置中裁剪掉不必要的组件。

第二步是添加模型供应商。我主要用的是 OpenAI 的 GPT-4o 和 GPT-4o mini 各一个。在 Dify “设置 → 模型供应商”中填入 API Key，然后在“模型”页面分别配置：

• 深度推理模型：gpt-4o， temperature 设为 0.2，这是为了减少生成的随机性，保证复盘报告的稳定性；
• 快速响应模型：gpt-4o-mini， temperature 设为 0.1，用于意图识别和轻量处理。

如果你有开源模型部署需求，Dify 也支持接入 Ollama、Xinference 等本地推理服务，不过对生成质量要求较高的场景，商业模型依然是首选。后面我会给出一组实测对比数据，说明模型选型对输出质量的影响有多大。

第三步是创建知识库。在 Dify “知识库”模块新建三个库，分别命名为“历史复盘库”“最佳实践库”“行业案例库”，上传对应文档。上传时注意选择分块模式为“自定义分段”，并按照我前面提到的参数进行设置——历史复盘库 500 字/50 字重叠，最佳实践库 300 字/30 字重叠，行业案例库 800 字/100 字重叠。上传完成后，先运行一次“召回测试”，在知识库的检索测试界面输入几个历史项目的关键词，检查返回的段落是否与预期相关。这个环节非常建议做，因为你后续 Agent 生成质量，完全取决于这一步效果。我最初上传文档后没测试，结果生成报告引用了完全不相关的段落，排查了好久才发现是分段参数设置不合理。

第四步是创建工作流。在 Dify“工作室”中新建“Chatflow”类型应用，从模板左侧拖出各个节点，按我前面提到的七节点链路进行连接。对于只熟悉低代码操作的人来说，这个环节可能需要一些时间适应，但 Dify 的画布交互做得比较直观，拖拽、连线、配置参数三步即可完成一个节点。配置“生成复盘节点”的提示词时，用我前面贴的 System Prompt 模板即可，需要微调的话建议保留“四维度归因”和“历史经验关联”两条核心指令。

第五步是配置外部数据库和落库逻辑。如果你不需要把复盘结果持久化，这一步可以跳过。如果需要，可以通过 Website API 或自定义工具节点实现。我这里用的是 Dify 的“HTTP 请求”节点，目标地址是我部署的一个小型 Node.js 接口，接收 JSON 格式的复盘报告和待办列表，写入 PostgreSQL 数据库。

第六步是发布与测试。工作流配置完成后，先发布为“草稿”状态，用几组真实项目资料做端到端测试。建议准备至少三组测试数据：一组是成功项目，一组是失败项目，一组是信息不全的短文本，分别验证 Agent 在不同输入下的表现。发布正式版本后，可以在 Dify 的“访问 API”页面获得 API 密钥，接入你的内部系统或聊天工具。

3.2 关键配置参数速查表

我把整个项目中最关键的参数汇总成一个速查表，方便你对照检查：

值得强调的是，这些参数不是拍脑袋定的，而是基于我测试集上的对比实验调出来的。比如相似度阈值，我先用一套标注过的“相关/不相关”问答对，在 0.2 到 0.6 之间按 0.02 的步长扫描，选择 F1 分数最高的点。这个方法可以复现，建议你在自己的语料上也跑一遍，不要直接照搬我的值——因为不同领域文档的语义分布差异很大，阈值选择高度依赖语料特征。

3.3 一次完整的复盘流程演示

为了让你更直观地理解整个系统，我用一个脱敏后的真实项目记录做一次完整演示。

假设原始输入材料是一段 500 字的项目记录，内容大致是：“智能客服项目原定 5 月底上线，但实际推迟到 7 月 15 日才发布。推迟的主要原因是语音识别模块供应商接口变更，导致联调工作比预期复杂；期间客服部门多次催促，研发资源出现争抢；最终上线后首月满意度达标，但转人工率比预期高出 8 个百分点。”

用户把这端文本粘贴到对话框，点击发送。Agent 的处理过程如下：

第一步，意图识别节点用 gpt-4o-mini 快速判断这是“项目复盘”请求，置信度 98%。

第二步，知识检索节点并行查询三个库。历史复盘库返回三个历史项目：一个是去年 4 月上线的电商推荐项目，遇到过类似的第三方接口变更问题；一个是前年的语音机器人项目，有转人工率异常的详细分析；还有一个是今年初的支付项目，没有明显相关性，但相似度勉强超过阈值。最佳实践库返回两条资料，包括《三方服务接口变更应对流程》和《客服指标异常排查手册》。行业案例库返回一篇关于客服系统容灾设计的公开文章片段，相关性一般。

第三步，生成复盘节点接到检索结果后，按照提示词中的五段式框架输出一份完整报告。报告中“历史经验关联”部分明确写道：“此项目中语音模块接口变更导致的联调延误，与历史项目‘电商推荐项目’中第三方推荐引擎接口下线问题高度相似。当时团队的处理方式是提前两周启动替代方案评估，并建立了供应商直接对接通道，最终将影响时间压缩在 5 个工作日内。本轮建议参考此经验，在下一次项目排期预研阶段加入供应商接口变更风险清单。”

第四步，结构化提取节点从报告中提取待办事项：“在项目预研阶段建立第三方接口变更风险清单，责任人：架构组小李，优先级：高；建立客服转人工率异常预警机制，责任人：产品组小王，优先级：中。”

整个过程大约耗时 18 秒。用户收到的是一份层次清晰的复盘报告，而不是一大段混沌的文字。实测中，这版报告团队成员普遍认为“够专业，可以直接用”，这正是我设计这个项目时最想达到的效果。

4. 常见问题与排查技巧实录

4.1 知识库检索质量差：八成是分段和阈值的问题

上线初期我最头疼的问题就是“检索召回了一堆不相关内容”。当时检查的方向有三个：是不是文档本身格式太乱？是不是分段参数不合理？是不是相似度阈值太低？

首先自查文档格式。我把原始文档打开看了一遍，发现很多是从 Notion 导出的 HTML 格式，里面夹杂着大量空行、图片标签和导航菜单文字。Dify 的解析器虽然能识别 HTML，但对导航信息和正文不加区分地全部收录了。解决方案是写脚本统一转 Markdown，把无关内容剔除后在整体上传。

接着排查分段参数。我用的是 Dify 内置的分段方式，默认是“自动分段”，它会把文章按段落拆分成不定长的小块。这个模式在信息密度较低的对话类文档上效果可以，但对技术文档类的内容不适用——很多技术文档的关键信息都集中在一两个长段里，自动分段经常把它们拆得七零八落，检索时只命中其中一部分，导致上下文不完整。改成按固定长度分段并设置合适重叠区之后，检索完整性明显提升。

最后调整相似度阈值。Dify 的检索结果会给出每条结果的相似度分数，我跑了一遍测试集，发现大量不相关的段落分数集中在 0.2-0.35 之间，而真正相关的段落普遍在 0.4 以上。于是我把各库的阈值分别上调到 0.36-0.5 之间，无效召回率从 41% 降到 12%。需要注意的是，阈值太高也会误伤正确结果，需要在精确率和召回率之间做平衡。

4.2 Agent 输出经常“自由发挥”，不按模板走

这个问题在接入知识库之后出现过一段时间的“复发”。现象是：明明 System Prompt 里要求按固定框架输出，但偶尔几份报告会漏掉某一节，或者把所有内容都压缩成一大段。

排查后定位到两个原因。第一，用户的输入很长时，模型可能被原始素材中的叙述逻辑带跑偏，尤其是当输入材料本身就有极强的叙事性时，模型会倾向于模仿这种风格而不是执行 System Prompt 里的结构化指令。解决方案是把结构化要求从 System Prompt 中搬到用户输入前的额外处理中，用模板化的前缀提示强化约束，比如在用户输入前加一句“请严格按照以下章节输出：项目摘要 / 目标回顾 / 结果与偏差分析 / 根因分析 / 历史经验关联 / 改进措施 / 待办事项”。

第二，部分模型对指令中的“输出必须采用 Markdown 格式，用二级标题分隔各章节”理解得不够稳定。后来我改为不强依赖模型自觉，而是在生成后加一个结构化提取节点，用函数调用方式让模型返回 JSON 格式的数据，再由前端渲染成固定模板。这个方法生效后，输出格式的稳定性基本达到了 95% 以上。

4.3 模型选型与成本控制的实测对比

最后排一下模型选择的实测数据。我在同样的提示词和知识库设置下，用 GPT-4o、GPT-4o mini、以及一个开源模型（安装的是 Qwen2-72B 的量化版）各跑了 20 组测试数据。

从生成质量上看，GPT-4o 的结构化程度最高，几乎每个测试样本都能输出严格的五段式框架，且归因分析具体有依据，很少出现空话套话；GPT-4o mini 能完成基本的框架，但深度不足，根因分析部分经常是比较浅显的“沟通不好”“进度管理不到位”这类描述；开源模型则发挥极不稳定，有些输出效果接近 GPT-4o，有些则在逻辑性和关联性上掉线。

从成本上看，GPT-4o 大约是 GPT-4o mini 的 15 倍左右，对个人项目来说压力较大。所以我做了一个折中方案：日常的意图识别和轻量处理全部用 mini，只把耗时的“生成复盘报告”环节用 GPT-4o。这样整体成本降低了 60% 左右，而关键输出质量没有明显下降。

还有一个省钱技巧是我后来才发现的：对知识库检索结果做“相关性预筛”，在生成环节之前把不相关的检索段落剔除掉。这个直接减少了大模型处理的 token 数量，因为生成节点的输入中，检索到的相关段落往往占了 70% 以上的 token 开销。我现在让检索节点先返回每个库的 top 10 结果，再用一个快速模型做二次过滤，只保留 top N 条最高质量的，再送入生成环节。

4.4 易被忽视的日常维护细节：会话记忆与知识库增量更新

这个项目跑通后，我日常维护发现两个细节非常影响长期使用体验。

第一个是会话记忆管理。Dify 默认会把前几轮对话作为上下文传给模型，这在连续补充资料时很好用——用户先发一段项目记录，Agent 生成了报告初稿，用户接着补充一条背景信息，Agent 能在原报告基础之上更新而不是重新生成。但副作用是，如果对话轮次多了，上下文占用膨胀。我建议给“生成复盘节点”明确设置上下文轮数，Dify 中可以配置最多携带几轮对话历史。对于复盘这类长文本生成任务，我会限制只把用户输入和系统提示作为上下文，避免历史对话干扰生成质量。

第二个是知识库增量维护。复盘最关键的价值在“复用”，如果你的知识库一直不更新，Agent 总是引用半年前的旧经验，价值会逐日递减。我养成了一个固定习惯：每次复盘报告生成后，经过人工确认没有问题，就把它加入历史复盘库。这个动作可以用 Dify 的 API 接口自动化完成，报告落库的同时自动写入知识库。另外还要定期清理知识库里的失效内容，比如某些过时的流程文档，如果不清理，检索结果就会拿过时的经验指导新的项目，造成反向误导。

写在最后的个人体会

我在实际使用中发现，“hindsight”这个项目真正解决的并不是“生成一篇复盘报告”这个问题本身。报告只是表象，它背后代表的是一种把“事后经验”转变为“事前能力”的机制。以前我们复盘靠的是老员工个人记忆，人走了经验就带走了；现在经验沉淀在知识库里，任何人面对新项目时都能先问一句“之前有没有遇到过类似的”。这种改变带来的红利是长期的，它的价值会随着知识库的积累越来越大。

还有一个体会是，任何 AI 产品，前期最大的投入一定不是写代码、调模型，而是梳理业务逻辑。我花了两三天时间做提示词和流程设计，但知识库的整理和清洗花了两周。别嫌这个过程繁琐，AI 的能力上限往往不在模型，而在你喂给它的信息的质量——垃圾进，垃圾出。

如果你也想搞一个类似的 Agent 项目，我的建议是把验收标准定得具体一点。不要只满足于“输出看起来不错”，而是要问“这份报告能直接指导动作吗”，“待办事项能分给具体的人吗”，“下次遇到类似问题能搜得到这条经验吗”。三个问题都能答“是”，这才算是一个真正能落地的“后见之明”项目。