7 Context Engineering Rules for Production AI Agents (Anthropic + LangGraph)
Dr. Maryam Miradi · 2025-11-22 · 14м 53с · 3 151 просмотров · YouTube ↗
Топики: ai-loop-engineering
🎧 Аудио
📝 Summary
model=deepseek-v4-flash · prompt=summary-v7 · 4 650→2 131 tokens · 2026-07-20 11:59:22
🎯 Главная суть
Контекстное окно LLM-агентов деградирует далеко до своего номинального лимита — уже при 200k из 1M токенов начинаются ошибки, потеря инструкций и замедление. Чтобы агенты работали стабильно в production, нужно применять семь методов контекстной инженерии: мониторинг порога ротации, выгрузку контекста, иерархию инструментов, компоновку, суммаризацию, суб-агентов как временные инструменты, контекстный карантин для multi-agent и RAG для выбора инструментов. Итоговые восемь законов сводятся к простому принципу: «чем проще система, тем надёжнее».
Проблема деградации контекста: метод pre-rot threshold
Контекстное окно в 1 млн токенов не означает, что агент может качественно использовать весь объём. Исследования показывают: до 128k токенов — безопасная зона, с 200k начинается ухудшение, а к 500k производительность падает критически. Симптомы: повторения, медленные ответы, вызов несуществующих функций, потеря инструкций и забывание того, что только что сказал пользователь. Решение — непрерывно мониторить размер контекста и при достижении порога 128k–200k запускать редукцию. При этом простая суммаризация неоптимальна — нужны специализированные методы.
Выгрузка контекста (context offloading) и иерархия инструментов
Аналогия с компьютером (Андрей Карпати): контекст работает как CPU RAM, а долговременное хранилище — как диск. Всё тяжёлое (логи, HTML, PDF, большие JSON) должно находиться вне контекста — сохраняется только идентификатор файла и краткое структурированное резюме. Уровень 1: scratchpad (краткосрочная память) — агент пишет в него ключевые находки, не храня сырые результаты поиска; реализуется как простой message state в LangGraph. Уровень 2: долговременная память (Postgres с векторным поиском). Второй аспект — «парадокс инструментов»: чем больше инструментов, тем больше контекст и выше путаница. Решение — трёхуровневая архитектура:
- Core-инструменты (read file, write file, search, browser) — всегда доступны.
- Pre-installed инструменты (видеоконвертер, распознавание речи, MCP) — устанавливаются, но не входят в постоянный список.
- Power-слой — агент пишет код для любых нестандартных задач, вызывая API и библиотеки.
Таким образом агент видит только ограниченный набор инструментов, но может получить доступ к любым через код.
Компактизация и суммаризация: когда и как
Даже при умном дизайне инструментов их выходы накапливают тысячи токенов (один веб-поиск — ~3000 токенов). Метод compaction — обратимое сжатие: из результатов удаляется восстанавливаемая информация, но сохраняются идентификаторы (путь файла, URL запроса, ID API). Это позволяет восстановить полные данные при необходимости. Суммаризация, наоборот, необратима — теряет детали. Золотое правило: суммаризацию всегда делать с полной (не скомпактированной) версии, используя структурированную схему, а не свободный промпт. Практический совет: последние несколько результатов инструментов оставлять в нескомпактированном виде, чтобы модель сохраняла стиль ответа.
Суб-агенты как временные инструменты
Если агенту нужно 50+ вызовов инструментов подряд, контекст всё равно раздувается. Решение — запускать Helper Agent для каждой сложной подзадачи: создаётся свежий пустой контекст, выполняются все вызовы, возвращается краткое резюме (~500 токенов), и Helper Agent целиком выбрасывается. При этом не теряется координация, если принять правило:
- 5–20 вызовов — используй основного агента.
- 20–50 — суб-агент.
- Более 50 — выгрузка контекста (context offloading), так как даже суб-агент будет перегружен.
Однако злоупотреблять суб-агентами нельзя: изолированные подзадачи теряют когерентность — финальное объединение результатов часто ненадёжно.
Multi-agent и контекстный карантин (context quarantine)
Если задача требует согласованного решения, простой multi-agent с разделением труда работает плохо: каждый агент видит только свою часть, итоговое объединение не гарантирует целостности. Рабочая схема — supervisor-агент: он даёт подзадачи двум суб-агентам, они возвращают результаты, supervisor сам синтезирует ответ. Такой «контекстный карантин» изолирует контексты суб-агентов, но сохраняет единое принятие решений. Когда использовать:
- Multi-agent (несколько параллельных агентов) — для сбора информации.
- Supervisor-система — когда требуется согласованность.
RAG для выбора инструментов
Даже с трёхуровневой архитектурой, если в слое pre-installed много похожих инструментов, агент путается. Решение — предварительно векторизовать описания всех инструментов (создать registry: tool_id, description, embedding) и хранить их в векторной БД. По запросу пользователя агент через similarity search находит топ-5 релевантных инструментов и предъявляет агенту только их. Например, для запроса «погода в Токио» будут выбраны get_weather, get_temperature, humidity, alerts. Это резко снижает когнитивную нагрузку на агента. Метод эффективен для большого количества схожих инструментов; при малом наборе не нужен.
Восемь законов контекстной инженерии
Все методы собраны в 8 правил, которые стоит использовать как чек-лист:
- Выгружай всё, что тяжело по токенам.
- Сначала компактизация, потом суммаризация (и то от полной версии).
- Ставь порог срабатывания на 128k токенов.
- Разделяй задачи по типу, а не по должности.
- Трёхуровневый дизайн инструментов (core, pre-installed, code).
- Структура побеждает свободный формат.
- Простые системы всегда выигрывают.
- Мониторинг контекста — непрерывно.
Единый объединяющий принцип: контекстная инженерия должна делать работу агента проще, а не сложнее.
📜 Transcript
en · 2 360 слов · 36 сегментов · clean
Показать текст транскрипта
This video is on 7 advanced context engineering methods for AI agents. I spent 40 plus hours studying the best in the industry and extracted 7 methods that are intuitive and simple but advanced and suitable for AI agents in production. Also, we'll tie everything together with 8 method laws and we'll give you actually Python code in Langer. You can find all of the references in the description. I'm Maryam, PhD with 20 plus years in AI teaching AI agents 2000 in 90 plus countries. Let's go to method 1, pre-road threshold. To explain the route, we can ask ourselves, what will you engineer context in the first place? We know that agents need useful context to create design output. The context window is now very large, like 1 million tokens. But after using only 10% of it, basically, agents start to become poisoned, distracted, confused, or clashed. So context capacity is not the same as context quality. So how about that 10%? is going to explain that 10% to us. It says that mother fails not cleanly at their limits, but it degrades progressively. It means that at 128k, they are in the safe zone. At 200k, they have quality degradation. At 500k, severe performance drops. And 1 million k is technically the drop or the limit. So what are the symptoms? Are that... repetition you start to get a slower response you get some wrong tools they call like invalid functions they lost the instruction they forget what you have just said and what you can do is to avoid actually that trot what are the solution to that is it's basically very simple you monitor your context window and the context size continuously as soon as you hit that 120 8k to 200k you trigger reduction Okay, you can say reduction should I summarize it? It's not just the same I will explain that in just a few minutes, but let's first identify another problem Imagine you just detect the rotzone at 200k you gonna take care of it, but your agency still has like 20 more steps to execute and just Need those information. So here is the critical question if it cannot stay in the context, where does it go? Andre Karpathy says treat your context window as a computer. Same as that CPU has fast access, RAM has like a little bit of a slower access, and then you've got disk, which is the slowest access. Your agency needs also that kind of hierarchy. So keep only what you need right now for the current decision. Everything else offloaded. So our method two is basically context offloading. So you can do context offloading by showing everything heavy in files, like logs, search results. like scraped html, a pdf extraction, large json responses and then return only the file path identifiers and clean summaries structured schemas and you will have like two levels of context offloading level one is a short term kind of scratchpad you write to scratchpad and you read it from it and read the scratchpad if it's empty write initial ones otherwise we just write the key findings to scratchpad don't keep raw search results in the context you just keep references to nodes and final answers are basically synthesis of scratchpad nodes and if i want to show you the code this is actually how simple we can just do it in blank chain So use the scratchpad like a message state, explain it, then write the tool. As you can see, you can just define the tools, write your scratchpad tool, and then just save it. You just give the description and then read will be again also same way. And then we have search tools or other tools, and then you can add that tool. So read from scratchpad and write from scratchpad to your tools. it is as simple as that and the second one is just do a long-term memory store which is just write it to your postgres it's really easy and if you look at the code you can go ahead and pick up the vector stores the pg to postgres embedding and just write it from a document to that postgres it is pretty straight and there is these brilliant things that manastos they use kind of plan to do md and for every complex text they just continuously rewrite that to do and then in this case memory lives in your system and not in your LLM or AI agent context so you may ask what about tools themselves don't 100 tools definition bloat context okay just give it fewer tools but then we cannot solve a complicated problem. So we have this tool paradox, you know, you need more capability, but too many tools cause confusion. This is our method three. Just before that, I have made one of my paid course modules free. It's a link in the description. I will give you also a free guide. It's the first link. and if you want to dive into my paid course it's also in the description this is the five in one a agent mastery okay what are the three simple layers so the core functions are layer one think of read file write file search browsers so here is the trick by just using these tools you can do anything for other things that you need you go to pre-install tools those are basically all your other tools If you've got a video converter or an image processor or speech recognition or even your MCP tools, you just install here unlimited tools, but they are just not in your list of tools in your permanent tools. And finally, we have the layer of power. Just write code. So you just write custom code for anything you want. So your agent will call any API, use any Python library, do heavy computation, process large databases at this stage. It just gives you that a small interface, but infinite possibility. But now you have another problem. Even with a smart tool design, tool outputs still add thousands of tokens to your context. So for example, a single web search, it can be like 3000 tokens and then you have FireEat, another 5000. And then after 22 calls, you are basically drowning in output. So how do you actually reduce this without losing critical information? It is with compaction. Do you remember that I was talking about compaction and reduction earlier? And I said I will talk about it later. This is actually our method 4, which... will show you how to compact our context so we instead of having that full raw contact we want actually that reference contact the compact contact so what we do in the compaction and that's why it's reversible you strip the reconstructable information but keep identifiers so universal identifiers are file operation gives file pass browser operation gives url and search operation gives Query strings and API calls will give you request IDs. Context summarization is different. You compress information in shorter form so your details are lost. And what is the golden rule for when to do summarization is that when you do summarize, always summarize from the full version. Never compact version, just always from a structured schema, not free format prompts. So let me show you do compaction, compaction, compaction. and a little bit of summarization and then you go compaction and compaction and the last one you can see it's just kind of hanging there because a pro tip is keep the last few tools on summer and this maintain actually the style of what you were writing so it provides fresh view shot example it also prevents the model from imitating your compact format so coding it in LangChain is straightforward what you can see is that you give the guidelines the same as I explained in the prompt add that node to the to the graph which is a tool node with summarization it's as simple as that if you have a workflow that needs 50 tool calls this is still going to bloat your contacts right that's where the method number five is coming another intuitive but a very effective way to decrease your contacts window so if you have a deep search your agent will gonna just do some research get some links then extract the key points compare the resources synthesize findings and then you've got a lot of tokens at hand and if you do that five times and you are 140 000 tokens which is you are in the rot zone but if you want to use the agent as tool which is called sop agent as well what you do is you use a helper agent so so each time you just create a new helper fresh empty content do the 50 tool calls you need return the summary and throw away the entire helper agent basically you create another new helper the next time you need actually that tool and in this way the sub-agent will return 500 tokens so sub-agent context is thrown away because it was basically temporary workspace so if you're wondering what if helper agent needs 200 tokens then i would say use these decision tree between 5 to 20 tools just use your main agent 20 to 50 tools use a sub-agent and if you have more than that basically do context uploading as we have said because it's just too much to do and the question is if sub-agents are so powerful why not use them for everything but we have a problem with these sub-agents because they have a trap which is called isolation because in isolation you increase the capacity but then you lose coordination and cooperation cognition ai says don't build a multi-agent when you need actually this coherence you need to create a decision all together so what they say is if you have this kind of tasks the agent breaks into tasks and you get it and combine it it's almost surely unreliable it's still unreliable when you do the sub agents and they do the sub task and they combine it what is working is when you have supervision on one one agent just kind of give two sub agents the sub tasks and they can just do it separately or will give it back to the agent and that agent will combine it this is what we call context quarantine in context quarantine you just have a supervisor agency synthesize everything one agent does all the decision making so when to use it use multi-agent for information gathering and use this supervisor system when you need coherence how do you code it graph for both of them so you have the math expert and the research expert and it will be combined by the supervisor but if any agent may not help us see different tools at once it struggles to pick the right one and we can solve that actually with our method number seven which is rag for tools It's extremely intuitive and simple, but we are going to use our vector database, our RAC method to solve this problem. If you don't know about RAC, I have a video about RAC on my channel. You just pre-process, you just create a registry of your tools. For each tool, you write a description, convert the description to embedding, and then store it in a searchable database. Then your... user can ask something like what's the better in Tokyo and then you go ahead and basically find all the tools by finding the similarities in your embedding the similarity gives you actually five top tools for example And in this case, it would get weather, get forecast, get temperature, get humidity, and weather alerts. Now agent basically can see only five tools. It will be way easier to get the right tools. It will not be confused by 100 other tools, which makes it very easy for your agent to choose. If we want to code it, you will have just set. tool registry and you have tool ids and the description as i said you can just use the surveys and spaces store in a line graph and you finally can have something like query that and we'll search for that tool for the top five this works actually with layer action space sub agents or also agent as tools all of the previous methods that we mentioned It's relevant when you have a lot of similar tools. If you just have limited tools, it doesn't make sense to use RAP. I promised a number of laws and meta laws. Number one, offload everything token heavy. Number two, compact first, summarize last. Number three, set alerts on 128k. Split by task type, not job title. Three layer design, as I just mentioned. You go to basic utility and code and then structure beats. free format you know that and simpler systems always win and at the end the law number eight is monitor continuously and if you want to have also as a checklist this is actually the context engineering checklist that you can also screenshot and always use if you want to keep just one law that would be like the unifying principle that would be the simpler system always win because context engineering should make the a agent job simpler not harder so i hope that all of these methods could just make the desired output that you want for your a agent it makes it for my 300 plus agents that i have built uh check out my free module and also the the course all the methods that i mentioned are brilliant but simple you can only get better at them and apply them if you build AI agents and if you want to build AI agents like hands-on and real-world AI agents watch this next video where I build the AI cyber security end-to-end in just 12 minutes. See you there!
⚙️ Pipeline jobs
| Stage | Status | Att. | Updated | Error |
|---|---|---|---|---|
| download | done | 1/3 | 2026-07-20 11:58:02 | |
| transcribe | done | 1/3 | 2026-07-20 11:59:01 | |
| summarize | done | 1/3 | 2026-07-20 11:59:22 | |
| embed | done | 1/3 | 2026-07-20 11:59:24 |
📄 Описание YouTube
Показать
Learn 7 advanced context engineering methods used by Anthropic, LangChain, and Manus to build production-ready AI agents. This comprehensive tutorial covers the Pre-Rot Threshold (why agents fail at 128K tokens), Layered Action Space architecture, Context Offloading strategies, the Compaction Principle, Agent-as-Tool patterns, Multi-Agent coordination, and Dynamic Tool Selection—plus 8 Meta Laws and Python code in LangGraph. » ♕ 𝗙𝗿𝗲𝗲 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝘀 𝗧𝗿𝗮𝗶𝗻𝗶𝗻𝗴 + 𝟮𝗫 𝗙𝗿𝗲𝗲 𝗚𝘂𝗶𝗱𝗲𝘀: https://www.maryammiradi.com/free-ai-agents-training?utm_source=youtube_desc » ♔ 𝟳-𝗶𝗻-𝟭 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝘀 𝗧𝗿𝗮𝗶𝗻𝗶𝗻𝗴 (𝟲𝟬% 𝗢𝗙𝗙): https://www.maryammiradi.com/ai-agents-mastery?utm_source=youtube_desc Perfect for developers, ML engineers, and AI practitioners building real-world agentic systems that scale beyond toy demos. Github repo: github.com/langchain-ai/how_to_fix_your_context/blob/main/notebooks/06-context-offloading.ipynb Chroma: research.trychroma.com/context-rot Manus: rlancemartin.github.io/2025/10/15/manus/ 🔑 KEY TOPICS Context Engineering: - Pre-Rot Threshold - Agents degrade at 128K-200K tokens, not at model limits - Context Offloading - Scratchpads and external memory strategies - Layered Action Space - Supporting infinite capabilities with 10 function calls - Compaction vs Summarization - Reversible vs irreversible compression - Agent-as-Tool Pattern - Hiding complex workflows behind clean schemas - Context Quarantine - Multi-agent isolation for information gathering - Dynamic Tool Selection - RAG for tools to reduce confusion - 8 Meta Laws - Golden rules for balancing trade-offs 📊 WHAT YOU'LL LEARN: ✅ Why context capacity ≠ context quality ✅ How to detect and prevent context rot before 200K tokens ✅ Production patterns from Anthropic's multi-agent researcher ✅ Peak's breakthrough Layered Action Space architecture from Manus ✅ When to use compaction vs summarization ✅ How to build Agent-as-Tool patterns that save 10,000 tokens per session ✅ Multi-agent strategies that avoid coordination chaos ✅ Python implementation of Context Engineering in LangGraph 🎓 ABOUT ME: I'm Maryam, PhD with 20+ years in AI, teaching AI Agents to thousands of students in 90+ countries through AI Agents Mastery. ⏱️ TIMESTAMPS: 0:00 - Context Engineering: Capacity vs Quality 0:27 - Pre-Rot Threshold Detection in Context Engineering 2:44 - Context Offloading 5:31 - Layered Action Space 6:59 - Compaction Principle 8:50 - Agent-as-Tool Pattern 11:12 - Context Quarantine 11:47 - Dynamic Tool Selection 13:27 - Meta Laws of Context Engineering 14:17 - Build AI Agents #contextengineering #aiagents #langchain #langgraph #llm