最开始把 Claude Code 当高级聊天框用是我对它最大的误解。写一句需求等它吐一段代码我复制粘贴到项目里跑起来报错再把错误贴回去让它继续改。这种“单步聊天”模式应付几十行的小脚本还行一旦进入多模块、多文件、有历史包袱的真实工程效率会肉眼可见地崩塌上下文越聊越乱改了一个文件漏了另一个修完一个小问题又冒出新的反复来回能把人磨到没脾气。直到我尝试用多 Agent 编排把任务拆给多个独立上下文用闭环自愈让失败在无人介入的情况下被自动消化再用 Routine 脚本化把整条工作流固化成可重复执行的资产才算真正感受到这套工具在“干活”而不是“聊天”。这篇内容就是我的实操记录和架构拆解适合那些已经入门 Claude Code、但还在用单轮问答方式搬砖又想把它推向自动化、并行化、可复用方向的人。我会把编排思路、自愈循环、Routine 设计、落地脚本和踩坑经验一次讲清楚。1. 为什么单步聊天撑不起真实工程需求1.1 单步聊天的三个致命短板单步聊天的第一个问题是“上下文污染”。同一个会话里无论聊了多少轮模型都要把前面的对话历史、代码片段、错误日志堆在一起。短时间还好一旦超过几万 token最前面的关键约定就容易被稀释后边的生成质量断崖式下跌。你做了一次大重构之后它可能把旧接口的用法当成最新的来写因为旧信息还没被清理这跟人一样脑子里的临时记忆太多了反而抓不住重点。第二个问题是“无任务边界”。单步聊天天然是线性问答你问一句、它答一句没有“任务清单”更没有“验收标准”。它今天帮你修好了函数 A明天你在同一个会话里让它重构模块 B它不一定记得 A 那边还有一处依赖需要同步修改。没有边界就没有责任的切分出了错只能全靠人工反复盯你成了整个流程的兜底者AI 只是偶尔正确的工具人。第三个问题是“故障靠人去发现”。单步聊天里你贴过去报错它给方案你跑了再贴新的报错。这套循环的传感器是你判断器也是你执行者还是你。真正失控不是错误本身而是错误没有被系统性捕获、分类和处理。真实项目的错误是链式的一个类型错误会引发一连串编译失败一个越界会带崩后续所有操作。靠人工一次次贴回显注定又慢又容易漏。1.2 从“提问-回答”转向“代理-执行”所以我在自己的实践里完成了一个思维转变把 Claude Code 不再当作“问答机器人”而是当作一个能自主调工具、读文件、跑命令的“编码代理”。它手里有终端、有文件系统、有搜索能力那我的角色就不该是“复读机”而是“任务分发员”和“流程管理员”。这个转变的第一个关键是给模型一个明确的任务范围而不是一句模糊的“帮我看看这个 bug”。第二个关键是要用外部机制去约束它的行为比如让它在修改代码后必须跑测试、必须把变更记录写进某个文件、必须按固定格式返回状态。第三个关键则是接受“它也会失败”所以流程里要有检测与纠错环节而不是把失败当作需要换一种问法再来一遍。这一步想通了后面的多 Agent 编排、闭环自愈、Routine 脚本化其实都是顺理成章的事。它们不是在给模型“加戏”而是在给一个原本只能“聊”的系统装上真正干活该有的骨架。2. Claude Code 多 Agent 编排把任务拆成一支小团队2.1 多 Agent 编排的核心思想职责分离与上下文隔离多 Agent 编排听起来很高级但落到本质上就是两件事职责分离和上下文隔离。一个庞大任务如果只丢给一个会话上下文必然互相干扰。但如果你把需求拆成几个子域分别由不同的 Agent 负责每个 Agent 只保留自己领域的上下文那么单个 Agent 的负担会大幅降低错误也不容易跨模块传染。我通常在项目里区分三类角色。第一类是“规划者”负责读需求、拆任务、列出文件清单和验收条件。第二类是“执行者”每个执行者只负责一个模块或一个任务簇比如前端组件、后端接口、测试脚本。第三类是“审查者”负责检查执行者的产出跑测试找逻辑漏洞。这样形成了一条简单的流水线规划者不写代码执行者不独自做设计决策审查者专注于挑刺。注意这里说的多 Agent 不一定非要同时打开多个交互界面。我在 Claude Code 中常用的是并行会话加外部脚本统一调度。简单做法是开多个终端窗口每个终端里运行一个 Claude Code 会话各自加载不同的上下文文件复杂做法是通过 CLI 脚本按顺序或并行地调起多个非交互式任务。后者更容易自动化也会在后面 Routine 部分详细展开。2.2 三种实用的编排模式第一种是“主管-执行者模式”。主管 Agent 负责把需求拆解成多个子任务然后逐个分配执行者完成后把结果回报给主管由主管汇总、检查、决定是否需要返工。这种模式适合需求明确、模块边界清楚的项目比如给新服务添加一组 CRUD 接口主管拆任务执行者分别写 controller、service、repository最后由主管统一整合和审查。第二种是“流水线模式”。上游 Agent 的输出直接成为下游 Agent 的输入。比如数据分析类任务Agent A 负责拉取数据和清洗Agent B 负责特征工程Agent C 负责建模每个阶段都有明确的输入输出契约。这种模式的好处是链路清晰缺点是中间环节出错会影响后续所以每一级都要有校验。第三种是“专家委员会模式”。多个 Agent 从各自角度对同一份代码或方案给出意见最后通过另一个 Agent 或人工做裁决。比如做一次代码审查可以让一个 Agent 重点检查并发与安全一个 Agent 重点检查可测试性和边界条件还有一个 Agent 只关注性能和资源占用。三者互不干扰各自输出问题清单最后由汇总者去重、定级。这种模式我特别推荐用在风险较高的重构上能明显减少“一个视角没看到上线就出事”的情况。2.3 落地多 Agent 编排的注意事项多 Agent 不是银弹落地时最容易踩的几个坑我一个个说。第一个坑是“伪多 Agent”只是把名字换成 Agent A、Agent B喂给他们的上下文还是全量代码库。这等于把业务逻辑拆了记忆没拆照样互相污染。正确的做法是给每个 Agent 划定工作目录或明确的文件集合让它们只读自己该看的部分。比如通过.claude项目配置或者给同一个会话设置不同的 CLAUDE.md 指引让不同会话只关注特定模块。第二个坑是“接口契约不清晰”。多 Agent 之间的交付物如果没有固定格式下游拿到东西还得花时间理解反而比人肉协作更慢。所以我会让每个执行者在结尾输出统一的摘要包含“改了哪些文件、关键改动点是什么、测试结果如何、有没有遗留风险”。有了这个固定格式任何下游角色都能快速接住。第三个坑是“缺少全局视角”。拆得太细单个 Agent 只顾局部可能做出互相矛盾的设计。我的做法是保留一个“总控 Agent”掌握全局架构文档每次分配任务时把相关约束和接口定义写进任务描述里。宁可多写几句上下文也不要让执行者凭空猜测。3. 闭环自愈机制让任务在失败中自动站起来3.1 没有自愈的 Agent 像一次性餐具如果只做多 Agent 编排而没有闭环自愈那整套系统依然是脆弱的。因为 Agent 不是确定性程序它的每一步都可能跑偏改了一个文件引入了另一个语法错误执行了一条命令环境变量没配对甚至本来正确的代码因为一次重试时心态漂移给“优化”坏了。没有自愈机制任何一个小错误都会让整个流程卡死又需要你手动接手。我把自愈看成 Agent 系统工程里最被低估的部分。传统脚本遇到失败就是失败但 Agent 可以自己分析错误、自己修、自己验证。这正是 LLM 与普通脚本相比最强大的地方——它具备读错误信息、推断原因、生成修复补丁、重新验证的能力缺的只是有人把这条循环串起来。3.2 自愈循环的三要素监控、诊断、修复一个完整的闭环自愈机制至少包含三个环节。监控是观察运行结果是否正常。最简单的是看命令退出码但更可靠的要看输出日志、测试报告和预期文件是否生成。我在实践里会把 Agent 执行的每条关键命令的 stdout、stderr 都捕获下来作为后续判断的依据。诊断是拿到失败信号后让有分析能力的 Agent 判断问题出在哪。这一步很关键不能简单看到“测试失败”就盲目重跑而是要读取堆栈、比较代码 diff定位是逻辑问题、环境问题还是需求理解偏差。诊断结果要可结构化至少包含“失败环节、可能原因、修复方案建议”。修复是根据诊断结果做具体操作。可以有两种形式如果是外部脚本可以直接用预置规则重试如果是代码逻辑问题就派给负责该模块的 Agent让它基于错误信息生成补丁。修复之后必须回到监控环节验证修复是否真正生效。这样三个环节形成闭环而不是修完就跑。3.3 在 Claude Code 中实现闭环自愈的完整策略具体到 Claude Code我是这样实现的。第一步给每个 Agent 的输出加上“文档化协议”。比如要求它在跑完测试后把结果写入~/.agent_logs/任务名.json内容包含测试是否通过、失败的测试名、错误日志摘要。这样外部脚本就能用grep或者jq快速判断成功与失败。第二步写一个外层脚本脚本包围 Claude Code 的非交互式调用。举个例子#!/usr/bin/env bash set -uo pipefail TASK$1 LOG_FILEagent_run.json claude -p $TASK --output-format json $LOG_FILE exit_code$? if [ $exit_code -ne 0 ]; then echo Agent 执行失败收集错误信息 jq -r .result $LOG_FILE last_error.txt fi如果你不习惯用 Bash也可以用 Node.js 或 Python 写一个更灵活的执行器。我个人更喜欢 Python因为对于复杂逻辑和重试策略处理起来更舒服。第三步定义重试规则。不是所有失败都应该重试我会把失败分成三类环境类失败比如网络超时、依赖暂时不可用。这类问题可以直接重试通常等几秒就好。代码类失败比如测试报错、类型不匹配。这类问题要派给对应模块的 Agent带着错误日志和文件列表去修复。需求类失败比如 Agent 表示任务描述有歧义或者做出来的东西和预期不符。这类问题即时重试也没用需要回到规划者那边重新澄清。第四步确认修复是否真的可靠。很多人会犯一个错误只要测试通过就认为自愈完成。但有时候 Agent“修好”的方式非常粗暴比如直接删掉了断言或者把失败用例跳过。所以我在验证环节还会让审查 Agent 检查补丁是不是合理不允许为了让测试变绿而绕过行为变更。自愈要的是系统变健康而不是测试报告变漂亮。3.4 自愈与多 Agent 协同谁负责修、谁负责验自愈不能只靠一个 Agent 无限自我循环那样很容易陷入局部最优。我的做法是用外部脚本作为“流程大脑”根据失败类型决定把任务交给哪个 Agent。代码问题交给对应的执行者审查问题交给审查者需求问题打回给规划者。每个 Agent 重新介入时都会带上外部脚本整理好的结构化错误报告而不是一句“刚才失败了你再试试”这样模糊的话。为了让这个协同更顺滑我要求每个 Agent 在修复完以后在返回结果里明确声明“修复点是什么、修改了哪些文件、如何验证”。这样审查 Agent 就不用重新把整个代码库读一遍只需要核对关键的变更。闭环自愈的意义不只是让流程继续跑更是让每一次失败都能沉淀为可追溯的记录让下一次更加可靠。4. Routine 脚本化架构把重复劳动固化成可执行资产4.1 什么是 Routine 脚本化能解决什么日常工作里有很多固定套路提交前跑代码检查、发布前做回归测试、重构后做接口一致性检查、PR 前生成变更摘要。这些套路每次内容可能都很相似只不过对象不同。Routine 脚本化就是把这类反复执行的流程写成可复用的脚本和配置文件让 Claude Code 在接到一个任务后能自动按固定步骤工作而不是每次从零临场发挥。Routine 的价值在于三点。一是降低决策成本Agent 不用每次都在“先做什么后做什么”上纠结按脚本走就行。二是保证一致性人肉操作偶尔会遗忘步骤脚本不会。三是积累最佳实践你这周调好的压测流程、上线前检查项写进 Routine 之后下周就自动变成团队的基础设施。4.2 一套 Routine 的标准结构与设计原则我常用的 Routine 结构分四块触发条件、前置检查、执行步骤、验收标准。触发条件可以是“当检测到 main 分支有新提交时”“当某个文件被修改时”“当用户手动输入特定关键词时”。前置检查是确认环境现状是否允许执行比如目标分支存在、依赖已经安装、环境变量已加载。执行步骤是具体的命令序列和 Agent 任务描述每一步都需要有可检查的输出。验收标准是整条 Routine 是否完成的判断依据比如测试全部通过、覆盖率达标、变更文件数在预期范围内。设计 Routine 时有三个原则我现在牢记在心。第一个原则是按“事物”而不是按“UI”组织。意思是让每个 Routine 围绕一个业务目标比如“发布前检查”“依赖漏洞扫描”而不是围绕某个工具的操作。因为工具会变目标才是稳定的。第二个原则是每一步都尽量可回滚。Routine 里包含修改性操作时我一定会先打标签或快照。宁可多花几秒备份也不要让 Routine 在中间出错后留下一地鸡毛。第三个原则是 Routine 要能分段调试。先把整条流程拆成独立步骤每步做成独立的可调用函数出现问题只用调其中一段而不是整个重跑。4.3 一个可抄作业的 Routine 实例发布前检查下面是我为一个中小型项目写的发布前检查 Routine 脚本骨架。它做的事情是拉取最新代码、检查依赖安全、跑完整测试、生成变更摘要、最后让审查 Agent 做一次代码审查。#!/usr/bin/env bash set -euo pipefail REPO_DIR$1 cd $REPO_DIR echo 1/5 拉取最新代码 git pull origin main git log --oneline -5 /tmp/last_commits.txt echo 2/5 检查依赖安全 npm audit --audit-levelhigh /tmp/audit.txt || echo 发现安全告警 echo 3/5 跑完整测试 npm test /tmp/test_output.txt || echo 测试失败 echo 4/5 生成变更摘要 git diff --stat HEAD~1..HEAD /tmp/diff_stat.txt echo 5/5 调用 Claude Code 做审查摘要 claude -p 请阅读以下信息最近5次提交、变更统计、安全审计结果。请总结这次发布的主要影响并列出需要重点回归的场景。内容控制在300字内输出为 Markdown 列表。 --output-format text /tmp/release_review.md cat /tmp/release_review.md这个脚本很朴素但已经能解决很大一部分重复劳动。你可能会问“这不就是普通脚本吗和 Agent 有什么关系”关键差别在于最后一步Claude Code 能基于前面生成的上下文做语义理解生成人类能快速决策的发布说明。而前面所有收集信息的工作都是让 Agent 有足够的、结构化的输入不需要重新翻代码库。4.4 Routine、多 Agent 与自愈的联动关系Routine 脚本化的真正威力是它能成为多 Agent 编排和闭环自愈的黏合剂。一个运行良好的系统往往是这样的外部调度器读取 Routine 配置按步骤依次触发执行。每个步骤可能对接到不同的 Agent。如果某一步失败自愈模块捕获错误按预设策略选择重试或派发修复任务。修复完成后Routine 从失败的那一步继续往下跑而不是从头再来。这就像给 Agent 装了一套“工作流操作系统”编排负责把活分下去自愈负责处理异常Routine 负责让一切可重复、可沉淀。所以我不建议把这些概念拆开看。你在实践时可以先把一个高频的重复流程做成 Routine再在旁边加上一个简单的失败检测与重试循环。跑通了再逐步拆出多个 Agent 角色。这样循序渐进比一开始就追求一个大而全的平台要稳妥得多。5. 实操记录从零搭建一个多 Agent Routine 系统5.1 环境准备与 Claude Code 安装这一部分的某些操作属于常见实践具体版本和命令以官方文档为准。我在 macOS 上的安装很简单用 npm 全局安装就行npm install -g anthropic-ai/claude-code如果是 Linux 环境同样适用但需要你先确认终端的网络环境能正常访问官方 API 服务。安装完成后第一步是登录与鉴权。Claude Code 一般会在首次运行时跳转浏览器完成授权拿到会话密钥后保存在本地。注意这里不要用任何非官方代理或转发服务直接按官方提示操作即可。安装好后我习惯先验证一下版本和工作状态claude --version claude -p hi # 非交互模式输出一句话确认链路正常如果能在终端里得到正常输出说明基本环境没问题。接下来可以看目录下的.claude配置一个项目可以放一个共享的 CLAUDE.md相当于给所有 Agent 读到的项目说明书。我通常会把项目结构、常用命令、代码规范、模块边界都写进去。这个文件是多 Agent 编排中很重要的“公共记忆”。5.2 任务拆解与 Agent 角色定义一次真实场景是我要给一个旧服务增加一个“导出报表”功能涉及后端接口、前端页面、测试和文档。如果只开一个会话Agent 需要同时处理数据库查询、Excel 生成、前端表格展示和接口文档上下文很快会爆。我选择拆成四个角色Agent A后端负责新增导出接口处理查询参数、超时设置、文件流返回。Agent B前端负责生成导出按钮、请求接口、处理下载与错误提示。Agent C测试负责补充接口集成测试和前端交互测试。Agent D审查负责在合并前检查接口规范、异常处理和潜在安全风险。我会用独立的终端会话启动每个 Agent每个会话的 CLAUDE.md 通过参数或目录切换加载不同模块描述。为了让协作不混乱我会让每个 Agent 都遵守同一个输出协议结束工作时输出“修改文件列表 验证命令 结果状态”。这样最后我或者总控脚本只需要收集四个会话的输出就能快速判断哪里掉了链子。5.3 编写 Routine 脚本含代码示例有了角色定义后我把调度过程写成脚本。下面是一个简化但可运行的 Python 示例展示如何顺序调用不同 Agent并在失败时做条件重试import subprocess import json import time def run_claude(prompt, agent_name, max_retries2): for attempt in range(max_retries 1): result subprocess.run( [claude, -p, prompt, --output-format, json], capture_outputTrue, textTrue, ) if result.returncode ! 0: print(f[{agent_name}] 执行失败: {result.stderr[-500:]}) if attempt max_retries: print(f[{agent_name}] {attempt 1} 次重试...) time.sleep(3) continue return None try: data json.loads(result.stdout) return data.get(result, ) except json.JSONDecodeError: return result.stdout return None def main(): tasks [ { name: backend, prompt: 新增导出接口参考 docs/api.md修改后跑 pytest 接口测试, }, { name: frontend, prompt: 增加导出按钮和下载逻辑修改后跑前端构建, }, { name: test, prompt: 补充端到端测试用例确保导出功能覆盖正常和异常路径, }, ] results {} for task in tasks: print(f 开始执行 {task[name]} ) output run_claude(task[prompt], task[name]) if output is None: results[task[name]] FAILED else: results[task[name]] OK with open(foutput_{task[name]}.md, w) as f: f.write(output) failed [k for k, v in results.items() if v FAILED] if failed: print(失败任务:, failed) else: print(全部完成) if __name__ __main__: main()这个脚本足够做演示真正生产化时我会加上并行执行、日志归档和更精细的失败分类。核心思路是用代码把 Agent 一个个“喂”进流程而不是靠人手工复制粘贴提示词。5.4 接入闭环自愈的完整流程上面的简单脚本只有“失败重试”还没有“自愈修复”。完整的做法是引入判断逻辑当某个 Agent 失败时先读取其输出日志如果日志包含明确的代码错误就构造一个修复任务派给同一个 Agent 或另一个专门的修复 Agent。我经常用的方式是当普通重试两次仍失败就调用一个“诊断 Agent”diagnose_prompt f 请分析下面这段失败输出判断问题原因并输出结构化 JSON。 字段failure_type(env/code/requirement)summary(一句话概述)fix_hint(修复建议)。 失败输出: {error_snippet} 拿到诊断结果后我根据failure_type决定后续动作env等 10 秒后重跑原任务。code把fix_hint附加到新任务里交给执行 Agent让它读取相关文件并生成补丁。requirement停止流程把问题返回给规划者或者人工处理。在集成测试里这套机制的效果很直观。有一次测试脚本因为缺少临时文件权限而失败诊断 Agent 判定为环境类问题自动修改了目录权限后重新跑通另一次是代码里有一个空指针诊断 Agent 判定为代码类问题派给后端 Agent 修复后回归通过。整个过程我几乎没有介入。5.5 实测效果与关键参数调优搭好这套系统后我做了一轮实测一个包含 12 个文件的模块改动从拆任务到全部测试通过整体跑了大约 11 分钟。如果靠单步聊天我估算至少要 40 分钟以上而且我还要全程盯着上下文。这个效率提升很大但也不是没有代价多 Agent 并行和多次重试会消耗更多 token我在调优时总结了几个关键参数。第一重试次数不要设太高。来自环境的瞬时失败重试一次就够代码逻辑问题重试超过三次基本是在浪费 token不如切换路径。第二Agent 的 prompt 越聚焦输出越稳定。我会给每个任务限定“你必须使用项目里的测试命令不要重新设计测试框架”之类的硬性约束。第三日志记录要适度。只记录结构化摘要不记录全部 stdout否则日志文件会比代码还大反而没法快速排查。成本方面我会为每个 Agent 任务设置一个最大 token 预算。比如后端 Agent 最多执行 20 万 token超过就中断并报告。这个预算可以写在脚本里也可以通过 Claude Code 的上下文管理参数调。核心原则是宁可中断一个跑偏的任务也不要让它无限生成无用代码。6. 常见问题与排查技巧实录6.1 多 Agent 之间上下文冲突怎么办这是最常见的问题。两个 Agent 同时改同一个文件或者一个 Agent 改了公共类型另一个 Agent 还在用旧签名。我的解决方法是在任务启动前生成一份“共享契约文件”里面记录所有跨模块使用的接口签名、关键类型定义、文件职责说明。每个 Agent 启动时都会被要求先读这份契约再开始改代码。如果仍有冲突我会在自愈逻辑里加一个“变更冲突检测”步骤检查同一文件是否被多个任务同时修改如果发现就触发一个合并 Agent 去解决冲突。还有一个土办法但很有效把工作目录按 Agent 隔离每个 Agent 有一个work_目录最终再统一合并。合并时不要用 git 自动合并而是让审查 Agent 逐个文件做一致性检查。这样成本高一点但能避免很多隐性 bug。6.2 自愈误判导致死循环怎么破自愈机制本身也可能出错最常见的是死循环。比如一个 Agent 每次修复都会引入新的语法错误然后系统又派它去修复无限循环烧掉大量 token。我现在的对策是给整个流程设置两个“刹车”一是总重试次数上限比如所有任务累计重试不超过 5 次二是“修复后回归测试未通过的次数”上限比如同一任务连续失败 3 次就停止改为人工介入。另一个问题是“修复通过但实际是作弊”。Agent 可能删掉了失败的测试或者给测试打了桩让结果看起来通过。这种问题要靠审查 Agent 来处理比较测试文件在修复前后的 diff如果发现删减了断言直接拒绝并打回。宁可不通过也不能让假绿混过去。6.3 Routine 脚本失效Agent 不按约定办事有时脚本明明写得很好但 Agent 就是“不听话”。我遇到过的情况包括要求 Agent 输出 JSON它却在 JSON 外面加了 Markdown 代码块导致解析失败要求它只改指定文件它顺手改了无关文件。排查这类问题我的经验是要在 prompt 里用“绝对句式”写约束并把关键格式要求放到 prompt 的最后一句模型对文末指令的记忆更强。同时在代码里加一层“防御式解析”比如用正则去掉代码块标记或者校验输出是否符合模式不符合就重试一次。如果仍然不遵守就要考虑是不是上下文太长约束被稀释了。这时候可以把约束写进 CLAUDE.md并且每次让 Agent 在开始工作前先“复述任务要求”。让其复述两到三句能显著提高遵守率。6.4 成本与资源消耗怎么控制多 Agent 编排、自愈重试、Routine 脚本都是 token 消耗大户。我控制成本的手段有几个。一是尽量用小参数模型处理归纳、摘要类任务不要每个环节都用最贵的模型。二是给每个 Agent 的 prompt 里明确“如无必要不要读取超过 5 个文件”避免 Agent 自己把一堆无关文件读进来。三是做好缓存项目里的接口定义、测试报告如果没变化就不必每次都重新生成。还有一个小技巧刚开始做自动化时先用一个小任务跑通流程观察每一步消耗了多少 token、耗时多少再决定哪些步骤可以精简。先把系统跑快再考虑跑贵。对于大部分个人项目或者小团队一个月几十万 token 的用量其实是可控的只要不是无限死循环。最后再分享一点个人经验从“单步聊天”切换到“多 Agent 编排 闭环自愈 Routine 脚本化”我踩过的最大一个坑就是一上来就想把所有流程自动化结果脚本比业务代码还复杂维护成本高到吓人。我现在更推荐的做法是先把手头最重复、最容易出错的一个流程挑出来写成一个可以手动触发的 Routine 脚本再加最简单的失败重试。跑顺之后再加入自愈诊断和多 Agent 拆分。每加一层都要确认它确实降低了你的介入成本而不是反过来把问题复杂化。另外多 Agent 编排的效果高度依赖任务拆分的质量。任务拆得越清晰、边界越明确、交付格式越固定整套系统就越稳。反过来如果需求本身模糊硬拆只会让错误被放大。所以我现在遇到模糊需求第一反应不是派 Agent而是先补需求文档。工具再强也替代不了自己想清楚这件事。这套架构还有一个值得继续扩展的方向把 Routine 脚本和 CI/CD 集成做成提交代码后自动触发多 Agent 审查、自动跑回归、自动生成发布说明的长线流程。对我个人而言它已经从一个“提高效率的工具”慢慢变成了“沉淀团队经验的基础设施”。如果你也正在被低效的单步聊天折磨希望这篇拆解能给你一个清晰的起步地图。
Claude Code进阶：多Agent编排、闭环自愈与Routine脚本化实战
最开始把 Claude Code 当高级聊天框用是我对它最大的误解。写一句需求等它吐一段代码我复制粘贴到项目里跑起来报错再把错误贴回去让它继续改。这种“单步聊天”模式应付几十行的小脚本还行一旦进入多模块、多文件、有历史包袱的真实工程效率会肉眼可见地崩塌上下文越聊越乱改了一个文件漏了另一个修完一个小问题又冒出新的反复来回能把人磨到没脾气。直到我尝试用多 Agent 编排把任务拆给多个独立上下文用闭环自愈让失败在无人介入的情况下被自动消化再用 Routine 脚本化把整条工作流固化成可重复执行的资产才算真正感受到这套工具在“干活”而不是“聊天”。这篇内容就是我的实操记录和架构拆解适合那些已经入门 Claude Code、但还在用单轮问答方式搬砖又想把它推向自动化、并行化、可复用方向的人。我会把编排思路、自愈循环、Routine 设计、落地脚本和踩坑经验一次讲清楚。1. 为什么单步聊天撑不起真实工程需求1.1 单步聊天的三个致命短板单步聊天的第一个问题是“上下文污染”。同一个会话里无论聊了多少轮模型都要把前面的对话历史、代码片段、错误日志堆在一起。短时间还好一旦超过几万 token最前面的关键约定就容易被稀释后边的生成质量断崖式下跌。你做了一次大重构之后它可能把旧接口的用法当成最新的来写因为旧信息还没被清理这跟人一样脑子里的临时记忆太多了反而抓不住重点。第二个问题是“无任务边界”。单步聊天天然是线性问答你问一句、它答一句没有“任务清单”更没有“验收标准”。它今天帮你修好了函数 A明天你在同一个会话里让它重构模块 B它不一定记得 A 那边还有一处依赖需要同步修改。没有边界就没有责任的切分出了错只能全靠人工反复盯你成了整个流程的兜底者AI 只是偶尔正确的工具人。第三个问题是“故障靠人去发现”。单步聊天里你贴过去报错它给方案你跑了再贴新的报错。这套循环的传感器是你判断器也是你执行者还是你。真正失控不是错误本身而是错误没有被系统性捕获、分类和处理。真实项目的错误是链式的一个类型错误会引发一连串编译失败一个越界会带崩后续所有操作。靠人工一次次贴回显注定又慢又容易漏。1.2 从“提问-回答”转向“代理-执行”所以我在自己的实践里完成了一个思维转变把 Claude Code 不再当作“问答机器人”而是当作一个能自主调工具、读文件、跑命令的“编码代理”。它手里有终端、有文件系统、有搜索能力那我的角色就不该是“复读机”而是“任务分发员”和“流程管理员”。这个转变的第一个关键是给模型一个明确的任务范围而不是一句模糊的“帮我看看这个 bug”。第二个关键是要用外部机制去约束它的行为比如让它在修改代码后必须跑测试、必须把变更记录写进某个文件、必须按固定格式返回状态。第三个关键则是接受“它也会失败”所以流程里要有检测与纠错环节而不是把失败当作需要换一种问法再来一遍。这一步想通了后面的多 Agent 编排、闭环自愈、Routine 脚本化其实都是顺理成章的事。它们不是在给模型“加戏”而是在给一个原本只能“聊”的系统装上真正干活该有的骨架。2. Claude Code 多 Agent 编排把任务拆成一支小团队2.1 多 Agent 编排的核心思想职责分离与上下文隔离多 Agent 编排听起来很高级但落到本质上就是两件事职责分离和上下文隔离。一个庞大任务如果只丢给一个会话上下文必然互相干扰。但如果你把需求拆成几个子域分别由不同的 Agent 负责每个 Agent 只保留自己领域的上下文那么单个 Agent 的负担会大幅降低错误也不容易跨模块传染。我通常在项目里区分三类角色。第一类是“规划者”负责读需求、拆任务、列出文件清单和验收条件。第二类是“执行者”每个执行者只负责一个模块或一个任务簇比如前端组件、后端接口、测试脚本。第三类是“审查者”负责检查执行者的产出跑测试找逻辑漏洞。这样形成了一条简单的流水线规划者不写代码执行者不独自做设计决策审查者专注于挑刺。注意这里说的多 Agent 不一定非要同时打开多个交互界面。我在 Claude Code 中常用的是并行会话加外部脚本统一调度。简单做法是开多个终端窗口每个终端里运行一个 Claude Code 会话各自加载不同的上下文文件复杂做法是通过 CLI 脚本按顺序或并行地调起多个非交互式任务。后者更容易自动化也会在后面 Routine 部分详细展开。2.2 三种实用的编排模式第一种是“主管-执行者模式”。主管 Agent 负责把需求拆解成多个子任务然后逐个分配执行者完成后把结果回报给主管由主管汇总、检查、决定是否需要返工。这种模式适合需求明确、模块边界清楚的项目比如给新服务添加一组 CRUD 接口主管拆任务执行者分别写 controller、service、repository最后由主管统一整合和审查。第二种是“流水线模式”。上游 Agent 的输出直接成为下游 Agent 的输入。比如数据分析类任务Agent A 负责拉取数据和清洗Agent B 负责特征工程Agent C 负责建模每个阶段都有明确的输入输出契约。这种模式的好处是链路清晰缺点是中间环节出错会影响后续所以每一级都要有校验。第三种是“专家委员会模式”。多个 Agent 从各自角度对同一份代码或方案给出意见最后通过另一个 Agent 或人工做裁决。比如做一次代码审查可以让一个 Agent 重点检查并发与安全一个 Agent 重点检查可测试性和边界条件还有一个 Agent 只关注性能和资源占用。三者互不干扰各自输出问题清单最后由汇总者去重、定级。这种模式我特别推荐用在风险较高的重构上能明显减少“一个视角没看到上线就出事”的情况。2.3 落地多 Agent 编排的注意事项多 Agent 不是银弹落地时最容易踩的几个坑我一个个说。第一个坑是“伪多 Agent”只是把名字换成 Agent A、Agent B喂给他们的上下文还是全量代码库。这等于把业务逻辑拆了记忆没拆照样互相污染。正确的做法是给每个 Agent 划定工作目录或明确的文件集合让它们只读自己该看的部分。比如通过.claude项目配置或者给同一个会话设置不同的 CLAUDE.md 指引让不同会话只关注特定模块。第二个坑是“接口契约不清晰”。多 Agent 之间的交付物如果没有固定格式下游拿到东西还得花时间理解反而比人肉协作更慢。所以我会让每个执行者在结尾输出统一的摘要包含“改了哪些文件、关键改动点是什么、测试结果如何、有没有遗留风险”。有了这个固定格式任何下游角色都能快速接住。第三个坑是“缺少全局视角”。拆得太细单个 Agent 只顾局部可能做出互相矛盾的设计。我的做法是保留一个“总控 Agent”掌握全局架构文档每次分配任务时把相关约束和接口定义写进任务描述里。宁可多写几句上下文也不要让执行者凭空猜测。3. 闭环自愈机制让任务在失败中自动站起来3.1 没有自愈的 Agent 像一次性餐具如果只做多 Agent 编排而没有闭环自愈那整套系统依然是脆弱的。因为 Agent 不是确定性程序它的每一步都可能跑偏改了一个文件引入了另一个语法错误执行了一条命令环境变量没配对甚至本来正确的代码因为一次重试时心态漂移给“优化”坏了。没有自愈机制任何一个小错误都会让整个流程卡死又需要你手动接手。我把自愈看成 Agent 系统工程里最被低估的部分。传统脚本遇到失败就是失败但 Agent 可以自己分析错误、自己修、自己验证。这正是 LLM 与普通脚本相比最强大的地方——它具备读错误信息、推断原因、生成修复补丁、重新验证的能力缺的只是有人把这条循环串起来。3.2 自愈循环的三要素监控、诊断、修复一个完整的闭环自愈机制至少包含三个环节。监控是观察运行结果是否正常。最简单的是看命令退出码但更可靠的要看输出日志、测试报告和预期文件是否生成。我在实践里会把 Agent 执行的每条关键命令的 stdout、stderr 都捕获下来作为后续判断的依据。诊断是拿到失败信号后让有分析能力的 Agent 判断问题出在哪。这一步很关键不能简单看到“测试失败”就盲目重跑而是要读取堆栈、比较代码 diff定位是逻辑问题、环境问题还是需求理解偏差。诊断结果要可结构化至少包含“失败环节、可能原因、修复方案建议”。修复是根据诊断结果做具体操作。可以有两种形式如果是外部脚本可以直接用预置规则重试如果是代码逻辑问题就派给负责该模块的 Agent让它基于错误信息生成补丁。修复之后必须回到监控环节验证修复是否真正生效。这样三个环节形成闭环而不是修完就跑。3.3 在 Claude Code 中实现闭环自愈的完整策略具体到 Claude Code我是这样实现的。第一步给每个 Agent 的输出加上“文档化协议”。比如要求它在跑完测试后把结果写入~/.agent_logs/任务名.json内容包含测试是否通过、失败的测试名、错误日志摘要。这样外部脚本就能用grep或者jq快速判断成功与失败。第二步写一个外层脚本脚本包围 Claude Code 的非交互式调用。举个例子#!/usr/bin/env bash set -uo pipefail TASK$1 LOG_FILEagent_run.json claude -p $TASK --output-format json $LOG_FILE exit_code$? if [ $exit_code -ne 0 ]; then echo Agent 执行失败收集错误信息 jq -r .result $LOG_FILE last_error.txt fi如果你不习惯用 Bash也可以用 Node.js 或 Python 写一个更灵活的执行器。我个人更喜欢 Python因为对于复杂逻辑和重试策略处理起来更舒服。第三步定义重试规则。不是所有失败都应该重试我会把失败分成三类环境类失败比如网络超时、依赖暂时不可用。这类问题可以直接重试通常等几秒就好。代码类失败比如测试报错、类型不匹配。这类问题要派给对应模块的 Agent带着错误日志和文件列表去修复。需求类失败比如 Agent 表示任务描述有歧义或者做出来的东西和预期不符。这类问题即时重试也没用需要回到规划者那边重新澄清。第四步确认修复是否真的可靠。很多人会犯一个错误只要测试通过就认为自愈完成。但有时候 Agent“修好”的方式非常粗暴比如直接删掉了断言或者把失败用例跳过。所以我在验证环节还会让审查 Agent 检查补丁是不是合理不允许为了让测试变绿而绕过行为变更。自愈要的是系统变健康而不是测试报告变漂亮。3.4 自愈与多 Agent 协同谁负责修、谁负责验自愈不能只靠一个 Agent 无限自我循环那样很容易陷入局部最优。我的做法是用外部脚本作为“流程大脑”根据失败类型决定把任务交给哪个 Agent。代码问题交给对应的执行者审查问题交给审查者需求问题打回给规划者。每个 Agent 重新介入时都会带上外部脚本整理好的结构化错误报告而不是一句“刚才失败了你再试试”这样模糊的话。为了让这个协同更顺滑我要求每个 Agent 在修复完以后在返回结果里明确声明“修复点是什么、修改了哪些文件、如何验证”。这样审查 Agent 就不用重新把整个代码库读一遍只需要核对关键的变更。闭环自愈的意义不只是让流程继续跑更是让每一次失败都能沉淀为可追溯的记录让下一次更加可靠。4. Routine 脚本化架构把重复劳动固化成可执行资产4.1 什么是 Routine 脚本化能解决什么日常工作里有很多固定套路提交前跑代码检查、发布前做回归测试、重构后做接口一致性检查、PR 前生成变更摘要。这些套路每次内容可能都很相似只不过对象不同。Routine 脚本化就是把这类反复执行的流程写成可复用的脚本和配置文件让 Claude Code 在接到一个任务后能自动按固定步骤工作而不是每次从零临场发挥。Routine 的价值在于三点。一是降低决策成本Agent 不用每次都在“先做什么后做什么”上纠结按脚本走就行。二是保证一致性人肉操作偶尔会遗忘步骤脚本不会。三是积累最佳实践你这周调好的压测流程、上线前检查项写进 Routine 之后下周就自动变成团队的基础设施。4.2 一套 Routine 的标准结构与设计原则我常用的 Routine 结构分四块触发条件、前置检查、执行步骤、验收标准。触发条件可以是“当检测到 main 分支有新提交时”“当某个文件被修改时”“当用户手动输入特定关键词时”。前置检查是确认环境现状是否允许执行比如目标分支存在、依赖已经安装、环境变量已加载。执行步骤是具体的命令序列和 Agent 任务描述每一步都需要有可检查的输出。验收标准是整条 Routine 是否完成的判断依据比如测试全部通过、覆盖率达标、变更文件数在预期范围内。设计 Routine 时有三个原则我现在牢记在心。第一个原则是按“事物”而不是按“UI”组织。意思是让每个 Routine 围绕一个业务目标比如“发布前检查”“依赖漏洞扫描”而不是围绕某个工具的操作。因为工具会变目标才是稳定的。第二个原则是每一步都尽量可回滚。Routine 里包含修改性操作时我一定会先打标签或快照。宁可多花几秒备份也不要让 Routine 在中间出错后留下一地鸡毛。第三个原则是 Routine 要能分段调试。先把整条流程拆成独立步骤每步做成独立的可调用函数出现问题只用调其中一段而不是整个重跑。4.3 一个可抄作业的 Routine 实例发布前检查下面是我为一个中小型项目写的发布前检查 Routine 脚本骨架。它做的事情是拉取最新代码、检查依赖安全、跑完整测试、生成变更摘要、最后让审查 Agent 做一次代码审查。#!/usr/bin/env bash set -euo pipefail REPO_DIR$1 cd $REPO_DIR echo 1/5 拉取最新代码 git pull origin main git log --oneline -5 /tmp/last_commits.txt echo 2/5 检查依赖安全 npm audit --audit-levelhigh /tmp/audit.txt || echo 发现安全告警 echo 3/5 跑完整测试 npm test /tmp/test_output.txt || echo 测试失败 echo 4/5 生成变更摘要 git diff --stat HEAD~1..HEAD /tmp/diff_stat.txt echo 5/5 调用 Claude Code 做审查摘要 claude -p 请阅读以下信息最近5次提交、变更统计、安全审计结果。请总结这次发布的主要影响并列出需要重点回归的场景。内容控制在300字内输出为 Markdown 列表。 --output-format text /tmp/release_review.md cat /tmp/release_review.md这个脚本很朴素但已经能解决很大一部分重复劳动。你可能会问“这不就是普通脚本吗和 Agent 有什么关系”关键差别在于最后一步Claude Code 能基于前面生成的上下文做语义理解生成人类能快速决策的发布说明。而前面所有收集信息的工作都是让 Agent 有足够的、结构化的输入不需要重新翻代码库。4.4 Routine、多 Agent 与自愈的联动关系Routine 脚本化的真正威力是它能成为多 Agent 编排和闭环自愈的黏合剂。一个运行良好的系统往往是这样的外部调度器读取 Routine 配置按步骤依次触发执行。每个步骤可能对接到不同的 Agent。如果某一步失败自愈模块捕获错误按预设策略选择重试或派发修复任务。修复完成后Routine 从失败的那一步继续往下跑而不是从头再来。这就像给 Agent 装了一套“工作流操作系统”编排负责把活分下去自愈负责处理异常Routine 负责让一切可重复、可沉淀。所以我不建议把这些概念拆开看。你在实践时可以先把一个高频的重复流程做成 Routine再在旁边加上一个简单的失败检测与重试循环。跑通了再逐步拆出多个 Agent 角色。这样循序渐进比一开始就追求一个大而全的平台要稳妥得多。5. 实操记录从零搭建一个多 Agent Routine 系统5.1 环境准备与 Claude Code 安装这一部分的某些操作属于常见实践具体版本和命令以官方文档为准。我在 macOS 上的安装很简单用 npm 全局安装就行npm install -g anthropic-ai/claude-code如果是 Linux 环境同样适用但需要你先确认终端的网络环境能正常访问官方 API 服务。安装完成后第一步是登录与鉴权。Claude Code 一般会在首次运行时跳转浏览器完成授权拿到会话密钥后保存在本地。注意这里不要用任何非官方代理或转发服务直接按官方提示操作即可。安装好后我习惯先验证一下版本和工作状态claude --version claude -p hi # 非交互模式输出一句话确认链路正常如果能在终端里得到正常输出说明基本环境没问题。接下来可以看目录下的.claude配置一个项目可以放一个共享的 CLAUDE.md相当于给所有 Agent 读到的项目说明书。我通常会把项目结构、常用命令、代码规范、模块边界都写进去。这个文件是多 Agent 编排中很重要的“公共记忆”。5.2 任务拆解与 Agent 角色定义一次真实场景是我要给一个旧服务增加一个“导出报表”功能涉及后端接口、前端页面、测试和文档。如果只开一个会话Agent 需要同时处理数据库查询、Excel 生成、前端表格展示和接口文档上下文很快会爆。我选择拆成四个角色Agent A后端负责新增导出接口处理查询参数、超时设置、文件流返回。Agent B前端负责生成导出按钮、请求接口、处理下载与错误提示。Agent C测试负责补充接口集成测试和前端交互测试。Agent D审查负责在合并前检查接口规范、异常处理和潜在安全风险。我会用独立的终端会话启动每个 Agent每个会话的 CLAUDE.md 通过参数或目录切换加载不同模块描述。为了让协作不混乱我会让每个 Agent 都遵守同一个输出协议结束工作时输出“修改文件列表 验证命令 结果状态”。这样最后我或者总控脚本只需要收集四个会话的输出就能快速判断哪里掉了链子。5.3 编写 Routine 脚本含代码示例有了角色定义后我把调度过程写成脚本。下面是一个简化但可运行的 Python 示例展示如何顺序调用不同 Agent并在失败时做条件重试import subprocess import json import time def run_claude(prompt, agent_name, max_retries2): for attempt in range(max_retries 1): result subprocess.run( [claude, -p, prompt, --output-format, json], capture_outputTrue, textTrue, ) if result.returncode ! 0: print(f[{agent_name}] 执行失败: {result.stderr[-500:]}) if attempt max_retries: print(f[{agent_name}] {attempt 1} 次重试...) time.sleep(3) continue return None try: data json.loads(result.stdout) return data.get(result, ) except json.JSONDecodeError: return result.stdout return None def main(): tasks [ { name: backend, prompt: 新增导出接口参考 docs/api.md修改后跑 pytest 接口测试, }, { name: frontend, prompt: 增加导出按钮和下载逻辑修改后跑前端构建, }, { name: test, prompt: 补充端到端测试用例确保导出功能覆盖正常和异常路径, }, ] results {} for task in tasks: print(f 开始执行 {task[name]} ) output run_claude(task[prompt], task[name]) if output is None: results[task[name]] FAILED else: results[task[name]] OK with open(foutput_{task[name]}.md, w) as f: f.write(output) failed [k for k, v in results.items() if v FAILED] if failed: print(失败任务:, failed) else: print(全部完成) if __name__ __main__: main()这个脚本足够做演示真正生产化时我会加上并行执行、日志归档和更精细的失败分类。核心思路是用代码把 Agent 一个个“喂”进流程而不是靠人手工复制粘贴提示词。5.4 接入闭环自愈的完整流程上面的简单脚本只有“失败重试”还没有“自愈修复”。完整的做法是引入判断逻辑当某个 Agent 失败时先读取其输出日志如果日志包含明确的代码错误就构造一个修复任务派给同一个 Agent 或另一个专门的修复 Agent。我经常用的方式是当普通重试两次仍失败就调用一个“诊断 Agent”diagnose_prompt f 请分析下面这段失败输出判断问题原因并输出结构化 JSON。 字段failure_type(env/code/requirement)summary(一句话概述)fix_hint(修复建议)。 失败输出: {error_snippet} 拿到诊断结果后我根据failure_type决定后续动作env等 10 秒后重跑原任务。code把fix_hint附加到新任务里交给执行 Agent让它读取相关文件并生成补丁。requirement停止流程把问题返回给规划者或者人工处理。在集成测试里这套机制的效果很直观。有一次测试脚本因为缺少临时文件权限而失败诊断 Agent 判定为环境类问题自动修改了目录权限后重新跑通另一次是代码里有一个空指针诊断 Agent 判定为代码类问题派给后端 Agent 修复后回归通过。整个过程我几乎没有介入。5.5 实测效果与关键参数调优搭好这套系统后我做了一轮实测一个包含 12 个文件的模块改动从拆任务到全部测试通过整体跑了大约 11 分钟。如果靠单步聊天我估算至少要 40 分钟以上而且我还要全程盯着上下文。这个效率提升很大但也不是没有代价多 Agent 并行和多次重试会消耗更多 token我在调优时总结了几个关键参数。第一重试次数不要设太高。来自环境的瞬时失败重试一次就够代码逻辑问题重试超过三次基本是在浪费 token不如切换路径。第二Agent 的 prompt 越聚焦输出越稳定。我会给每个任务限定“你必须使用项目里的测试命令不要重新设计测试框架”之类的硬性约束。第三日志记录要适度。只记录结构化摘要不记录全部 stdout否则日志文件会比代码还大反而没法快速排查。成本方面我会为每个 Agent 任务设置一个最大 token 预算。比如后端 Agent 最多执行 20 万 token超过就中断并报告。这个预算可以写在脚本里也可以通过 Claude Code 的上下文管理参数调。核心原则是宁可中断一个跑偏的任务也不要让它无限生成无用代码。6. 常见问题与排查技巧实录6.1 多 Agent 之间上下文冲突怎么办这是最常见的问题。两个 Agent 同时改同一个文件或者一个 Agent 改了公共类型另一个 Agent 还在用旧签名。我的解决方法是在任务启动前生成一份“共享契约文件”里面记录所有跨模块使用的接口签名、关键类型定义、文件职责说明。每个 Agent 启动时都会被要求先读这份契约再开始改代码。如果仍有冲突我会在自愈逻辑里加一个“变更冲突检测”步骤检查同一文件是否被多个任务同时修改如果发现就触发一个合并 Agent 去解决冲突。还有一个土办法但很有效把工作目录按 Agent 隔离每个 Agent 有一个work_目录最终再统一合并。合并时不要用 git 自动合并而是让审查 Agent 逐个文件做一致性检查。这样成本高一点但能避免很多隐性 bug。6.2 自愈误判导致死循环怎么破自愈机制本身也可能出错最常见的是死循环。比如一个 Agent 每次修复都会引入新的语法错误然后系统又派它去修复无限循环烧掉大量 token。我现在的对策是给整个流程设置两个“刹车”一是总重试次数上限比如所有任务累计重试不超过 5 次二是“修复后回归测试未通过的次数”上限比如同一任务连续失败 3 次就停止改为人工介入。另一个问题是“修复通过但实际是作弊”。Agent 可能删掉了失败的测试或者给测试打了桩让结果看起来通过。这种问题要靠审查 Agent 来处理比较测试文件在修复前后的 diff如果发现删减了断言直接拒绝并打回。宁可不通过也不能让假绿混过去。6.3 Routine 脚本失效Agent 不按约定办事有时脚本明明写得很好但 Agent 就是“不听话”。我遇到过的情况包括要求 Agent 输出 JSON它却在 JSON 外面加了 Markdown 代码块导致解析失败要求它只改指定文件它顺手改了无关文件。排查这类问题我的经验是要在 prompt 里用“绝对句式”写约束并把关键格式要求放到 prompt 的最后一句模型对文末指令的记忆更强。同时在代码里加一层“防御式解析”比如用正则去掉代码块标记或者校验输出是否符合模式不符合就重试一次。如果仍然不遵守就要考虑是不是上下文太长约束被稀释了。这时候可以把约束写进 CLAUDE.md并且每次让 Agent 在开始工作前先“复述任务要求”。让其复述两到三句能显著提高遵守率。6.4 成本与资源消耗怎么控制多 Agent 编排、自愈重试、Routine 脚本都是 token 消耗大户。我控制成本的手段有几个。一是尽量用小参数模型处理归纳、摘要类任务不要每个环节都用最贵的模型。二是给每个 Agent 的 prompt 里明确“如无必要不要读取超过 5 个文件”避免 Agent 自己把一堆无关文件读进来。三是做好缓存项目里的接口定义、测试报告如果没变化就不必每次都重新生成。还有一个小技巧刚开始做自动化时先用一个小任务跑通流程观察每一步消耗了多少 token、耗时多少再决定哪些步骤可以精简。先把系统跑快再考虑跑贵。对于大部分个人项目或者小团队一个月几十万 token 的用量其实是可控的只要不是无限死循环。最后再分享一点个人经验从“单步聊天”切换到“多 Agent 编排 闭环自愈 Routine 脚本化”我踩过的最大一个坑就是一上来就想把所有流程自动化结果脚本比业务代码还复杂维护成本高到吓人。我现在更推荐的做法是先把手头最重复、最容易出错的一个流程挑出来写成一个可以手动触发的 Routine 脚本再加最简单的失败重试。跑顺之后再加入自愈诊断和多 Agent 拆分。每加一层都要确认它确实降低了你的介入成本而不是反过来把问题复杂化。另外多 Agent 编排的效果高度依赖任务拆分的质量。任务拆得越清晰、边界越明确、交付格式越固定整套系统就越稳。反过来如果需求本身模糊硬拆只会让错误被放大。所以我现在遇到模糊需求第一反应不是派 Agent而是先补需求文档。工具再强也替代不了自己想清楚这件事。这套架构还有一个值得继续扩展的方向把 Routine 脚本和 CI/CD 集成做成提交代码后自动触发多 Agent 审查、自动跑回归、自动生成发布说明的长线流程。对我个人而言它已经从一个“提高效率的工具”慢慢变成了“沉淀团队经验的基础设施”。如果你也正在被低效的单步聊天折磨希望这篇拆解能给你一个清晰的起步地图。