上一篇把工具系统当成 Claude Code 的执行层来看。工具让 agent 有了行动能力：它可以读文件、搜代码、改内容、跑命令、拿到验证结果。但工具一旦能接触真实项目，新的问题马上出现：模型为什么知道自己该怎样使用这些工具、遵守哪些项目规则、用什么方式和用户协作？这篇就接着看 Prompt System。我现在更愿意把它叫作“行为协议层”。

文章摘要： Claude Code 的工具系统是连接模型意图与真实项目的执行层，负责将“读文件”“改代码”等动作转化为受控操作。其核心流程包括参数检查、权限判断、执行动作和结果封装，确保每一步可追溯。工具分为三类风险等级：只读观察、写入修改和命令执行，支持并行调用以提升效率。工具协议需明确描述、输入、风险和输出格式，便于模型选择与系统调度。结果需结构化（如diff、退出码、错误类型）以支撑主循环的

文章摘要： Claude Code 的工具系统是连接模型意图与真实项目的执行层，负责将“读文件”“改代码”等动作转化为受控操作。其核心流程包括参数检查、权限判断、执行动作和结果封装，确保每一步可追溯。工具分为三类风险等级：只读观察、写入修改和命令执行，支持并行调用以提升效率。工具协议需明确描述、输入、风险和输出格式，便于模型选择与系统调度。结果需结构化（如diff、退出码、错误类型）以支撑主循环的

上一篇先把 Claude Code 放回工程系统里看。它更像一个能进入仓库、观察环境、调用工具、处理风险、验证结果的 coding agent。沿着这个角度往下拆，第一条主线就是 Agent Loop。工具、上下文、提示词、计划、权限、恢复、多 agent，后面都会单独讲。但这些模块最后都要挂到同一条运行链路上：用户给出一个目标以后，Claude Code 如何一轮一轮地观察、判断、行动、接收反馈

这个系列写完以后，我希望得到一套理解 coding agent 的工程框架。它的主循环是什么？它有哪些基础工具？它如何组织提示词和项目规则？它如何管理记忆和上下文？它如何规划任务并维护状态？它如何处理权限和安全？它如何记录执行轨迹？它如何从失败中恢复？它如何扩展到外部工作流？它什么时候需要多 agent？这些问题能帮助我把一个产品拆回工程系统。