کتاب مدل عملیاتی Claude Code

توضیحات

کتاب مدل عملیاتی Claude Code با رویکردی مهندسی، Claude Code را یک «چارچوب عامل» (Agent Framework) قابل برنامه‌ریزی معرفی می‌کند. هسته‌ی اصلی این دیدگاه، مفهوم «هارنس» (Harness) است؛ لایه‌ای از ابزارها، مدیریت حافظه و کنترل مجوزها که دور مدل زبانی پیچیده شده و آن را به عاملی توانمند برای اجرا در محیط‌های واقعی تبدیل می‌کند.

شاید با Claude Code کار کرده باشید و از توانایی‌اش در تولید کد شگفت‌زده شده باشید. اما آیا تا به حال احساس کرده‌اید که این ابزار قدرتمند، گاهی «حواس‌پرتی» دارد، استانداردهای تیم را فراموش می‌کند یا در پروژه‌های بزرگ گم می‌شود؟

اینجاست که کتاب The Claude Code Operating Model وارد می‌شود. این کتاب با زبانی دقیق و مبتنی بر مثال‌های عملی، نشان می‌دهد که چگونه می‌توان از Claude Code به عنوان یک پلتفرم مهندسی استفاده کرد و آن را از یک دستیار خط‌فرمان به عضوی قابل‌اعتماد در فرآیند توسعه تبدیل نمود.

Claude Code چیست و چه تفاوتی با سایر دستیارها دارد؟

پاسخ به این پرسش، درک مفهوم «هارنس» (Harness) است. کتاب مدل عملیاتی Claude Code با فرمول Agent = Model + Harness این تفاوت را توضیح می‌دهد. مدل زبانی (Model) فقط یک «مغز» است که توانایی تولید متن را دارد، اما هارنس (Harness) همان «بدن» و «ابزار»هایی است که به این مغز قدرت عمل می‌دهد؛ توانایی خواندن فایل، اجرای دستورات و تعامل با دنیای خارج.

فراتر از یک چت‌باکس؛ معماری چهارلایه و نقش هارنس (Harness)

برخلاف چت‌بات‌های ساده، Claude Code دارای یک معماری چهارلایه است که در کتاب به تفصیل تحلیل شده است:

• لایه حافظه (Memory Layer): شامل سیستم CLAUDE.md برای حفظ بافت پروژه.
• لایه توسعه (Extension Layer): شامل مهارت‌ها (Skills)، عامل‌های فرعی (Sub-agents) و هوک‌ها (Hooks).
• لایه یکپارچه‌سازی (Integration Layer): شامل حالت Headless و پروتکل MCP برای اتصال به دنیای خارج.
• لایه برنامه‌نویسی (Programming Layer): شامل Agent SDK برای ساخت برنامه‌های سفارشی.

هارنس، حلقه‌ی عاملی (Agentic Loop) را اجرا می‌کند که در آن مدل به‌طور مداوم «فکر می‌کند → عمل می‌کند → مشاهده می‌کند → تکرار می‌کند» (Think-Act-Observe-Repeat یا TAOR). جالب اینجاست که طراحان Claude Code، خود حلقه‌ی Orchestrator را بسیار ساده و «احمق» طراحی کرده‌اند تا تمام هوش و تصمیم‌گیری به مدل سپرده شود و پایداری معماری افزایش یابد.

چرا هارنس از خود مدل مهم‌تر است؟ (Agent = Model + Harness)

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

هارنس شامل مؤلفه‌هایی مانند سیستم مجوزدهی است که در آن قوانین deny بر allow اولویت دارند و مدل هرگز نمی‌تواند با استدلال، این محدودیت‌های سیستمی را دور بزند. به عبارت دیگر، هارنس مشخص می‌کند که مدل اجازه دارد چه کاری انجام دهد، نه اینکه چه کاری می‌تواند انجام دهد.

مقایسهٔ مکانیزم‌های تحریک؛ دستورات، مهارت‌ها، عامل‌های فرعی و هوک‌ها

یکی از نقاط قوت کتاب، مقایسه‌ی دقیق این چهار مکانیزم است که درک کاربرد هرکدام را ساده می‌کند. این مقایسه در قالب جدولی در فصل اول کتاب ارائه شده است که تفاوت آن‌ها را در پنج بعد کلیدی نشان می‌دهد: نحوه‌ی تحریک (دستی در مقابل خودکار)، نیاز به حافظه، کاربرد معمول و مشابه مهندسی. برای مثال، دستورات (Commands) مانند /review هستند که کاربر آن را تایپ می‌کند.

مهارت‌ها (Skills) بر اساس تشخیص معنایی توسط خود Claude فعال می‌شوند. عامل‌های فرعی (Sub-agents) برای واگذاری وظایف در یک متن ایزوله به‌کار می‌روند و در نهایت هوک‌ها (Hooks) مانند میان‌افزارهای وب، به‌صورت خودکار در رویدادهایی مانند قبل یا بعد از اجرای یک ابزار، فعال می‌شوند.

حافظه و بافت پروژه؛ چگونه Claude Code پروژه را «به‌خاطر می‌سپارد»؟ (طبق سیستم حافظهٔ معرفی‌شده در کتاب مدل عملیاتی Claude Code)

در کتاب مدل عملیاتی Claude Code، این معما با معرفی یک سیستم حافظه‌ی پنج‌لایه حل شده است. هسته‌ی این سیستم، فایل CLAUDE.md است که مانند یک «دفترچه‌ی راهنمای کارمند» در شروع هر جلسه، به‌طور خودکار در بافت مدل قرار می‌گیرد تا از پروژه، تکنولوژی‌ها و استانداردهای آن آگاه شود.

سیستم پنج‌لایهٔ حافظه از خط‌مشی سازمانی تا یادداشت‌های محلی

این پنج لایه، از سراسری به محلی، به ترتیب اولویت عبارت‌اند از:

1. لایهٔ خط‌مشی سازمانی (Enterprise Policy): قوانین امنیتی اجباری که توسط مدیران سازمان اعمال می‌شود.
2. لایهٔ کاربر (User): شامل تنظیمات و ترجیحات شخصی برنامه‌نویس در ~/.claude/CLAUDE.md.
3. لایهٔ پروژه (Project): شامل فایل CLAUDE.md در ریشه‌ی پروژه که با تیم به اشتراک گذاشته می‌شود.
4. لایهٔ دایرکتوری قواعد (Rules Directory): شامل فایل‌های *.md در .claude/rules/ که با استفاده از الگوی Glob به‌صورت شرطی و فقط در زمان نیاز بارگذاری می‌شوند.
5. لایهٔ محلی (Local): شامل CLAUDE.local.md برای یادداشت‌های شخصی که در .gitignore قرار می‌گیرد.

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

اصل «کمتر، بیشتر است» در نگارش CLAUDE.md و بارگذاری شرطی قواعد با .claude/rules

کتاب به‌صراحت توصیه می‌کند که CLAUDE.md را زیر ۲۰۰ خط نگه دارید. هر خط اضافی، هزینه‌ی توکن دارد و می‌تواند باعث کاهش پایبندی مدل به قواعد شود. به‌جای توضیحات اضافی، از دستورالعمل‌های دقیق و عملی استفاده کنید. برای اطلاعات تخصصی‌تر، از بارگذاری شرطی با .claude/rules/ بهره ببرید.

برای مثال، قواعد مربوط به پایگاه‌داده را تنها زمانی که فایل‌های prisma/** یا src/repositories/** ویرایش می‌شوند، فعال کنید. این کار نه تنها هزینه‌ی توکن را کاهش می‌دهد، بلکه با کاهش نویز، دقت مدل را نیز افزایش می‌دهد.

مهارت‌ها (Skills)؛ بسته‌های دانش قابل‌استفادهٔ مجدد

مهارت‌ها (Skills) در کتاب مدل عملیاتی Claude Code به‌عنوان بسته‌های دانشی معرفی می‌شوند که فراتر از قواعد عمومی CLAUDE.md عمل می‌کنند. اگر CLAUDE.md «فرهنگ‌نامه‌ی شرکت» باشد، Skills «راهنمای عملیاتی استاندارد (SOP)» برای نقش‌های خاص هستند که فقط در زمان نیاز فراخوانی می‌شوند.

افشای تدریجی؛ بارگذاری دانش فقط در زمان نیاز (صرفه‌جویی ۵۰–۹۸٪ در توکن)

مکانیزم «افشای تدریجی» (Progressive Disclosure) در قلب طراحی Skills قرار دارد. این مکانیزم از سه سطح تشکیل شده است:

1. سطح اول (همیشه در متن): فقط نام و توضیحات (description) تمام Skills نصب‌شده در بافت مدل قرار می‌گیرد تا بتواند تشخیص دهد کدام یک مناسب است.
2. سطح دوم (پس از فعال‌سازی): بدنه‌ی اصلی فایل SKILL.md بارگذاری می‌شود که شامل دستورالعمل‌های اصلی است.
3. سطح سوم (در حین اجرا): فایل‌های مرجع (reference/)، الگوها (templates/) و اسکریپت‌ها (scripts/) تنها در صورت نیاز و با ارجاع صریح از داخل SKILL.md بارگذاری می‌شوند.

کتاب با یک مثال عینی نشان می‌دهد که یک Skill مالی با ۵۳۰۰ توکن، در ۸۵٪ موارد فقط به ۸۰۰ توکن (حدود ۱۵٪) برای پاسخ‌گویی به درخواست‌های ساده نیاز دارد که منجر به صرفه‌جویی قابل‌توجهی در هزینه می‌شود.

تفاوت مهارت‌های مرجع با مهارت‌های وظیفه‌محور (disable-model-invocation)

کتاب دو فلسفه‌ی طراحی برای Skills تمایز قائل می‌شود:

• مهارت‌های مرجع (Reference Skills): به‌صورت خودکار توسط Claude بر اساس متن فعال می‌شوند. برای مثال، یک Skill درباره‌ی استانداردهای API، وقتی کاربر از Claude می‌خواهد یک مستندات API بنویسد، به‌خودی‌خود بارگذاری می‌شود.
• مهارت‌های وظیفه‌محور (Task Skills): با تنظیم disable-model-invocation: true در فایل SKILL.md، غیرفعال می‌شوند و فقط با دستور مستقیم کاربر مانند /deploy یا /commit اجرا می‌گردند.

دلیل این تفکیک، اصل «کنترل بر اثرات جانبی» است. عملیاتی مانند استقرار (Deploy) یا کامیت (Commit) دارای اثرات جانبی و غیرقابل‌برگشت هستند، بنابراین نباید به تشخیص خودکار مدل سپرده شوند و کاربر باید آن‌ها را به‌صورت دستی فراخوانی کند.

عامل‌های فرعی (Sub-agents) و هنر واگذاری کار

راه‌حل کتاب مدل عملیاتی Claude Code برای این مشکل، استفاده از عامل‌های فرعی (Sub-agents) است. این عامل‌ها، نمونه‌های مستقلی از Claude هستند که در یک متن کاملاً ایزوله اجرا می‌شوند و تنها نتیجه‌ی نهایی خود را به مکالمه‌ی اصلی بازمی‌گردانند.

ایزوله‌سازی متن برای جلوگیری از آلودگی پنجرهٔ زمینه

زمانی که یک عامل فرعی را برای تحلیل لاگ راه‌اندازی می‌کنید، آن ۵۰۰ خط لاگ، هرگز وارد متن مکالمه‌ی اصلی نمی‌شوند. این کار از «آلودگی متن» جلوگیری کرده و به مدل اصلی اجازه می‌دهد تا روی مسئله‌ی اصلی متمرکز بماند. این مفهوم در مهندسی نرم‌افزار با عنوان الگوی Bulkhead یا ایزوله‌سازی خطا شناخته می‌شود که از نشت اطلاعات و اختلال در عملکرد سیستم اصلی جلوگیری می‌کند.

پنج حالت اجرا؛ از فقط‌خواندنی تا خط لوله و همکاری تیمی

کتاب پنج حالت اصلی برای استقرار عامل‌های فرعی معرفی می‌کند که هرکدام معماری خاص خود را دارند:

1. فقط‌خواندنی (Read-Only): برای بازبینی کد و تحلیل امنیت.
2. اجرایی (Execution): برای پردازش داده‌های حجیم مانند اجرای تست و خلاصه‌سازی نتایج.
3. موازی (Parallel): الگویی شبیه به MapReduce که در آن چند عامل فرعی به‌طور هم‌زمان روی بخش‌های مختلف یک مسئله کار می‌کنند.
4. خط لوله (Pipeline): الگویی شبیه به Chain of Responsibility که در آن خروجی هر مرحله، ورودی مرحله‌ی بعدی است (مثلاً: تحلیل خطا → رفع خطا → تست → گزارش).
5. تیمی (Team-based): پیچیده‌ترین حالت برای همکاری طولانی‌مدت چند عامل با یکدیگر (نیازمند فعال‌سازی تجربی).

اقتصاد توکن؛ چرا عامل‌های فرعی هزینه را کاهش می‌دهند (صرفه‌جویی تا ۵۰٪ در سناریوهای طولانی)

برخلاف تصور اولیه، استفاده از عامل‌های فرعی در بسیاری از موارد هزینه را کاهش می‌دهد. کتاب با یک مثال عددی نشان می‌دهد که اگر ۱۰,۰۰۰ توکن خروجی تست، وارد مکالمه‌ی اصلی شود، این توکن‌ها در هر دور بعدی مکالمه، دوباره ارسال می‌شوند و هزینه‌ی زیادی ایجاد می‌کنند. اما اگر این خروجی در یک عامل فرعی ایزوله شود، فقط یک خلاصه‌ی ۱۰۰ توکنی به مکالمه‌ی اصلی برمی‌گردد. در یک سناریوی ۵ دور مکالمه، این روش می‌تواند تا ۵۰٪ در هزینه‌های طولانی‌مدت صرفه‌جویی ایجاد کند و مهم‌تر از آن، از پر شدن پنجره‌ی متن اصلی جلوگیری می‌کند.

هوک‌ها (Hooks)؛ از راهنما تا حفاظ اجباری در لایهٔ اجرا

کتاب مدل عملیاتی Claude Code هوک‌ها را به‌عنوان «مجری‌های قوانین» معرفی می‌کند. برخلاف CLAUDE.md و Skills که در لایه‌ی شناختی عمل می‌کنند و صرفاً راهنما هستند، هوک‌ها در لایه‌ی اجرا قرار دارند و به‌صورت سیستمی، قبل یا بعد از اجرای یک ابزار، فراخوانی می‌شوند و قابلیت متوقف‌کردن یا تغییر رفتار را دارند.

رویدادهای کلیدی؛ PreToolUse، PostToolUse و Stop

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

• PreToolUse: قدرتمندترین رویداد. قبل از اجرای یک ابزار (مثل Bash یا Write) فراخوانی می‌شود و می‌تواند با خروجی deny، اجرا را متوقف یا حتی ورودی آن را تغییر دهد.
• PostToolUse: بعد از اجرای ابزار فراخوانی می‌شود. نمی‌تواند عمل انجام‌شده را برگرداند، اما می‌تواند بازخوردی (مثل نتیجه‌ی Lint) از طریق additionalContext به Claude ارائه دهد.
• Stop: بعد از اتمام یک دور پاسخ‌دهی کامل توسط Claude فراخوانی می‌شود. می‌تواند با تنظیم decision: "block"، از پایان جلسه جلوگیری کرده و Claude را مجبور به بازبینی یا تکمیل کار کند.

پیاده‌سازی سیستم حفاظت امنیتی (مسدودسازی rm -rf / و محافظت از .env)

کتاب با یک مثال عملی، نحوه‌ی ساخت یک سیستم حفاظتی سه‌لایه را با هوک‌ها نشان می‌دهد:

1. هوک PreToolUse روی ابزار Bash: اسکریپتی که دستورات خطرناکی مانند rm -rf / یا curl.*| sh را تشخیص داده و با کد خروج ۲، اجرای آن‌ها را مسدود می‌کند.
2. هوک PreToolUse روی ابزارهای Write و Edit: اسکریپتی که از تغییر فایل‌های حساس مانند .env، secrets.json یا کلیدهای خصوصی (*.pem) جلوگیری می‌کند.
3. هوک PostToolUse روی همه‌ی ابزارها: اسکریپتی که تمام فراخوانی‌های ابزار را برای ممیزی (Audit) در یک فایل لاگ ثبت می‌کند.

هوک Stop برای تضمین کیفیت قبل از پایان جلسه

یک کاربرد حیاتی دیگر، دروازه‌ی کیفیت (Quality Gate) است. با استفاده از هوک Stop، می‌توانید قبل از اینکه Claude جلسه را تمام کند، به‌طور خودکار تست‌ها را اجرا کنید. اگر تست‌ها شکست بخورند، هوک با decision: "block" از پایان جلسه جلوگیری کرده و پیام خطا را به همراه additionalContext به Claude برمی‌گرداند تا آن را اصلاح کند.

در این هوک، استفاده از فیلد stop_hook_active برای جلوگیری از ایجاد حلقه‌ی بی‌نهایت است؛ در غیر این صورت، Claude در یک چرخه‌ی بی‌پایان «رفع خطا → تست → شکست → رفع خطا» گرفتار می‌شود.

MCP و اتصال یکپارچه به پایگاه‌داده و ابزارهای خارجی

پروتکل MCP (Model Context Protocol) در کتاب مدل عملیاتی Claude Code به‌عنوان «راه‌حل استاندارد اتصال» معرفی شده است. هدف آن، پایان دادن به آشفتگی اتصالات N×M میان مدل‌های زبانی و منابع داده‌ی خارجی است.

از N×M تا N+M؛ قدرت استانداردسازی به سبک USB-C

قبل از MCP، برای اتصال هر مدل زبانی به هر منبع داده‌ی جدید، باید یک اداپتور جداگانه نوشته می‌شد. با MCP، هر مدل (مثل Claude) فقط یک‌بار کلاینت MCP را پیاده‌سازی می‌کند و هر منبع داده (مثل Jira، GitHub، پایگاه داده) فقط یک‌بار سرور MCP را می‌سازد. این کار مسئله‌ی N×M را به N+M تبدیل می‌کند و پیچیدگی را به‌شدت کاهش می‌دهد.

ساخت سرور MCP سفارشی با TypeScript یا Python

کتاب با ارائه‌ی مثال‌های کد در تایپ‌اسکریپت و پایتون، نحوه‌ی ساخت یک سرور MCP سفارشی را آموزش می‌دهد. برای مثال، یک سرور ساده برای مدیریت لیست کارها (Todo) با دو ابزار todo_add و todo_list.

در طراحی سرور MCP، نوشتن توضیحات (description) دقیق برای هر ابزار است، زیرا این توضیحات، تنها راهنمای Claude برای تشخیص زمان فراخوانی آن ابزار هستند. همچنین، لاگ‌ها باید به stderr فرستاده شوند تا stdout برای ارتباطات JSON-RPC خالص باقی بماند.

همکاری MCP و مهارت‌ها؛ آشپزخانه و دستورالعمل پخت

کتاب از یک استعاره‌ی زیبا برای تشریح همکاری این دو استفاده می‌کند: MCP آشپزخانه است و Skills دستورالعمل‌های پخت. MCP ابزارها و مواد اولیه (دسترسی به پایگاه داده، APIها) را فراهم می‌کند، اما نحوه‌ی استفاده از این ابزارها برای پخت یک «غذای» مشخص (مثل تحلیل مالی یا تولید مستندات) توسط Skills تعیین می‌شود. به‌بیان دیگر، MCP «چه چیزی» در دسترس است را مشخص می‌کند و Skills تعیین می‌کند «چگونه» از آن استفاده شود.

از حالت بدون سر تا Agent SDK؛ برنامه‌نویسی عامل‌های هوشمند

کتاب مدل عملیاتی Claude Code این دو را به‌عنوان دو سطح از یک تکامل معرفی می‌کند: از پیکربندی در خط‌فرمان تا برنامه‌نویسی با کد. حالت Headless برای اتوماسیون و Agent SDK برای ساخت برنامه‌های سفارشی طراحی شده‌اند.

چهار بُعد پارامترهای Headless؛ خروجی، هزینه، امنیت و کنترل اجرا

حالت Headless با پارامتر -p فعال می‌شود و برای استفاده در محیط‌های بدون نظارت مانند CI/CD طراحی شده است. کتاب کنترل آن را در چهار بُعد خلاصه می‌کند:

1. فرمت خروجی (--output-format): شامل text (خوانا برای انسان)، json (قابل پردازش با متادیتای هزینه و تعداد دورها) و stream-json (برای پایش لحظه‌ای).
2. هزینه (--max-turns و --max-budget-usd): محدودیت‌های حیاتی برای جلوگیری از هزینه‌های سرسام‌آور در اجراهای خودکار.
3. امنیت (--allowedTools): تعیین لیست سفید ابزارها. استفاده از لیست سفید (مثلاً Read,Grep,Glob) بسیار امن‌تر از لیست سیاه است.
4. کنترل اجرا (--model, --append-system-prompt): انتخاب مدل و سفارشی‌سازی پرامپت سیستم.

تابع query و جریان پیام‌های ناهمگام در Agent SDK

Agent SDK (نسخه‌های پایتون و تایپ‌اسکریپت) با تابع query کار می‌کند. این تابع یک مولد ناهمگام (Async Generator) است که پیام‌ها را به‌صورت جریانی بازمی‌گرداند. این یعنی برنامه‌نویس مجبور نیست منتظر پایان کامل کار Claude بماند و می‌تواند خروجی را به‌صورت لحظه‌ای (مثلاً با Server-Sent Events در وب) به کاربر نمایش دهد.

جریان پیام‌ها شامل انواع system/init (شروع جلسه)، assistant (پاسخ Claude با متن و درخواست ابزار)، user (نتیجه‌ی اجرای ابزار) و result (پایان کار با متادیتا) است.

ساخت ابزارهای سفارشی با @tool و چهار لایهٔ امنیتی SDK

یکی از قدرتمندترین ویژگی‌های SDK، تعریف ابزارهای سفارشی با دکوراتور @tool است. این ابزارها درون‌فرایندی (in-process) اجرا می‌شوند و نیازی به راه‌اندازی یک سرور MCP مجزا ندارند. اما نکته‌ی حیاتی، امنیت است. کتاب یک سیستم دفاعی چهارلایه برای SDK معرفی می‌کند:

1. حالت مجوز (permission_mode): تعیین سطح کلی دسترسی (مثل plan برای فقط خواندنی).
2. لیست سفید ابزار (allowed_tools): مشخص کردن ابزارهای مجاز.
3. فراخوانی can_use_tool: یک تابع بازگشتی (Callback) که قبل از هر اجرا، بر اساس ورودی ابزار (مثل مسیر فایل) تصمیم‌گیری می‌کند.
4. هوک‌های PreToolUse: آخرین نقطه‌ی بازرسی برای اعمال قوانین امنیتی دقیق.

کتاب مدل عملیاتی Claude Code به چه چالش‌های پیاده‌سازی در محیط تولید پرداخته است؟

کتاب مدل عملیاتی Claude Code با نگاهی واقع‌بینانه، به چالش‌های عملی پیاده‌سازی در محیط‌های تولیدی پرداخته و راهکارهایی برای مدیریت آن‌ها ارائه می‌دهد.

هزینه‌های پنهان و مدیریت پنجرهٔ زمینه (حداکثر ۱۴۳,۰۰۰ توکن مفید برای کد)

یک باور غلط رایج این است که پنجره‌ی ۲۰۰,۰۰۰ توکنی Claude، تمام فضا را برای کد در اختیار دارد. کتاب با یک محاسبه‌ی ساده نشان می‌دهد که از این مقدار، پس از کسر System Prompt (حدود ۵,۰۰۰)، CLAUDE.md (حدود ۲,۰۰۰)، تاریخچه‌ی مکالمه (حدود ۲۰,۰۰۰) و بافر ایمنی، تنها حدود ۱۴۳,۰۰۰ توکن (معادل ۳۵,۰۰۰ تا ۴۰,۰۰۰ خط کد) برای خود کد باقی می‌ماند.

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

وابستگی به کیفیت دستورالعمل‌ها و مهندسی پرامپت

کتاب به‌صراحت بیان می‌کند که کیفیت خروجی Claude، به شدت به کیفیت ورودی (دستورالعمل‌ها) وابسته است. یک CLAUDE.md مبهم و طولانی، نه تنها هزینه را افزایش می‌دهد، بلکه باعث کاهش دقت می‌شود. اصول کلیدی عبارت‌اند از:

• کمی‌سازی (Quantify): به‌جای «کد را خوب بنویس»، بنویسید «توابع حداکثر ۲۰ خط داشته باشند».
• مثال‌محوری (Example-driven): برای قوانین پیچیده، مثال بزنید.
• تعیین مرزها (Define Boundaries): به‌وضوح مشخص کنید «چه کاری را نباید انجام دهد» (مثلاً console.log ممنوع).
• تأیید گام‌به‌گام: کارهای پیچیده را به چند مرحله‌ی مجزا تقسیم کنید و پس از تأیید هر مرحله، به مرحله‌ی بعد بروید.

ریسک‌های امنیتی MCP و اهمیت اصل حداقل دسترسی

هر سرور MCP، یک پل ارتباطی به دنیای خارج است و همین آن را به یک تهدید امنیتی بالقوه تبدیل می‌کند. کتاب به سه ریسک اصلی اشاره می‌کند:

1. حملات تزریق پرامپت (Prompt Injection): داده‌های مخرب برگشتی از MCP می‌توانند Claude را فریب دهند.
2. سوءاستفاده از ابزار (Tool Abuse): ترکیب مجوزهای به‌ظاهر امن می‌تواند عواقب خطرناکی ایجاد کند.
3. جعل هویت (Impersonation): ابزارهای مخرب می‌توانند با نام ابزارهای معتبر، Claude را فریب دهند.

راه‌کار کلیدی، رعایت اصل حداقل دسترسی (Principle of Least Privilege) و استفاده از سرورهای MCP از منابع معتبر و preferably متن‌باز است. در محیط CI/CD، استفاده از پارامتر --strict-mcp-config برای جلوگیری از بارگذاری پیکربندی‌های محلی و استفاده از قفل کردن نسخه (Version Pinning) برای جلوگیری از به‌روزرسانی خودکار سرورها، بسیار حیاتی است.

از ابزار تا طرز فکر مهندسی

کتاب مدل عملیاتی Claude Code در نهایت، خواننده را به یک تغییر پارادایم دعوت می‌کند: از «استفاده‌کننده از یک ابزار» به «مهندسی که یک پلتفرم را طراحی می‌کند».

جمع‌بندی نه مکانیزم کلیدی در یک نگاه

این کتاب با بررسی دقیق نه مکانیزم کلیدی، نقشه‌ی راهی کامل برای تسلط بر Claude Code ارائه می‌دهد:

1. CLAUDE.md (حافظه و بافت پروژه): ستون فقرات سیستم، برای درک پروژه.
2. مهارت‌ها (Skills): برای بسته‌بندی و استفاده‌ی مجدد از دانش تخصصی.
3. عامل‌های فرعی (Sub-agents): برای ایزوله‌سازی متن و واگذاری کار.
4. دستورات (Commands): برای عملیات‌های دستی و استاندارد.
5. هوک‌ها (Hooks): برای اعمال اجباری قوانین امنیتی و کیفی.
6. MCP: برای اتصال یکپارچه به دنیای خارج.
7. حالت Headless: برای یکپارچه‌سازی با CI/CD.
8. Agent SDK: برای ساخت برنامه‌های سفارشی با کد.
9. افزونه‌ها (Plugins): برای بسته‌بندی و توزیع تمام قابلیت‌های فوق.

نقش مهندس در طراحی مرزهای حلقهٔ عاملی (Agentic Loop)

در پایان، کتاب تأکید می‌کند که وظیفه‌ی مهندس، مداخله در فرآیند فکر کردن مدل نیست، بلکه طراحی مرزهای حلقه‌ی عاملی است. مهندس مشخص می‌کند که مدل چه چیزی را می‌تواند ببیند (ابزارها)، چه چیزی را به خاطر بسپارد (CLAUDE.md و مدیریت متن)، چه کاری را می‌تواند انجام دهد (سیستم مجوزها) و چه زمانی باید متوقف شود (max-turns و هوک‌ها). این همان هنر Harness است: پایدار و قابل‌اعتماد کردن یک سیستم نامعین، با طراحی دقیق ساختار پیرامون آن. همانطور که در مقدمه‌ی کتاب آمده، هدف، تبدیل «بینش فردی» به «استانداردهای نهادی» است. (فصل ۱۰، بخش نقش مهندس در طراحی مرزهای حلقهٔ عاملی)

کتاب مدل عملیاتی Claude Code توسط Jia Huang، محقق هوش مصنوعی، نوشته شده است. مخزن کدهای نمونه کتاب به‌همراه مثال‌های عملی تمام فصل‌ها، به‌صورت عمومی در دسترس است:

مشاهده مخزن کدهای نمونه کتاب در GitHub

کتاب مکمل: Agentic Coding with Claude Code

اگر به دنبال رویکردی کاربردی‌تر و متمرکز بر چالش‌های واقعی مانند آلودگی context، مدیریت MCP در پروژه‌های بزرگ و تشخیص زمان استفاده از Skill در مقابل Subagent هستید، کتاب Agentic Coding with Claude Code نوشتهٔ ایدن مارکو (مهندس LLM در گوگل کلود) را مطالعه کنید. این دو کتاب مکمل یکدیگرند؛ کتاب اول معماری هارنس را بنا می‌کند و کتاب دوم نشان می‌دهد که چگونه در پروژه‌های واقعی از آن استفاده کنید.