企业官网建设流程全解析

最开始把 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_FILE="agent_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-level=high > /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_retries=2): for attempt in range(max_retries + 1): result = subprocess.run( ["claude", "-p", prompt, "--output-format", "json"], capture_output=True, text=True, ) 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(f"output_{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 审查、自动跑回归、自动生成发布说明的长线流程。对我个人而言，它已经从一个“提高效率的工具”，慢慢变成了“沉淀团队经验的基础设施”。如果你也正在被低效的单步聊天折磨，希望这篇拆解能给你一个清晰的起步地图。