------从"会用"到"用好"，掌握 Agent 的思维模型
上篇：底层机制再精炼
前面已经拆解过 Agent 的核心循环，这里提炼出六个影响实际使用的关键机制，每一个都会直接影响你的使用效果。
机制一：增量规划，不是一次性全规划
Agent 不会在任务开始时就把 20 步全列出来。
实际行为：先规划前 3-5 步 → 执行 → 观察结果 → 再规划后续步骤。
对你的影响：
· 你不需要把任务描述得事无巨细，Agent 会自己逐步细化
· 但如果关键约束不在一开始说清楚，Agent 可能在错误方向上走了好几步才发现
最佳实践：开头说清楚"目标 + 硬约束"，细节让 Agent 自己探索。
机制二：上下文窗口是稀缺资源
Claude 有 20 万 token 上下文，听起来很大，但 Agent 模式下消耗极快：
· 每次工具调用的输入输出都占空间
· 文件内容、命令结果、Skills 指令全在里面
· 多轮对话越长，留给推理的空间越少
当上下文接近上限时，Agent 会启动分层压缩（热区/温区/冷区），但这会导致：
· 早期细节被摘要化，精度下降
· Agent 可能"忘记"你在对话开头说过的小要求
最佳实践：
· 长任务拆成多个会话，每个会话一个明确子目标
· 中途发现 Agent 开始忽略早期指令 → 重新强调，或开新会话
机制三：权限确认不是阻碍，是指挥机会
Agent 每次写文件、跑命令前都会弹确认。很多人一路点"批准"，这就浪费了一个重要机制。
确认弹窗其实给了你三个操作空间：
-
批准：这步没问题，继续
-
拒绝：方向错了，Agent 会重新规划
-
修改：告诉 Agent 具体哪里不对，它会在修改后的框架内继续
最佳实践：前几步密集关注，确认方向正确；后续可适当放宽。一开始就错，后面全错。
机制四：错误重试有上限，且策略固定
Agent 会自动纠错，但：
· 重试次数有限（通常 3-5 次）
· 每次重试会换策略，但如果连续失败且根因相同，Agent 会停下来求助
· 它不会无限循环，也不会"换个模型试试"
最佳实践：
· Agent 求助时，不要只点"继续"，先看报错日志
· 给它一个新的方向或约束，比让它盲目重试有效 10 倍
· 例如：不说"再试试"，说"这个报错可能是 Node 版本问题，检查一下"
机制五：Skills 和 MCP 在 Agent 运行时是动态加载的
不是"启动时加载完就固定了"：
· 任务开始时匹配一批 Skill
· 执行中发现新需求，动态补充加载
· 上下文不够时，低优先级 Skill 被自动卸载
这对你的影响：如果你发现 Agent 在执行某个子任务时表现得不够专业，可能是相关 Skill 没被匹配上。
最佳实践：
· 复杂任务可以在指令里显式点名要用的 Skill
· 例如："用 TypeScript 迁移规范 skill 来重构这个项目"
· 定期检查 claude skills list，看看当前加载了哪些
机制六：Agent 有"惯性"，方向偏了会越偏越远
Agent 的核心循环是"规划→执行→观察"，问题在于：
如果早期某一步的观察结论是错误的，后续规划都基于这个错误结论，形成"错误滚雪球"。
例如：Agent 分析项目结构时误判了框架版本，后续所有迁移方案都基于错误版本。
最佳实践：
· 关键决策点手动验证：Agent 判断"这个项目用的是 Express 4.x"时，自己去 package.json 看一眼
· 如果发现 Agent 开始做出奇怪的决策，往前翻几步，检查是不是某一步的观察结论有问题
· 及时纠正，不要让错误滚大
下篇：使用最佳实践
基于以上机制，提炼出可操作的实践指南。
实践一：任务描述的结构化公式
坏的描述：
"帮我把这个项目改一下"
好的描述：
"把这个 Express 项目重构成 Fastify。约束：保持所有 API 路径不变、保留现有的中间件逻辑、不要改数据库层。先分析项目结构给我看，然后一个一个文件改，每改 5 个文件跑一次测试。"
公式：目标 + 硬约束 + 执行策略（可选）
要素 作用 示例
目标 告诉 Agent 要达成什么 "重构成 Fastify"
硬约束 防止 Agent 跑偏 "API 路径不变"、"不要改数据库"
执行策略 控制节奏 "每改 5 个文件跑一次测试"
实践二：长任务的分段策略
不要试图在一个会话里完成"重构整个项目 + 写测试 + 写文档"。
分段原则：
-
每个会话一个独立可验证的子目标
-
会话之间你手动确认成果
-
新会话带上关键上下文摘要
示例：
· 会话 1："分析项目结构，生成重构方案，不要改代码"
· 会话 2："按方案迁移路由层，每 5 个文件跑一次测试"
· 会话 3："迁移中间件层，保持所有现有测试通过"
· 会话 4："更新文档，基于最终代码生成"
实践三：关键节点的主动验证
Agent 最脆弱的环节是观察阶段------它可能读错文件、误判结果、遗漏重要信息。
你需要主动验证的节点：
· ✅ 项目结构分析完成后 → 自己看一眼，确认框架、版本、依赖判断正确
· ✅ 第一批文件修改完成后 → 跑一下测试，确认没挂
· ✅ Agent 说"搞定了" → 自己 review 改动，别直接交差
· ✅ Agent 说"这错误是因为 XXX" → 验证这个根因判断对不对
实践四：纠错的艺术
当 Agent 跑偏时，不同回应方式效果天差地别：
你说什么 Agent 的理解 效果
"继续" 当前方案没问题，再来一次 ❌ 浪费次数
"不对" 结果不对，但不知道为什么 ⚠️ 可能换错方向
"这个文件不应该改，因为它是第三方库" 明确错误点 + 原因 ✅ 精准修正
"停下来，检查 Node 版本" 先诊断再继续 ✅ 避免盲目
原则：给原因，不给结论。给方向，不给方案。
让 Agent 自己推理出修正方案，比直接告诉它答案更好------它能把这个修正逻辑应用到后续所有类似情况。
实践五：Skills 的管理策略
少即是多：不是 Skill 装得越多越好。
· Skill 太多 → 上下文被大量 Skill 指令占据 → 留给任务的推理空间变少
· Skill 之间可能冲突 → Agent 频繁询问你选择哪个
推荐策略：
· 安装项目级 Skill（和当前项目直接相关的）
· 不要装全局通用 Skill（除非你真的每天用）
· 定期清理不用的 Skill
· 用 claude skills list 看当前加载了什么，用 claude skills disable xxx 临时关掉
实践六：MCP 的边界意识
MCP 给了 Agent 强大的外部能力，但也有风险：
不要同时给 Agent 太多 MCP 工具：
· 工具列表太长，Agent 选择困难，可能选错工具
· 不同 MCP 服务器的操作可能互相干扰
推荐做法：
· 按任务类型启用 MCP：做数据库任务才连数据库 MCP，做前端调试才连浏览器 MCP
· 敏感操作（删数据库记录、发消息）的 MCP，加确认步骤
· 测试 MCP 服务器时，先用只读操作验证，别一上来就给写权限
实践七：建立自己的 CLAUDE.md
Claude Code 会自动读取项目根目录的 CLAUDE.md 文件，作为持久化约束。
这是一个被低估的超级能力。你可以在里面写：
```markdown
CLAUDE.md
项目约束
-
这是一个 monorepo，每个 package 独立
-
使用 pnpm 作为包管理器，不要用 npm 或 yarn
-
Node 版本 >= 18
代码规范
-
所有函数必须加 JSDoc 注释
-
用 TypeScript 严格模式
-
错误处理使用 Result 类型，不要抛异常
测试要求
-
修改任何源码文件后，跑对应的测试
-
测试命令：pnpm test --filter <package>
禁止事项
-
不要修改 /packages/database 下的 schema 文件
-
不要升级第三方依赖，除非明确要求
```
这比每次任务都重复说一遍约束高效得多。
实践八：理解 Agent 最适合的任务类型
Agent 不是万能的，它的能力有清晰边界：
✅ 适合 Agent 的任务：
· 有明确目标和验收标准
· 可以分解成多个步骤
· 主要操作文件、代码、命令
· 你具备验证结果的能力
❌ 不适合 Agent 的任务：
· 目标模糊，需要大量主观判断（"让这个设计更好看"）
· 需要你逐步教学（不如直接用 Cursor 手动写）
· 一次性的简单操作（杀鸡用牛刀，Agent 的规划开销比任务本身还大）
· 依赖你的私有知识且没写在 CLAUDE.md 里
总结：Agent 使用的心智模型
把 Agent 当成一个能力很强但不了解你项目背景的新同事：
-
交代清楚目标和约束（别让他猜）
-
前几步盯紧点（确认方向对）
-
关键决策你自己验证（他有他的盲区）
-
出错时给方向不给答案（他需要学会自己修正）
-
长任务分段（别让他一口气干完，中间你会失控）
-
善用 CLAUDE.md（把你的项目知识持久化）
如果你想进一步了解某个具体场景的最佳实践（比如如何用 Agent 做代码审查、如何配置 MCP + Skills 自动化工作流），可以继续展开。