آنتروپیک معماری جدیدی برای هماهنگی چندعاملی معرفی کرد؛ کلود برنامه‌های اجرایی خود را برای مدیریت عامل‌های هوش مصنوعی می‌نویسد
در یک سامانه چندعاملی، می‌توان وظایف را میان عامل‌های مختلف تقسیم کرد تا به‌صورت موازی انجام شوند. بااین‌حال، پس از تقسیم کار همچنان به سازوکاری برای هماهنگی نیاز است تا مشخص شود چه کسی مسئول مدیریت روند اجرا و تحویل نتایج است و در مرحله بعد باید کدام عامل به کار گرفته شود.
آنتروپیک اخیراً رویکرد تازه‌ای برای این مسئله پیشنهاد کرده است: کلود بر اساس نیازهای هر وظیفه، یک برنامه هماهنگ‌کننده تولید می‌کند که مسئول راه‌اندازی عامل‌های فرعی، اتصال مراحل مختلف، پردازش نتایج دریافتی و ارسال وضعیت اجرا به عامل اصلی است. به این ترتیب، بخشی از کارهای هماهنگی که پیش‌تر به مشارکت مداوم عامل اصلی نیاز داشت، می‌تواند به‌وسیله برنامه‌هایی که در پس‌زمینه اجرا می‌شوند، انجام شود.
آنتروپیک در ۹ اکتبر قابلیت Dynamic Workflows را برای Claude Managed Agents معرفی کرد که در حال حاضر در مرحله آزمایشی بتا قرار دارد. در ۱۲ اکتبر نیز دو تن از مهندسان این شرکت، سی‌جی آویلا و هریسون استال، در کارگاه رویداد AI Engineer New York 2026 جزئیات این سازوکار را تشریح کردند.
مهندسان آنتروپیک در این ارائه، با اشاره به روند تکامل پروژه‌های یونیکس و لینوکس از توسعه فردی تا همکاری در مقیاس بزرگ، توضیح دادند که با افزایش تعداد عامل‌های مشارکت‌کننده در توسعه نرم‌افزار، سازمان‌دهی و هماهنگی وظایف خود به گلوگاه تبدیل می‌شود. Dynamic Workflows سازوکار تازه‌ای است که آنتروپیک برای حل این مشکل آزمایش کرده است.
۱. تبدیل برنامه اجرای وظایف چندعاملی به کد
توسعه‌دهندگانی که از چند عامل هوش مصنوعی در پروژه‌های واقعی استفاده می‌کنند، اغلب درمی‌یابند که واگذاری وظایف فقط گام نخست است و بخش پرزحمت‌تر، به‌هم‌پیوسته نگه‌داشتن کل فرایند است. برای مثال، عامل اصلی به‌راحتی می‌تواند چند عامل فرعی را به‌طور هم‌زمان برای جست‌وجوی اطلاعات به کار بگیرد. مشکل از جایی شروع می‌شود که نتایج هر عامل باید به گفت‌وگوی اصلی بازگردد و عامل اصلی آن‌ها را یکی‌یکی پردازش کند تا وظایف بعدی را تعیین کند. هرچه تعداد وظایف بیشتر شود، فضای زمینه مدل نیز به‌سرعت با نتایج میانی پر می‌شود.
در روش متداولی که عامل اصلی مستقیماً عامل‌های فرعی را فراخوانی می‌کند، خود عامل اصلی وظایف را توزیع می‌کند، نتایج دریافتی را می‌خواند و سپس درباره گام بعدی تصمیم می‌گیرد. عامل‌های فرعی می‌توانند به‌صورت موازی کار کنند، اما پیشبرد مراحل بعدی همچنان بر عهده عامل اصلی است.
در مقابل، Dynamic Workflows بخشی از منطق هماهنگی را در قالب یک برنامه پیاده‌سازی می‌کند. کلود متناسب با نیاز وظیفه، برنامه‌ای برای هماهنگی تولید می‌کند که مشخص می‌سازد کار چگونه تقسیم شود، از چه مراحلی تشکیل شود و فعالیت عامل‌های مختلف چگونه به یکدیگر متصل شوند. سپس سرور این برنامه را در پس‌زمینه اجرا می‌کند تا عامل‌ها را راه‌اندازی کند، نتایج میانی را انتقال دهد و بر اساس وضعیت اجرا، مراحل بعدی را پیش ببرد.
برنامه هماهنگ‌کننده در اینجا صرفاً فهرستی از وظایف نیست که مدل آن را بخواند. این برنامه منطق اجرایی واقعی دارد؛ برای نمونه، می‌تواند چند عامل را به‌طور هم‌زمان راه‌اندازی کند، نتیجه مرحله قبلی را به‌عنوان ورودی مرحله بعد به کار ببرد، بر اساس نتیجه بررسی تصمیم بگیرد وظیفه‌ای دوباره اجرا شود یا در صورت شکست یک عامل فرعی، ادامه فرایند را انتخاب کند یا آن را متوقف سازد.
تفاوت اصلی این روش با شیوه سنتی واگذاری وظایف به عامل‌های فرعی، به این برمی‌گردد که چه کسی مراحل بعدی را تعیین می‌کند. در روش قبلی، پس از بازگشت نتیجه عامل فرعی، عامل اصلی معمولاً باید دوباره استدلال کند تا اقدام بعدی را مشخص سازد. اما در Dynamic Workflows، برنامه هماهنگ‌کننده می‌تواند مستقیماً بر اساس داده‌های دریافتی به اجرا ادامه دهد. در نتیجه، عامل اصلی مجبور نیست در هر مرحله از تحویل کار مشارکت کند؛ می‌تواند در زمان اجرای گردش کار در پس‌زمینه به کارهای دیگر بپردازد و پس از پایان اجرا، نتیجه نهایی را بررسی کند.
آنتروپیک در مستندات رسمی هماهنگی چندعاملی در پلتفرم کلود، تفاوت Subagents سنتی و Dynamic Workflows را به‌طور مشخص توضیح داده است. در روش نخست، عامل اصلی بر اساس نتایج وظایف فرعی، مراحل بعدی را به‌تدریج تعیین می‌کند. در روش دوم، منطق‌هایی مانند حلقه‌ها، شاخه‌های شرطی و انتقال نتایج به برنامه هماهنگ‌کننده سپرده می‌شوند تا اجرا شوند. همچنین، داده‌های میانی را می‌توان در متغیرهای برنامه ذخیره کرد و دیگر لازم نیست هر بار برای پردازش مجدد به عامل اصلی بازگردانده شوند.
در نمایش این قابلیت در رویداد، وظیفه بررسی فهرستی از سهام برای رصد بازار به‌عنوان نمونه استفاده شد. در مرحله نخست، بررسی سهام مختلف به عامل‌هایی با زمینه‌های مستقل سپرده می‌شود. در مراحل بعدی، نتایج بررسی کنترل و سپس گزارشی نهایی تهیه می‌شود. این مثال نشان می‌دهد که گردش کار چگونه اجرای توزیع‌شده، بازبینی متمرکز و تجمیع نهایی نتایج را به هم پیوند می‌دهد.
توسعه‌دهندگان همچنان می‌توانند مشارکت عامل‌ها در وظایف را محدود کنند. قابلیت رسمی از دو نوع عامل پشتیبانی می‌کند: عامل‌های ازپیش‌تعریف‌شده و عامل‌هایی که به‌صورت درون‌خطی و موقت تعریف می‌شوند. نوع نخست از مدل‌ها، دستورالعمل‌ها و ابزارهای ازپیش‌تنظیم‌شده استفاده می‌کند؛ نوع دوم متناسب با وظیفه جاری ساخته می‌شود و پیکربندی مدل و ابزارهای مرتبط عامل اصلی را به ارث می‌برد. توسعه‌دهندگان می‌توانند امکان ایجاد عامل‌های موقت را غیرفعال کنند و اجازه دهند گردش کار فقط عامل‌های موجود در فهرستی مشخص را فراخوانی کند. بنابراین، تولید پویای برنامه اجرا و استفاده از عامل‌های تخصصیِ ازپیش‌پیکربندی‌شده می‌توانند در کنار هم به کار روند. برای مثال، توسعه‌دهنده می‌تواند یک عامل اختصاصی برای بازبینی در نظر بگیرد و سپس به کلود اجازه دهد زمان مناسب برای فراخوانی آن را تعیین کند.
Dynamic Workflows نیاز توسعه‌دهندگان به طراحی دستی مسیر اجرای وظایف را کاهش می‌دهد، اما محدودیت‌های آن‌ها بر رفتار سامانه را از میان نمی‌برد. همچنان باید از طریق پیکربندی، سیاست‌های مجوزدهی و سازوکارهای اعتبارسنجی کسب‌وکار مشخص شود چه عامل‌هایی اجازه مشارکت دارند، کدام ابزارها قابل فراخوانی‌اند، چه میزان هزینه مجاز است و چه شرایطی به‌معنای تکمیل وظیفه محسوب می‌شود.
۲. سقف تجمعی ۱۰۰۰ عامل و محدودیت‌های اجرایی بودجه
اگر برای انجام یک وظیفه ساده نیز تعداد زیادی عامل راه‌اندازی شود، چگونه می‌توان از فراخوانی‌های بیش‌ازحد جلوگیری کرد؟ هزینه اجرای سامانه‌های چندعاملی چگونه باید کنترل شود؟ این‌ها از جمله دغدغه‌های بسیاری از توسعه‌دهندگان است.
بر اساس مستندات رسمی آنتروپیک، هر گردش کار پویا می‌تواند در مجموع تا ۱۰۰۰ عامل را راه‌اندازی کند؛ بااین‌حال، حداکثر تعداد رشته‌های اجرایی عامل که به‌طور هم‌زمان فعال‌اند، ۶۴ است و مدت اجرای هر گردش کار نیز به‌طور پیش‌فرض حداکثر ۲۴ ساعت تعیین شده است. به بیان دیگر، عدد ۱۰۰۰ به کل عامل‌های راه‌اندازی‌شده در طول یک چرخه اجرا اشاره دارد؛ این عدد به‌معنای امکان زمان‌بندی هم‌زمان ۱۰۰۰ عامل توسط کلود نیست و تضمین نمی‌کند که وظایف چندعاملی در چنین مقیاسی با ثبات و موفقیت انجام شوند.
این محدودیت‌ها مرزهای اجرایی Dynamic Workflows را مشخص می‌کنند، اما آنتروپیک هنوز پاسخ عمومی و مشخصی برای این پرسش ارائه نکرده است که هر وظیفه به چند عامل نیاز دارد. استال در جلسه پرسش‌وپاسخ رویداد گفت که در حال حاضر، تعداد عامل‌ها عمدتاً از طریق ارزیابی‌ها و تنظیمات پیش‌فرض نسبتاً پایین کنترل می‌شود. برای وظایف پیچیده‌تر، معمولاً باید مدل را صریحاً راهنمایی کرد تا میزان اجرای موازی را افزایش دهد. او همچنین توضیح داد که مدل هنگام اجرا از بودجه در دسترس خود اطلاع ندارد و توسعه‌دهندگان می‌توانند برای هر نشست بودجه تعیین کنند.
هزینه نیز باید با توجه به نوع وظیفه بررسی شود. آویلا در نمایش زنده قابلیت بررسی فهرست سهام گفت که Dynamic Workflows در مقایسه با راهکار تک‌عاملی هزینه بیشتری دارد، اما در عوض می‌تواند جزئیات بیشتری را کشف کند.
برای کنترل هزینه، Managed Agents سازوکاری برای تعیین بودجه در سطح نشست فراهم می‌کند. پلتفرم هزینه‌ها را بر اساس نرخ‌های عمومی و متناسب با مصرف منابعی مانند توکن‌های مدل، جست‌وجوی وب و مدت اجرای نشست محاسبه می‌کند. با رسیدن هزینه به سقف بودجه، سامانه ارسال درخواست‌های جدید به مدل را متوقف می‌کند و وظیفه به حالت تعلیق درمی‌آید. توسعه‌دهندگان می‌توانند با تغییر بودجه، اجرا را از سر بگیرند.
بااین‌حال، این سازوکار کلیدی نیست که بلافاصله همه محاسبات را متوقف کند. درخواست‌هایی که پیش‌تر به مدل ارسال شده‌اند، همچنان تکمیل خواهند شد و در صورت اجرای هم‌زمان چند عامل، هزینه نهایی ممکن است از سقف بودجه فراتر برود. افزون بر این، چون محاسبه بودجه بر اساس نرخ‌های عمومی انجام می‌شود، رقم محاسبه‌شده ممکن است با مبلغ واقعی تسویه‌حساب سازمانی تفاوت داشته باشد.
این مسئله همچنین توضیح می‌دهد که چرا «خواندن تعداد کمتری از نتایج میانی توسط عامل اصلی» لزوماً به «کاهش هزینه کلی» منجر نمی‌شود. هر عاملی که در انجام کار مشارکت می‌کند، هزینه استنتاج ایجاد می‌کند و مراحل اضافی بازبینی نیز به منابع محاسباتی نیاز دارند.
۳. آیا گردش‌های کار می‌توانند خودشان بهتر شوند؟
در جلسه پرسش‌وپاسخ رویداد، پرسش مهم دیگری مطرح شد: اگر یک گردش کار پویا بارها اجرا شود، آیا می‌تواند بر اساس نتایج اجراهای قبلی، عملکرد خود را به‌تدریج بهبود دهد تا وظایف در دفعات بعد با سرعت بیشتر و هزینه کمتر انجام شوند؟
یکی از حاضران با اشاره به نمونه بررسی فهرست سهام پرسید که اگر سامانه متوجه شود مدل مورد استفاده برای بررسی عملکرد مطلوبی ندارد، آیا می‌تواند در اجرای زمان‌بندی‌شده بعدی مدل را به‌طور خودکار جایگزین کند یا فرایند اجرای قبلی را تغییر دهد؟
استال صریحاً اعلام کرد که Dynamic Workflows در حال حاضر چنین قابلیت داخلی‌ای برای بهبود خودکار ندارد. بااین‌حال، او و آویلا به دو روش احتمالی برای بهبود اشاره کردند: روش Hill-climbing و قابلیت Dreaming که آنتروپیک در حال پژوهش روی آن است.
Dreaming را می‌توان سازوکاری برای سامان‌دهی حافظه بر اساس تجربه‌های گذشته عامل‌ها دانست. بر اساس تعریف ارائه‌شده در مستندات رسمی Dreaming آنتروپیک، این قابلیت پایگاه حافظه موجود و سوابق نشست‌های قبلی را می‌خواند، اطلاعات تکراری را ادغام می‌کند، محتوای قدیمی یا متناقض را جایگزین می‌سازد، تجربه‌های تازه را از نشست‌های پیشین استخراج می‌کند و در نهایت پایگاه حافظه‌ای بازسازمان‌دهی‌شده تولید می‌کند.
این فرایند مستقیماً حافظه اصلی را بازنویسی نمی‌کند. Dreaming یک پایگاه حافظه مستقل و جدید می‌سازد تا توسعه‌دهندگان بتوانند محتوای آن را بررسی کنند و سپس درباره استفاده از آن در نشست‌های بعدی تصمیم بگیرند. این قابلیت در حال حاضر در مرحله پیش‌نمایش پژوهشی قرار دارد و استفاده از آن به دریافت مجوز دسترسی نیازمند است.
آویلا توضیح داد که Dreaming می‌تواند به عامل‌ها کمک کند تجربه‌های به‌دست‌آمده در نشست‌های قبلی را بهتر استخراج و تثبیت کنند. برای گردش‌های کاری که باید بارها اجرا شوند، این قابلیت به توسعه‌دهندگان فرصت می‌دهد مشکلات مشاهده‌شده در اجراهای گذشته، اطلاعات انباشته‌شده و روش‌های مؤثر پردازش را در قالب حافظه‌هایی سامان دهند که وظایف بعدی بتوانند از آن‌ها استفاده کنند. سازوکار حافظه در Managed Agents به توسعه‌دهندگان اجازه می‌دهد پایگاه حافظه را به نشست‌های جدید متصل کنند تا عامل‌ها بتوانند اطلاعات مرتبط را میان نشست‌های مختلف حفظ کنند.
بااین‌حال، سامان‌دهی حافظه با بهینه‌سازی گردش کار دو موضوع متفاوت‌اند. Dreaming به‌خودی‌خود تصمیم نمی‌گیرد چند عامل باید راه‌اندازی شوند یا از کدام مدل استفاده شود؛ همچنین برنامه هماهنگ‌کننده‌ای را که کلود تولید کرده است، به‌طور خودکار تغییر نمی‌دهد. روش Hill-climbing ایده دیگری را دنبال می‌کند: یافتن پیکربندی یا راهبرد اجرایی بهتر از طریق ارزیابی‌های مکرر و اصلاحات محدود و مرحله‌ای. بااین‌حال، آنتروپیک در این نوبت جزئیات پیاده‌سازی کامل و ادغام این سازوکارها با Dynamic Workflows را اعلام نکرد.
بنابراین، کلود اکنون می‌تواند بر اساس نیاز وظایف، برنامه‌های هماهنگی چندعاملی را به‌صورت پویا تولید کند؛ اما گردش‌های کار هنوز نمی‌توانند چرخه کاملی از «اجرا، ارزیابی، اصلاح و راستی‌آزمایی مجدد» را به‌طور خودکار شکل دهند. برای بهینه‌سازی مستمر وظایف تکرارشونده، توسعه‌دهندگان همچنان باید شاخص‌های ارزیابی را طراحی کنند، نتایج اجراها را ثبت کنند و تصمیم بگیرند تجربه‌های گذشته چگونه در اجرای بعدی به کار گرفته شوند.
۴. عامل‌ها می‌توانند کار را به یکدیگر بسپارند، اما امکان گفت‌وگوی آزاد گروهی ندارند
در Dynamic Workflows، با وجود آنکه هر عامل فرعی زمینه گفت‌وگوی مستقلی دارد، عامل‌ها کاملاً از یکدیگر جدا نیستند. طبق مستندات رسمی اجرای گردش کار آنتروپیک، آن‌ها علاوه بر انتقال نتایج از طریق برنامه هماهنگ‌کننده، می‌توانند با کمک فایل‌سیستم مشترک در محیط ایزوله نشست نیز اطلاعات ردوبدل کنند.
انتقال اطلاعات عمدتاً به دو روش انجام می‌شود. در روش نخست، برنامه هماهنگ‌کننده مسئولیت انتقال را بر عهده دارد: پس از آنکه عاملی وظیفه خود را تکمیل کرد و نتیجه را بازگرداند، برنامه می‌تواند محتوای مرتبط را به‌عنوان ورودی در اختیار عامل بعدی قرار دهد. برای مثال، یک عامل ابتدا کد را تحلیل می‌کند و سپس نتیجه تحلیل برای بازبینی به عامل دیگری سپرده می‌شود. روش دوم از طریق فایل‌سیستم مشترک انجام می‌شود؛ عامل‌های مختلف می‌توانند محصولات میانی کار خود را در فایل‌ها ذخیره کنند تا سایر عامل‌ها آن‌ها را بخوانند و به کار بگیرند.
بااین‌حال، این شیوه همکاری با ارسال مستقیم پیام میان عامل‌ها تفاوت دارد. استال در جلسه پرسش‌وپاسخ توضیح داد که توسعه‌دهندگان در حال حاضر نمی‌توانند از طریق رابط برنامه‌نویسی کاربردی (API)، مستقیماً از یک عامل فرعی در گردش کار بخواهند برای عامل فرعی دیگری پیام بفرستد. اتصال وظایف میان عامل‌ها عمدتاً به منطق اجرایی و داده‌های مشترکی متکی است که در برنامه هماهنگ‌کننده تعریف شده‌اند.
این روش همچنین با الگوی تعامل در Subagents معمولی تفاوت دارد. در روش سنتی می‌توان رشته گفت‌وگوی عامل فرعی را حفظ کرد تا عامل اصلی پیام‌های بعدی را به همان عامل بفرستد. اما در Dynamic Workflows نمی‌توان به همین شیوه پیام‌های جدیدی به رشته‌های اجرایی عامل‌های فرعی افزود و این رشته‌ها پس از پایان اجرای گردش کار بایگانی می‌شوند.
فایل‌سیستم مشترک مسئله مهندسی دیگری نیز ایجاد می‌کند: جداسازی زمینه گفت‌وگو به‌معنای جداسازی دسترسی به فایل‌ها نیست. اگرچه سابقه گفت‌وگوی هر عامل مستقل است، همه آن‌ها می‌توانند به فایل‌های مشترک در محیط یک نشست دسترسی داشته باشند. بنابراین، هنگام کار با کد، فایل‌های پیکربندی یا داده‌های حساس، توسعه‌دهندگان باید احتمال بازنویسی فایل‌ها، تعارض در وضعیت مشترک و تفاوت سطح دسترسی عامل‌های مختلف را نیز در نظر بگیرند.
Dynamic Workflows هم‌اکنون می‌تواند در وظایف چندمرحله‌ای که به «تحلیل اولیه، سپس بازبینی و در نهایت تجمیع» نیاز دارند، انتقال کار میان عامل‌ها را از طریق برنامه انجام دهد. اما اگر هدف این باشد که چند عامل به‌طور پیوسته با یکدیگر بحث کنند و در هر زمان پیام‌های مستقیمی برای هم بفرستند، نمی‌توان این سازوکار هماهنگی را معادل یک شبکه چندعاملی با قابلیت ارتباط آزاد دانست.
۵. پس از اجرای برنامه، وظیفه همچنان به بررسی و تأیید نهایی نیاز دارد
اینکه چند عامل بتوانند مطابق یک فرایند کار را به یکدیگر بسپارند، به این معنا نیست که همه مراحل لزوماً بدون مشکل تکمیل می‌شوند. در وظایف طولانی، توسعه‌دهندگان باید به یک پرسش مهم پاسخ دهند: آیا پایان گردش کار به‌معنای تکمیل موفق وظیفه است؟
در مستندات رسمی، نکته مهمی درباره قابلیت اطمینان وظایف طولانی مطرح شده است: وضعیت completed برای گردش کار فقط به این معناست که اجرای برنامه پایان یافته است. حتی اگر وظیفه بعضی از رشته‌های اجرایی با شکست مواجه شده باشد یا ایجاد یک رشته اجرایی ناموفق بوده باشد، ممکن است کل فرایند همچنان با وضعیت completed خاتمه پیدا کند.
مستندات رسمی میان خطاهای برنامه و ناقص‌بودن نتایج وظیفه نیز تمایز قائل می‌شود. اگر اجرای کد گردش کار شکست بخورد یا خطای یک عامل فرعی در خود گردش کار مدیریت نشود، ممکن است اجرا با وضعیت program_error پایان یابد. اما اگر برنامه هماهنگ‌کننده خطا را تشخیص دهد و اجرای کار را ادامه دهد، ممکن است در نهایت همچنان وضعیت completed را برگرداند. بنابراین، مدیریت خطا در سطح برنامه لزوماً به‌معنای موفقیت وظیفه در سطح کسب‌وکار نیست.
برای مثال، ممکن است در یک وظیفه بازبینی گروهی، گزارش تجمیعی تولید شده باشد، اما برخی از اسناد و اطلاعات با موفقیت خوانده نشده باشند. اگر برنامه کاربردی فقط وضعیت نهایی را بررسی کند، ممکن است گزارشی ناقص را به‌اشتباه نشانه تکمیل همه وظایف بداند.
ازاین‌رو، بررسی نهایی نباید فقط بر وضعیت اجرا متکی باشد؛ بلکه باید میزان پوشش وظایف، موارد ناموفق و نتایج کلیدی را نیز کنترل کند. در وظایف برنامه‌نویسی می‌توان نتایج آزمون‌ها و فرایند ساخت نرم‌افزار را بررسی کرد. در بازبینی اسناد نیز باید فهرست موارد پردازش‌نشده حفظ شود و مشخص باشد کدام نتیجه‌گیری‌ها مورد بازبینی قرار گرفته‌اند.
خود برنامه هماهنگ‌کننده‌ای که مدل تولید می‌کند نیز ممکن است خطا داشته باشد؛ از جمله شکست در اجرا، پایان‌یافتن مهلت زمانی یا عبور از سقف تعداد عامل‌ها. اجرای مجدد پس از خطا نیز ممکن است باعث ایجاد رشته‌های اجرایی جدید برای همان کار شود. اگر ابزار مورد استفاده داده‌ها را در یک سامانه خارجی ثبت کند، توسعه‌دهندگان باید فراخوانی‌های تکراری را نیز مدیریت کنند تا هنگام تلاش مجدد، یک رکورد چند بار ثبت نشود. بنابراین، سازوکارهای راستی‌آزمایی و بازیابی متناسب با نیاز هر کسب‌وکار همچنان ضروری‌اند.
Dynamic Workflows بخشی از وظایف زمان‌بندی و هماهنگی را که پیش‌تر بر عهده عامل اصلی بود، به برنامه واگذار می‌کند و به کلود امکان می‌دهد همکاری چندعاملی را متناسب با نیاز هر وظیفه سازمان‌دهی کند. بااین‌حال، مشخص‌شدن اینکه این روش در پروژه‌های واقعی نتایج بهتری به همراه دارد یا نه، به ارزیابی نرخ تکمیل وظایف، توانایی بازیابی پس از شکست و هزینه کلی اجرا نیاز دارد. به‌ویژه با افزایش تعداد عامل‌ها، راستی‌آزمایی نتایج میانی، مدیریت وضعیت مشترک و کنترل سربار محاسباتی همچنان از مسائلی هستند که توسعه‌دهندگان باید برای آن‌ها راه‌حل پیدا کنند.
منابع:
- مستندات هماهنگی چندعاملی در پلتفرم کلود
- مستندات اجرای گردش کار
- گزارش مربوط به Dynamic Workflows در وب‌سایت Latent Space
این مقاله از حساب رسمی وی‌چت InfoQ با شناسه infoqchina گرفته شده است. نویسندگان آن لین چی‌بِی و کای فانگ‌فانگ هستند و انتشار آن با مجوز 36Kr انجام شده است.