تصور کنید یک عامل هوش مصنوعی برای تغییر یک ساعت در سند فنی، کل فایل ۱۰۰ صفحه‌ای شما را بازنویسی کند و در این مسیر، نیمی از جزئیات حیاتی را حذف کند. این کابوس رایج در محیط‌های عملیاتی است که Doco برای پایان دادن به آن، یک حلقهٔ عملیاتی سخت‌گیرانه با شش فعل کلیدی معرفی کرده است: مرور (Browse)، جست‌وجو (Search)، خواندن (Read)، پیمایش (Traverse)، ویرایش (Edit) و پایش (Watch). هدف از این ساختار، حذف توهمات (Hallucinations) و تبدیل حدس زدن به تأیید است.
بسیاری از گردش‌کارهای عامل‌محور (Agentic) — شبیه به دستیاری که برای تغییر یک کلمه، کل کتاب را دوباره می‌نویسد — از الگوی خطرناک «دانلود و بازنویسی» استفاده می‌کنند. در این الگو، عامل کل فایل را دانلود کرده، بخش هدف را حدس می‌زند، کل سند را بازنویسی می‌کند و سپس اعلام می‌کند که کار تمام شده است. این رویکرد باعث گسترش «حوزه اثر» (Blast Radius) خطاها می‌شود و مدیریت ویرایش‌های هم‌زمان انسانی و ماشینی را تقریباً غیرممکن می‌کند. این چالش‌ها در واقع ریشه در شکاف میان صحتِ پیاده‌سازی و صحتِ سیستمی در عامل‌های کدنویس دارد که منجر به رفتارهای غیرقابل‌پیش‌بینی در محیط‌های عملیاتی می‌شود. طبق مستندات Doco، جایگزین این روش، یک سیستم جراحی‌گونه است که مدیریت دانش را به مجموعه‌ای از نقاط بازرسی مبتنی بر شواهد تبدیل می‌کند.
زمینه: عامل قابل‌دفاع (The Defensible Agent)
برای درک ضرورت این حلقه، یک مثال عینی و عملی را در نظر بگیرید: «پنجره انتشار محصول را از ساعت ۲۰:۰۰ به ۲۰:۳۰ تغییر بده و تأیید کن که برنامه بازگشت (Rollback) هنوز معتبر است.»
این درخواست یک عملیات ساده‌ی «جست‌وجو و جایگزینی» (Search-and-Replace) نیست. یک عامل قابل‌دفاع نمی‌تواند مکان فایل را حدس بزند. او باید ابتدا محیط درست را بیابد، شواهد را جمع کند، وابستگی‌ها را بفهمد، تغییری بسیار محدود ایجاد کند و در نهایت وضعیت نهایی را تأیید کند. این توالی دقیق، جایگزین الگوی ناامنِ حدس زدن اهداف و بازنویسی کامل فایل‌ها می‌شود.
مرحله جمع‌آوری شواهد
فرآیند با مرور (Browse) آغاز می‌شود. در این مرحله، عامل هویت و محدوده (Scope) خود را تعریف می‌کند. او پایگاه‌های دانش و پوشه‌ها را فهرست می‌کند تا موارد زیر را تعیین کند:
- آیا به محیط‌های محلی (Local)، استیج (Staging) یا تولید (Production) متصل است؟
- آیا توکن دسترسی او فقط خواندنی (Read-only) است یا خواندنی-نوشتنی (Read-write)؟
- شناسه‌های واقعی (Real IDs) پایگاه دانش و سند هدف چیست؟
- جایگاه دقیق سند در سلسله‌مراتب پوشه‌ها کجاست؟
این دقت مانع از آن می‌شود که عامل بر اساس حدس‌های حافظه، در فضای کاری اشتباه بنویسد یا اسناد تکراری ایجاد کند. در واقع، ساختارهای مبهم مخزن اغلب مانع عملکرد صحیح عامل‌ها می‌شوند و باعث می‌شوند عامل‌ها در تشخیص محدوده درست عملیات دچار خطا شوند.
سپس عامل به مرحله جست‌وجو (Search) می‌رود. به‌جای تکیه بر یک نتیجه‌ی مبهم در جست‌وجوی معنایی (Semantic Search) — که مثل پیدا کردن یک موضوع بر اساس «حس کلی» است و نه کلمات دقیق — عامل برای یافتن حقیقت مشخص (مثلاً «پنجره انتشار محصول») درخواست فهرست کامل می‌کند. یک نتیجه‌ی مفید در این مرحله باید شامل موارد زیر باشد: URI سند، شناسه بلوک (Block ID)، مسیر پوشه، مسیر تیترها، بافت (Context) اطراف، نسخه منبع، نسخه ایندکس و میزان کامل بودن پرس‌وجو. اگر سیستم اعلام کند که جست‌وجو کامل نیست (complete=false)، عامل اجازه ندارد نتیجه بگیرد که پاسخ وجود ندارد؛ بلکه باید به خواندن عمیق‌تر روی آورد یا گزارش دهد که پوشش داده‌ها ناقص است.
در مرحله خواندن (Read)، عامل ابتدا طرح کلی (Outline) سند را بررسی کرده و سپس تنها بافت اطراف شواهد را می‌خواند. برای مثال، اگر متنی را یافت که می‌گوید «انتشارها چهارشنبه‌ها ساعت ۲۰:۰۰ است»، بلوک‌های اطراف مربوط به بررسی‌های پیش‌پرواز (Pre-flight checks) و اعلان‌های مهندس آن‌کال (On-call engineer) را می‌خواند. با استفاده از یک نشانگر ادامه (Continuation Cursor)، عامل می‌تواند متن بیشتری را درخواست کند بدون اینکه به‌طور مخفیانه محتواهایی از نسخه‌های مختلف سند را به هم بچسباند، که این امر یکپارچگی منبع را حفظ می‌کند.
تأیید و اجرا
برای پرسش‌های پیچیده، عامل از پیمایش (Traverse) استفاده می‌کند. پاسخ به سؤال «آیا برنامه بازگشت هنوز معتبر است؟» را نمی‌توان تنها از یک جمله به دست آورد. عامل رابطه depends_on را دنبال کرده و به دفترچه راهنمای بازگشت (Rollback Runbook) می‌رود تا بررسی کند:
- آیا این رابطه هنوز معتبر است؟
- آیا شواهد به‌روز هستند؟
- آیا سند هدف هنوز وجود دارد؟
- آیا نسخه منبع با سند فعلی مطابقت دارد؟
پیمایش جایگزین خواندن منبع نیست، بلکه راهی برای یافتن تکه بعدی شواهد است که باید بازرسی شود. شواهد قدیمی یا گسسته (Dangling) به‌جای اینکه به عنوان یک نتیجه قطعی ارائه شوند، به عنوان «عدم قطعیت» گزارش می‌شوند.
در مرحله ویرایش (Edit)، Doco از مکانیزم سخت‌گیرانه «وصله زدن» (Patching) استفاده می‌کند:
- عامل بلوک و نسخه فعلی را می‌خواند و فقط همان بلوک هدف را تغییر می‌دهد (مثلاً تغییر ۲۰:۰۰ به ۲۰:۳۰).
- برای جلوگیری از مشکل «به‌روزرسانی‌های گم‌شده» (Lost Update Problem)، نوشته‌ها دارای هدر
If-Matchهستند (مطابق با RFC 9110 بخش 13.1.1). - اگر ویرایشی هم‌زمان توسط کاربر یا عامل دیگر پس از مرحله خواندن رخ داده باشد، Doco خطای HTTP 409 برمی‌گرداند و عامل را مجبور می‌کند پیش از تصمیم‌گیری مجدد، سند را دوباره بخواند.
در نهایت، مرحله پایش (Watch) تضمین می‌کند که دنیای دانش به‌روز شده است. عامل با استفاده از یک خط مبنای تغییرات ذخیره شده، بررسی می‌کند کدام بلوک‌ها اضافه، حذف، جابه‌جا یا تغییر کرده‌اند. او تأیید می‌کند که مقدار جدید در یک «خوانش معتبر» (Authoritative Read-back) قابل مشاهده است (زیرا دریافت HTTP 200 به تنهایی کافی نیست)، پروژکشن‌های جست‌وجو می‌توانند زمان جدید را بیابند و نسخه‌های ایندکس‌شده با منبع مطابقت داشته باشند. اگر تاریخچه تغییرات فشرده (Compacted) شده باشد، پرچم sync_required=true یک همگام‌سازی کامل را فعال می‌کند.
یکپارچه‌سازی و دسترسی
این عامل‌ها می‌توانند از طریق پروتکل زمینه مدل (MCP)، رابط خط فرمان (CLI) یا APIهای REST با Doco ارتباط برقرار کنند. آن‌ها از اسناد، شناسه‌های بلوک، نسخه‌ها، مجوزها و خطاهای یکسانی استفاده می‌کنند. پروتکل MCP به‌طور خاص باعث می‌شود این ابزارها برای کلاینت‌هایی مانند Claude Code و Cursor قابل شناسایی باشند، در حالی که CLI برای ترمینال‌ها و اسکریپت‌ها و REST به عنوان زیربنای یکپارچه‌سازی عمل می‌کند. با این حال، باید توجه داشت که هرگونه دسترسی API می‌تواند ریسک‌های امنیتی داشته باشد؛ برای مثال، حفره‌های امنیتی در متادیتای ابزارها می‌توانند به عنوان راهی برای نفوذ به استدلال عامل‌های هوشمند مورد استفاده قرار گیرند.
به نقل از تیم توسعه Doco، حتی عامل‌های «فقط خواندنی» نیز می‌توانند اکثر این مراحل — مرور، جست‌وجو، بررسی طرح کلی، دنبال کردن روابط و پایش تغییرات — را طی کنند. این قابلیت به توسعه‌دهندگان اجازه می‌دهد پیش از اعطای مجوز نوشتن، کیفیت پاسخ‌ها را اثبات کنند.
این تغییر پارادایم، تعریف «پایان کار» (Done) را از یک پاسخ موفق API به یک «گزارش جامع شواهد» تغییر می‌دهد. یک پیام تکمیلِ مفید باید شامل موارد زیر باشد:
- URI سند و شناسه بلوک هدف.
- هش‌های نسخه (sha256) قبل و بعد از تغییر.
- تأییدیه اینکه خوانش معتبر (Authoritative Read-back) با موفقیت پاس شده است.
- وضعیت پروژکشن جست‌وجو (به‌روز، complete=true).
- وضعیت شواهد رابطه (معتبر، به‌روز).
- وضعیت تداخل (عدم وجود تداخل).
برای یک توسعه‌دهنده، این به معنای فاصله گرفتن از افسانه «جست‌وجوی معنایی همه‌دان» است. Doco در حال حاضر از جست‌وجوی تمام‌متن ساختاریافته استفاده می‌کند. با پذیرش این واقعیت که پروژکشن‌ها می‌توانند قدیمی شوند و تداخلات 409 رخ دهند، Doco سیستمی می‌سازد که در آن صداقت درباره عدم قطعیت، ارزشمندتر از یک بازنویسی مطمئن اما غلط است.
در آینده، پیاده‌سازی «نشانگرهای گذرا» (Transient Cursors) برای عامل‌های متصل به API در راه است که باعث می‌شود ویرایش‌های در حال انجام در بلوک‌ها، به‌صورت لحظه‌ای برای همکاران انسانی قابل مشاهده باشد.
گام بعدی شما
- اگر از عامل‌های AI برای مدیریت مستندات استفاده می‌کنید، الگوی «بازنویسی کل فایل» را حذف و به مدل «ویرایش بلوکی» کوچ کنید.
- پروتکل MCP را برای اتصال مدل‌های خود به پایگاه‌های دانش ساختاریافته بررسی کنید.
- در خروجی عامل‌های خود، فیلدی برای «ارائه شواهد» (Evidence Report) تعریف کنید تا هر تغییر با یک هش نسخه تأیید شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو