我第一次用 Claude Code 的时候还把它当成一个能在终端里聊天的代码助手贴一段报错问一句怎么改把答案复制回去再跑一遍。后来发现这完全是在浪费这个工具最值钱的部分。真正把 Claude Code 用出生产力的人早就不在一个 Session 里反复拉扯了他们玩的是多 Agent 编排、闭环自愈和 Routine 脚本化架构——让 Agent 自己开文件、改代码、跑测试、循环迭代直到全绿人只负责定目标和看结果。这篇文章我不打算从头科普 Claude Code 的每个命令而是直接拆解我最常用的一套工作流如何用 Subagent 做任务拆分、如何让 Agent 自己发现错误并修复验证、如何把高频操作固化成可复用的脚本化 Routine。同时会把安装配置、VSCode 接入、Mac/Ubuntu 上的环境搭建、以及通过 cc switch 这类工具切换 DeepSeek、Qwen、GLM 等第三方模型的实操经验一并讲清楚。无论你是刚装好 Claude Code 的新手还是已经用了一段时间但总觉得“差点意思”的老手这套内容应该都能帮你把效率再提一档。1. 先搞清楚一件事Claude Code 里的 Agent 到底是什么1.1 它不是一个聊天窗口而是一个“能动手的执行器”很多人对 Claude Code 的第一印象是“能在终端里聊天的 AI”。这个理解没有错但太浅了。网页版的 Claude 是“对话”而 Claude Code 是“执行”。它跑在本地终端里自带一套完整的工具Bash 命令执行、读写文件、代码检索、项目内搜索还能通过 MCP 接外部数据源。模型不只是“给建议”而是真的会动手改文件、跑命令、看输出、再根据输出决定下一步怎么走。我打个比方网页聊天像是你打电话给一个远程专家你负责替他看电脑屏幕、复述报错、再把他的指令敲进去而 Claude Code 是把这个专家直接请到你的电脑前让他自己开终端、翻代码、动手改改完还会自己验证一遍。区别就在这里——前者是“人肉搬运信息”后者是“Agent 闭环执行”。这也就解释了为什么同样一个模型在网页里聊和在 Claude Code 里用效果完全是两个量级。Claude Code 里的 Agent 能看到真实执行环境里的反馈测试跑挂了、编译报错了、lint 不通过这些信息会直接流回模型的上下文里成为下一步决策的依据。少了“人肉搬运”的信息损耗它判断问题的准确率高得多。1.2 为什么“单步聊天”是效率黑洞我刚开始用 Claude Code 的时候习惯还是改一点聊一点让它改一个函数、我去跑一下测试、把报错贴回来、它再改。这个循环的问题不在于慢而在于每轮对话都在丢弃和重建上下文。第一个痛点是上下文碎片化。你贴回去的报错信息是截断的、人工筛选过的可能漏掉了关键堆栈。模型看不到完整文件状态只能靠猜。第二个痛点是上下文无限膨胀。如果你用同一个 Session 连续干几件事这个 Session 会越来越长Token 消耗越来越大到后来模型连“自己最开始定的方案”都可能忘了回答质量急剧下降。第三个痛点是无法并行。单步聊天天然是串行的你一次只能处理一个问题但一个中型改动往往涉及多个文件、多个关联测试串行处理就是浪费时间。我见过不少人的用法是开一个 Session从头到尾一个人工陪着改全程自己跑测试、自己贴报错。本质上还是把 Agent 当高级补全工具用只是从“逐字补全”变成了“逐函数补全”。这种用法没有错但确实离“Agent 化”还很远。1.3 会话模型理解 Session、上下文管理与 Fork要让 Agent 高效工作必须先理解它的会话模型。Claude Code 的每一次交互都在一个 Session 里Session 里保存着系统提示、CLAUDE.md 项目约定、历史消息和工具调用记录。你可以把它理解成 Agent 的“工作记忆”。这个记忆是有限度的。上下文越长Token 成本越高模型的注意力也会被稀释。Claude Code 提供了一些管理手段最常用的是/compact把当前会话的历史消息压缩成摘要释放大量上下文空间。我通常在连续工作了十几轮之后手动触发一次或者让它自动在接近上限时压缩。另一个非常实用的功能是 Fork 分支会话。当 Agent 在某个任务上走偏了你不需要把整个 Session 清空重来而是可以从某一条消息开始分出一个新分支保留此前有价值的上下文丢弃后面的跑偏内容。对于长时间复杂任务这个功能能让方向纠偏的成本低很多。单步聊天模式里根本没有这种能力因为你的“上下文”根本不连续全在复制粘贴中散落了。2. 多 Agent 编排从单兵作战到小队协作2.1 什么时候需要 Subagent 登场Claude Code 支持 Subagent也就是子任务 Agent。主 Agent 可以把一个复杂任务拆成多个子任务交给不同的 Subagent 去处理。每个 Subagent 拥有独立的上下文窗口互不干扰完成后把结果交回主 Agent 汇总。为什么要这么做最直接的原因是上下文隔离。假设你要同时重构三个模块如果都在同一个 Session 里做三个模块的代码和问题描述会混在一起上下文很快就爆了而且改 A 模块时看到的上下文可能干扰对 B 模块的判断。拆成三个 Subagent 并行跑每个只关心自己模块的代码效率和质量都会高很多。我判断是否需要 Subagent 的标准很简单如果这个任务需要看的文件超过 5 个、需要修改的位置超过 3 处、或者需要并行做多组独立验证我就会考虑拆分。比如“给整个项目的所有 API 路由加统一的错误处理”“把旧的构建流程迁移到新的打包工具上”“审计并修复所有类型为any的隐患”这类活儿都是典型的 Subagent 场景。2.2 三种编排模式与适用场景我实际用下来多 Agent 编排最常见的模式有三种。第一种是 Manager-Worker 模式也就是“主管-工人”。主 Agent 扮演主管负责拆解任务、制定标准、派发子任务、收集结果、做最终整合。Subagent 扮演工人只负责执行具体的子任务不需要了解全局。这种模式适合需求明确、子任务边界清晰的场景。第二种是 Pipeline 流水线模式。上一个 Agent 的输出是下一个 Agent 的输入形成一条流水线。比如“先让 Agent A 梳理代码结构并产出一份改造方案再让 Agent B 根据方案实施改动最后让 Agent C 做审查并输出报告”。这种模式适合步骤间有先后依赖的任务每步专注一件事质量更可控。第三种是 Fan-out/Fan-in 并行发散再收敛模式。一个主任务被拆成多个完全独立的子任务并行执行完成后统一汇总。比如“分别让三个 Subagent 检查前端、后端、部署脚本的安全性最后主 Agent 汇总成一份安全报告”。这种模式最适合真实并行效率提升最明显。编排模式适用场景核心优势注意事项Manager-Worker子任务边界清晰、可并行职责分明、上下文隔离主 Agent 要做好验收和汇总Pipeline步骤间有顺序依赖单步专注、输出即时可查上游质量决定下游效果Fan-out/Fan-in多组独立检查或修改并行度高、效率提升大结果需要统一格式和标准2.3 落地配置主 Agent 与 Subagent 的分工Subagent 在 Claude Code 里不是抽象概念而是可以显式配置的。你可以在项目的.claude/agents/目录下定义自己的 Subagent每个文件就是一个 Agent 定义里面写明它的职责、擅长领域、可用工具和输出要求。举一个我常用的配置场景。我定义一个executorAgent职责是“按方案实施代码改动修改后必须运行指定测试并回报结果”再定义一个reviewerAgent职责是“审查 diff检查是否有遗漏、风格问题和潜在缺陷”。在主任务里我让主 Agent 规划方案让 executor 落地最后让 reviewer 交叉检查。这样做的好处是写代码和审代码的上下文是隔离的reviewer 不会因为自己在写代码而“手下留情”。配置文件一般长这样.claude/ ├── agents/ │ ├── executor.md │ └── reviewer.md ├── commands/ │ ├── review.md │ └── release.md └── hooks/ └── pre_tool_use.json每个 Agent 定义文件里我会写清楚角色定位、工作流程、输入输出格式和禁止做的事。比如 executor 的定义里特别强调“改完必须跑测试不能只改不验”。这一句话就让闭环自愈从“可选行为”变成了“明确定下的工作纪律”。2.4 编排时最容易踩的三个坑第一个坑是任务拆得太碎。有些任务本身很小拆成三四个 Subagent 以后光是在主 Agent 和子 Agent 之间传递上下文、对齐格式就要花不少成本。我的经验是如果这个任务 10 分钟内能做完别拆。拆分的收益边界大概是每个子任务能在一次上下文窗口内独立完成且不需要频繁向主 Agent 请示。第二个坑是没有统一的验收标准。Subagent 各自为政交回来的结果格式五花八门主 Agent 还得花时间转化。解决办法是在任务派发时就把输出格式写死比如“每个问题必须包含文件路径、行号、严重级别和建议改法”。第三个坑是结果没人交叉验证。多个 Subagent 并行改代码改完各说各的“改好了”但合并在一起可能互相冲突。所以主 Agent 在汇总后必须做一轮整体验证跑一遍全量测试、检查 diff 是否冲突。这个“最后一公里”不能省。3. 闭环自愈Agent 不再“说了就走”3.1 自愈闭环是什么闭环自愈不是 Claude Code 官方文档里的一个按钮而是一种工作流设计。它的核心思想是Agent 不能只负责“产出改动”还要负责“验证改动是否有效”如果无效就继续诊断和修复直到成功或达到某个阈值才停下来。完整的闭环有四个环节执行、验证、诊断、修复。执行是实施改动验证是运行测试或检查来确认结果诊断是分析失败原因修复是根据诊断结果再次调整代码。这四个环节循环往复直到验证通过。我经常类比的是修空调的师傅他不是修完就走了而是开机、听声音、看压力表、确认制冷正常才收工。Agent 也一样改完代码不跑测试等于没修完。这个闭环在单步聊天里不可能实现因为聊天模式里模型没有执行环境验证环节永远依赖人。而 Claude Code 里模型可以直接跑测试直接把失败信息读回上下文然后自己决定下一步。这就是“自愈”和“被动修补”的本质区别。3.2 在 Claude Code 里把闭环建起来要把闭环建立起来第一件事是给 Agent 足够的工具权限。它需要能执行 Bash 命令、能读取文件、能编辑文件否则是“有嘴没手”。这是权限配置层面的事后面第 5 节详细说。第二件事是在 CLAUDE.md 里写清楚验证要求。我通常会在项目手册里写明“任何代码改动完成后必须运行npm test测试失败时先阅读完整错误输出定位到具体文件再修改禁止在没有测试结果的情况下直接提交。”这相当于给 Agent 立了一条工作纪律它每次行动都会参考这个约束。第三件事是用 Hooks 做自动化门禁。Claude Code 支持在特定事件前后触发自定义脚本比如在 Agent 调用某个工具之前拦截检查或者在任务停止后强制执行一轮 lint。我把这理解为“制度和基础设施双保险”CLAUDE.md 是口头约定Hooks 是强制执行。两者都上闭环才算稳固。3.3 自愈的边界与兜底措施闭环自愈不是让 Agent 无限循环。如果没有边界控制最坏的情况是 Agent 在一个错误上反复打转白白消耗大量 Token甚至把代码改得越来越糟。所以必须设下限度和兜底。我的做法是在任务描述里明确失败阈值“同一个问题最多尝试 3 次修复如果第 3 次仍未通过测试停止修改输出完整的失败报告和你的分析和建议等待人工决策。”这个上限让“自愈”变得可控——它既能自己解决问题又不会失控。另一个兜底是危险操作的 Deny 规则。比如我几乎会永久拒绝rm -rf这类破坏性命令也会把git push这类操作设为每次询问而不是自动放行。通过 Hooks 可以很容易实现{ hooks: { PreToolUse: [ { matcher: Bash(rm -rf*), hooks: [ { type: command, command: echo 危险操作已拦截 exit 1 } ] } ] } }在安全和不信任之间找一个平衡点既让 Agent 有足够的自由度去动手实验又在真正会造成不可逆后果的动作前踩住刹车。3.4 一个能复现的自愈小 Demo纸上谈兵没有用我实际演示一次。假设项目里有一个文件src/format.ts里面有个函数把字符串转成kebab-case但代码写错了测试会失败。我会启动 Claude Code然后下发一条指令claude 修复 src/format.ts 上失败的测试要求先运行 npm test 查看失败原因再修复代码修复后必须再次运行 npm test直到全部通过。如果连续修复 3 次仍未通过停下来输出报告。接下来你会看到它自己执行这样的循环先跑npm test看到失败信息“expected hello-world but received hello_world”自己定位到format.ts的某个字符替换逻辑修改代码再跑npm test确认通过后汇报“测试已全部通过改动位置和原因如下”。整个过程里你几乎不需要插话它自己完成了“失败→诊断→修复→验证”的闭环。这个 Demo 看起来简单但它就是自愈工作流的最小单元。你把这个单元用在不同项目、不同复杂度的任务上再叠加多 Agent 编排和 Routine 脚本化就构成了一个完整的自动化开发体系。4. Routine 脚本化把高频操作变成 Agent 的肌肉记忆4.1 为什么要 Routine如果你的 Agent 每天处理的任务五花八门每次都靠“现场临时写 prompt”来指挥那么效果一定不稳定。因为你每次的描述可能遗漏细节前后不一致。Routine 脚本化的本质是把高频操作固化成确定性的流程模板让 Agent 看到某个指令就自动执行一套标准动作。我自己的一个真实体验项目里经常要做“代码审查”。以前我会手动给 Agent 写一大段要求包括“看 diff、检查错误处理、检查命名、检查测试覆盖”。每次写的还不一样有时忘了提示它检查测试。后来我把这套流程固化成一个名为review的自定义命令之后每次只需要输入/reviewAgent 就会自动按固定清单审查。效果一下就稳定了。脚本化的目的不是“少打字”而是把正确的做法固化下来保持每次执行的一致性。这和人用流程清单是一个道理——手术室里的核对清单不是为了给新人看的是为了让老手也不出错。4.2 用 CLAUDE.md 给 Agent 写“操作手册”CLAUDE.md 是 Claude Code 的项目手册每次会话启动时都会自动读入。它是最便宜的脚本化方式——你不需要写任何额外工具只需要把项目的约定、常用命令、工作纪律写清楚Agent 就会持续参考。我一般会在 CLAUDE.md 里包含这几类内容项目结构说明、常用构建测试命令、代码风格约定、工作流规矩。比如# 项目约定 ## 常用命令 - 测试: npm test - 类型检查: npm run typecheck - 构建: npm run build ## 工作纪律 - 任何代码改动后必须运行相关测试 - 测试失败时先读错误日志再修改代码 - 禁止在未运行测试的情况下声称“已完成” ## 输出规范 - 所有报告必须包含改动文件、改动原因、验证结果这段配置看起来简单但对 Agent 的行为影响非常大。它相当于告诉 Agent“在我们项目里‘完成’的定义是测试通过而不是代码写完”。很多自愈遗漏的问题本质上不是模型能力不够而是 Agent 没有被告知“什么叫完成”。4.3 用自定义命令固化高频流程CLAUDE.md 是静态约定自定义 Slash Command 则是主动触发的流程模板。Claude Code 支持在.claude/commands/目录下放 Markdown 文件文件名就是命令名。在会话里输入/命令名就会把对应的模板内容注入。举个例子我写一个release.md用来固化发版前的检查流程# 发版前检查流程 请按以下顺序完成发布前检查 1. 运行 npm run typecheck 确认类型无误 2. 运行 npm test 确认全部测试通过 3. 运行 npm run build 确认构建成功 4. 检查 git status确认没有未提交的临时文件 5. 输出检查结果清单标记每项的通过/失败状态有了这个命令发版检查就从“每次写一段新的 prompt”变成了“敲两下键盘”。而且因为是固定模板不会漏项。同样思路我还配置了plan.md用来让 Agent 输出分层改造方案、review.md用来触发代码审查。自定义命令的本质是把“过程资产”沉淀下来你不需要每次重新发明流程。4.4 用 Hooks 做自动化门禁如果说 Slash Command 是“主动触发”那么 Hooks 就是“被动拦截”。Claude Code 支持 PreToolUse、PostToolUse、Stop 等事件钩子可以在 Agent 调用工具前后自动执行脚本。最典型的应用是任务停止后强制执行一遍 lint。比如我有一类需求是“所有代码改动必须过 lint”。这个要求不靠嘴说而是用 Hook 强制实现。我可以在 settings.json 里配置一个 PostToolUse 钩子匹配 Edit 工具每次 Agent 编辑完文件后自动执行npm run lint如果 lint 失败就记录警告。这比事后人工检查可靠得多。Hooks 的配置本质上是 Shell 命令或脚本文件。这种“基础设施强制”能堵住很多空白。因为模型有时候会“忘事”但 Hook 不会。它像一个在门口把守的保安姿势对不对都要查。4.5 Routine 体系带来的三个实际收益把这套 Routine 体系搭起来之后最直观的收益有三个。第一是可预测。同样一个/review昨天执行和今天执行流程完全一致不会因为你对 AI 的描述方式不同而导致质量波动。第二是省 Token。固定的模板和预设命令减少了大量重复性的 prompt 输入每个任务节省下来的 Token 累积起来非常可观。第三是降低幻觉。当 Agent 不再“自由发挥”工作流程而是严格按模板执行时它“自创流程”和“漏步骤”的概率大幅下降。我在踩过几次“Agent 信誓旦旦说跑过测试其实根本没跑”的坑之后彻底相信了一点约束越具体结果越可靠。脚本化不是限制 AI 的“智能”而是给它一套靠谱的“肌肉记忆”。5. 把 Agent 接到不同模型安装配置与环境工程5.1 安装与升级Mac、Linux、Windows 与 VSCode聊完架构回到最基础的安装配置。Claude Code 是 npm 包前提是本机有 Node.js 环境。Mac 和 Linux 上装起来基本一致npm install -g anthropic-ai/claude-code装完先检查一下版本claude --version确认安装成功后直接在终端输入claude就能进入交互界面。Windows 上如果是 Linux 子系统安装方式和 Linux 一致如果用原生 PowerShell同样走 npm 命令但要注意终端权限和 Node 的 PATH 配置。VSCode 用户建议直接安装官方扩展安装后可以在 IDE 内打开 Claude Code 面板不用切出编辑器。我自己的习惯是终端里跑 Agent 做重活VSCode 扩展里做轻量交互和代码审查。两者互补。升级也是日常操作因为新版本功能迭代很快。我一般用npm update -g anthropic-ai/claude-code如果升级后遇到奇怪的配置丢失可以检查~/.claude.json或项目目录下的.claude/settings.json是否被覆盖。遇到这类问题不要急着卸载重装先看配置文件和版本日志。5.2 登录与不登录的区别安装完 Claude Code第一次启动会提示登录。登录之后才能使用完整的账号功能和订阅权限。不登录也能进到界面里试用但会被限制在演示模式一些核心能力如长期会话恢复、完整权限和部分工具调用都会受限。我建议日常使用一定要登录原因不只是功能完整还因为登录状态下你的项目配置、历史 Session 和权限设置才能统一管理。团队场景下每个成员用自己的账号登录也方便做权限隔离。不登录更像是“体验模式”适合先感受一下界面和流程不适合真正干活。登录之后如果发现某个会话的上下文过长可以直接输入/compact压缩如果发现会话状态异常可以退出重新进入再用claude --resume恢复历史对话。这些都会在登录状态下更可靠。5.3 用环境变量切换模型服务商Claude Code 的一个很实用的特性是它支持通过环境变量接入 Anthropic 兼容接口。这意味着你不一定只能用官方模型还可以接 DeepSeek、Qwen、GLM 等第三方模型服务。原理很简单。Claude Code 在启动时会读取几个环境变量其中三个最关键ANTHROPIC_BASE_URL决定请求发到哪个 API 地址ANTHROPIC_AUTH_TOKEN是你的访问密钥ANTHROPIC_MODEL指定使用哪个模型名。只要服务商提供了兼容 Anthropic 接口格式的 API就可以配置。以 DeepSeek 为例配置方式大概是这样export ANTHROPIC_BASE_URLhttps://api.deepseek.com/anthropic export ANTHROPIC_AUTH_TOKENsk-你的密钥 export ANTHROPIC_MODELdeepseek-chat不同服务商的兼容端点和模型名略有差异以各家官方文档为准。你想长期在多个模型之间切换的话每次都手动 export 很痛苦这时候就可以用 cc switch 这类社区工具。它本质上是一个配置管理工具把多套BASE_URL TOKEN MODEL组合保存为多个 profile一条命令就能切换当前生效的配置。如果你经常要对比不同模型在处理某个任务时的表现这个工具堪称效率神器。需要注意的一点是不是所有第三方模型服务都完整支持 Claude Code 依赖的工具调用能力。接入之后先跑个简单任务验证一下工具调用是否正常再投入到正式工作流。5.4 第三方 API 使用技巧接入第三方 API 有几个容易踩的坑我总结几个实测过的经验。第一先验证再配置。不要直接改完环境变量就启动 Claude Code先用最朴素的 curl 测试 API 连通性确认鉴权成功再进项目。这会帮你把“配置错误”和“模型问题”快速分开。curl -s $ANTHROPIC_BASE_URL/v1/messages \ -H x-api-key: $ANTHROPIC_AUTH_TOKEN \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d {model:你的模型名,max_tokens:64,messages:[{role:user,content:ping}]}第二密钥不要硬编码进配置文件。我见过有人把 Key 直接写进.bashrc或者项目配置里一旦项目公开或者被别人看到损失是很惨重的。正确做法是放进.env文件并通过export加载或者使用密码管理器注入。第三注意上下文长度限制。不同模型支持的上下文窗口不一样一些参数量较小的模型如果被塞入过长的编排任务表现会急剧下降。我给这类模型的任务会比较克制少开并行 Subagent控制单个任务的内容量。5.5 终端命令执行权限配置Claude Code 要让 Agent 真正执行 Bash 命令就必须授予一定权限。默认情况下每个命令都会弹出确认提示这对于自动化流程来说非常烦。所以我会配置权限白名单让一部分安全命令自动执行其余的保持询问。启动时可以带上允许名单claude --allowedTools Bash(git*), Read, Edit也可以在 settings.json 里配置更细致的 Spring 规则。我的原则是只允许与当前项目相关的操作自动执行比如git status、npm test、npm run build涉及远程推送、生产部署、删除文件等操作必须人工确认甚至直接 Deny。让 Agent 高效但不给它“闯祸”的权限这是多 Agent 编排和自愈体系能稳定运行的地基。6. 常见问题与排查技巧实录6.1 安装与升级类问题我遇到过的最多的安装问题是command not found。这通常不是没装成功而是 npm 全局目录没有加到 PATH 里。常见的解决方法是检查 npm 全局 bin 路径并把它加到 shell 配置里。另一个高发问题是权限报错多见于 Linux 和 Mac 上使用系统 Node 安装全局包。建议用 nvm 管理 Node 版本这样全局装包不需要sudo省掉一堆权限困扰。版本太旧也会出问题Claude Code 依赖比较新的 Node 特性如果装完启动报错优先检查node -v是否满足要求。升级后配置丢失也是一类典型问题。我建议升级前备份~/.claude.json和项目内的.claude/settings.json尤其是你精心调过的权限规则和 Hook 配置。升级不是坏事但留个备份总是稳妥的。6.2 模型接入类问题接入第三方模型时最常见的报错是 401 或 403通常意味着密钥无效或者没有该模型权限404 通常是你把BASE_URL的路径拼错了400 则可能是请求里的模型名不对或者参数格式不被服务商接受。我把排查路径整理成了表格报错可能原因排查方向401 / 403密钥错误或权限不足检查 Key 是否有效确认账号有该模型的访问权限404API 地址路径错误查阅服务商官方文档确认兼容端点的完整路径400模型名不存或参数格式不支持确认模型名拼写检查是否支持 tool_use 等参数工具调用失败服务商兼容层不完整先用简单任务验证工具调用换一个兼容度更高的服务商接入之后不要直接跑大型任务先让它执行一次最简单的文件编辑测试确认 Edit 和 Bash 工具都正常工作再投入真实项目。6.3 上下文与会话类问题上下文过长是很多人都会遇到的“墙”。表现为Agent 开始答非所问或者明显忽略了你前面的指令甚至重复执行已经完成的操作。这时候最有效的操作就是/compact把历史压缩成摘要释放空间。如果任务做到一半Agent 状态乱掉了可以考虑 Fork 分支会话从关键节点重新开始。如果 Session 意外断开不要慌用claude --resume恢复但要注意恢复后检查一下上下文是否完整必要时先/compact再继续。6.4 编排与自愈类问题Subagent 编排时最典型的失败是“Subagent 没有按预期执行任务”常见原因是任务描述太模糊或者 Subagent 的定义里没有写清楚验收标准。我的经验是给 Subagent 的指令必须包含输入、输出格式和完成定义少一个它就容易跑偏。自愈死循环是另一个高频问题。有些项目里的测试特别慢或者失败信息特别隐蔽Agent 会在同一个错误上反复打转。这时候除了预先设上限还要学会中断它直接发送一个明确指令“停止当前修复循环生成报告”多数情况下它都能听话退出。如果它不听话最高优先级是 CtrlC 中断进程然后检查改动记录必要时用 Git 回滚。这也是为什么我在第 3 节反复说边界控制重要——自愈是好东西但失控的自愈会变成灾难。最后再分享一点我在实际使用中的体会。别急着一次性把所有功能都堆上去——一上来就配 10 个 Subagent、5 个 Hook、十几个自定义命令结果大概率是调试这套体系的时间比干活还多。我自己的演进路线是先把项目的测试命令写进 CLAUDE.md让 Agent 习惯“改完必须验证”然后尝试拆分第一个 Subagent 任务接着固化一两个高频 Routines最后才上 Hooks 门禁。每一步都跑顺了再加下一步。核心不是功能多而是每个环节都有明确的验收标准和兜底方案。从最小闭环开始一步一步把 Claude Code 打磨成真正替自己干活的那双手。