企业官网建设流程全解析

1. SubAgent 到底是什么：先搞清它和普通对话的差别

用 Cursor 写代码的人基本都经历过这个阶段：一开始觉得它的对话补全很强，后来开始玩 Chat 里的 Agent 模式，让它在整个代码库范围内自主改代码、跑命令、修报错。但用久了你会发现，单个 Agent 干起活来其实有点“独木难支”的意思——大一点的改造任务，它一个线程串行跑下来，动不动十几分钟，中间还会因为上下文太长开始犯迷糊。

SubAgent 就是冲着这个痛点来的。它本质上是把原来“一个全能代理从头干到尾”的模式，拆成“多个子代理并行开工、各管一段、最后汇总结果”的模式。你可以把它理解成一个项目经理带着若干个小工：项目经理负责理解全局、拆解任务、分配下去，每个小工只盯着自己那一小块，干完把结果交回来。

这套机制解决了两类很典型的问题。一类是效率问题，多个互不依赖的子任务并行执行，比串行快很多；另一类是上下文质量问题，每个子代理只加载自己需要的那部分代码和说明，不会被整个项目无关的文件把上下文撑爆。很多人觉得 SubAgent 只是“多了个并行的入口”，其实不是，它在上下文管理上的收益，往往比速度上的收益更重要。

这篇文章适合的人：想优化 Cursor 工作效率的中高级用户、被大任务耗时长和上下文错乱折磨过的人。我后面会把入口、配置、实战场景、翻车记录全都翻出来讲，能直接照着用。

2. 上手实操：从入口到一次完整的子任务下发

2.1 入口位置和界面结构

SubAgent 的入口不算隐蔽，但确实有不少人没注意过。在 Cursor 的主对话框里，输入框附近通常会有一个模式切换的入口，你能在普通 Chat、Agent、SubAgent 几个模式之间切换。有的版本在对话窗口顶部有标签页，有的版本在小图标菜单里，如果找不到，先看一眼你的 Cursor 版本是不是够新，这个功能迭代很快，老版本确实没有。

进入 SubAgent 模式后，界面布局和普通对话有明显的区别：左侧是家主对话（或者叫调度窗口），右侧可以展开一个子任务面板，里面会列出当前已下发、执行中、已完成的子代理任务。每个子任务都带自己的状态标识，比如排队中、运行中、已完成、失败，点开任意一个子任务，可以看到它独立的上下文、用到的文件和最终结果。

这个界面设计本身就是答案：SubAgent 不是把任务混在一个对话流里，而是每个子任务有自己独立的小环境。我的建议是先把界面结构摸熟，再开始配置任务。不然下发了一堆并行任务，都不知道去哪看结果，体验会非常混乱。

2.2 第一次下发：一个最小可用的操作流程

我们直接走一遍最简单的流程，目标是让一个子代理帮我们生成某个模块的单元测试。

第一步，切换到 SubAgent 模式。确保当前工作区打开的是你的项目根目录，因为子代理默认的工作范围就是当前项目。

第二步，在下发任务之前，先明确你要拆什么。比如我打开一个工具类文件utils/format.ts，里面有一堆时间格式化、数字格式化的函数，我希望子代理只针对这个文件生成测试。

第三步，填写子任务描述。我一般是这样写的：“你是这个项目的测试工程师。请阅读utils/format.ts中的所有函数，为每个函数生成 Vitest 单元测试，覆盖正常输入、边界输入和异常输入三类情况。测试代码放到tests/unit/format.test.ts。只做这一个文件，不要改动其他文件。”

注意这段描述里的几个关键信息——角色、范围、输出位置、约束。角色让子代理知道用什么视角干活；范围防止它越界乱改成别的文件；输出位置减少你事后整理的工作量；约束是告诉它哪些事情绝对别做。一条合格的任务描述，比你在主对话里长篇大论更有用。

第四步，确认配置后下发。如果同时下发多个子任务，它们并行执行，每个子任务都有独立的进度。等全部子任务状态变成“已完成”，再回主对话统一检查结果。

2.3 结果回收时的两个关键动作

子代理跑完，把结果 Applied 到项目里之前，我强烈建议你先做两件事。

第一件事，临时把目标文件加入版本控制或者做个快照。因为 SubAgent 并行执行时，多个任务的结果会被合并到主对话的变更集里，一旦 Apply，改动是批量的，这时候想后悔就麻烦了。我一般用 Git 先 commit 一次，或者在 Cursor 的变更列表里逐个审查文件，确认没有意外改动再合并。

第二件事，逐个检查子任务报告。每个子任务完成时，会附带它改了什么、为什么这么改、还有哪些遗留风险的说明。这些说明是子代理自己的“工作汇报”，别跳过。很多时候问题就藏在“遗留风险”这一段，比如“这个函数有副作用，测试可能需要 mock 某个全局依赖”，这种提示能帮你避免上线后炸雷。

提示：子任务的 Apply/Reject 是可以单独操作的，不一定非要全盘接受。并行任务里如果有一个结果你不满意，单独 Reject 它，不影响其他子任务的合并。这一点很实用，后面排查问题也会用到。

3. 配置详解：模型、知识库、系统提示词怎么组合才合理

3.1 模型选择：不是所有任务都该用最强的

SubAgent 允许每个子任务单独选择模型，这是很多人忽略的配置项。我的原则是“任务难度和模型能力匹配”，不为所有子任务一律选最强模型。

比如做代码查询、定位问题、生成注释这类轻量任务，用普通的中档模型就够了，速度快、成本低，结果质量也不会差。而涉及跨文件重构、算法实现、复杂业务逻辑理解的重活，才值得把更强的模型放上去。

这里有个经验可以分享：我习惯把需要创新设计的工作分配给强模型，把机械性执行的工作分配给普通模型。举个例子，重构一个数据访问层，我会让强模型负责设计新的仓储接口，让普通模型负责把旧调用点逐一替换成新接口。前者需要理解整个项目的架构风格，后者只是按规则改字和调用方式。这样的组合，整体速度比全上强模型快，质量也不差。

3.2 知识库绑定：让子代理站在“懂项目”的基础上干活

SubAgent 比普通 Chat 强的一点，是它可以在下发任务时绑定特定文件、目录或整个代码库作为参考上下文。这个能力用好了，子代理就不是“瞎猜项目结构”的临时工，而是“看过你项目规范的正式员工”。

具体操作上，在子任务描述里可以用@符号引用文件或目录，也可以指定让它读取某个说明文档。我的习惯是三类东西必带：一是任务涉及的核心文件；二是项目里的编码规范或贡献指南文档；三是与你这次改动相关的既有模式文件，比如一个已实现好的相似模块。

为什么要带“既有模式文件”？因为大模型非常擅长模仿。你给它看一个现成的模块是怎么写的——目录结构、命名风格、导出方式、注释习惯——它写出来的新代码就会自动贴合这个风格，而不是重新发明一套。我踩过这方面的坑：有一次没给参考文件，子代理生成的代码风格和项目完全不一致，我花在调整上的时间比让它重写还久。

3.3 系统提示词设计：三句话讲清边界

SubAgent 的配置里通常会留一个系统提示词字段，相当于给子代理设定的“岗位说明书”。很多人的做法是留空或者写一句“你是一个专业的程序员”，这其实浪费了能力。

我自己的模板是三层结构：

第一层，角色定位。一句话说清楚它是什么角色。比如“你是资深前端工程师，负责实现 UI 组件库”。

第二层，工作边界。写清楚它只能动哪些文件、不能动哪些文件、不能执行哪些操作。比如“你只能修改src/components/下的文件，禁止运行安装命令，禁止改动配置文件”。

第三层，输出要求。明确输出形式。比如“完成代码修改后，用列表说明改动的文件、改了什么、为什么这么改、有什么风险”。

这套模板特别适合多人协作场景，也适合任务拆得很细的并行场景。边界清晰了，子代理就不会“自由发挥”，你的审查压力会小很多。我见过有人把系统提示词写成一个很长的规章制度，反而效果不好——提示词过长会挤占有效的指令空间，子代理执行起来反而会犹豫。三到五句话，说清楚角色、范围和输出要求，足够。

4. 实战场景：三类我用 SubAgent 验证过的任务拆法

4.1 多文件并行重构：把大手术拆成小切口

先说我用得最多的场景：跨模块重构。一个典型的例子是，把项目里所有直接操作原始 SQL 的地方，全部迁移到一个新增的数据访问层上。

这类任务在单 Agent 模式下很容易翻车，因为改到一半，Agent 会把上下文焦点放在正在改的文件上，忽略之前看过的调用方约束。用 SubAgent 怎么拆？

我的做法是，主对话先梳理出所有涉及 SQL 调用的文件清单，按模块分成几组。比如用户模块一组、订单模块一组、支付模块一组，然后下发三个子代理，每个负责一组。每个子代理的命令里都注明：数据访问层的方法签名先去读src/data/schema.ts，以那里的定义为准；只允许修改指定分组的文件；遇到不确定的业务逻辑，先跳过并在结果报告里标注，不要自行假设。

这样拆完，三个子代理并行改三块代码，大概几分钟就能全部完成。最让我满意的是“遇到不确定的逻辑先跳过”这个约束——之前单 Agent 经常自作主张乱改业务逻辑，拆给子代理并加了边界之后，这类问题少了很多。最后要做的事就是汇总子代理的报告，把标出来的不确定项交给人工确认。

4.2 自动化 Code Review：省钱省时的并行审阅流程

SubAgent 做代码审查是我个人最推荐的低风险用法，因为它不需要真的往项目里写代码，跑错了损失也小。

我的操作是：把待审查的代码按模块或文件拆开，每个子代理分配一个清晰的审查指令，要求它分别从代码正确性、性能隐患、安全漏洞、可维护性四个维度给出意见，并且每条意见必须标出行号和严重级别。最后把并行产出的结果汇总，按严重级别排序，形成一份审查报告。

这个流程我在一个大约两万行代码的中型项目上实测过，一次性拆了五个子代理并行审查，十几分钟就出完了全部结果。单 Agent 模式至少需要两倍时间，而且越到后面越容易忘记前面文件的内容。

有个细节值得注意：审查任务一定要限制子代理“只读不写”。如果子代理在审查过程中顺手“优化”了几个文件，那就不是审查了，是乱改。我的提示词里会加一句强约束：“你只能输出审查意见，绝对不要修改任何代码文件。”这句话简单有效，能挡住绝大部分控制不住手的问题。

4.3 测试用例批量生成：以量取胜的并行优势

测试生成是并行收益最大的场景，因为各个测试文件之间天然独立，没有任何状态共享。

实战过的一个项目是内部管理系统，有好几个核心模块的接口测试覆盖率一直上不去。我按模块把任务拆成多个子代理，每个子代理负责一个模块的接口测试，给它指定对应的 API 定义文件、Mock 规则、历史测试样例。子代理各自独立生成测试代码并写入独立的测试文件，互不干扰。

效果非常直接：一次并行生成了几百条测试用例，覆盖正常流程、参数边界、鉴权失败、接口超时等场景。之前靠手写或者靠单个 Agent 生成，这种量级至少要大半天，SubAgent 把时间压缩到了半小时以内。

我做完之后的复查发现，子代理生成的测试代码，质量和风格差异挺明显。有的子代理生成的测试注释非常详细，有的就只写断言不多解释。这个问题靠什么解决？回到 3.3 节说的系统提示词，把输出格式要求写清楚，风格差异就会大幅缩小。如果你发现并行产出的测试风格不统一，优先检查是不是系统提示词里的输出规范写得不够细，而不是逐个文件去改。

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

5.1 子任务一直“排队中”不执行

并行任务一多，明显能感觉到部分任务排队等待。这个通常是资源限制导致的，模型调用有并发上限，或者是订阅套餐里的并行额度不够用。

我的排查顺序是先看其他子任务是不是都在跑，如果已经有任务占用额度，排队就是正常的，等一会儿即可。如果所有任务都停在排队状态，那就不是额度问题，大概率是你下发的任务配置有问题，比如同时绑定了大量文件导致上下文准备超时，或者引用了不存在的目录，子代理卡在执行前校验。

遇到这种情况，取消任务重新下发，并减少引用范围。我习惯一条任务最多绑定三五个核心文件，超过这个数的就再拆分。子代理需要的上下文越多，准备时间越长，排队风险也越高。

5.2 结果和预期差很多：先查描述，再查上下文

子代理跑出来的代码完全不是你要的东西，这事我碰到过不止一次。这时候先别急着怪工具，按顺序排查两个地方。

第一个是任务描述。子代理对模糊表述的解读能力其实很强，但也意味着它会按自己的理解去脑补。你写“优化这个模块的性能”，它可能去改数据结构，也可能去加缓存，也可能去调整算法。问题的根源是“性能”太宽泛了。改成“将列表查询从 O(n²) 的双重遍历改为一次遍历，并补充基准测试验证”，结果就完全不一样。

第二个是上下文引用。检查你绑定的文件里面，是不是有旧版本的实现文件。有一次我给子代理绑定了包含废弃接口的文件，它照着废弃接口写了一圈新代码，全部白干。查上下文引用，把废弃文件移除，重新下发，就正常了。

5.3 并行任务互相干扰：变更冲突怎么处理

并行任务最大的坑，是两个子代理同时改了同一个文件的相邻区域，合并时发生冲突。我在 2.3 节里说过要先提交一次快照，就是为了应对这种情况。

处理思路是：先逐个 Reject 冲突的变更，然后手动合并，或者将公共文件的修改任务合并成一个子代理执行。拆任务的时候，最好明确“文件所有权”，就是每个子代理独享一组文件，不要有交叉。如果确实要多个子代理都碰同一个文件，就在描述里限定它们各自修改的区域。

还有一个偏经验的做法：涉及公共依赖文件的修改，永远在主对话里自己完成，不要让子代理做。例如修改一个被很多模块引用的数据类型定义，如果子代理改动它而你没盯住，最后的冲突排查会非常痛苦。

5.4 成本涨得太快：怎么控制并行消耗

SubAgent 并行跑起来，消耗的速度确实让人肉疼。我刚开始用的那段时间，某个月消耗翻了好几倍。现在我会控制几个维度。

一是限制并行的任务数量，同时最多四个左右，再多任务的收益增长就开始下降，纯属烧钱。二是轻量任务不用强模型，这个前面说过，模型级别直接决定成本。三是设置每个子任务的最大轮次或者输出长度限制，防止子代理在一个任务上无限纠结、反复修改。四是及时关闭不再需要的子任务，执行完的会话别一直挂着，保持会话卡片在后台也很耗资源。

注意：SubAgent 的计费是以底层模型调用和后端资源占用综合计算的，不是单纯按“生成的字数”计费。所以“等待时间”也是成本。一个子任务反复重试一个小时，比你重发三次正常任务都贵。控制执行时间，是控制成本的核心。

6. 最后说点我的体会

SubAgent 给我最大的感受不是“并行快”，而是“边界清晰”。单 Agent 模式下，一个代理既当架构师又当执行者，上下文切换频繁，出错率自然高。拆成 SubAgent 之后，每个代理只盯着自己那一小块，反而把质量提上来了。

我现在的用法已经变成了一种习惯：接到大任务，先坐在主对话前拆任务、写描述、定边界，然后一次性下发，干完再逐个验收。这套流程跑顺之后，我个人的代码产出效率大概提升了一半还多，尤其是那些需要多文件联动、重复性很强的工作，基本都交出去了。

最后再分享一个小技巧：把你自己常用的 SubAgent 任务模板保存下来，无论是任务描述模板还是系统提示词模板，都值得在本地留一份。下次接到类似任务的时候，直接复制改一下就能用，不用每次重新构思边界条件。我现在每次开新项目的第一天，就会顺手建一份模板库，省下的时间远比你想象的多。