اگر امروز برای مدیریت کدها به عامل‌های هوش مصنوعی تکیه می‌کنید، احتمالاً با هزینه‌های نجومی توکن یا رفتارهای غیرقابل‌پیش‌بینی مدل مواجه شده‌اید. طبق تحلیل فنی منتشر شده در ۱۳ سپتامبر ۲۰۲۶، استفاده از یک مدل احتمالی برای اجرای یک قانون قطعی، سریع‌ترین راه برای از کار انداختن یک عامل هوش مصنوعی است.
در پوشش پیشین ما از ابزارهایی مانند enterprise-claude-kit دیدیم که چگونه لایه‌های حاکمیتی به API اضافه می‌شوند؛ اما اکنون تمرکز از مدیریت سطح بالا به سازمان‌دهی دقیق عامل‌های محیط خط فرمان (CLI) تغییر کرده است. برای اکثر توسعه‌دهندگان، یک عامل (Agent) — شبیه به یک مهندس تازه‌کار است؛ شما می‌توانید یا یک چک‌لیست سخت‌گیرانه به او بدهید که باید دقیقاً دنبال کند (قطعی/Deterministic) یا مجموعه‌ای از دستورالعمل‌ها را ارائه دهید تا بر اساس آن‌ها قضاوت کند (احتمالی/Probabilistic).
حفاظ‌های قطعی: هوک‌ها
هوک‌ها (Hooks) دستورات شل (Shell) هستند که به رویدادهای چرخهٔ حیات در فایل settings.json متصل می‌شوند. این ابزارها بدون توجه به خواستهٔ مدل اجرا می‌شوند و تنها گزینه برای قوانینی هستند که جای هیچ بحثی ندارند. در اینجا مدل حق رأی ندارد؛ این یک سازوکار قطعی است که تصمیم‌گیری را کاملاً از مدل می‌گیرد.
یک نمونه پیکربندی برای هوک به این شکل است:{ "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [{ "type": "command", "command": "prettier --write "$CLAUDE_FILE_PATHS"" }] } ] } }
موارد رایج استفاده عبارتند از:
- فرمت‌دهی کد هنگام نوشتن (مثلاً با استفاده از
prettier --write "$CLAUDE_FILE_PATHS") - مسدود کردن دسترسی به فایل‌های حساس و محرمانه (مانند فایل‌های
.env) - اجرای تست‌ها پیش از آنکه یک جلسه (Session) متوقف شود
به نقل از مستندات Anthropic، چون این دستورات به عنوان دستورات شل خارج از پنجرهٔ زمینه (Context Window) — که مثل میز کاری است و فقط جای چند ورق کاغذ دارد — اجرا می‌شوند، هزینهٔ توکن آن‌ها تقریباً صفر است، مگر اینکه توسعه‌دهنده عمداً خروجی استاندارد (stdout) را دوباره به پرامپت تزریق کند. این ویژگی آن‌ها را به ایده‌آل‌ترین مکان برای الزاماتی نظیر «همیشه linter را اجرا کن» تبدیل می‌کند. شما از کلود نمی‌خواهید یک قانون را به خاطر بسپارد، بلکه حق انتخاب را از او می‌گیرید.
چرخهٔ حیات هوک و ریسک‌های آن
در سال ۲۰۲۶، سطح رویدادهای هوک بسیار گسترده شده است. علاوه بر موارد استاندارد مانند PreToolUse ،PostToolUse ،UserPromptSubmit ،SessionStart ،Stop و Notification ،اکنون سیستم از موارد زیر نیز پشتیبانی می‌کند:
- رویدادهای جلسه:
SessionEnd - رویدادهای عامل:
SubagentStartوSubagentStop - رویدادهای زمینه:
PreCompactوPostCompact
خطر اصلی در کد خروجی (Exit Code) نهفته است. کد خروجی ۰ به معنای موفقیت است. اما کد خروجی ۲ یک خطای مسدودکننده است: در این حالت، خروجی خطا (stderr) به کلود بازگردانده می‌شود و اقدام مورد نظر رد می‌شود. در یک هوک PreToolUse ،این یک ویژگی مثبت است که مانع از دسترسی عامل به فایل‌های ممنوعه می‌شود.
اما در هوک‌های Stop یا SubagentStop ،کد ۲ به معنای این است که «شما اجازه ندارید متوقف شوید، به کار ادامه دهید». این وضعیت می‌تواند بن‌بست (Deadlock) ایجاد کند. برای مثال، هوکی که تغییرات ثبت‌نشده (uncommitted changes) را بررسی می‌کند و در صورت یافتن آن‌ها کد ۲ برمی‌گرداند، عامل را در یک حلقهٔ بی‌نهایت می‌اندازد: عامل سعی می‌کند متوقف شود، توسط هوک مسدود می‌شود و دوباره و دوباره تلاش می‌کند. هر هوکی که قابلیت مسدودسازی دارد، باید مسیر خروجی-۲ آن به طور کامل تست شود.
انتخاب‌های احتمالی: مهارت‌ها
مهارت‌ها (Skills) در فایل‌های SKILL.md به همراه frontmatter تعریف می‌شوند. برخلاف هوک‌ها، مدل بر اساس توصیفی که در ابتدای جلسه می‌خواند، تصمیم می‌گیرد که آیا از یک مهارت استفاده کند یا خیر. کاربران همچنین می‌توانند با استفاده از دستور /name اجرای یک مهارت را اجبار کنند.
برای جلوگیری از تورم زمینه (Context Bloat)، آنتروپیک از سیستم افشای تدریجی در سه سطح استفاده می‌کند:
- همیشه بارگذاری شده: فقط نام و توصیف (چند ده توکن) در شروع جلسه بارگذاری می‌شود. این اجازه می‌دهد یک عامل بدون غرق شدن در توکن‌ها، از صدها مهارت آگاه باشد.
- بارگذاری هنگام فراخوانی: بدنهٔ فایل
SKILL.mdفقط زمانی بارگذاری می‌شود که مهارت صدا زده شود. آنتروپیک توصیه می‌کند این بدنه زیر ۵۰۰ خط باشد. - بارگذاری فقط هنگام ارجاع: اسکریپت‌های باندل شده و فایل‌های جزئیات تنها زمانی بارگذاری می‌شوند که کلود صراحتاً به سراغ آن‌ها برود.
نقطه شکست مهارت‌ها «مسیریابی اشتباه» (Misrouting) است. چون توصیف هر مهارت در هر نوبت در زمینه حضور دارد، توصیفات طولانی یک «مالیات توکن» دائمی بر کل جلسه تحمیل می‌کنند و تصمیم‌گیری برای مسیریابی را برای مدل سخت‌تر می‌کنند. این چالش‌ها در واقع نسخه‌ای از همان مشکلاتی است که در سیستم ZIM برای تبدیل کدهای توهمی به استانداردهای برنامه‌نویسی بررسی کردیم، جایی که ساختارهای ماشین‌خوان برای کاهش خطاهای احتمالی مدل به کار گرفته شدند.
مهارت‌ها برای رویه‌های تکرارشونده‌ای که در آن‌ها کلود باید قضاوت کند مناسب‌اند، مانند:
- یک گردش‌کار ساختاریافته برای بازبینی کد (Code-review)
- روتینی برای پیش‌نویس یادداشت‌های انتشار (Release Notes) از روی git log
- روتین دسته‌بندی و اولویت‌بندی (Triage) برای گزارش‌های خطای ورودی
هنگام نوشتن این مهارت‌ها، توصیف باید به جای یک خلاصه، به عنوان یک «کلید مسیریابی» در نظر گرفته شود تا اطمینان حاصل شود مدل مهارت را تنها در زمان مرتبط بودن فراخوانی می‌کند.
قرنطینهٔ زمینه: عامل‌های فرعی
عامل‌های فرعی (Subagents) عامل‌های تخصصی هستند که به صورت فایل‌های Markdown در مسیر .claude/agents/ با frontmatter تعریف می‌شوند. بدنهٔ فایل تبدیل به پرامپت سیستمی (System Prompt) آن عامل می‌شود. برای مثال، یک عامل codebase-explorer می‌تواند به شکل زیر پیکربندی شود:
`---
name: codebase-explorer
description: Search the codebase for where a symbol is defined and used. Use proactively before refactors.
tools: Read, Glob, Grep
model: sonnet
You locate code. Report file paths and line numbers, not full file dumps.`
ویژگی تعیین‌کننده یک عامل فرعی این است که در یک پنجرهٔ زمینهٔ ایزوله و مجزا اجرا می‌شود. پرامپت سیستمی، فراخوانی ابزارها و تمام خروجی‌های خام (مانند نتایج حجیم grep یا خطوط لاگ) هرگز وارد گفتگوهای اصلی نمی‌شوند. تنها پیام نهایی به عامل والد بازمی‌گردد.
این ایزولاسیون ابزار اصلی برای پاک نگه داشتن پنجرهٔ زمینه در کارهای «پرهیاهو» است؛ مثلاً زمانی که باید تمام فراخوان‌های یک تابع را در ۴۰۰ فایل پیدا کرد. به جای ورود ۴۰۰ فایل نویز به حافظه، عامل والد فقط یک خلاصهٔ تمیز دریافت می‌کند.
محدودیت‌های عامل‌های فرعی
دو ریسک اصلی در مورد عامل‌های فرعی وجود دارد:
- عدم تعامل: عامل‌های فرعی نمی‌توانند در میانهٔ انجام وظیفه متوقف شوند تا از کاربر سؤالات تکمیلی بپرسند. آن‌ها تا پایان اجرا می‌شوند و یک‌بار گزارش می‌دهند. اگر با ابهامی روبرو شوند، مجبور به حدس زدن هستند.
- خلاصه‌های ناقص (Lossy Summaries): جزئیات در پنجرهٔ ایزوله می‌مانند و پس از پایان کار عامل فرعی حذف می‌شوند. ممکن است یک عامل فرعی با اطمینان گزارش دهد که «هیچ موردی یافت نشد» چون پوشهٔ اشتباهی را جست‌وجو کرده است، اما عامل والد هرگز این خطا را نمی‌بیند.
برای کاهش این ریسک، دستورالعمل‌ها باید عامل فرعی را ملزم کنند که «شواهد» (مانند مسیرها و تعداد موارد) را برگرداند، نه فقط نتایج کلی را. علاوه بر این، توسعه‌دهندگان باید توجه کنند که حالت‌های دسترسی (Permission modes) از والد به ارث می‌رسند؛ اگر جلسه اصلی دسترسی‌های آزادتری داشته باشد، لیست ابزارهای مجاز عامل فرعی ممکن است نادیده گرفته شود. لیست ابزارها را به عنوان محدودهٔ کاری (Scoping) در نظر بگیرید، نه به عنوان یک مرز امنیتی.
کنترل برنامه‌نویسی: Agent SDK
Agent SDK (در دسترس برای TypeScript از طریق @anthropic-ai/claude-agent-sdk و برای Python از طریق claude-agent-sdk) اجازه می‌دهد حلقهٔ عامل به جای ترمینال، درون یک فرآیند سفارشی اجرا شود. این ابزار قبلاً Claude Code SDK نامیده می‌شد، زیرا این حلقه بسیار فراتر از کدنویسی کاربرد دارد.
با استفاده از SDK، توسعه‌دهندگان می‌توانند تابع query() را با ClaudeAgentOptions خاص برای تعریف ابزارهای مجاز فراخوانی کنند. یک پیاده‌سازی پایتونی به این شکل است:
from claude_agent_sdk import query, ClaudeAgentOptions async for message in query( prompt="Find and fix the failing test in auth.py", options=ClaudeAgentOptions(allowed_tools=["Read", "Edit", "Bash"]), ): print(message)
اگرچه این SDK همان حلقهٔ عامل، ابزارهای داخلی، هوک‌ها، عامل‌های فرعی و پشتیبانی از MCP را فراهم می‌کند، اما تمام اتوماسیون‌های پیش‌فرض را حذف می‌کند. اکنون توسعه‌دهنده مسئول موارد زیر است:
- مدیریت تلاش مجدد (Retries) و رسیدگی به خطاها
- ایجاد محیط ایزوله (Sandboxing) برای اجرای کدها
- مدیریت تداوم جلسه (Session persistence) و وضعیت (State)
- کنترل هزینه و نظارت بر مصرف توکن‌ها
احراز هویت نیز تغییر می‌کند؛ در حالی که CLI از اشتراک‌های claude.ai استفاده می‌کند، SDK به کلیدهای API نیاز دارد که می‌تواند مستقیماً یا از طریق پلتفرم‌هایی مانند Amazon Bedrock و Google Vertex AI تأمین شود.
انتخاب سازوکار مناسب
انتخاب ابزار درست به میزان نیاز به «قطعیت» بستگی دارد. سلسله‌مراتب تصمیم‌گیری باید چنین باشد:
۱. آیا این کار باید هر بار و بدون استثنا رخ دهد؟ $\rightarrow$ هوک
۲. آیا کلود باید تصمیم بگیرد چه زمانی این کار مرتبط است؟ $\rightarrow$ مهارت
۳. آیا این کار حجم زیادی از داده‌های زائد (Junk) را وارد زمینه می‌کند؟ $\rightarrow$ عامل فرعی
۴. آیا این فرآیند باید بدون حضور من در حلقه اجرا شود؟ $\rightarrow$ Agent SDK
بیشتر شکست‌های پایداری زمانی رخ می‌دهند که توسعه‌دهنده از یک ابزار «احتمالی» (مهارت) برای انجام یک وظیفه «قطعی» (هوک) استفاده می‌کند. اشتباه گرفتن «همیشه» با «زمانی که مرتبط است»، علت اصلی ناپایداری عامل‌ها در محیط‌های عملیاتی است.
برای بهینه‌سازی عملکرد عامل خود، ابتدا فایل settings.json را بررسی کنید تا هر مهارتی (Skill) که در واقع باید اجباری باشد شناسایی و به هوک (Hook) منتقل شود. با حذف حق رأی مدل در جایی که نیازی به آن نیست، پایداری را افزایش و اتلاف توکن را کاهش می‌دهید.
گام بعدی شما
- فایل
settings.jsonخود را بررسی کنید و هر مهارتی (Skill) که در واقع باید اجباری باشد را به هوک (Hook) منتقل کنید. - برای کارهای جست‌وجوی گسترده در کد، حتماً از عامل‌های فرعی استفاده کنید تا پنجرهٔ زمینهٔ اصلی شما با نتایج Grep پر نشود.
- اگر قصد استقرار عامل در محیط سرور را دارید، به جای CLI از Agent SDK استفاده کنید تا کنترل کاملی بر هزینه و محیط اجرا داشته باشید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو