最大限度压榨你的 iFlow CLI

众所不周知,iflow cli 是有并发限制的

类型 并发数
主 agent 1
subagent 2

并且通常不会自动触发,就算触发也是只使用一个 subagent,所以需要通常需要通过类似以下提示词来主动触发

请使用 2 个 subagent 帮我 ...

但这种方式通常会出现两种现象:

  • 两个 subagent 一路干到底
  • 两个 subagent 做完前两个任务,剩下的任务由主 agent 一路干到底

所以我的做法是分批执行,来提高效率,前提是任务可以并发,不然滥用并发效果可能反而变差,比如对信息重复收集,多个 subagent 修改同一个文件等

提示词类似这样

任务...;使用多个 subagent 拆分成多个高并发任务分批执行,一批任务完成后进行整理总结再进行下一批,每批可以进行 n 个并发,合理安排每批次的并发数

然后又看到了下面这篇帖子获得了灵感,可以将提示词封装成 command,就不需要每次都复制粘贴这么一段内容

这篇帖子中将不同的并发数做成了不同的 command,方便随时使用指定的并发数

但我觉得可以稍作调整,将最大并发数写在 AGENTS.md 中,iflow 就能根据任务,拆分出不同的任务点,并整理每个批次最合适的并发数

比如像下面这个复杂任务,涉及了资料的收集整理,以及代码编写

在 AGENTS.md 中,设定了最大并发数为 3,这是用来展示可配置性,不受限于 1、2、5 个并发

这样 iflow 就会开始规划任务和调整每个任务批次的并发数,然后分批并发执行任务了

最终效果还需要微调一下,不过这是一次性生成,效果还算可以了吧 :joy:

由于提示词太长,就不放在帖子里了,直接上架到平台上,到时候一键安装就能用了

命令在审核中,等审核通过了就能安装体验一下


2026-03-14 补充

突然发现没讲这个 command 的细节
:distorted_face:


这个 command 主要主要分为

  • 用户输入检查
  • 目标效果
  • 执行流程

用户输入检查

这部分是参考 spec-kit 的写法,大概是这样,这是防止用户只执行了命令没有填需求的

## User Input

```text
$ARGUMENTS
```

你**必须**在继续前考虑用户的意见 (如果不是空的话)。用户在触发消息后面输入的文本就是功能描述。假设你在这段对话中随时都有它,即使字面上显示在下面。除非用户提供了空命令,否则不要要求用户重复输入。

目标效果

就是告诉 iflow 最终需要达到什么效果

## Goal

将复杂任务自适应拆分为可并发的子任务批次,通过智能调度器动态分配 subagent,在保证质量的前提下最大化并发效率。

执行流程

执行流程就是详细告诉 iflow 应该如何进行 并发,这部分需要让 iflow 先拆分子任务,再找出可并行的任务,为的就是防止简单粗暴的直接拉满并行数量,因为不是所有任务都需要并行,像编写代码,需要做到文件隔离避免多个 agent 各有各的想法,然后还修改相同的文件,这样反而拉低的生成的质量,要让每隔 agent 做自己该做的事情

首先是让 iflow 知道要去 AGENTS.md 找最大并发数,才能合理的安排每批的并发

### 1. 初始化调度上下文

1. **解析用户输入**:解析 `$ARGUMENTS` 中的任务描述
2. **读取并发配置**:
   - 优先级:用户显式指定 > AGENTS.md 配置 > 默认值 2
   - 有效范围:1 ~ 5
   - 存储为 `MAX_CONCURRENCY`

然后是构建有向无环图,也就是大学数据结构和软考做题做到烦的关键路径题

1. **识别任务类型**:

   | 类型 | 特征 | 典型操作 |
   |------|------|----------|
   | 研究类 | 信息收集、分析 | 文件读取、网络搜索、代码探索 |
   | 开发类 | 代码编写、重构 | 文件创建、修改、删除 |
   | 测试类 | 验证、测试 | 测试执行、断言检查 |
   | 文档类 | 文档编写 | Markdown 创建、更新 |

2. **评估任务复杂度**:
   - **简单**:单文件操作,无外部依赖
   - **中等**:多文件相关操作,有内部依赖
   - **复杂**:跨模块/系统集成,有外部依赖

3. **构建任务依赖图**:
   - 提取任务间的强依赖关系
   - 识别可并行执行的任务组
   - 标记关键路径任务

### 3. 自适应批次规划

**批次划分算法**:

```
输入: 任务列表 + 依赖图 + MAX_CONCURRENCY
输出: 批次列表

1. 拓扑排序获取执行顺序
2. 按 DAG 层级划分批次
3. 每批次任务数 ≤ MAX_CONCURRENCY
4. 同文件操作必须同批次或串行批次
5. 高复杂度任务独占或降低并发数
```

以上就是大概的细节,然后填充更多的补充信息进行完善就能打造一个同款 command 了

2 个赞

能不能写出queue的能力啊,就是100个差不多的任务,先扔到队列里面,

然后两个subagent轮流取任务来执行。

我之前试过简单的写法,是两个两个批次执行,没搞定这种任务分配。

2 个赞

这得研究一下,因为 commands 本质是提示词模板,提示词做不到的 commands 应该也做不到 :joy:

找时间研究一下 workflow 看看能不能做这种功能,或者其他的方式实现 :thinking:

感觉没必要,我最头大的其实是它生成代码的质量,很多时候我都不采纳他的代码,我一直希望有个办法能极大限度的提升它的代码质量,而不是让它干的更快,开很多subagent反而会使得它写出的代码更不可控,同时希望iflow能够让工具调用更明显些吧,很多时候调用工具都不知道它改了哪些代码(可能是我用法的问题)具体可以看看pi-mono这个agent我很喜欢,还得去git一点一点找

很有意思。用subagent,不光能压榨速度,还能压榨context。我担心的是,subagent没有和用户直接对话的能力,黑盒程度很高。所以需要主agent审查,并且只有在清晰的情况下才调用subagent

干的活不一样,我是用它来处理一堆文件,先分别提取摘要完了,再综合处理一下,理想的模式就是用subagent分别处理完了,最后塞一起汇总,不过现在还是有点骨感。

我曾经用iflow检查代码技术债务。然后写出一个个md报告以后用trae来修。trae的子agent没有限制,一下子调用了6个,而且全部并发,那个场面…啧啧太壮观了。
后面也是修好了。如果没修好的话估计要寄了哈哈哈,我没有检查代码的能力,也不知道什么地方出问题了,一股脑回滚吧。

trea国内是不是免费啊?明天我也去试试。

免费。而且我的很神奇地不用排队,是新人福利还是啥我也不知道。
它6个并发 k2.5 速度还很快,我不敢想啊。。
现在估计没这么快了。但完全免费是真的

所以需要规定哪些任务需要串行哪些可以并行,互不干扰的可以并行,代码编写同一个文件需要串行,但多个不同文件的多个模块可以并行,文中这部分有提到

trae cn 排队太严重了,说开 auto 可以自动分配避免排队,但是我 auto 都要排队 :joy:
而且个人觉得 trae cn 不知道是人用的多还是什么原因,感觉能力不太行好像比网页版都差,像是负优化,现在都不怎么用了

可以!有机会我试试,主要是iflow很多时候写的代码很多时候很多死代码(这辈子不可能执行到),还有很多低效率逻辑,以及一些神秘的try,还有些代码会间接影响其他地方的逻辑,这一点我比较头疼,大佬有解决对策吗?

我是将一些代码的设计原则写在 AGENTS.md 中,比如什么单一职责原则、避免深层嵌套、及时清理历史遗留代码啥的

但是作用不大,上下文长了还是不会遵守,这个时候就需要在开发完一个功能后,执行一下代码审查,看看哪些不符合这些设计原则的地方,然后进行优化

我本身是重度规则使用用户,~/.iflow/IFLOW.md已经有一百多行了。
一开始我是往IFLOW.md里直接追加让其控制subagent数量的,但实际情况是agent并没有很好遵守。

直接在 AGENTS.md 中写并发数确实用着用着就不遵守了,所以我是每次需要并发时都手动复制粘贴一段提示词,而你的那篇帖子中是用 commands ,这本身也是提示词模板

也就是这里就给了我灵感,因为 commands 作为模板不论多长都是一样的短指令,所以可以写更复杂的规则,而且肯定会加载到上下文中,所以我仿照 spec-kit 的写法,规定了对用户输入的处理、指令执行的目标以及指令执行的步骤,其中就有规定需要读取 AGENTS.md 的描述

已经拉满5个了

直接拉满不一定好,需要了解清楚哪些该并行哪些该串行,比如查资料并改代码,应该先查资料再改代码,不然查资料和改代码同时在不同的 agent 进行的话,就会出现查的资料用不上,改的代码没改对 :joy:

佬,市场上没搜到这个,是不是删了呀,能分享一下源文件吗 :heart_eyes:

这个现在可以说是没啥用的 :joy: 因为加速卡这周是最后一期了,之后的最大并发只有 2 了

直接使用下面的提示词就好了,也可以直接在项目目录下创建 .iflow/commands/multi-agent.md 文件,就能快捷使用 /multi-agents 指令了,同样可以规划任务和分批并行

请使用有向无环图将复杂任务拆分为多个任务点,动态分配 subagent,最大并发为 2,构建依赖图划分批次,执行时并行处理无冲突任务;<你的任务>