Step01
第一步做的事情，先把 Python 版 OnCall 的后端外壳搭起来。也就是说，先验证了一件最关键的事：这个项目能不能先以 Python 服务的形式真正跑起来，并且具备最基础的对外通信能力。只有这一步成立，后面接模型、接 RAG、接工具调用才有意义。
从工程角度看，完成的是一个最小可运行骨架。创建了基础目录，明确了入口文件、路由文件、请求响应结构和 SSE 工具函数这些最核心的位置。这一步的价值不在于功能多，而在于它把项目从"想法"变成了"有结构的代码工程"，后面继续扩展时就不会一开始全堆在一个文件里。
在服务层面，把 FastAPI 服务真正启动起来了，并且有了 main.py 作为统一入口。这说明 Python 版 OnCall 已经不再停留在方案阶段，而是有了一个可以启动、可以监听端口、可以对外提供接口的实际运行体。
在接口层面，固定了两个最重要的入口，一个是普通的 /api/chat，一个是流式输出的 /api/chat_stream。这一步非常关键，因为它相当于先把未来系统最核心的对外协议钉住了。后面不管你内部是 mock、是真实模型、还是再加上 RAG 和工具，前端调用方式都可以尽量保持不变，这样整个迁移过程会稳定很多。
在功能层面，虽然现在还没有接入真实模型，但已经让 /api/chat 能正常接收请求并返回一段 mock 内容了。这说明请求解析、参数校验、路由分发和 JSON 响应这一整条基础链路是通的。换句话说，已经证明前端发一个聊天请求，Python 后端能接住并给出结构化结果这件事是成立的。
更重要的是， /api/chat_stream 做通了，也就是把 SSE 流式输出先跑起来了。这一步对 OnCall 这种项目尤其关键，因为后面无论是模型逐 token 输出，还是工具调用过程中的中间状态返回，都很可能依赖流式机制。现在先把 start、token、done 这种基本事件流走通，相当于把后面最容易出问题的一层提前验证掉了。
最后，通过实际请求验证了当前这套最小骨架是有效的。也就是说，/health、/api/chat 和 /api/chat_stream 都已经不是理论存在，而是已经经过真实测试、能够返回结果的接口。这代表第一步已经形成了一个完整闭环：服务能启动，请求能进来，结果能出去，流式输出也能工作。
所以如果把第一步浓缩成一句话来说，那就是：已经从零搭出了 Python 版 OnCall 的最小后端运行底座，并验证了普通 HTTP 和 SSE 两条最基础的通信链路都能正常工作。这一步虽然还没有真正实现 AI 能力，但它已经把后面所有开发要依赖的地基先打稳了。
Step02
第二步做的事情，核心不是新增更多接口，而是把第一步那个能跑的 demo 外壳，进一步整理成一个有分层的后端结构。如果说第一步解决的是Python 服务能不能启动、接口能不能通，那么第二步解决的就是代码以后还能不能继续扩展，而不至于越来越乱。
第二步最重要的变化，是把原来直接写在路由里的 mock 聊天逻辑抽离出来，放进一个单独的 ChatService 里。这样一来，路由层就不再负责具体怎么生成回复，而只负责接收请求、调用服务、返回结果。这个拆分的意义非常大，因为后面你要接真实模型、接 RAG、接工具调用，其实都应该发生在 service 层，而不是堆在 API 路由函数里。
除了 ChatService，第二步还引入了一个最简单的 SessionStore，也就是会话存储。它的作用是先把同一个 session_id 下的历史消息保存起来，让系统开始具备最基础的多轮对话记忆"能力。虽然这个版本只是内存存储，进程一重启就会丢失，但对现阶段来说已经足够了，因为它先帮你验证了一件事：Python 版 OnCall 不只是单轮问答接口，而是已经开始具备会话状态这个后续智能体系统必需的基础能力。
从项目结构上看，第二步的意义在于开始引入真正的分层。原来项目里只有入口、路由、schema 和 SSE 工具，逻辑基本都贴在接口附近；到了第二步，项目开始出现 services/ 和 infra/memory/ 这样的目录，这代表你已经不再把所有东西都放在 API 层，而是把"业务逻辑"和"底层存储"往不同层拆开了。虽然现在规模还很小，但这种结构一旦立住，后面继续接入模型、Milvus、Redis、工具系统时，整个工程就会顺很多。
第二步还带来了一个很重要的效果，就是开始从"接口 mock"过渡到"业务 mock"。第一步的 mock 更像是在证明接口通不通，而第二步的 mock 已经开始模拟真实业务行为了。因为现在回复内容不只是简单返回一段固定文本，而是可以结合当前会话历史数量来构造结果，这说明系统内部已经开始有状态、有上下文，而不是纯静态输出。
从演进路径上来说，第二步其实是在给第三步做准备。因为一旦 ChatService 已经存在，下一步你要做的事情就非常清晰了：把 ChatService 里原本的 mock 拼字符串逻辑，替换成真实的 LLM 调用；再往后，可以在这个 service 里继续插入 RAG 检索、工具调用、提示词构建等能力。也就是说，第二步本身做的事情不一定最"炫"，但它是整个 Python 版 OnCall 从"能跑"走向"可持续开发"的真正起点。
所以如果把第二步浓缩成一句话，它做的事情就是：把第一步跑通的最小聊天接口，进一步整理成"路由层 + 服务层 + 会话存储层"的结构，让 Python 版 OnCall 开始具备最基础的业务分层和多轮会话能力。
Step03
第三步做的事情，核心就是把前面那个"结构已经搭好、但回复还是假的聊天系统"，正式升级成了一个会真实调用大模型的聊天系统。如果说前两步是在搭外壳、理结构，那么第三步就是第一次把"智能能力内核"真正接进来，让 Python 版 OnCall 不再只是返回本地拼出来的 mock 文本，而是开始根据用户输入，向真实模型发请求并拿回结果。
这一阶段最重要的变化，是你新增了一个独立的模型适配层。也就是说，模型调用不再直接散落在路由或 service 代码里，而是被封装进了 infra/llm/openai_compatible.py 这样的文件中，专门负责和 OpenAI 兼容接口通信。这一步的意义非常大，因为它把"业务逻辑"和"模型供应商实现细节"分开了。以后无论你换模型地址、换模型名字，甚至换一家兼容 OpenAI 协议的服务商，都主要改这一层，而不用把整个项目都改一遍。
与此同时，你还补上了配置层，也就是 config.py 和 .env 这部分。这样模型的 base_url、api_key、model 名称这些信息，就不再写死在代码里，而是统一从配置读取。这一步虽然看起来不像"功能开发"，但它实际上是在把项目从"临时试验代码"往"真正可持续维护的工程"推进。因为只要配置和代码分离了，后面开发、测试、部署就会清晰很多。
在业务层面，第三步真正改造的是 ChatService。前面第二步里，ChatService 只是基于 session 和用户输入拼一个 mock 回复；到了第三步，它开始承担更真实的职责了：先读取当前 session_id 对应的历史消息，再加上 system prompt，把这些内容组织成模型需要的 messages 格式，然后调用 LLM 适配器获取真实回答，最后再把用户消息和模型回复一起写回会话历史。也就是说，从这一刻开始，你的系统已经不只是"能保存上下文"，而是"会带着上下文去和模型对话"。
第三步还把流式接口也从假流升级成了真流。前面 /api/chat_stream 是本地逐字输出一段 заранее 准备好的字符串，本质上只是模拟 SSE；而现在，它已经变成真正调用模型的流式接口，持续接收模型返回的增量内容，再通过 start、token、done 这些事件发给前端。这一步非常关键，因为它说明你的 OnCall 不只是支持"普通调用模型"，而是已经具备了后续 Agent、工具调用、RAG 流式展示这些高级能力所依赖的基础输出模式。
从整体结果上看，第三步完成后，系统内部第一次形成了一个真实的 AI 闭环：用户请求进入路由，路由调用 ChatService，ChatService 组织消息并调用模型，模型返回真实内容，再把结果写进 session history，最后由接口返回给用户。这和前两步最大的区别在于，前两步解决的是"程序骨架和工程结构对不对"，而第三步解决的是"这个系统是不是真的开始像一个 AI 系统那样工作了"。
所以如果把第三步浓缩成一句话，它做的事情就是：把 Python 版 OnCall 从一个"有结构的 mock 聊天后端"，升级成了一个"有结构、可配置、支持上下文、支持流式输出的真实大模型聊天后端"。这一阶段做完以后，后面的第四步就顺理成章了，因为你已经有了模型调用能力，接下来只需要在模型调用之前插入检索逻辑，就可以把系统继续升级成带 RAG 的 OnCall。
Step04
第四步做的事情，核心就是把第三步那个"已经能真实调用大模型聊天"的系统，进一步升级成了一个带知识库检索能力的 RAG 系统。如果说第三步解决的是"模型能不能真正回答"，那么第四步解决的就是"模型能不能在回答之前，先去查本地知识，再基于知识回答"。这一步做完之后，Python 版 OnCall 就不再只是一个通用聊天后端，而是开始具备"面向特定知识库做增强问答"的能力了。
这一阶段最重要的新增能力，是文件上传和知识入库链路。也就是说，系统不再只接收用户的聊天请求，还新增了一个上传入口，用来接收本地文档。上传之后，文件不会只是简单保存下来，而是会继续经过一条完整的数据处理流程：先读取文件内容，再对文本做切分，然后调用 embedding 模型把每个文本片段转成向量，最后把这些片段连同向量一起写入 Milvus。这个过程的意义在于，它把原本"人类可读的文档"，转成了"系统可以检索的知识单元"。
为了让这条链路成立，第四步还引入了 embedding 层和向量存储层。embedding 层负责把文本变成向量，也就是把自然语言内容转换成模型可以用于相似度检索的数值表示。向量存储层则负责把这些向量和对应的文本片段保存起来，并在后续查询时，根据用户问题去做相似度搜索。你这里用的是 Milvus，本地开发阶段走的是 Milvus Lite，所以这一步实际上也意味着：你的项目已经从"只有大模型接口"扩展成了"模型 + 向量库"的双基础设施架构。
第四步另一个关键变化，是在聊天链路里插入了检索逻辑。也就是说，ChatService 不再只是把历史消息和当前用户问题直接送给大模型，而是多了一步：当 use_rag=true 时，先用用户问题生成 query embedding，再到 Milvus 里查找最相关的知识片段，把这些片段组织成上下文信息，然后再一起送给模型。这样一来，模型的回答就不再只依赖自身训练时学到的通用知识，而是会优先基于你本地上传的知识内容来回答。
从行为上看，这一步带来的变化非常明显。开启 RAG 时，模型回答会明显引用知识库中的具体信息，并且返回结果里会带上 references 和 trace，表示它命中了哪些知识片段、检索到了多少条结果。关闭 RAG 时，模型就退回到自身的通用能力，只能给出更泛化、更经验性的回答。你实际做的对照测试已经很好地证明了这一点：在开启 RAG 时，回答会直接贴着你上传的 runbook 内容走；关闭 RAG 时，回答就变成了一个泛化的 5xx 排障思路。这说明第四步并不是"看起来像加了知识库"，而是知识检索真的已经在回答流程里生效了。
从工程结构上说，第四步不只是"多加了几个功能"，而是让整个项目开始出现了更完整的 AI 后端形态。原来系统里只有 API、service、session、LLM 适配器；到了第四步，项目里又增加了 loader、splitter、embedding adapter、Milvus store、RAG service、ingestion service 这些模块。也就是说，Python 版 OnCall 已经开始从一个普通聊天服务，演进成一个真正意义上的"知识增强智能体后端"。
如果把第四步浓缩成一句话，它做的事情就是：为 Python 版 OnCall 建立了一条从文件上传、知识入库到检索增强回答的完整 RAG 闭环。
这一步完成之后，你已经具备了两种能力：一种是纯模型问答，另一种是基于本地知识库的增强问答。也正因为这一步已经完成，接下来的第五步才会很自然地变成"接入工具调用"，因为现在系统已经有了聊天能力，也有了知识能力，下一步就该给它加上"主动调用外部工具"的执行能力了。
Step05
第五步做的事情，核心就是在前面已经具备"普通聊天"和"RAG 检索增强问答"能力的基础上，再往系统里加入了一层工具调用能力。如果说前四步的系统本质上还是"用户问，模型答"，那么第五步之后，系统开始具备一种新的行为模式：模型不再只是单纯根据上下文生成答案，而是可以在判断"需要外部实时信息"时，先请求调用某个工具，等工具返回结果后，再基于这个结果组织最终回答。也就是说，系统第一次拥有了"借助外部能力完成回答"的执行型能力。
这一阶段最重要的新增内容，是你建立了一个最小的工具系统。它并不是一开始就接入日志、告警、数据库这些复杂工具，而是先用 get_current_time 这个非常简单的工具，打通了整条工具调用闭环。这样做的重点并不在于"获取时间"这个功能本身，而在于验证整个协议和流程是否成立：模型能不能识别自己需要一个工具，后端能不能执行这个工具，工具执行结果能不能被重新送回模型，以及模型能不能基于工具结果生成自然语言答案。也就是说，第五步的真正价值在于"让系统第一次学会工具调用"，而不是某一个具体工具有多复杂。
为了让这件事成立，第五步还新增了工具注册中心，也就是 ToolRegistry。这一步的意义在于，你不再是零散地写几个 Python 函数，而是开始把工具当成一种正式的系统能力来管理。注册中心一方面负责把工具的名字、描述和参数 schema 转换成模型能读懂的格式，另一方面负责在模型返回工具调用请求后，根据工具名找到对应的工具实现并执行。这样一来，系统里第一次出现了一种"工具协议层"，后面继续扩展日志工具、告警工具、内部文档工具时，都会沿用这个统一框架，而不是各写各的。
与此同时，第五步也真正改造了模型调用层。原来第三步和第四步中的 LLM 适配器，本质上只需要处理"发消息给模型，再收回文本答案"这类单轮行为；到了第五步，LLM 适配器开始支持 tools 和 tool_calls 这些结构化字段。也就是说，模型返回的结果已经不再只是"纯文本"，而可能是一种"我要调用某个工具"的结构化请求。这代表你的系统开始从"文本交互型"演进到"文本 + 结构化动作请求"混合型交互，这一步其实非常关键，因为它是从普通聊天系统走向 Agent 系统的第一个真实转折点。
在业务层面，第五步最核心的变化发生在 ChatService。前面第四步中，ChatService 的职责主要是：拼好历史消息和 RAG 上下文，然后把它们送给模型，再拿回答案。而到了第五步，ChatService 里新增了一层最小的 tool loop，也就是一个小型循环机制：先发起第一轮模型请求；如果模型直接给出最终答案，就结束；如果模型返回 tool_calls，那就进入工具执行逻辑，执行完成后把工具结果作为新的消息继续发给模型，再让模型基于工具结果生成最终自然语言回答。这个循环虽然现在还比较简单，但它已经让系统开始具备"思考是否要借助外部工具"的能力，这本质上已经是一个最小 Agent 行为了。
第五步还对流式接口做了升级。虽然这一版还没有做到"工具调用过程与模型 token 真正完全混合式的实时流"，但它已经能把工具相关的过程通过 SSE 事件流发给前端，比如 tool_call、tool_result，然后再继续输出最终答案的 token。这意味着你的前端以后不只是能显示"模型在回答什么"，还可以显示"模型刚刚调用了哪个工具、拿到了什么结果"。从 OnCall 场景来说，这一点非常重要，因为在一个运维、排障、分析类系统中，用户往往不仅关心最终答案，还关心这个答案是怎么来的，调用了哪些外部能力，这样系统的行为才更可解释、更可信。
从整体效果上说，第五步完成后，系统已经不再只是一个"会聊天、会查知识库"的后端了，而是开始具备最基础的"执行能力"。前四步解决的更多是知识和表达问题：系统能不能基于上下文和知识回答用户；而第五步开始解决的是动作问题：系统能不能在需要外部实时事实时，不靠猜，而是主动请求工具来获取信息。这就是为什么第五步虽然只先接了一个简单的时间工具，但它在系统演进上的意义其实非常大，因为它第一次让 Python 版 OnCall 从"增强问答系统"走向了"最小可执行智能体系统"。
如果把第五步浓缩成一句话，它做的事情就是：在现有聊天与 RAG 系统之上，建立了一个最小可用的工具调用闭环，让模型能够根据需要触发工具、获取外部信息，并基于工具结果生成最终回答。
也正因为这一步已经完成，后面的第六步就会非常自然：你不需要再重新设计工具框架，而只需要沿着这一套机制，继续增加更符合 OnCall 场景的工具，比如日志查询、告警查询、内部文档查询、数据库只读查询等。换句话说，第五步真正搭好的，不只是一个时间工具，而是整个 OnCall 后续工具体系的底座。
Step06
第 6 步做的事情，核心就是把第 5 步那个"只有一个时间工具的最小工具调用系统"，扩展成了一个更贴近 OnCall 场景的多工具系统。如果说第 5 步是在验证"模型会不会调用工具"，那么第 6 步解决的就是"模型能不能在不同的运维排障场景里，选择合适的工具来辅助分析问题"。这一步做完以后，系统已经不只是会聊天、会查知识库、会查时间，而是开始具备了面向真实 OnCall 问题调用多种外部能力的基础。
这一阶段最重要的变化，是新增了三个真正有业务意义的工具：内部知识库查询工具、告警查询工具和日志查询工具。内部知识库工具的作用，是让模型在用户明确要求"查知识库""查 runbook""查内部文档"时，主动调用现有的知识检索能力，而不是仅仅依赖主链路里的 use_rag=true 开关。告警工具的作用，是让模型能够针对"当前有哪些 firing 告警""gateway 最近的 critical 告警有哪些"这类问题，主动获取结构化告警数据。日志工具则是让模型可以针对"最近有没有 timeout""有没有 5xx 相关 ERROR 日志"这类问题，主动查询日志并基于日志做进一步总结。也就是说，第 6 步让工具系统开始从演示性质，走向真正的运维场景应用。
为了支撑这些工具，第 6 步并没有推翻第 5 步已经做好的工具调用框架，而是在原有基础上把工具注册中心扩展成一个更完整的多工具管理层。工具注册中心现在不再只是登记一个 get_current_time，而是统一管理多个工具，并且为每个工具提供名字、描述、参数 schema 和统一的返回结构。这样一来，系统已经开始形成一个比较稳定的工具协议：模型根据描述选择工具，后端按统一规则执行工具，工具再按统一格式返回结果，最后模型基于这个结果生成自然语言回答。这说明你的系统已经不再是"临时加几个函数"，而是在形成一个真正可以持续扩展的工具体系。
在业务流程上，第 6 步本质上还是沿用了第 5 步的 tool loop，只不过现在这个 loop 开始服务于更复杂的场景了。也就是说，ChatService 的核心逻辑没有推翻重写，而是在原有"模型先决定是否调用工具"的基础上，继续支持更多工具种类，并适当放宽了工具循环轮次限制，以适应一个回答里可能涉及多次工具请求的情况。这个变化的意义在于，你已经不再处在"验证框架能不能跑"的阶段，而是进入了"框架已成立，开始往里面填真正的业务能力"的阶段。
从系统行为上看，第 6 步带来了一个很明显的升级。以前系统主要有三种能力：普通聊天、大模型问答、RAG 检索增强回答；而现在又多了一层"面向 OnCall 的工具型分析能力"。这意味着，用户问问题时，系统不只是被动地根据知识生成答案，而是会开始主动判断：这个问题更适合查知识库，还是查告警，还是查日志。比如在"5xx 告警应该先检查什么"这种问题上，它会倾向于查内部知识库；在"gateway 现在有哪些 firing 告警"这种问题上，它会选择查告警；在"最近有没有 timeout ERROR 日志"这种问题上，它会选择查日志。这种"按问题类型动态选择工具"的行为，就是第 6 步最本质的成果。
这一阶段的另一个重要变化，是系统的可解释性进一步增强了。因为每一次工具调用都会在 trace 里留下记录，包括模型选择了哪个工具、传了什么参数、工具返回了什么结果。流式接口也继续沿用了第 5 步的事件机制，可以把 tool_call、tool_result 和最终的 token 输出逐步发给前端。这使得系统不只是"给答案"，而且能展示答案是如何来的。对于 OnCall 场景来说，这一点非常重要，因为用户往往不只关心结论，也关心系统到底查了哪些信息、依据了哪些数据做判断。
从工程角度来说，第 6 步最大的价值，不在于某一个具体工具，而在于你已经搭好了一个可以持续扩展的 OnCall 工具体系底座。虽然目前 alerts 和 logs 还是 mock 数据，但这一步已经证明：多工具注册、模型选工具、工具执行、结果回填、trace 记录、SSE 输出，这整套机制都已经成立。也就是说，后面你要做的，已经不再是"怎么设计工具调用框架"，而是"把 mock 工具替换成真实数据源"。这会让后续开发轻松很多。
如果把第 6 步浓缩成一句话，它做的事情就是：在现有聊天、RAG 和单工具调用能力之上，建立了一个面向 OnCall 场景的多工具系统，让模型能够根据问题类型主动调用知识库、告警和日志工具来辅助分析。
也正因为这一步已经完成，下一步才会很自然地进入两个方向中的一个。一个方向是把 alerts 和 logs 从 mock 替换成真实后端数据源；另一个方向是进一步做多步工具协同，也就是更接近 ReAct 或 Plan-Execute-Replan 的执行模式。换句话说，第 6 步真正完成的，不只是 3 个工具，而是整个 OnCall 智能体执行能力的第一层业务化落地。
Step07
第 7 步做的事情，核心就是把第 6 步中仍然停留在 mock 阶段的工具系统，开始真正接入真实业务后端。如果说第 6 步解决的是"模型能不能在 OnCall 场景里选择合适的工具"，那么第 7 步解决的就是"这些工具拿到的数据是不是真的来自外部系统，而不是写死在代码里的假数据"。这一点非常关键，因为它标志着系统开始从"可演示的智能助手"迈向"具备真实业务接入能力的智能助手"。
这一阶段最重要的工作，是把 query_alerts 从第 6 步中的 mock 告警数据，替换成了一个真实的 HTTP 后端适配器。也就是说，告警工具不再直接读代码里写好的几条静态告警，而是通过新增的 alerts_client 去访问真实的告警接口，再把接口返回的数据做规范化处理，然后交还给工具层。这个改动的意义非常大，因为它让"工具"这层和"真实后端接口"这层被正式分开了。以后无论你接的是 Prometheus、Alertmanager、Grafana，还是公司内部告警平台，你都不需要推翻工具框架，只需要替换或扩展底层的 backend 适配器。
在实现层面，第 7 步并没有推翻第 5、6 步已经搭好的工具调用架构，而是沿用了原有的 ToolRegistry + ChatService tool loop 机制，只把 query_alerts 的底层数据来源换成了真实 Prometheus 接口。这说明前面几步搭建的架构已经经得住扩展，不需要每次引入真实系统时都重写一遍业务逻辑。换句话说，第 7 步验证的不只是"能不能查真实告警"，也间接证明了你前面搭好的工具分层和执行流程是合理的。
为了完成这一步，你还补上了本地 Prometheus 环境。也就是说，第 7 步不只是写代码层面的工作，还包括真实运行环境的搭建和验证。你本地起了一个最小 Prometheus 实例，配置了最基本的规则文件，并用一条始终成立的测试告警规则，确保 /api/v1/alerts 这个真实接口能返回 firing 告警。这样做的价值在于，你不是"假设自己接上了真实告警系统"，而是真正在本机造出了一个可访问、可验证、可用于联调的真实告警源。这一步把"真实后端接入"从概念变成了一个可以重复验证的本地开发能力。
从系统行为上看，第 7 步完成后，query_alerts 已经不再是一个"模型以为自己在查告警，其实只是代码里拿几条假数据"的工具，而是真的能调用 Prometheus /api/v1/alerts，把返回的告警信息结构化处理后交给模型。模型再根据这些真实告警信息生成自然语言总结。这一点从你后面的测试结果已经很清楚了：模型不仅成功触发了 query_alerts，还从真实返回中读到了 PrometheusAlwaysFiring 这条告警，并给出了带有状态、级别、描述和时间信息的总结。这说明第 7 步的核心目标已经达成------工具系统开始消费真实系统数据，而不是内部 mock 数据。
这一阶段还有一个非常重要的意义，就是它验证了工具系统在"真实接口条件下"依然能稳定工作。第 6 步里，工具调用闭环虽然已经跑通，但那是在 mock 数据条件下完成的，风险比较低；到了第 7 步，工具开始真正面临 HTTP 超时、接口结构不一致、字段归一化、环境依赖这些现实问题。而你通过 alerts_client 的封装，把这些外部复杂性都隔离在工具层下面，没有把它们污染到 ChatService 或上层路由。这说明你的项目架构已经具备了承载真实外部系统接入的能力，而不仅仅是写几个 demo 用的工具。
从项目整体演进上看，第 7 步是一个很关键的转折点。前面第 4 步和第 5 步更多是在打能力基础：RAG、工具调用协议、SSE 事件流；第 6 步是在这个基础上做出多工具系统；而第 7 步第一次让系统真正连接到了外部真实服务。也就是说，从这一步开始，OnCall 不再只是"模拟一个会查知识和查告警的助手"，而是在逐步成为一个"能接入真实监控系统并进行辅助分析的助手"。
如果把第 7 步浓缩成一句话，它做的事情就是：在第 6 步多工具系统的基础上，把 query_alerts 从 mock 数据升级为真实 Prometheus 告警接口接入，并完成了本地真实告警环境的搭建与验证。
也正因为第 7 步已经完成，后面的下一步就变得很自然了。既然真实告警接口已经接通，那么接下来最合理的方向就是继续把 query_logs 也从 mock 替换成真实日志后端。到那时，你的系统就会同时拥有真实知识库、真实告警和真实日志三个核心 OnCall 能力，整体完成度会再上一个台阶。
全程按照GPT的提示实现，先复现，之后再来梳理这个过程。
原项目来自小林Coding，但是只有基于Java和Go的实现。