از عوامل انفرادی تا ارکستراسیون تیمی: ساختن چندین عامل هوش مصنوعی در واقع با هم کار کنند

توسعه دهندگان بیشتری در حال حاضر چندین ابزار هوش مصنوعی را به طور همزمان اجرا می کنند: Claude برای کد، GPT برای اسناد، یک عامل تخصصی برای تجزیه و تحلیل داده ها. هر کدام کار خود را انجام می دهد و سازنده به نظر می رسد.

اما این نوع موازی‌سازی فقط به صورت دستی بیشتر است، نه همکاری واقعی. لحظه ای که سعی می کنید چندین عامل را برای انجام یک کار با وابستگی ها جذب کنید، پیچیدگی به سطح کاملاً متفاوتی می رود.

چه کسی چه چیزی را می بیند

اولین سوالی که وقتی عوامل همزمان کار می کنند این است که چه کسی چه چیزی را می بیند. دو نماینده که نیمه اول و دوم پروپوزال را می نویسند. آیا آنها باید پیشرفت یکدیگر را ببینند یا کورکورانه کار کنند و اجازه دهند یک انسان خروجی را ادغام کند؟ اگر آنها نمی توانند یکدیگر را ببینند، چگونه می توانید سبک را ثابت نگه دارید و از تکراری شدن اجتناب کنید؟ اگر می‌توانند، وقتی عامل A خروجی B را می‌خواند و به جهت دیگری کشیده می‌شود، چگونه تداخل را مدیریت می‌کنید؟

هیچ پاسخ جهانی وجود ندارد، این کاملا به وظیفه بستگی دارد. طوفان فکری به عواملی نیاز دارد که ایده های یکدیگر را ببینند و بر اساس آنها بسازند. وظایف خط لوله فقط به خروجی بالادست نیاز دارند، هر چیز اضافی نویز است. آنچه شما نیاز دارید کنترل دید قابل تنظیم با توپولوژی های اطلاعاتی مختلف برای حالت های مختلف کار است. اکثر چارچوب‌های موجود این انتزاع را ایجاد نکرده‌اند، بنابراین توسعه‌دهندگان آن را در درخواست‌های خود وصله می‌کنند.

انتقال نتایج بین مراحل

وقتی کارها چندین مرحله را در بر می گیرند، ارائه نتایج دشوار می شود. عامل A کد را می نویسد، عامل B آن را بررسی می کند، B مشکلات را پیدا می کند و به A می فرستد، A آن را برطرف می کند و دوباره به B ارسال می کند، B آن را تایید می کند و برای مستندسازی به C ارسال می کند. این جریان نیاز به یک ماشین وضعیت واضح دارد که وظیفه را در کدام مرحله است، چه کسی نسخه فعلی را نگه می دارد، چه کسی منتظر ورودی است.

موتورهای گردش کار سنتی وظایف انسانی را انجام می دهند که در آن تغییرات حالت آهسته است، یک مرحله ممکن است ساعت ها یا روزها طول بکشد. Agent ها بسیار سریعتر اجرا می شوند، در عرض چند دقیقه از طریق چندین مرحله انجام می شوند، با تغییرات حالت بسیار بیشتر از جریان های کاری انسانی اتفاق می افتد. همچنین زمانی که نمایندگان به طور موازی کار می کنند، شرایط مسابقه را دریافت می کنید: دو نماینده که یک سند را به طور همزمان ویرایش می کنند یا بر اساس اطلاعات قدیمی یکسان تصمیم می گیرند و نتایج متناقضی تولید می کنند. و در گردش‌های کاری سنتی، هر گره تأیید انسانی دارد. اگر عامل ها فقط نتایج را بدون بررسی پذیرش به پایین دست منتقل کنند، خروجی با کیفیت پایین جریان می یابد و خطاها در طول زنجیره تقویت می شوند.

لایه ارکستراسیون گمشده

اکثر چارچوب‌های چند عامله مشکل راه‌اندازی چندین عامل را حل می‌کنند، اما نه اینکه چگونه آنها را به همکاری وادار کنیم. چندین عامل همزمان در حال اجرا هستند. چگونه آنها را هماهنگ می کنند، پوشه های مشترک، صف های پیام یا مکالمه مستقیم را انجام می دهند؟ در عمل، توسعه دهندگان کدهای چسب زیادی را برای مدیریت تعاملات عامل می نویسند، هیچ کدام استاندارد نشده اند، و همه آن ها برای هر سناریوی جدید بازنویسی می شوند. اشکال‌زدایی حتی سخت‌تر است: وقتی چندین عامل خروجی غیرمنتظره تولید می‌کنند، تعیین دقیق مرحله اشتباه دشوار است زیرا استدلال داخلی هر عامل غیرشفاف است و گزارش‌های تعامل در همه جا پراکنده هستند.

لایه ارکستراسیون نیاز به تعریف حالت های مختلف همکاری دارد. نمایندگانی که درباره موضوعی با یک انسان که آخرین تماس را برقرار می کند بحث می کنند، این حالت میزگرد است. یک عامل کار را انجام می‌دهد و آن را برای بررسی به دیگری می‌سپارد، رد کردن یعنی دوباره کاری، این حالت انتقادی است. یک کار بزرگ که به وظایف فرعی تقسیم می شود که به صورت موازی اجرا می شوند و سپس ادغام می شوند، این حالت تقسیم است. هر حالت دارای جریان اطلاعات، مرزهای مجوز و مکانیسم های پذیرش متفاوت است. یک رفتار پیش فرض نمی تواند همه آنها را پوشش دهد.

Octo شش حالت ارکستراسیون را در سطح چارچوب ارائه می دهد: انفرادی (اجرای مستقل)، میزگرد (بحث گروهی)، Critic (جریان کاری مرور)، Pipeline (تقویت متوالی)، تقسیم (پارتیشن بندی وظایف)، و Swarm (هوش جمعی). هر حالت قوانین دید و مکانیسم های انتقال حالت خاص خود را دارد. توسعه دهندگان به جای منطق همکاری کدگذاری برای هر سناریو، حالتی را انتخاب می کنند که متناسب با کار باشد. این امر ارکستراسیون را از کد چسب به زیرساخت قابل تنظیم تبدیل می کند.

مرزهای هویت و مجوز

هر عامل باید دارای مرزهای هویت و توانایی روشن باشد. عاملی که برای بازبینی کد پیکربندی شده است نباید الزامات محصول را ویرایش کند. یک عامل تجزیه و تحلیل داده ها نباید اجازه لمس پایگاه های داده تولید را داشته باشد. مدیریت مجوز در محیط‌های چند عاملی بسیار پیچیده‌تر از IAM سنتی است: سیستم‌های سنتی دارای هویت‌های کاربر نسبتاً ثابت با نگاشت‌های مجوز نقش روشن هستند. هویت عامل ممکن است با زمینه کار تغییر کند. همان عامل ممکن است یک مجری در پروژه A و یک بازبینی کننده در پروژه B باشد، با مجوزهایی که نیاز به دنبال کردن سناریو دارند.

وقتی یک نماینده از طرف یکی از اعضای تیم عمل می کند، آیا باید دامنه مجوز آن شخص را به ارث ببرد یا یک مدل مجوز مستقل داشته باشد؟ هنوز اتفاق نظری در صنعت وجود ندارد، اما باید به آن رسیدگی شود. رویکرد Octo با نمایندگان به‌عنوان افزونه‌های نیروی کار دیجیتالی سازندگانشان رفتار می‌کند، که مجوز را به ارث می‌برند و ترجیحات سلیقه‌ای را برای تکمیل کار به ارث می‌برند، با مرزهای هویت و توانایی که به وضوح از طریق AgentCard مشخص شده‌اند.

آن را امتحان کنید

چرخاندن چند عامل آسان است. واداشتن آنها به همکاری قابل اعتماد و تولید نتایج قابل ردیابی نیاز به زیرساخت های زیادی دارد. جریان اطلاعات، مجوزها، مدیریت وضعیت، بررسی های پذیرش، قابلیت ردیابی، هر بعد نیاز به طراحی دقیق دارد.

Octo اکنون در GitHub کاملاً منبع باز است، با سرور، سرویس گیرنده وب/دسکتاپ، iOS، Android و پایگاه کدهای CLI، تحت Apache 2.0. اگر در حال کاوش در مسیر مهندسی برای همکاری چند عامل هستید، کد را بکشید و آن را امتحان کنید. اسناد استقرار در octo-deployment مخزن با استقرار K8s مانیفست آماده به کار است. جامعه تازه شروع شده است. اگر این جهت ارزشمند به نظر می رسد، ستاره ای را رها کنید و بازخورد اولیه شما مستقیماً به جایی که محصول می رود شکل می دهد.