前面几篇讲的都是"系统怎么运转"，这篇讲"能力怎么长出来"。 Octop 里给 Agent 加本事有三条路：技能、知识库、插件。三者的代码量差不多（3,337 / 2,325 / 4,089 行），但重量级差了三个数量级——最轻的那个只要往目录里放个 Markdown 文件就生效了，最重的那个是进程内加载的 Python 代码。 这个分层不是随便划的，它直接决定了"你想加的东西该放哪"。

第 1 篇画链路的时候，画到这一行就收住了： async for ev in project_stream(agent_manager, agent_id, request, ...): yield ev 当时我说「project_stream 是这里的分界线：往里是 harness 的地盘，往外是 Octop 的地盘」。这篇把它拆开。 顺带把...

第 5 篇写 _start_agent 的时候，第 ⑦ 步我写的是「_post_start_agent：注入 gateway 工具、清洗 MCP 工具名、同步技能」，一句就过去了。 其实那一步里藏着整个项目我最喜欢的一部分：9 个中间件。 它们合计不到 900 行，每个都很小，但每一个都对应一个具体的、真实发生过的问题。

读源码有个顺序问题：先读哪块？ 我原来的顺序是先读运行时（第 5 篇），结果一路都在猜 repos 是什么。这篇回头补地基。 infra/db/ 8,854 行，是后端第五大模块。但读完发现它的结构比预想的清楚——难的不是设计，是兼容。

第 1 篇写启动链的时候，有个分叉我没敢展开： if should_defer_control_plane_db(config, self.paths): self._started = True self._emit_wizard_password(user_count=0) return OctopServer.start() 跑到这里就 return...

前几篇一直在往上走：进程怎么起、Agent 怎么活、谁能碰谁的数据。这篇横向切一刀，读 infra/gateway/——13,857 行，第二大模块，负责所有消息的进出口。 打开 ws_channel.py 的第一行，我笑了： """Virtual IM channel that delivers Dashboard chat over WebSocket.""" Dashboard...

前面读了启动链路和 Agent 运行时，这篇读隔离。 之所以单独拎出来，是因为"多用户"这三个字在自托管项目里最容易含混：有的项目是"多用户登录"，有的是"多租户隔离"，两者差着十万八千里。 看 README 看不出来，只能读代码。 读完之后我的判断是：Octop 属于前者，而且它自己知道。

上一篇只摊了地图，这篇开始钻。按重要性，第一个要读的是 infra/agents/manager.py——4187 行，是整个后端最大的单个文件。 我原以为它会很复杂，读完发现职责其实很清楚，就四件事：启动、注册、执行、回收。复杂的是每一件事背后的并发问题。

上一篇把 Octop 装起来跑通了，这一篇换个方向：不碰功能，只读代码。 我读源码有个习惯，第一篇绝对不抠实现。先干三件事——它到底自己写了什么、代码重量压在哪、一次启动按什么顺序把东西搭起来。这三件事不清楚，后面看任何一个模块都会飘。