企业官网建设流程全解析

聊到 Claude Code，我猜大多数朋友的第一体验都是：打开终端，敲一句话，等它回答，再敲一句，再等……这种单步聊天方式，做点小实验没问题，但一旦面对真实项目——改一个跨模块功能、重构几十个文件、跑通一整套 CI 流程——就会明显觉得心累。上下文在滚动中丢失、中间产物要人工搬运、出错后要手动把报错贴回去，本质上是把“思考”外包给了模型，把“流程”留给了自己。

这篇文章想聊的，就是我最近在实际项目里反复打磨的一套东西：基于 Claude Code 的多 Agent 编排架构，配合闭环自愈机制，再叠一层 Routine 脚本化封装。三个词拆开看不难，组合起来却能把“低效单步聊天”变成“高自由度的自动化团队”。如果你正在被“问一句答一句”的交互方式拖住，或者想把手里的 Claude Code 从“高级命令行助手”升级成“能自主推进任务的执行体”，这篇拆解应该能给你一个比较完整的落地方案。我会尽量把设计思路、实操配置、踩坑记录都摊开讲，而不是只给一堆概念。

1. 为什么单步聊天不够用：从“问答工具”到“任务引擎”的思维切换

1.1 单步聊天的三个隐藏瓶颈

先说一个我自己的别扭体验。早期用 Claude Code 做需求，基本是“人肉调度”：我给一句需求，它给一段代码，我拷进编辑器，跑测试，发现报错，再把报错复制粘贴回去让它修。这个过程看起来没什么问题，但放大到十次、二十次交互后，痛点非常明显。

第一个瓶颈是上下文衰减。Claude Code 本身有不错的记忆能力，但单轮对话的注意力会随着内容累积逐渐偏移，尤其当项目文件多、报错日志长的时候，后面几轮常常把前面已经确认的约束忘掉。比如我明确说过“不要改公共接口”，它可能在第三轮就把接口签名改了，起因只是我在后来的对话里贴了一段和接口无关的代码。

第二个瓶颈是中间产物断裂。真实开发任务往往不是“生成一段代码”这么简单，而是“调研现状 → 设计改动方案 → 修改 A 模块 → 同步修 B 模块的依赖 → 跑测试 → 修复回归 → 更新文档”。单步聊天模式下，每个环节都需要我手动把它从上一环节的结果“喂”给下一环节，一旦中间断了或忘了，整个链路就废掉。

第三个瓶颈是失败恢复成本高。一步错了，往往不能只改这一步。比如测试失败了，原因可能在代码逻辑、环境变量、依赖版本、甚至上一次修改留下的残留状态。单步聊天要我去把日志里最关键的几行挑出来，再翻译成清晰的指令。如果任务复杂，光是“定位问题”这一件事就能耗掉我半小时。

1.2 多 Agent 编排解决的是什么

多 Agent 编排的本质，是用一套固定的“角色结构”和“任务流转规则”，把原本需要我手动做的事情拆给不同的执行单元。这个概念听起来高大上，但落地到 Claude Code 里可以理解得很朴素：不要让它一个人从头干到尾，而是让它像一个小团队一样，有人负责读代码、有人负责改代码、有人负责跑测试，还有人负责验收。

我比较常用的一种比喻是把它想成一个外包团队。你（主 Agent）是项目负责人，不用自己动手写每一行代码，但你要定义清楚目标、验收标准、交付物格式。下面可以拆出“代码侦察兵”负责摸清现状、“编码执行者”负责改文件、“测试哨兵”负责跑测试和输出结构化结果。每个角色都在自己的上下文里工作，输出结果再汇回主 Agent。这样一来，某一个子任务的失败不会污染整个会话，上下文也能保持相对干净。

1.3 先把术语对齐：Agent、Subagent、编排器

很多同学一上来就被术语绕晕。这里我用最直白的话对齐一下：

• 主 Agent（ Orchestrator）：整个会话的调度中枢，负责理解目标、拆任务、收集结果、做最终决策。在 Claude Code 里，你交互的那个实例就是这个角色。
• Subagent（子 Agent）：被主 Agent 调用的执行单元，各自有独立上下文窗口，通常承担一类子任务。Claude Code 里可以通过特定方式把任务委派给子 Agent。
• 编排（Orchestration）：定义“谁先做、谁后做、结果交给谁”的流程规则，不是代码层面的框架，而是任务流转的设计模式。
• Routine：一组预先写好的、可复用的指令模板，类似于“把某个高频任务的标准操作步骤打包”，让主 Agent 遇到同类需求时直接走固定流程。

对齐这些词之后，后面的内容就不会绕了。我最想强调的是：多 Agent 并不是越高深越好，而是为了“让每一步都有明确负责人、可重试、可验收”。这个心智模型一旦建立，你再看各种编排框架都会觉得顺眼很多。

2. 多 Agent 编排的落地思路：拆分、流转与设计取舍

2.1 四种常见的编排模式，我实际用过的场景

网上天天讲 workflow 编排，但真正落到 Claude Code 里，常用的编排模式并不多，我按使用频率排一下：

第一种是链式编排。任务严格按顺序执行，前一步输出是后一步输入。最适合“调研 → 设计 → 实现 → 验证”这种流水线。优点是流转清晰，缺点是一环失败全线卡住。所以我在链式编排里会特别强调“每一环节都要输出结构化结果”。

第二种是并行编排。多个子 Agent 同时处理互不依赖的子任务，最后汇总。比如一个大项目里同时要改前端样式、后端接口、数据库迁移脚本，三者互相不依赖，我就可以拆开并行做。这个模式最考验拆解能力，如果子任务之间有隐式依赖，并行就会翻车。

第三种是主从编排（即 Master–Slave 风格，但称呼上我更习惯叫“主控-执行”）。主 Agent 负责统筹，子 Agent 被反复委派执行同类型工作，比如“给这三个文件分别补注释”。这个模式能显著提升一致性，因为每个子 Agent 拿到的指令模板是同一个。

第四种是协商式编排。多个子 Agent 互相评审、迭代方案，主 Agent 只做仲裁。这是我用得最少的，因为代价很高——几个 Agent 互相 review 时，token 消耗和上下文开销都很大。但遇到非常开放性的设计问题，比如新系统架构选型，它确实能给出比单 Agent 更全面的视角。

2.2 子任务拆分的三个原则

拆分决定了编排的上限。我踩过很多坑之后，总结出三条原则：

原则一，按交付物拆，不按文件拆。很多人习惯说“你改这个文件，他改那个文件”，但真实项目里文件之间耦合很重。更好的做法是按“可验收的中间产物”拆，比如“产出一份改动方案”“产出一份测试报告”“产出一段可运行脚本”。

原则二，每个子任务都要有明确的边界和退出条件。所谓边界，是子 Agent 只能改哪些目录、动哪些文件类型；所谓退出条件，是它做完之后输出什么才算合格。没有退出条件的子任务是灾难，因为它会无限发挥，产出大量你根本不需要的东西。

原则三，信息传递走结构化文本，不走聊天记录。子 Agent 之间的上下文本来就不共享，与其靠主 Agent 转述，不如约定好输出格式，比如 Markdown 表格、JSON 片段、固定字段的摘要。这一点对后面要讲的闭环自愈尤其重要，因为自愈逻辑需要靠“机器可读的结果”来判断下一步怎么走。

2.3 编排不是银弹：先问这三个问题

很多人一看多 Agent 就觉得“更智能”，但我会劝你先问自己三个问题。第一个：这个任务真的需要多轮迭代吗？如果只是写一个一次性脚本，单步聊天最省事。第二个：子任务之间的依赖是动态的还是静态的？静态依赖适合链式，动态依赖意味着你需要真正的规划能力，除非模型很强，否则别硬上。第三个：失败后的恢复成本你能接受吗？多 Agent 一旦中途乱了，排查要比单 Agent 复杂得多。

我的经验是，多 Agent 编排最适合的是“中等复杂度、结构化程度高、可反复执行”的任务。比如批量重构、代码迁移、测试补全这类，因为它们天然能拆成多个边界清晰的子任务。反过来，那种“灵感式”的探索性任务——比如“帮我想想这个新功能应该怎么做”——交给一个上下文充足的 Agent 可能更好。

3. 闭环自愈：让 Agent 从“会改”进化到“能修”

3.1 自愈的本质是反馈回路

闭环自愈这个词听起来很玄，但核心思想其实是一句运维老话：发现问题，修复问题，然后确认问题真的消失了。放到 Claude Code 的场景里，自愈就是让 Agent 在执行任务的过程中自动检查自己的产出，如果检查不通过，它就读取反馈（日志、测试结果、lint 输出），定位原因，修改重试，直到通过或达到重试上限。

这个机制的关键不是“让它认错”，而是“给它的错误配一个冷冰冰的检测器”。因为模型自己评估自己的代码，常常会自我感觉良好，觉得“应该没问题”。只有把检测器外置——真实去跑测试、真实去看编译输出——才能逼它正视失败。

3.2 三种最常见的检测器

我常用的自愈检测器有三种，按成本从低到高排列。

第一种是静态检查，也就是 lint、类型检查、格式检查。像 eslint、tsc、ruff 这类工具跑一遍只要几秒，而且输出格式非常规整，很适合让 Agent 解析。这是性价比最高的检测器，它能在代码动手前就拦住一大批低级问题。

第二种是单元测试与集成测试。测试的输出相对结构化，但信息量更大。难点在于，Agent 要学会区分“测试断言本身有问题”和“实现代码有问题”。实际跑下来，有时候是测试写得不对，有时候是测试环境缺依赖，这些情况都需要人工预置一些处理规则，否则它会陷入无效循环。

第三种是端到端验证，比如启一个本地服务、模拟调用一次 API、或执行一组冒烟脚本。这是最接近真实使用场景的检测器，但成本最高，速度最慢，失败原因也最复杂。我一般只会在关键交付物上用它。

3.3 一个典型的自愈循环长什么样

我以“修复一个 Python 项目的单测失败”为例，展示一个我自己封装的自愈循环：

第一步，主 Agent 收到目标：“让 test_user_service.py 全部通过”。第二步，运行命令pytest tests/test_user_service.py -x --tb=short，拿到测试输出。第三步，把输出交给一个专门的“分析子 Agent”，让它提炼出失败点和可能原因，写成一页短报告。第四步，主 Agent 根据报告，指派“编码子 Agent”去修改实现代码，注意限制它只能改动指定的业务代码和测试辅助配置，不能碰不相干的文件。第五步，改完以后重新跑测试。如果仍然失败，就让分析子 Agent 看看“上一次修改是否引入了新问题”，然后指定另一轮修改。第六步，如果连续三次失败，停止循环，把诊断报告交回给我，不做无意义的第 N 次重试。

这套循环看起来简单，但实际落地要解决几个细节。首先，重试次数必须限制，我通常设 3 次，太多会卡在同一个问题上烧 token。其次，每次修改后要输出 diff 摘要，避免它为了“让测试通过”而把测试本身删掉或改成无断言——这种情况我遇到太多次了。最后，每次失败的新报错，必须追加到之前报错的上下文中，不能覆盖。不然它修了一个问题又忘了上一个问题还没修完。

3.4 自愈的边界：它治不了环境病

我必须泼一盆冷水：自愈机制对“代码逻辑问题”非常有效，对“环境问题”会非常头疼。比如依赖版本冲突、端口被占用、权限不足、系统库缺失，这些即使 Agent 看到了报错，也很难在有限的重试次数里自己修好，因为修改环境本身就超出了它的安全操作范围。我的处理方式是：在进入自愈循环之前，先跑一个环境预检脚本，检查关键依赖和端口，把环境问题挡在门外。如果预检没过，就直接终止自愈流程，推给我人工处理。

4. Routine 脚本化架构：把高频流程变成“一键启动”

4.1 什么是 Routine，为什么它值得单独拿出来讲

如果说多 Agent 编排解决的是“任务怎么拆、怎么流转”，那 Routine 解决的是“这类任务的标准做法是什么”。我非常后悔没有早点意识到这一点——早期每次做一个相似任务，都要重新把细节描述一遍，然后看着 Agent 做出风格完全不同的结果。后来我把常见的操作流程沉淀成 Routine，效果立竿见影：结果一致性大幅提升，token 消耗降低了，因为不用每轮把上下文重新交代一遍。

你可以把 Routine 理解为一份“详细的岗位说明书”。它不是一句简单的“帮我重构这个模块”，而是写清楚：先读哪些文件、输出什么格式的方案、改动时遵守什么规范、用什么命令验证、失败后怎么办、最终交付物是什么。

4.2 一个合格的 Routine 应该包含哪些要素

根据我自己的沉淀经验，一份能用的 Routine 至少要覆盖五个要素。

第一是入口触发条件。明确告诉 Agent“什么场景下走这个流程”，避免它在不合适的任务里错误套用。比如我有一条“热修复 Routine”，触发条件是生产环境出现紧急 bug，它就不应该在正常功能开发里被触发。

第二是前置检查步骤。进入正式操作前，先确认环境、分支、相关服务状态。这一步看似多余，实际上能省掉大量的自愈循环。

第三是标准执行步骤。按顺序列出需要完成的事项，尽量细化到“运行什么命令”“读取哪个文件”“产出什么中间件”。这里的粒度要拿捏：太粗，Agent 会自由发挥；太细，一旦项目结构有变化，Routine 就失效了。

第四是自我验收项。定义“做完”意味着什么：测试通过？lint 干净？有 diff 摘要？有文档更新？没有验收项的 Routine 等于没有闭环。

第五是回退路径。如果中途失败，是否允许改文件？是否允许回滚？是否要保留现场日志？这些不写清楚，Agent 面对失败时行为会很随机。

4.3 Routine、多 Agent、自愈三者怎么组合

这三者不是并列的三个功能，而是一套分层结构。我理解的最优组合方式是：Routine 定义流程骨架，多 Agent 提供执行角色，自愈机制兜底质量。

用一个我常做的“新增一个 API 接口”任务举例。整套流程入口是“执行新增 API 的 Routine”。Routine 里定义了五个阶段：先产出接口设计文档，然后实现路由，然后写单测，然后跑自愈检查，最后更新接口文档。每个阶段对应不同的子 Agent 角色：设计阶段用“架构师子 Agent”，实现阶段用“编码子 Agent”，检查阶段用“测试子 Agent”。自愈机制嵌在检查阶段，如果单测失败，就自动进入重试循环。所有阶段的状态由主 Agent 统一跟踪，最后给我一份总结报告。

这个组合的好处是，我把“怎么做事”从“怎么对话”里解放了出来。我不再需要在每次对话里重新教它流程，只需要调用 Routine，然后在最关键的报告节点人工确认。相当于把一个临时工，升级成了一个带标准化作业程序的小分队。

5. 实操：从零配一套“多 Agent + 自愈 + Routine”工作流

5.1 环境准备：安装、登录与基本配置

先解决最基础的问题：Claude Code 怎么装起来。以目前的主流用法，装好 Node.js 之后，在终端执行安装命令，再按提示完成 Claude 账号的登录授权即可。装完之后，建议验证一下版本号，确认当前是最新版本，因为早期版本的子 Agent 调度能力差很多，后来几个版本才逐步加强了任务委派相关的功能。

如果你用的是 VSCode，可以考虑装官方提供的扩展插件，好处是能把 Claude Code 集成进编辑器，文件 diff、终端输出、当前 git 状态这些上下文都能更自然地被 Agent 感知。我个人体会是，插件模式更适合“在编辑器里边看边改”，终端模式更适合“跑批量任务”，两个场景别混着用。

登录方式上，注册账号和不注册账号的区别很明显：不登录的会话能力受限，复杂的编排大概率跑不动。所以别省这一步，先登录再把全局配置确认好。

5.2 用 CLAUDE.md 沉淀项目级约束

先说我用下来最关键的配置文件：项目根目录下的CLAUDE.md。这个文件相当于给 Agent 的“项目入职培训”，可以在里面写清楚项目技术栈、目录结构、代码规范、常用命令、禁止事项。

我会在这里放几类东西：第一，构建与测试命令的统一入口，方便后续自愈循环直接调用；第二，路径和模块的约定，比如“业务代码在 src/ 下，测试在 tests/ 下，禁止改 migration 历史”；第三，任务管控规则，比如“最多重试三次”“同一个文件的改动要生成 diff 摘要”。这样在后续多 Agent 编排里，每个子 Agent 启动时都会先读取这份文件，相当于每个外包员工入职先看一遍《员工手册》。

5.3 实现一个最小可用的多 Agent 编排与自愈脚本

下面给一个非常朴素，但可实际跑通的多 Agent 加自愈脚本流程，用 bash 作为外壳。我不直接贴完整产品代码，而是给出核心思路，你可以照着搭。

# 伪代码式脚本：演示任务流转与自愈循环 TASK_ID="$1" MAX_RETRY=3 ATTEMPT=0 # 阶段1：调研子任务，产物为方案文件 echo "== 启动调研子 Agent ==" claude --prompt "读取 docs/task_$TASK_ID.md，输出实现方案到 /tmp/plan.md" > /tmp/agent_plan.log 2>&1 # 阶段2：实现子任务，依赖方案文件 echo "== 启动编码子 Agent ==" claude --prompt "根据 /tmp/plan.md 修改 src/ 下的代码，并输出 diff 摘要到 /tmp/diff.md" > /tmp/agent_code.log 2>&1 # 阶段3：验证与自愈循环 while [ $ATTEMPT -lt $MAX_RETRY ]; do echo "== 第 $((ATTEMPT+1)) 次验证 ==" if npm run test; then echo "测试通过，任务完成" exit 0 else echo "测试失败，读取错误信息交给修复子 Agent" ATTEMPT=$((ATTEMPT+1)) claude --prompt "根据 npm test 的最新报错修改 src/，禁止改动 tests/，修改后重新验证" >> /tmp/self_heal.log 2>&1 fi done echo "已达到最大重试次数，请人工介入" exit 1

这里每个claude调用实际上都会起一个独立的会话上下文，天然就有点“子 Agent”的味道。能力更强的方式是直接用内置的任务委派接口，不过脚本外壳的好处是流程逻辑完全透传，可调试、可加日志、可嵌进 CI。

注意，真实环境里我不会把全部提示词硬编码在 shell 里，而是放在单独的 prompt 模板文件中，再用变量替换，这样维护成本更低。

5.4 把自愈循环的安全边界写进脚本

我在前面提过，自愈循环会乱改代码。所以脚本里要加上保护措施。第一，用 git 做到自动快照，每次修复子 Agent 执行前，记录当前分支的状态。第二，限定文件权限，我一般给编码子 Agent 明文列出“可改写目录”，超出范围就拒绝执行。第三，每一次修改后至少要跑一次“静态检查 + 单测”，静态检查没过就直接算失败，不浪费 token 去解释为什么失败。

这些保护措施看着不起眼，但实测下来能避免大部分“Agent 自信地改坏项目”的灾难场面。尤其是 git 快照，等于给自愈循环上了一道保险，再离谱的修改都能一键还原。

5.5 第三方 API 与本地模型：CC Switch 与 LM Studio 的实际体验

很多人对 Claude Code 有个误区，以为它只能连官方订阅。实际上，通过配置第三方 API 或本地模型，也能跑起来。我目前试过的两条路径很成熟。

一条是用 CC Switch 这类配置切换工具，把 API 入口切到 DeepSeek、Qwen、GLM 等兼容接口上。这种做法比较适合想体验不同模型能力、或者控制成本的朋友。操作上有几个要点：一是确认目标模型对工具调用和长上下文的支持是否完整，很多模型聊天很强，但结构化指令跟随便会比较弱；二是注意上下文窗口大小，多 Agent 编排每个子会话都要占用较大的上下文，模型如果上下文太小，很容易在长任务里断片；三是配置第三方 API 时，密钥、接口地址、模型名称这些字段要和目标服务商的最新文档对齐，不同服务商对兼容模式的定义不完全一样。这条路我用下来的感受是，切换本身很简单，真正的门槛在于评估“这个模型的编排稳定性是否够用”。

另一条是接 LM Studio 跑本地模型。好处是数据不出本机、不用担心配额，缺点是对本机性能要求高，而且本地小模型的复杂推理能力往往跟不上多 Agent 编排的需求。我的建议是，如果只是跑高度模板化的 Routine 任务，本地模型完全可以胜任；但如果你指望它处理需要综合多轮证据链的编排任务，还是别太难为它。配置上，记得在 LM Studio 里启动本地服务并开启跨域/外部访问选项，然后在 Claude Code 的配置文件里把端点指向本地端口，测试连通之后再开始跑正式任务。

这两条路径我都实测过，稳定性排序大致是：官方订阅 > 兼容性好的大厂第三方 API > 本地大模型。注意，组队用第三方 API 时，不要并发压太高，很容易触发限流；在自愈循环里频繁重试也会加速配额消耗，所以 max retry 别设太大。

5.6 配置过程中的常见坑

我第一次在 Windows 上配置时遇到的坑最多。Claude Code 官方安装包对 64 位 Windows 的支持没问题，但很多集成工具链对 Windows 的路径符号和 shell 语义兼容得不太好。比如 bash 脚本里的export、git diff这种命令，在 Windows 的 Git Bash 里跑是能跑，但一旦涉及路径中有空格，很容易被当成两个参数处理。后来我统一习惯了“配置先做 while 循环验证、路径统一加引号、尽量用 Node/脚本而不是纯 shell 跑复杂逻辑”。

还有一次印象很深：我配置好全局环境后，VSCode 插件一直报“无法连接”，找了一整圈才发现是插件用的终端环境和我命令行里验证的环境压根不是同一个，导致读不到密钥和配置文件。所以要养成习惯：凡是改了全局配置，插件和终端要一并重启，不要只重载窗口。

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

6.1 “your organization has disabled claude subscription access”这类订阅报错

这个报错我遇到过两次，每次原因都不同。第一次是登录的账号和组织不对，很多人公司账号和个人账号同时存在，默认登录到了没有订阅授权的组织下，换回个人账号或正确的组织即可。第二次是账号的订阅状态和授权范围不匹配，等了一会儿重新加载订阅状态才好。解决办法很朴素：先用官方文档确认账号的订阅类型，再检查全局配置里是否残留了旧账号信息，最后彻底登出、重新拉起一个干净终端做登录。注意，别频繁重试登录，有些接口会做风控，容易触发短期锁定。

6.2 “note: claude code might not be available in your country”提示

这个提示字面上是可用性说明。遇到它最好先去官方文档确认支持区域和最新说明，以官方信息为准。不同地区的网络服务差异不在本文讨论范围内，我这里不展开去讲绕过手段。最稳妥的做法是：在官方支持的区域和网络环境下使用，并确保账号注册信息与使用环境一致。这个问题在配置阶段就要留意，因为后面所有编排流程都建立在能正常连接服务的基础上，环境不对的话会把时间浪费在排查上。

6.3 第三方 API 接入后的兼容性问题

用 CC Switch 接 DeepSeek、Qwen、GLM 时，最常见的现象是“对话正常，但任务一复杂就静默失败”。我排查下来，原因几乎都指向同一点：模型的工具调用（function calling）能力不够稳。Claude Code 的编排层非常依赖工具调用协议，子 Agent 的消息要准确映射成结构化工具事件，模型一旦在这个层面有偏差，整个编排链条就会在某个环节悄悄断掉。

排查方法是：先降低任务复杂度，用小型的单步任务验证工具调用是否正常；再逐步增加子任务数量；最后再上自愈循环。另外，有些兼容层需要手工指定 model 名称、max_tokens 等参数，格式稍微不对，请求就失败。我的建议是尽量用各家模型对外宣称支持 Claude 兼容模式的版本，别拿纯聊天优化版模型硬跑，否则会反复踩坑。

6.4 本地模型接入 LM Studio 的怪问题

LM Studio 本地模型我踩过两个比较烦的坑。一个是模型上下文窗口默认设置和模型本身能力不匹配，经常对话到一半直接报超限。解决方式是在加载模型时显式调整上下文参数，并且在任务提示里控制输入的日志长度，不要一股脑把全部报错贴进去。另一个是本地服务启动后，端口被系统防火墙拦了，Claude Code 端表现为“连接超时”而不是“认证失败”。排查时一定要先在浏览器里手动访问一下本地端点的地址，确认服务真的通了，再回去调 Claude Code 侧配置。这个“先验证服务本身，再验证客户端配置”的顺序，可以适用到几乎所有接入类问题上。

6.5 多 Agent 编排“越改越乱”的急救方法

如果编排跑到一半，发现几个子 Agent 已经把同一个文件改得乱七八糟，最快的急救不是让主 Agent 继续修，而是立即停止循环、查看 git 改动、挑选一个改动量最少的版本作为基线，然后重新进入链式编排。我早期不舍得回滚，总想让 Agent 在坏状态上继续救，结果 token 烧了一大堆，最后还是回到上次的 git commit 才恢复正常。现在只要发现状态不可控，就果断git checkout回到上一个安全点，再降低任务拆分的粒度重新来。这是我从无数次失败里总结出的最实用一条经验。

7. 实战心得：什么场景该上多 Agent，什么场景纯粹是折腾

先说结论：不要为了“听起来高级”而上多 Agent。我见过不少朋友，其实只是写个几百行的工具脚本，也非要拆成“分析、编码、测试”三阶段，最后等了几分钟，交付结果反而比单步聊天还差。适合多 Agent 的场景，一定是任务本身具备了三个特征：足够大、边界清晰、可并行或可链式拆解。具体到实际项目，最典型的就是跨模块重构、批量迁移旧代码、为缺失测试的模块补测试这类干净利落的工程活。

反过来，如果任务是探索性质的，比如“看看这个项目的技术债有哪些”“设计一个推荐策略”，我反而建议你把全部上下文放在一个对话里，保留下每个灵感的来龙去脉。多 Agent 拆得太碎，会损失这种上下文连续性。

再补一句关于 Routine 的心得。Routine 不是一劳永逸的，它需要经常迭代。每当我发现一条 Routine 在某个新项目里跑不动，我不会急着修提示词，而是先看看项目结构是不是变了，然后更新 Routine 里的路径和验收项。这个维护过程本身就是把个人的经验资产化的过程，积累得越久，Routine 越值钱，因为你已经不需要重新教一遍 Agent 怎么做事了。

我个人现在的习惯是：所有重复三次以上的任务，都会写一条 Routine；所有中等以上复杂度的任务，都先问自己“能不能拆成子 Agent”；所有能自动验证的改动，都会套上一层带重试上限的自愈循环。这套组合拳落地之后，我花在“人肉调度”上的时间至少少了一半，而且交付质量更稳定。希望这些拆解和踩坑记录，能让你少走我走过的弯路。