مدل عامل
عامل چیست؟
بخش با عنوان “عامل چیست؟”عامل یک کنشگر نام‌دار با یک پرسونا، مجموعه‌ای از مهارت‌ها و یک آداپتور برای اجراست. عامل‌ها به همان معنایی که انسان‌ها کنشگر مستقل‌اند، کنشگر مستقل محسوب می‌شوند: پیام می‌نویسند، مالک تیکت هستند، بازبینی می‌گذارند و در همان فهرست حضور ظاهر می‌شوند. کار واقعی را همین‌ها انجام می‌دهند.
هر عامل دقیقاً به یک فضای کاری تعلق دارد. این یک نامتغیر سخت است — agent.workspaceId تهی نیست، فضای کاری خودِ عامل است که تعیین می‌کند سطرهایش در کدام فایل پایگاه داده بنشینند و ساخت عامل بدون فضای کاری رد می‌شود.
عامل همچنین یک پوشه است. تعریفش در agents/<slug>/AGENTS.md زیر پوشهٔ دادهٔ فضای کاری زندگی می‌کند و مهارت‌هایی که دارد به‌صورت پیوند نمادین در agents/<slug>/.agents/skills قرار می‌گیرند. سطر پایگاه داده و فایل با هم نوشته می‌شوند. بذرکاری خودتوان است: اگر سطر عامل از قبل وجود داشته باشد، فایل‌های روی دیسک و پیوندهای مهارت باز هم بازنویسی می‌شوند. فراخوان‌کنندهٔ تولیدی، ساخت فضای کاری است، نه هر بار راه‌اندازی سرور.
یک عامل چه چیزهایی حمل می‌کند
بخش با عنوان “یک عامل چه چیزهایی حمل می‌کند”| ویژگی | کارکرد |
|---|---|
name |
شناسهٔ کوتاه شبیه اسلاگ (architect، qa). همچنین چیزی که @mentions بر پایهٔ آن حل می‌شوند |
title |
عنوان شغلی خوانا برای انسان |
persona |
متن آزاد شخصیت و دستورالعمل‌های رفتاری که به‌صورت یک بخش پرامپت تزریق می‌شود |
systemPrompt |
دستورالعمل‌های اضافی اختیاری که به‌صورت بخشی با عنوان «دستورالعمل‌های عامل» تزریق می‌شوند — جای بقیهٔ پرامپت سرهم‌شده را نمی‌گیرند |
skills |
مجموعه‌ای از نام مهارت‌ها بدون حساسیت به بزرگی و کوچکی حروف که به‌صورت پیوندهای مهارت روی دیسک بازتاب می‌یابد |
adapterId |
اینکه عامل به کدام اجراکننده اعزام می‌شود. مقدار تهی به حلقهٔ داخلی برمی‌گردد |
modelId |
اینکه کدام مدل در آن آداپتور |
effort |
سطح استدلال، برگرفته از واژگان خودِ مدل انتخاب‌شده |
contextSize |
مقدار جایگزین برای پنجرهٔ زمینه |
silenceTimeoutMinutes |
مقدار جایگزین هر عامل (1–240) برای نگهبان سکوت |
reportsTo |
شناسهٔ عامل والد — زنجیرهٔ گزارش‌دهی که چارت سازمانی ترسیم می‌کند |
همهٔ این‌ها را در تنظیمات → فضای کاری → عامل‌ها ویرایش می‌کنید. عامل جدید یک عامل بی‌نام می‌سازد که سپس آن را پر می‌کنید.
مهارت‌ها
بخش با عنوان “مهارت‌ها”مهارت‌ها نام‌هایی روی موجودیت عامل هستند که به بزرگی و کوچکی حروف حساس نیستند. دو چیز جداگانه با آن‌ها رخ می‌دهد:
- نام‌ها زیر عنوانی به نام «مهارت‌ها» در پرامپت سرهم‌شده فهرست می‌شوند. همین تمام کاری است که مجموعهٔ موجودیت به‌تنهایی انجام می‌دهد — کتابخانهٔ پرامپتی برای تک‌تک مهارت‌ها که بر پایهٔ آن کلید بخورد وجود ندارد.
- پوشهٔ هر مهارت نام‌دار (
skills/<slug>/SKILL.mdدر فضای کاری) به پوشهٔ خودِ عامل پیوند می‌شود. روی هارنس داخلی، فرانت‌مترِ مهارت‌های پیوندشده به‌طور خودکار در پرامپت سیستمی بارگذاری می‌شود و عامل متن اصلی را در صورت نیاز می‌خواند؛ تایپ/skill:<name>در یک گفتگو آن متن را به‌عنوان دستوری برای همان نوبت بارگذاری می‌کند.
مهارت‌هایی که از بیرون واکشی می‌شوند، میان واکشی و نوشتن از یک اسکن زنجیرهٔ تأمین که در برابر خطا بسته است می‌گذرند — هیچ محتوای مهارتی بدون حکم به دیسک یا پرامپت نمی‌رسد. «بیرون» مخزن‌های GitHub هستند که خودتان آن‌ها را به‌عنوان منبع مهارت ثبت می‌کنید: فروشگاه گزینش‌شده‌ای وجود ندارد، پس فرادادهٔ خود مخزن (توصیفش، ستاره‌هایش، نام مهارت) دادهٔ نمایشی نامعتمد است و حکم اسکن تنها سیگنال امنیتی است. نصب، تمام پوشهٔ مهارت را واکشی می‌کند، آن را در skills-lock.json به همان کامیتی که از آن آمده سنجاق می‌کند و به‌روزرسانی بعدی پیش از جایگزینی هر چیزی دوباره از این دروازه می‌گذرد. روش کار در نصب و مدیریت مهارت‌ها آمده است.
مهارت‌های محدود به مخزن
بخش با عنوان “مهارت‌های محدود به مخزن”یک مخزن می‌تواند مهارت‌های خودش را در هر یک از جاهای مرسوم (.agents/skills/، .claude/skills/، .opencode/skills/) ارائه کند. فضا هر مخزن پیوندشده را جداگانه زیر repos/<name>/ چک‌اوت می‌کند، اما عامل هر بار در یک مخزن کار می‌کند — پس فقط مهارت‌های همان مخزن را با خود دارد و با جابه‌جایی، آن‌ها عوض می‌شوند.
اینکه کدام مخزن فعال است از فایل‌هایی که عامل لمس می‌کند استنتاج می‌شود: نوشتن یک فایل زیر repos/<name>/ آن را مخزن فعال می‌کند، در حالی که فقط خواندن در چند مخزن این کار را نمی‌کند؛ بنابراین دنبال‌کردن یک نماد در سرویسِ همسایه هرگز مجموعه را از زیر کار بیرون نمی‌کشد. در فضایی که فقط یک مخزن دارد، پاسخ پیش از نخستین نوبت روشن است.
این محدودسازی تصمیمی دربارهٔ بودجهٔ زمینه است. فهرست مهارت‌ها در هر نوبت در پرامپت می‌نشیند ولی متن اصلی نه، پس فهرست‌کردن مهارت‌های همهٔ مخزن‌ها به‌طور پیوسته توکن می‌سوزاند — و یک مهارت testing از یک سرویس، وقتی کار در سرویس دیگری است، فعالانه گمراه می‌کند. همین استدلال توضیح می‌دهد چرا فهرست یک عامل یک مخزن را حمل می‌کند اما ویرایشگر این‌طور محدود نشده است: نام‌بردن خودتان از یک مهارت یک کنش صریح است، پس /skill:<repo>:<name> به هر مخزنی در فضا می‌رسد.
مهارت‌های مخزن برای هر آداپتوری بارگذاری می‌شوند، نه فقط هارنس داخلی. مهارت‌های مخزن فعال در پوشهٔ کاری عامل ایجاد می‌شوند، همان مسیری که Claude Code از قبل اسکن می‌کند؛ همان فهرست نیز در AGENTS.md که هارنس داخلی می‌خواند ترکیب می‌شود. مهارت‌های یک مخزن پیش از همهٔ این‌ها از همان اسکن بسته در برابر خطا می‌گذرند که یک مهارت نصب‌شده می‌گذرد — مخزن چک‌اوت‌شده محتوای کلون‌شده است و فرانت‌متر آن به پرامپت می‌رسد.
مجوزها
بخش با عنوان “مجوزها”عامل هیچ پرچم مجوزی ندارد. اینکه بتواند کامیت بسازد، پوش کند، pull request باز کند، در یک ردیاب بنویسد یا به شبکه دسترسی داشته باشد را گاردریل‌های کنش تعیین می‌کنند — اجازه، ابتدا بپرس یا رد، در محدودهٔ فضای کاری، عامل یا فضا — و همین قواعد صرف‌نظر از اینکه کدام آداپتور آن را اجرا کند اعمال می‌شوند.
آنچه به یک اجرا داده می‌شود با این قواعد تغییر نمی‌کند. اجرایی که در یک worktree گیت‌هاب است همیشه یک توکن فقط‌خواندنی GitHub می‌گیرد و پوش در همان لحظه‌ای که رخ می‌دهد پرسیده می‌شود: پیکربندی git عامل هر پوش به GitHub را از طریق Control Center می‌فرستد، که پیش از عبور دادن آن قاعدهٔ پوش به یک ریموت را اعمال می‌کند.
برای اینکه این سازوکار چگونه کار می‌کند، از جمله اینکه در سطح فایل‌سیستم چه چیزی اعمال می‌شود و چه چیزی نه، سندباکس و امنیت را ببینید.
آداپتور تعیین می‌کند چه چیزی قابل اعمال است
بخش با عنوان “آداپتور تعیین می‌کند چه چیزی قابل اعمال است”تنها فیلد تعیین‌کننده‌ترین روی یک عامل، آداپتور آن است، چون شیوهٔ انتقال آداپتور مشخص می‌کند چه مقدار از سیاست Control Center واقعاً قابل اعمال است.
| شیوهٔ انتقال | آداپتورها | آنچه Control Center اعمال می‌کند |
|---|---|---|
| هارنس داخلی | Control Center (داخلی) | همه‌چیز. سطح ابزار از حالت ساخته می‌شود، پس ابزار غیرمجاز به‌جای اینکه فقط رد شود، نامرئی است؛ هر فراخوانی از دروازهٔ تأیید و گاردریل‌های کنش می‌گذرد؛ قرارداد تکمیل می‌تواند تلنگر بزند و سپس اجرایی را که بدون تحویل‌دادنی‌اش تمام شود ناموفق اعلام کند |
| Claude CLI | Claude Code | ابزارهای mcp__* که در اختیارش گذاشته می‌شود، و فرمان‌های Bash آن، که یک هوک پیش از اجرا به سیاست کنش می‌فرستد. ابزارهای خواندن، نوشتن و ویرایش خود Claude در فرایند آن زندگی می‌کنند و دیده‌نشده اجرا می‌شوند — و با --dangerously-skip-permissions راه‌اندازی می‌شود، چون در غیر این صورت claude -p غیرتعاملی برای همیشه روی پرامپت خودش قفل می‌شود |
به‌طور مشخص، تنها هارنس داخلی از زیرعامل‌ها، هدایت میان‌اجرا، توقف و ازسرگیری (و در نتیجه تصاحب) و اعمال ساختاری حالت پشتیبانی می‌کند. Claude Code هیچ‌کدام از این‌ها را ندارد.
عاملی که هیچ آداپتوری ندارد به Control Center (داخلی) برمی‌گردد — همان حلقهٔ درون سرور، پس CLIای برای نصب وجود ندارد — و گزارش اجرای آن cc-harness را ثبت می‌کند. هر عامل بذرکاری‌شده بدون آداپتور یا مدل ساخته می‌شود، پس پنج عامل یک فضای کاری تازه همگی تا زمانی که برای هر عامل آداپتور و مدل تعیین کنید، همان‌جا روی مدل پیش‌فرض Anthropic اجرا می‌شوند. انتخاب «آداپتور پیش‌فرض» در راه‌اندازی اولیه یک ترجیح سمت کلاینت است که سرور هرگز آن را نمی‌خواند و به‌صورت گذشته‌نگر روی عامل‌های از قبل ساخته‌شده اعمال نمی‌شود.
عامل‌ها از کجا می‌آیند
بخش با عنوان “عامل‌ها از کجا می‌آیند”- همراه با فضای کاری بذرکاری می‌شوند. هر فضای کاری — نه فقط اولی — یک CEO به‌علاوهٔ چهار متخصص (
qa،architect،engineer،librarian) می‌گیرد که به آن گزارش می‌دهند و هنگام ساخت فضای کاری، خودتوان در پس‌زمینه ساخته می‌شوند. فضاهای کاری و ایزوله‌سازی را ببینید. - دستی افزوده می‌شوند در تنظیمات → فضای کاری → عامل‌ها. درخواست از یک عامل برای استخدام همکار، سطری نمی‌سازد؛ از همان صفحه استفاده کنید.
وضعیت زنده
بخش با عنوان “وضعیت زنده”عامل ستون وضعیت ذخیره‌شده‌ای ندارد. وضعیت زندهٔ آن هر بار که خوانده می‌شود، از جدیدترین گزارش‌های اجرایش استخراج می‌شود:
| وضعیت | معنا |
|---|---|
neverRun |
هیچ گزارش اجرایی وجود ندارد |
running |
دست‌کم یک اجرا هم‌اکنون در جریان است |
failed |
آخرین اجرا خطا داده است، یا زنده‌بودنش ناموفق یا مرده است |
blocked |
زنده‌بودن آخرین اجرا مسدود، متوقف یا در حلقه است |
idle |
هر چیز دیگر — عامل قبلاً اجرا شده و کاری در پرواز ندارد |
دو وضعیت دیگر، queued و succeeded، برای اجراهای تک‌تک در درخت اجرای گفتگو وجود دارند؛ فهرست حضور هرگز آن‌ها را تولید نمی‌کند، چون سبز بودن یک اجرای تمام‌شده واقعیتی دربارهٔ اجراست، نه دربارهٔ عامل.
فهرست حضور تصویری موازی و درشت‌تر را نشان می‌دهد که سمت سرور از رویدادهای زندهٔ اجرا ترکیب می‌شود — در حال فکر کردن، در حال اجرا، مسدود در انتظار تأیید، تمام‌شده — و همین است که عامل‌ها را کنار انسان‌ها ظاهر می‌کند. چندنفره را ببینید.
مفهوم‌های مرتبط
بخش با عنوان “مفهوم‌های مرتبط”- چرخهٔ عمر اعزام عامل: وقتی یک عامل واقعاً اجرا می‌شود چه اتفاقی می‌افتد
- حالت‌ها: تنظیم هر گفتگو که سطح ابزار عامل را شکل می‌دهد
- چندنفره: عامل‌ها به‌عنوان کنشگرهای مستقل، حضور و چرخ تنظیم خودمختاری
- سندباکس و امنیت: امروز چه چیزی یک اجرا را محدود می‌کند
- مرجع پیکربندی عامل: فهرست کامل فیلدها