五层架构里，哪几层最值得拿来当通用分析框架
我不会把五层都等量地背
CCB 的五层架构很有用，但我不会把它当成“必须逐层平均记住”的目录。
如果目的是以后拿它去分析别的 coding agent，我最想先复用的是三层：
- 编排层
- 核心循环层
- 工具层
交互层和通信层当然也重要，但它们更像边界层；中间三层更像通用骨架。
第一层：编排层最适合当“系统感”的起点
CCB 对 QueryEngine 的强调非常对路。
很多人一想到 coding agent，会直接盯模型循环或工具调用，但真正把产品感拉出来的，往往是编排层：
- 会话状态怎么管
- transcript 怎么持久化
- cost 怎么累计
- 文件快照和 undo 怎么接进来
这层值钱的地方，是它逼你意识到：
coding agent 不是只有一个 loop，而是一个围绕 loop 组织会话、状态和恢复能力的系统。
第二层：核心循环层最适合当“最小原理框架”
这层几乎是所有 agent 系统都绕不开的共性：
- 组装上下文
- 调模型
- 解析工具调用
- 执行工具
- 把结果塞回下一轮
所以它当然值得复用。
但我不会只把它看成“Claude Code 的循环怎么写”，而会把它当成判断别的系统是不是还停在表层包装器的标准。
如果一个产品讲不清这层，就很难说它有真正的 agentic loop。
第三层：工具层最适合分析系统边界
工具层为什么重要，不是因为“工具多”，而是因为它最直接暴露系统边界：
- 工具能力是怎么声明的
- 输入校验在哪里
- 权限检查在哪里
- 失败和结果怎么回流
这层特别适合拿来比较不同 coding agent。
因为很多产品体验上的差异，最终都能回到工具能力的组织方式和边界控制上。
交互层为什么我不先拿来当主框架
交互层很重要，但它的通用性相对没那么高。
Terminal UI、IDE UI、Web UI 都会长得不一样。你当然可以分析输入捕获、消息展示、命令模式这些点，但如果先从这里开始，很容易被界面形态带偏。
所以我更愿意先把它当“具体产品实现差异层”，不是最先拿来复用的分析框架。
通信层为什么我放后面
通信层也值得看，尤其 Provider 抽象和流式 API 很关键。
但如果你还没把编排层、核心循环层、工具层看清，过早盯通信层很容易进入“Provider 支持了几个、协议有什么细节”的局部视角。
这层更适合在中间三层站稳之后，再用来分析系统的可扩展性和模型接入策略。
如果要用这三层分析别的 coding agent
我会先问三组问题：
编排层
- 会话状态放在哪
- 长任务怎么恢复
- 成本和历史怎么管理
核心循环层
- 一轮 loop 的 完整链路是什么
- 上下文在哪收缩、压缩、替换
- 模型输出怎么转成后续动作
工具层
- 工具边界怎么定义
- 权限在哪做
- 工具结果怎么进入下一轮决策
只要这三组问题能问清，一个 coding agent 的骨架基本就能看出七八成。