受到 scrapy 框架启发，本系列要实现一个异步高并发的爬虫框架，记录一下手写的过程，在 AI 横行的时代，停下来审视自己架构、高并发的基本功，我觉得是挺有意

还记得上一篇文章—手写调度器，我们提到的“检查点恢复”吗？ 遗留了一个小问题：无法从中断的具体 Agent/具体 phase 精确继续，是按照固定的流程继续

众所周知目前多 agent 架构下，如何组织、调度各个 agent是个基础工作，业界常见的做法是使用 langgraph 直接做调度，但是我们的客户希望更加精细的展示，每个阶段的调度过程和结果，而 langgraph 只能做到某个阶段完成后才会展示结果，所以我决定自己手写一个调度器，来实现更精细的调度过程展示。

现在 agent 开发形势，就和当初前端从蛮荒时代进入到vue/react/solid框架时代一样，花式复杂啊，尤其是拆分成多个 agent 后，调度管理就变得复杂起来。

多Agent核心问题不是调用多个 Agent，而是管理一个长期、可中断、可恢复、可分支的工作流。

先回忆一下上一篇讲分词架构，留了一个小尾巴，ES 字段咋设计，因为这个设计原则确实影响了我们如何设计分词，所以本文就记录一下我们RAG 项目里 ES 字段的设计思路，抛砖引玉一下😯

没有测试数据的性能优化就是放屁。靠脑补做的优化99%都是无效的。 这是我们开会时，大领导们的评价。我觉得说的没毛病🥹 最终沉淀的评估系统是：后端