اگر فکر میکنید با انتخاب یک مدل قدرتمند، نیمی از راه ساخت یک عامل هوشمند را رفتهاید، احتمالاً در تلهٔ رایجترین اشتباه طراحی سیستمهای AI افتادهاید. باید بدانید که شکست در عملکرد یک عامل، بهندرت ناشی از ضعف مدل ریاضی است و معمولاً در لایههای ارکستراسیون ریشه دارد. در واقع، وقتی کسی میگوید «مدل من شکست خورده است»، معمولاً توصیفی از شکست در لایه ارکستراسیون است، نه لایه تابع ریاضی.
دقت در اصطلاحات، تنها راه سریعتر کردن فرآیند اصلاح سیستمهای هوش مصنوعی است. بسیاری از کاربران واژههای «عامل» و «مدل» را بهجای یکدیگر به کار میبرند، اما این ابهام باعث میشود متوجه نشویم منطق واقعی سیستم در کجا قرار دارد. برای ساخت سامانههای قابلاعتماد، باید تفاوت میان مغز، میزبان و دستهای سیستم را درک کنیم.
تصور کنید در حال ساخت یک خانه هستید. معمار نقشههای درخشانی میکشد اما هرگز به آجرها دست نمیزند؛ تیم اجرایی مصالح را جابهجا کرده و کار فیزیکی را انجام میدهد و شرکت پیمانکار، هزینهها و زمانبندی میان این دو را مدیریت میکند. در این مثال، معمار همان مدل، تیم اجرایی لایهٔ هارنس و شرکت پیمانکار سرویس استنتاج است.
بر اساس تحلیل فنی منتشر شده در ۲۴ اوت ۲۰۲۶ در وبسایت code.joejag.com، یک سامانهٔ عاملمحور از سه لایه مجزا تشکیل شده است:
مدل (The Model)
این لایه همان تابع ریاضی هسته است. مدلهایی مثل Sonnet، Opus یا Gemini در واقع مجموعههای عظیمی از اعداد اعشاری هستند که به شکلی خاص به هم متصل شدهاند. آنها توکن (Token) — تکههای کوچکی از متن، مثل برشهای یک کیک طولانی که مدل تکهتکه میخورد — را از ورودی به خروجی تبدیل میکنند، اما هیچ آگاهی ذاتی از دنیای بیرون ندارند. آنها در محدودهٔ وظیفهٔ خود، خالص، محدود و در درک وظایف تخصصی خود درخشان عمل میکنند.
سرویس استنتاج (The Inference Service)
مدلهای پیشرو بهدلیل نیاز شدید به حافظه RAM، برای اجرا روی سیستمهای معمولی بسیار سنگین هستند و اکثر کاربران نمیتوانند آنها را در مقیاس کامل بهصورت محلی اجرا کنند. سرویسهایی مانند AWS Bedrock یا API شرکت Anthropic، مدل را در یک موتور استنتاج (Inference) — لحظهای که مدل واقعاً جواب تولید میکند، شبیه خودِ آشپزی و نه دورهی آموزش آشپز — میزبانی میکنند. این لایه تماسهای API را مدیریت کرده، آنها را به مدل تغذیه میکند و هزینهها را بهصورت لحظهای محاسبه میکند. در سادهترین حالت، این لایه فقط یک تعامل «متن در مقابل متن» است.
هارنس یا لایهٔ سازگارساز (The Harness)
منطق واقعی شما در اینجا جای دارد. هارنس در واقع پوششی است — مانند Claude Desktop، Claude CLI یا اسکریپتهای سفارشی LangChain — که ورودیها را شکل داده و خروجیها را تفسیر میکند. این تنها بخشی از سیستم است که میتواند با دنیای بیرون در تماس باشد و نقشهها را به عمل تبدیل کند. در همین راستا، رویکرد DeepSeek در تبدیل قابلیتهای LLM به پلاگینها نمونهای بارز از آن است که چگونه یک هارنس میتواند مدل را به یک عامل خودمختار تبدیل کند.
همانطور که در تحلیل قبلی ما دربارهی پروتکل MCP اشاره کردیم، ابزارهای ارتباطی در این لایه تعریف میشوند. جزئیات این لایه عبارت است از:
- منطق و ابزارها: قابلیتهایی مثل پروتکل زمینهٔ مدل (MCP) و مهارتها (Skills) در اینجا قرار دارند، نه درون مدل.
- کنترل زمینه: هارنس تصمیم میگیرد چه ابزارها و چه متنی در اختیار مدل قرار گیرد.
- پردازش: مدیریت تجزیه و تحلیل ابزارها (Tool Parsing)، خواندن و نوشتن فایلها (File I/O) و سازماندهی بستر متن در این لایه رخ میدهد.
نمونههای واقعی از این ساختار
ابزارهای دنیای واقعی دقیقاً از این الگو پیروی میکنند. یک مدل واحد میتواند در سیستمهای مختلف رفتار متفاوتی داشته باشد، چون هارنس ورودیها را تغییر میدهد:
- Claude Desktop: از رابط کاربری دسکتاپ، MCP و منطق محلی به عنوان هارنس، سرویس استنتاج Anthropic به عنوان میزبان و مدلهای Sonnet، Opus یا Haiku به عنوان مدل استفاده میکند.
- Claude CLI: از رابط خط فرمان (برای تجزیه ابزارها و I/O فایلها) به عنوان هارنس، سرویس استنتاج Anthropic به عنوان میزبان و مدلهای Sonnet، Opus یا Haiku به عنوان مدل استفاده میکند.
- Cursor: ویرایشگر Cursor (برای سازماندهی زمینه و مسیریابی ابزارها) هارنس است، لایه استنتاج Cursor (با ارائهدهندگان مختلف) میزبان است و مدلهایی مثل Sonnet، GPT یا Gemini نقش مدل را ایفا میکنند.
- ChatGPT: رابط کاربری ChatGPT (مدیریت تاریخچه و ارکستراسیون) هارنس است، سرویس استنتاج OpenAI میزبان است و مدلهای GPT هستهٔ سیستم هستند.
- عاملهای سفارشی LangChain: کدهای خاص شما (قالبهای پرامپت و تعریف ابزارها) هارنس هستند، ارائهدهندهای مثل Bedrock یا OpenAI میزبان است و مدل انتخابی شما هستهٔ ریاضی است.
این تفکیک، شیوهٔ عیبیابی شما را تغییر میدهد. وقتی بتوانید لایهٔ خطا را نام ببرید، میتوانید آن را اصلاح کنید. اگر با این علائم مواجه شدید، لایهٔ احتمالی را شناسایی کنید:
- استدلال ضعیف یا نبود دانش: مدل یا زمینهٔ ارسالی توسط هارنس را بررسی کنید.
- نبود زمینه یا عدم دسترسی به ابزارها: این یک مشکل در لایهٔ هارنس است.
- فراخوانیهای اشتباه ابزار: احتمالاً مشکل از فرمتبندی در هارنس یا ضعف مدل است.
- اجرای نادرست ابزار: یکپارچگی ابزار با هارنس را بررسی کنید.
- کندی در پاسخ: مشکل مربوط به زیرساخت سرویس استنتاج است.
- هزینه بالا: نتیجهٔ انتخاب مدل یا تعرفهٔ سرویس استنتاج است.
برای توسعهدهندگان، بزرگترین ریسک اتکای بیش از حد به منطق فعلی هارنس است. با هوشمندتر شدن مدلها، بسیاری از ویژگیهای پیچیدهٔ امروز در لایهٔ هارنس — مثل پیادهسازیهای خاص مهارتها یا MCP — ممکن است منسوخ شوند. روشی که ما اکنون این پوششها را میسازیم ممکن است با گذشت زمان کارآمد نباشد، زیرا «معمار» (مدل) هر روز توانمندتر میشود تا وظایف «تیم اجرایی» (هارنس) را بر عهده بگیرد.
دقت در نامگذاری لایهها، به معنای وسواس نیست؛ بلکه به معنای کاهش فاصله میان مشاهدهٔ یک خطا و رسیدن به راهکار است.
گام بعدی شما
- در اولین خطای بعدی عامل خود، بهجای تغییر پرامپت، بررسی کنید که آیا مشکل از عدم دسترسی هارنس به ابزار است یا ضعف استدلال مدل.
- اگر از LangChain استفاده میکنید، لایهٔ مدیریت زمینه (Context Management) را از منطق فراخوانی مدل جدا کنید تا عیبیابی سریعتر شود.
- بررسی کنید که آیا مدلهای جدیدتر میتوانند بخشی از منطق هارنس شما را بهصورت داخلی (Native) انجام دهند تا پیچیدگی سیستم کاهش یابد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو