Claude Code Agent 设计机制
八二定理：80% 的能力取决于模型，剩余 20% 来自 cli。
QA 模式：
user message + <attachment> -> model -> answer message
TASK 模式:
user message + <attachment> -> model -> temp message + tool_use -> exec tool -> model -> response
Noteagent 和编排式workflow区别：
workflow式的设计通常有while循环、if-else之类，没有达到某个条件就一直不退出；而 agent 是在无形中隐式循环，只要是模型对你有一个工具执行的输出，那么 cli 就一定会帮这个模型把对应的工具做一个执行，哪怕是一个错误的结果，也会把这个信息返回给它，而这个循环的开始和结束是模型在控制的，cli 是一个执行者。
一个 cli 的简单架构模块：
- context（整个系统固定写好的一些信息）
- tool use（工具执行中心）
- message + llm（消息处理，和模型通信）
这三个核心模块足以构成cli一个最小化的结构，也就是需要给出相关系统上下文，一个脚手架执行的能力，还有一个互动通信的地方。
cc 在这最小化的三个核心元素的 cli 上还引入了非常多的东西，比如在工具执行的前和后加上了hook（preToolUse、afterToolUse），context 层面这有memory、system prompt（可以做一些 diy：action style）、env。
简单说一下cc这个架构，
- 用户界面层就是 UI，给用户一个大输入框，显示消息的一个组件（用户的消息以及来自模型、工具执行结果的消息），还有另外一个单独的模态框（比如当前要执行一个bash工具，弹出来问你是否允许）。
- 组件协调层就是维护上面这些 UI 的生命周期，不管是输入框还是模态框，这些东西都需要状态管理机制。
- 核心来到 query，每次发消息触发一个query，这个query执行之后，如果有新的工具执行，它就会在递归的地方query（相当于这个执行结果作为一个新的user message再次发给这个模型从而触发query自身的再次调用）。
- 消息管理一方面是由于你是流式的拿到整个消息，你下一轮请求模型之前要把这些消息放到一个正确的顺序上（比如你并发执行了多个工具，需要通过这些消息ID的关联进行一个拼接），另一方面就是涉及模型传输协议的一些小问题。
- AI 交互就比如 querySonnet、queryHaiku 这些，发起请求，做流式处理。
- 权限管理就是看一个命令是否危险，还有就是看用户是否放行了这个工具的执行权限，如果用户没有放行的话，就弹出对话框让用户确认是否要执行这个命令。
- 工具执行层涉及到外部的一些MCP工具以及内部的bash、write、edit等等这些工具，他们统一注册到一个工具中心上，模型不用管他们是内部还是外部的，对模型来说就是收到一堆允许调用的工具集合以及每一个工具的参数描述和作用描述。
- 并发控制就是，我们可能收到一个列表要并行调用一堆的工具使用，这时候就可以看哪些工具能够并发去执行，这样可以加快整个系统运行。
- 数据存储层就是做一个持久化保存，比如你不小心把终端关了或者啥的，你下次打开这个项目文件夹要把之前agent所有对话的上下文信息都恢复出来，这就依赖数据的一个持久化。配置文件就是你在启动cli的时候去加载的一些信息。另外就是模型请求过程中或者工具执行发生了一些错误，就可以把这些error信息统一打到一个log文件里。