ایجنت هوش مصنوعی چیست
ایجنت هوش مصنوعی یک مدل زبانی است که به جای دادن یک جواب، در یک حلقه از ابزارها استفاده می کند، نتیجه هر قدم را می بیند و قدم بعد را بر اساس همان نتیجه انتخاب می کند. تفاوتش با چت بات در هوش نیست؛ در این است که چت بات جواب می دهد و ایجنت کار انجام می دهد، و کاری که انجام می دهد ممکن است غلط باشد.
- درس ۹ از ۱۵
- میانی
- رایگان، بدون ثبت نام
یک ایجنت از چه چیزی ساخته شده
دو طرف بالا مدل و ابزارها هستند و چیزی که بینشان است حلقه است. گره پایین حافظه کار است: هر دو طرف از آن می خوانند و در آن می نویسند.
مدل، که تصمیم می گیرد
هدف را می خواند و انتخاب می کند قدم بعد چه باشد.
- هیچ چیزی درباره درست بودن تصمیمش تضمین نمی دهد
- هر قدم کل گفتگو را دوباره می خواند
ابزارها، که عمل می کنند
جستجو، خواندن فایل، صدا زدن یک API، نوشتن در پایگاه داده.
- نتیجه واقعی برمی گردد، نه حدس مدل
- هر ابزاری که بدهید، اجازه ای است که داده اید
هر دو از حافظه کار می خوانند و در آن می نویسند
حافظه کار
هدف، قدم های برداشته شده و نتیجه هر ابزار، همه در یک متن.
- قدمی که غلط بود همین جا می ماند و قدم بعد رویش ساخته می شود
در این شکل هیچ جایی برای تایید آدم دیده نمی شود، و همین درست است: تایید انسانی جزو ساختار ایجنت نیست و باید عمدا اضافه شود.
آخرین بررسی: فکت ها و نام ابزارهای این درس در همین تاریخ با منابعشان بازبینی شده اند.
فرق ایجنت با چت بات در یک جمله
چت بات یک نوبت دارد: شما می پرسید، مدل جواب می دهد، تمام. ایجنت نوبت ندارد؛ حلقه دارد. به آن یک هدف می دهید، خودش تصمیم می گیرد کدام ابزار را صدا بزند، نتیجه آن ابزار را می بیند، و بر اساس همان نتیجه تصمیم بعدی را می گیرد، تا وقتی که کار تمام شود یا به شرط توقفی بخورد که شما گذاشته اید.
انتروپیک در نوشته مهندسی خودش این را با یک تفکیک معماری صریح می گوید که از هر تعریف دیگری کاربردی تر است: در یک گردش کار، مدل و ابزارها از مسیر کدی می گذرند که شما از پیش نوشته اید. در یک ایجنت، مدل خودش مسیر و استفاده از ابزارها را هدایت می کند. همان جا جمله ای هست که کل صنعت را ساده می کند: ایجنت ها معمولا فقط مدل هایی هستند که در یک حلقه، بر اساس بازخورد محیط، از ابزار استفاده می کنند.
وقتی این را فهمیدید، سوال «آیا این محصول واقعا ایجنت است یا اسمش را ایجنت گذاشته اند» جواب دارد. اگر مسیر از قبل معلوم است و همیشه همان سه قدم اجرا می شود، گردش کار است، هر چقدر هم که تبلیغش بگوید ایجنت. و این توهین نیست: گردش کار برای کاری که شکلش ثابت است انتخاب بهتری است، چون قابل پیش بینی است.
حلقه ای که کل ماجراست
حلقه چهار قدم دارد و همیشه همین چهار قدم است، چه محصول تجاری باشد و چه صد خط کد خودتان. مدل هدف را می خواند و تصمیم می گیرد چه کاری لازم است. ابزار را صدا می زند. نتیجه واقعی آن ابزار برمی گردد و همین است که ایجنت را از یک متن تولید کننده جدا می کند: مدل دیگر حدس نمی زند که فایل وجود دارد یا نه، خطای واقعی سیستم فایل را می بیند. بعد با آن نتیجه دوباره تصمیم می گیرد.
دو چیز از همین شکل بیرون می آید که در تبلیغ ها گفته نمی شود. اول اینکه حلقه باید شرط توقف داشته باشد، وگرنه یک اشتباه کوچک تبدیل به بیست تلاش پشت سر هم می شود. انتروپیک هم توصیه می کند سقف تعداد تکرار گذاشته شود تا کنترل حفظ شود. دوم اینکه هزینه ایجنت با تعداد قدم ها بالا می رود، نه با تعداد سوال ها. یک کار که به دوازده بار صدا زدن ابزار احتیاج دارد، دوازده بار کل گفتگو را دوباره می خواند.
و مهم ترین نکته این است: خطاها جمع می شوند. انتروپیک این را با همین عبارت می گوید، خطای انباشته. اگر هر قدم نود درصد درست باشد، کاری با ده قدم دیگر نود درصد درست نیست. برای همین ایجنت خوب ایجنتی نیست که قدم های بیشتری بردارد؛ ایجنتی است که قدم های کمتری بردارد و بعد از هر قدم واقعیت را ببیند.
چهار قدم حلقه، و جایی که باید بایستد
قدم سوم است که ایجنت را از یک متن ساز جدا می کند: نتیجه واقعی ابزار برمی گردد و مدل دیگر حدس نمی زند. قدم چهارم جایی است که هزینه بالا می رود، چون هر دور کل متن قبلی را دوباره می خواند.
- ۱ هدف را می خواند
- ۲ ابزار را انتخاب می کند
- ۳ نتیجه واقعی را می بیند
- ۴ دوباره تصمیم می گیرد
این چرخه به خودی خود پایان ندارد. شرط توقف چیزی است که شما اضافه می کنید، و اگر اضافه نشود یک اشتباه کوچک به تکرارهای پشت سر هم تبدیل می شود.
امروز چه چیزی واقعا کار می کند و چه چیزی دمو است
یک الگو در کارهایی که واقعا جواب داده اند دیده می شود: ایجنت جایی خوب کار می کند که محیط بتواند به او بگوید اشتباه کرده. کد نوشتن بهترین نمونه است، چون کد یا کامپایل می شود یا نمی شود و تست یا سبز است یا قرمز. انتروپیک هم در همان نوشته دو حوزه ای را نام می برد که مشتری هایش بیشترین ارزش را در آنها دیده اند: پشتیبانی مشتری و کدنویسی. هر دو یک ویژگی مشترک دارند و آن ویژگی معیار موفقیت روشن است.
چیزی که دمو است، همان کاری است که محیط درباره اش هیچ سیگنالی نمی دهد. ایجنتی که «استراتژی محتوا می نویسد» هیچ وقت خطا نمی گیرد، چون هیچ چیزی در دنیا به او نمی گوید این استراتژی غلط بود. خروجی اش همیشه روان و همیشه قابل قبول به نظر می رسد و شما ماه ها بعد می فهمید که کار نکرده. برای این نوع کار ایجنت لازم ندارید؛ یک آدم لازم دارید که تصمیم بگیرد و یک مدل که سرعتش را بالا ببرد.
موضع ما، که با توصیه خود انتروپیک هم می خواند: قبل از ساختن ایجنت، یک بار جدی از خودتان بپرسید که آیا اصلا لازم است. همان صفحه صریح می گوید ساده ترین راه حل ممکن را پیدا کنید و پیچیدگی را فقط وقتی اضافه کنید که لازم شد، و اضافه می کند که این ممکن است یعنی اصلا ایجنتی نسازید. برای بسیاری از کارها، یک پرامپت خوب با چند مثال کافی است.
گردش کار یا ایجنت؛ هیچ کدام جواب درست همیشگی نیست
گردش کار
- مسیر را شما از قبل در کد نوشته اید
- قابل پیش بینی و قابل تست
- وقتی خراب می شود، سر و صدا می کند
- برای کاری که شکلش ثابت است
ایجنت
- مدل خودش مسیر و ابزارش را هدایت می کند
- برای وقتی که تعداد قدم ها را نمی شود از قبل دانست
- هزینه و تاخیر بیشتر، و خطای انباشته
- وقتی خراب می شود، معمولا ساکت است
این تفکیک از نوشته مهندسی انتروپیک است. انتخاب بین این دو به شکل کار بستگی دارد و نه به اینکه کدام مدرن تر است.
برای یک کسب و کار کوچک، دو جای واقعی
جای اول تحقیق است. به ایجنت می گویید درباره یک موضوع مشخص بگرد، منابع را باز کن، و یک خلاصه با لینک هر ادعا بده. اینجا اگر اشتباه کند، اشتباهش ارزان است و دیده می شود: لینک را باز می کنید و نیست. برای همین این ساده ترین جایی است که یک تیم کوچک می تواند شروع کند، و در عمل هم بیشترین وقت را برمی گرداند چون بخش خسته کننده کار جمع کردن است و نه تصمیم گرفتن.
جای دوم دسته بندی و مسیردهی پیام های ورودی است. ایمیل یا تیکت یا پیام فرم تماس می آید، مدل تشخیص می دهد که موضوعش چیست و فوریتش چقدر است، به آدم درست می سپاردش و یک پیش نویس جواب هم کنارش می گذارد. تا اینجا خوب است. جمله بعدی همان جایی است که همه چیز تصمیم می شود: پیش نویس را ایجنت نمی فرستد. آدم می فرستد.
این یک احتیاط کلی نیست، یک قاعده است و مرزش هم مشخص: هر جا خروجی ایجنت به بیرون سازمان می رود، یا پول جابه جا می کند، یا چیزی را حذف می کند، آدم باید بین ایجنت و نتیجه بایستد. انتروپیک هم همین را با زبان مهندسی می گوید: تست گسترده در محیط ایزوله و حفاظ های مناسب. و دلیلش همان خطای انباشته بخش قبل است: قدمی که غلط بود در گفتگو می ماند و قدم بعدی روی آن ساخته می شود.
قبل از اینکه ایجنت بسازید، کارت توقفش را بنویسید
پنج چیز است که اگر روی کاغذ نیامده باشد، ایجنت شما یک آزمایش است و نه یک ابزار. هدف، در یک جمله و با یک معیار که بشود گفت انجام شد یا نشد. فهرست ابزارهایی که اجازه دارد صدا بزند، و همان قدر مهم، فهرست کارهایی که هرگز نباید بکند. شرط توقف، یعنی سقف تعداد قدم و سقف هزینه. جایی که آدم باید تایید کند. و آخری که همیشه فراموش می شود: اینکه اگر ایجنت شکست خورد، چه کسی می فهمد.
آن قلم آخر مهم تر از بقیه است چون شکست ایجنت معمولا بی صدا است. یک اسکریپت که خطا می دهد لاگ می نویسد؛ ایجنتی که در قدم سوم بد فهمیده تا آخر با اطمینان ادامه می دهد و یک خروجی مرتب تحویل می دهد. برای همین، بخشی از ساختن ایجنت این است که آن را وادار کنید بگوید بر اساس چه چیزی تصمیم گرفته. انتروپیک سه اصل می نویسد و اصل دوم دقیقا همین است: شفافیت، یعنی گام های برنامه ریزی ایجنت را صریح نشان بدهید. اصل اول سادگی است و اصل سوم طراحی دقیق رابط بین ایجنت و ابزارها.
و یک مرز واقعی که کمتر گفته می شود: اگر همین پنج قلم را نوشتید و دیدید هدف با سه قدم ثابت انجام می شود، شما به ایجنت نرسیده اید، به یک گردش کار رسیده اید. آن را بسازید و خوشحال باشید. ارزان تر است، سریع تر است و وقتی خراب می شود، سر و صدا می کند.
مسیر سریع با هوش مصنوعی
بیشتر پروژه های ایجنت جایی شکست نمی خورند که کد بد نوشته شده باشد؛ جایی شکست می خورند که هیچ وقت روی کاغذ نیامده اند که این ایجنت دقیقا چه کاری را تمام شده حساب می کند. راه سریع این است که پیش از هر خط کد، مدل را وادار کنید همان کارت توقف بخش بالا را بنویسد، و مهم تر، وادارش کنید ساده ترین نسخه ممکن را هم پیشنهاد بدهد. برای این کار یک مدل قوی بردارید و نه یک مدل ارزان، چون کار قضاوت است.
- کاری را که می خواهید خودکار شود، همان طور که امروز دستی انجام می شود، در چند خط بنویسید. بدون کلمه ایجنت و بدون اسم هیچ ابزاری.
- دستور زیر را اجرا کنید. حتما بخواهید نسخه بدون ایجنت را هم بنویسد؛ همین یک بند است که این دستور را از یک تولیدکننده ایده جدا می کند.
- دو نسخه را کنار هم بگذارید و اگر فاصله شان کم بود، نسخه ساده را بسازید. این تصمیم را همان روز اول بگیرید، نه بعد از دو هفته کد زدن.
- قبل از اجرا، ستون «چه کسی می فهمد» را خودتان پر کنید. اگر جوابش هیچ کس است، هنوز آماده نیستید.
نسخه آماده کپی
کاری که پایین توضیح داده ام امروز دستی انجام می شود و می خواهم خودکارش کنم. تو قرار نیست ذوق زده شوی؛ قرار است سخت گیر باشی.
کار: {همان چند خطی که نوشتید}
چیزی که نباید اتفاق بیفتد: {مثلا هیچ ایمیلی بدون تایید من نرود}
اول یک جدول با این ستون ها بده، یک ردیف برای هر قدم:
قدم | این قدم قانون ثابت است یا قضاوت | اگر خراب شود چه شکلی خراب می شود | چه کسی می فهمد
بعد دو طرح بنویس:
طرح الف، ساده ترین چیزی که این کار را انجام می دهد، حتی اگر هیچ ایجنتی در آن نباشد.
طرح ب، نسخه ایجنت، با: هدف در یک جمله، فهرست ابزارهای مجاز، فهرست کارهای ممنوع، سقف تعداد قدم، و نقطه ای که آدم تایید می کند.
در آخر در سه خط بگو طرح ب چه چیزی بیشتر از طرح الف می دهد. اگر جواب واقعی این است که چیزی بیشتر نمی دهد، همین را بنویس و اصرار نکن.قبل از اعتماد به خروجی: خروجی این دستور یک طرح است و نه یک تصمیم. دو چیز را حتما خودتان بررسی کنید: ستون «اگر خراب شود چه شکلی خراب می شود» را، چون مدل تمایل دارد خرابی های واضح را بنویسد و خرابی های ساکت را جا بیندازد؛ و فهرست ابزارهای مجاز را، چون هر ابزاری که در آن فهرست بماند یک دسترسی واقعی است که به یک برنامه غیرقطعی داده اید. و اگر مدل برای طرح الف استدلال ضعیفی نوشت، احتمالا نه به این دلیل که طرح الف ضعیف است.
هوش مصنوعی در این کار
برای فهمیدن ایجنت، بهترین کار این است که یکی را در جایی که خطایش ارزان است خودتان اجرا کنید و به جای خروجی، به قدم هایش نگاه کنید. سه سوالی که در همان اجرا جواب های آموزنده می دهند: چند بار ابزار صدا زدی، کدام قدم را بر اساس یک حدس برداشتی، و اگر همین الان متوقفت کنم چه چیزی نصفه می ماند. موضع ما این است که ابزار عاملی که قدم هایش را نشان نمی دهد، برای کار جدی مناسب نیست؛ نه به این دلیل که بدتر است، بلکه به این دلیل که وقتی اشتباه کند نمی توانید بفهمید کجا.
ابزارهایی که واقعا کمک می کنند
- Claude Code نمونه ای از همان حوزه ای که ایجنت ها در آن واقعا کار می کنند، چون محیط برنامه نویسی مدام می گوید چه چیزی شکست خورده. قدم هایش را نشان می دهد و همین برای یاد گرفتن این درس مهم تر از خروجی اش است. ایران در فهرست کشورهای پشتیبانی شده انتروپیک نیست.
- ChatGPT برای اجرای یک ایجنت تحقیق ساده و دیدن اینکه چه منابعی را واقعا باز کرده مناسب است. قاعده همان است: هر لینکی که داد باز کنید؛ اگر لینکی نداد، جستجویی در کار نبوده. درباره دسترسی از ایران ادعایی نمی کنیم چون صفحه کشورهای پشتیبانی شده اوپن ای آی به این سرور خطای دسترسی می دهد.
- Gemini فارسی را خوب می فهمد و برای امتحان کردن دسته بندی و مسیردهی پیام های فارسی گزینه معقولی است. صفحه خود گوگل می گوید اپ وب جمنای در بیش از دویست و سی کشور و منطقه کار می کند و ایران در آن فهرست نیست.
کجا نتیجه معکوس می دهد
خطر مشخص ایجنت این است که هم توانایی و هم خطا را با هم بزرگ می کند. یک چت بات که اشتباه می کند یک پاراگراف غلط به شما می دهد و شما می خوانیدش؛ یک ایجنت که اشتباه می کند همان اشتباه را در پنج قدم بعدی به کار می برد و انتروپیک این را در نوشته خودش خطای انباشته می نامد و توصیه می کند تست در محیط ایزوله و حفاظ گذاشته شود. خطر دوم ابزارهاست: هر ابزاری که به ایجنت می دهید یک دسترسی واقعی است که به برنامه ای غیرقطعی داده اید، و اگر آن ابزار بتواند ایمیل بفرستد یا رکورد حذف کند، اشتباه مدل دیگر روی کاغذ نمی ماند. خطر سوم مربوط به داده است: ایجنتی که فایل ها یا صندوق ایمیل شما را می خواند، محتوای آنها را به سرویس مدل می فرستد، و اینکه آن محتوا برای آموزش استفاده می شود یا نه به نوع حساب و تنظیمات بستگی دارد؛ انتروپیک این را در صفحه حریم خصوصی اش نوشته. قاعده ما ساده است: هر جا خروجی از سازمان بیرون می رود یا پول یا داده را تغییر می دهد، آدم تایید می کند. برای وضعیت دسترسی و پرداخت این ابزارها از ایران، راهنمای خرید را ببینید.
منبع ها: Anthropic: building effective AI agents Anthropic: is my data used for model training Anthropic: supported countries Google: where the Gemini web app is available
حد این توصیه
این درس شکل ایجنت را توضیح می دهد و راهنمای ساخت نیست. لایه ابزار و کتابخانه ها هر چند ماه عوض می شوند و اسم بردن از یکی از آنها یعنی صفحه ای که سال بعد غلط است، پس اینجا فقط اصولی نوشته شده که با عوض شدن ابزار عوض نمی شوند. دوم اینکه ما هیچ عددی درباره نرخ موفقیت ایجنت ها نمی نویسیم چون منبعی نداریم که بشود به آن اعتماد کرد؛ آنچه از انتروپیک نقل شده توصیه مهندسی است و نه اندازه گیری. و سوم، خود ما روی این سایت هیچ ایجنت بدون ناظری نداریم که اجازه نوشتن داشته باشد، پس درباره تجربه اجرای ایجنت خودکار در محیط تولید ادعایی نمی کنیم.
از تجربه خود ما
همین بخش آموزش، درسش را از یک خرابی واقعی گرفت. فایل های داده این بخش را جلسه های خودکار روی سایت زنده می نویسند و یک فایل صد کیلوبایتی اتمی نوشته نمی شود؛ در همان چند ثانیه، include روی نسخه نیمه نوشته یک ParseError می دهد. و چون تابع خواننده این فایل ها از صفحه wp-admin تا هر مسیر /learn/ صدا زده می شود، همان چند ثانیه به «خطای بحرانی» کل سایت تبدیل می شد. جوابش در rgbl_read_data_file() در includes/registry.php نشسته: خواندن داخل try است، فایل خراب رد می شود و در گزارش validate می آید، و همان جا DONOTCACHEPAGE تعریف می شود تا صفحه ای که یک درس در آن غایب بوده هرگز در کش نماند. جالب اینکه php -l روی این سرور غیرفعال است، پس چاره ای جز گرفتن همان ParseError نبود. این دقیقا همان حفاظی است که این درس درباره اش حرف می زند، فقط به زبان کد: نویسنده خودکار را متوقف نکردیم، مرزی گذاشتیم که خطایش از آن بیرون نزند.
سوال هایی که واقعا پرسیده می شوند
ایجنت با چت بات چه فرقی دارد
چت بات یک جواب می دهد و تمام می شود؛ ایجنت در یک حلقه از ابزار استفاده می کند و نتیجه هر قدم را می بیند. فرقشان در باهوش تر بودن نیست، در این است که یکی حرف می زند و دیگری کار انجام می دهد.
برای کسب و کار کوچک ایجنت به درد می خورد
در دو جا بله: تحقیق و جمع آوری اطلاعات، و دسته بندی و مسیردهی پیام های ورودی با پیش نویس جواب. در هر دو، تایید نهایی با آدم می ماند. برای کارهایی که معیار موفقیت روشنی ندارند، ایجنت وقت شما را نمی خرد.
ایجنت را می شود بدون ناظر رها کرد
جایی که خطایش قابل برگشت است و کسی از بیرون آن را نمی بیند، بله. جایی که پول جابه جا می شود، داده مشتری تغییر می کند، یا چیزی به بیرون سازمان فرستاده می شود، نه. دلیلش ترسو بودن نیست؛ دلیلش این است که خطای ایجنت معمولا ساکت است و روی قدم های بعدی سوار می شود.