【💰】各位如何平衡多 agent 协同工作的工作流和并发呢
个人做大型项目如何处理高并发问题?大尺寸模型和小尺寸模型间的协同工作问题?
金币会随着回复数量动态增加,首次回复有概率获得金币池中部分金币奖励。
个人做大型项目如何处理高并发问题?大尺寸模型和小尺寸模型间的协同工作问题?
金币会随着回复数量动态增加,首次回复有概率获得金币池中部分金币奖励。
优先用快速小模型做初步筛选、再用干活大模型兜底。
这个问题太宽泛了,不妨拿出一些明确的问题出来讨论,可以管中窥豹
路过
用三省六部制度进行有效管理
低智模型检索,高智模型设计计划并生成对应的验收标准,中等模型完成开发任务,高智模型 review。
如果不考虑任何成本,全程使用上下文最大以及智商最高的模型。
一般工作流程就是,输入需求,模型问询并扩展需求,生成完整的 plan 及验收文件,设定项目边界,调用 subagent 实现,在实现的过程中可以开多个 worktree 同步进行开发,最终各自验证并合并到同一分支。
想同步推荐,就要提前先做好预期管理和质量管理。
问一问 Claude,它对于变长超长上下文有诀窍。
什么是高并发问题?是说 subagent 太多消耗了过多 tokens?
蹲一下看看
我也要学习一下
学习一下 (mark)
我平时基本用不到 subagent,是不是很 low
学习下,嘿嘿,话说这池子真大啊
说实话,没怎么管,全靠 OMP 自己,确定 plan 和工作流,然后许愿把活儿干好就行
我最近也在想怎么解决这类问题,只能多个工具一起用了,来回切挺麻烦
这个时候就需要爱马仕了
这确实是一个很大的难题,感觉搞好了会有大出路大结果啊。
大小模型協同,我是讓大模型當「總包商」負責開頭定規格與結尾驗收,小模型當「分包商」照著規格包辦中間的寫 Code 與補測試。
處理高併發,則是靠 Git 切出多個獨立目錄讓小模型同時動工不互撞,並規定它們「自己跑過自動化測試才准回報」,自己進行最後的合併簽核。
基于第三方开源 agent 做自定义工作流,代码强约束
目前是多工具一起用,然后常干的事是用 codex 调多个 opencode
先管好边界,再增加并行度。