读源代码

我们前面讲了架构、链路、并发、安全，最后一篇工程向收官：
线上出问题时，到底怎么定位。

AI助手系统要上线，安全一定不能放在最后补。
这一篇我们不聊“炫技功能”，只聊“怎么避免事故”。

OpenClaw渠道多、能力多，但核心代码没有膨胀到不可维护，关键就在插件化。
这一篇我们就看插件加载器的主思路。

做多模型系统时，最容易踩的坑之一就是：
“同名模型在不同Provider下，能力和上下文窗口并不一样”。

很多同学会觉得“我明明改了提示词，为什么助手行为变化不稳定？”
这个问题通常和工作空间文件注入机制有关。

很多同学体验AI助手时，最在意的一点就是“回得快不快”。
但真实工程里，快和稳经常打架。OpenClaw在这块做了不少折中。

到了线上场景，最容易把AI助手搞崩的，不是“模型智商不够”，而是“并发消息打架”。
这篇就看OpenClaw怎么处理这件事。

AI助手好不好用，关键不只是模型强不强，还得看“会不会记住该记的上下文”。
这一篇就专门聊Session。

前面两篇把“怎么启动”讲了，这一篇正式回答最关键的问题：
用户发来一条消息，OpenClaw内部到底怎么跑起来的？

前一篇我们走完了CLI链路，这一篇终于进入核心区域：Gateway。
如果说CLI是“入口大厅”，那Gateway就是“总控室”。

上一篇我们把地图铺开了，这一篇开始走主链路第一站：CLI启动。
毕竟无论你是跑openclaw gateway还是openclaw agent，第一步都绕不开CLI入口。

最近打算系统性地啃一下OpenClaw源码，顺手也开个系列记录一下自己的理解过程。
这一篇是第1篇，目标很简单：先把地图摊开，搞清楚这个项目大致由哪些模块组成，消息是怎么流动的，后面再按模块逐个击破。

这应该是Pingora源码阅读的最后一篇文章，之前介绍了Pingora中两个比较重要的概念, Server和Service, 本篇文章着重于监听服务的钩子函数, 这也是我们主要写业务代码的地方。

上次主要阅读了Pingora的Server部分的代码, 本文阅读Pingora另一个比较重要的部分Service, Pingora内置两种服务background(后台)和Listening(监听), 本文着重后者。

要想深入Pingora应该是需要阅读源代码的，所以分析一下源代码，虽然Pingora没有提供丰富的示例，但是提供了一些不错的文档，比如它的internals.md文档，提供了很多细节和示意图，本系列文章会引用很多其中的示意图，Pingora的源码分析应该会分为2篇文章或更多。