شهریور
Opsless و آینده کار
Context Engineering برای ایجنتهای کسبوکار
وقتی یک ایجنت فروش تصمیم اشتباهی میگیرد، اولین واکنش معمول این است که پرامپت را بازنویسی کنیم یا مدل قویتری انتخاب کنیم. اما در بیشتر موارد واقعی، مشکل نه در جملهٔ دستورالعمل است و نه در توان مدل، بلکه در اینکه ایجنت در لحظهٔ تصمیم، اطلاعات درست را نداشته یا اطلاعات نادرست و اضافی او را گمراه کرده. این همان جایی است که Context Engineering وارد میشود: هنر و مهندسیِ تعیین اینکه در هر لحظه چه چیزی باید داخل پنجرهٔ دید ایجنت باشد، نه فقط چه چیزی باید به او گفته شود.
لیست مطالب
تفاوت Context Engineering با Prompt Engineering
Prompt Engineering روی نوشتن یک دستورالعمل ثابت و خوشساخت تمرکز دارد؛ چیزی که یکبار مینویسید و امیدوارید در همهٔ موقعیتها کار کند. Context Engineering فراتر از این میرود: تصمیم میگیرد در هر فراخوانی، از میان انبوه دادههای موجود — تاریخچهٔ مکالمه، رکوردهای CRM، اسناد سیاست شرکت، خروجی ابزارها — کدام بخشها باید وارد پنجرهٔ Context مدل شوند، به چه ترتیبی، و با چه سطحی از خلاصهسازی. یک پرامپت عالی روی Context بد، همچنان تصمیم بد تولید میکند.
اجزای اصلی Context یک ایجنت کسبوکاری
| لایه | محتوا | ریسک اگر غایب یا اشتباه باشد |
|---|---|---|
| دستورالعمل سیستم | نقش ایجنت، مرزهای اختیار، لحن | ایجنت خارج از نقش تعریفشده عمل میکند |
| دانش بازیابیشده (RAG) | سیاستها، قیمتگذاری، سوابق مشابه | پاسخ بر اساس اطلاعات قدیمی یا نادرست |
| Schema ابزارها | تعریف دقیق ورودی/خروجی هر API یا MCP | فراخوانی نادرست ابزار یا پارامتر اشتباه |
| حافظهٔ بلندمدت | ترجیحات مشتری، تاریخچهٔ تعاملات قبلی | تکرار سؤال یا نادیدهگرفتن توافق قبلی |
| تاریخچهٔ مکالمهٔ جاری | پیامهای اخیر همین تعامل | گسست در ادامهٔ منطقی گفتوگو |
مسئلهٔ اصلی: پنجرهٔ Context محدود است
حتی مدلهایی با پنجرهٔ Context بزرگ، محدودیت عملی دارند: هرچه اطلاعات نامرتبط بیشتری وارد Context شود، احتمال اینکه مدل روی جزئیات مهم تمرکز از دست بدهد بالاتر میرود. Context Engineering یعنی بهجای «همهچیز را بریز داخل پرامپت»، یک مکانیزم انتخاب هوشمند بسازید که فقط دادههای مرتبط با همان تصمیم مشخص را بازیابی و تزریق کند. این مکانیزم معمولاً شامل بازیابی معنایی (Retrieval)، فیلتر بر اساس Intent فعلی، و خلاصهسازی تاریخچهٔ طولانی است.
یک الگوی ساده برای سرهمبندی Context
شبهکد زیر نشان میدهد چگونه یک ایجنت فروش پیش از هر فراخوانی مدل، Context را بهصورت لایهای و هدفمند میسازد، بهجای اینکه یک بلوک متن ثابت و بزرگ به آن بدهد.
def build_context(intent, lead_id):
system_layer = load_system_instructions(role="sales_agent")
policy_layer = retrieve_relevant_policies(intent) # فقط بخش مرتبط
tool_schemas = load_tool_schemas(["crm_api", "calendar_mcp"])
memory_layer = load_long_term_memory(lead_id, max_items=5)
recent_turns = summarize_if_long(get_recent_history(lead_id))
context = assemble(
system_layer,
policy_layer,
tool_schemas,
memory_layer,
recent_turns,
token_budget=MAX_CONTEXT_TOKENS
)
return context
context = build_context(intent="qualify_lead", lead_id=lead.id)
response = call_model(context)خطاهای رایج در Context Engineering سازمانی
سه اشتباه بیشتر از بقیه دیده میشود: اول، تزریق کل تاریخچهٔ CRM یک مشتری بهجای فقط بخش مرتبط با تصمیم فعلی؛ این کار Context را پر از نویز میکند. دوم، فراموش کردن schema دقیق ابزارها که باعث میشود ایجنت پارامتر اشتباه به API بفرستد. سوم، نبود مکانیزم خلاصهسازی برای مکالمات طولانی، که باعث میشود یا Context سرریز شود یا بخشهای مهم اولیهٔ گفتوگو حذف شوند. هر سه این خطاها را میتوان با یک لایهٔ میانی بین منبع داده و مدل، پیش از فراخوانی، رفع کرد.
جمعبندی
- Context Engineering مهمتر از نوشتن یک پرامپت بلندتر است؛ کیفیت تصمیم ایجنت به کیفیت اطلاعاتی بستگی دارد که در لحظهٔ تصمیم میبیند.
- هر لایهٔ Context (دستورالعمل، دانش بازیابیشده، schema ابزار، حافظه، تاریخچه) را جدا طراحی و جدا اعتبارسنجی کنید.
- بهجای تزریق کل دادههای موجود، یک مکانیزم بازیابی هدفمند بر اساس Intent فعلی بسازید.
- برای مکالمات طولانی، خلاصهسازی تدریجی را از همان ابتدا در معماری بگنجانید، نه پس از سرریز شدن Context.
- schema دقیق ابزارها را بهعنوان بخشی حیاتی از Context در نظر بگیرید، نه یک جزئیات فنی جانبی.
این مقاله بخشی از دورهٔ Opsless است.
