在日常开发中，我们常遇到涉及多模块、跨文件交互的复杂任务。如果直接把整个需求丢给AI，它可能会一口气生成大量代码——中间过程不透明，问题往往在最终结果才暴露，返工成本高，甚至可能引入代码安全隐患。
飞算 JavaAI 提供了智能体（计划模式）来解决这一问题。它的核心思路是：根据任务复杂程度，智能体自主将其拆解为多个子任务，明确步骤顺序、依赖关系及预期结果，生成结构化计划，然后按步骤有序执行。
如果任务中涉及复杂执行流程，希望定义完整执行流程，约束条件，可以使用——创建子智能体来解决。
01｜子智能体是什么？
一句话：子智能体是你亲手配的一个「技术专家」，计划模式拆出来的活，可以点名交给它干。
以前是这样。 智能体（计划模式）会把复杂需求拆成多个子任务——这点它做得不错。但每个子任务具体怎么执行，用的是系统内置的那一套逻辑。你想往里加自己的规矩，没有入口。
现在是这样。 你创建一个子智能体，写清楚它是什么、什么时候用、具体怎么做。智能体（计划模式）拆完子任务后，把对应的活委派给它，它严格按你写的那段提示词执行。
它适合这三类场景：
- 规范固定型
：团队的代码规范、命名约定、分层规则，每次都要重复强调的那些话。 - 流程固定型
：顺序不能乱的多步操作。比如「改代码之前先跑通编译」「动 Service 之前先确认事务边界」。 - 产出固定型
：输出格式必须统一。比如「必须给 diff 形式」「必须附复现步骤」「必须给可直接替换的代码片段」。
一句话：以前是「AI 按它的习惯干」；现在是「你定规矩，AI 负责执行」。
02｜三步，创建你的第一个子智能体
第 1 步：找到入口
进入「设置 → 子智能体」，点「创建」。
第 2 步：让它自己生成，或者自己写
页面会先问你一句：这个子智能体应该做什么？
在输入框里把需求描述清楚，点「生成」，模型会按你的描述自动产出一份完整内容，可根据实际需要进行修改。
生成完会落到几个字段上，全都可以改：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这里有个点必须记住：描述字段是模型判断「要不要用它」的唯一依据。
写得太虚——比如只写「帮助开发」——模型识别不出使用场景，你建了它也不会被调用。写得越贴近你真实的开发需求，它被自动选中的概率越高。
03｜怎么让它真的接管任务？
建好只是第一步，用起来是这样的：
-
回到会话窗口，把模式选成 智能体（计划模式）
四个最容易踩的坑：
- 没切计划模式。
子智能体列表只在「智能体（计划模式）」下才显示。普通模式下你根本看不到这个列表，会以为功能没生效。 - 描述写虚了。
模型认不出使用场景，不会调用它。 - 提示词只写了「做什么」。
没写「怎么做」和「产出什么格式」，结果还是它自己发挥。 - 建完忘了选。
列表里不勾，等于没建。
一句话：描述决定它会不会被想起来，提示词决定它干最终是否被使用。
04｜五个让它更好用的建议
一、提示词按四段写：角色 → 流程 → 产出格式 → 禁止项。
四段齐了，AI 干活才有章法。少了「禁止项」，它就会顺手做你没让它做的事。
二、一个子智能体只管一件事。
又管单测、又管安全审计、又管 SQL 优化，三边都会做得半吊子。宁可建五个窄的，别建一个全能的。
三、把团队规范的原文贴进提示词。
「不要三层以上 if 嵌套」「金额统一用 BigDecimal」「Controller 里不写业务逻辑」——这类约定写进去，比每次临时叮嘱靠谱得多。
四、在实践中不断优化提示词。
别指望一次写到完美。看它哪一步跑偏，就补哪一句约束。两三轮回调之后，它就稳了。
一句话总结：子智能体，就是你和 AI 之间的一份「岗位说明书」——把这类活该怎么干固定下来，AI 就永远按你的习惯干活。与其每次重复强调一遍规范，不如花五分钟建一个子智能体。