程序员阿江(Relakkes) c2cd615824 docs: rebuild the documentation site around two readers
The site had drifted from the product. Every screenshot predated the
v0.5.0 UI redesign, the reading experience shipped no search and no
syntax highlighting, and a third of the pages were internal process
artefacts — migration task lists addressed to agentic workers, a
release runbook, a proposal marked "historical".

Reorganise around the only two people who read this: someone getting
the desktop app running for the first time, and someone reading the
source. Five sections replace nine — start / desktop / im / cli /
internals — and the pages that served neither reader are gone.

Site rewrite:

- Palette lifted from the desktop app's 「纸·墨·印」 themes, so the
  site and the product read as one thing. Light mirrors 纯白, dark
  mirrors 墨夜, and dark mode exists at all now.
- Fonts are self-hosted. The old @import from Google Fonts is
  unreachable from mainland China, which left every heading in a
  fallback serif; it also only requested weight 600 while the CSS
  asked for 900, so Latin and CJK in the same heading disagreed.
- Docs were shipped as one 968KB manifest downloaded on every page
  view. Split into a 32KB index plus one lazily imported chunk per
  page; the entry bundle is now 101KB gzipped.
- Add search, syntax highlighting, per-route meta with canonical and
  hreflang, a sitemap, and an error boundary. Replace the 44vh
  mobile sidebar with a drawer.
- Image dimensions are read at build time and written into the tag,
  so lazy images reserve their space instead of collapsing.

Screenshots are recaptured from a real v0.5.0 build against a clean
demo project, with tokens, QR codes and paired accounts redacted.
The previous set is deleted rather than kept alongside.

Routes follow file paths, so the restructure would have broken every
inbound link; 37 old paths redirect, in both languages. The PR policy
gate and CODEOWNERS also hardcoded docs/guide/contributing.md.

Verified: check:docs 78 pages / 323 links / 0 problems, check:policy
127 pass. Walked every route at 1440 and 390 in both themes for
overflow, contrast, keyboard reachability and focus management.
2026-07-27 17:32:41 +08:00

4.2 KiB
Raw Blame History

title nav_title description order
架构总览 架构总览 五层代码怎么分工,一条消息怎么流过它们,以及改动某块功能该从哪篇读起。 0

架构总览

Claude Code Haha 看着是一个桌面应用,实际是五块可以各自独立运行的代码拼起来的。想读源码或者提 PR先把这五块的边界分清楚后面每一篇都会落在其中一块里。

desktop/src/          前端 —— React + Zustand只画界面不碰系统能力
desktop/electron/     桌面壳 —— Electron 主进程,管窗口、更新、终端、原生预览
src/server/           本地 Server —— Bun.serve 的 REST + WebSocket桌面端和手机端共用
src/                  CLI 内核 —— Agent 循环、工具系统、权限、记忆、Skills
adapters/             IM 接入 —— 每个平台一个独立 sidecar桥回同一套会话

三条事实值得先记住:

  • CLI 内核是唯一执行方。桌面端每开一个会话Server 就拉起一个 CLI 子进程;前端点的每个按钮最后都变成发给它的一条消息。
  • 本地 Server 是唯一入口。桌面端、手机 H5、IM adapter 走的是同一套 REST 与 WebSocket只是鉴权等级不同。
  • Electron 是当前桌面主路径desktop/src-tauri/ 只保留打包资源和历史代码作回滚,不是运行时。

CLI 内核怎么分层

CLI 内核的整体分层

入口层做完初始化后分成两侧:左侧是把一次请求跑完的主链路(终端界面 → 查询引擎 → 工具系统 → 子 Agent右侧是被主链路调用的横切能力状态管理、Skills 与插件、MCP / OAuth / 记忆等服务)。桌面端接管了终端界面那一格,其余部分原样复用。

一条消息经过什么

一次请求的生命周期

用户输入被解析、组装上下文后发给模型,流式返回里一旦出现工具调用,就先过权限校验再执行,结果回填进上下文继续下一轮,直到模型不再请求工具。桌面端看到的「工具调用卡」「权限询问卡」,就是这条链路上两个节点的可视化。

工具和权限的关系

工具系统与权限门

所有工具在同一个注册中心登记,按能力分成文件、命令、系统、子 Agent、外部集成和通信几类。真正决定安全边界的是下面那条固定管线任何一次调用都要先过参数校验和权限门再进沙箱执行。加新工具时接进注册中心不难难的是想清楚它落在权限门的哪一侧。

我想改 X该看哪篇

你想动的东西 从这篇开始
窗口、托盘、自动更新、内嵌终端、原生预览 桌面端架构
REST 接口、WebSocket 事件、鉴权、Provider 代理 本地 Server 与 API
不知道某个功能的代码在哪个目录 项目结构
子 Agent 的行为、内置 Agent、Agent Teams 多 Agent 使用指南
子 Agent 的生成路径、工具池过滤、后台任务引擎 多 Agent 实现原理
Agent 主循环、系统提示词、上下文压缩 Agent 框架深度解析
Skill 的写法、来源优先级、触发方式 Skills 使用指南
Skill 的发现、注入、fork 执行 Skills 实现原理
记忆存在哪、什么时候写 记忆系统使用指南
记忆的注入、提取、检索、团队同步 记忆系统实现原理
后台自动整合记忆 AutoDream 记忆整合
屏幕控制的工具、授权、坐标换算 Computer Use 架构
IM 消息协议、访问控制、权限中继 Channel 系统
提 PR 前要跑哪些检查、发版流程 参与贡献与质量门禁
在终端里跑 CLI、写自动化脚本 CLI 安装与启动

产品功能怎么用不在这个分区,从 开始使用桌面端功能 进。