我并行运行了11个研究代理一天。诚实记录,包括那两个什么都没做的。
摘要
并行运行11个研究代理进行数据扫描,将处理时间减半,但暴露了空白简报和API速率限制等失败,强调编排和验证比使用具体工具更为关键。
在这里看到收入会计帖子后,我觉得同样的诚实对代理工作流也有用,因为我看到的所有并行代理帖子都跳过了失败列。任务:为一个研究项目扫描大量Reddit数据。11个代理,每个都有自己的书面简报,每个写一个输出文件。成本:一天用了890个API积分,结果发现是当月配额的大部分。三天后一切开始失败时我才发现,花了一个小时诊断‘故障’。有效的:9个代理中,9个产出了真正好的文件。整个扫描大约花了4小时,而不是串行处理所需的两天。无效的:2个代理在启动时使用了空简报,因为在写提示和启动之间临时文件夹被清理了。两者都正常退出。都报告成功。我只是因为输出文件不存在才发现的。一个没有指令的代理不会出错,它只是愉快地什么也不做。另外,我猛击的API对所有人进行了速率限制,包括那些正常的代理,所以真正的并发上限是上游服务,而不是我的机器。我遵守的规则:最多2-3个并发,启动前验证简报非空,完成意味着向我展示文件。之后我将编排转移到了coldtea-ai,因为它将简报作为代理实际读取的文件保存,但老实说,检查比工具更重要。结论:并行是值得的,大约是我开始时并发度的一半。
相似文章
全职工作之余一人运营约16个代理:实际出问题的地方与真正有效的做法
一位独立创始人通过Paperclip协调运行16个AI代理,分享出问题与有效之处,包括通过QA代理缓解的幻觉功能承诺,以及用代码级执行取代提示规则。
如果你使用 Open Code 或其他代理程序,但没有并行使用代理,那么你会损失大量的 t/s。基准测试:RTX5090,通过 LM Studio 加载 Qwen3.6 35B,并行任务数设为 8
基准测试表明,在 RTX 5090 上使用 LM Studio 并行运行 4-5 个代理可最大化吞吐量,而更多代理会因显存和计算分割导致收益递减。
并行运行多个编码代理时出现了我未曾预料的故障。实际让我措手不及的三个问题
文章讨论了并行运行多个编码代理时出现的三个意外问题:共享工作树的冲突、运行时冲突(数据库、端口)以及难以检测卡住的代理。解决方案包括使用每个代理的 Git 工作树、隔离运行环境以及监测剩余差距指标。
我让一个代理每天早上自主选择任务,持续了23天。共41次运行,19次成功上线,22次失败。正是这22次失败让系统得以生效。
一项为期23天的实验,通过GitHub Actions让AI代理自主选择并执行任务,自动化检查机制导致54%的失败率,反而通过减少人工审核提升了效率。
@PrajwalTomar_:停一下。在你添加另一个AI代理之前,请先阅读。人们现在并行运行20个编码代理。二十个。而且工具…
该推文认为,并行运行过多AI编码代理会降低代码库质量,并提倡使用少数几个专门代理的结构化设置。它还提到了Jcode的发布,这是一个开源代理,声称内存效率提高20倍。