企业官网建设流程全解析

从"单步聊天"到"工程流水线"，这是我用Claude Code之后感受最深的一个转变。早期用Agent干活，基本是开一个对话窗口，把需求一股脑丢进去，然后就是漫长的对话拉锯：代码改一处、上下文乱一段，改到十几轮的时候模型连最初的约束都忘得差不多了。后来我开始把任务拆给多个子Agent协调执行，把出错后的诊断和修复流程做成闭环，再把高频动作固化成Routine脚本，才算真正把Claude Code当成一套工程体系在用。这篇文章就把这三块——多Agent编排、闭环自愈、Routine脚本化——拆开讲清楚，顺带把安装、模型接入、编辑器集成这些跑起来之前的事一并交代了。适合已经在用或准备用Claude Code做实际项目开发的读者参考。

1. 单步聊天的天花板：为什么复杂任务需要多Agent编排

1.1 单步模式的三个典型死法

先说结论：单步聊天不是不能用，是它只适合"一次改一个文件、需求一句话能说清"的场景。一旦任务变大，三个问题会依次冒出来。

第一个是上下文污染。Claude Code的上下文窗口再大也是有限的，但单步聊天不会帮你清理旧信息。改完A模块之后，A模块的中间产物、临时变量、失败尝试全堆在上下文里，等到改B模块时，模型还在被A的历史干扰。我实测过一个重构任务，单步模式聊到第16轮时，模型开始把旧的文件路径和新的目录结构混着用，生成的import路径全是错的，而且是那种肉眼很难一眼发现的错。

第二个是注意力漂移。任务拆得越碎，原始目标在对话里的权重越低。你第1轮说的是"重构支付模块，保持对外接口不变"，第10轮模型可能已经在改接口签名了，因为它顺着你中间的某句话理解成了新需求。没有人在全局层面盯着原始约束，方向就漂了。

第三个是责任不清。一个Agent从头做到尾，写代码的是它、review的也是它、测试的还是它，这等于自己考自己自己批卷。哪怕代码有问题，模型在同一个上下文里很难发现自己犯的错，因为它对自己生成的内容有路径依赖。我见过最典型的场景：模型写了一个有bug的函数，又写了一个能跑通的测试用例，但这个测试用例恰好绕过了bug分支——不是故意的，是它潜意识里在为自己的代码辩护。

1.2 多Agent编排的本质：任务分解与上下文隔离

多Agent编排解决的就是上面这三个问题。核心思路很简单：把一个大任务拆成多个子任务，每个子任务交给一个独立的子Agent执行，子Agent之间不共享完整上下文，只传递必要的信息产物。

这样做最直接的好处是上下文隔离。每个子Agent只看到自己的局部任务描述和输入文件，它不需要知道整个项目的来龙去脉，只需要把手里的活干好。这样既减少了token消耗，也避免了跨任务的上下文污染。

第二个好处是角色专业化。你可以让一个子Agent专门做代码审查，它的prompt里写满了"只检查代码质量问题，不改代码"；另一个子Agent专门做测试，它的任务是补测试并跑通。专业化之后，每个Agent的判断标准都更清晰，不会出现"既当运动员又当裁判"的混乱。

第三个好处是可审计性。每个子Agent的输入、输出、决策过程都可以独立记录，哪个环节出了问题一目了然。单步模式下，你很难回答"这段代码为什么这么写"这个问题，因为中间过程散落在几十轮对话里。

1.3 与LangGraph、AutoGen等编排框架的差异

市面上常见的Agent编排框架，像LangGraph、AutoGen，本质上是给你一套图结构或对话协议，让你在代码层面定义Agent之间的通信关系。它们很强，但也很重：你要自己写状态管理、自己设计图拓扑、自己处理Agent间的消息协议。

Claude Code的多Agent路线不一样。它内置在终端工作流里，不是让你从零搭框架，而是提供了一套原生的子Agent机制和Task Tool，你只需要在对话中用指令把任务拆给子Agent，由主Agent负责任务调度和结果汇总。听起来好像比LangGraph"轻量"，实际用起来也确实轻量——不需要额外写Python代码，不需要管理agent间的消息队列，一切都在CLI交互层完成。

代价是灵活性不如框架类方案。如果你想定义复杂的加权路由、动态扩展Agent数量，Claude Code这套原生机制会显得不够"可编程"。我的经验是：项目规模在中小型范围、Agent数量在十几个以内时，用Claude Code原生的多Agent编排就够了；真到了需要几十个Agent协作的大规模场景，再考虑上游编排框架也不迟。

2. Task Tool与子Agent：把编排落地

2.1 子Agent的边界怎么划

多Agent编排不是把任务随便切几块丢出去就行，切分粒度直接决定效果。我踩过的坑是：一开始恨不得把一个需求拆成十几块，结果一半时间浪费在子Agent之间互相传递信息上。

我的分法遵循三条原则。

第一条，按文件边界拆。一个子Agent尽量只碰一个或一组紧密相关的文件，避免两个子Agent同时修改同一个文件的冲突。比如"改订单模块"和"改用户模块"可以并行，"把用户模块的接口拼到订单模块"就必须串行。

第二条，按生命周期拆。生成、审查、测试这三个阶段天然适合不同角色的子Agent。生成Agent负责写代码，审查Agent负责找毛病，测试Agent负责验证。三个阶段串行执行，每个阶段用独立的上下文。

第三条，按职责分离拆。凡是涉及"检查"性质的工作，一定要从"执行"Agent里单独拆出来。我习惯在每次重构类任务里专门起一个reviewer子Agent，它的唯一任务就是挑毛病。效果立竿见影——挑出来的问题明显比同一个Agent自己做review时多，因为它就是被训练来找茬的。

2.2 一个代码仓库重构的编排实例

说一个我最近实际跑过的例子。任务是对一个老旧的Node.js服务做模块化重构，同时要求对外HTTP接口行为完全不变。按照单步聊天的玩法，这种任务基本要聊到天荒地老，而且很容易改坏接口自己还不知道。

我用Task Tool拆了四个子Agent，串行执行：

• 第一个子Agent是架构分析师。输入是老代码目录、接口文档、以及约束条件"对外行为完全不变"。输出是重构方案，标明每个模块的职责边界、依赖关系、迁移顺序。
• 第二个子Agent是执行者。输入是架构方案和原始代码，输出是重构后的代码文件，同时记录每一处可能影响外部行为的改动。
• 第三个子Agent是接口审查官。输入是重构前与重构后的接口定义、路由代码和请求处理逻辑，输出是一份差异报告，列出所有不一致的地方。
• 第四个子Agent是回归测试员。输入是重构后的完整代码和原测试套件，任务是补测试、跑回归，确保所有既有用例通过。

整个流程里，主Agent只负责传递产物和把控节奏，具体的技术判断全部交给子Agent。重构做完，接口差异报告为零，回归测试全绿。如果单步聊天来做，我估计至少要三轮人工提醒"注意保持接口不变"。

2.3 串行还是并行，以及成本平衡

子Agent不是开得越多越好。每开一个子Agent，就多一轮任务调度的token开销。而且子Agent之间的依赖关系处理不好，会互相等，时间上反而比单步聊天更长。

我现在的经验是：能并行的一定并行，但并行只发生在互不依赖的文件模块之间。比如上面那个例子里，架构分析阶段必须串行，因为后面的执行者要等方案出来；但执行阶段可以按模块拆成两三个子Agent并行改，只要它们不碰同一批文件。

另一个要留意的是上下文预算。Task Tool传出去的输入文件越大，子Agent读文件的token越贵。我在实际使用中会把输入先做瘦身——不是把整个目录丢给子Agent，而是先把相关文件的导出列表、类型定义、关键函数签名整理成一份摘要，再连带文件路径一起传。这样既保留了必要信息，又把token开销砍掉了不少。

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

3.1 闭环四步：执行、验证、诊断、修复

"闭环自愈"听起来玄乎，本质上就是把这四步串成一个自动循环：执行任务、验证结果、诊断失败原因、执行修复，然后回到验证环节。循环什么时候停？要么验证通过，要么达到预设的重试上限。

我在Claude Code里跑自愈循环的典型姿势是：让它跑一段测试脚本，如果退出码非零，就把stderr内容回传给它；它根据报错信息定位到具体文件和行号，改完代码之后再跑一次测试；如果还失败，再读新的报错，再改。这个循环可以重复N次，直到测试通过或者连续几次没有进展。

关键在一个"诊断"环节。很多实现只做了"失败后简单重跑"，没有诊断，结果就是同一个错误反复触发、反复重试，纯烧token。真正有效的自愈循环，必须让Agent在重试之前先形成对错误原因的判断——是代码逻辑错、环境配置错、还是测试本身写错。判断对了，修复一步到位；判断错了，再重试多少次都没用。

3.2 一次实际的自愈过程复盘

说个具体案例。我在一个数据处理脚本里用Claude Code做自动化测试，脚本逻辑是读取CSV、按日期分组聚合、输出统计结果。测试用例有一个是校验时区边界，要求把UTC时间转成本地时间后归类到正确日期。

第一次跑测试，失败。报错信息指向某个断言：期望"2024-01-01"这一组，实际输出却落在"2023-12-31"。如果按无脑重试的玩法，模型大概率会重复同样的修复：改断言、或者改时间格式代码，然后继续失败。但有了诊断这一步，Claude Code先把测试代码和被测代码各读一遍，然后判断：被测代码用了new Date()取服务器本地时区，而容器默认时区是UTC，导致边界时间被归到了前一天。

诊断正确之后，修复方案很清晰：不是改业务逻辑，而是让时间处理显式使用配置的时区，并在测试初始化里设置固定时区。改完重新跑，断言通过。

这个案例的关键不在修复本身，而在于它是"诊断驱动"的修复。如果模型不花那两步去看测试代码和被测代码，而是直接尝试把日期串加一小时，大概率会引入新问题。所以我的经验是：配置自愈循环时，一定要约束它"在输出修复方案前，先把错误分类写出来"，哪怕这段分类文字不直接产出代码，也值得花这个token。

3.3 自愈的边界：什么场景必须喊停

自愈不是万能的，有些场景让它自己折腾反而是灾难。

第一个要喊停的场景是"错误模式长时间不变化"。如果连续四五次重试，报错信息还是同一个，说明Agent的诊断方向可能错了。这时候需要人工介入，或者强制换一条诊断路径，比如让它去读官方文档、搜索历史提交，而不是继续在同一块地方打转。

第二个要喊停的场景涉及不可逆操作。如果Agent可以在自愈过程中执行数据库迁移、删除文件、推送远端分支这类操作，必须在上游就把这些命令禁掉。我在Claude Code里给自愈循环单独配置了权限白名单，默认只开放编辑文件、运行测试、读取日志这三类操作，其余一律拦截。

第三个要喊停的场景是成本失控。自愈循环是token消耗大户，尤其是长上下文的循环。我一般设置最多三轮自愈，三轮没搞定就直接把错误详情整理出来汇报，而不是无限重试。这既控制了成本，也倒逼Agent在有限轮次内提高诊断质量。

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

4.1 Routine到底解决什么问题

在单步聊天的模式下，同类型的工作每次都要从零开始攒一套上下文。比如"帮我做一次代码审查"，理论上每次应该检查的内容都差不多：潜在bug、安全漏洞、性能问题、过度设计。但如果你每次都靠脑子里临时攒这些点，第一轮输出一定是不完整的，得靠你一条一条追问才能补全。

Routine脚本化的思路，就是把这一类高频工作流的输入、约束、检查清单、输出格式全部固化下来，变成一条命令或一个可复用的任务模板。执行的时候，只需要输入这次的具体目标（比如"审查src/目录最近的改动"），Routine会自动带上全套约束和流程定义。

这带来的提升不是"少打几个字"这么简单。固化之后，每次执行的检查标准是一致的——不会因为今天状态不好就少查一轮安全项，也不会因为Agent版本更新就丢掉某个你调试了很久才总结出来的注意事项。Routine本质上是在给Agent注入你已经踩过的坑。

4.2 一个可复用的Code Review Routine示例

我用Claude Code做代码审查比较多，这里给出一个固化成Routine的实际例子。核心思路是：外部输入一个代码路径，Routine固定一套审查流程。

工作原理是这样的：我把审查流程定义成一段模板文本，放在固定的指令文件里。执行时用一次性的CLI调用，把项目路径和目标注入进去。如果需要交互式运行，也可以在Claude Code的交互会话里引用这个模板。

模板文本的关键内容大致如下：

You are performing a code review. Review target: {target_path} Follow this checklist strictly: 1. Read the target files first, list all changed functions and exports. 2. Check for these issue categories in order: - correctness: null/undefined, off-by-one, race condition, error handling - security: injection, unsafe deserialization, hardcoded secrets, missing auth - performance: N+1 queries, unbounded loops, excessive copying - maintainability: dead code, duplicated logic, unclear naming 3. For each issue, output one item with: - severity: critical / major / minor / nit - file and line number - explanation in one sentence - suggested fix (code snippet only if under 10 lines) 4. At the end, output a summary table sorted by severity. Do not modify any files.

这段模板看起来简单，但实际效果比随机发挥稳定得多。几点体会：

• 强制了"先读文件再列问题"的顺序，避免模型凭经验瞎猜代码内容。
• 问题分类固定，每类都有具体的检查点，覆盖面稳定。
• 明确禁止修改文件，防止review Agent顺手改代码。
• 输出格式固定，便于对接后续自动化处理。

4.3 Routine与Hooks、CI/CD的串联

Routine固化了工作流，但真正让它发挥价值的是和环境绑定。我目前在自己的项目里做了这样几层绑定：

第一层是git pre-commit hooks。提交前自动跑一轮简化版的代码质量审查Routine——只查critical级别的问题，有就直接拦下，没有就放行。这一层的价值是拦截低级错误，成本很低，因为只查最近改动。

第二层是CI流水线。合并请求触发时，跑完整版的审查Routine和回归测试Routine。和第一层的区别是，这里跑的是全量检查，输出报告会附在PR评论里。全部通过才允许合并。

第三层是日常的开发循环。针对"新功能开发、补测试、跑测试、修错"这种高频循环，我也做了一条开发型Routine。它固定完整个循环的执行顺序，避免了每次都要在交互对话里重新描述"先干什么后干什么"。

串联之后，我的很多工作变成了"提交代码，然后等CI的报告"。Agent在后台自动完成审查、测试、修复建议这些环节，我再根据报告决定是合并还是让Agent继续修改。这比在终端里一条一条聊，效率高了一整个量级。

5. 装好、接入模型、接进编辑器：跑起来之前的准备工作

5.1 安装方式与版本验证

聊完了架构层面的东西，回到最基础的问题：Claude Code到底怎么装。实际上手的时候，安装本身不难，但有些细节不弄清楚后面容易卡壳。

官方推荐的安装方式是命令行全局安装。安装完成后，在终端输入claude就可以进入交互界面。验证安装是否成功，除了看版本号，我更建议直接跑一条最简单的指令，确认CLI能正常工作。

Project的安装不是终点，我通常会做两件事：一是确认当前CLI版本，二是确认和编辑器扩展的版本是否匹配。不同版本之间偶尔会出现新特性不兼容的情况，比如旧版的CLI在解析某些多Agent指令时行为不一样。

5.2 用CC Switch管理多模型接入

很多人不满足于只用一个默认模型，会希望在一个CLI前端下切换不同模型供应商。我自己的做法是用CC Switch这类配置切换工具来管理多套模型接入。

为什么需要这种工具？因为Claude Code本身是一个harnass式的壳，模型接入靠的是环境变量和配置文件的组合——不同的模型供应商对应不同的接口地址、API Key、模型名称。如果你不想每次都手动改环境变量，那就需要一个配置管理器，把几套配置存好，随时一键切换。

具体的流程不复杂：

• 准备各供应商的API接口地址和密钥。
• 在CC Switch里创建多套配置，每一套对应一个模型供应商，填好接口地址、密钥、默认模型名。
• 切换时选中对应的配置，CC Switch会帮你把环境变量重写到当前shell会话或全局配置里，然后启动Claude Code。

实际使用中要注意一个坑：各家模型对上下文长度的支持不一致。同一个多Agent编排任务，在上下文支持较小的模型上很容易提前截断。所以如果你计划在多个模型之间切换，建议把任务拆得更碎一些，或者优先选择上下文长度更大的模型跑复杂任务。

5.3 环境变量、API Token与权限配置的常见坑

接入第三方模型时，最容易出问题的三个点，我逐个说一下。

第一个是接口地址必须带对协议和后缀。很多人填接口地址时漏了路径后缀，导致请求404。这个报错通常在第一次对话时就会暴露，排查方式是先调试接口本身。

第二个是模型名称要和供应商实际支持的命名一致。同一个模型可能同时存在基础版和增强版，名称不同。如果填错模型名，API会直接拒绝。所以切换配置后，不要急着跑大任务，先用一条极短的指令试探通了再上重量级任务。

第三个是Token的读取优先级。Claude Code会先从命令行参数读API Key，再从环境变量里读，最后才看配置文件。很多人改了配置文件里的Token，但环境变量里还残留着旧值，导致实际生效的还是旧Token。排查时可以把环境变量列表打印出来检查一遍。

至于编辑器集成，VSCode这样的主流IDE都有对应的插件方式。装好插件之后，关键是把CLI可执行文件的路径指对。插件本质上还是调用命令行后端，只是把对话界面嵌进了编辑器面板。配置好后，在编辑器里选中代码就能直接发起Agent操作，比切到终端粘贴代码方便不少。

另外，关于账号登录的问题：登录状态下会走官方账号体系，能同步历史会话和部分配置；不登录时也可以作为harness配合第三方模型接口使用，只是历史同步等功能就不可用了。这个取决于你的使用场景，没有绝对的好坏。

5.4 安装之后最容易忽略的权限配置

Claude Code在终端里是有实际执行命令的能力的。这意味着权限配置直接决定了它能碰你系统的哪些部分。我的建议是最小权限原则：默认禁止所有高风险操作，按需放行。

我日常使用的权限配置大致是这个逻辑：

这套策略看起来保守，但用下来反而顺。它的好处是让Agent在大部分情况下可以放手干活，到了关键决策点才停下来问你。真正的风险往往不是Agent能力不够，而是权限给得太宽后，一个错误诊断可能导致不可逆的破坏。

6. 边界与体感：这套玩法适合什么，不适合什么

6.1 我实测后觉得最值的场景

用了这套组合拳大半年，我觉得性价比最高的场景是这三类。

第一类是存量项目的模块化重构。因为重构的约束非常明确（行为不变、接口不变），非常适合拆成"分析、执行、审查、回归"四个子Agent的流水线。每一轮的产出都可验证，不像新功能开发那样目标模糊。

第二类是"写了代码但没人review"的个人项目。用Routine固化一套审查流程之后，每次提交都有机器人帮你从bug、安全、性能、维护性四个维度过一遍。虽然比不上资深工程师的真人review，但至少能把低级问题拦在提交前。

第三类是CI挂掉之后的自动修复循环。以前CI失败，流程是：看日志、定位问题、改代码、重新提交，忙活半小时。现在CI挂了，我把错误信息交给自愈循环，大部分简单问题三轮之内自己修好了；修不好它也会把诊断结论整理好等我接手，省去自己翻日志的时间。

6.2 不太适合的场景，以及我为什么这么说

反过来，有三类场景我试过之后发现效果一般，现在基本不用这套玩法。

第一类是需求本身高度模糊的探索型任务。比如"帮我想个新功能"，这种任务需要的是发散思维和多轮对话的碰撞，拆成子Agent去做反而会把思路切碎。多Agent编排和自愈循环都是为"目标明确、可验证"设计的，目标和验证都不存在时，拆解没有意义。

第二类是强依赖隐性知识的任务。如果团队代码库里有大量不在文档里的约定、只有老人才知道的潜规则，Agent在没有这些上下文的情况下容易产出风格割裂的代码。这时候不是编排的问题，是知识库没建好。先把Routine里那些项目特定约定积累成文件，再上Agent，才是正路。

第三类是对响应延迟极度敏感的交互场景。多Agent编排再怎么优化，也要经历任务调度、上下文传递、结果汇总这些环节，时序上必然比单次对话慢。如果你只是需要一个快速的回答或一次简单的文件修改，请直接开一个普通会话，别上多Agent这套重武器。

6.3 成本控制的一点小心得

最后聊一下钱的事。这套玩法确实是token消耗大户——子Agent的调度、自愈循环的重试、Routine里每次都带的超长模板文本，每一环都在增加token支出。

我的成本控制三板斧：

第一，给自愈循环设轮次上限。这个前面说过了，最多三轮，三轮解决不了就直接汇报。

第二，把Routine模板里的内容做"按需裁剪"。不是所有审查都要全量跑，日常提交只跑critical级别，合并请求才跑完整版。

第三，善用本地执行和缓存。有些前置步骤（比如拉取仓库、构建依赖）其实不需要Agent来做，用Shell脚本在本地搞定，让Agent只处理最需要智能的部分。省下来的不只是token，还有时间。

这半年下来，我的最直观感受是：Claude Code的价值不在于它能在单次对话里给出多惊艳的回答，而在于你愿意花多少精力去设计围绕它的工作流。多Agent编排给任务搭好了骨架，闭环自愈让流程有了纠错能力，Routine脚本化则把一次次重复劳动沉淀成可持续复用的资产。这三者组合起来，才真正把Agent从"聊天工具"升级成了"工程流水线"。