واگذاری کار به عامل‌ها

این راهنما به این می‌پردازد که چگونه کار را از دوش خود بردارید و به یک عامل بسپارید و وقتی عامل‌ها کار را میان خودشان دست‌به‌دست می‌کنند چه اتفاقی می‌افتد.

سپردن یک تیکت به یک عامل

تیکت را بسازید با عنوانی و شرحی که به‌قدر کافی دقیق باشند تا بتوان بر اساس‌شان کار کرد.
تخصیص‌یافتهی آن را روی عامل بگذارید تا مالکیت ثبت شود.
فضایی را باز کنید (یا بسازید) و آن عامل را با @ منشن کنید.
در پیام‌تان با یک منشن # به تیکت ارجاع دهید — نویسندهٔ پیام تیکت‌های فضای کاری را خودکار کامل می‌کند — و بگویید چه می‌خواهید انجام شود.

عامل کار را از گفتگو برمی‌دارد. پیشرفتش به‌صورت زنده در همان فضا جریان می‌یابد.

آنچه عامل دریافت می‌کند

پیام شما، همراه با ارجاع تیکتی که برچسب زدید.
فضایی برای کار و گزارش دادن.
یک worktree ایزوله از مخزن‌های پیوندشدهٔ فضای کاری.
حالت فضا، که همان چیزی است که سطح ابزار اجرا را تعیین می‌کند.

حالت ویژگی فضا است، نه تیکت — تیکت حالتی ندارد. بنابراین یک عامل می‌تواند در یک فضا در chat باشد و در فضایی دیگر در plan. آن را از فهرست بازشوی حالتِ نویسندهٔ پیام انتخاب کنید (عامل، برنامه یا ارکستر)؛ review را فضاهای بازبینی PR تعیین می‌کنند و انتخاب‌پذیر نیست. حالت‌ها را ببینید.

درخواست یک نتیجهٔ ساختاریافته

قرارداد خروجی روی اعزام اعلام می‌شود، نه روی تیکت: expected_output_schema به‌علاوهٔ output_contract_mode (به‌طور پیش‌فرض strict). عامل آن را با فراخوانی submit_output برآورده می‌کند؛ این فراخوانی بار داده را با اسکیما اعتبارسنجی می‌کند و داده‌ای را که مطابق نباشد رد می‌کند.

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

پایش پیشرفت

فضا — فعالیت زندهٔ عامل، نمای اصلی.
تیکت — وضعیتش، همان‌طور که هر کس آن را جابه‌جا می‌کند تعیین می‌کند.
مشاهده‌پذیری → زنده (/workspaces/<workspace-id>/observability) — فهرست زندهٔ عامل‌ها.
مشاهده‌پذیری → بینش‌ها — گزارش اجرا، همراه با هزینه و مدت.

هیچ صفحهٔ داشبوردی وجود ندارد؛ یک URL خالی فضای کاری به صندوق ورودی هدایت می‌شود.

بگذارید عامل‌ها به یکدیگر واگذار کنند

عاملی که به یک زیرمسئله می‌خورد، با ابزار MCP به نام delegate_task واگذاری می‌کند. این ابزار یک تیکت فرزند می‌سازد که به عاملی دیگر تخصیص یافته و — وقتی parent_ticket_id را می‌فرستید — زنجیره را ثبت می‌کند تا گاردها بتوانند آن را ببینند.

دو گارد ساختاری همیشه و در گلوگاه تیکتینگ اجرا می‌شوند، هرگز به فرمان پرامپت:

سقف عمق — زنجیره‌ای عمیق‌تر از ۳ جهش رد می‌شود.
تشخیص چرخه — جهشی بازگشتی به عاملی که از قبل در زنجیره است رد می‌شود.

وقتی from_agent_id را می‌فرستید، دو گارد دیگر اجرا می‌شوند (محیط تولید همیشه پورت‌های حل‌کننده را تأمین می‌کند):

سقف خودمختاری — سطح مؤثر واگذارشده در فضا نباید از سطح واگذارکننده بیشتر باشد.
پاکت بودجه — واگذاری از بودجهٔ توقف سختِ باقی‌ماندهٔ واگذارکننده برداشت می‌کند و نمی‌تواند بیشتر خلق کند. نبودِ سیاست، یا سیاستی نامحدود، می‌گذرد.

یک رد پرصداست: ابزار دلیل گارد را عیناً برمی‌گرداند، پس عامل واگذارکننده دقیقاً می‌بیند چرا. فیلد delegatedByAgentId ثبت می‌کند چه کسی واگذار کرده است و یک درخت واگذاری می‌سازد.

این سقف عمق واگذاری ۳ محدودیتی متفاوت از سقف تودرتویی زیرعاملِ هارنس داخلی (۲) است — یکی تیکت‌ها را میان عامل‌ها مقید می‌کند و دیگری زیرعامل‌ها را درون یک اجرای واحد.

گذاشتن چند عامل روی یک تیکت

آن‌ها را به‌عنوان همکاران روی تیکت اضافه کنید (نقش‌ها: assignee، collaborator، reviewer). این تنها یک فهرست است — ثبت اینکه چه کسی درگیر است — و به‌خودی‌خود چیزی نمی‌بخشد.

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

ایجاد خودکار تیکت

هیچ گره‌ای در پالت پایپ‌لاین تیکت نمی‌سازد، بنابراین یک پایپ‌لاین نمی‌تواند کار را به‌صورت تیکت‌های تخصیص‌یافته پخش کند.

مسیری که وجود دارد ارکستراسیون است: تأیید یک پیشنهاد، یک پروژه و یک تیم می‌سازد، DAG زیرتیکت‌های پیشنهاد را به یک قالب پایپ‌لاین کامپایل می‌کند (یک گام promptAgent به‌ازای هر زیرتیکت، نه یک ردیف Ticket برای هرکدام) و آن اجرا را شروع می‌کند. اجرای یک ارکستراسیون را ببینید.