​

Claude Code

​

1.Claude Code概述

​

1.1 什么是 Claude Code

​

1.2 Claude Code 能做什么

• 根据自然语言需求从零生成完整项目代码
• 读取、修改、重构现有代码文件
• 执行终端命令(安装依赖、运行测试、启动服务器等)
• 调用 MCP 外部工具(连接 Figma、GitHub、数据库、Slack 等第三方服务)
• 构建并自动执行复杂的多步骤自动化工作流
• 并发运行多个子任务(SubAgent 并行处理)
• 自我修复：遇到错误时能分析原因、修改代码、重新测试

想完整了解实现过程，参考视频：Master 95% of Claude Code in 36 Minutes 视频以这个 YouTube 周报自动化项目为主线，从界面安装到部署上线全程实操演示

​

1.3 访问方式

• Claude-CLI：在终端直接执行 claude 命令启动，这是 Claude Code 的核心使用方式。它不依赖 IDE，适合项目开发、脚本自动化、服务器环境和长任务执行
• Claude-App：通过 Claude 桌面端或网页端使用，更适合日常对话、资料整理、轻量代码问答和多模态输入，但不适合作为主力工程执行环境
• IDE-Plugins：嵌入到 VS Code、Cursor 等编辑器中使用，优点是和代码编辑窗口结合紧密，适合边写边问；但自动化能力、终端控制和跨项目任务编排不如 CLI 直接

​

1.4 收费标准

​

1.5 中国区安装

​

2. 核心特性与用法

​

2.1 CLAUDE.md

• 在 Claude Code 对话中输入 /init，它会根据当前项目自动生成一份 CLAUDE.md
• 输入 /memory 可以快速打开并编辑 CLAUDE.md
• 分为项目级(放在项目目录，对该项目生效)和用户级(放在用户目录，对所有项目生效)
• 内容可以包括：编码规范、项目结构说明、注意事项(比如“每次回答结尾都追加 Happy Coding”)、技术栈偏好等

# 项目规范
- 使用 React + TypeScript + Vite 技术栈
- 所有组件必须有对应的单元测试
- 禁止在代码中硬编码任何 API Key
- 提交代码前必须运行 lint 检查

.claude/rules/
├─ security.md       # 安全规则：不能硬编码密钥，要验证输入
├─ coding-style.md   # 代码风格：不可变性、模块化
├─ testing.md        # 测试规则：TDD 流程、80% 覆盖率
├─ git-workflow.md   # Git 规范：提交格式、PR 流程
└─ agents.md         # 何时委托给 SubAgent

​

2.2 三种交互模式

​

2.3 Checkpoints

• 输入 /rewind 或连续按两次 ESC 进入回滚界面
• 选择要回滚的时间点后，有四个选项：回滚代码+会话、只回滚会话、只回滚代码、放弃回滚
• 也可直接输入 /checkpoints 查看文件级别的回滚点

​

2.4 权限管理

​

2.5 Plan Mode

​

2.6 Hooks

​

2.7 MCP

​

2.8 Skills (Agent Skill)

• 全局：~/.claude/skills/(对所有项目生效)
• 项目：项目目录下的 .claude/skills/

• 自动触发：Claude 识别到请求与某个 Skill 相关时，自动请求用户确认加载
• 手动触发：在输入框中输入 /技能名称 直接调用

---
name: daily-report
description: 当用户要求写每日总结时调用此技能
---
日报格式要求、日期
- 开发摘要（不超过3条）
- 开发详情（每条需包含：实现内容、遇到的问题、解决方案）
- 明日计划

​

2.9 SubAgent

• Agent Skill 适合：与主上下文关联紧密，不会产生大量中间数据的任务(如“写一份今日开发总结”)
• SubAgent 适合：需要大量探索，会产生海量中间上下文的任务(如“审查整个代码库的安全漏洞”)

​

2.10 Plugins

​

2.11 上下文管理

​

2.12 斜杠命令

• /init — 自动生成当前项目的 CLAUDE.md
• /memory — 快速打开 CLAUDE.md 编辑
• /compact — 手动压缩上下文
• /clear — 清空所有上下文
• /context — 查看上下文用量
• /rewind — 进入代码回滚界面
• /checkpoints — 查看文件级回滚点
• /resume — 恢复历史对话
• /tasks — 查看后台任务
• /mcp — 查看和管理 MCP 工具
• /hooks — 配置 Hook
• /skills — 查看已安装的 Skill
• /agent — 创建和管理 SubAgent
• /plugin — 插件管理器
• /permissions — 权限管理
• /fork — 分叉当前会话，用于并行执行不重叠的任务
• /rename — 重命名当前会话
• /insights — 生成个人 Claude Code 使用分析报告
• /statusline — 自定义状态栏显示内容

​

2.13 Insights

这个是最近(2026.3月)面试喜欢考的一个特性

• 你使用 Claude Code 的典型模式和习惯
• 做得好的地方(Impressive Things)
• 哪些地方在阻碍你的效率(Where Things Go Wrong)
• 值得尝试的新功能和使用模式
• 工作流自动化建议

​

3. 最佳实践经验

​

3.1 项目初始化必做三件事

security.md       # 安全规则：不能硬编码密钥，要验证输入
coding-style.md   # 代码风格：不可变性、模块化
testing.md        # 测试规则：TDD 流程、80% 覆盖率
git-workflow.md   # Git 规范：提交格式、PR 流程
agents.md         # 何时委托给 SubAgent

​

3.2 先规划，再执行(Plan Mode 优先)

• 修改了错误的文件
• 产生大量无用的中间 Token 消耗
• 后期难以回滚

​

3.3 控制上下文,定期”清理”

• 关闭不需要的 MCP：即使安装了 20-30 个 MCP，也只保持少于 10 个处于启用状态，活跃工具不超过 80 个。过多的 MCP 工具描述会占用大量上下文，200k 的窗口可能只剩 70k 可用
• 在完成一个大阶段任务后，手动执行 /compact 压缩，保留关键决策，释放空间
• 开始全新任务前用 /clear 完全清空，避免旧上下文干扰
• 用 /context 定期检查上下文用量，在自动压缩前主动手动压缩以获得更好的控制效果

​

3.4 跨会话记忆持久化

# 按上下文切换不同的记忆文件
alias claude-dev='claude --system-prompt "$(ca

​

3.5 SubAgent 模式提升效率

• 实例一(Scaffolding Agent)：负责搭建项目骨架、建立 CLAUDE.md 和 Rules
• 实例二(Research Agent)：负责调研技术选型、生成详细需求文档(PRD)、绘制架构图

第一阶段：用 Explore 子Agent做代码调研 -> 输出 `research-summary.md`
第二阶段：用 Planner 子Agent制定计划 -> 输出 `plan.md`
第三阶段：用 TDD-Guide 子Agent实现代码 -> 输出代码变更
第四阶段：用 Code-Reviewer 子Agent审查 -> 输出 `review-comments.md`
第五阶段：如有构建错误，用 Build-Error-Resolver -> 循环直到通过

​

3.6 Token 优化策略

• 代码库探索、文件搜索 → Haiku(速度快、成本低，够用)
• 单文件改动 → Haiku
• 多文件实现 → Sonnet(编程任务最优平衡)
• 复杂架构设计 → Opus(深度推理)
• 安全漏洞分析 → Opus(不允许遗漏)
• PR 审查 → Sonnet
• 写文档 → Haiku

​

3.7 有效的提示与沟通技巧

• 把需求当作给团队成员写 SOP： 越具体越好，包含目标、输入、输出、边界条件
• WAT 框架(Workflows-Agent-Tools)：将任务分为工作流(markdown SOP)、代理(负责任协调)、工具(Python 脚本执行具体操作)三层，分离概率性 AI 推理和确定性代码执行
• 不要只描述目标，还要描述你的顾虑：在让 Claude 部署代码前，说“先做安全审查，确保 API Key 没有暴露，然后再告诉我部署方案”
• 反复出现的提示应该变成 Skill：如果你发现自己多次给 Claude 相同的指令，就应该把它写成 Skill 文件，让 Claude 自动加载
• Ctrl+G 打开 VSCode 编辑器输入框：当在终端输入框里需要多行复杂提示时，按 Ctrl+G 打开 VSCode 编辑，方便多行修改，保存后自动回填

​

3.8 安全最佳实践

• 绝对不要将 API Key 硬编码进任何文件，应使用环境变量(.env 文件)或 Modal Secrets 等密钥管理服务
• **部署前主动要求安全审查：**让 Claude Code 检查代码中的漏洞，特别是 Webhook 是否有认证、Key 是否暴露
• **在 CLAUDE.md 中明确禁止规则：**如“禁止在代码中包含任何 API Key 或密码”
• **精确控制 SubAgent 的工具权限：**代码审查 SubAgent 只需只读工具，不应有写权限
• 使用沙盒模式测试可能影响系统的危险操作
• --dangerously-skip-permissions 意味着 Claude 拥有和你一样的终端权限，仅在受控的开发环境中使用

​

3.9 并行工作流

git worktree add ../feature-branch-a feature-a
git worktree add ../feature-branch-b feature-b
不同目录分别启动 Claude 实例

​

3.10 连续学习机制

​

4.ClaudeCode 源码解读 / 架构拆解

26年三月底，Claude Code 源码泄露。一经泄露，面试就成近期必考的问题。有同学反应面试官直接问他，Claude Code 代码泄露 2 天了？你还没看吗？所以对于这一部分，近期是非常重要的考点 另外其实除开最近热点事件外，学习 ClaudeCode 本身就是非常有帮助的，他本质是一个 CodingAgent。我们学习 Agent 可以分成三步：

1. 掌握了 Agent 的基础知识 .
2. 可以典型的 Agent 架构，比如笔记已经有的 Openclaw 架构分析，本期的 Claude Code 架构以及马上会出的字节的 Deerflow2.0 的 Agent 架构，建立审美。
3. 设计一个自己的 Agent 项目架构，写文档，用 Harness 工程来完成。

有了项目后，我们就可以面试了。所以学习经典的 Agent 架构是很有帮助的，本节就一起来学习这个经典的 CodingAgent - Claude Code

​

4.1 事件概述

​

4.1.1 怎么泄漏的

​

4.1.2 泄漏揭示了什么

• 核心架构： Query Loop、工具系统、System Prompt 分层设计、终端 UI 引擎
• 记忆与上下文： 多层记忆架构、5 级上下文压缩(Compaction)策略
• 安全与权限：** 权限模式、YOLO Classifier、Prompt Injection 防御
• 多 Agent 协作： 子代理模型(Fork / Teammate / Work Tree)、Coordinator Mode

• 未发布功能: 24/7 自主守护进程 Kairos、记忆整合的 Dream System、30 分钟深度规划 Ultra Plan、反蒸馏防御 Anti-Distillation、卧底模式 Undercover Mode 等
• 未发布模型: Capybara/Mythos(全新产品线)、Numbat(完全未知)、Opus 4.7 / 4.8 等下一代模型代号

​

4.1.3 社区反应

这里我们在笔记的 Harness Engineering 工程中，来讲解这个 Claw Code 开源项目。学习这个项目，可以进一步帮助理解 Harness 工程(无疑这个也是 26 年的高频考点)。你自己其实也可以更深入学习这个项目，自己仿照这个也来做一个 Claude Code，是一个很好的学习 Claude Code、Agent 的机会，同时也是一个练手 Harness 工程的机会。具体请看笔记的 Harness 工程的 Claw Code 讲解

​

4.2 记忆功能

其实大家看各种 Agent 的开源项目，每个 Agent 项目，我们都需要关注最重要的几个点，也是 Agent 项目的核心：比如记忆、架构、Agent 的交互对吧。所以不管看哪个 Agent 项目，都该特别解析关注这个记忆模块。我们在笔记的 openclaw 部分已经解析了小龙虾的记忆功能，今天我们来看 ClaudeCode 的记忆功能，二者对比，体会成熟的 Agent 项目的记忆功能背后的设计哲学

学习 Agent 的记忆模块的设计可以从这几个方面思考： 它由什么组成(4 种记忆存储)，以及它怎么运作(加载、压缩、写入三大策略)。我们笔记按这个思路来讲。下图是 Claude Code 记忆功能架构

​

4.2.1 四层记忆存储

指令文件其实在 CC 的核心用法就讲过，这里 Claude.md 系列文件的维护，需要人工维护的。

• 管理员全局：/etc/claude-code/CLAUDE.md —— IT 管理员设定的全局规则
• 用户全局：~/.claude/CLAUDE.md —— 个人偏好(跨项目生效)
• 项目级：CLAUDE.md、.claude/CLAUDE.md、.claude/rules/*.md —— 随 Git 提交，团队共享
• 本地私有：CLAUDE.local.md —— 不提交 Git，个人使用

就是大模型多轮对话的数组，每个 Agent 都有

这个就是随着每次会话记录的，Claude Code特有的设计

• /resume 恢复会话时，从这个文件快速恢复上下文，无需重新喂全部历史
• 上下文压缩时可作为摘要来源(见 3.1.3 第 3 层)
• /skillify 可以将其转化为可复用的 SKILL.md 文件

• user：用户角色、偏好、技能水平。例：“偏好函数式风格”、“是后端工程师”
• feedback：用户对 AI 的纠正和确认。例：“上次用 forEach 被要求改成 map”
• project：项目目标、决策、截止日期。例：“Q3 要迁移到 TypeScript”
• reference：外部系统指针。例：“Bug tracker 在 Linear: xxx”

~/.claude/memory/
├─ MEMORY.md                ← 索引文件（每次会话自动加载）
├─ user_role.md             ← 主题文件：用户角色
├─ feedback_testing.md      ← 主题文件：测试相关反馈
├─ project_migration.md     ← 主题文件：迁移计划
└─ reference_tracker.md     ← 主题文件：外部系统指针

​

4.2.2 上下文组装

1. MEMORY.md 前 200 行每次会话自动加载到 system prompt
2. 用 Sonnet(非主力模型，不是主模型 Opus)扫描所有记忆文件的标题和 frontmatter 描述，选出最多 5 条最相关的，作为 relevant_memories 附注入上下文
3. 排除本次会话已召回过的记忆(避免重复)
4. 超过 1 天的记忆自动过期警告： “这条记忆是 N 天前的… 关于代码行为的声明可能已过时，请先验证。”
5. 会话总预算 60KB

​

4.2.3 压缩

压缩是 Agent 里面的一个核心技巧。怎么样压缩保证模型能记住最重要的东西，直接影响接下来对话的好坏。我们可以看到 Claude Code 的压缩策略其实非常复杂，是用心在设计的

第1层 Tool Result Budget  ← 每轮都跑，限制单条消息体积
第2层 Microcompact        ← 清理旧工具结果内容
第3层 Auto-compact        ← 触发 LLM 做全量摘要（核心层）
第4层 Blocking Limit      ← 硬拒绝：上面都压不下来就报错
第5层 Reactive Compact    ← API 返回 413 后的兜底重试

第一层是为了压缩工具，如果工具调用结果返回内容太多，就只给索引，按需加载。有点像 Skill 的思想，渐进式披露

这一层设计就是为了清理工具。多轮调用后，工具的结果会一直跟随在上下文中(没压缩前)。这里要解决的核心就是适当处理过期的工具调用结果

1. 基于时间的 Microcompact： 如果距上次助手回复超过 60 分钟(缓存 TTL 已自然过期)，直接将旧的工具结果内容替换为 [Old tool result content cleared]，只保留最近 5 条 适用的工具类型： Read、Bash、Grep、Glob、WebSearch、WebFetch、Edit、Write 因为缓存已经失效，直接改内容不会有额外损失。
2. 基于缓存编辑的 Microcompact(Anthropic 内部)： 客户端消息完全不改，而是额外发一条 cache_edits 指令，告诉服务端“在你缓存的副本里删掉这些工具结果” 这样 prompt 前缀不变，缓存继续有效，省钱 客户端本地的消息数组保持完整(用于 session 持久化、resume 等)，但模型实际看到的上下文已经被浓缩了

上面两层都是在上下文窗口还没有很大的时候就尝试压缩，这是 Claude Code 的巧思。很多 Agent 都是在上下文快满了才压缩，包括 openclaw。第三步，自动压缩也就是所有 Agent 都会做的，窗口满了，一定要压缩的策略。

有效窗口 = 200,000 - min(maxOutputTokens, 20,000) = 180,000
自动压缩阈值 = 180,000 - 13,000 = 167,000 tokens

1. Session Memory Compact(轻量)： 用已经由后台代理提取好的 Session Memory 文件作为摘要，保留最近 10K~40K tokens 的原始对话(至少保留 5 条含文本的消息)不需要额外的 LLM 调用，所以很便宜
2. Full LLM Compact(重量)： 把整段对话发给 LLM 做结构化摘要。摘要输出上限 20K tokens，包含 9 个固定段落：
   • 核心请求(Primary Request)
   • 关键概念(Key Concepts)
   • 涉及文件列表(Files)
   • 代码错误与修复(Errors)
   • 问题解决过程(Problem Solving)
   • 所有用户消息(User Messages)
   • 待办事项(Pending Tasks)
   • 当前工作(Current Work)
   • 下一步计划(Next Step)
3. 压缩后自动恢复文件上下文： 压缩会丢弃旧消息，但会话期间所有被读过、写过、编辑过的文件都记录在 readFileState 缓存中(包括 agent 调用 FileRead / FileEdit / FileWrite / Bash 工具操作的文件，以及 memdir 系统和 Sonnet 预取自动加载的记忆文件) 压缩完成后，系统会从这个缓存中排除 CLAUDE.md 和 Plan 文件(它们有各自的恢复机制)，再按最近访问时间排序，取最多 5 个文件从磁盘重新读取(不用旧缓存，确保内容是最新的)，以每文件 ≤5K tokens、总计 ≤50K tokens 的预算注入到压缩后的上下文中，让模型不需要在下一轮重新读取这些文件就能继续工作。如果会话中没有操作过任何文件，则不会恢复
4. 防御机制： 连续失败 3 次后触发熔断，不再尝试。如果压缩调用本身也报 prompt-too-long，会从最旧的消息开始截断，最多重试 3 次

这里我们不妨把两个架构的压缩策略对比

下图是 Claude Code 的压缩策略 vs Openclaw 的压缩策略

四五两层其实就比较简单，就是兜底策略。一个从客户端兜底，一个从服务端兜底。出现了问题，压缩后还是上下文爆炸，就直接给用户提示，用户可以手动来 /compact 来继续对话

​

4.2.4 记忆写入

1. extractMemories(持久记忆提取)： 在每次完整查询循环结束后(模型给出最终回复，没有更多工具要调用时)，由一个 Fork Agent 后台执行：

• 继承父对话的完整上下文，共享 prompt cache(不额外消耗 token)
• 严格权限沙箱：只能读文件 + 只能写记忆目录，不能执行 bash，不能调 MCP，不能启动子代理
• 高效的 2 轮模式：第 1 轮并行读所有需要更新的文件 -> 第 2 轮并行写所有有变更
• 有频率限制，不是每轮都跑

2. Session Memory 更新： 对话 token 超过 10K 后启动，之后每 5K tokens 由后台 Fork Agent 更新一次结构化笔记文件
3. AutoDream(记忆整合)—— “睡眠整理” 定期运行的后台代理，对持久记忆做整理、合并、去重、清理。灵感来自人类睡眠时整理白天记忆的过程。下图是 AutoDream 图片展示

1. 距上次整合 ≥ 24 小时(最先检查，成本最低，一次 stat 调用)
2. 距上次整合 ≥ 5 个会话
3. 获取 consolidation lock(PID 文件锁，防并发；超过 1 小时且 PID 已死则可回收)

• Orient：读取 MEMORY.md 索引，浏览现有主题文件，了解当前状态
• Gather：扫描每日日志和会话记录(JSONL)，窄范围 grep，不穷举
• Consolidate：新信息合并到现有主题文件，修复矛盾，相对日期转绝对日期
• Prune：保持 MEMORY.md ≤ 200 行，删除过时条目，精简冗长描述

*"You are performing a dream — a reflective pass over your memory files. Synthesize what you've learned recently into durable, well-organized memories so that future sessions can orient quickly."*

​

4.2.5 Claude Code vs OpenClaw：记忆设计思路对比

Claude Code 设计了 5 层压缩流水线，从温和到激进逐层升级 —— 先清理工具输出碎片、再考虑缓存优化、然后才做 LLM 摘要，最后硬拒绝和兜底。大部分情况下前两层（不需要 LLM 调用）就能把 token 压下来，真正的 LLM 压缩是中低频事件。这是一种用工程复杂度换成本效率的思路。

OpenClaw 只有一级压缩，但流程更精细：划分保留区（最近 ~20K tokens 原封不动）、压缩区分块逐块总结、多块摘要再合并成一个连贯总结。每次触发都需要 LLM 调用，成本更高，但实现简单、行为可预测

Claude Code 做了重度的写入自动化 —— 三个后台 Agent 分工：extractMemories 每轮结束后自动提取持久记忆，Session Memory 持续维护会话笔记，AutoDream 定期整合去重。用户不需要主动“存档”，系统自动帮你把重要信息沉淀下来

OpenClaw 更依赖显式写入。它的文档反复强调一个常见失误：聊天中说的指令不会自动保存到文件 —— 不写入文件就会被压缩丢掉。作为补偿，OpenClaw 在压缩前有一个 Pre-Compaction Memory Flush —— 静默提醒 Agent 把重要内容写入记忆文件。但这本质上是“事到临头才保存”，而 Claude Code 是“一直在保存”

Claude Code 是系统层面硬编码的 push 模式——每轮对话前，系统必定用 Sonnet（轻量小模型）扫一遍所有记忆文件的标题和描述，挑出最相关的几条，直接塞进上下文。主模型开始思考时，相关记忆已经摆在眼前了，不需要它主动去找。类比：秘书在你开会前，把相关资料提前放在桌上。代价是每轮都要占固定的上下文空间，不管用不用得上。

OpenClaw 是 pull 模式——系统不会提前塞记忆，而是把 `memory_search` 作为一个普通工具暴露给模型。模型在推理过程中自己判断“这轮要不要查记忆”，跟它决定要不要调 `bash`、要不要读文件是一样的逻辑。更灵活省空间，但风险在于模型不知道自己不知道什么——比如你上周说过“我讨厌 forEach”，这条记忆存在文件里了，但今天聊到循环时模型可能根本没想到要去搜“用户的代码风格偏好”，就直接写了 forEach。Push 模式下这条记忆会被小模型提前捞出来，就不会犯这个错。

​

4.3 Agent架构

​

4.3.1 中心化星型拓扑

        ┌───────┐
        │ 用户  │
        └───────┘
            │
            ↕
    ┌────────────────┐
    │   主 Agent     │  ← 唯一的中央控制节点
    │ (Query Loop)   │
    └────────────────┘
       ↙     ↓     ↘
      ↗      ↑      ↙
 ┌────────┐ ┌────────┐ ┌────────┐
 │子代理A │ │子代理B │ │子代理C │
 └────────┘ └────────┘ └────────┘
        X   互不通信   X

​

4.3.2 为什么选中心化？

其实架构这个事情上，你很难说谁对谁错，为什么 CC 选择中心化，不选择去中心化。这些理论是我自己分析，结合我们之前学习的笔记、论文来分析的。这里没有标准答案，谁对谁错，但是我希望大家是可以一步步去理解，去思考。你自己想清楚了，觉得合理了，那么就可以和面试官去探讨，沟通，这是一个开放性问题 所以我希望大家还是有一些自己的思考。特别是对于 Agent 的架构设计这块，本身比较难。包括面试要是问你设计一个系统架构，都是比较难的。但是通过我们八股、论文，以及我们现在已经看了两个 Agent 架构了，大家理解了以后去分析、去消化，慢慢地建立自己地思考。建立了自己的想法的时候，在面试中有东西说，在设计自己项目架构的时候，也知道怎么设计，设计得更复杂。而不是让 AI 生成一个最普通的架构，你也没有任何的修改意见

• Coding 是工具密集 + 顺序推理场景：论文指出单体基线 >=45% 时，盲目加多 Agent 反而因协调减效。Claude Code 的核心就是单体 Query Loop，只在需要并行时才派生子代理
• 中心化控制错误放大：独立多体错误放大 17.2 倍，中心化只有 4.4 倍——coding 场景下错误扩散代价极高，必须有统一收敛点
• 去中心化通信开销 O(D·N²) 不划算：论文只在高熵、路径不唯一的场景观测到去中心化优势，coding 工作流结构化、路径确定，不适用。所谓“高熵”，就是完成任务的正确路径不唯一、信息分散、需要探索的场景。动态网页导航就是典型例子：要找某公司的碳排放数据，可以查官网、查媒体报道、查监管机构，信息散布在不同来源，没有一条确定的标准路径，每个 Agent 独立探索一个方向然后互相校验反而更高效。相反，coding 是低熵的——“读代码 -> 改代码 -> 跑测试”的路径是固定的，不需要多个 Agent 去“探索”不同的编码路径然后辩论哪个更好
• 匹配“可拆分 + 统一验收”场景：主 Agent 拆解任务、分派子代理、统一验收，和笔记中 Orchestrator 模式的描述完全一致

​

4.3.3 运行机制

用户输入
↓
组装 System Prompt（CLAUDE.md + 记忆 + 工具定义 + 权限规则）
↓
┌→ 调用 LLM API
│   ↓
│   模型返回：
│   ├─ 纯文本 → 输出给用户，循环结束
│   └─ 工具调用（模型自主选择）
│       │
│       ├─ Bash / Read / Write / Grep / Glob ...  ← 普通工具：直接执行
│       │   │
│       │   └→ 返回结果追加到上下文
│       │
│       └─ Agent 工具（也是普通工具之一）        ← 特殊之处：结果来自另一个循环
│           │
│           └→ 派生子代理（Fork / Teammate / WorkTree）
│               │
│               └→ 子代理启动自己的 Query Loop  ← 递归：内核完全相同
│               |    ├─ 调用 LLM API
│               |    ├─ 调用普通工具（但不能再派生子代理）
│               |    └─ 输出最终文本
│               └→ 子代理的输出作为这次工具调用的返回值
│
└── 带着工具结果继续问模型（无论结果来自普通工具还是子代理）

while (true) {
  1. 把当前消息发给模型 → 拿到模型的回复
  2. 检查回复里有没有 tool_use block
     - 有 → needsFollowUp = true → 执行这些工具 → 把工具结果拼回消息 → continue（回到第 1 步）
     - 没有 → needsFollowUp = false → break，循环结束
}

type AgentToolInput = {
  prompt: string              // 任务描述
  description: string         // 3-5 字简述
  subagent_type?: string      // 省略 -> Fork; 指定 -> 特定子代理
  name?: string               // 提供 name + team_name -> Teammate
  team_name?: string
  isolation?: 'worktree'      // 提供 -> WorkTree 隔离
  model?: 'sonnet' | 'opus' | 'haiku'
  run_in_background?: boolean
}

Fork yourself (omit subagent_type) when the intermediate tool output isn’t worth keeping in your context. The criterion is qualitative — “will I need this output again” — not task size.

• Research: fork open-ended questions. If research can be broken into independent questions, launch parallel forks in one message. A fork beats a fresh subagent for this — it inherits context and shares your cache.
• Implementation: prefer to fork implementation work that requires more than a couple of edits.

希望大家可以对比着去理解。我们看了两个架构，Openclaw 和 CC 都是用的主 Agent 来使用工具调用的方法，来 fork 子 Agent，不同的 Agent 形式由工具参数决定。这是一致的。不一致的地方，是对于子 Agent 的形式，有一些不同，也就是工具的参数。大家看了本章，在设计自己的架构的时候，可以参考这一套。但是思考一下你的场景中的子 Agent 需要是什么形式，有哪些 type，是起一个新的进程还是作为 subagent 合适？

​

4.3.4 Agent通信

Agent 之间如何通信，其实也是面试官喜欢考的。所以在解析 Agent 架构的时候，我都会注重这一点，包括 Openclaw。但是拆解了两个架构后，其实我们发现，这些出名的架构，Agent 通信也不会特别复杂，比如 A2A 啊。相反，他们都是主 Agent 生成子 Agent，而子 Agent 之间不交互，只是把结果交给主 Agent。背后的思想其实省去 Agent 之间的通信，一定会减少各种开销和难度，成熟的架构都这么设计，我们也可以这么设计，也不用担心自己没有复杂的 Agent 通信是不是就意味着项目浅

主 Agent 上下文窗口
│
├─ 调用 Agent 工具 -> prompt 作为"下行消息" -> 子代理 A
│                                               │
│         子代理 A 的返回值作为"上行消息" <────────┘
│
├─ 调用 Agent 工具 -> prompt 作为"下行消息" -> 子代理 B
│                                               │
│         子代理 B 的返回值作为"上行消息" <────────┘
│
└─ 主 Agent 拿到 A 和 B 的结果后，在自己的上下文中综合处理

• 下行通信(主 -> 子)： 通过 Agent 工具调用的 prompt 参数。主 Agent 必须在这个 prompt 中放入子代理完成任务所需的全部信息，因为子代理看不到其他任何上下文
• 上行通信(子 -> 主)： 子代理 query loop 结束时的最终文本输出，作为工具调用的返回值传回主 Agent 的上下文
• 横向通信(子 ↔ 子)： 不存在。如果子代理 A 的结果需要被子代理 B 使用，唯一的路径是：A 的结果先返回主 Agent，主 Agent 把 A 的结果写进 B 的 prompt 里，再派生 B

​

4.3.5 与 Agent 通信理论的呼应

这一节我是专门加的，我们在 Agent Theory 中，学习了理论部分。我想让大家看看，其实我们学到理论，都是没问题的，主流 Agent 框架用的就是我们学的东西。希望通过这一节，大家能够让理论对应实践，相互呼应，有更深入的理解

这几个问题是我之前面试被问到过的，我以这个举例子，告诉大家我们学的东西其实都面试考的。而且你学完了，都是直接对你面试有帮助的。没学这个小节之前，面试官问你 Agent 如何通信，当然你可以回答理论部分。学了以后，加入了 CC 和 Openclaw，一定回答得更好了。所以很多问题的答案，是在我们学习的过程，不断总结提炼出更好的答案的

Agent Theory 快速测试(面试原题)： 如果 Agent 之间通信，某些东西不想给另一个 Agent 看到，应该怎么做？ 笔记里给的答案方向是“仅共享最终结果”。现在结合 Claude Code 和 OpenClaw 的源码实践，面试时可以更具体地这么回答：

采用“仅共享最终结果”的消息传递策略。每个子 Agent 拥有独立的上下文空间，所有中间推理过程——包括中间的工具调用链、思维链——都留在子 Agent 的私有空间里，执行完成后只把最终结论提取出来返回给父 Agent，父 Agent 看不到任何中间步骤。这样做的好处有两个：

一是隐私隔离，某个子 Agent 的中间数据不会泄露给其他 Agent；

二是控制上下文膨胀，如果把所有中间步骤都传回去，父 Agent 的上下文窗口会快速撑满。

这个策略在实际项目中是主流做法，比如 Claude Code 的子代理只返回纯文本结果，OpenClaw 的子 Agent 也是只把蒸馏后的最终回复推送给父 Agent。

面试时可以从三个层面回答：

一.架构选型：
我们采用中心化架构，一个主 Agent 作为编排者，通过工具调用的方式委派任务给子 Agent。选择中心化而非去中心化的原因是，对话场景天然是“一进一出”的结构——用户发一条消息，最终要有一条连贯的回复，必须有且只有一个 Agent 对最终输出负责。中心化的星型拓扑正好对应这个模型：主 Agent 是唯一的回复责任人。

二.通信模式：
使用工具调用而非移交。主 Agent 保留控制权，把子任务作为参数发给子 Agent，等结果回来后自己整合决策。子 Agent 之间不直接通信，如果 A 的结果需要被 B 使用，必须由主 Agent 中转——先拿到 A 的结果，再把相关信息写进 B 的任务描述中。

三.消息内容：
仅传递最终结果，不传递中间推理链。子 Agent 在自己的独立上下文中完成全部推理和工具调用，只把最终结论返回给主 Agent。这样既保护了各 Agent 的中间数据隐私，也有效控制了主 Agent 的上下文膨胀。

​

4.4 权限系统与安全审查

学习 ClaudeCode 的权限处理，除了应对面试官问你 CC 权限系统是如何设计的这个问题(有朋友被问过)。另外你也可以应对面试官问你 Agent 安全相关的问题，比如如何避免 Agent 乱调用工具对系统产生破坏。除此之外也希望大家学会了本节，在设计自己 Agent 项目的时候可以在 Agent 的权限系统 / 安全上进行设计，会让自己的项目更加有深度，不被置疑是玩具项目。最后学了本节，其实你在使用 ClaudeCode 不同模式的时候，其实也可以知道里面的运行原理。

​

4.4.1 总览：四层权限管道

当主 AI 请求执行任何操作时，都要依次经过四层安全过滤。每一层都可以直接做出“放行”或“拒绝”的终审判决，只有当本层说“我没意见”时，请求才会继续流入下一层

确定性高 -----------------------------------------------> 确定性低

第一层                第二层                第三层                第四层
规则过滤              工具自检              模式兜底              AI 分类器
──────               ──────               ──────               ──────
纯配置匹配            代码逻辑判断          策略分流              AI 推理判断
← 零成本 →            ← 零成本 →            ← 零成本 →            ← 额外 API 调用 →

​

4.4.2 第一层：规则过滤

这一层我在使用 github copilot 的时候也有，大家有没有注意到在使用 copilot 的时候，如果有一个工具，他让你点击 approve，下面有选项(是否 always approve)，如果你点了是，其实就在对应 copilot 的配置文件(json)中把这个命令设置为 allow，下次执行相同内容就不会再 approve 了。 这个方法是 CodingAgent 的通用技巧，设置规则，下次直接按照规则命中。

{
  "permissions": {
    "allow": [
      "Bash(ls *)",        // 允许所有 ls 命令
      "Bash(mkdir:*)",     // 允许所有 mkdir 命令
      "Bash(python:*)"     // 允许所有 python 命令
    ],
    "deny": [
      "Bash(rm -rf:*)"     // 禁止所有 rm -rf 命令
    ]
  }
}

这些细节也不用强行记住，就是给大家看一下，重要的是这个思路，具体细节面试问的少。

​

4.4.3 第二层：工具自检

• Bash 工具：检查命令本身是否属于高风险操作
• Write/Edit 工具：检查目标文件路径是否合法
• 安全路径检查：.git/、.claude/ 等关键目录有特殊保护 —— 即使在 bypass 模式下也不能跳过，源码注释称之为 “bypass-immune”(免疫 bypass)

• 拒绝：终审，直接拒绝操作
• 放行：终审，直接通过
• 无意见：不做判断，流入下一层

​

4.4.4 第三层：模式兜底

设置模式。这个大家在使用 CC 的时候相比有印象。在 CLI 下方有：acceptEdits on 等提示。学习了本节你更会理解在不同的模式下的预期行为。 大家可能困惑为啥自己使用 CC 切换不到某种模式。要注意的是，里面有一些模式，比如 bypassPermissions 是要通过命令行参数启动的，dontAsk 并不可用(只是源码里有)，auto 是需要使用 feature flag 才能开启的。

​

4.4.5 第四层：AI分类器(动态审查)

这一层就是有一个分类器，也就是使用 AI 最后来判断，是否允许还是拒绝还是人工 approve。只不过这一层也有策略，先固定规则跑 - AI 弱分类(省 Token)- AI 强分类 - 错误处理兜底。所以这就是企业项目和自己做的项目的区别。大家自己做，用 AI 分类，可能就调用个 API 写个提示词就完了，但是企业项目是用了多层的调用。看了这些架构我们也应该有意识对齐，当然自己做项目肯定不如企业项目复杂，但是我们可以尽量设计地更复杂，更稳健，让面试官觉得我们的项目并不简单

1. 安全工具白名单： Read、Grep、Glob、Sleep、TodoWrite 等完全无副作用的工具，直接放行，无需分类器审查。设计原则是——只有零副作用的工具才进白名单，Write、Edit、Bash 这些有副作用的工具一律不在。
2. 工作目录内的编辑： 如果操作是在项目目录内编辑文件(模拟 acceptEdits 行为)，也直接放行。

Stage 1：快速粗筛（64 token，偏保守）
提示词要求 "Err on the side of blocking"（宁可错拦，不可漏放）
│
├─ 判断为安全 -> ✅ 直接放行（完成）
│                 大部分安全操作在这里就结束了
│
├─ 判断为危险 -> 进入 Stage 2
└─ 无法判断   -> 进入 Stage 2
                 │
                 ▼

Stage 2：深度精筛（4096 token，带推理链）
要求 AI 先写下推理过程，再给结论
│
├─ 判断为安全 -> ✅ 放行（翻案成功）
├─ 判断为危险 -> ❌ 阻止
└─ 无法判断   -> ❌ 阻止（安全优先）

​

4.4.6 设计思想

1. 这套权限系统直接关联笔 Agent 安全设计 章节 和 Agent 通信安全章节。如果面试中被问到“Agent 项目怎么做安全控制”，可以从这三个层面回答：多层防御(不靠单点) -> Fail Closed(不确定就拒绝) -> 防注入(从信息流源头过滤，分类器只看工具调用，不看模型文本输出
2. 与 OpenClaw 的对比也值得一提：OpenClaw 用规则 + 沙箱实现安全，没有独立 AI 审查；Claude Code 用独立 AI 分类器理解上下文做判断，更安全但成本更高。两者代表了“静态规则 vs 动态 AI 审查”两种安全哲学

​

4.5 成本追踪与速率限制

• 你的 Agent 如何控制成本？
• 如何监控每次调用和每个会话的成本？
• 如何防止用户一次任务把 token 预算打爆？
• 如果用户快被限流了，你的系统怎么提前感知？

• 限制速率：回答“按当前消耗速度，还能不能继续调 API”。它关注账号配额、时间窗口、配额消耗速度、限流状态，以及限流后的处理策略。
• 限制花费：回答“这次以及这个会话消耗了多少”。它关注 token 用量、模型单价、缓存读写成本、单次查询预算，以及会话级累计。 这两条线合在一起，构成 Claude Code 的成本闭环：前者防止用户把账号配额用爆，后者防止一次会话或一次查询无节制地消耗 token。

1. 面试回答思路：当面试官问“Agent 如何做成本控制”时，可以从速率限制、实时计费、缓存成本、预算保护、会话持久化几个角度系统回答。当面试官问你，如何防止 Agent 进入无线循环、无限消耗TOKEN时，我们也能够借助今天的问题有一个回答。我也会结合今天的知识，总结一些常见的面试问题。
2. 项目设计启发：首先我们要有一个意识，就是我们在做自己的Agent项目的时候，需要考虑成本模块。所以你最好能够在你的项目中设计出一个模块专门负责成本控制的。另一方面成本控制模块也可以从两个方面，比如设计两个类。一类专门统计速率，按照现在的消耗，是否需要限速，需要提示消耗过多，及时提醒？第二个类统计花费，持久化每一次请求工作的Token消耗，并从输入、输出、缓存读写、网页搜索、模型维度等方面去统计。这些就是看完本篇给我们的启示。

​

4.5.1 总览：两条成本控制路线

API 响应返回 
├─ 路线一：限制速率（当前配额消耗速度是否正常） 
│ ├─ 输入：服务端返回的配额/限流信号 
│ ├─ 处理：解析多时间窗口配额 + 判断消耗速度 
│ ├─ 状态：汇总成统一的配额状态 
│ └─ 输出：限流状态、提前预警、额外用量/升级/等待策略、企业策略限制 
│ 
└─ 路线二：限制花费（这次到底消耗了多少） 
	├─ 输入：usage token/tool 计数 
	├─ 处理：按模型价格把 usage 换算成费用 
	├─ 状态：费用累加到会话状态 + 按模型统计 
	└─ 输出：会话成本累计、Token Budget、保存/恢复

1. 速率 / 配额问题：用户的订阅或账号额度是不是快被服务端限制了？如果快被限制，系统如何提前知道？如果已经被拒绝，系统如何决定下一步？
2. 花费 / 账单问题：本次调用用了多少 token？按当前模型价格折算多少钱？这个会话累计花了多少？单次查询有没有继续跑下去的必要？

项目启发：做 Agent 成本控制时，不要只设计一个“费用统计器”。更合理的拆法是：一个模块负责配额/速率状态，一个模块负责 token/费用累计。两者数据源不同、处理逻辑不同、触发的保护动作也不同

​

4.5.2 路线一：限制速率

API 调用完成 
	↓ 
读取服务端配额信号 
	↓ 
整理成统一的配额状态 
	↓ 
按照短期 / 长期 / 模型等维度判断风险 
	↓ 
判断当前消耗速度是正常还是偏快 
	↓ 
如果按当前速度可能提前耗尽：提前预警 
	↓ 
如果已经被限制：给出等待、加额度、升级、组织协作等处理策略 
	↓ 
企业策略再做一层能力管控

1. API 调用后读取服务端配额信号 Claude Code 不靠客户端自己猜“用户还能不能继续用”。每次 API 调用之后，服务端都会把当前账号的配额状态返回给客户端。客户端要先读到这些信号，才能知道当前请求到底处于哪种状态：

• 还能正常继续调用；
• 已经接近某个额度上限；
• 已经被服务端限制；
• 虽然基础额度不足，但可能还有额外用量、升级或等待恢复等路径。 这一层解决的是“信息来源”问题：配额状态必须以服务端判断为准，而不是客户端自己估算。 因为真正决定能不能继续调用的，是服务端的账号、订阅、组织和额度系统。

2. 把零散信号整理成统一状态 读到配额信号以后，Claude Code 不会让上层业务到处自己判断，而是先把它们整理成统一的配额状态。这个状态只需要回答三个问题：

• 当前是否可用：还能不能继续调用。
• 风险在哪里：是短期额度、长期额度，还是某类高价模型额度有风险。
• 下一步怎么办：继续、提醒、等待、申请额度、升级，还是换一种执行策略。 这一步很关键。因为后面的提前预警、限流处理、任务调度，都不应该直接面对一堆底层信号，而应该面对一个统一状态。否则每个模块都会写一套判断逻辑，最后很容易不一致。

3. 多个维度判断配额消耗速度 有了统一状态以后，Claude Code 会继续判断“当前消耗速度是否合理”。它不是只看一个“总额度”，而是把配额拆成多个维度：

4. 如果消耗速度偏快，就提前预警 如果服务端还没有真正拒绝请求，但系统发现消耗速度过快，就会进入提前预警。这里的判断逻辑不是只看“用了多少”，而是看“用掉这些额度时，时间才过去了多少”。 核心思想是：使用率高 + 时间还早 = 消耗过快。 同样是用掉一部分额度，如果发生在周期刚开始，说明后面很可能会提前耗尽；如果发生在周期快结束，就不一定危险。 所以提前预警做的是中间层保护：它不是直接阻止用户，也不是等到服务端拒绝才处理，而是在“还能用，但按当前速度会提前耗尽”的阶段提醒用户调整节奏
5. 如果已经被限流，就给出下一步策略 如果请求已经被服务端限制，Claude Code 也不是简单报错退出，而是把“不能继续”进一步翻译成“接下来能做什么”。常见处理路径包括：

• 等待恢复：告诉用户什么时候可以继续，避免无意义重试
• 增加额度：如果账号支持额外用量，引导用户进入额外用量路径
• 升级计划：如果当前套餐额度不够，引导用户升级
• 组织协作：如果是团队或企业账号，可能需要管理员开通额度或调整组织策略
• 调整任务：降低任务规模、换低价模型、拆分任务，减少继续撞限流的概率 这里的产品价值是：系统不仅知道“不能继续”，还知道“为什么不能继续”以及“下一步怎么继续”。这比简单返回一个错误码更符合 Agent 产品的使用场景。

6. 企业策略做更高层的能力管控 最后，Claude Code 还会叠加一层企业策略。它和 API 配额不是同一层问题：配额回答“额度够不够”，企业策略回答“组织允不允许” 比如企业可能允许普通对话，但限制远程执行、外部工具、高价模型或敏感数据相关能力。这类策略一般需要服务端统一配置、客户端本地缓存、定期刷新，并且在策略服务不可用时有明确的降级原则：普通能力可以尽量不阻塞，合规或敏感能力则应该更保守 小结：这一条速率路线的核心特点可以概括成四个词：
   1. 服务端可信：能不能继续调用，以服务端配额状态为准。
   2. 状态统一：不要到处散落判断，先汇总成统一配额状态。
   3. 分层判断：短期、长期、模型、额外用量分开看，判断当前消耗速度是否偏快。
   4. 可执行处理：预警和限流都要给出下一步，而不是只报错。

项目启发：做自己的 Agent 时，可以把速率控制设计成一个独立的 Rate Limit Manager。它负责读取服务商配额信号、归一化状态、多维度判断消耗速度、触发预警、处理真正限流，并和组织策略联动。这样任务调度、重试、降级、提醒都会围绕同一条流程展开，而不是散落在各个模块里。

​

4.5.3 路线二：限制花费

API 调用完成 
	↓ 
读取本次调用的 usage 
	↓ 
拆成输入、输出、缓存、工具等账单项 
	↓ 
按模型价格换算成本 
	↓ 
累加到会话级成本状态 
	↓ 
用 Token Budget 判断单次查询是否值得继续 
	↓ 
把会话成本保存下来，下一次恢复

1. API 调用后读取 usage 花费路线的起点，是每次模型调用结束后拿到本次调用的 usage。这里的 usage 不只是一个“总 token 数”，而是成本计算的原始账单数据。 从 Claude Code 的统计口径看，它关心的不是“这次一共用了多少 token”这么粗的数字，而是会把 usage 拆成几类消耗来源：

2. 把 usage 拆成可计费的账单项 读到 usage 之后，Claude Code 会把一次调用拆成多个账单项，而不是只记录一个 token 总数：

项目启发：我们自己做项目时，不能只说“我要统计 token”，还要说清楚统计哪些 token(比如输入，输出，Tool, SKILL)等、按什么维度聚合、最后要回答什么成本问题

3. 按模型价格换算成真实成本 有了账单项之后，Claude Code 会结合模型价格，把 token、缓存和搜索消耗换算成金额。这里要注意两点： 第一，不同模型价格不同。同样的 token 数，用在便宜模型和高价模型上，最终成本可能完全不同。所以成本计算必须带上模型维度，不能只看 token 总数。 第二，缓存也要进入成本模型。缓存写入通常更像一次“前期投入”，后续缓存读取才是“节省成本”。所以 Prompt Cache 不能只当作性能优化，它本身也是成本模型的一部分。 完整公式不需要记具体数字，只要抓住一个原则：

总费用 = 输入成本 + 输出成本 + 缓存写入成本 + 缓存读取成本 + 搜索等额外成本。 如果遇到未知模型，也应该有默认估算和异常记录，避免成本计算直接断掉。

4. 累加到会话级成本状态 单次调用算完以后，费用不会只停留在这一轮请求里，而是会累加到会话状态。Claude Code 这里有一个很重要的设计：它不是只维护一个总费用，而是按模型维护一份 usage 汇总 也就是说，每个模型都会有自己的结构化账单，大致包括：

会话级追踪: 
├─ 总费用 
├─ 总输入 / 输出 token 
├─ 缓存读取 / 缓存写入 token 
├─ 网页搜索次数 
├─ 工具耗时 
├─ API 调用耗时和重试成本 
├─ 代码修改规模 
└─ 按模型分类的使用量

5. 用 Token Budget 判断单次查询是否值得继续 会话级累计解决的是“已经花了多少”，但还不够。Agent 最大的问题是：一次任务可能不断续跑、不断调用工具、不断扩上下文，最后在用户没注意的时候消耗大量 token 所以 Claude Code 还有单次查询级别的预算管理。它不只是看“有没有超过上限”，还会看“继续跑有没有收益”：
   • 如果预算还比较充足，而且本轮输出仍然有明显增量，就允许继续。
   • 如果已经接近预算上限，就停止继续消耗。
   • 如果连续几轮输出增量都很低，说明进入收益递减，也应该停止。 这一步的关键是：成本控制不能只看上限，还要看收益。 如果模型已经在原地打转，哪怕还没完全用完预算，也应该及时停下来，让用户重新确认方向。

这里对我们也是一个很好的启示。也就是我们怎么防止Agent无限调用。我们知道我们讲的ClaudeCode也好，Openclaw也好，它内部用了ReAct是自己在循环中思考，推理的。所以如何防止他无限调用呢？设置最大此处我觉得大家都可以想到吧，但是看到这里，我们的有了新的思路：可以从预算以及输出增量的角度，前者从成本上控制，后者从收益上控制是否需要继续迭代。我也会将这个思路总结到后面面试题目中

6. 保存并恢复会话成本

1. 账单结构化：每次调用都拆成输入、输出、缓存、工具、模型等账单项。
2. 价格模型化：不同模型、缓存读写、网页搜索等额外消耗要进入同一套成本公式
3. 会话可观测：成本要按会话、模型、工具、任务类型累计，而不是只记总数
4. 预算可中断：单次任务不仅看是否超预算，还要看继续运行是否还有收益

项目启发：做自己的 Agent 时，可以把花费控制设计成一个独立的 Cost Manager：它负责采集 usage、拆账单项、换算费用、按会话累计、判断单次任务是否值得继续，并把成本状态持久化。这样成本控制就不只是日志，而是能参与任务停止、模型选择、缓存优化和后续分析的产品能力。

​

4.5.4 设计思想总结

限制速率：控制“按当前速度还能用多久” 
	- 多时间窗口配额 
	- 配额消耗速度判断 
	- 提前预警
	- 限流后的升级 / 额外用量 / 等待策略 
	- 企业策略限制
	  
限制花费：控制“已经消耗了多少” 
	- usage 实时计费
	- 模型定价表 
	- Prompt Cache 读写成本 
	- 会话级累计 
	- Token Budget 
	- 会话费用持久化与恢复

• 速率路线更像“配额消耗速度保护”：判断用户按当前速度会不会提前撞上限流墙
• 花费路线更像“账单保护”：防止一次调用、一次会话、一次查询无节制地消耗

1. 先分两条线：限制速率 + 限制花费，不要混在一起讲。
2. 限制速率：服务端给出配额状态，客户端结合时间窗口判断消耗速度是否偏快，提前预警，并在限流后提供升级 / 额外用量 / 等待策略。
3. 限制花费：每次 API 调用后用 usage + 模型定价表算成本，包含 Prompt Cache 和网页搜索等额外成本，按会话 / 模型累计。
4. 加预算控制：单次查询 Token Budget、会话级累计、会话持久化恢复。
5. 企业管控：团队或企业场景下，还可以通过组织策略远程禁用特定能力。

​

4.5.5 成本控制面试问题

​

5. 面试问答

​

6. 参考资料