VibeCoder Primer
§ B4·AI 实践4 prompts

Agent 与 Coding Agent

Agent = 一个能「感知 → 决策 → 行动 → 观察 → 再决策」的循环系统。*不是*一个会聊天的模型，而是*会调用工具完成任务*的系统。

← AI 划重点·← Prev · 上下文工程：填满窗口的工程学·Next · Embedding 与 RAG 原理 →
先读这部分
§ B4

Agent 与 Coding Agent

Agent = 一个能「感知 → 决策 → 行动 → 观察 → 再决策」的循环系统。*不是*一个会聊天的模型，而是*会调用工具完成任务*的系统。

核心循环与主流范式

每个 Agent 的核心循环都一样：拼上下文 → 调模型 → 模型说要调工具 → 执行工具 → 结果回填 → 再调模型 → 重复。

  • ReAct（Reason + Act）， 模型生成「思考 + 工具调用 + 观察」循环往复。绝大多数 Coding Agent 的底座。
  • Plan-Execute。先让模型出完整计划，用户确认后再分步执行。Cline、Claude Code 的 Plan Mode 是这种。
  • Multi-Agent。主 Agent 把子任务派给子 Agent，每个子 Agent 有独立上下文，最后汇总。Claude Code 的 Task tool 是这种。
  • Reflection。Agent 跑完自己审一遍，发现问题再修。
主流 Coding Agent 工具（2026）
  • Claude Code（Anthropic）， 终端原生、AGENTS.md/CLAUDE.md 配置、MCP 全套支持、Subagents + Routines。
  • Codex CLI（OpenAI）， 终端原生、kernel 级 sandbox（Seatbelt / Landlock / seccomp）、Apache 2.0 开源。
  • Cursor（Anytsphere）， VS Code 改的桌面应用、Background Agents、Composer 多模型编排。
  • Cline / Aider / Continue。开源 VS Code / 终端 / IDE 扩展的代表。

选哪个：solo 偏终端 → Claude Code；偏 IDE → Cursor；安全/审计导向 → Codex CLI。

工具调用的工程
  • 工具描述（tool schema）= 模型的「用户手册」，写得越清楚模型用得越准。
  • 工具结果（tool result）要 token-efficient。， 只返回模型做下一步决定需要的信息，别把 1MB 的日志塞回去。
  • 错误处理：工具调用失败时让模型能看到错误并重试，不要把错误吞掉。
想做 Agent 系统工程师再看
Claude Code 内部架构（queryLoop、5 层 compaction、27 种 hook event、permission system 7 种模式）值得读一遍源码。关键论文：ReAct、Reflexion、AutoGPT、BabyAGI、Anthropic 的《Building effective agents》。
动手做 · 提示词卡

把这段知识变成一段可执行的练习

以下 4 张卡，每张都是一段可复制的提示词。打开 Claude Code（或任何 LLM 终端），把卡里的提示词粘进去，AI 会陪你完成这一步。遇到不会的概念，把 AI 的回答贴回 卡里继续问下一步。可以一次做完，也可以分几次。

2 操作1 决策1 概念
Prompt 01操作★★★

Plan Mode 跑 3 步任务

为什么要学重要任务先让 AI 出计划你审, 比直接执行安全 10 倍——避免它'自作主张'改坏东西。
打个比方像让装修工先出图纸, 你签字他才砸墙, 不然他砸完你说不好看。
VibeCoder 场景你让 AI 改 README, 它顺手把你 git config 改了——开 Plan Mode 后它会先问。

在 Claude Code Plan Mode 里跑一个 3 步真实任务：读项目 README.md → 找出 TODO 列表 → 在 README 末尾加 1 段 'How to contribute'。让用户审计划再执行。

前置装好 Claude Code 或支持 Plan Mode 的 Agent
  1. 01开 1 个测试项目（任意 git 仓库）
  2. 02进入 Plan Mode（Shift+Tab 在 Claude Code）
  3. 03审 AI 出的 3 步计划
  4. 04批准 → 观察执行
  5. 05验收：README 是否真的改了、commit 是否合理
粘贴到 Claude Code（或任何 LLM 终端）Claude Code Plan Mode 体验最稳
进入 Plan Mode。请按以下 3 步规划，再等我确认再执行：\n1) 读 ./README.md，提取现有的 TODO 列表（如果存在）\n2) 找出 1 个适合在 README 末尾加的段落主题（建议 'How to contribute'）\n3) 在 README 末尾追加这个段落，commit 时跳过（用 --no-verify 之外的合理方案）
✓ 完成判据计划先出 → 用户审 → 执行，3 步全部成功，README 修改正确。
坑Plan Mode 适合需要'先想清楚再动手'的任务；小任务（如改 1 行）直接执行更快，Plan 反而拖慢节奏。
参考B4 § Plan-Execute
Prompt 02操作★★★

Subagent 派子任务

为什么要学主对话塞太多任务会污染上下文, 子 Agent 独立上下文 = 干净分工。
打个比方像公司分部门——财务不掺和销售, 各管各的, 最后总经理汇总。
VibeCoder 场景你让 AI 审 1 万行代码, 看到第 3 千行它'忘了'前面——子 Agent 分审干净利落。

在 Claude Code 里用 Task 工具派 3 个子 Agent 并行：分别审代码风格 / 审安全 / 审测试覆盖；每个子 Agent 独立上下文；主对话汇总。

前置Claude Code + Task 工具可用 · 有 1 个 5K+ 行的真实代码项目
  1. 01选 1 个真实项目（5K+ 行）
  2. 02起 3 子任务（注意 Task 工具的并行配置）
  3. 03看每个子任务的独立上下文（不应互相干扰）
  4. 04主对话收 3 份报告并合并
  5. 05你检查：3 角度是否都覆盖、汇总是否真合并而非简单拼接
粘贴到 Claude Code（或任何 LLM 终端）Claude Code Task 工具
请起 3 个并行的子任务（用 Task tool）：\n- 子任务 1：审计 src/ 下的代码风格（命名、注释、错误处理）\n- 子任务 2：审计安全问题（注入、硬编码密钥、权限）\n- 子任务 3：审计测试覆盖（每个模块是否有对应测试）\n\n每子任务独立上下文，不要互相依赖；完成后把 3 份报告汇总成 1 份。
✓ 完成判据3 个子任务并行执行；汇总报告覆盖所有 3 个角度，不是简单拼接。
坑子任务不能调子任务（递归限制）；不要派'小到不需要独立上下文'的任务——那只是给主对话加噪音。
参考B4 § Multi-Agent
Prompt 03概念★★★

ReAct vs Plan-Execute 对比

为什么要学任务模糊用 ReAct, 任务明确用 Plan-Execute, 选错模式浪费 3 倍 token。
打个比方ReAct 像边想边走迷宫, Plan-Execute 像先看地图再走。
VibeCoder 场景你让 AI'去 GitHub 找 5 个 issue 提建议', Plan-Execute 一遍过; 模糊任务用 ReAct。

选 1 个多步任务（如'在 GitHub 找 5 个 issue、读最新 3 条、给每条提修复建议'），分别用 ReAct（直接执行）和 Plan-Execute（先计划）跑一遍，对比 step 数、工具调用次数、最终质量。

前置有 1 个多步工具调用任务可跑
  1. 01选 1 个有 ≥5 个 issue 的 GitHub repo
  2. 02ReAct 模式跑一遍：直接调工具、推理、调工具
  3. 03Plan-Execute 跑一遍：先看计划、改计划、批准、执行
  4. 04记 step 数、工具调用次数、最终质量（你盲评）
  5. 05出对比表：哪种模式适合哪种任务
粘贴到 Claude Code（或任何 LLM 终端）
任务：在我的 GitHub repo [owner/repo] 找 5 个最近打开的 issue，读最新 3 条评论，给每条写 1 段修复建议。\n\n请按以下 2 种模式各跑一次：\nA) ReAct 模式：直接调工具，按需推理\nB) Plan-Execute 模式：先出完整计划，我审后再执行
✓ 完成判据明确判断出 2 模式各自的适用场景（ReAct 适合探索性、Plan-Execute 适合明确任务）。
坑Plan-Execute 在任务明确时赢（避免走弯路）；模糊探索性任务反而绕弯（计划本身需要 ReAct 来生成）。
参考B4 § 主流范式
Prompt 04决策★★★

工具调错看自纠

为什么要学工具错误被吞是 90% Agent bug 来源, 你必须知道错误是否对模型可见。
打个比方像医生误诊, 但病历本被撕了, 下一位医生以为'没事'——错必须传下去。
VibeCoder 场景你让 AI 读 README, 它说'读完了'——其实工具报错被吞了, 它读的是空文件。

故意让 AI 用错工具——给 Agent 5 个工具定义，其中 1 个名字拼错（如 git_sttaus）；看 AI 调用出错后能否在 ≤2 步内自纠。

前置能自己写 / 改 tool schema
  1. 01准备 5 个工具的 schema（其中 1 个名字故意拼错）
  2. 02让 AI 跑任务
  3. 03观察 AI 调用失败后的下一步：自纠 / 假装成功 / 卡住
  4. 04记自纠步数 + 错误可见性
  5. 05写 1 段你对自己 tool schema 的改进建议
粘贴到 Claude Code（或任何 LLM 终端）
你拥有以下 5 个工具：git_status、git_diff、git_log、git_sttaus（注意拼错）、read_file。\n任务：列出当前 git 状态、查看最近 3 条 commit、读 README.md。\n\n如果某次工具调用失败，请在下一轮重试或换用其他工具；不要假装调用成功。
✓ 完成判据Agent 在 ≤2 步内自我纠正；错误信息对模型可见（没被 framework 吞）。
坑实际工程里'工具错误被吞'是 90% Agent bug 的来源——framework 把错误吃了，模型看到的是'工具返回空'，就以为任务完成。必须让模型看到原始错误。
参考B4 § 工具调用的工程
← 返回 AI 划重点回到首页 →