调用tool不再是Agent的主要能力，怎么让其真正做事，cc是很好的学习资源，重新认识Agent。

1.main.tsx

“前期投入，后期回报”的过程。提前准备好任务所需的内容——CLI参数，环境变量，tools，命令......

同时对于REPL（Read-Eval-Print-Loop）工程，claude在此前已经准备好了state，tools，api......

2.QueryEngine

QueryEngine是一个核心引擎。重新定义了 Agent "不再是简单调用tool，而是整个闭环的工作流"

它不是一次请求，而是不断存在在整个会话任务中。所以，保留了很多任务状态信息，history_memory，tools，skills......

如果说QueryEngine是一个loop，那submitMessage()就是一个agent run的过程。

submitMessage()调用了前期预热的信息，完成整个闭环过程。

QueryEngine 不是简单地“把工具借给模型”，而是在负责整个闭环编排。

在这种闭环下，claude可以对任务中的 bug 进行定位处理。

3.prompt engineer

在claude code中，其不是一大段的prompt，是分层装配的。Claude Code 的 prompt 不是“写一段厉害的话”，而是“把不同职责的提示词放到不同层，再按运行时状态拼起来”。

system prompt，是由环境信息，语言风格，角色约束等动态拼接而成。同时允许用户追加信息及覆盖内容。

在多 Agent 协作模式下，Claude Code 还会给 teammate 附加专属说明，用于Agent之间相互工作

tool的prompt，用于去表示tool的使用，参数输入，什么时候调用tool等。

还有众多不同配件中的prompt，用于去分层配合。大家可以自行去看看。

4.Tool

claude code不是简单调用一个工具函数，调用工具的过程中，外挂了很多运行时的资源。

tools.ts中存在很多工具，file_tools,bash_tools,web_tools等。值得注意的一点，claude code能够去挑选工具的使用。工具集是可配置、可裁剪的；模型看到的工具集不一定等于代码里存在的工具集。

5.Slash Commands

工具系统是给模型调用；命令系统为人的显示调用

我们要考虑的是，为什么cc要有人的交互/由人决定的命令系统？

我们希望任务层面是由模型去处理，管理层面由人能控制，所以应保留命令面，而不是让模型去猜是启动哪个模式，及权限控制等。

6.上下文

有git状态的处理，仓库的分支，提交状态等

在上下文中，对仓库中的文件进行提炼，注入重要内容——>CLAUDE.md

压缩机制，准备了多层处理。

工具结果的裁剪，因为tool_call返回的是一大段终端信息，如果这类结果不先处理，后面的压缩就会被低价值大文本拖累。同时再经过上面的处理......（主要内容大家可以去自行了解）

总的来说，cc对上下文的处理是先保留原结构，再压缩，再处理。

“保留结构”在这里的核心含义是：不把不同来源、不同性质的信息抹平成一坨自然语言，而是保留它们各自的边界、类型和可操作形态。

所以，“保留结构”不是一种修辞，而是一套精密的取舍策略：
宁可丢弃连续的文本细节，也要保住信息的类型边界、任务状态机和关键引用的骨架。 这正是它能支撑长时间、多文件、多步工程任务，而不至于在接近上下文窗口时突然“变傻”的根本原因。

7.文件的操作能力

对文件的操作在cc中是基础的能力，但不把文件能力当成附加功能，而是当成默认运行时的核心组件。

读/写文件是不同的操作，有不同的考虑。

修改时，cc强调可解释/可展示/可控制。

8.Bash_Tool

有了file_tool，cc能对文件/代码进行读写。但有了bash_tool，能真正使cc的结果得到落地，真正工程话。

但Shell的能力太强，直接控制电脑的操作系统，需要去约束。

学习资源：学习 Claude Code | Claude Code源码学习专题

我也是学习者，文章用于学习记录，大家多多参考上面的链接学习，写的非常好！