理解 AI Agent 的关键，不是只看模型强不强，而是同时看它拿到了什么材料、用了什么工具、愿意查多深，以及有没有清晰的工作边界。
AI Agent 的效果，不是单纯由“模型聪不聪明”决定，而是由多个变量共同决定。
| AI 概念 | 类比 | 决定什么 |
|---|---|---|
| Model 模型 | 你请了什么水平的人 | 能力上限、知识和经验 |
| Context 上下文 | 你给他看的材料 | 他这次知道哪些具体情况 |
| Prompt 指令 | 你安排的任务 | 他要完成什么 |
| Tools 工具 | 电脑、数据库、浏览器、命令行 | 他能采取哪些行动 |
| Effort 努力程度 | 给他多少时间、要求查多细 | 看多少文件、检查多少次、做多少步骤 |
| Output Tokens | 他的思考、操作和汇报 | 实际消耗的工作量 |
当你在 Claude Code 里输入任务，系统会把很多内容一起打包给模型，而不是只发送你当前输入的一句话。
这里的“上下文”，就是 Claude 这次工作时能看到的所有材料。
把项目背景、代码、文档、CLAUDE.md 放进去，不等于模型永久学会了这些内容。它只是这次任务临时拿到了这些材料。
像专家长期积累的能力和经验。训练后固定，决定模型的能力上限。
像这次递给专家看的项目资料。只影响本次任务，不会永久改变模型。
| 类型 | 类比 | 是否长期保留 |
|---|---|---|
| 模型权重 | 专家的长期经验 | 是，训练后固定 |
| 上下文 | 这次给专家看的项目资料 | 否，只影响本次任务 |
| CLAUDE.md | 每次开工前递给专家的项目说明书 | 文件长期存在，但模型不是永久学会 |
| 对话历史 | 当前会议记录 | 只在当前上下文窗口内有效 |
模型并不是直接看懂人类眼中的完整文字页面。文字会先被拆成 token，再映射成数字 ID。模型真正处理的是一串数字序列。
示意：数字不用死记。重点是理解“文字会变成 token 序列”，模型后续处理的是这些 token 对应的数字表示。
模型不是一次性生成完整答案，而是不断基于已有 token 序列预测下一个 token。
这看起来像“预测下一个词”，但不是简单文字接龙。预测背后依赖的是模型训练中形成的大量模式：编程语言、框架用法、常见 bug、代码结构、业务逻辑和问题解决路径。
模型使用时，权重是固定的。prompt、上下文、CLAUDE.md 都不会改变它的权重。
如果模型见过很多类似的 API 模式，它可能根据模式生成一个看起来合理、但实际不存在的 API。
这不是“查询数据库失败”，而是模型根据训练中见过的模式，生成了一个看起来合理的 token 序列。
普通聊天更多是“用户提问 → 模型回答”。Claude Code 更像一个循环。
| 输出类型 | 说明 |
|---|---|
| Thinking | 中间推理、计划、判断 |
| Tool calls | 调用 Read、Edit、Bash 等工具 |
| Text to you | 给用户看的计划、进展和总结 |
当 Claude 后面开始写代码时，它前面的 reasoning 也会像读过的文件一样，成为后续输入的一部分。Agent 的上下文是动态增长的。
Effort 控制的是 Claude 对整个任务投入多少工作量，而不只是 thinking time。
更多文件读取、更多工具调用、更多验证、更多 token、更高成本、更长等待。
快速判断、更少验证、更早回来问你、成本更低、速度更快。
可以把不同模型理解成不同水平的人，把 effort 理解成他们愿意在任务上花多少时间。
面对极复杂、罕见、普通模型很难解决的问题。
适合复杂推理、架构判断、疑难问题和关键审查。
适合大多数日常开发、文档、代码和分析任务。
低 effort 的 Opus，就像你只请到专家 5 分钟。这个专家经验很强，能快速指出方向和风险，但不会完整审查。
强模型低 effort 不是没用，而是适合“快速判断方向”，不适合“完整交付”。
高 effort 会生成更多 token，读更多文件，使用更多工具，等待更久。
只是改一个小样式，强模型高 effort 可能会想得太多、改得太多。
如果业务背景不完整或错误，高 effort 可能基于错误上下文做出更复杂的推理。
批量整理、格式检查、清单核对，需要的是不漏项，不一定是高级判断。
| 任务类型 | 推荐组合 | 原因 |
|---|---|---|
| 改文案、改样式、小格式 | 小/中模型 + 默认 effort | 任务明确，风险低 |
| 按已有模式新增功能 | 中模型 + 默认或中等 effort | 需要理解项目，但不太复杂 |
| 复杂 bug、架构设计、权限、数据库 | 强模型 + 高 effort | 需要推理和验证 |
| 快速评审方案 | 强模型 + 低/默认 effort | 要专家直觉，不一定完整执行 |
| 批量检查、错别字、格式整理 | 中模型 + 高 effort + 清单 | 重点是不漏项 |
| 需求还没聊清楚 | 强模型/中模型 + 澄清流程 | 关键不是执行，而是先问清 |
不要一出错就问“是不是模型不行”。先判断是哪类问题。
| 问题表现 | 原因判断 | 应该调整 |
|---|---|---|
| 不知道项目背景、误解术语 | 上下文不足 | 补上下文 |
| 看了材料，但理不清复杂关系 | 能力不够 | 换强模型 |
| 没看相关文件、没跑测试 | 工作不够深入 | 提高 effort |
| 需求没问清就开始干 | 流程缺失 | 加需求澄清规则 |
| 改多了、乱跑 | 边界不清 | 限制执行范围 |
| 编造不存在的 API | 缺少真实依据 | 读文档、类型定义、测试 |
| 做得慢、成本高，但任务简单 | 配置过重 | 换小模型或降低 effort |
强模型 + 默认/中高 effort。
先阅读项目说明和交接文件，先判断任务复杂度，不要直接改代码。
中模型 + 默认 effort。
按确认方案执行，不要扩大范围，不要重构无关文件。
中模型 + 高 effort + 清单。
逐项检查，运行必要测试，记录检查结果。
强模型 + 高 effort。
停止继续修改，先做诊断，确认后再执行。
强模型低 effort 像专家快速会诊，方向可能很准，但不会完整审查。强模型高 effort 像专家深度介入，适合复杂问题，但成本更高，也需要边界。中小模型高 effort 像助理按清单认真干，适合重复、明确、不能漏的任务。