过了一个漫长的春节，我想聊聊我春节里的一些感受，关于 ai，关于 vibe coding，关于我们这份工作还能干多久。
"我们是怎么一步步走到分手的？"
我把这句话喂给了市面上大多数的 RAG 方案【lixxtRag，nanoRag..】，没有一个能答出来。换个问题——"我们去年七月聊了什么？"它们都能答。但只要问题稍微涉及状态变化、关系走向、叙事脉络，全部哑火。 原因很简单：传统 RAG 的底层假设是"问题可以被一段文字回答"。它按 token 切块，向量召回，Re-rank，找出最相关的几段文本——这套路子处理文档很好用，但遇上微信聊天记录这种数据就抓瞎了。因为"我们感情是怎么走到现在的"这个问题，答案不在任何一段聊天里，它藏在几十次对话的时序变化之间。
所以春节我花三天做了 narrarc，我的灵感其实来自 Page Index 这类非传统 RAG：不硬切 chunk，而是按文档本来的结构（目录、章节）喂给大模型。但通用非结构化文档太难搞了，于是我把场景收敛到聊天记录，因为它有天然的时间戳和对话边界，是完美的半结构化文本。一个专门针对聊天记录的 Agentic RAG，不切 chunk，不做向量暴力召回，而是把每段对话理解成有状态的叙事节点，再用 LangGraph 驱动 Agent 去"读故事"而不是"找段落"。
今天也不只是来安利这个项目——更想聊聊当下是怎么用一套完整的 AI 工具链（从调研、Plan、OpenSpec 到 Agent Team），把这个相对复杂的 Agentic RAG 项目落地的。
本文涉及的工具：Cursor · Kimi Agent · Manus · Google AI Studio · Google Colab · OpenSpec · Claude Code · Lovart · Typeless
一、Before Everything：用 agent 探路
从一个idea到开启新项目最忌讳上来就打开 IDE 哐哐写。我的第一步永远是调研。
对于 narrarc，我要解决的核心问题是：既然传统 RAG 的“一锤子买卖”不行，那肯定得上 Agentic RAG。但具体怎么实现？有没有别人造好的轮子？
这时候我通常不用 Cursor，而是用 Kimi Agent 或者 Manus ，Google Gemini Deep Search。【顺带一提，虽然manus被广泛吐槽是套壳产品，但就我个人体验而言，在这三个产品内是最佳体验。】
为什么？因为它们有更大的权限，能主动调浏览器去广撒网，且过程可视化、能随时打断。
我一般让它们帮我干两件事：
这里大概就是我让调研agent干的事情🥹
- 看有没有现成轮子：搜一下 GitHub 上有没有人做过基于时间序列的聊天记录 RAG。确认没有完全符合的，我再动手。
- 拿可选方案：帮我搜罗一些 Agentic RAG 的框架对比，以及相关的评测数据集，例如这里我的项目非常需要两人长时间对话的数据集，于是manus就帮我选择了数据集 GitHub - danny911kr/REALTALK: Evaluate your agent memory on real-world dialogues, not LLM-simulated dialogues.
这步做完，把调研到的前期资料建个文件夹存好，作为后续的弹药库。
你甚至可以把manus当成一个集成vercel和cursor的工具，例如这样做!
二、Desgining with AI：Claude Code Plan 模式
调研完了，接下来是盘逻辑。对于 narrarc，我需要设计一套能支持多轮探索的查询机制。
在这个阶段，我强推 Claude Code 的 Plan 模式。把前期的调研资料喂给它，通过不断地对话，把脑子里的想法固化成具体的架构/产品设计。
Plan 模式有个坑要提前填：它给出的 Option 往往是少部分的，大部分还是交由claudecode设计，就可能出现plan和预期不匹配的情况。比如它会说"用 30 分钟聚合 Burst"，但不会告诉你 Burst 的数据结构长什么样；会说"提取 7 维元数据"，但不会列出每一维的公式和阈值。我的做法是：在 Plan 推演阶段，一旦敲定某个 Option，就当场追问并固化这些细节，否则后续 OpenSpec 生成时模型会自己脑补，容易跑偏。
通过 Plan 模式的推演，我最终敲定了 narrarc 的核心底座：双层索引 + 基于 LangGraph 的 Agentic RAG 工作流。
构建侧：
- Burst：按 30 分钟时间窗聚合消息，输出
(start_local_id, end_local_id, start_time, end_time)等字段。 - TopicNode：每个 Burst 经 LLM 分类为 1~N 个话题节点，结构为
(topic_name, start_local_id, end_local_id, start_time, end_time)。 - 7 维元数据：
reply_delay_avg/max_s（回复延迟）、term_shift_score（称呼变化）、silence_event（超 3× 中位间隔的沉默）、topic_frequency（话题历史出现次数）、initiator_ratio（用户发起比例）、emotional_tone（-11）、1）。AnomalyAnchor 的判定：信号值超过 μ+2σ 即标为异常锚点。conflict_intensity（0 - SemanticThreadPointer：ChromaDB 向量召回 → Cross-encoder Reranker 重排 → CoT LLM 语义仲裁，建立节点间的语义线程。
查询侧：planner 解析意图 → retriever 查锚点与线程 → grader 评估是否充足 → 不足则 explorer 扩展 → generator 生成叙事弧并附证据。
这样一来，数据就不再是碎片的，而是一张带有时间顺序和语义关联的网。
三、Departing Huge Plan：OpenSpec 拆解
有了宏大的 Plan，怎么落地？
直接让 Claude Code 的 Sonnet/Opus 去 Apply Plan？我是真的不推荐这么做，只要项目稍微复杂点，模型大概率会跑偏或者改崩你的旧代码。为了避免上述的情况这里我选择引入openspec的工具，而且这里还有一个隐藏的好处，对于多ai coding tool的同学来说，不用费劲的给每个coding agent写prompt解释进度了，openspec的task文档天生就把这部分活揽过去了
我的 Best Practice 是：用 OpenSpec 新建 Change。
把 Plan 拆解成一个个 Change，在 OpenSpec 里：
- 先确认整体大纲。
- 列出本次改造的子系统要求。
- 最关键的一步：强制设定校验条件（必须通过哪些测试或脚本）。
比如在实现 narrarc 的查询管道时，我用 OpenSpec 要求模型实现一套基于 LangGraph 的图结构。只要是 Kimi 2.5 或以上级别的模型，有了 Spec 约束后的代码转换非常稳健。
拆解 narrarc 的 Agentic Workflow
这也是 narrarc 最核心的部分。当我们查询“我们是怎么分手的”时，底层的 Workflow 是这么流转的：
- planner (意图解析)：LLM 先判断你想问什么，生成 1-3 个维度的语义查询。
- retriever (召回)：根据意图，去查上面建好的“异常锚点”和“语义线程”，捞出一批候选节点。
- grader (评估)：这一步是 Agentic 的灵魂。Agent 会自己评估：“现有的这些聊天节点，够不够回答这个问题？”
- explorer (探索)：如果 grader 觉得不够（比如只找到了吵架的高潮，没找到起因），流转到 explorer，顺着时间线和语义线程继续往下挖，再把新线索丢回给 grader 评估。
- generator (生成)：信息收集充足后，生成分段的叙事弧，并且把原始聊天记录作为证据 (Evidence) 附上。
这就是 Agentic 思想：把单次检索变成了“检索 ⇄ 评估 ⇄ 扩展”的循环。
四、Right way to Coding ：Agent Team 与它的正确打开方式
在落地上述这套复杂的 Agent Workflow 时，我重度使用了 Claude Code 里的 Agent Team 机制。
这里有必要澄清一个概念：很多人的认知还停留在 Sub Agent。
- Sub Agent 主打隔绝：主上下文怕爆炸，就把一个脏活累活丢给子代理，子代理干完只扔回来一个 Summary。
- Agent Team 主打协作：它是一群 Agent 的团队。比如 A 发现了一个线索，可以把状态和信息同步给团队里的 B，大家共享上下文来完成一个大目标。
但注意避坑：
- 极度烧 Token：状态共享意味着上下文指数级膨胀，短平快的 Bug 修复、单函数修改，千万别开 Agent Team。这里是glm5模型agent-team狂奔十二小时的花费😶
- 适用场景：目前这功能还没完全发布，偶尔不太理想。我把它用在刀刃上：一是探索新项目（摸清代码库的脉络），二是做 Long-term 的迭代（比如我用来跑自动化优化任务，在上述提到的数据集上划分测试集和训练集，不断微调 narrarc 里 LangGraph 的 retriever 召回参数和 grader 阈值，让它自己寻找最优解）。
五、外围工具
除了核心后端，项目还有个 Tauri 的客户端界面，以及一系列边角料。为了追求效率，我分享这些工具：
- Google Gemini Studio (搭前端)：Gemini 3.1 Pro 在前端视觉上的表现是目前的 SOTA，Taste实在是太棒了。我会让它先生成我满意的网页原型，把代码下载下来，再无缝迁移到 React + Tauri 客户端里。速度比用 Cursor 从头敲快太多了。【这里是我用google studio五分钟 创建一个我的世界demo的例子】
- Lovart(搓 Logo)：我先用懂审美的模型结合项目痛点生成一段极佳的 Prompt，然后丢进 Lovart。虽然它底层还是即梦或 banana的模型，但它做了层约束，出来的 Logo 质感非常好。
- Typeless (语音输入)：人在构思复杂逻辑时，打字速度往往跟不上脑子。Typeless 自带语义去重和口语化消除不是单纯的asr，我经常通过它把一连串的构思直接口述，丢给大模型去提炼。但是定价有点贵，第一个月使用有免费的pro可以使用～（大家可以找国产平替如闪电说），但确实能减少 input 成本。Typeless会整理我混乱的口喷思绪，然后输出结构化的实施改进方案，我连打字都不用打。
我要做的事情就是，躺在椅子上，看看前端页面，看看后端代码逻辑，然后打开麦克风一顿胡言乱语，“给我加个预览分页功能”，“前端给我用 xx 框架”，跟它确认完方案后，等它跑完，这十分钟里我可以一边玩手机一边玩狗，然后顺便盯着它干活，不要出大岔子。
原来做产品高 P的感觉这么爽，家人们。
但现在我觉得AI 无法理解我们的业务，很有可能是我们的文档规范做的不够好，据我了解，一些开源公司的AI coding已经发展到可以自己领 issue 完成，人工 review 了，这里最大的差距就是开源项目的全部文档都是统一维护，但我们业务代码的复杂度是散落在不同的语雀文档，不同的钉钉群聊，不同的配置后台，不同的语音文字聊天里....
- Keep following，keep moving：业界每天都会提出新的范式和名词，然后公众号就在那里推“震撼！”“颠覆！”“SOTA！”，作为从业者的我们活在这种繁杂狂野的背景音中，难免有一种被时代抛下的焦虑，我想说的是，动手试一试吧，接受一下最新的workflow，在最初的震撼和焦虑之外，我相信你会发现 ai 的边界和能力，发现新时代下新角色的乐趣。
结语
从大年初一冒出一个想法，到把 narrarc 这个用 LangGraph 驱动的 Agentic RAG 跑通，最大的感受是：AI 工具不是单纯的代码补全补丁，它是一整套工程方法论。
都看到这了，给 narrarc 来个star吧 🙏，非常欢迎分享你的最佳实践和任何对于项目/文章的意见。
