企业官网建设流程全解析

1. 告别单步聊天：先搞清楚多 Agent 编排到底在解决什么问题

我刚接触 Claude Code 的时候，说实话，它给我的第一印象就是一个长在终端里的高级聊天框。你能让它读文件、改代码、跑命令，但整个交互模式还是单步的：你提一个需求，它改完，你 review，发现问题，再丢回去，它再改。如此循环。单看每一步，AI 都很聪明，但站在一个完整需求的维度上看，你会发现整个过程其实是低效的——上下文在轮次之间不断丢失，你作为人类被迫在每一条反馈链路里当人肉路由器。

后来我慢慢摸到了 Claude Code 真正的价值所在：它根本不是给你“聊天”用的，它是给你“编排”用的。所谓多 Agent 编排，就是让主 Agent 不再事必躬亲，而是像项目经理一样把任务拆解给不同的专业子 Agent——有人写代码，有人审代码，有人跑测试，有人查文档——再由主 Agent 收集结果、处置冲突、推进下一个阶段。配合闭环自愈和 Routine 脚本化，你会发现自己从“盯着 AI 干活”变成了“定义流程，让 AI 自己跑完整个流程”。

这篇文章想跟你聊的就是这三件事：多 Agent 怎么编排、闭环自愈怎么落地、Routine 脚本怎么设计。不写官方文档式的一二三条，只讲我实际踩过坑之后沉淀下来的方案。适合谁看？如果你已经用 Claude Code 做过一些简单任务，但觉得它“也就那样”，或者你想把 AI 编程从“玩具”推进到“生产力工具”，这篇值得你花十分钟读完。

2. 多 Agent 编排实战：角色划分、任务拆解与协作机制

2.1 为什么一个 Agent 撑不住大型任务

很多人会问：一个 Agent 不也能多轮对话吗？让它先设计再实现再测试，不就行了？理论上是，但实际跑过几个中型任务你就会发现单 Agent 的命门：上下文窗口是有限的，而大型任务的“必要上下文”增长是线性的。你让一个 Agent 从头跟到尾，它前十分钟记住的设计决策，可能在中途就被新的代码片段挤出了上下文窗口。

更麻烦的是职责混杂带来的注意力稀释。一个 Agent 既要思考架构，又要写具体实现，还要自查 bug，它的注意力会在这几件事之间反复横跳。就好比你让同一个工程师同时当架构师、开发、测试负责人，他每个角色都只能做到“及格线”。我在实践中发现，超过 300 行有效代码变更的活儿，单 Agent 的质量就开始明显下滑——要么忘了最初的设计约束，要么测试覆盖不全，要么改完 A 文件忘了同步 B 文件的接口调用。

多 Agent 编排的核心思路，就是把“一个人干所有事”变成“一个项目经理协调一组专业员工”。每个子 Agent 的上下文只装载它职责范围内的信息，承载压力小，专注度高，而且主 Agent 可以在子 Agent 返回结果后做统一的整合与校验。这才是 Claude Code 真正拉开差距的地方。下面我直接给你看怎么落地。

2.2 用子 Agent 定义专业化角色：一个 Markdown 文件就是一个工种

Claude Code 支持在项目里自定义子 Agent（subagent），本质上是.claude/agents/目录下的一个个 Markdown 文件。每个文件用 YAML frontmatter 声明这个 Agent 的职责、可用工具、模型等级，正文部分就是它的系统提示词，告诉它在自己的职责范围内该如何思考、如何输出。主 Agent 在执行任务时，会根据候选子 Agent 的 description 自动判断要不要调用，以及把哪部分任务委托出去。

我习惯在每个项目里先建三个固定角色：实现者、审查者、测试者。给你看一下其中一个的完整定义，这是我在.claude/agents/implementer.md里写的：

--- name: implementer description: 负责具体的代码实现。适用于需要新增功能、修改逻辑、重构代码的任务。当主任务明确要求写代码时使用。 tools: Read, Write, Edit, Bash, Grep model: sonnet --- 你是一名资深后端工程师，擅长 Go 和 Python。你的职责是实现主 Agent 分配给你的具体编码任务。 工作准则： 1. 动手前先列出对现有代码影响点的清单，标注出需要同步修改的文件。 2. 每个文件修改完成后，用一句话说明你改了什么、为什么这么改。 3. 如果发现任务描述中有歧义，不要自行假设，把问题列出来返回给主 Agent。 4. 不修改与任务无关的代码，不做顺手优化，那是审查者的职责。 5. 所有代码必须附带必要的错误处理，不允许吞异常。

注意这里的两个关键字段：tools限制了它能动的东西，model指定用什么档位的模型。我的经验是，实现类任务用 sonnet 档性价比最高，而涉及全局架构设计的角色才值得用 opus 档，否则 token 消耗会非常快。另外子 Agent 的 description 写得越精确，主 Agent 的调度就越准。描述里要写清楚“什么情况下用它”，而不是写“它是一个程序员”。

2.3 一个前端+后端+测试的编排示例

理论说再多不如看一次实际调度。假设我现在要加一个“用户积分排行榜”功能，涉及后端接口、前端页面、单元测试三块。如果单 Agent 来做，它会在一个上下文里来回切三块代码，最后大概率出现接口字段名前后不一致的问题。

多 Agent 编排下的流程是这样的：主 Agent 先读取需求文档，拆出三个子任务，然后调用 implementer 写后端接口，等它返回后再调用另一个 implementer 实例（或者同一个）写前端页面，最后把两边的接口约定交给 tester 去写测试。每一步返回后，主 Agent 都会做一次“连接点校验”——检查前端调用的 URL 路径、参数名和后端实现是否完全一致。

你可以直接在终端里这么跑：

claude -p "请完成这个需求：在现有电商项目中新增积分排行榜功能。先读取 requirements.md，拆解任务，然后按后端接口、前端页面、单元测试的顺序分别交给对应的子 Agent 执行，每步完成后校验接口字段一致性。"

关键心得是：不要让子 Agent 自己决定流程顺序，顺序和验收标准必须由主 Agent 定死。子 Agent 是执行者，不是决策者。否则三个子 Agent 各自为政，最后你要花更多时间去缝补它们之间的缝隙。真正的编排工作发生在主 Agent 的任务描述里——你的拆解越细、验收标准越明确，最终产出的集成质量越高。

3. 闭环自愈：让 Agent 自己发现问题、修复问题、验证修复

3.1 从“开环”到“闭环”：差的就是那条反馈回路

聊完多 Agent，下一个关键词是闭环自愈。简单说，开环模式是：AI 改完代码，停下来，等你 review，你发现问题，再让它改。闭环模式是：AI 改完代码后，自动跑测试，发现失败，读取报错，分析原因，再次修改，再次跑测试，直到通过或达到重试上限，才把结果汇报给你。

这个理念并不是 Claude Code 独有的，CI/CD 里早就有类似思路，但把它放到 Agent 的实时工作流里，体验是完全不一样的。闭环自愈解决的最大痛点是“上下文断裂”。你想想开环模式下的真实场景：Agent 改完代码，你花十分钟 review，发现问题，再把问题描述给它——此时它的上下文可能已经不是刚才写代码时的状态了，它甚至可能忘了自己当初的实现意图。修复质量自然打折扣。

而闭环模式下，测试失败的信息、堆栈、日志是直接在同一轮上下文里反馈给 Agent 的。它不需要你去翻译问题，它看到的就是原始错误信息，修复路径最短、最直接。我用下来的感受是：对于“测试挂了—修—再挂—再修”这类循环，闭环自愈能把原本需要来回五轮的交互压缩到一轮自动完成，而且修复质量明显更高，因为它始终带着完整上下文。

3.2 用非交互模式搭一条最小可用的自愈循环

Claude Code 的-p（print 模式）参数天然适合做这件事。它让 Claude 以非交互方式执行一条指令，执行完直接输出结果并退出，非常适合脚本化调用。我常用的自愈循环命令长这样：

claude -p " 运行 npm test 执行测试。 如果有失败的用例，按以下步骤处理： 1. 读取失败信息，定位到对应的源码文件。 2. 分析失败原因，修改源码。 3. 重新执行 npm test。 4. 重复以上步骤，最多 5 轮。 5. 5 轮后仍然失败，列出当前所有失败用例和你的修复尝试，停止。 "

这段指令的核心是给 Agent 限定重试轮次和退出条件。我见过很多人写自愈循环时忘了设上限，结果 Agent 在一个永远修不好的问题上空转十几轮，白白烧掉大量 token。5 轮是我试出来的经验值——如果同一个测试 5 次迭代还过不了，说明问题可能出在需求本身或架构方向上，应该把问题交回给人类决策，而不是让 AI 继续盲目打转。

还有两个实用 flag：--max-turns可以控制整轮对话的最大轮数，防止失控；--dangerously-skip-permissions可以跳过权限确认，让 Agent 自动执行更多命令。后面这个 flag 我建议只在隔离环境或可随时回滚的 git 分支上使用，具体原因下文展开。

3.3 自愈的“刹车”：没有安全护栏的自动修复就是灾难

让我给你一个反面教材。有次我在一个接近生产环境的分支上跑自愈循环，没设 git 回滚点，Agent 在修复一个测试失败时，为了“顺手”清理了一个看起来无用的函数——结果那个函数是另一个模块的公共依赖，直接导致另外 11 个用例失败。Agent 又继续“自愈”了十几轮，把项目改得一塌糊涂。

从那以后，我给自己定了几条硬规矩：

1. 跑自愈循环前，先git commit或至少git stash，保证有干净的还原点。
2. 给 Agent 设置“最小改动”约束，明确禁止修改与当前失败无关的文件。
3. 每次自愈结束后，无论如何都要人工 review diff，绝不直接合并。
4. 自愈只负责“修到测试通过”，不负责“重构优化”，那是另一个流程的事。

说白了，闭环自愈解决的是“已知目标下的执行效率”问题，而不是“决策质量”问题。你可以让 AI 放心地原地打转直到找到出口，但你不能让它在不熟悉的项目空间里横冲直撞。安全护栏的优先级，永远高于自动化程度。

4. Routine 脚本化：把高频工作固化成一条命令

4.1 Routine 的本质是“约定大于配置”

如果说多 Agent 解决的是“任务怎么拆”，闭环自愈解决的是“过程怎么稳”，那 Routine 脚本化解决的就是“重复的事怎么不再重复”。Routine 的本质，是把一段稳定、高频、复杂度适中的工作流，固化成一段可重复执行的指令或脚本。它跟普通 prompt 的区别在于：Routine 是经过验证的、有稳定输出的、可以被参数化的流程模板，而不是随手写的一段话。

我打个比方。普通 prompt 像是你每次做饭都凭着感觉放盐；Routine 像是你把自己验证过的菜谱写下来，下次直接照着做，只是根据人数调整一下分量。人的状态会有波动，但菜谱不会。Routine 也一样——它会过滤掉“今天心情不好导致 prompt 写得烂”这类随机性，保证每次执行质量的下限。

4.2 三个可以直接照抄的 Routine

我项目里最常用的三个 Routine，覆盖了日常开发里最高频的三类工作：Code Review、变更说明生成、测试补全。直接给你看实际脚本。

第一个是 Code Review Routine。以前我每次提交前都要人肉过一遍 diff，现在直接让 Agent 做第一轮：

#!/bin/bash # 用法: ./review.sh [commit_range] # 例: ./review.sh HEAD~3..HEAD DIFF_RANGE="${1:-HEAD~1..HEAD}" claude -p " 你是资深 code reviewer。请审查以下 git diff 范围内的所有变更： git diff $DIFF_RANGE 审查要点： 1. 找出可能导致运行时错误的逻辑问题。 2. 检查是否有明显的安全漏洞（如未校验输入、硬编码密钥）。 3. 检查是否有资源泄漏（未关闭的连接、未释放的内存）。 4. 对每个问题标注严重级别：P0 必修 / P1 建议修 / P2 可忽略。 5. 只输出问题列表，不要输出夸奖和总结。 "

注意第 5 条，我特别要求“只输出问题列表，不要输出夸奖和总结”。因为 Agent 默认会倾向于先夸你几句再提建议，这些客套话在脚本输出里完全是噪音。

第二个是变更说明生成 Routine。这个简单很多，核心是把 git log 转成规范的更新日志：

claude -p " 读取 git log --oneline -20 的输出，结合相关的代码变更， 生成一份面向用户的中文更新日志。要求： 1. 按功能、修复、优化分组。 2. 每条变更用一句话说明，面向非技术读者。 3. 不要编造代码里不存在的变更。 "

第三个是测试补全 Routine。写成脚本后，配合前面的闭环自愈，效果拔群：

claude -p " 请为以下目录中的新增/修改代码补全单元测试： $(git diff --name-only HEAD) 要求： 1. 先读取被测代码，理解其输入输出。 2. 覆盖正常路径、边界条件和异常路径。 3. 运行新测试，全部通过后才算完成。 4. 测试失败就修复测试或代码，最多重试 3 轮。 "

4.3 Routine 的进阶玩法：与多 Agent 和自愈组合成一条流水线

单个 Routine 是菜谱，多个 Routine 串起来就是流水线。我现在最高频使用的一条组合命令长这样：一条命令触发“代码审查 + 问题修复 + 回归测试”的完整流程。执行后，Routine 负责定义流程骨架，多 Agent 负责分配审查和修复的角色，闭环自愈负责让测试迭代自动收敛。整个过程完成后，我再人工过一遍最终的 diff。

这里有个执行上的细节：Routine 脚本里如果涉及多轮任务，建议加上--max-turns参数做总闸。我一般设 40 轮左右，既能覆盖复杂的修复流程，又不会让脚本在异常情况下无限跑下去。还有一点，脚本里的 Prompt 尽量用$(...)动态注入当前环境的信息（比如 diff 范围、文件列表），不要让脚本完全写死输入，否则复用性会大打折扣。Routine 的意义在于“稳定地处理变化的信息”，而不是“处理一份固定的信息”。

5. 环境搭建与第三方模型接入：从 npm 安装到 cc switch

5.1 官方安装、VS Code 集成与底层依赖

聊了这么多实战场景，该说说环境了。Claude Code 的官方安装方式非常直接——它是一个 npm 包，装好 Node.js 之后一条命令就能装。国内开发者的 Node 版本建议保持在 18 以上，我在老版本 Node 上遇到过安装后运行时崩溃的问题，升级后一切正常。

npm install -g @anthropic-ai/claude-code

装完后在终端输入claude就能进入交互模式。如果要在 VS Code 里用，官方提供了插件市场里的 Claude Code 扩展，装好后直接在编辑器里打开终端面板就能接入，省去来回切换窗口的麻烦。VS Code 集成最舒服的一点是点击代码中的报错可以直接让 Claude 解释或修复，不用自己复制粘贴代码片段。

登录方面，官方支持直接账号登录，也支持 API Key 方式。我个人的建议是：如果你只是偶尔体验，用账号登录最省事；如果你要跑脚本化 Routine 和高频自动化任务，请务必配置独立的 API Key，并在环境变量或配置文件中单独管理——因为账号登录方式在非交互模式下的配额管理和可观测性都差点意思，出现问题你都不好定位是谁在消耗额度。

5.2 注册与不注册的区别：上限决定你的用法

很多人问过我不注册能不能用。答案是要分两层看：第一层是能不能启动，第二层是能不能跑生产级任务。

不注册的方式，也就是完全以匿名身份通过 API 配置对接模型网关，前提是你得有一个兼容的 API 端点，然后通过环境变量指定。这种情况下工具本体能跑起来，也能做基础的代码问答，但每次会话的上下文长度和请求配额非常有限，我实测下来处理几轮简单对话还行，一旦跑多 Agent 编排或者闭环自愈这种长流程，很快就会撞到上限，过程中直接中断的体验很崩溃。

注册并完成身份绑定之后，才能拿到完整的多 Agent 调度、长上下文记忆、自定义子 Agent 这些核心能力。所以我的建议很明确：如果你只是尝鲜，不注册体验一下完全没问题；但如果你要把它当成日常生产力工具，别犹豫，直接注册并配置好正式凭证。这之间的体验差距，用一次多 Agent 编排任务就能明显感受到。

5.3 通过 cc switch 接入 DeepSeek、Qwen、GLM 等第三方模型

说到模型接入，很多朋友会问：能不能不依赖原生模型，走第三方 API？答案是完全可以，而且社区在这方面已经非常成熟。现在大家用得比较多的方式是借助 cc switch 这类 API 切换工具，在配置界面里填上目标兼容服务商提供的 API 地址和密钥，就能一键把 Claude Code 的底层模型切换到 DeepSeek、Qwen、GLM 这些模型上。

直接看一个典型的配置方式，本质上是在环境变量层面做覆盖：

# 以 cc switch 切换到第三方兼容端点为例 export ANTHROPIC_BASE_URL="https://your-provider-api.example.com/v1" export ANTHROPIC_AUTH_TOKEN="sk-your-key" export ANTHROPIC_MODEL="deepseek-chat" claude -p "用一段话介绍你现在能使用的模型能力"

切换之后要注意几个点。第一，第三方模型对工具调用的支持程度参差不齐。Claude Code 的核心能力依赖模型的 tool calling 质量，有些模型号称兼容，但实际跑起来工具调用的参数格式经常出幺蛾子。我建议你在切换后先跑一次简单的“生成代码然后执行测试”的流程验证，不要直接上生产级任务。

第二，不同模型在长上下文场景里的表现差异极大。多 Agent 编排恰恰就是典型的长上下文场景——主 Agent 要反复记住各子 Agent 的返回值。我实测下来，有的模型单轮对话表现很好，但上下文一拉长就开始丢前面的信息，导致编排链条断裂。所以如果你要做多 Agent 编排，优先选上下文能力强、工具调用稳定的模型，其次才是价格。

第三，cc switch 这类工具本身不生产模型，它只负责把请求转发到目标地址。因此你选的第三方服务商提供的 API 是否稳定、是否限流、是否有数据合规说明，这些都要自己提前确认好。网络连接层面的事交给正规服务商解决，不要贪便宜走来历不明的中转端点，否则你的代码和对话内容都过了一道不受控的转发，安全上不划算。

6. 常见问题与排查技巧实录

最后这部分，我把实际使用中遇过频率最高的几个问题整理成一个速查表，全是亲身踩坑换来的经验。不保证覆盖所有场景，但至少能帮你少走我走过的弯路。

补充一条排查思路：遇到诡异的配置问题，不要急着翻文档。先跑一条最小化的诊断命令，比如claude -p "输出当前模型配置和可用的工具列表"，看它在自己的视角里是怎么理解当前环境的。很多时候 AI 工具的问题不在于工具坏了，而是环境变量、配置文件或者插件版本之间的某个隐性冲突。让 AI 自己描述“它看到的自己”，往往比你瞎猜快得多。

另外关于在线升级，Claude Code 的 npm 包更新比较频繁，新版本经常带模型能力和工具调用层面的优化。我习惯每次月初统一跑一次升级并重新验证关键 Routine——这个节奏既不会太频密，又能跟上功能迭代。升级命令就是npm update -g @anthropic-ai/claude-code，升级完记得重启终端和 VS Code 窗口，否则插件侧可能还是旧版本。

我个人在实际项目里最深的体会是：Claude Code 这类工具的上限，根本不取决于模型多聪明，而取决于你多会定义流程。多 Agent 编排、闭环自愈、Routine 脚本化，这三件事本质上都是同一个动作：把不可控的、随机的、靠临场发挥的 AI 交互，改造成可控的、稳定的、可复用的开发流水线。刚开始搭这套体系确实需要一点耐心，但等你把第一条流水线跑通、把第一个 Routine 沉淀下来，之后每一次新任务都是在既有骨架上的增量工作，那种“一次配置、长期复用”的爽感，是真的会让人上瘾的。