• AI 智能体的上限，不只看模型大小，更看“上下文管理”这门手艺。它就像为 CPU 配置内存，决定了智能体思考的深度和效率。
• 上下文窗口不是垃圾桶：信息过载会“投毒”、干扰、混淆 AI 的判断。精准，远比海量更重要。
• 高手用“写、筛、压、隔”四字诀管理 AI 上下文，把有限的“内存”用在刀刃上，实现降本增效。
• 未来的竞争是系统效率的竞争。用多智能体架构“隔离”任务，让每个智能体在自己的小窗口里做到极致，是构建复杂任务系统的关键。

核心摘要

智能体（Agent）执行任务离不开上下文（Context）。所谓“上下文工程”，正是在智能体执行任务的每一步，都为其上下文窗口精准注入恰当信息的艺术与科学。本文将当下主流智能体所采用的上下文工程策略，归纳为几大通用模式。

上下文工程（Context Engineering）

正如 Andrej Karpathy 所说，大语言模型（LLM）就像一种“新型操作系统”。LLM 是 CPU，而它的“上下文窗口”就是 RAM，充当着模型的工作记忆。正如 RAM 的容量有限，LLM 的上下文窗口在处理各种上下文来源时也面临容量瓶颈。操作系统的核心工作之一是管理如何高效使用 CPU 的 RAM，而“上下文工程”也扮演着类似的角色。Karpathy 对此总结得非常到位：

上下文工程是“……一门为下一步（计算）精准填充上下文窗口的精妙艺术与科学。”

在构建 LLM 应用时，我们需要管理哪些类型的上下文呢？上下文工程这个总括性概念，涵盖了以下几种不同的上下文类型：

• • 指令（Instructions） – 提示词、记忆、少样本示例、工具描述等
• • 知识（Knowledge） – 事实、记忆等
• • 工具（Tools） – 工具调用的反馈信息

面向智能体的上下文工程

今年，随着 LLM 在推理和工具调用方面能力的提升，人们对智能体的兴趣与日俱增。智能体通过交替调用 LLM 和工具来执行任务，尤其擅长处理长期运行的复杂任务。

然而，长期任务和不断累积的工具调用反馈，意味着智能体通常会消耗大量的 token。这可能引发诸多问题：超出上下文窗口的容量限制、导致成本和延迟激增，甚至降低智能体性能。Drew Breunig 曾清晰地指出，过长的上下文可能通过以下几种方式导致性能问题：

• • 上下文投毒（Context Poisoning）：当幻觉（错误信息）进入上下文时。
• • 上下文干扰（Context Distraction）：当上下文信息过多，淹没了模型的原始训练知识时。
• • 上下文混淆（Context Confusion）：当无关的上下文信息影响了模型的响应时。
• • 上下文冲突（Context Clash）：当上下文中的不同部分相互矛盾时。

考虑到这些问题，Cognition AI 公司强调了上下文工程的重要性：

“上下文工程”……实际上是构建 AI 智能体的工程师的首要任务。

Anthropic 公司也明确指出：

智能体通常需要进行数百轮的对话，这要求我们采用审慎的上下文管理策略。

那么，如今的开发者们是如何应对这一挑战的呢？我将现有方法归纳为四大类——写入（Write）、筛选（Select）、压缩（Compress）和隔离（Isolate）——并分别举例说明。

写入上下文（Write Context）

写入上下文，指将信息保存在上下文窗口之外，以备智能体执行任务时使用。

暂存区（Scratchpads）

人类在解决问题时，会做笔记并记住一些事，以便在未来处理相关任务时使用。智能体也正逐渐获得这些能力！通过“暂存区”做笔记，就是一种在智能体执行任务期间持久化信息的方法。其核心思想是将信息保存在上下文窗口之外，但又能随时供智能体取用。Anthropic 的多智能体研究系统就提供了一个清晰的例子：

“首席研究员”首先会思考解决问题的方法，并将其计划保存到“记忆”中以持久化上下文，因为一旦上下文窗口超过 20 万 token 就可能被截断，而保留计划至关重要。

暂存区的实现方式有多种。它可以是一个简单的工具调用，比如写入一个文件；也可以是运行时状态对象中的一个字段，在整个会话期间保持不变。无论哪种方式，暂存区都让智能体能够保存有用信息，以更好地完成任务。

记忆（Memories）

暂存区帮助智能体在单次会话中解决任务，但有时智能体需要跨越多次会话记住事情。Reflexion 模型引入了在每轮智能体行动后进行反思，并复用这些自我生成记忆的理念。Generative Agents 模型则能从过去智能体的反馈集合中，周期性地合成记忆。

这些概念已被应用于 ChatGPT、Cursor 和 Windsurf 等流行产品中。它们都具备基于用户与智能体交互，自动生成长期记忆的机制。

筛选上下文（Select Context）

筛选上下文，指将所需信息调入上下文窗口，以帮助智能体执行任务。

暂存区（Scratchpad）

从暂存区筛选上下文的机制，取决于其实现方式。如果它是一个工具，智能体只需通过工具调用来读取。如果它是智能体运行时状态的一部分，开发者就可以在每一步选择性地将状态的某些部分暴露给智能体。这为后续回合中向 LLM 提供暂存区上下文提供了精细的控制。

记忆（Memories）

如果智能体有能力保存记忆，它们也需要能力来筛选与当前任务相关的记忆。这非常有用，原因有几点：智能体可以选择少样本示例（情景记忆）来学习期望的行为模式；可以选择指令（程序记忆）来引导自身行为；或者选择事实（语义记忆）来为任务提供相关背景。

一大挑战是确保筛选出的记忆是相关的。一些流行的智能体仅使用一小部分固定的文件，这些文件总是被加载到上下文中。例如，许多代码智能体使用文件来保存指令（“程序记忆”），或在某些情况下保存示例（“情景记忆”）。Claude Code 使用 CLAUDE.md，而 Cursor 和 Windsurf 则使用规则文件。

但是，如果智能体存储了大量的（例如“语义记忆”类型的）事实或关系，筛选就变得更加困难。ChatGPT 是一个很好的例子，它存储并从大量用户专属记忆中进行筛选。

向量嵌入和/或知识图谱是常用的记忆索引技术，以辅助筛选。尽管如此，记忆筛选仍然充满挑战。在 AIEngineer 世界博览会上，Simon Willison 分享了一个记忆筛选出错的例子：ChatGPT 从记忆中获取了他的位置信息，并意外地将其注入到他要求的图片中。这种意料之外或不希望发生的记忆检索，会让一些用户感觉上下文窗口“不再属于他们自己”！

工具（Tools）

智能体需要使用工具，但如果提供的工具过多，它们可能会不堪重负。这通常是因为工具描述可能重叠，导致模型在选择哪个工具时感到困惑。一种方法是对工具描述应用 RAG（检索增强生成），根据语义相似性为任务检索最相关的工具。最近的一些论文表明，这种方法能将工具选择的准确率提高 3 倍。

知识（Knowledge）

检索增强生成（RAG）本身就是一个宏大的课题，并且可以成为上下文工程的核心挑战。代码智能体是 RAG 在大规模生产应用中的最佳范例之一。Windsurf 的 Varun 很好地概括了其中的一些挑战：

索引代码 ≠ 上下文检索……我们正在做的，是通过 AST（抽象语法树）解析代码，并沿着有语义意义的边界进行分块……但随着代码库规模的增长，向量嵌入搜索作为一种检索启发式方法变得不可靠……我们必须依赖多种技术的组合，如 grep/文件搜索、基于知识图谱的检索，以及……一个重排序步骤，其中上下文会按相关性排序。

压缩上下文（Compress Context）

压缩上下文，指仅保留执行任务所必需的 token。

上下文总结（Context Summarization）

智能体的交互可能跨越数百轮，并使用消耗大量 token 的工具。总结是应对这些挑战的常用方法。如果你用过 Claude Code，你已经见过它的实际应用。当上下文窗口使用率超过 95% 时，Claude Code 会运行“自动压缩”，对用户与智能体的完整交互轨迹进行总结。这种对智能体轨迹的压缩可以采用多种策略，例如递归总结或分层总结。

在智能体的设计中适时加入总结步骤也很有用。例如，它可以用于后处理某些工具的调用（特别是像搜索工具这类消耗大量 token 的工具）。再比如，Cognition 公司提到在智能体与智能体交接的边界处进行总结，以减少知识传递过程中的 token 消耗。如果需要捕捉特定的事件或决策，总结可能会很有挑战性。Cognition 为此使用了一个微调模型，这凸显了这一步骤可能需要投入的大量工作。

上下文修剪（Context Trimming）

总结通常使用 LLM 来提炼最相关的上下文片段，而修剪则更像是过滤或如 Drew Breunig 所说的“剪枝”上下文。这可以采用硬编码的启发式规则，比如从消息列表中移除较早的消息。Drew 还提到了 Provence，一个为问答任务训练的上下文剪枝器。

隔离上下文（Isolating Context）

隔离上下文，指将上下文拆分，以帮助智能体执行任务。

多智能体（Multi-agent）

隔离上下文最流行的方式之一，就是将其分散到多个子智能体中。OpenAI 的 Swarm 库的一个动机就是“关注点分离”，即由一个智能体团队来处理子任务。每个智能体都有自己特定的工具集、指令和独立的上下文窗口。

Anthropic 的多智能体研究系统为此提供了有力论证：多个拥有独立上下文的智能体，其表现优于单个智能体，很大程度上是因为每个子智能体的上下文窗口可以专注于一个更狭窄的子任务。正如其博客所述：

子智能体们带着各自的上下文窗口并行运作，同时探索问题的不同方面。

当然，多智能体也面临挑战，包括 token 的消耗（例如，Anthropic 报告称其 token 使用量是聊天的 15 倍）、需要精心的提示工程来规划子智能体的工作，以及子智能体之间的协调问题。

通过环境隔离上下文（Context Isolation with Environments）

HuggingFace 的深度研究员项目展示了另一个有趣的上下文隔离例子。大多数智能体使用工具调用 API，这些 API 返回 JSON 对象（工具参数），然后传递给工具（如搜索 API）以获取反馈（如搜索结果）。HuggingFace 则使用一个 CodeAgent，它直接输出包含所需工具调用的代码。这些代码随后在一个沙箱环境中运行。工具调用返回的特定上下文（如返回值）才被传回给 LLM。

这使得上下文可以在环境中与 LLM 隔离。Hugging Face 指出，这是一种隔离消耗大量 token 的对象的绝佳方式：

Code Agents 能够更好地处理状态……需要存储图像/音频/其他数据以备后用？没问题，只需将其分配为一个变量，你就可以稍后使用它。

状态（State）

值得一提的是，智能体的运行时状态对象也是隔离上下文的好方法。这可以起到与沙箱类似的作用。状态对象可以设计一个模式（Schema，例如 Pydantic 模型），其中包含可以写入上下文的字段。模式中的一个字段（如 messages）可以在智能体的每一轮交互中暴露给 LLM，但模式可以将信息隔离在其他字段中，以便更具选择性地使用。

结论

智能体上下文工程的模式仍在不断演进，但我们可以将常见方法归纳为四大类——写入、筛选、压缩和隔离：

• • 写入上下文，指将信息保存在上下文窗口之外，以备智能体执行任务时使用。
• • 筛选上下文，指将所需信息调入上下文窗口，以帮助智能体执行任务。
• • 压缩上下文，指仅保留执行任务所必需的 token。
• • 隔离上下文，指将上下文拆分，以帮助智能体执行任务。

理解并运用这些模式，是当今构建高效智能体的核心工作。

• إن حدود وكيل الذكاء الاصطناعي لا تعتمد فقط على حجم النموذج، بل تعتمد أيضًا على مهارة “إدارة السياق”. فهي تشبه تكوين الذاكرة لوحدة المعالجة المركزية، حيث تحدد عمق التفكير وكفاءته.
• نافذة السياق ليست سلة مهملات: إن تحميل المعلومات بشكل زائد يمكن أن “يسمم” ويعوق ويشوش أحكام الذكاء الاصطناعي. الدقة أكثر أهمية بكثير من الكمية الهائلة.
• يسعى الفطاحل إلى إدارة سياق الذكاء الاصطناعي باستخدام أربع كلمات: “الكتابة، التصفية، الضغط، والعزل”، مستخدمين جزءًا محدودًا من “الذاكرة” في المكان المناسب، لتحقيق خفض التكاليف وزيادة الكفاءة.
• المنافسة المستقبلية هي منافسة كفاءة الأنظمة. استخدام بنية متعددة الوكلاء “لعزل” المهام، مما يسمح لكل وكيل بالعمل على أعلى مستوى في نافذته الخاصة، هو المفتاح لبناء أنظمة المهام المعقدة.

ملخص أساسي

إن الوكلاء (Agent) لا يمكنهم تنفيذ المهام دون وجود سياق (Context). ما يسمى بهندسة السياق، هو فن وعلم ضمان إدخال معلومات دقيقة لنافذة سياق الوكيل في كل خطوة من خطوات تنفيذ المهمة. في هذا المقال، سنستعرض استراتيجيات هندسة السياق المستخدمة حاليًا من قبل الوكلاء الرائدين، ونلخصها في عدة أنماط شائعة.

هندسة السياق (Context Engineering)

كما قال Andrej Karpathy، تعتبر النموذجات اللغوية الكبيرة (LLM) كنوع من “أنظمة التشغيل الجديدة”. إن الـ LLM هي وحدة المعالجة المركزية، بينما تعتبر “نافذة السياق” بمثابة الذاكرة العشوائية RAM، حيث تعمل كذاكرة العمل للنموذج. ومثلما سعة الـ RAM محدودة، تواجه نافذة سياق الـ LLM أيضًا قيودًا بسبب سعة معالجة مصادر السياق المختلفة. واحدة من المهام الأساسية لنظام التشغيل هي إدارة كيفية استخدام ذاكرة وحدة المعالجة المركزية بفعالية، وتلعب “هندسة السياق” دورًا مشابهًا. وقد لخص Karpathy ذلك بشكل ممتاز:

هندسة السياق هي “فن وعلم دقيق لتعبئة نافذة السياق بدقة للخطوة التالية (الحساب).”

عند بناء تطبيقات الـ LLM، أي نوع من السياقات يجب علينا إدارته؟ تغطي فكرة هندسة السياق المفاهيم التالية:

• • التعليمات (Instructions) – كلمات الدليل، الذاكرة، أمثلة قليلة، وصف الأدوات، إلخ.
• • المعرفة (Knowledge) – الحقائق، الذاكرة، إلخ.
• • الأدوات (Tools) – معلومات التغذية المرتدة لاستدعاء الأدوات.

الهندسة السياقية للوكيل الذكي

هذا العام، مع تعزيز قدرات LLM في الاستدلال واستدعاء الأدوات، زاد اهتمام الناس بالوكلاء بشكل كبير. يقوم الوكلاء بتنفيذ المهام من خلال استدعاء LLM والأدوات بالتناوب، ويمتازون بخبرتهم في معالجة المهام المعقدة التي تتطلب تشغيلًا لفترات طويلة.

ومع ذلك، فإن المهام طويلة الأمد والتغذيات المرتبطة باستدعاء الأدوات تُشير إلى أن الوكلاء عادةً ما تستهلك كمية كبيرة من الـ token. هذا قد يؤدي إلى العديد من المشاكل: تجاوز قيود سعة نافذة السياق، مما يؤدي إلى زيادة التكاليف والكمون، بل ويقلل من أداء الوكيل. أشار Drew Breunig بوضوح إلى أن السياق الطويل جدًا قد يؤدي إلى مشاكل أداء بعدة طرق:

• • تسمم السياق (Context Poisoning): عندما تدخل المعلومات الخاطئة (الأوهام) إلى السياق.
• • تشتت السياق (Context Distraction): عندما تكون المعلومات السياقية كثيرة لدرجة أنها تغمر معرفة التدريب الأصلية للنموذج.
• • تشويش السياق (Context Confusion): عندما تؤثر المعلومات السياقية غير ذات الصلة على استجابة النموذج.
• • تعارض السياق (Context Clash): عندما تتنافى أجزاء مختلفة من السياق مع بعضها البعض.

نظرًا لهذه المشاكل، أكدت شركة Cognition AI على أهمية هندسة السياق:

“هندسة السياق”… في الواقع، هي المهمة الأساسية لمهندسي بناء الوكلاء الذكية.

كما أكدت شركة Anthropic:

يحتاج الوكلاء عادةً إلى إجراء مئات من الدردشات، مما يتطلب منا اعتماد استراتيجيات صارمة لإدارة السياق.

كيف يتعامل مطورو اليوم مع هذه التحديات؟ سأقوم بتلخيص الأساليب الحالية في أربع فئات: **الكتابة (Write)، التصفية (Select)، الضغط (Compress)، والعزل (Isolate)**، وسأقوم بتقديم أمثلة لكل منها.

كتابة السياق (Write Context)

كتابة السياق تعني حفظ المعلومات خارج نافذة السياق لاستخدامها أثناء أداء الوكيل للمهمة.

مناطق التخزين المؤقت (Scratchpads)

عندما يحل البشر المشكلات، يكتبون الملاحظات ويتذكرون بعض الأمور لاستخدامها لاحقًا في المهام المرتبطة. الوكلاء أيضًا بدأوا في اكتساب هذه القدرة! تُعد كتابة الملاحظات في منطقة التخزين المؤقت، طريقة لاستمرارية المعلومات أثناء أداء الوكيل للمهمة. الفكرة الرئيسية هي حفظ المعلومات خارج نافذة السياق، ولكن يمكن استرجاعها من قبل الوكيل في أي وقت. تقدم أنظمة الأبحاث المتعددة الوكلاء التابعة لشركة Anthropic مثالًا واضحًا على ذلك:

“الباحث الرئيسي” سيبدأ أولًا في التفكير في طرق لحل المشكلة، ويقوم بحفظ خطته في “الذاكرة” لاستدامة السياق، لأن تجاوز نافذة السياق 200,000 توكن قد يؤدي إلى قطعها، مما يجعل الحفاظ على الخطة أمرًا حيويًا.

يمكن تنفيذ منطقة التخزين المؤقت بطرق عديدة. يمكن أن تكون استدعاء أداة بسيطة، مثل كتابة ملف؛ أو قد تكون حقلًا داخل كائن حالة التشغيل، يظل ثابتًا على مدار الجلسة بأكملها. بغض النظر عن طريقة التنفيذ، فإن منطقة التخزين المؤقت تمكن الوكلاء من حفظ معلومات مفيدة لأداء أفضل في المهام.

الذاكرة (Memories)

تساعد منطقة التخزين المؤقت الوكيل في حل المهام ضمن جلسة واحدة، لكن في بعض الأحيان يحتاج الوكيل إلى تذكر الأشياء عبر جلسات متعددة. قدم نموذج Reflexion مفهوم التفكير بعد كل دورة من دورة الوكيل، وأعاد استخدام هذه الذكريات الناتجة عن الذات. بينما يستطيع نموذج Generative Agents دمج الذكريات بشكل دوري من مجموعة ردود الوكيل السابقة.

تُستخدم هذه المفاهيم في العديد من المنتجات الشائعة مثل ChatGPT وCursor وWindsurf. لديها آلية لتوليد الذاكرة الطويلة تلقائيًا بناءً على تفاعل المستخدم مع الوكيل.

تصفية السياق (Select Context)

تصفية السياق تعني سحب المعلومات المطلوبة إلى نافذة السياق لمساعدة الوكيل في تنفيذ المهمة.

مناطق التخزين المؤقت (Scratchpads)

تعتمد آلية تصفية السياق من منطقة التخزين المؤقت على كيفية تنفيذها. إذا كانت أداة، يمكن للوكيل القراءة من خلال استدعاء الأداة. إذا كانت جزءًا من حالة تشغيل الوكيل، يمكن للمطور اختيار عرض أجزاء معينة من هذه الحالة للوكيل في كل خطوة. وهذا يوفر تحكمًا دقيقًا لتوفير سياق منطقة التخزين المؤقت إلى الـ LLM في الجولات التالية.

الذاكرة (Memories)

إذا كان للوكيل القدرة على حفظ الذكريات، فسيحتاج أيضًا إلى القدرة على تصفية الذكريات المرتبطة بالمهمة الحالية. هذا مفيد لأسباب عدة: يمكن للوكيل أن يختار أمثلة قليلة (ذاكرة سياقية) لتعلم الأنماط السلوكية المتوقعة؛ أو تحديد التعليمات (ذاكرة برمجية) لتوجيه سلوكه؛ أو تقديم الحقائق (ذاكرة دلالية) لتوفير الخلفية ذات الصلة للمهمة.

ومن التحديات الكبيرة هو ضمان أن الذكريات المصفاة ذات صلة. يستخدم العديد من الوكلاء الشائعة جزءًا صغيرًا من ملفات ثابتة، تُحمّل دائمًا في السياق. على سبيل المثال، تستخدم العديد من الوكلاء البرمجية الملفات للاحتفاظ بالتعليمات (“ذاكرة برمجية”)، أو في بعض الحالات، للاحتفاظ بالأمثلة (“ذاكرة سياقية”). يستخدم Claude Code ملف CLAUDE.md، بينما تستخدم Cursor وWindsurf ملفات القواعد.

ومع ذلك، إذا خزن الوكيل كمية كبيرة من الحقائق أو العلاقات (مثل نوع “الذاكرة الدلالية”)، تصبح عملية التصفية أكثر صعوبة. يُعتبر ChatGPT مثالًا جيدًا، حيث يخزن ويصفّي من كمية كبيرة من الذكريات الخاصة بالمستخدم.

تعتبر عمليات تضمين المتجهات و/أو الرسوم البيانية المعرفية تقنيات شائعة لفهرسة الذاكرة للمساعدة في التصفية. ومع ذلك، لا تزال التصفية تتسم بالتحديات. في معرض AIEngineer، شارك Simon Willison مثالًا على فشل تصفية الذاكرة: حيث استرجع ChatGPT موقعه من الذاكرة، وأدرجه بشكل غير مقصود في الصورة التي طلبها. هذه الاسترجاعات غير المتوقعه أو غير المرغوب فيها من الذاكرة قد تجعل بعض المستخدمين يشعرون بأن نافذة السياق “لم تعد خاصة بهم”!

الأدوات (Tools)

يحتاج الوكلاء لاستخدام الأدوات، لكن إذا قدمت أدوات كثيرة، قد يجدون أنفسهم تحت ضغط هائل. غالبًا ما يكون السبب في ذلك هو تداخل أوصاف الأدوات، مما يجعل النموذج مرتبكًا بشأن الأداة التي ينبغي استخدامها. إحدى الطرق هي تطبيق RAG (التوليد المحسن بالاسترجاع) على أوصاف الأدوات، وفقًا للتشابه الدلالي لاسترجاع الأداة الأكثر ارتباطًا بالمهمة. أظهرت بعض الأوراق البحثية الأخيرة أن هذه الطريقة تستطيع زيادة دقة اختيار الأداة ثلاثة أضعاف.

المعرفة (Knowledge)

إن التوليد المحسن بالاسترجاع (RAG) هو موضوع كبير بحد ذاته، ويمكن أن يصبح تحديًا مركزيًا في هندسة السياق. تُعتبر الوكلاء البرمجية مثالًا ممتازًا لتطبيق RAG على نطاق واسع. وقد اختصر Varun من Windsurf بعض التحديات:

فهرسة الكود بذاتها لا تعني الاسترجاع السياقي… ما نقوم به هو تحليل الكود من خلال AST (شجرة التركيب المجردة) وتقسيمه على حدود ذات معنى دلالي… لكن مع ازدياد حجم مكتبة الكود، يصبح البحث باستخدام تضمين المتجهات كأسلوب استرجاع غير موثوق… نحن مضطرون للاعتماد على مجموعة من التقنيات، مثل grep/البحث في الملفات، واسترجاع البيانات بناءً على الرسوم البيانية المعرفية، بالإضافة إلى… خطوة إعادة ترتيب، حيث يتم تصنيف السياق حسب الصلة.

ضغط السياق (Compress Context)

ضغط السياق يعني الإبقاء فقط على الـ token الضرورية لتنفيذ المهمة.

تلخيص السياق (Context Summarization)

يمكن أن تمتد تفاعلات الوكيل عبر مئات الجولات، باستخدام أدوات تستهلك كمية كبيرة من الـ token. يُعتبر التلخيص وسيلة شائعة للتعامل مع هذه التحديات. إذا كنت قد استخدمت Claude Code، فقد شهدت تطبيقه العملي. عندما تتجاوز استخدام نافذة السياق نسبة 95%، يقوم Claude Code بتنفيذ “ضغط تلقائي”، لتلخيص المحاورات الكاملة بين المستخدم والوكيل. يمكن أن يتم هذا التلخيص بطرق متعددة، مثل التلخيص المتكرر أو التلخيص الهيكلي.

من المفيد دمج خطوة التلخيص في تصميم الوكيل في الوقت المناسب. على سبيل المثال، يمكن استخدامها لمعالجة بعض استدعاءات الأدوات (خاصةً تلك التي تستهلك مصادر كثيرة من الـ token مثل أدوات البحث). على سبيل المثال، تشير شركة Cognition إلى أنه يمكن إجراء التلخيص عند انتقال المعرفة بين الوكلاء، لتقليل استهلاك الـ token في كيفية نقل المعرفة. إذا كانت هناك حاجة لالتقاط أحداث أو قرارات معينة، قد يواجه التلخيص تحديات. استخدمت Cognition نموذجًا مُعدّلًا لهذه الغاية، مما يُبرز كمية العمل التي قد يتطلبها هذا الخطوة.

اقتطاع السياق (Context Trimming)

غالبًا ما يستخدم التلخيص الـ LLM لاستخراج أجزا السياق الأكثر صلة، بينما اقتطاع السياق يميل إلى أن يكون أكثر تخليصًا أو كما أوضح Drew Breunig، “التقليم” للسياق. يمكن تنفيذ ذلك باستخدام قواعد خوارزمية صريحة، مثل إزالة الرسائل القديمة من قائمة الرسائل. أشار Drew أيضًا إلى Provence، وهو مقلم سياقي تم تدريبه على مهام السؤال والجواب.

عزل السياق (Isolating Context)

عزل السياق يعني تقسيم السياق لمساعدة الوكيل على تنفيذ المهمة.

أكثر من وكيل (Multi-agent)

إحدى الطرق الأكثر شيوعًا لعزل السياق هي تقسيمه إلى عدة وكلاء فرعيين. أحد دوافع مكتبة Swarm الخاصة بـ OpenAI هو “فصل النقاط الأساسية”، أي أن فريقًا من الوكلاء يتولى معالجة المهام الفرعية. كل وكيل لديه مجموعة محددة من الأدوات، وتعليمات، ونافذة سياق خاصة به.

كما يقدم نظام البحث المتعدد الوكلاء من Anthropic دليلًا قويًا على أن الوكلاء المتعددين الذين لديهم سياقات مستقلة، يؤدون أداءً أفضل من وكيل واحد، وذلك إلى حد كبير لأن نافذة السياق لكل وكيل فرعي يمكن أن تركز على مهمة فرعية أكثر ضيقًا. كما جاء في مدونتهم:

الوكلاء الفرعيون يعملون بالتوازي، موجهين من خلال سياقاتهم الخاصة، مع استكشاف جوانب مختلفة من المشكلة.

بالطبع، تواجه الوكالات المتعددة تحديات أيضًا، بما في ذلك استهلاك الـ token (على سبيل المثال، يشير تقرير Anthropic إلى أن استخدام الـ token الخاص بهم 15 مرة أكثر من المحادثة)، والحاجة إلى إدارة دقيقة لتحفيز تخطيط الوكلاء الفرعيين، بالإضافة إلى تنسيق العمل بين الوكلاء الفرعيين.

عزل السياق عبر البيئات (Context Isolation with Environments)

يعرض مشروع HuggingFace Deep Research مثالًا مثيرًا آخر لعزل السياق. تستخدم معظم الوكلاء واجهات تطبيقات استدعاء الأدوات، التي تعود بأشياء JSON (معلمات الأدوات)، ثم تُمرر إلى الأدوات (مثل واجهة تطبيق بحث) للحصول على التغذية الراجعة (مثل نتائج البحث). بينما تستخدم HuggingFace وكيل CodeAgent، الذي يخرج مباشرةً بالشيفرة التي تحتوي على استدعاء الأدوات المطلوبة. ثم يتم تشغيل هذه الشيفرة في بيئة صندوق الرمل. السياق المحدد الناتج عن استدعاءات الأدوات فقط هو الذي يعود إلى الـ LLM.

هذا يسمح بعزل السياق عن الـ LLM في البيئة. تشير Hugging Face إلى أنها وسيلة رائعة لعزل الأشياء التي تستهلك كمية كبيرة من الـ token:

يتمكن وكلاء الشيفرة من التعامل بشكل أفضل مع الحالة… تحتاج إلى تخزين الصور/الصوت/بيانات أخرى لاستخدامها لاحقًا؟ لا توجد مشكلة، فقط قم بتخصيصها كمتغير، يمكنك استخدامه لاحقًا.

الحالة (State)

من الجدير بالذكر أن كائن حالة التشغيل للوكيل يعد أيضًا وسيلة جيدة لعزل السياق. يمكن أن يعمل كمثل صندوق الرمل. يمكن تصميم كائن الحالة بنمط (Schema، مثل نموذج Pydantic) يتضمن حقول يمكن كتابتها في السياق. يمكن أن يُظهر حقل في النمط (مثل messages) في كل جولة من التفاعلات للـ LLM، لكن النمط يمكن أن يعزل المعلومات في حقول أخرى لاستخدامها بشكل أكثر انتقائية.

الخاتمة

لا تزال أنماط هندسة سياق الوكيل تتطور باستمرار، لكن يمكننا تلخيص الأساليب الشائعة في أربع فئات: الكتابة، التصفية، الضغط، والعزل:

• • كتابة السياق تعني حفظ المعلومات خارج نافذة السياق لاستخدامها أثناء أداء الوكيل للمهمة.
• • تصفية السياق تعني سحب المعلومات المطلوبة إلى نافذة السياق لمساعدة الوكيل في تنفيذ المهمة.
• • ضغط السياق يعني الإبقاء فقط على الـ token الضرورية لتنفيذ المهمة.
• • عزل السياق يعني تقسيم السياق لمساعدة الوكيل على تنفيذ المهمة.

إن فهم واستخدام هذه الأنماط هو عمل أساسي عند بناء وكلاء ذكيين فعالين اليوم.

• La limite des agents IA ne dépend pas seulement de la taille du modèle, mais aussi de l’art de la « gestion du contexte ». Cela revient à configurer la mémoire d’un CPU, déterminant la profondeur et l’efficacité de la pensée de l’agent.
• Une fenêtre contextuelle ne doit pas être un dépotoir : un trop grand flot d’informations peut « empoisonner », perturber et obscurcir le jugement de l’IA. La précision est bien plus importante que la quantité.
• Les experts maîtrisent l’art de la gestion du contexte des agents IA grâce à la stratégie des quatre mots : « Rédaction, Filtrage, Compression, Isolation », utilisant judicieusement la « mémoire » pour optimiser coûts et efficacité.
• La concurrence de demain sera celle de l’efficacité systémique. Isoler des tâches à l’aide d’une architecture multi-agents, permettant à chaque agent de briller dans sa propre petite fenêtre, est essentiel pour la construction de systèmes de tâches complexes.

Résumé Central

Les agents (Agents) accomplissent leurs missions grâce au contexte (Context). Ce que l’on appelle « ingénierie du contexte » est l’art et la science d’injecter précisément les informations appropriées dans la fenêtre contextuelle de l’agent à chaque étape de sa tâche. Cet article résume les stratégies d’ingénierie du contexte utilisées par les agents IA contemporains en plusieurs modèles généraux.

Ingénierie du Contexte

Comme l’a dit Andrej Karpathy, les grands modèles de langage (LLM) sont comme un « nouveau système d’exploitation ». Le LLM est le CPU, tandis que sa « fenêtre contextuelle » est la RAM, servant de mémoire de travail pour le modèle. Tout comme la capacité de la RAM est limitée, la fenêtre contextuelle du LLM est également soumise à des contraintes de capacité lorsqu’il traite diverses sources contextuelles. L’un des principaux travaux d’un système d’exploitation est de gérer l’utilisation efficace de la RAM du CPU, et « l’ingénierie du contexte » joue un rôle similaire. Karpathy résume cela parfaitement :

L’ingénierie du contexte est « … un art et une science subtiles pour remplir précisément la fenêtre contextuelle en prévision de la prochaine étape (de calcul) ».

Lorsque nous développons des applications de LLM, quels types de contexte devons-nous gérer ? Ce concept général d’ingénierie du contexte comprend les types de contexte suivants :

• • Instructions – Prompts, mémoire, exemples à faible échantillonnage, descriptions d’outils, etc.
• • Connaissances – Faits, mémoires, etc.
• • Outils – Feedback sur les appels d’outils.

Ingénierie du Contexte pour les Agents

Cette année, avec l’augmentation des capacités des LLM dans le raisonnement et les appels d’outils, l’intérêt pour les agents IA a considérablement augmenté. Les agents exécutent des tâches en alternant entre les appels de LLM et les outils, et ils sont particulièrement efficaces pour gérer des tâches complexes de longue durée.

Cependant, les tâches à long terme et les feedbacks d’appels d’outils en constante accumulation impliquent que les agents consomment souvent de nombreux tokens. Cela peut soulever de nombreux problèmes : déborder la capacité de la fenêtre contextuelle, entraînant des coûts et des délais accrus, allant jusqu’à nuire à la performance de l’agent. Drew Breunig a clairement souligné que des contextes trop longs peuvent engendrer des problèmes de performance de plusieurs manières :

• • **Empoisonnement du Contexte ** : lorsque des hallucinations (informations erronées) pénètrent dans le contexte.
• • Distraction du Contexte : lorsque trop d’informations contextuelles inondent les connaissances d’entraînement originales du modèle.
• • Confusion du Contexte : lorsqu’une information contextuelle non pertinente influence la réponse du modèle.
• • Conflit du Contexte : lorsque différentes parties du contexte se contredisent.

Tenant compte de ces défis, la société Cognition AI a souligné l’importance de l’ingénierie du contexte :

« L’ingénierie du contexte » est en fait la tâche principale des ingénieurs construisant des agents IA.

La société Anthropic a également précisé :

Les agents ont généralement besoin de mener des dizaines de dialogues, ce qui exige que nous utilisions des stratégies de gestion de contexte attentives.

Comment les développeurs d’aujourd’hui relèvent-ils ce défi ? Je regroupe les méthodes existantes en quatre catégories : Écrire, Filtrer, Comprimer, Isoler et je les illustre avec des exemples.

Écrire le Contexte

Écrire le contexte, c’est conserver des informations en dehors de la fenêtre contextuelle pour utilisation lors de l’exécution de la tâche par l’agent.

Zones de Travail (Scratchpads)

Lorsque les humains résolvent des problèmes, ils prennent des notes et gardent en mémoire certaines choses pour pouvoir les utiliser plus tard. Les agents acquièrent également progressivement ces capacités ! Prendre des notes avec une zone de travail est une méthode pour rendre l’information persistante pendant l’exécution de la tâche par l’agent. L’idée principale est de conserver les informations en dehors de la fenêtre contextuelle, tout en permettant à l’agent d’y accéder à volonté. Le système de recherche multi-agents d’Anthropic offre un exemple clair :

Le « Chercheur Principal » réfléchit d’abord à la manière de résoudre le problème et sauvegarde son plan dans la « mémoire » pour persister le contexte, car une fois que la fenêtre contextuelle dépasse 200 000 tokens, elle risque d’être coupée, et il est crucial de conserver le plan.

Les zones de travail peuvent être mises en œuvre de diverses façons. Cela peut être un simple appel d’outil, comme écrire un fichier ; ou un champ dans un objet d’état d’exécution, conservé constant tout au long de la session. Quoi qu’il en soit, la zone de travail permet à l’agent de conserver des informations utiles pour mieux accomplir ses tâches.

Mémoires (Memories)

Les zones de travail aident les agents à résoudre des tâches dans une seule session, mais parfois, les agents doivent se souvenir de choses sur plusieurs sessions. Le modèle Reflexion a introduit l’idée de réfléchir après chaque action de l’agent et de réutiliser ces mémoires générées. Le modèle Generative Agents peut synthétiser périodiquement des mémoires à partir de l’ensemble des feedbacks des agents passés.

Ces concepts ont été appliqués dans des produits populaires comme ChatGPT, Cursor et Windsurf. Tous possèdent des mécanismes pour automatiser la génération de mémoires à long terme en fonction des interactions entre les utilisateurs et les agents.

Filtrer le Contexte

Filtrer le contexte, c’est attirer les informations nécessaires dans la fenêtre contextuelle pour aider l’agent à exécuter sa tâche.

Zones de Travail (Scratchpad)

Le mécanisme de filtrage du contexte à partir de la zone de travail dépend de son implémentation. S’il s’agit d’un outil, l’agent n’a qu’à lire à l’aide d’un appel d’outil. Si c’est une partie de l’état d’exécution de l’agent, les développeurs peuvent exposer sélectivement certaines parties de l’état à l’agent à chaque étape. Cela permet un contrôle précis sur le contexte de la zone de travail fourni au LLM dans les tours suivants.

Mémoires (Memories)

Si l’agent a la capacité de stocker des mémoires, il doit aussi être capable de filtrer les mémoires pertinentes pour la tâche en cours. Cela est très utile pour plusieurs raisons : l’agent peut choisir des exemples à faible échantillonnage (mémo-situation) pour apprendre des comportements attendus ; envisager des instructions (mémo-programme) pour orienter son propre comportement ; ou sélectionner des faits (mémo-sémantique) pour fournir un contexte pertinent à la tâche.

Un grand défi consiste à garantir que les mémoires filtrées sont pertinentes. Certains agents populaires n’utilisent qu’une petite partie de fichiers fixes, qui sont toujours chargés dans le contexte. Par exemple, de nombreux agents codants utilisent ces fichiers pour stocker des instructions (« mémo-programme ») ou, dans certains cas, des exemples (« mémo-situation »). Claude Code utilise CLAUDE.md, tandis que Cursor et Windsurf utilisent des fichiers de règles.

Cependant, si l’agent a stocké un grand nombre de faits ou de relations de type « mémo-sémantique », le filtrage devient plus complexe. ChatGPT en est un bon exemple, car il filtre ses données à partir d’un grand ensemble de mémoires spécifiques à l’utilisateur.

Les embeddings vectoriels et/ou les graphes de connaissances sont des techniques d’indexation de mémoires couramment utilisées pour faciliter le filtrage. Pourtant, le filtrage des mémoires reste un défi. Lors de la conférence AIEngineer World Expo, Simon Willison a partagé un exemple où le filtrage des mémoires a échoué : ChatGPT a obtenu des informations sur sa localisation et les a accidentellement injectées dans l’image qu’il demandait. Cette récupération de mémoire inattendue peut donner à certains utilisateurs l’impression que la fenêtre contextuelle « ne leur appartient plus » !

Outils (Tools)

Les agents doivent utiliser des outils, mais si trop d’outils sont proposés, ils risquent d’être submergés. C’est généralement dû à un chevauchement potentiel des descriptions d’outils, ce qui confond le modèle lors du choix de l’outil à utiliser. Une méthode consiste à appliquer RAG (Récupération Augmentée par Génération) aux descriptions d’outils pour en récupérer les plus pertinentes selon leur similarité sémantique. Des études récentes ont montré que cette méthode pouvait tripler la précision des choix d’outils.

Connaissances (Knowledge)

La récupération augmentée par génération (RAG) est elle-même un vaste sujet et peut constituer un défi central de l’ingénierie du contexte. Les agents codants sont l’un des meilleurs exemples de la RAG dans les applications de production à grande échelle. Varun de Windsurf résume très bien certains des défis :

Indexer du code ≠ récupérer le contexte… Ce que nous faisons, c’est analyser le code à l’aide d’un AST (arbre de syntaxe abstrait) et diviser en frontières sémantiquement significatives… Mais à mesure que la taille du code augmente, la recherche par embeddings vectoriels devient peu fiable… Nous devons compter sur une combinaison de plusieurs techniques, comme grep/recherche de fichiers, récupération basée sur des graphes de connaissances, et… une étape de réordonnancement, où le contexte est classé selon sa pertinence.

Compresser le Contexte

Compresser le contexte signifie ne conserver que les tokens nécessaires à l’exécution de la tâche.

Résumé du Contexte (Context Summarization)

Les interactions avec les agents peuvent s’étendre sur des centaines de tours, en utilisant des outils qui consomment beaucoup de tokens. Résumer est une méthode courante pour relever ces défis. Si vous avez utilisé Claude Code, vous avez déjà vu son application pratique. Lorsque l’utilisation de la fenêtre contextuelle dépasse 95 %, Claude Code exécute une « compression automatique », résumant l’ensemble de l’interaction de l’utilisateur avec l’agent. Cette compression du parcours de l’agent peut adopter plusieurs stratégies, comme le résumé récursif ou le résumé hiérarchique.

Intégrer des étapes de résumé au moment opportun dans la conception des agents est également très utile. Par exemple, cela peut être utilisé pour post-traiter certains appels d’outils (en particulier des outils ayant une forte consommation de tokens, comme les outils de recherche). De plus, Cognition a mentionné effectuer des résumés aux frontières de transition entre agents afin de réduire la consommation de tokens lors du transfert de connaissances. Il peut être difficile de capturer certains événements ou décisions spécifiques en résumé. Pour cela, Cognition a utilisé un modèle de fine-tuning, soulignant le travail considérable que cette étape peut nécessiter.

Élagage du Contexte (Context Trimming)

Les résumés utilisent souvent des LLM pour extraire les segments de contexte les plus pertinents, tandis que l’élagage ressemble davantage à un filtrage ou, comme l’a dit Drew Breunig, à une « taille » du contexte. Cela peut emprunter des règles heuristiques codées, comme supprimer les messages plus anciens d’une liste de messages. Drew a également mentionné Provence, un élagage contextuel entraîné pour des tâches de questions-réponses.

Isoler le Contexte

Isoler le contexte signifie diviser le contexte afin d’aider l’agent à exécuter sa tâche.

Multi-agents

L’une des formes les plus populaires d’isolation du contexte consiste à le répartir entre plusieurs sous-agents. L’une des motivations de la bibliothèque Swarm d’OpenAI est la « séparation des points de focus », où une équipe d’agents gère des sous-tâches. Chaque agent a son propre ensemble d’outils, des instructions et des fenêtres contextuelles indépendantes.

Le système de recherche multi-agents d’Anthropic apporte des preuves solides à cet égard : plusieurs agents ayant des contextes indépendants se montrent plus performants qu’un seul agent, en grande partie parce que la fenêtre contextuelle de chaque sous-agent peut se concentrer sur une sous-tâche plus étroite. Comme le mentionne son blog :

Les sous-agents fonctionnent en parallèle avec leurs propres fenêtres contextuelles, explorant différents aspects d’un problème.

Cependant, les multi-agents rencontrent également des défis, y compris la consommation de tokens (par exemple, Anthropic a rapporté que son utilisation de tokens est 15 fois supérieure à celle de la conversation), la nécessité d’une ingénierie des prompts soignée pour planifier le travail des sous-agents, et des problèmes de coordination entre les sous-agents.

Isolement du Contexte par Environnements (Context Isolation with Environments)

Le projet Deep Research de HuggingFace montre un autre exemple fascinant d’isolement du contexte. La plupart des agents utilisent des appels d’outils API qui retournent des objets JSON (paramètres des outils), puis les transmettent aux outils (comme l’API de recherche) pour obtenir des retours (comme des résultats de recherche). HuggingFace opte pour un CodeAgent, qui génère directement le code pour le nécessaire appel d’outil. Ce code est ensuite exécuté dans un environnement sandbox. Seul le contexte spécifique de l’appel d’outil (comme la valeur retournée) est renvoyé au LLM.

Cela permet de garder le contexte isolé de l’environnement vis-à-vis du LLM. Hugging Face souligne que c’est une excellente méthode pour isoler des objets consommant beaucoup de tokens :

Les Code Agents sont capables de mieux gérer l’état… Besoin de conserver des images/son/données pour une utilisation ultérieure ? Aucun problème, il suffit de les affecter en tant que variable, et vous pourrez l’utiliser plus tard.

État

Il convient de mentionner que l’objet d’état d’exécution de l’agent est également un bon moyen d’isoler le contexte. Cela peut fonctionner comme un sandbox. L’objet d’état peut avoir un schéma (Schema, par exemple un modèle Pydantic) contenant des champs pouvant être écrits dans le contexte. Un champ dans le schéma (comme messages) peut être exposé au LLM à chaque interaction de l’agent, tandis que d’autres champs peuvent conserver les informations isolées pour une utilisation plus sélective.

Conclusion

Les modèles d’ingénierie du contexte pour les agents continuent d’évoluer, mais nous pouvons les regrouper en quatre catégories principales : Écrire, Filtrer, Comprimer, Isoler :

• • Écrire le contexte signifie conserver des informations en dehors de la fenêtre contextuelle pour utilisation lors de l’exécution de la tâche par l’agent.
• • Filtrer le contexte signifie attirer les informations nécessaires dans la fenêtre contextuelle pour aider l’agent à exécuter sa tâche.
• • Comprimer le contexte signifie ne conserver que les tokens nécessaires à l’exécution de la tâche.
• • Isoler le contexte signifie diviser le contexte afin d’aider l’agent à exécuter sa tâche.

Comprendre et appliquer ces modèles est le cœur du travail actuel de construction d’agents IA efficaces.

• Das Potenzial von KI-Agenten hängt nicht nur von der Modellgröße ab, sondern auch von der Kunst des „Kontextmanagements“. Es ist vergleichbar mit der Konfiguration des Arbeitsspeichers (RAM) für die CPU und bestimmt die Tiefe und Effizienz des Denkens des Agenten.
• Das Kontextfenster ist kein Mülleimer: Eine Informationsüberlastung kann zu „Toxifizierung“, Störungen und Verwirrungen bei den Entscheidungen der KI führen. Präzision ist weitaus wichtiger als eine Fülle von Daten.
• Fortgeschrittene Benutzer verwalten den Kontext der KI mit der vierteiligen Strategie von „Schreiben, Filtern, Komprimieren und Isolieren“, um den begrenzten „Arbeitsspeicher“ effizient einzusetzen, was zu Kostensenkungen und Effizienzsteigerungen führt.
• Die Zukunft des Wettbewerbs ist ein Wettbewerb um Systemeffizienz. Die Verwendung einer Multi-Agenten-Architektur zur Isolation von Aufgaben, damit jeder Agent in seinem eigenen kleinen Fenster hervorragende Leistungen erbringt, ist der Schlüssel zum Aufbau komplexer Aufgabensysteme.

Kernzusammenfassung

Agenten führen Aufgaben nicht ohne Kontext aus. Das, was wir „Kontextengineering“ nennen, ist die Kunst und Wissenschaft, die Kontextfenster der Agenten bei der Durchführung jeder Aufgabe präzise mit den richtigen Informationen zu füllen. In diesem Artikel werden die derzeit gängigen Kontextengineering-Strategien zusammengefasst und in einige allgemeine Muster gegliedert.

Kontextengineering (Context Engineering)

Wie Andrej Karpathy treffend bemerkte, sind große Sprachmodelle (LLMs) wie ein „neues Betriebssystem“. LLM ist die CPU, und sein „Kontextfenster“ fungiert als RAM, als Arbeitsgedächtnis des Modells. So wie der RAM begrenzten Speicher hat, unterliegt auch das Kontextfenster eines LLM bei der Verarbeitung verschiedener Kontextquellen einer Kapazitätsgrenze. Eine der zentralen Aufgaben des Betriebssystems ist es, zu verwalten, wie effizient der RAM der CPU genutzt wird, und das „Kontextengineering“ nimmt eine ähnliche Rolle ein. Karpathy fasste dies hervorragend zusammen:

Kontextengineering ist „…die Kunst und Wissenschaft, das Kontextfenster für den nächsten Schritt (der Berechnung) präzise zu füllen.“

Welche Arten von Kontext müssen wir also beim Aufbau von LLM-Anwendungen verwalten? Der umfassende Begriff „Kontextengineering“ umfasst folgende verschiedene Kontextarten:

• • Anweisungen (Instructions) – Eingabeaufforderungen, Gedächtnis, few-shot Beispiele, Werkzeugbeschreibungen usw.
• • Wissen (Knowledge) – Fakten, Erinnerungen usw.
• • Werkzeuge (Tools) – Rückmeldungen zu Werkzeugaufrufen

Kontextengineering für Agenten

In diesem Jahr, mit den verbesserten Fähigkeiten von LLM in den Bereichen Schlussfolgerungen und Werkzeugaufrufe, wächst das Interesse an Agenten. Agenten führen Aufgaben aus, indem sie LLM und Werkzeuge abwechselnd aufrufen, insbesondere bei der Bearbeitung langwieriger komplexer Aufgaben.

Langfristige Aufgaben und die fortlaufende Ansammlung von Rückmeldungen aus Werkzeugaufrufen bedeuten jedoch, dass Agenten oft eine große Anzahl von Tokens verbrauchen. Dies kann zu zahlreichen Problemen führen: der Überschreitung der Kapazitätsgrenze des Kontextfensters, steigenden Kosten und Verzögerungen sowie einer Beeinträchtigung der Leistung des Agenten. Drew Breunig hat klar darauf hingewiesen, dass ein zu langer Kontext zu Leistungsproblemen führen kann, und zwar auf folgende Arten:

• • Kontextvergiftung (Context Poisoning): Wenn Halluzinationen (falsche Informationen) in den Kontext gelangen.
• • Kontextlenkung (Context Distraction): Wenn überflüssige Kontextinformationen die ursprünglichen Trainingskenntnisse des Modells überlagern.
• • Kontextverwirrung (Context Confusion): Wenn irrelevante Kontextinformationen die Antworten des Modells beeinflussen.
• • Konflikte im Kontext (Context Clash): Wenn unterschiedliche Teile des Kontextes sich widersprechen.

Angesichts dieser Probleme hebt die Firma Cognition AI die Wichtigkeit des Kontextengineerings hervor:

„Kontextengineering“ … ist tatsächlich die oberste Aufgabe für Bauingenieure von KI-Agenten.

Das Unternehmen Anthropic betont ebenfalls:

Agenten müssen oft Hunderte von Runden von Dialogen führen, was von uns eine sorgfältige Strategie des Kontextmanagements erfordert.

Wie gehen die heutigen Entwickler also mit dieser Herausforderung um? Ich habe die bestehenden Methoden in vier Hauptkategorien gegliedert – Schreiben (Write), Filtern (Select), Komprimieren (Compress) und Isolieren (Isolate) – und werde jeweils Beispiele anführen.

Kontext Schreiben (Write Context)

Das Schreiben von Kontext bedeutet, Informationen außerhalb des Kontextfensters zu speichern, um sie bei der Aufgabenerfüllung durch den Agenten zu nutzen.

Scratchpads (Temporäre Notizen)

Menschen machen beim Lösen von Problemen Notizen, um sich an relevante Informationen zu erinnern, die sie bei zukünftigen Aufgaben benötigen. Agenten erlangen zunehmend diese Fähigkeiten! Das Führen von Notizen in einem „Scratchpad“ stellt eine Möglichkeit dar, Informationen während der Aufgabenerfüllung des Agenten persistent zu speichern. Der zentrale Gedanke ist, Informationen außerhalb des Kontextfensters zu halten, gleichzeitig aber jederzeit für den Agenten verfügbar zu machen. Das Multi-Agenten-Forschungssystem von Anthropic bietet ein klares Beispiel:

Der „Hauptforscher“ denkt zunächst nach, wie er das Problem lösen kann, und speichert seinen Plan im „Gedächtnis“, um den Kontext zu persistent zu halten, da das Kontextfenster möglicherweise über 200.000 Tokens hinaus abgeschnitten werden kann, was das Bewahren des Plans entscheidend macht.

Die Implementierung von Scratchpads kann auf verschiedene Weise erfolgen. Sie können ein einfacher Werkzeugaufruf sein, wie das Schreiben in eine Datei; oder ein Feld in einem Laufzeitstatusobjekt, das während der gesamten Sitzung konstant bleibt. In jedem Fall ermöglicht ein Scratchpad dem Agenten, nützliche Informationen zu speichern, um die Aufgaben besser zu erledigen.

Erinnerungen (Memories)

Scratchpads helfen Agenten, Aufgaben in einer einzelnen Sitzung zu lösen, aber manchmal müssen Agenten Informationen über mehrere Sitzungen hinweg behalten. Das Reflexionsmodell hat die Idee eingeführt, nach jeder Runde des Agenten zu reflektieren und diese selbst generierten Erinnerungen wiederzuverwenden. Das Modell „Generative Agents“ kann regelmäßig Erinnerungen aus dem Feedback vergangener Agenten generieren.

Diese Konzepte wurden in beliebten Produkten wie ChatGPT, Cursor und Windsurf implementiert. Sie verfügen über Mechanismen zur automatischen Generierung langfristiger Erinnerungen, basierend auf der Interaktion zwischen dem Benutzer und dem Agenten.

Kontext Filtern (Select Context)

Das Filtern von Kontext bedeutet, erforderliche Informationen in das Kontextfenster zu ziehen, um dem Agenten bei der Aufgabenerfüllung zu helfen.

Scratchpads (Temporäre Notizen)

Der Mechanismus zum Filtern von Kontext aus einem Scratchpad hängt von dessen Implementierung ab. Wenn es ein Werkzeug ist, kann der Agent es einfach durch einen Werkzeugaufruf abrufen. Wenn es Teil des Laufzeitstatus des Agenten ist, können Entwickler selektiv bestimmte Teile des Status bei jedem Schritt dem Agenten zugänglich machen. Dies ermöglicht eine präzise Kontrolle beim Bereitstellen von Scratchpad-Kontext für die folgenden Runden beim LLM.

Erinnerungen (Memories)

Wenn Agenten in der Lage sind, Erinnerungen zu speichern, benötigen sie auch die Fähigkeit, solche Erinnerungen auszuwählen, die für die aktuelle Aufgabe relevant sind. Dies ist aus mehreren Gründen nützlich: Agenten können wenige Beispielalso gen (Situationsgedächtnis) auswählen, um das erwartete Verhaltensmuster zu lernen; sie können Anweisungen (Programmerinnerungen) auswählen, um ihr eigenes Verhalten zu leiten; oder Fakten (semantische Erinnerungen) auswählen, um der Aufgabe den relevanten Kontext zu geben.

Eine große Herausforderung besteht darin, sicherzustellen, dass die gefilterten Erinnerungen relevant sind. Einige beliebte Agenten verwenden nur einen kleinen Teil fester Dateien, die immer ins Kontext geladen werden. Zum Beispiel speichern viele Code-Agenten Anweisungen (“Programmerinnerungen”) oder in bestimmten Fällen Beispiele (“Situationsgedächtnis”) in Dateien. Claude Code verwendet CLAUDE.md, während Cursor und Windsurf Regeldateien nutzen.

Wenn Agenten jedoch eine große Anzahl an Fakten oder Beziehungen (z.B. „semantische Erinnerungen“) gespeichert haben, wird das Filtern komplizierter. ChatGPT ist ein gutes Beispiel, das aus einer Vielzahl von benutzerspezifischen Erinnerungen speichert und filtert.

Vektor-Embedding und/oder Wissensgraphen sind gängige Techniken für die Indizierung von Erinnerungen, um beim Filtern zu helfen. Dennoch bleibt das Filtern von Erinnerungen eine Herausforderung. Auf der AIEngineer-Weltausstellung präsentierte Simon Willison ein Beispiel, bei dem das Filtern von Erinnerungen schiefging: ChatGPT holte seine Standortinformationen und injizierte sie unbeabsichtigt in die angeforderte Abbildung. Diese unerwartete oder unerwünschte Erinnerungseinsicht kann bei einigen Benutzern das Gefühl erzeugen, dass das Kontextfenster „nicht mehr ihnen gehört“!

Werkzeuge (Tools)

Agenten müssen Werkzeuge nutzen, aber wenn zu viele Werkzeuge bereitgestellt werden, könnte dies sie überfordern. Oft liegt das daran, dass die Beschreibungen der Werkzeuge überschneiden, was das Modell bei der Auswahl des relevanten Werkzeugs verwirrt. Eine Methode besteht darin, RAG (Retrieval-Augmented Generation) auf die Werkzeugbeschreibungen anzuwenden, um die relevantesten Werkzeuge für die Aufgabe basierend auf semantischer Ähnlichkeit abzurufen. Neuere Studien zeigen, dass diese Methode die Genauigkeit bei der Werkzeugauswahl verdreifachen kann.

Wissen (Knowledge)

Die retrieval-augmentierte Generierung (RAG) ist an sich bereits ein großes Thema und kann zur zentralen Herausforderung des Kontextengineerings werden. Code-Agenten sind eines der besten Beispiele für RAG in großflächigen Produktionsanwendungen. Varun von Windsurf hat einige der Herausforderungen gut zusammengefasst:

Das Indizieren von Code ≠ Kontextabruf… was wir tun, besteht darin, über AST (Abstrakte Syntaxbaum) Code zu analysieren und entlang semantisch sinnvoller Grenzen zu segmentieren… aber mit dem Wachstum der Codebasis wird die Suche nach Vektor-Embeddings als heuristische Abrufmethode unzuverlässig… wir müssen auf eine Kombination verschiedener Techniken zurückgreifen, wie grep/Dateisuche, wissensgrafbasierter Abruf, und… einen Sortierschritt, bei dem die Kontexte nach Relevanz geordnet werden.

Kontext Komprimieren (Compress Context)

Das Komprimieren von Kontext bedeutet, nur die für die Ausführung der Aufgabe erforderlichen Tokens zu behalten.

Kontextzusammenfassung (Context Summarization)

Die Interaktionen von Agenten können sich über Hunderte von Runden erstrecken und eine Vielzahl von Token-verbrauchenden Werkzeugen nutzen. Zusammenfassungen sind gängige Methoden zur Bewältigung dieser Herausforderungen. Wenn Sie Claude Code verwendet haben, haben Sie bereits die reale Anwendung gesehen. Wenn die Nutzung des Kontextfensters 95 % übersteigt, führt Claude Code ein „automatisches Komprimieren“ durch und fasst den gesamten Interaktionsverlauf zwischen Benutzer und Agenten zusammen. Diese Art der Komprimierung der Agenteninteraktionen kann verschiedene Strategien wie rekursive Zusammenfassungen oder hierarchische Zusammenfassungen umfassen.

Das rechtzeitige Einfügen eines Zusammenfassungsschrittes in das Design des Agenten ist ebenfalls nützlich. Zum Beispiel kann es zur Nachbearbeitung von Werkzeugaufrufen verwendet werden (insbesondere von token-intensiven Werkzeugen wie Suchwerkzeugen). Zum Beispiel erwähnt die Firma Cognition, dass sie Zusammenfassungen an den Übergangspunkten zwischen Agenten vorzunehmen, um den Token-Verbrauch während des Wissensaustausches zu minimieren. Wenn es notwendig ist, bestimmte Ereignisse oder Entscheidungen festzuhalten, kann die Zusammenfassung herausfordernd sein. Cognition verwendet dafür ein Feinabstimmungsmodell, was den Aufwand für diese Schritte hervorhebt.

Kontexttrimmen (Context Trimming)

Zusammenfassungen nutzen oft LLMs, um die relevantesten Kontextfragmente zu extrahieren, während das Trimmen eher wie ein Filtern oder wie Drew Breunig es nennt, ein „Beschneiden“ des Kontexts funktioniert. Dies kann durch fest kodierte Heuristikregeln geschehen, wie das Entfernen älterer Nachrichten aus einer Liste. Drew erwähnte auch Provence, einen für Frage-Antwort-Aufgaben trainierten Kontext-Trimmer.

Kontext Isolieren (Isolating Context)

Das Isolieren von Kontext bedeutet, den Kontext zu segmentieren, um dem Agenten bei der Aufgabenerfüllung zu helfen.

Multi-Agenten (Multi-agent)

Eine der populärsten Methoden des Kontextisolierens besteht darin, diesen auf mehrere Unteragenten zu verteilen. Ein Ziel der Swarm-Bibliothek von OpenAI ist es, „Fokussierung zu isolieren“, indem ein Team von Agenten Unteraufgaben bearbeitet. Jeder Agent hat sein spezifisches Set an Werkzeugen, Anweisungen und ein unabhängiges Kontextfenster.

Das Multi-Agenten-Forschungssystem von Anthropic bietet starke Beweise dafür, dass mehrere Agenten mit unabhängigem Kontext besser abschneiden als ein einzelner Agent, da das Kontextfenster jedes Unteragenten sich auf eine engere Unteraufgabe konzentrieren kann. Wie in ihrem Blog beschrieben:

Unteragenten arbeiten parallel mit ihren eigenen Kontextfenstern und erkunden verschiedene Aspekte des Problems.

Natürlich stehen Multi-Agenten auch vor Herausforderungen, einschließlich Token-Verbrauch (zum Beispiel berichtete Anthropic, dass ihr Token-Verbrauch 15-mal so hoch war wie der von Chats), die Notwendigkeit sorgfältiger Prompt-Engineering zur Planung der Aufgabenerfüllung der Unteragenten und Koordinationsprobleme zwischen diesen.

Kontextisolierung mit Umgebungen (Context Isolation with Environments)

Das Deep Researcher-Projekt von HuggingFace zeigt ein weiteres interessantes Beispiel für die Kontextisolierung. Die meisten Agenten verwenden Werkzeugaufrufs-APIs, die JSON-Objekte (Werkzeugparameter) zurückgeben, die dann an Werkzeuge (wie die Such-API) übergeben werden, um Rückmeldungen (wie Suchergebnisse) zu erhalten. HuggingFace dagegen verwendet einen CodeAgent, der direkt den Code mit den erforderlichen Werkzeugaufrufen ausgibt. Diese Codes werden anschließend in einer Sandbox-Umgebung ausgeführt. Der spezifische zurückgegebene Kontext des Werkzeugaufrufs (wie Rückgabewerte) wird dann an das LLM zurückgesendet.

Dies ermöglicht eine Isolation des Kontextes innerhalb der Umgebung vom LLM. Hugging Face merkt an, dass dies eine hervorragende Methode zur Isolation von objekten ist, die eine große Menge an Token verbrauchen:

Code-Agenten können mit Zuständen besser umgehen… Müssen Sie Bilder/Audios/andere Daten speichern, um sie später zu verwenden? Kein Problem, weisen Sie sie einfach als Variable zu, und Sie können sie später verwenden.

Zustand (State)

Es ist erwähnenswert, dass die Laufzeitstatusobjekte von Agenten ebenfalls eine gute Methode zur Isolation des Kontexts darstellen können. Diese können eine ähnliche Funktion wie Sandboxing erfüllen. Statusobjekte können ein Schema entwerfen (z. B. Pydantic-Modell), das Felder umfasst, die in den Kontext geschrieben werden können. Ein Feld im Schema (zum Beispiel messages) kann in jeder Runde der Interaktion des Agenten dem LLM offenbart werden, während das Schema Informationen in anderen Feldern isolieren kann, um eine selektivere Verwendung zu ermöglichen.

Fazit

Die Muster des Kontextengineerings für Agenten entwickeln sich weiterhin, aber wir können die gängigen Methoden in vier Hauptkategorien zusammenfassen – Schreiben, Filtern, Komprimieren und Isolieren:

• • Das Schreiben von Kontext bezieht sich darauf, Informationen außerhalb des Kontextfensters zu speichern, um sie bei der Aufgabenerfüllung durch den Agenten zu verwenden.
• • Das Filtern von Kontext bedeutet, nötige Informationen in das Kontextfenster zu ziehen, um dem Agenten zu helfen.
• • Das Komprimieren von Kontext bedeutet, nur die für die Ausführung der Aufgabe erforderlichen Tokens zu behalten.
• • Das Isolieren von Kontext bedeutet, den Kontext zu segmentieren, um dem Agenten zu helfen.

Das Verständnis und die Anwendung dieser Muster sind die zentralen Aufgaben beim Aufbau effizienter Agenten heute.

• AIエージェントの限界は、モデルのサイズだけでなく、「コンテキスト管理」という技術にも依存しています。これはCPUに対するメモリの設定のようなもので、エージェントの思考の深さと効率を決定します。
• コンテキストウィンドウはゴミ箱ではありません：情報過多は「毒を盛り」、AIの判断を妨げ、混乱させます。正確性は、膨大な量よりもはるかに重要です。
• 熟練者は「書く、選ぶ、圧縮する、隔離する」の4つのテクニックを用いてAIのコンテキストを管理し、限られた「メモリ」を要所に活用しながらコスト削減と効率向上を実現します。
• 未来の競争はシステムの効率性の競争です。複数のエージェントアーキテクチャを用いてタスクを「隔離」し、それぞれのエージェントが自分の小さな窓の中で極限まで達成することが、複雑なタスクシステムの構築における鍵となります。

コア要約

エージェントがタスクを実行するには、コンテキストが不可欠です。いわゆる「コンテキストエンジニアリング」とは、エージェントがタスクを実行する各ステップでそのコンテキストウィンドウに適切な情報を正確に注入する技術と科学のことを指します。この記事では、現在の主流エージェントが採用しているコンテキストエンジニアリングの戦略を、いくつかの一般的なパターンにまとめます。

コンテキストエンジニアリング（Context Engineering）

Andrej Karpathyが述べるように、大規模言語モデル（LLM）は「新しいオペレーティングシステム」のようなものです。LLMがCPUであり、その「コンテキストウィンドウ」がRAMとして機能し、モデルの作業記憶を担っています。RAMの容量が限られているように、LLMのコンテキストウィンドウも様々なコンテキストのソースを処理する際に容量のボトルネックに直面します。オペレーティングシステムの核心的な仕事の一つは、CPUのRAMを効率的に利用する方法を管理することです。「コンテキストエンジニアリング」も同様の役割を果たします。Karpathyはこれを非常に的確にまとめています：

コンテキストエンジニアリングは「……次のステップ（計算）に向けて、コンテキストウィンドウを正確に埋める巧妙な技術と科学です。」

LLMアプリケーションを構築する際には、どのタイプのコンテキストを管理する必要があるのでしょうか？コンテキストエンジニアリングという包括的な概念は、以下の異なるコンテキストタイプを含んでいます：

• • 指示（Instructions） – プロンプト、メモ、少量のサンプル、ツールの説明など
• • 知識（Knowledge） – 事実、メモなど
• • ツール（Tools） – ツール呼び出しのフィードバック情報

エージェント向けコンテキストエンジニアリング

今年、LLMが推論とツール呼び出しの能力を向上させる中で、エージェントへの関心が高まっています。エージェントはLLMとツールを交互に呼び出してタスクを実行し、特に長期間にわたる複雑なタスク処理に優れています。

しかし、長期タスクや累積したツール呼び出しのフィードバックは、エージェントが大量のトークンを消費することを意味します。これは様々な問題を引き起こす可能性があります：コンテクストウィンドウの容量制限を超え、コストと遅延が増加し、エージェントの性能を低下させることもあります。Drew Breunigは、過度なコンテキストが以下の方法で性能問題を引き起こす可能性があることを明確に指摘しました：

• • コンテキスト投毒（Context Poisoning）：幻覚（誤った情報）がコンテキストに入る場合。
• • コンテキスト干渉（Context Distraction）：コンテキスト情報が多すぎて、モデルの元々のトレーニング知識が埋もれてしまう場合。
• • コンテキスト混乱（Context Confusion）：無関係なコンテキスト情報がモデルの応答に影響を与える場合。
• • コンテキスト衝突（Context Clash）：コンテキストの異なる部分が互いに矛盾する場合。

これらの問題を考え、Cognition AI社はコンテキストエンジニアリングの重要性を強調しています：

“コンテキストエンジニアリング”……実際はAIエージェントを構築するエンジニアの最重要な任務です。

Anthropic社も明確に指摘しています：

エージェントは通常、数百ラウンドの対話を必要とします。そのため、慎重なコンテキスト管理戦略を採用することが求められます。

では、今日の開発者はこの課題にどう対処しているのでしょうか？私は既存の方法を4つの大カテゴリ——書き込み（Write）、選択（Select）、圧縮（Compress）、隔離（Isolate）——にまとめ、それぞれ例を挙げて説明します。

コンテキストへの書き込み（Write Context）

コンテキストへの書き込みは、情報をコンテキストウィンドウの外に保存し、エージェントのタスク実行時に使用できるようにすることを指します。

スクラッチパッド（Scratchpads）

人間が問題を解決する際にはノートを取り、将来関連するタスクを処理する際に使うことを記憶します。エージェントもこの能力を徐々に獲得しています！「スクラッチパッド」を通じてメモを取ることは、エージェントがタスクを実行中に情報を持続的に保持する方法の一つです。その核心的な考え方は、情報をコンテキストウィンドウの外に保存しつつ、エージェントがいつでも取り出せるようにすることです。Anthropicの多エージェント研究システムはその明確な例を提供しています：

「チーフリサーチャー」は最初に問題を解決する方法を考え、その計画を「メモリ」に保存し、コンテキストを持続化します。なぜなら、コンテキストウィンドウが20万トークンを超えると切り捨てられる恐れがあるからです。計画の保持が極めて重要です。

スクラッチパッドの実装方法はいくつかあります。単純なツール呼び出しでファイルに書き込むこともあれば、ランタイムの状態オブジェクトのフィールドとしてセッション全体にわたって保持されることもあります。いずれの場合でも、スクラッチパッドはエージェントが有用な情報を保存し、タスクをより良く完了させることを可能にします。

記憶（Memories）

スクラッチパッドはエージェントが単一のセッションでタスクを解決するのを助けますが、時にはエージェントが複数のセッションを跨いで物事を記憶する必要があります。Reflexionモデルは各ラウンドのエージェントの行動後に反省し、それらの自己生成記憶を再利用するという考えを導入しました。Generative Agentsモデルは、過去のエージェントのフィードバックを定期的に合成して記憶を生成します。

これらの概念はChatGPT、Cursor、Windsurfなどの人気製品に適用されています。これらはすべて、ユーザーとエージェントの相互作用に基づいて自動生成される長期記憶を持つメカニズムを備えています。

コンテキストのフィルタリング（Select Context）

コンテキストのフィルタリングは、必要な情報をコンテキストウィンドウに調整し、エージェントがタスクを実行できるようにすることを指します。

スクラッチパッド（Scratchpad）

スクラッチパッドからコンテキストをフィルタリングするメカニズムは、その実装方法によって異なります。ツールであれば、エージェントはただツール呼び出しを使って読み取るだけです。もしそれがエージェントのランタイム状態の一部であれば、開発者は各ステップで状態の特定部分を選択的にエージェントに提示することができます。これは、以降のラウンドでLLMに対してスクラッチパッドコンテキストを提示する際に非常に細かなコントロールを提供します。

記憶（Memories）

もしエージェントが記憶を保存する能力を持っている場合、現在のタスクに関連する記憶を選択する能力も必要です。これにはいくつかの利点があります。エージェントは期待される行動パターンを学ぶために少サンプルの例（シナリオメモリ）を選択したり、自己の行動を導くために指示（プログラムメモリ）を選んだりすることができます。また、タスクに関連する背景を提供するために事実（セマンティックメモリ）を選ぶことも可能です。

一つの大きな課題は、選ばれた記憶が関連性を持つことを確認することです。一部の人気のあるエージェントは、固定されたファイルの一部しか使用せず、これらのファイルは常にコンテキストにロードされることがあります。例えば、多くのコードエージェントは指示（「プログラムメモリ」）を保存するためのファイルを使用したり、場合によっては例（「シナリオメモリ」）を保存したりします。Claude CodeはCLAUDE.mdを使用し、CursorやWindsurfはルールファイルを使用しています。

しかし、エージェントが大量の（例えば「セマンティックメモリ」タイプの）事実や関係を保存している場合、フィルタリングはより困難になります。ChatGPTは良い例であり、大量のユーザー専用の記憶から情報を保存およびフィルタリングします。

ベクトル埋め込みや知識グラフは、フィルタリングを支援するためによく使用される記憶インデックステクニックです。それでも、記憶のフィルタリングは依然として挑戦に満ちています。AI Engineer World Expoで、Simon Willisonは記憶フィルタリングの失敗例を共有しました：ChatGPTが彼の位置情報を記憶から取得し、彼が要求した画像に意図せず注入したのです。このような意外な、または望まれない記憶検索は、一部のユーザーにコンテキストウィンドウが「彼ら自身のものではなくなった」と感じさせることがあります！

ツール（Tools）

エージェントはツールを使用する必要がありますが、提供されるツールが多すぎると、彼らは圧倒されるかもしれません。これは通常、ツールの説明が重複するため、モデルがどのツールを選ぶべきか迷わせてしまうことから来ます。一つの方法は、ツールの説明にRAG（Retrieval-Augmented Generation）を適用し、セマンティックな類似性に基づいてタスクに最も関連するツールを取得することです。最近のいくつかの論文では、この方法が工具選択の正確性を3倍向上させることが示されています。

知識（Knowledge）

RAG自体は広大なトピックであり、コンテキストエンジニアリングの核心的な課題になり得ます。コードエージェントは大規模な生産アプリケーションにおけるRAGの最良の例の一つです。WindsurfのVarunは、その中のいくつかの課題をうまく要約しています：

コードのインデックス化 ≠ コンテキスト検索……私たちがやっているのは、AST（抽象構文木）でコードを解析し、セマンティックな境界に沿ってブロック化することです……しかし、コードベースの規模が増えるにつれて、ベクトル埋め込み検索は検索の啓発的手法としての信頼性を失います……私たちは、grep/ファイル検索、知識グラフに基づく検索、および……関連性の順位付けを行う再ランキングステップなど、さまざまな技術の組み合わせに依存しなければなりません。

コンテキストを圧縮する（Compress Context）

コンテキストを圧縮するとは、タスクの実行に必要なトークンのみを保持することです。

コンテキスト要約（Context Summarization）

エージェントの対話は数百ラウンドにわたる可能性があり、大量のトークンを消費するツールを使用します。要約はこれらの課題に対処するための一般的な方法です。Claude Codeを使用したことがあれば、その実際の適用を目にしたことがあるでしょう。コンテキストウィンドウの使用率が95%以上に達すると、Claude Codeは「自動圧縮」を実行し、ユーザーとエージェントとの完全な対話の軌跡を要約します。このエージェントの軌跡の圧縮はいくつかの戦略を採用でき、再帰的な要約や階層的な要約が含まれます。

エージェントの設計において適時に要約ステップを追加することも有益です。たとえば、特にトークンを大量に消費するツール（検索ツールのような）の呼び出し後処理に利用できます。特定のイベントや意思決定をキャッチする必要がある場合、要約は挑戦的なものになる可能性があります。このためにCognitionは微調整モデルを使用し、このステップに多大な作業投入が必要であることを浮き彫りにしています。

コンテキストトリミング（Context Trimming）

要約は通常LLMを用いて最も関連性の高いコンテキスト片を抽出しますが、トリミングはフィルタリングのようなもので、あるいはDrew Breunigが言うように「剪定」することです。これは、ハードコーディングされたヒューリスティックルールを用い、メッセージリストから古いメッセージを削除するなどの方法で行うことができます。Drewはまた、質問応答タスク向けに訓練されたコンテキストトリッパーであるProvenceについて言及しています。

コンテキストを隔離する（Isolating Context）

コンテキストを隔離するとは、コンテキストを分割し、エージェントがタスクを実行できるようにすることを指します。

複数エージェント（Multi-agent）

コンテキストを隔離する最も一般的な方法の一つは、それを複数のサブエージェントに分散させることです。OpenAIのSwarmライブラリの動機の一つは「注意点の分離」であり、サブタスクを処理するためのエージェントチームを構成することです。各エージェントは特定のツールセット、指示、独立したコンテキストウィンドウを持っています。

Anthropicの多エージェント研究システムは、独立したコンテキストを持つ複数のエージェントが単一のエージェントよりも優れたパフォーマンスを示すことを強力に証明しています。これは各サブエージェントのコンテキストウィンドウがより狭いサブタスクに集中できるためです。彼らのブログに記載されているように：

サブエージェントはそれぞれのコンテキストウィンドウを持ち並行して動作し、問題のさまざまな側面を探求します。

もちろん、複数エージェントにも課題があり、トークン消費など（例えば、Anthropicはそのトークン使用量が会話の15倍であると報告）や、サブエージェントの作業を計画するための注意深いプロンプトエンジニアリングが求められ、サブエージェント間の調整の問題もあります。

環境を通じたコンテキスト隔離（Context Isolation with Environments）

HuggingFaceの深層学習研究者プロジェクトは、別の興味深いコンテキスト隔離の例を示しています。ほとんどのエージェントはツール呼び出しAPIを使用し、これらのAPIはJSONオブジェクト（ツールパラメータ）を返し、次にツール（例えば検索API）にフィードバック（検索結果など）を取得するために渡されます。一方、HuggingFaceは CodeAgentを使用し、必要なツール呼び出しのコードを直接出力します。このコードはその後、サンドボックス環境で実行されます。ツール呼び出しからの特定のコンテキスト（例えば戻り値）は、その後LLMに返されます。

これにより、LLMと環境内でコンテキストが隔離されます。Hugging Faceは、これは大量のトークンを消費するオブジェクトを隔離する優れた方法であると指摘しています：

Code Agentsは状態をより適切に取り扱うことができます……画像や音声、その他のデータを保存する必要がありますか？問題ありません、変数として代入すれば、後で使用できます。

状態（State）

注目すべきは、エージェントのランタイム状態オブジェクトもコンテキストを隔離する良い方法であるという点です。これはサンドボックスのような作用を果たします。状態オブジェクトは、コンテキストに書き込むことができるフィールドを含むスキーマ（例えばPydanticモデルなど）を設計可能です。スキーマ中のあるフィールド（例えばmessages）は、エージェントの各インタラクションラウンドでLLMに対して公開されますが、そのスキーマは他のフィールド内で情報を隔離し、より選択的に使用できるようにします。

結論

エージェントのコンテキストエンジニアリングのパターンはまだ進化を続けていますが、私たちは一般的な方法を次の4つのカテゴリにまとめることができます——書き込み、選択、圧縮、および隔離：

• • コンテキストへの書き込みとは、情報をコンテキストウィンドウの外に保存し、エージェントのタスク実行時に使用できるようにすることです。
• • コンテキストのフィルタリングとは、必要な情報をコンテキストウィンドウに調整し、エージェントがタスクを実行するのを手助けすることです。
• • コンテキストの圧縮とは、タスクの実行に必要なトークンのみを保持することです。
• • コンテキストの隔離とは、コンテキストを分割し、エージェントがタスクを実行できるようにすることです。

これらのパターンを理解し、適用することは、今日の効率的なエージェントを構築するための核心的な取り組みです。

• Il limite degli agenti AI non dipende solo dalla dimensione del modello, ma anche dall’abilità nella “gestione del contesto”. È come configurare la memoria per una CPU, determinando la profondità e l’efficienza del pensiero dell’agente.
• La finestra di contesto non è un bidone della spazzatura: il sovraccarico di informazioni può “contaminare”, disturbare e confondere il giudizio dell’AI. La precisione è molto più importante della quantità.
• Gli esperti usano le quattro tecniche di “Scrittura, Filtraggio, Compressione e Isolamento” per gestire il contesto dell’AI, massimizzando l’uso della “memoria” limitata per ottenere una riduzione dei costi e un aumento dell’efficienza.
• La competizione futura sarà una competizione di efficienza dei sistemi. Isolare i compiti usando un’architettura multi-agente, permettendo a ciascun agente di dare il massimo nella propria piccola finestra, è la chiave per costruire sistemi complessi di compiti.

Riepilogo Chiave

Gli agenti (Agent) svolgono i loro compiti grazie al contesto (Context). L’ingegneria del contesto è l’arte e la scienza di iniettare informazioni appropriate nella finestra di contesto dell’agente in ogni fase del suo compito. In questo articolo, sintetizzeremo le strategie di ingegneria del contesto adottate dagli attuali agenti di punta in alcune categorie generali.

Ingegneria del Contesto

Come ha detto Andrej Karpathy, i modelli linguistici di grandi dimensioni (LLM) sono come un “nuovo sistema operativo”. LLM è la CPU, mentre la sua “finestra di contesto” funge da RAM, rappresentando la memoria di lavoro del modello. Proprio come la capacità della RAM è limitata, la finestra di contesto di un LLM affronta anche delle limitazioni di capacità quando si tratta di gestire fonti diverse di contesto. Uno dei compiti principali di un sistema operativo è gestire come utilizzare efficacemente la RAM della CPU, e “l’ingegneria del contesto” svolge un ruolo simile. Karpathy riassume benissimo questo concetto:

L’ingegneria del contesto è “…un’arte e scienza sofisticata per riempire con precisione la finestra di contesto per il passo successivo (di calcolo).”

Quando costruiamo applicazioni LLM, quali tipi di contesto dobbiamo gestire? Il concetto complessivo di ingegneria del contesto include i seguenti diversi tipi di contesto:

• • Istruzioni (Instructions) – frasi di invito, memoria, esempi con pochi campioni, descrizioni degli strumenti, ecc.
• • Conoscenza (Knowledge) – fatti, memoria, ecc.
• • Strumenti (Tools) – informazioni di feedback sulle chiamate di strumenti.

Ingegneria del Contesto per Agenti

Quest’anno, con il miglioramento delle capacità di ragionamento e di chiamata di strumenti degli LLM, l’interesse per gli agenti è cresciuto notevolmente. Gli agenti eseguono compiti alternando chiamate a LLM e strumenti, mostrano particolari abilità nel gestire compiti complessi a lungo termine.

Tuttavia, i compiti a lungo termine e il feedback accumulato dalle chiamate agli strumenti significano che gli agenti tendono a consumare un gran numero di token. Questo può dar luogo a vari problemi: superare i limiti di capacità della finestra di contesto, aumentando i costi e i ritardi, e persino riducendo le prestazioni degli agenti. Drew Breunig ha chiaramente evidenziato che un contesto eccessivamente lungo può portare a problemi di prestazione in vari modi:

• • Contaminazione del Contesto (Context Poisoning): quando informazioni errate (hallucination) entrano nel contesto.
• • Distrazione del Contesto (Context Distraction): quando troppi elementi di contesto sommersano la conoscenza originale addestrata nel modello.
• • Confusione del Contesto (Context Confusion): quando informazioni di contesto irrilevanti influenzano le risposte del modello.
• • Conflitto del Contesto (Context Clash): quando le diverse parti del contesto si contraddicono.

Considerando questi problemi, la Cognition AI sottolinea l’importanza dell’ingegneria del contesto:

“L’ingegneria del contesto”… è, di fatto, il compito principale per gli ingegneri che costruiscono agenti AI.

Anche la Anthropic ha affermato chiaramente:

Gli agenti spesso hanno bisogno di condurre centinaia di turni di dialogo, il che richiede l’adozione di strategie di gestione del contesto prudenti.

Come stanno affrontando l’attuale sfida gli sviluppatori? Ho riassunto i metodi esistenti in quattro categorie: **Scrittura (Write), Filtraggio (Select), Compressione (Compress) e Isolamento (Isolate)**—e fornirò esempi per ciascuna.

Scrivere il Contesto (Write Context)

Scrivere il contesto significa conservare informazioni al di fuori della finestra di contesto per l’uso durante l’esecuzione di un compito da parte dell’agente.

Area di Scratch (Scratchpads)

Quando gli esseri umani risolvono problemi, prendono appunti e ricordano alcune cose da usare in compiti futuri. Anche gli agenti stanno acquisendo gradualmente queste capacità! Prendere appunti in un’“area di scratch” è un modo per persistente informazioni durante un compito effettuato da un agente. L’idea principale è di conservare informazioni al di fuori della finestra di contesto, ma accessibili all’agente in qualsiasi momento. Il sistema di ricerca multi-agente di Anthropic offre un chiaro esempio:

Il “capo ricercatore” inizia a riflettere su metodi per risolvere un problema e salva il piano nella “memoria” per permanere il contesto, poiché una volta superati i 200.000 token, il contesto potrebbe essere troncato e la conservazione del piano è cruciale.

Esistono vari modi per implementare un’area di scratch. Può essere una semplice chiamata di strumento, come scrivere un file; oppure un campo nello stato di runtime, che rimane invariato per l’intero periodo della sessione. Indipendentemente dal metodo, l’area di scratch consente all’agente di memorizzare informazioni utili per completare meglio il compito.

Memoria (Memories)

L’area di scratch aiuta l’agente a risolvere compiti all’interno di una singola sessione, ma a volte l’agente deve ricordare informazioni attraverso più sessioni. Il modello Reflexion ha introdotto l’idea di riflessione dopo ogni azione dell’agente e il riutilizzo di queste memorie generate autonomamente. Il modello Generative Agents consiglie di sintetizzare periodicamente memorie da un insieme di feedback del passato agente.

Questi concetti sono stati applicati in prodotti popolari come ChatGPT, Cursor e Windsurf. Tutti hanno meccanismi per generare automaticamente memorie a lungo termine basate su interazioni tra l’utente e l’agente.

Filtrare il Contesto (Select Context)

Filtrare il contesto significa portare le informazioni necessarie nella finestra di contesto per aiutare l’agente nell’esecuzione del compito.

Area di Scratch (Scratchpad)

Il meccanismo di filtraggio del contesto dall’area di scratch dipende da come è stato implementato. Se è uno strumento, l’agente può leggerlo semplicemente attraverso una chiamata a uno strumento. Se è parte dello stato di runtime dell’agente, gli sviluppatori possono selettivamente esporre alcune parti dello stato all’agente in ogni fase. Questo fornisce un controllo fine su come fornire contesto dall’area di scratch all’LLM nei turni successivi.

Memoria (Memories)

Se l’agente è in grado di memorizzare, ha anche la necessità di selezionare memorie pertinenti al compito attuale. Questo è molto utile per diversi motivi: l’agente può scegliere esempi con pochi campioni (memoria contestuale) per apprendere schemi comportamentali attesi; può scegliere istruzioni (memoria programmatica) per guidare il proprio comportamento; oppure può selezionare fatti (memoria semantica) fornisce un contesto rilevante per il compito.

Una grande sfida è garantire che le memorie filtrate siano pertinenti. Alcuni agenti popolari utilizzano solo una piccola parte di file fissi che vengono sempre caricati nel contesto. Ad esempio, molti agenti di codice utilizzano file per salvare istruzioni (memoria programmatica) o, in alcuni casi, salvare esempi (memoria contestuale). Claude Code utilizza CLAUDE.md, mentre Cursor e Windsurf utilizzano file di regole.

Tuttavia, se un agente conserva un gran numero di fatti o relazioni (ad esempio di tipo “memoria semantica”), il filtraggio diventa più complesso. ChatGPT è un buon esempio, poiché memorizza e filtra da una vasta gamma di memorie esclusive per l’utente.

L’uso di embeddings vettoriali e/o graph di conoscenza è una tecnica comune di indicizzazione della memoria per assistere il filtraggio. Tuttavia, il filtraggio della memoria rimane pieno di sfide. Alla AI Engineer World Expo, Simon Willison ha condiviso un esempio in cui il filtraggio della memoria ha sbagliato: ChatGPT ha recuperato la sua posizione dalla memoria e l’ha inavvertitamente iniettata nell’immagine richiesta. Questo recupero di memoria inaspettato o indesiderato può far sentire ad alcuni utenti che la finestra di contesto “non gli appartiene più”!

Strumenti (Tools)

Gli agenti devono utilizzare strumenti, ma se gli strumenti forniti sono troppi, possono essere sopraffatti. Questo è spesso causato da descrizioni di strumenti che possono sovrapporsi, portando il modello a confondersi nella scelta dello strumento da utilizzare. Un metodo è applicare RAG (Retrieve-Augmented Generation) alle descrizioni degli strumenti, per recuperare gli strumenti più rilevanti per il compito in base alla similarità semantica. Alcuni articoli recenti dimostrano che questo approccio può triplicare la precisione nella scelta degli strumenti.

Conoscenza (Knowledge)

Il Retrieve-Augmented Generation (RAG) è di per sé un ampio argomento ed è una delle principali sfide dell’ingegneria del contesto. Gli agenti di codice sono uno dei migliori esempi dell’applicazione di RAG su larga scala. Varun di Windsurf ha riassunto bene alcune di queste sfide:

Indicizzare il codice ≠ Recuperare il contesto… ciò che stiamo facendo è analizzare il codice tramite AST (Abstract Syntax Tree) e suddividerlo lungo confini semanticamente significativi… Ma con la crescita delle dimensioni del codice, la ricerca tramite embeddings vettoriali come metodo di recupero diventa inaffidabile… dobbiamo fare affidamento su una combinazione di diverse tecniche, come grep/ricerca di file, recupero basato su graph di conoscenza e… un passaggio di riordino in cui il contesto viene ordinato per rilevanza.

Comprimere il Contesto (Compress Context)

Comprimere il contesto significa mantenere solo i token necessari all’esecuzione del compito.

Sintesi del Contesto (Context Summarization)

Le interazioni degli agenti possono coprire centinaia di turni e utilizzare strumenti che consumano un gran numero di token. La sintesi è un metodo comune per affrontare queste sfide. Se hai mai usato Claude Code, avrai visto la sua applicazione pratica. Quando l’utilizzo della finestra di contesto supera il 95%, Claude Code esegue la “compressione automatica”, sintetizzando l’intera traiettoria di interazione tra utente e agente. Questa sintesi della traiettoria dell’agente può comportare diverse strategie, come la sintesi ricorsiva o la sintesi a livelli.

Integrare passaggi di sintesi nel design di un agente è anche molto utile. Ad esempio, può essere utile per elaborare dopo determinate chiamate di strumenti (specialmente strumenti come quelli di ricerca che consumano molti token). Inoltre, la Cognition ha menzionato la sintesi ai confini della transizione tra agenti, per ridurre il consumo di token durante il processo di trasmissione delle conoscenze. Se è necessario catturare eventi o decisioni specifiche, la sintesi può presentare delle sfide. Per questo motivo, la Cognition utilizza un modello fine-tuned, evidenziando l’importante lavoro necessario in questa fase.

Potatura del Contesto (Context Trimming)

La sintesi utilizza tipicamente LLM per estrarre i frammenti di contesto più rilevanti, mentre la potatura si assomiglia più a un filtro o, come ha detto Drew Breunig, a una “potatura” del contesto. Questo può comportare regole euristiche codificate, come rimuovere messaggi più vecchi dalla lista di messaggi. Drew ha anche menzionato Provence, un potatore di contesto addestrato per compiti di domande e risposte.

Isolare il Contesto (Isolating Context)

Isolare il contesto significa suddividerlo per aiutare l’agente a svolgere il compito.

Multi-agente (Multi-agent)

Uno dei modi più popolari per isolare il contesto è disperderlo tra più sub-agenti. Una delle motivazioni per la libreria Swarm di OpenAI è la “separazione dei punti di attenzione”, cioè un team di agenti posterà per gestire i sub-compiti. Ogni agente ha un proprio set di strumenti, istruzioni e finestra di contesto indipendente.

Il sistema di ricerca multi-agente di Anthropic offre una forte prova di ciò: più agenti con contesti indipendenti tendono a superare le prestazioni di un singolo agente, in gran parte perché la finestra di contesto di ogni sub-agente può concentrarsi su un sub-compito più ristretto. Come dichiarato nel loro blog:

I sub-agenti operano in parallelo con le proprie finestre di contesto, esplorando diversi aspetti del problema.

Naturalmente, anche i multi-agenti affrontano sfide, inclusi i consumi di token (ad esempio, Anthropic riporta un uso di token 15 volte superiore rispetto alla chat), richiedendo una progettazione attenta dei suggerimenti per pianificare il lavoro dei sub-agenti e gestire il coordinamento tra di essi.

Isolamento del Contesto tramite Ambienti (Context Isolation with Environments)

Il progetto Deep Research di HuggingFace mostra un altro esempio interessante di isolamento del contesto. La maggior parte degli agenti utilizza chiamate API per strumenti, le quali restituiscono oggetti JSON (parametri degli strumenti), quindi vengono trasmesse a strumenti (come un’API di ricerca) per ottenere feedback (come i risultati di ricerca). HuggingFace utilizza un CodeAgent, che genera direttamente il codice contenente la chiamata di strumento desiderata. Questi codici vengono poi eseguiti in un ambiente sandbox. Solo il contesto specifico restituito dalla chiamata agli strumenti (come i valori di ritorno) viene restituito all’LLM.

Questo consente la separazione del contesto dall’LLM nell’ambiente. Hugging Face sottolinea che questo è un ottimo modo per isolare oggetti che consumano molti token:

Gli Agent Code possono gestire meglio lo stato… Hai bisogno di memorizzare immagini/audio/altro per uso futuro? Nessun problema, assegnalo semplicemente come variabile e puoi usarlo più tardi.

Stato (State)

Vale la pena notare che l’oggetto di stato runtime dell’agente è anche un buon modo per isolare il contesto. Questo può funzionare in modo simile a un sandbox. L’oggetto di stato può essere progettato secondo uno schema (Schema, come il modello Pydantic) che include campi che possono essere scritti nel contesto. Un campo nello schema (come messages) può essere esposto all’LLM in ogni interazione dell’agente, ma lo schema può isolare le informazioni in altri campi per un utilizzo più selettivo.

Conclusione

I modelli di ingegneria del contesto per gli agenti AI continuano ad evolversi, ma possiamo riassumere i metodi comuni in quattro categorie: Scrittura, Filtraggio, Compressione e Isolamento:

• • Scrivere il contesto significa conservare informazioni al di fuori della finestra di contesto per l’uso dell’agente nell’esecuzione del compito.
• • Filtrare il contesto significa portare le informazioni necessarie nella finestra di contesto per aiutare l’agente nell’esecuzione del compito.
• • Comprimere il contesto significa mantenere solo i token necessari per eseguire il compito.
• • Isolare il contesto significa suddividere il contesto per aiutare l’agente nell’esecuzione del compito.

Comprendere e applicare questi modelli è il lavoro chiave per costruire agenti efficienti oggi.

• O limite dos agentes de AI não depende apenas do tamanho do modelo, mas sim da habilidade de “gerenciar o contexto”. Essa prática é como configurar a memória para um CPU, determinando a profundidade e a eficiência do pensamento do agente.
• A janela de contexto não é uma lixeira: o excesso de informações pode “contaminar”, distrair e confundir o julgamento da AI. Precisão é muito mais importante do que um grande volume de dados.
• Especialistas utilizam as quatro etapas de “escrever, filtrar, comprimir e isolar” para gerenciar o contexto da AI, usando a limitada “memória” de forma eficaz e alcançando redução de custos e aumento de eficiência.
• O futuro da competição será uma disputa pela eficiência dos sistemas. Isolar tarefas usando uma arquitetura de múltiplos agentes, permitindo que cada agente se destaque em sua própria pequena janela, é fundamental para a construção de sistemas complexos.

Resumo Central

Os agentes (Agents) realizam suas tarefas com o auxílio do contexto (Context). A chamada “engenharia de contexto” refere-se à arte e à ciência de injetar informações adequadas na janela de contexto de um agente durante cada etapa da execução da tarefa. Neste artigo, compilamos as estratégias de engenharia de contexto usadas pelos agentes atuais em grandes categorias.

Engenharia de Contexto (Context Engineering)

Como André Karpathy afirmou, os modelos de linguagem grande (LLM) são como um “novo tipo de sistema operacional”. Os LLM funcionam como um CPU, e sua “janela de contexto” atua como RAM, servindo como a memória de trabalho do modelo. Assim como a capacidade da RAM é limitada, a janela de contexto dos LLM também enfrenta restrições de capacidade ao lidar com diversas fontes de contexto. Uma das funções centrais do sistema operacional é gerenciar o uso eficiente da RAM do CPU, e a “engenharia de contexto” desempenha um papel similar. Karpathy resumiu isso de forma precisa:

A engenharia de contexto é “… uma arte e ciência refinada para preencher com precisão a janela de contexto para o próximo passo (cálculo).”

Ao desenvolver aplicações baseadas em LLM, que tipos de contexto precisamos gerenciar? O conceito de engenharia de contexto abrange os seguintes tipos diferentes de contexto:

• • Instruções (Instructions) – Palavras-chave, memória, exemplos de poucos disparos, descrições de ferramentas, etc.
• • Conhecimento (Knowledge) – Fatos, memórias, etc.
• • Ferramentas (Tools) – Informações de feedback sobre chamadas de ferramentas

Engenharia de Contexto para Agentes

Neste ano, à medida que as capacidades dos LLM em raciocínio e chamadas de ferramentas aumentam, o interesse pelos agentes cresce dia após dia. Os agentes executam tarefas alternando entre LLM e ferramentas, sendo especialmente habilidosos em lidar com tarefas complexas de longa duração.

No entanto, as tarefas longas e o feedback acumulado das chamadas de ferramentas significam que os agentes geralmente consomem uma grande quantidade de tokens. Isso pode acarretar vários problemas: exceder os limites de capacidade da janela de contexto, resultando em aumentos nos custos e na latência, e até mesmo deteriorar o desempenho do agente. Drew Breunig destacou de forma clara que um contexto excessivamente longo pode levar a problemas de desempenho das seguintes maneiras:

• • Contaminação de Contexto (Context Poisoning): Quando informações errôneas (ilusões) entram no contexto.
• • Distração de Contexto (Context Distraction): Quando um excesso de informações no contexto sobrecarrega o conhecimento treinado do modelo.
• • Confusão de Contexto (Context Confusion): Quando informações irrelevantes no contexto afetam as respostas do modelo.
• • Conflito de Contexto (Context Clash): Quando diferentes partes do contexto se contradizem.

Diante desses problemas, a empresa Cognition AI enfatizou a importância da engenharia de contexto:

“A engenharia de contexto”… é na verdade a principal tarefa do engenheiro que constrói agentes de AI.

A Anthropic também esclareceu:

Agentes geralmente precisam passar por centenas de rodadas de diálogo, o que nos exige adotar estratégias de gerenciamento de contexto prudentes.

Então, como os desenvolvedores de hoje estão enfrentando esse desafio? Resumi as abordagens existentes em quatro categorias: Escrever (Write), Filtrar (Select), Comprimir (Compress), e Isolar (Isolate) — e darei exemplos para cada uma.

Escrever o Contexto (Write Context)

Escrever o contexto significa armazenar informações fora da janela de contexto, para que possam ser utilizadas pelo agente durante a execução da tarefa.

Áreas de Trabalho (Scratchpads)

Quando os humanos resolvem problemas, costumam anotar e lembrar de certos aspectos para utilizá-los em tarefas futuras relacionadas. Os agentes também estão adquirindo gradualmente essas habilidades! Fazer anotações em uma “área de trabalho” é uma forma de persistir informações durante a execução da tarefa pelo agente. A ideia central é manter informações fora da janela de contexto, mas acessíveis ao agente quando necessário. O sistema de pesquisa multi-agente da Anthropic fornece um exemplo claro:

O “pesquisador-chefe” primeiro pensa em uma forma de resolver o problema e salva seu plano na “memória” para persistir o contexto, já que uma vez que a janela de contexto ultrapassa 200 mil tokens, ela pode ser truncada, e manter o plano é vital.

Existem várias formas de implementar a área de trabalho. Pode ser uma simples chamada de ferramenta, como gravar um arquivo; ou um campo em um objeto de estado em tempo de execução que se mantém constante durante toda a sessão. Independentemente da abordagem, a área de trabalho permite que o agente armazene informações úteis para melhor atender às suas tarefas.

Memórias (Memories)

A área de trabalho ajuda o agente a resolver tarefas em uma única sessão, mas às vezes os agentes precisam lembrar de informações ao longo de múltiplas sessões. O modelo Reflexion introduziu a ideia de refletir após cada ação do agente, reutilizando essas memórias auto-geradas. Modelos de Agentes Geradores podem periodicamente sintetizar memórias a partir de conjuntos de feedback passados dos agentes.

Esses conceitos foram aplicados em produtos populares como ChatGPT, Cursor e Windsurf. Todos possuem mecanismos para gerar memórias de longo prazo automaticamente a partir da interação dos usuários com os agentes.

Filtrar o Contexto (Select Context)

Filtrar o contexto refere-se a trazer a informação necessária para a janela de contexto a fim de auxiliar o agente na execução de suas tarefas.

Áreas de Trabalho (Scratchpad)

O mecanismo de filtro a partir da área de trabalho depende de como ela foi implementada. Se for uma ferramenta, o agente pode simplesmente fazer uma chamada para ler. Se for parte do estado de execução do agente, o desenvolvedor pode expor seletivamente certas partes do estado para o agente a cada etapa. Isso fornece controle refinado sobre o contexto da área de trabalho fornecido ao LLM nas rodadas seguintes.

Memórias (Memories)

Se o agente tem a capacidade de armazenar memória, ele também precisa ser capaz de filtrar memórias que são relevantes para a tarefa atual. Isso é especialmente útil, pois: o agente pode selecionar exemplos de poucos disparos (memórias situacionais) para aprender padrões de comportamento esperados; pode selecionar instruções (memórias programáticas) para guiar seu próprio comportamento; ou pode escolher fatos (memórias semânticas) para fornecer o contexto relevante para a tarefa.

Um grande desafio é garantir que as memórias filtradas sejam relevantes. Alguns agentes populares utilizam apenas uma pequena parte de um conjunto fixo de arquivos, que são sempre carregados no contexto. Por exemplo, muitos agentes de código usam arquivos para armazenar instruções (memórias programáticas), ou em alguns casos, exemplos (memórias situacionais). Claude Code utiliza CLAUDE.md, enquanto Cursor e Windsurf utilizam arquivos de regras.

No entanto, se o agente armazenar uma grande quantidade de fatos ou relações (por exemplo, do tipo “memórias semânticas”), filtrar se torna mais complicado. O ChatGPT é um ótimo exemplo, pois armazena e filtra a partir de uma grande quantidade de memórias exclusivas de usuários.

Embeddings vetoriais e/ou grafos de conhecimento são técnicas comuns de indexação de memória que auxiliam na filtragem. Apesar disso, a filtragem de memórias continua sendo cheia de desafios. No AIEngineer World Expo, Simon Willison compartilhou um exemplo de erro na filtragem de memórias: o ChatGPT obteve suas informações de localização da memória e acidentalmente as injetou na imagem que ele pediu. Essa recuperação de memória inesperada ou indesejada pode fazer alguns usuários sentirem que a janela de contexto “não lhes pertence mais”!

Ferramentas (Tools)

Os agentes precisam usar ferramentas, mas se muitas ferramentas forem disponibilizadas, eles podem ficar sobrecarregados. Isso geralmente acontece quando as descrições das ferramentas se sobrepõem, o que confunde o modelo ao escolher qual ferramenta usar. Uma abordagem é aplicar RAG (Geração Aumentada por Recuperação) nas descrições das ferramentas, e assim recuperar a ferramenta mais relevante para a tarefa com base na similaridade semântica. Alguns documentos recentes demonstraram que essa abordagem pode aumentar a precisão na seleção de ferramentas em até três vezes.

Conhecimento (Knowledge)

A recuperação aumentada por geração (RAG) é um tópico vasto em si e pode ser um dos desafios centrais da engenharia de contexto. Agentes de código são um dos melhores exemplos da aplicação em larga escala do RAG. Varun, da Windsurf, resumiu bem alguns dos desafios:

Indexar código ≠ recuperar contexto… O que estamos fazendo é usar a AST (árvore de sintaxe abstrata) para analisar o código e segmentá-lo ao longo de limites semanticamente significativos… mas à medida que o tamanho do repositório de código cresce, a busca por embeddings vetoriais se torna menos confiável… Precisamos confiar em uma combinação de várias técnicas, como grep/busca de arquivos, recuperação baseada em grafos de conhecimento, e… um passo de reordenação, onde o contexto é ordenado pela relevância.

Comprimir o Contexto (Compress Context)

Comprimir o contexto significa reter apenas os tokens necessários para a execução da tarefa.

Resumo de Contexto (Context Summarization)

As interações dos agentes podem se estender por centenas de rodadas e utilizar ferramentas que consomem uma grande quantidade de tokens. A compressão é uma abordagem comum para enfrentar esses desafios. Se você já usou o Claude Code, já deve ter visto sua aplicação prática. Quando a taxa de uso da janela de contexto ultrapassa 95%, o Claude Code executa “compressão automática”, resumindo toda a trajetória de interação entre usuário e agente. Essa compressão da trajetória do agente pode adotar diversas estratégias, como resumos recursivos ou resumos hierárquicos.

Adicionar um passo de resumo no design do agente em um momento oportuno também é útil. Por exemplo, pode ser utilizado para pós-processar chamadas de ferramentas (especialmente para ferramentas que consomem muitos tokens, como a de busca). Além disso, a Cognition mencionou a importância de resumir nas bordas onde a interação entre agentes ocorre, para reduzir o consumo de tokens durante a transferência de conhecimento. Capturar eventos ou decisões específicas pode ser desafiador ao resumir. A Cognition utilizou um modelo finetuning para esse propósito, o que destaca o trabalho intenso que pode ser necessário nesse passo.

Corte de Contexto (Context Trimming)

Os resumos geralmente utilizam LLM para extrair os fragmentos mais relevantes de contexto, enquanto o corte é mais como um filtro ou, como disse Drew Breunig, um “poda” de contexto. Isso pode ser feito por meio de regras heurísticas codificadas, como remover mensagens mais antigas de uma lista de mensagens. Drew também mencionou o Provence, um podador de contexto treinado para tarefas de perguntas e respostas.

Isolar o Contexto (Isolating Context)

Isolar o contexto significa fragmentar o contexto para ajudar os agentes na execução de tarefas.

Múltiplos Agentes (Multi-agent)

Uma das maneiras mais populares de isolar o contexto é dispersá-lo entre múltiplos subagentes. Uma das motivações da biblioteca Swarm da OpenAI é o “desvio de foco”, onde uma equipe de agentes trata sub-tarefas. Cada agente possui seu próprio conjunto específico de ferramentas, instruções e janelas de contexto independentes.

O sistema de pesquisa multi-agente da Anthropic fornece uma forte evidência para isso: múltiplos agentes com contextos independentes se saem melhor do que um único agente, em grande parte porque a janela de contexto de cada subagente pode se concentrar em uma sub-tarefa mais estreita. Como foi descrito em seu blog:

Os subagentes operam em paralelo com suas respectivas janelas de contexto, explorando diferentes aspectos do problema.

No entanto, o sistema multi-agente também enfrenta desafios, incluindo o consumo de tokens (por exemplo, a Anthropic relatou que seu uso de tokens é 15 vezes maior do que uma conversa) e a necessidade de uma engenharia de prompt cuidadosa para planejar o trabalho dos subagentes, além dos problemas de coordenação entre eles.

Isolando o Contexto com Ambientes (Context Isolation with Environments)

O projeto de pesquise de profundidade da HuggingFace apresenta outro exemplo interessante de isolamento de contexto. A maioria dos agentes utiliza chamadas de ferramentas via API, que retornam objetos JSON (parâmetros da ferramenta) que são então transmitidos à ferramenta (como uma API de busca) para obter feedback (como resultados de busca). A HuggingFace, por sua vez, utiliza um CodeAgent que gera diretamente o código contendo as chamadas de ferramentas necessárias. Esse código é então executado em um ambiente sandbox. Apenas o contexto específico retornado da chamada da ferramenta (como valores de retorno) é transmitido de volta para o LLM.

Isso permite que o contexto seja isolado no ambiente do LLM. A Hugging Face observa que essa é uma excelente maneira de isolar objetos que consomem muitos tokens:

Os Code Agents são melhores em lidar com estado… Precisa armazenar imagens/áudio/outros dados para uso posterior? Sem problemas, basta alocá-lo como uma variável e você poderá usá-lo mais tarde.

Estado (State)

Vale a pena mencionar que o objeto de estado de execução do agente também é uma boa forma de isolar o contexto. Isso pode funcionar de forma semelhante a um sandbox. O objeto de estado pode definir um esquema (Schema, como um modelo Pydantic) que contém campos que podem ser escritos para o contexto. Um campo no esquema (como messages) pode ser exposto ao LLM a cada interação do agente, mas o esquema pode isolar informações em outros campos para que possam ser utilizadas de forma mais seletiva.

Conclusão

Os padrões de engenharia de contexto dos agentes ainda estão em evolução, mas podemos resumir os métodos comuns em quatro categorias: Escrever, Filtrar, Comprimir e Isolar:

• • Escrever o contexto, referindo-se ao armazenamento de informações fora da janela de contexto, para que os agentes possam utilizá-las durante a execução de suas tarefas.
• • Filtrar o contexto, que envolve trazer informações necessárias para a janela de contexto a fim de auxiliar os agentes na execução de suas tarefas.
• • Comprimir o contexto, mantendo apenas os tokens essenciais para a execução das tarefas.
• • Isolar o contexto, que refere-se à fragmentação do contexto a fim de ajudar os agentes na execução de suas tarefas.

Compreender e aplicar esses padrões é o trabalho central na construção de agentes de AI eficientes hoje.

• El límite de los agentes de IA no depende solo del tamaño del modelo, sino también de la habilidad en la “gestión del contexto”. Es similar a configurar la memoria en un CPU, determina la profundidad y eficiencia del pensamiento del agente.
• La ventana de contexto no es un basurero: la sobrecarga de información puede “contaminar”, interferir y confundir el juicio de la IA. La precisión es mucho más importante que la cantidad.
• Los expertos utilizan la estrategia de “escribir, seleccionar, comprimir y aislar” para gestionar el contexto de la IA, aprovechando al máximo la “memoria” limitada, logrando así una reducción de costos y un aumento de eficiencia.
• La competencia del futuro es una competencia por la eficiencia del sistema. Aislar tareas con una arquitectura de múltiples agentes, permitiendo que cada uno funcione de manera óptima en su pequeña ventana, es clave para construir sistemas de tareas complejas.

Resumen Central

Los agentes (Agent) realizan tareas dependiendo del contexto (Context). La “ingeniería del contexto” es el arte y la ciencia de inyectar información apropiada en la ventana de contexto de un agente en cada paso de su tarea. Este artículo resume las estrategias de ingeniería del contexto utilizadas por los agentes más populares en varias categorías generales.

Ingeniería del Contexto (Context Engineering)

Como dice Andrej Karpathy, los modelos de lenguaje grandes (LLM) son como un “nuevo sistema operativo”. El LLM actúa como CPU, mientras que su “ventana de contexto” funciona como RAM, siendo la memoria de trabajo del modelo. Al igual que la RAM tiene un límite de capacidad, la ventana de contexto de un LLM enfrenta limitaciones de capacidad al procesar diversas fuentes de contexto. Uno de los trabajos clave del sistema operativo es gestionar cómo utilizar eficientemente la RAM del CPU, y “la ingeniería del contexto” desempeña un papel similar. Karpathy resume esto de manera convincente:

“La ingeniería del contexto es ‘… un arte y ciencia sutil para llenar de manera precisa la ventana de contexto para el siguiente paso (cálculo).’”

Al construir aplicaciones de LLM, necesitamos gestionar qué tipos de contexto. El concepto general de ingeniería del contexto abarca los siguientes tipos de contexto:

• • Instrucciones (Instructions) – Frases de entrada, memorias, ejemplos de pocos datos, descripciones de herramientas, etc.
• • Conocimiento (Knowledge) – Hechos, memorias, etc.
• • Herramientas (Tools) – Información de retroalimentación sobre llamadas a herramientas.

Ingeniería del Contexto para Agentes

Este año, con la mejora de las capacidades del LLM en razonamiento y llamadas a herramientas, el interés en los agentes ha aumentado considerablemente. Los agentes ejecutan tareas alternando entre llamadas a LLM y a herramientas, siendo especialmente buenos para manejar tareas complejas en ejecución a largo plazo.

Sin embargo, las tareas largas y la retroalimentación acumulativa de las llamadas a herramientas significan que los agentes suelen consumir grandes cantidades de tokens. Esto puede generar varios problemas: superar las limitaciones de capacidad de la ventana de contexto, incurrir en costos y retrasos adicionales, e incluso disminuir el rendimiento del agente. Drew Breunig ha señalado claramente que un contexto demasiado largo puede causar problemas de rendimiento de las siguientes maneras:

• • Contaminación de contexto (Context Poisoning): cuando información errónea (ilusión) entra en el contexto.
• • Interferencia de contexto (Context Distraction): cuando hay demasiada información en el contexto, ahogando el conocimiento original del modelo.
• • Confusión de contexto (Context Confusion): cuando información irrelevante en el contexto afecta la respuesta del modelo.
• • Conflicto de contexto (Context Clash): cuando diferentes partes del contexto son contradictorias.

Debido a estos problemas, la empresa Cognition AI ha enfatizado la importancia de la ingeniería del contexto:

“La ingeniería del contexto” … de hecho es la tarea principal de los ingenieros que construyen agentes de IA.

La empresa Anthropic también ha señalado:

Los agentes generalmente necesitan tener cientos de rondas de diálogo, lo que requiere que adoptemos estrategias de gestión del contexto con cuidado.

Entonces, ¿cómo están los desarrolladores de hoy enfrentando este desafío? Clasifico los enfoques actuales en cuatro categorías: escribir (Write), seleccionar (Select), comprimir (Compress) y aislar (Isolate) — y proporcionaré ejemplos para cada uno.

Escribir Contexto (Write Context)

Escribir contexto se refiere a almacenar información fuera de la ventana de contexto para su uso por parte del agente durante la ejecución de tareas.

Áreas de trabajo (Scratchpads)

Cuando los humanos resuelven problemas, toman notas y recuerdan cosas para su uso en el futuro. ¡Los agentes también están adquiriendo estas habilidades! Utilizar “áreas de trabajo” para tomar notas es un enfoque para persistir información durante la ejecución de tareas del agente. La idea principal es almacenar información fuera de la ventana de contexto, pero que esté siempre disponible para el agente. El sistema de investigación de múltiples agentes de Anthropic proporciona un claro ejemplo:

“El investigador principal” primero piensa en cómo resolver el problema y guarda su plan en la “memoria” para persistir el contexto, ya que una vez que la ventana de contexto supera los 200,000 tokens, puede ser truncada, y conservar el plan es vital.

Las áreas de trabajo pueden implementarse de varias maneras. Pueden ser una simple llamada a una herramienta, como escribir un archivo; o un campo en un objeto de estado durante la ejecución que permanezca constante durante toda la sesión. En cualquier caso, las áreas de trabajo permiten al agente guardar información útil para completar mejor las tareas.

Memorias (Memories)

Las áreas de trabajo ayudan a los agentes a resolver tareas en una sola sesión, pero a veces los agentes necesitan recordar cosas a través de múltiples sesiones. El modelo Reflexion introduce la idea de reflexionar en cada acción del agente y reutilizar estas memorias generadas por sí mismo. El modelo Generative Agents puede sintetizar periódicamente memorias de un conjunto de retroalimentación de acciones anteriores del agente.

Estos conceptos ya se han aplicado en productos populares como ChatGPT, Cursor y Windsurf. Todos ellos poseen mecanismos para generar automáticamente memorias a largo plazo basadas en la interacción del usuario con el agente.

Seleccionar Contexto (Select Context)

Seleccionar contexto se refiere a mover la información necesaria a la ventana de contexto para ayudar al agente en la ejecución de tareas.

Áreas de trabajo (Scratchpad)

El mecanismo para seleccionar contexto desde el área de trabajo depende de cómo se haya implementado. Si es una herramienta, el agente solo necesita leer a través de la llamada a la herramienta. Si es parte del estado de ejecución del agente, el desarrollador puede decidir exponer selectivamente ciertas partes del estado al agente en cada paso. Esto proporciona un control fino para suministrar el contexto del área de trabajo al LLM en rondas posteriores.

Memorias (Memories)

Si el agente tiene la capacidad de almacenar memorias, también necesita la capacidad de seleccionar memorias relevantes para la tarea en curso. Esto es muy útil por varias razones: el agente puede elegir ejemplos de pocos datos (memorias contextuales) para aprender los patrones de comportamiento esperados; puede seleccionar instrucciones (memorias programáticas) para guiar su propio comportamiento; o elegir hechos (memorias semánticas) para proporcionar el contexto relevante para la tarea.

Un gran desafío es asegurar que las memorias seleccionadas sean relevantes. Algunos agentes populares solo utilizan una pequeña parte de archivos fijos que siempre se cargan en el contexto. Por ejemplo, muchos agentes de código utilizan archivos para almacenar instrucciones (“memorias programáticas”) o, en algunos casos, ejemplos (“memorias contextuales”). Claude Code utiliza CLAUDE.md, mientras que Cursor y Windsurf utilizan archivos de reglas.

Sin embargo, si el agente ha almacenado una gran cantidad de hechos o relaciones (por ejemplo, de tipo “memorias semánticas”), la selección se vuelve más difícil. ChatGPT es un buen ejemplo, ya que almacena y selecciona de una gran cantidad de memorias específicas del usuario.

Las incrustaciones vectoriales y/o grafos de conocimiento son técnicas comunes de indexación de memorias utilizadas para ayudar en la selección. Aun así, la selección de memorias sigue siendo un desafío. En la feria mundial AIEngineer, Simon Willison compartió un ejemplo de un error en la selección de memorias: ChatGPT recuperó su información de ubicación de la memoria y la inyectó inesperadamente en la imagen solicitada. Esta recuperación de memoria inesperada o no deseada puede hacer que algunos usuarios sientan que la ventana de contexto “ya no les pertenece”.

Herramientas (Tools)

Los agentes necesitan usar herramientas, pero si se presentan demasiadas, pueden sentirse abrumados. Esto suele suceder porque las descripciones de herramientas pueden superponerse, causando confusión al modelo sobre cuál elegir. Una forma de abordarlo es aplicar RAG (Generación Aumentada por Recuperación) a las descripciones de herramientas, recuperando la herramienta más relevante para la tarea según la similitud semántica. Algunos estudios recientes han mostrado que este enfoque puede triplicar la precisión en la elección de herramientas.

Conocimiento (Knowledge)

La generación aumentada por recuperación (RAG) es en sí misma un gran tema y puede convertirse en un desafío central en la ingeniería del contexto. Los agentes de código son uno de los mejores ejemplos de RAG en producción a gran escala. Varun de Windsurf resume bien algunos de los desafíos:

Indexar código ≠ Recuperar contexto … lo que estamos haciendo es analizar código a través de un AST (Árbol de Sintaxis Abstracto) y fragmentarlo a lo largo de fronteras con significado semántico … pero a medida que crece el tamaño de la base de código, la búsqueda de incrustaciones vectoriales como método heurístico de recuperación se vuelve poco confiable … debemos confiar en una combinación de diferentes técnicas, como búsqueda por grep/búsqueda de archivos, recuperación basada en grafos de conocimiento, y … un paso de reordenación donde el contexto se clasifica por relevancia.

Comprimir Contexto (Compress Context)

Comprimir contexto significa conservar únicamente los tokens necesarios para la ejecución de la tarea.

Resumen de contexto (Context Summarization)

Las interacciones de los agentes pueden abarcar cientos de rondas, utilizando herramientas que consumen una gran cantidad de tokens. El resumen es una estrategia común para enfrentar estos desafíos. Si has usado Claude Code, ya has visto su aplicación práctica. Cuando la utilización de la ventana de contexto supera el 95%, Claude Code realiza una “compresión automática”, resumiendo la trayectoria completa de interacción entre el usuario y el agente. Este proceso de compresión de la trayectoria del agente puede llevarse a cabo de diversas maneras, como a través de resúmenes recursivos o jerárquicos.

Incorporar un paso de resumen en el diseño del agente puede ser muy útil. Por ejemplo, puede ser utilizado para postprocesar las llamadas de ciertas herramientas (especialmente herramientas que consumen muchos tokens, como las de búsqueda). Además, Cognition menciona la importancia del resumen en los límites de la interacción entre agentes para reducir el consumo de tokens en el proceso de transferencia de conocimiento. Capturar eventos o decisiones específicas puede ser un desafío para resumir. Cognition ha utilizado un modelo de ajuste fino para esto, lo que resalta la cantidad de trabajo que puede requerirse en esta etapa.

Recorte de contexto (Context Trimming)

Los resúmenes generalmente utilizan LLM para extraer los fragmentos de contexto más relevantes, mientras que el recorte es más como filtrar o “podar” el contexto, como dice Drew Breunig. Esto puede hacerse mediante reglas heurísticas codificadas, como eliminar mensajes más antiguos de una lista de mensajes. Drew también mencionó a Provence, un podador de contexto entrenado para tareas de preguntas y respuestas.

Aislar Contexto (Isolating Context)

Aislar contexto se refiere a descomponer el contexto para ayudar al agente en la ejecución de tareas.

Múltiples Agentes (Multi-agent)

Una de las formas más populares de aislar contexto es distribuirlo entre múltiples subagentes. Una de las motivaciones para la biblioteca Swarm de OpenAI es la “separación de preocupaciones”, donde un equipo de agentes maneja tareas secundarias. Cada agente tiene su propio conjunto de herramientas, instrucciones y ventana de contexto independiente.

El sistema de investigación de múltiples agentes de Anthropic proporciona una fuerte evidencia de que múltiples agentes con contextos independientes superan el rendimiento de un único agente, en gran medida debido a que la ventana de contexto de cada subagente puede concentrarse en una sub-tarea más específica. Como se señala en su blog:

Los subagentes operan paralelamente con sus respectivas ventanas de contexto, explorando diferentes aspectos del problema.

Naturalmente, los múltiples agentes también enfrentan desafíos, incluyendo el consumo de tokens (por ejemplo, Anthropic reportó que su consumo de tokens es 15 veces el de una conversación), la necesidad de ingeniería de indicaciones cuidadosa para planificar el trabajo de subagentes y los problemas de coordinación entre subagentes.

Aislamiento de contexto mediante entornos (Context Isolation with Environments)

El proyecto de investigadores profundos de HuggingFace muestra otro interesante ejemplo de aislamiento de contexto. La mayoría de los agentes utilizan llamadas a herramientas API, que devuelven objetos JSON (parámetros de herramientas), que luego se pasan a herramientas (como APIs de búsqueda) para obtener retroalimentación (como resultados de búsqueda). HuggingFace utiliza un CodeAgent, que genera directamente el código que contiene las llamadas a herramientas requeridas. Este código se ejecuta luego en un entorno de sandbox. El contexto específico devuelto por las llamadas a herramientas (como el valor de retorno) se reenvía al LLM.

Esto permite que el contexto esté aislado dentro del entorno del LLM. Hugging Face señala que esta es una excelente forma de aislar objetos que consumen muchos tokens:

Los Code Agents son mejores manejando estados … ¿Necesitas almacenar imágenes/audio/datos adicionales para su uso posterior? No hay problema, solo asígnalos como una variable para que los uses más tarde.

Estado (State)

Es notable que el objeto de estado en tiempo de ejecución del agente también es una buena forma de aislar el contexto. Esto puede funcionar de manera similar a un sandbox. El objeto de estado puede diseñarse con un esquema (por ejemplo, un modelo Pydantic) que incluya campos que se puedan escribir en el contexto. Un campo en el esquema (como messages) puede exponerse al LLM en cada interacción del agente, mientras que el esquema puede aislar información en otros campos para ser utilizada de manera más selectiva.

Conclusión

Los patrones de ingeniería del contexto para agentes están en evolución continua, pero podemos clasificar los métodos comunes en cuatro categorías: escribir, seleccionar, comprimir y aislar:

• • Escribir contexto implica almacenar información fuera de la ventana de contexto para su uso durante la ejecución de tareas por parte del agente.
• • Seleccionar contexto implica mover la información necesaria a la ventana de contexto para ayudar al agente en la ejecución de tareas.
• • Comprimir contexto significa conservar solo los tokens necesarios para la ejecución de la tarea.
• • Aislar contexto implica descomponer el contexto para ayudar al agente en la ejecución de su tarea.

Comprender y aplicar estos patrones es la tarea central para construir agentes eficientes en el presente.

• Потенциал AI-агентов зависит не только от размеров модели, но и от мастерства в управлении контекстом. Это похоже на то, как мы настраиваем память для CPU, что определяет глубину и эффективность размышлений агента.
• Контекстное окно — это не мусорное ведро: избыток информации может “отравить”, помешать и запутать суждения AI. Точность важнее, чем просто объем.
• Умелые специалисты применяют методы “запись, фильтрация, сжатие, изоляция” для управления контекстом AI и эффективно расходуют ограниченную “память”, что ведет к снижению затрат и повышению эффективности.
• Будущее конкурентной борьбы — это борьба за эффективность систем. Использование архитектуры многопроцессорных систем для “изоляции” задач, чтобы каждый агент достигал максимума в своем узком окне, является ключом к построению сложных систем задач.

Основные выводы

Агент (Agent) выполняет задачи, полагаясь на контекст (Context). “Контекстное проектирование” — это искусство и наука точного введения нужной информации в контекстное окно агента на каждом шаге выполнения задачи. В этой статье мы обобщим стратегии контекстного проектирования, используемые современными агентами.

Контекстное проектирование (Context Engineering)

Как сказал Андрій Карпаты, большие языковые модели (LLM) подобны “новой операционной системе”. LLM является CPU, а его “контекстное окно” — это RAM, которое выполняет роль рабочей памяти модели. Также, как и у RAM есть ограниченная емкость, контекстное окно LLM сталкивается с ограничениями при обработке разных источников контекста. Одна из основных задач операционной системы состоит в управлении эффективным использованием RAM для CPU, и “контекстное проектирование” выполняет аналогичную роль. Карпаты очень точно подытожил это:

Контекстное проектирование — это “…искусство и наука точного заполнения контекстного окна для следующего шага (вычисления)”.

При разработке приложений LLM, какие типы контекста нам нужно управлять? Этот обобщающий концепт контекстного проектирования охватывает несколько различных типов контекста:

• • Инструкции (Instructions) – подсказки, память, примеры с малым количеством данных, описания инструментов и т.д.
• • Знания (Knowledge) – факты, память и т.д.
• • Инструменты (Tools) – обратная информация о вызовах инструментов.

Контекстное проектирование для агентов

В этом году, с улучшением способностей LLM в области рассуждений и вызовов инструментов, интерес к агентам постоянно растёт. Агенты выполняют задачи, чередуя вызовы LLM и инструментов, и особенно успешны в обработке сложных долгосрочных задач.

Однако длительные задачи и постоянно накапливающиеся обратные связи от инструментов означают, что агенты зачастую расходуют значительное количество токенов. Это может привести к множеству проблем: превышение ограничений емкости контекстного окна, рост затрат и задержек, а также снижение производительности агента. Дрю Бройниг чётко указал, что чрезмерная длина контекста может приводить к следующим проблемам с производительностью:

• • Отравление контекста (Context Poisoning): когда в контекст попадают галлюцинации (ошибочные сведения).
• • Помехи в контексте (Context Distraction): когда избыток информации переполняет исходные знания модели.
• • Запутанность контекста (Context Confusion): когда нерелевантная информация влияет на реакцию модели.
• • Конфликт контекста (Context Clash): когда различные части контекста противоречат друг другу.

Учитывая эти проблемы, компания Cognition AI подчеркивает важность контекстного проектирования:

“Контекстное проектирование”… на самом деле является приоритетной задачей инженеров, строящих AI-агентов.

Компания Anthropic также явно указала:

Агенты обычно должны вести сотни раундов диалогов, что требует аккуратных стратегий управления контекстом.

Так как же современные разработчики справляются с этой задачей? Я обобщил существующие подходы в четыре основные категории — запись (Write), фильтрация (Select), сжатие (Compress) и изоляция (Isolate) — и привожу примеры для каждой.

Запись контекста (Write Context)

Запись контекста означает сохранение информации вне контекстного окна для использования агентом при выполнении задания.

Зоны для заметок (Scratchpads)

При решении задач люди делают записи и запоминают некоторые детали, чтобы использовать их в будущем. Агенты тоже постепенно развивают эти навыки! Использование “зоны для заметок” для записи является способом сохранения информации во время выполнения задачи агентом. Главная идея заключается в том, чтобы хранить информацию вне контекстного окна, но при этом сделать её доступной для агента в любое время. Многоагентная исследовательская система компании Anthropic предоставляет чёткий пример:

“Главный исследователь” сначала обдумывает, как решить задачу, и сохраняет свой план в “памяти”, чтобы сохранить контекст, так как контекстное окно может быть обрезано, если его размер превышает 200 тысяч токенов, что делает сохранение плана критически важным.

Существует много способов реализации зон для заметок. Это может быть простой вызов инструмента, например, запись в файл; или поле в объекте состояния во время выполнения, которое сохраняется неизменным в течение всей сессии. В любом случае, зоны для заметок позволяют агенту сохранить полезную информацию для более успешного выполнения задания.

Память (Memories)

Зоны для заметок помогают агенту решить задачу в одной сессии, но иногда агенту требуется запомнить вещи на протяжении нескольких сессий. Модель Reflexion представляет концепцию рефлексии после каждого действия агента и повторного использования этих самостоятельно сгенерированных воспоминаний. Модель Generative Agents может периодически синтезировать память из набора обратной связи от прошлых действий агента.

Эти концепции применяются в таких популярных продуктах, как ChatGPT, Cursor и Windsurf. Все они имеют механизмы автоматического создания долгосрочной памяти, основанные на взаимодействии пользователя с агентом.

Фильтрация контекста (Select Context)

Фильтрация контекста подразумевает выбор необходимой информации для включения в контекстное окно, чтобы помочь агенту выполнить задачу.

Зоны для заметок (Scratchpad)

Механизм фильтрации контекста из зоны для заметок зависит от способа её реализации. Если это инструмент, агент может просто прочитать его через вызов инструментов. Если это часть состояния времени выполнения агента, разработчик может на каждом этапе избирательно раскрывать определённые части состояния агенту. Это дает тонкий контроль над тем, какой контекст из зоны заметок предоставляется LLM в последующих раундах.

Память (Memories)

Если агент может сохранять воспоминания, ему также нужно уметь фильтровать память, относящуюся к текущей задаче. Это очень полезно по нескольким причинам: агент может выбрать примеры с малым количеством данных (сценарные воспоминания) для изучения ожидаемого поведения; выбрать инструкции (программные воспоминания) для управления собственными действиями; или выбрать факты (семантические воспоминания) для предоставления соответствующего фона к задаче.

Одной из больших задач является обеспечение релевантности отфильтровавшей памяти. Некоторые популярные агенты используют только небольшую фиксированную часть файла, которая всегда загружается в контекст. Например, многие кодовые агенты используют файлы для хранения инструкций (программные воспоминания) или, в некоторых случаях, примеров (сценарные воспоминания). Claude Code использует CLAUDE.md, а Cursor и Windsurf используют файлы правил.

Однако если агент хранит большое количество фактов или взаимосвязей (например, семантические воспоминания), то фильтрация становится более сложной. ChatGPT — отличный пример, который хранит и фильтрует из значительного числа пользовательских воспоминаний.

Векторные вложения и/или графы знаний — это распространённые технологии индексирования памяти для помощи в фильтрации. Тем не менее, фильтрация памяти остаётся сложной задачей. На выставке AIEngineer Саймон Уилисон поделился примером ошибки фильтрации памяти: ChatGPT извлёк его информацию о местоположении из памяти и случайно внедрил её в изображение, которое он запросил. Это неожиданный или нежелательный извлечение памяти может заставить некоторых пользователей чувствовать, что контекстное окно “больше не принадлежит им”!

Инструменты (Tools)

Агентам нужно использовать инструменты, но если предоставленных инструментов становится слишком много, они могут оказаться перегруженными. Это часто происходит из-за того, что описания инструментов могут перекрываться, что приводит к путанице при выборе инструмента. Один из подходов заключается в применении RAG (усиленная генерация), чтобы найти наиболее релевантные инструменты для задачи на основе семантической схожести. Недавние исследования показали, что такой метод может увеличить точность выбора инструментов в 3 раза.

Знания (Knowledge)

Усиленная генерация (RAG) сама по себе является обширной темой и может стать одной из основных проблем контекстного проектирования. Кодовые агенты — один из лучших примеров RAG в масштабных производственных приложениях. Варун из Windsurf хорошо обобщил некоторые из этих проблем:

Индексирование кода ≠ Поиск контекста… Мы занимаемся тем, что разбираем код с помощью AST (абстрактное синтаксическое дерево) и разбиваем его вдоль семантически значимых границ… Но по мере роста размера библиотеки кода поиск векторных вложений как метод поиска становится ненадежным… Мы должны комбинировать несколько технологий, таких как поиск по grep/файлам, поиск на основе графов знаний и… шаг переупорядочивания, где контекст сортируется по релевантности.

Сжатие контекста (Compress Context)

Сжатие контекста означает сохранение только необходимых токенов для выполнения задачи.

Суммирование контекста (Context Summarization)

Взаимодействия агента могут охватывать сотни раундов и использовать инструменты, которые расходуют большое количество токенов. Суммирование — это распространённый метод, чтобы справляться с этими вызовами. Если вы использовали Claude Code, вы уже видели его практическое применение. Когда использование контекстного окна превышает 95%, Claude Code запускает “автоматическое сжатие”, суммируя полный ход взаимодействия между пользователем и агентом. Это сжатие может применяться с использованием различных стратегий, таких как рекурсивное суммирование или многослойное суммирование.

Полезно также встраивать шаг суммирования в дизайн агента. Например, это может быть полезным для последующей обработки вызовов некоторых инструментов (особенно таких, как поисковые инструменты, которые потребляют много токенов). Например, компания Cognition упоминает о необходимости резюмирования в точках перехода между агентами, чтобы уменьшить потребление токенов в процессе передачи знаний. Если нужно захватить специфические события или решения, суммирование может быть сложной задачей. Cognition для этого использует модель, которая требует больших усилий для настройки.

Обрезка контекста (Context Trimming)

Суммирование часто использует LLM для выделения самых релевантных фрагментов контекста, тогда как обрезка больше похожа на фильтрацию или, как сказал Дрю Бройниг, на “обрезание” контекста. Это можно реализовать с помощью жестко закодированных эвристических правил, например, удаляя более ранние сообщения из списка сообщений. Дрю также упоминал о Provence, контекстном обрезателе, обученном для задач вопросов и ответов.

Изоляция контекста (Isolating Context)

Изоляция контекста означает разбивку контекста, чтобы помочь агенту выполнить задачу.

Многопроцессорные системы (Multi-agent)

Одним из самых популярных способов изоляции контекста является распределение его среди нескольких подагентов. Одной из мотиваций для библиотеки Swarm от OpenAI является “разделение внимания”, при котором команда агентов обрабатывает подсобные задачи. Каждый агент имеет свой определенный набор инструментов, инструкции и независимое контекстное окно.

Многоагентная исследовательская система от Anthropic предоставляет убедительные доказательства: несколько агентов с независимым контекстом функционируют лучше, чем один агент, во многом благодаря тому, что контекстное окно каждого подагента может сосредоточиться на более узкой подсобной задаче. Как упоминается в их блоге:

Подагенты работают параллельно с собственными контекстами, исследуя различные аспекты проблемы.

Конечно, многопроцессорные системы также сталкиваются с проблемами, включая потребление токенов (например, Anthropic сообщила, что их использование токенов в 15 раз превышает стандартный чат), необходимость тщательной разработки подсказок для планирования работы подагентов, а также проблемы координации между ними.

Изоляция контекста с помощью окружений (Context Isolation with Environments)

Программа глубоких исследований HuggingFace демонстрирует ещё один интересный пример изоляции контекста. Большинство агентов используют инструменты, вызывая API, которые возвращают объекты JSON (параметры инструмента), которые затем передаются инструментам (например, поисковым API) для получения обратной связи (например, результатов поиска). HuggingFace применяет CodeAgent, который напрямую выводит код для необходимых вызовов инструментов. Этот код затем выполняется в песочнице. Специфический контекст, возвращаемый вызовами инструментов (например, возвращаемое значение), затем возвращается в LLM.

Это позволяет изолировать контекст в окружении от LLM. Hugging Face отмечает, что это отличный способ изоляции объектов, которые расходуют много токенов:

Code Agents лучше справляются с состоянием… Нужно ли сохранить изображение/аудио/другие данные для последующего использования? Не проблема, просто выделите это как переменную, и вы сможете использовать её позже.

Состояние (State)

Стоит отметить, что объект состояния рабочего времени агента также является хорошим методом изоляции контекста. Это можно реализовать так же, как и песочница. Объект состояния может быть спроектирован по шаблону (Schema, например, модель Pydantic), включающему поля, которые можно записывать в контекст. Одно из полей шаблона (например, messages) может быть доступно для LLM на каждом раунде взаимодействия агента, в то время как информация может быть изолирована в других полях для более избирательного использования.

Заключение

Модели контекстного проектирования агентами продолжают эволюционировать, но мы можем обобщить распространенные методы в четыре основные категории — запись, фильтрация, сжатие и изоляция:

• • Запись контекста означает сохранение информации вне контекстного окна для использования агентом при выполнении задания.
• • Фильтрация контекста означает выбор необходимой информации для включения в контекстное окно, чтобы помочь агенту выполнить задачу.
• • Сжатие контекста означает сохранение только необходимых токенов для выполнения задания.
• • Изоляция контекста означает разбивку контекста для помощи агенту в выполнении задачи.

Понимание и применение этих моделей является ключевой задачей в создании эффективных агентов.

• Begränsningarna för AI-agenter beror inte bara på modellens storlek, utan också på konsten att hantera kontext. Det är som att konfigurera minne för en CPU och avgör hur djupt och effektivt agenten kan tänka.
• Kontextfönstret ska inte fungera som en soptunna: Informationsöverbelastning kan “förorena”, störa och förvirra AI:s bedömningar. Precision är mycket viktigare än mängd.
• Skickliga användare hanterar AI:s kontext med strategin “Skriv, Filtrera, Komprimera och Isolera”, för att använda det begränsade “minnet” effektivt och uppnå lägre kostnader och högre effektivitet.
• Framtidens konkurrens handlar om systemeffektivitet. Att “isolera” uppgifter med en fleragentarkitektur, så att varje agent kan briljera i sitt eget lilla fönster, är nyckeln till att bygga komplexa uppgiftssystem.

Huvudsammanfattning

Agenter (Agents) utför uppgifter med hjälp av kontext (Context). “Kontextteknik” handlar om att med precision injicera korrekt information i agentens kontextfönster för varje steg i uppgiftsutförandet. Denna artikel sammanfattar de aktuella strategierna för kontextteknik som används av populära agenter i några övergripande mönster.

Kontextteknik (Context Engineering)

Som Andrej Karpathy säger, liknar stora språkmodeller (LLM) ett “nytänkande operativsystem”. LLM fungerar som CPU, medan dess “kontextfönster” fungerar som RAM, och fungerar som modellens arbetsminne. Precis som kapaciteten hos RAM är begränsad, så är kontextfönster för LLM även begränsade när de hanterar olika kontextkällor. En av operativsystemets huvudsakliga uppgifter är att hantera hur RAM effektivt används, och “kontextteknik” spelar en liknande roll. Karpathy sammanfattade detta mycket väl:

Kontextteknik är “… en fin konst och vetenskap för att exakt fylla kontextfönstret för nästa steg (beräkning).”

Vilka typer av kontext behöver vi hantera när vi bygger LLM-applikationer? Kontextteknik omfattar följande olika typer av kontext:

• • Instruktioner (Instructions) – Promptord, minnen, några exempel, verktygsbeskrivningar etc.
• • Kunskap (Knowledge) – Fakta, minnen etc.
• • Verktyg (Tools) – Feedbackinformation från verktygsanrop.

Kontextteknik för agenter

I år, med LLM:s förbättrade förmågor inom resonemang och verktygsanrop, har intresset för agenter ökat stadigt. Agenter utför uppgifter genom att växelvis anropa LLM och verktyg, och är särskilt duktiga på att hantera långvariga och komplexa uppgifter.

Men långsiktiga uppgifter och den ständigt växande mängden feedback från verktygsanrop innebär att agenter ofta konsumerar en stor mängd tokens. Detta kan leda till flera problem: överskridande av kontextfönstrets kapacitetsgränser, vilket resulterar i ökade kostnader och förseningar, och till och med sänkt agentprestanda. Drew Breunig har tydligt påpekat att en för lång kontext kan orsaka prestationsproblem på flera sätt:

• • Kontextförorening (Context Poisoning): När falska uppgifter (illusioner) kommer in i kontexten.
• • Kontextstörning (Context Distraction): När överflödig kontextinformation överskuggar modellens ursprungliga träningskunskaper.
• • Kontextförvirring (Context Confusion): När irrelevant kontextinformation påverkar modellens svar.
• • Kontextkonflikt (Context Clash): När olika delar av kontexten motsäger varandra.

Med tanke på dessa problem betonar företaget Cognition AI vikten av kontextteknik:

“Kontextteknik”… är i själva verket ingenjörens främsta uppgift vid konstruktion av AI-agenter.

Företaget Anthropic har också påpekat att:

Agenter behöver ofta genomföra hundratals dialogrundor, vilket kräver att vi tillämpar försiktiga strategier för kontextförvaltning.

Hur möter dagens utvecklare denna utmaning? Jag har sammanfattat nuvarande metoder i fyra kategorier – Skriva (Write), Filtrera (Select), Komprimera (Compress) och Isolera (Isolate) – och ger exempel för varje.

Skriva kontext (Write Context)

Att skriva kontext handlar om att spara information utanför kontextfönstret för att agenten ska använda när den utför sina uppgifter.

Tillfälligt lagringsutrymme (Scratchpads)

När människor löser problem, gör de anteckningar och kommer ihåg vissa detaljer för framtida relaterade uppgifter. Agenter får också allt mer dessa förmågor! Att använda “tillfälligt lagringsutrymme” för att göra anteckningar är en metod för att bevara information under en agents uppgiftsutförande. Kärnprincipen är att spara information utanför kontextfönstret, men som agenten kan hämta när som helst. Anthropic har ett tydligt exempel genom sitt fleragentforskningssystem:

“Huvudforskaren” tänker först på hur de ska lösa problemet och sparar sin plan i “minnet” för att bevara kontexten, eftersom kontextfönstret kan klippas av när det överskrider 200 000 tokens, och att bevara planen är avgörande.

Det finns flera sätt att implementera tillfälligt lagringsutrymme. Det kan vara ett enkelt verktygsanrop för att skriva till en fil; det kan också vara ett fält i en runtime-statusobjekt som förblir konstant under hela sessionen. Oavsett metod, låter tillfälligt lagringsutrymme agenten spara användbar information för att bättre utföra sina uppgifter.

Minnen (Memories)

Tillfälligt lagringsutrymme hjälper agenten att lösa uppgifter inom en session, men ibland behöver agenten komma ihåg saker över flera sessioner. Reflexion-modellen introducerar idéer om att reflektera efter varje åtgärd som agenten utför och återanvända dessa egenproducerade minnen. Generativa agentmodellen kan periodiskt syntetisera minnen från samlingen av tidigare feedback från agenten.

Dessa koncept har tillämpats i populära produkter som ChatGPT, Cursor och Windsurf. De har mekanismer för att automatiskt generera långvariga minnen baserat på interaktioner mellan användaren och agenten.

Filtrera kontext (Select Context)

Att filtrera kontext innebär att hämta önskad information till kontextfönstret för att hjälpa agenten att utföra sin uppgift.

Tillfälligt lagringsutrymme (Scratchpad)

Filtreringsmekanismen från det tillfälliga lagringsutrymmet beror på hur det är implementerat. Om det är ett verktyg, kan agenten bara läsa information via verktygsanropet. Om det är en del av agentens runtime-status kan utvecklaren välja att exponera vissa delar av statusen för agenten i varje steg. Detta ger fin kontroll över att förse LLM med tillfälliga kontextdetaljer i kommande rundor.

Minnen (Memories)

Om agenten kan spara minnen behöver den också möjligheten att filtrera relevanta minnen för den aktuella uppgiften. Detta är mycket användbart av flera skäl: agenten kan välja exempel med få prov (situationsminnen) för att lära sig förväntade beteendemönster; den kan välja instruktioner (programminnen) för att styra sitt beteende; eller välja fakta (semantiska minnen) för att ge relevant bakgrund för uppgiften.

En stor utmaning är att säkerställa att de filtrerade minnena är relevanta. Vissa populära agenter använder bara en liten del av en fast fil, som alltid laddas till kontexten. Till exempel, många kodenheter använder filer för att spara instruktioner (“programminnen”) eller, i vissa fall, för att spara exempel (“situationsminnen”). Claude Code använder CLAUDE.md, medan Cursor och Windsurf använder regel-filer.

Men om agenten har lagrat en stor mängd fakta eller relationer (till exempel av “semantisk minnes”-typ) blir filtreringen mer komplicerad. ChatGPT är ett bra exempel på detta, då den lagrar och filtrerar från en stor mängd användarspecifika minnen.

Vektor-inbäddningar och/eller kunskapsgrafer är vanliga tekniker för att indexera minnen och underlätta filtrering. Trots detta är minnesfiltrering fortfarande fylld med utmaningar. På AIEngineer Världsmässan delade Simon Willison ett exempel på ett misstag i filtreringen av minnen: ChatGPT hämtade hans position från minnet och av misstag injicerade det i bilden han bad om. Denna oväntade och oönskade hämtning av minne kan få vissa användare att känna att kontextfönstret “inte längre tillhör dem själva”!

Verktyg (Tools)

Agenter behöver använda verktyg, men om det finns för många tillgängliga verktyg kan de bli överväldigade. Detta beror ofta på att verktygsbeskrivningarna kan överlappa, vilket gör att modellen blir förvirrad angående vilket verktyg som ska väljas. En metod är att tillämpa RAG (Retrieval-Augmented Generation) på verktygsbeskrivningar för att hämta det mest relevanta verktyget baserat på semantisk likhet. Nyare studier har visat att denna metod kan tredubbla noggrannheten i verktygsval.

Kunskap (Knowledge)

Retrieval-Augmented Generation (RAG) är ett omfattande ämne och kan bli en kärnissue inom kontextteknik. Kodenheter är ett av de bästa exemplen på RAG i storskalig tillämpning. Windsurf’s Varun sammanfattade några av de utmaningar som uppstår:

Indexera kod ≠ Kontextbaserad hämtning… Vi arbetar med att analysera koden genom AST (abstrakt syntaxträd) och segmentera längs meningsfulla semantiska gränser… Men i takt med att kodbasen växer, blir vektor-inbäddningssökningar som en hämtning-heuristik opålitlig… Vi måste förlita oss på en kombination av flera tekniker, som grep/filsökning, kunskapsgrafbaserad hämtning, och… ett omordningssteg där kontexten rangordnas efter relevans.

Komprimera kontext (Compress Context)

Att komprimera kontext handlar om att endast behålla de tokens som är nödvändiga för att utföra uppgifter.

Kontextsummering (Context Summarization)

Agenternas interaktion kan sträcka sig över hundratals rundor och använda verktyg som konsumerar en stor mängd tokens. Summering är en vanlig metod för att hantera dessa utmaningar. Om du har använt Claude Code, har du kanske redan sett dess praktiska tillämpning. När kontextfönstrets användning överstiger 95%, kör Claude Code automatisk “komprimering” och summerar hela interaktionshistoriken mellan användaren och agenten. Denna summering av agentens spår kan ta flera former, som rekursiv eller hierarkisk summering.

Det är också användbart att inkludera summering i agentens design vid rätt tillfälle. Till exempel kan den användas för att efterbehandla vissa verktygsanrop (speciellt sådana som konsumerar mycket tokens, som sökverktyg). Dessutom nämnde Cognition att man summerar vid gränsen mellan en agent och en annan agent, för att minska token-kostnaderna under kunskapsöverföringen. Att fånga specifika händelser eller beslut kan dock vara en utmaning. Cognition använde här en finjusterad modell, vilket belyser den stora mängd arbete som kan krävas för att genomföra detta steg.

Kontexttrimning (Context Trimming)

Summering använder vanligtvis LLM för att extrahera de mest relevanta kontextfragmenten, medan trimning handlar mer om att filtrera eller som Drew Breunig beskriver det, “beskära” kontexten. Detta kan göras med hårdkodade heuristiska regler, till exempel genom att ta bort äldre meddelanden från meddelandelistan. Drew nämnde också Provence, en kontextbeskärare som tränades för fråge- och svarsuppgifter.

Isolera kontext (Isolating Context)

Att isolera kontext handlar om att segmentera kontexten för att hjälpa agenten i uppgiftsutförandet.

Fleragenter (Multi-agent)

En av de mest populära metoderna för att isolera kontext är att sprida den över flera underagenter. En av motiven bakom OpenAI:s Swarm-bibliotek är att “separera fokus”, med ett team av agenter som hanterar underuppgifter. Varje agent har sin egen specifika uppsättning verktyg, instruktioner och oberoende kontextfönster.

Anthropics fleragentforskningssystem ger en stark bevisning för att flera agenter med oberoende kontext presterar bättre än en enda agent, mycket tack vare att varje underagentens kontextfönster kan fokusera på en smalare underuppgift. Som de beskriver i sin blogg:

Underagenterna arbetar parallellt med egna kontextfönster och utforskar olika aspekter av problemet.

Naturligtvis står fleragenter också inför utmaningar, inklusive token-konsumtion (till exempel, Anthropics rapporterar att deras användning av tokens är 15 gånger högre än för chatkonversationer), behovet av noggrant promptengineering för att planera underagenternas arbete, samt samordningsproblem mellan underagenterna.

Isolering av kontext genom miljöer (Context Isolation with Environments)

HuggingFace:s djupforskningsprogram visar ett intressant exempel på kontextisolering. De flesta agenter använder verktygsanrops-API:er, som returnerar JSON-objekt (verktygsparametrar) som skickas till verktyg (som sök-API) för att få feedback (som sökresultat). HuggingFace använder istället en CodeAgent, som direkt producerar koden för de nödvändiga verktygsanropen. Denna kod körs sedan i en sandlådemiljö. Endast den specifika kontext som returneras (som returvärden) skickas tillbaka till LLM.

Detta gör att kontexten kan isoleras i miljön med LLM. Hugging Face påpekar att detta är en utmärkt metod för att isolera objekt som konsumerar stora mängder tokens:

Code Agents kan hantera tillstånd bättre… behöver du lagra bilder/ljud/annan data för framtida bruk? Inga problem, tilldela det bara som en variabel, så kan du använda det senare.

Status (State)

Det är värt att nämna att agentens runtime-statusobjekt också är en bra metod för att isolera kontext. Det kan fungera på liknande sätt som en sandlåda. Statusobjektet kan designas med ett schema (exempelvis en Pydantic-modell) som innehåller fält som kan skrivas till kontexten. Ett fält i schemat (som messages) kan exponeras för LLM i varje interaktionsrunda, men schemat kan isolera information i andra fält för mer selektiv användning.

Slutsats

Mönstren för kontextteknik i AI-agenter utvecklas fortfarande, men vi kan sammanfatta de vanligaste metoderna i fyra kategorier – Skriva, Filtrera, Komprimera och Isolera:

• • Skriva kontext, handlar om att spara information utanför kontextfönstret för att agenten ska använda vid utförande av uppgifter.
• • Filtrera kontext, handlar om att hämta önskad information till kontextfönstret för att hjälpa agenten att utföra uppgifter.
• • Komprimera kontext, handlar om att endast behålla de tokens som är nödvändiga för att utföra uppgifter.
• • Isolera kontext, handlar om att segmentera kontexten för att hjälpa agenten att utföra uppgifter.

Att förstå och tillämpa dessa mönster är kärnan i att bygga effektiva agenter idag.

• De limieten van AI-agenten zijn niet alleen afhankelijk van de grootte van de modellen, maar ook van de vaardigheid in “contextmanagement”. Het is vergelijkbaar met het configureren van geheugen voor een CPU, wat de diepte en efficiëntie van het denkproces van de agent bepaalt.
• Het contextvenster is geen vuilnisbak: informatie-overload kan leiden tot “vervuiling”, verstoring en verwarring van het oordeel van de AI. Precisie is veel belangrijker dan kwantiteit.
• Vakmensen gebruiken de vier stappen van “schrijven, filteren, compressen, isoleren” om de context van AI te beheren en zetten de beperkte “geheugen” op de juiste manier in, wat leidt tot kostenbesparing en efficiëntieverbetering.
• De toekomst van concurrentie draait om het verbeteren van systeem efficiëntie. Het “isoleren” van taken met een multi-agent architectuur, zodat elke agent in zijn eigen kleine venster excelleert, is essentieel voor het bouwen van complexe taak systemen.

Kern Samenvatting

Agenten kunnen hun taken niet uitvoeren zonder context. “Context Engineering” is de kunst en wetenschap van het nauwkeurig injecteren van relevante informatie in het contextvenster van een agent bij elke stap van zijn taak. Dit artikel vat de huidige strategieën voor context engineering die in populaire agenten worden gebruikt samen in enkele veelvoorkomende patronen.

Context Engineering

Zoals Andrej Karpathy zegt, zijn grote taalmodellen (LLM) als een “nieuw soort besturingssysteem”. LLM fungeert als de CPU, terwijl zijn “contextvenster” de RAM is en dient als het werkgeheugen van het model. Net als de beperkte capaciteit van RAM, heeft het contextvenster van een LLM te maken met capaciteitsbeperkingen bij het verwerken van verschillende contextbronnen. Een van de belangrijkste taken van een besturingssysteem is het efficiënt beheren van het RAM-geheugen van de CPU, en “context engineering” speelt een vergelijkbare rol. Karpathy vat het mooi samen:

Context engineering is “…… een verfijnde kunst en wetenschap die zich richt op het nauwkeurig vullen van het contextvenster voor de volgende stap (berekening).”

Welke soorten context moeten we beheren bij het bouwen van LLM-toepassingen? Het overkoepelende concept van context engineering omvat de volgende verschillende types van context:

• • Instructies (Instructions) – promptwoorden, geheugen, voorbeelden met weinig data, toolbeschrijvingen, enz.
• • Kennis (Knowledge) – feiten, herinneringen, enz.
• • Tools (Tools) – feedbackinformatie van toolaanroepen.

Context Engineering voor Agenten

Dit jaar, met de verbeteringen in de redeneer- en toolaanroepcapaciteiten van LLM’s, groeit de interesse in agenten. Agenten voeren taken uit door afwisselend LLM’s en tools aan te roepen en zijn bijzonder goed in het beheersen van langdurige en complexe taken.

Echter, langdurige taken en continu toenemende feedback van tools betekent dat agenten meestal veel tokens verbruiken. Dit kan verschillende problemen met zich meebrengen: overschrijding van de capaciteitslimiet van het contextvenster, wat leidt tot stijgende kosten en vertragingen, en kan zelfs de prestaties van de agent verlagen. Drew Breunig heeft duidelijk gemaakt dat te lange contexten prestatieproblemen kunnen veroorzaken op verschillende manieren:

• • Contextvervuiling (Context Poisoning): wanneer hallucinaties (onjuiste informatie) de context binnendringen.
• • Contextafleiding (Context Distraction): wanneer er teveel contextuele informatie is die de oorspronkelijke trainingskennis van het model overschaduwt.
• • Contextverwarring (Context Confusion): wanneer irrelevante contextuele informatie de reacties van het model beïnvloedt.
• • Contextconflict (Context Clash): wanneer verschillende delen van de context tegenstrijdig zijn.

Gelet op deze problemen benadrukt Cognition AI het belang van context engineering:

“Context engineering” … is in feite de belangrijkste taak voor ingenieurs die AI-agenten bouwen.

Anthropic heeft ook duidelijk gemaakt:

Agenten moeten doorgaans honderden rondes van dialogen doorlopen, wat van ons vereist om zorgvuldige contextmanagementstrategieën toe te passen.

Hoe gaan de ontwikkelaars van vandaag met deze uitdaging om? Ik heb de bestaande methoden samengevat in vier hoofdtypes—**schrijven (Write), filteren (Select), comprimeren (Compress) en isoleren (Isolate)**—met daar voorbeelden bij.

Schrijven van Context (Write Context)

Schrijven van context betekent informatie buiten het contextvenster bewaren voor gebruik wanneer de agent taken uitvoert.

Scratchpads

Wanneer mensen problemen oplossen, maken ze aantekeningen en onthouden ze dingen voor toekomstige gerelateerde taken. Agenten beginnen ook stapsgewijs deze vaardigheden te ontwikkelen! Notities maken in een “scratchpad” is een manier om informatie tijdens de uitvoering van een taak aan de agent persistent aan te bieden. Het idee is om informatie buiten het contextvenster te bewaren, maar nog steeds toegankelijk te maken voor de agent. Het meeragentensysteem van Anthropic illustreert deze aanpak goed:

De “hoofdonderzoeker” denkt eerst na over manieren om het probleem op te lossen en slaat het plan op in het “geheugen” om de context te behouden, omdat het contextvenster mogelijk wordt afgebroken bij meer dan 200.000 tokens, terwijl het behoud van het plan cruciaal is.

Scratchpads kunnen op verschillende manieren worden geïmplementeerd. Het kan een eenvoudige toolaanroep zijn, zoals het schrijven naar een bestand; het kan ook een veld zijn in een runtime-statusobject dat gedurende de hele sessie onveranderd blijft. Hoe dan ook, scratchpads stellen agenten in staat om nuttige informatie te behouden om taken beter uit te voeren.

Herinneringen (Memories)

Scratchpads helpen agenten bij het oplossen van taken binnen één sessie, maar soms moeten agenten ook zaken onthouden over meerdere sessies. Het Reflexion-model heeft het idee geïntroduceerd om na elke actie van de agent na te denken en deze zelfgegenereerde herinneringen opnieuw te gebruiken. Het Generative Agents-model is in staat om periodiek herinneringen te synthetiseren vanuit een verzameling feedback van eerdere agenten.

Deze concepten zijn toegepast in populaire producten zoals ChatGPT, Cursor en Windsurf. Al deze producten hebben mechanismen in place om automatisch langdurige herinneringen te genereren op basis van de interacties van gebruikers met de agent.

Filteren van Context (Select Context)

Filteren van context betekent het inbrengen van de benodigde informatie in het contextvenster om de agent te helpen bij het uitvoeren van zijn taken.

Scratchpad

De methode voor het filteren van context uit een scratchpad hangt af van hoe deze is geïmplementeerd. Als het een tool is, kan de agent eenvoudig deze toolaanroep gebruiken om informatie te lezen. Als het een onderdeel is van de runtime-status van de agent, kunnen ontwikkelaars selectief bepaalde delen van de status blootstellen aan de agent bij elke stap. Dit biedt fijne controle over het aanleveren van scratchpad-context aan de LLM in de volgende rondes.

Herinneringen

Als agenten in staat zijn om herinneringen op te slaan, moeten ze ook in staat zijn om de relevante herinneringen voor de huidige taak te filteren. Dit is zeer nuttig om verschillende redenen: agenten kunnen voorbeelden met weinig data (situatieherinneringen) kiezen om de gewenste gedragspatronen te leren; instructies (programmaremmories) kunnen worden gekozen om hun eigen gedrag te sturen; of feiten (semantische herinneringen) kunnen worden geselecteerd om relevante context voor de taak te bieden.

Een grote uitdaging is ervoor te zorgen dat de gefilterde herinneringen relevant zijn. Sommige populaire agenten gebruiken slechts een klein deel van een vaste verzameling bestanden die altijd in de context worden geladen. Bijvoorbeeld, veel code-agenten gebruiken bestanden om instructies (programmaremmories) of in sommige gevallen voorbeelden (situatieherinneringen) op te slaan. Claude Code gebruikt CLAUDE.md, terwijl Cursor en Windsurf regelbestanden gebruiken.

Echter, als agenten een grote hoeveelheid (bijvoorbeeld semantische herinneringen) feiten of relaties opslaan, wordt het filteren ingewikkelder. ChatGPT is een goed voorbeeld, het slaat op en filtert uit een enorme verzameling gebruikersspecifieke herinneringen.

Vectorembeddedingen en/of kennisgrafieken zijn populaire technieken voor herinneringindexering ter ondersteuning van het filteren. Ondanks dat, blijft het filteren van herinneringen uitdagend. Tijdens de AI Engineer World Expo deelde Simon Willison een voorbeeld van een foutieve herinneringselectie: ChatGPT haalde zijn locatie-informatie uit herinneringen en voegde deze per ongeluk toe aan de afbeelding die hij vroeg. Deze onvoorziene of ongewenste herinneringsextractie kan sommige gebruikers het gevoel geven dat het contextvenster “niet meer van hen is”!

Tools

Agenten moeten tools gebruiken, maar als er teveel aangeboden tools zijn, kunnen ze overweldigd raken. Dit komt vaak doordat de toolbeschrijvingen op elkaar kunnen lijken, wat verwarring veroorzaakt bij het kiezen van welke tool te gebruiken. Een aanpak is om RAG (Retrieval-Augmented Generation) toe te passen op de toolbeschrijvingen en het meest relevante hulpmiddel op basis van semantische gelijkenis voor de taak te extraheren. Recente onderzoeken tonen aan dat deze aanpak de nauwkeurigheid van toolselectie drie keer kan verhogen.

Kennis

Retrieval-Augmented Generation (RAG) is op zichzelf al een omvangrijk onderwerp en kan een van de kernuitdagingen van context engineering vormen. Code-agenten zijn een van de beste voorbeelden van RAG in grootschalige productieapplicaties. Varun van Windsurf heeft enkele van de uitdagingen mooi samengevat:

Code-indexering ≠ contextretrieval…… Wat wij doen, is door AST (Abstract Syntax Tree) de code te parseren en langs semantisch betekenisvolle grenzen te chunkeren…… Maar naarmate de omvang van codebases toeneemt, wordt vectorembedding zoeken als een retrieval heuristiek onbetrouwbaar…… We moeten vertrouwen op een combinatie van technieken, zoals grep/bestandszoeken, kennisgrafiek-gebaseerde retrieval, en…… een herschikkingsstap, waarbij context wordt gerangschikt op relevantie.

Comprimeren van Context (Compress Context)

Comprimeren van context betekent alleen de tokens te behouden die essentieel zijn voor het uitvoeren van de taak.

Contextsamenvatting (Context Summarization)

Interacties van agenten kunnen zich over honderden rondes uitstrekken en gebruiken tools die veel tokens verbruiken. Samenvatten is een veelgebruikte benadering om deze uitdagingen aan te gaan. Als je Claude Code hebt geprobeerd, heb je gezien hoe het in de praktijk wordt toegepast. Wanneer het gebruik van het contextvenster meer dan 95% bedraagt, voert Claude Code “automatische compressie” uit, waarbij de volledige interactie van de gebruiker met de agent wordt samengevat. Dit comprimeren van de interacties van de agent kan op verschillende manieren plaatsvinden, zoals door middel van recursieve samenvattingen of hiërarchische samenvattingen.

Het tijdig opnemen van samenvattingen in het ontwerp van agenten is ook nuttig. Dit kan worden gebruikt om de aanroepen van bepaalde tools te verwerken (vooral bij tools die veel tokens verbruiken, zoals zoektools). Cognition heeft ook voorgesteld om samenvattingen te maken aan de grenzen waar agenten aan elkaar overdragen, om het tokenverbruik in het kennisoverdrachtsproces te verminderen. Als specifieke gebeurtenissen of beslissingen moeten worden vastgelegd, kan samenvatten uitdagend zijn. Cognition maakt hiervoor gebruik van een fijn afgestemd model, wat aangeeft dat deze stap veel inzet kan vereisen.

Contexttrimmen (Context Trimming)

Samenvattingen gebruiken vaak LLM’s om de meest relevante contextfragmenten te distilleren, terwijl trimmen meer lijkt op het filteren of, zoals Drew Breunig het noemt, “snoeien” van context. Dit kan worden bereikt met hardgecodeerde heuristieken, zoals het verwijderen van oudere berichten uit een lijst van berichten. Drew noemde ook Provence, een context-snoeier getraind voor vraag-en-antwoord-taken.

Isoleren van Context (Isolating Context)

Isoleren van context betekent het splitsen van context om de agent te helpen bij het uitvoeren van zijn taken.

Multi-agent (Multi-agent)

Een van de populairste manieren om context te isoleren, is door deze verdeeld over meerdere sub-agenten. Een motivatie voor OpenAI’s Swarm-bibliotheek is “focusscheiding”, waarbij een team van agenten sub-taken behandelt. Elke agent heeft zijn eigen specifieke set tools, instructies en een onafhankelijk contextvenster.

Het multi-agentsysteem van Anthropic biedt sterk bewijs voor het feit dat meerdere agenten met onafhankelijke contexten betere prestaties leveren dan één enkele agent, grotendeels omdat het contextvenster van elke sub-agent zich kan concentreren op een smallere sub-taak. Zoals ze in hun blog stellen:

Sub-agenten werken parallel met hun eigen contextvensters en verkennen tegelijkertijd verschillende aspecten van het probleem.

Natuurlijk heeft multi-agent ook zijn uitdagingen, waaronder tokenverbruik (bijvoorbeeld, Anthropic rapporteert dat hun tokenverbruik 15 keer dat van chatten is), de noodzaak van zorgvuldige promptengineering om het werk van sub-agenten te plannen, en coördinatieproblemen tussen sub-agenten.

Isoleren van context via omgevingen (Context Isolation with Environments)

Het Deep Researcher-project van HuggingFace toont een ander interessant voorbeeld van contextisolatie. De meeste agenten gebruiken toolaanroepen API’s die JSON-objecten retourneren (toolparameters), die vervolgens aan de tools (zoals de zoek-API) worden doorgegeven om feedback (zoals zoekresultaten) te verkrijgen. HuggingFace echter maakt gebruik van een CodeAgent, die direct de code uitvoert voor de benodigde toolaanroepen. Deze code wordt vervolgens in een sandboxomgeving uitgevoerd. De specifieke context die door de toolaanroep wordt geretourneerd (zoals de teruggegeven waarde) wordt dan teruggegeven aan de LLM.

Dit stelt de context in staat om in isolatie van de LLM te opereren. Hugging Face merkt op dat dit een uitstekende manier is om objecten die veel tokens verbruiken te isoleren:

Code Agents kunnen beter omgaan met status…… Moet je afbeeldingen/audio/andre gegevens opslaan voor later gebruik? Geen probleem, wijs het simpelweg toe als een variabele en je kunt het later gebruiken.

Status (State)

Het is ook vermeldenswaardig dat de runtime statusobjecten van agenten ook een goede manier zijn om context te isoleren. Dit kan een soortgelijk effect hebben als een sandbox. Statusobjecten kunnen een schema ontwerpen (Schema, bijvoorbeeld een Pydantic-model) met velden die in de context kunnen worden geschreven. Een veld in het schema (zoals messages) kan tijdens elke interactieronde van de agent aan de LLM worden blootgesteld, maar het schema kan informatie isoleren in andere velden voor selectiever gebruik.

Conclusie

De patronen van context engineering voor agenten zijn voortdurend aan het evolueren, maar we kunnen de gebruikelijke methoden samenvatten in vier hoofdtypes—schrijven, filteren, comprimeren en isoleren:

• • Schrijven van context betekent het opslaan van informatie buiten het contextvenster voor gebruik door de agent bij het uitvoeren van taken.
• • Filteren van context betekent het inbrengen van de benodigde informatie in het contextvenster om de agent te helpen bij het uitvoeren van taken.
• • Comprimeren van context betekent dat alleen de tokens die essentieel zijn voor het uitvoeren van de taak behouden blijven.
• • Isoleren van context betekent het splitsen van de context om de agent te helpen bij het uitvoeren van zijn taken.

Het begrijpen en toepassen van deze patronen is de kern van het bouwen van efficiënte agenten vandaag de dag.

• ขีดจำกัดของตัวแทน AI ไม่ได้ขึ้นอยู่กับขนาดของโมเดลเพียงอย่างเดียว แต่ยังขึ้นอยู่กับ “ทักษะการจัดการบริบท” ด้วย มันเหมือนกับการตั้งค่าหน่วยความจำสำหรับ CPU ซึ่งกำหนดความลึกและประสิทธิภาพในการคิดของตัวแทน
• หน้าต่างบริบทไม่ใช่ถังขยะ: การเกินข้อมูลจะทำให้เกิด “การปนเปื้อน” รบกวนและทำให้การตัดสินของ AI สับสน ความแม่นยำสำคัญมากกว่าปริมาณข้อมูลมหาศาล
• ผู้เชี่ยวชาญใช้การจัดการ AI บริบทด้วยคำว่า “เขียน คัดเลือก บีบอัด และแยกแยะ” เพื่อใช้หน่วยความจำที่มีอยู่ให้เป็นประโยชน์ที่สุด ทำให้ต้นทุนลดลงและประสิทธิภาพเพิ่มขึ้น
• การแข่งขันในอนาคตคือการแข่งขันด้านประสิทธิภาพของระบบ การแยกงานด้วยโครงสร้างตัวแทนหลายตัว ให้แต่ละตัวแทนทำงานได้อย่างเต็มที่ในหน้าต่างเล็กของตน เป็นกุญแจสำคัญในการสร้างระบบงานที่ซับซ้อน

สรุปแกนหลัก

ตัวแทน (Agent) ที่ทำภารกิจไม่สามารถหลีกเลี่ยงการใช้บริบท (Context) ได้ โดย “การจัดการบริบท” เป็นศิลปะและวิทยาศาสตร์ในการเติมข้อมูลที่เหมาะสมลงในหน้าต่างบริบทของตัวแทนในทุกขั้นตอนของการทำภารกิจ บทความนี้จะสรุปกลยุทธ์การจัดการบริบทที่ตัวแทนหลัก ๆ ใช้ในปัจจุบันให้อยู่ในรูปแบบที่เข้าใจง่าย

การจัดการบริบท (Context Engineering)

ตามที่ Andrej Karpathy ได้กล่าวไว้ โมเดลภาษาใหญ่ (LLM) เปรียบเสมือน “ระบบปฏิบัติการรูปแบบใหม่” LLM คือ CPU และ “หน้าต่างบริบท” ของมันเปรียบเสมือน RAM เป็นหน่วยความจำทำงานของโมเดล ซึ่งเช่นเดียวกับที่ RAM มีขนาดจำกัด หน้าต่างบริบทของ LLM ก็มีการจำกัดเมื่อจัดการกับแหล่งข้อมูลต่างๆ หนึ่งในงานที่สำคัญที่สุดของระบบปฏิบัติการคือการจัดการการใช้ RAM ของ CPU อย่างมีประสิทธิภาพ และ “การจัดการบริบท” ก็มีบทบาทที่คล้ายกัน Karpathy สรุปไว้ได้อย่างเหมาะสมว่า:

การจัดการบริบทคือ“…… ศิลปะและวิทยาศาสตร์ในการเติมข้อมูลบริบทที่แม่นยำสำหรับการคำนวณถัดไป”

เมื่อสร้างโปรแกรม LLM เราต้องจัดการกับบริบทประเภทไหนกันบ้าง? แนวคิดเกี่ยวกับการจัดการบริบทนี้ครอบคลุมประเภทบริบทที่แตกต่างกันดังนี้:

• • คำสั่ง (Instructions) – คำแนะนำ, ความทรงจำ, ตัวอย่างน้อย, คำอธิบายเครื่องมือ ฯลฯ
• • ความรู้ (Knowledge) – ข้อเท็จจริง, ความทรงจำ ฯลฯ
• • เครื่องมือ (Tools) – ข้อมูลนำกลับจากการเรียกเครื่องมือ

การจัดการบริบทสำหรับตัวแทน

ในปีนี้ ด้วยความสามารถที่เพิ่มขึ้นของ LLM ในด้านการอนุมานและการเรียกเครื่องมือ ความสนใจในตัวแทนก็เพิ่มขึ้นอย่างมาก ตัวแทนใช้การเรียก LLM และเครื่องมือสลับกันเพื่อทำภารกิจ โดยเฉพาะอย่างยิ่งในการจัดการกับภารกิจที่ซับซ้อนที่ต้องใช้เวลานาน

อย่างไรก็ตาม ภารกิจที่ใช้เวลานานและการตอบกลับจากการเรียกเครื่องมือที่สะสมจะทำให้ตัวแทนใช้ token อย่างมาก ซึ่งอาจก่อให้เกิดปัญหาหลายประการ เช่น การเกินขีดจำกัดของหน้าต่างบริบท ทำให้ต้นทุนและความล่าช้าสูงขึ้น ลดประสิทธิภาพของตัวแทนได้ Drew Breunig ได้ชี้ให้เห็นอย่างชัดเจนว่า บริบทที่ยาวเกินไปอาจทำให้เกิดปัญหาด้านประสิทธิภาพในหลายทางดังนี้:

• • การปนเปื้อนบริบท (Context Poisoning): เมื่อข้อมูลที่ผิดพลาดเข้าสู่บริบท
• • การรบกวนบริบท (Context Distraction): เมื่อข้อมูลบริบทมากเกินไปทำให้โมเดลสูญเสียความรู้ที่ได้จากการฝึกอบรม
• • การสับสนบริบท (Context Confusion): เมื่อข้อมูลบริบทที่ไม่เกี่ยวข้องส่งผลกระทบต่อการตอบสนองของโมเดล
• • ความขัดแย้งในบริบท (Context Clash): เมื่อส่วนต่าง ๆ ของบริบทขัดแย้งกันเอง

ด้วยเหตุผลเหล่านี้ Cognition AI ได้เน้นย้ำถึงความสำคัญของการจัดการบริบทดังนี้:

“การจัดการบริบท” …… เป็นหน้าที่หลักของวิศวกรที่สร้างตัวแทน AI

บริษัท Anthropic ก็ได้เน้นถึงจุดนี้ว่า:

ตัวแทนมักต้องมีการสนทนาเป็นร้อย ๆ รอบ ซึ่งต้องการให้เรามีกลยุทธ์การจัดการบริบทที่รอบคอบ

แล้วนักพัฒนายุคนี้จัดการกับความท้าทายนี้อย่างไร? ฉันได้ทำการสรุปวิธีการที่มีอยู่เป็นสี่กลุ่ม ได้แก่ การเขียน (Write), การคัดเลือก (Select), การบีบอัด (Compress) และการแยกแยะ (Isolate) พร้อมตัวอย่างแต่ละข้อ

การเขียนข้อมูลบริบท (Write Context)

การเขียนข้อมูลบริบทหมายถึงการเก็บข้อมูลไว้ภายนอกหน้าต่างบริบทเพื่อใช้ในขณะที่ตัวแทนทำภารกิจ

พื้นที่ชั่วคราว (Scratchpads)

เมื่อมนุษย์แก้ปัญหา พวกเขามักจะจดบันทึกและจดจำสิ่งต่าง ๆ เพื่อใช้ในอนาคต ตัวแทนก็เริ่มได้รับความสามารถเหล่านี้เช่นกัน! การจดบันทึกด้วย “พื้นที่ชั่วคราว” เป็นวิธีการหนึ่งในการทำให้ข้อมูลคงอยู่ระหว่างที่ตัวแทนทำภารกิจ แนวคิดหลักคือการเก็บข้อมูลไว้ข้างนอกหน้าต่างบริบท แต่สามารถให้ตัวแทนเข้าถึงได้ทุกเมื่อ ระบบวิจัยตัวแทนหลายตัวของ Anthropic มีตัวอย่างที่ชัดเจน:

“หัวหน้าฝ่ายวิจัย” จะคิดหาวิธีในการแก้ปัญหา และบันทึกแผนไว้ใน “ความทรงจำ” เพื่อเก็บรักษาบริบท เนื่องจากเมื่อหน้าต่างบริบทเกิน 200,000 token อาจถูกตัดขาด แผนการนี้จึงมีความสำคัญมาก

การสร้างพื้นที่ชั่วคราวมีหลายวิธี สามารถเป็นการเรียกเครื่องมือที่ง่าย เช่น การเขียนไฟล์ หรืออาจเป็นฟิลด์ในวัตถุสถานะของการทำงานในระหว่างเซสชัน ไม่ว่าจะเป็นวิธีใด พื้นที่ชั่วคราวทำให้ตัวแทนสามารถเก็บข้อมูลที่มีประโยชน์ไว้เพื่อลงมือทำภารกิจได้ดียิ่งขึ้น

ความทรงจำ (Memories)

พื้นที่ชั่วคราวช่วยให้ตัวแทนแก้ปัญหาในเซสชันเดียวยังไม่เพียงพอ บางครั้งตัวแทนต้องจดจำสิ่งต่าง ๆ ข้ามเซสชัน Reflexion model ได้นำเสนอแนวคิดในการสะท้อนความคิดหลังจากการกระทำของตัวแทนแต่ละรอบ และมีการใช้ความทรงจำที่สร้างขึ้นเองซ้ำไปซ้ำมา รุ่น Generative Agents ยังสามารถสังเคราะห์ความทรงจำจากการตอบกลับในอดีตของตัวแทนในบางช่วงเวลา

แนวคิดเหล่านี้ได้ถูกนำไปใช้อย่างแพร่หลายในผลิตภัณฑ์ต่าง ๆ อย่าง ChatGPT, Cursor และ Windsurf ทั้งหมดมีระบบที่สามารถสร้างความทรงจำระยะยาวโดยอัตโนมัติตามการติดต่อของผู้ใช้กับตัวแทน

การคัดเลือกรายละเอียดบริบท (Select Context)

การคัดเลือกบริบทหมายถึงการนำข้อมูลที่จำเป็นเข้าสู่หน้าต่างบริบท เพื่อช่วยให้ตัวแทนทำภารกิจได้

พื้นที่ชั่วคราว (Scratchpad)

กลไกการคัดเลือกบริบทจากพื้นที่ชั่วคราวขึ้นอยู่กับวิธีที่มันถูกสร้างขึ้น หากเป็นเครื่องมือ ตัวแทนสามารถเรียกอ่านได้ง่าย ๆ หากเป็นส่วนหนึ่งของสถานะการทำงาน แต่ผู้พัฒนาสามารถเลือกที่จะเปิดเผยบางส่วนของสถานะไปยังตัวแทนในแต่ละขั้นตอน การนี้ทำให้สามารถควบคุมได้อย่างประณีตในการให้ข้อมูลบริบทจากพื้นที่ชั่วคราวต่อไปยัง LLM

ความทรงจำ (Memories)

หากตัวแทนสามารถรักษาความทรงจำได้ พวกเขาก็ต้องมีความสามารถในการคัดเลือกความทรงจำที่เกี่ยวข้องกับภารกิจปัจจุบันให้ได้ การคัดเลือกถูกต้องสำคัญมาก ตัวแทนสามารถเลือกตัวอย่างจำนวนไม่มาก (ความทรงจำจากเหตุการณ์) เพื่อเรียนรู้รูปแบบพฤติกรรมที่ต้องการ; หรือเลือกคำสั่ง (ความทรงจำจากโปรแกรม) เพื่อชี้แนะพฤติกรรมของตนเอง; หรือเลือกข้อเท็จจริง (ความทรงจำจากความหมาย) เพื่อให้ข้อมูลพื้นฐานที่เกี่ยวข้องกับภารกิจ

ความท้าทายใหญ่คือการรับประกันว่าความทรงจำที่คัดเลือกจะต้องเกี่ยวข้อง ตัวแทนบางตัวใช้เพียงไฟล์ฟิกแบบตายตัวเพียงไม่กี่ไฟล์ ซึ่งจะถูกโหลดลงในบริบทเสมอ ตัวอย่างเช่น ตัวแทนที่มีการเขียนโค้ดหลายตัวใช้ไฟล์ในการบันทึกคำสั่ง ( “ความทรงจำจากโปรแกรม”) หรือในบางกรณีเก็บตัวอย่าง (“ความทรงจำจากเหตุการณ์”) Claude Code ใช้ CLAUDE.md ในขณะที่ Cursor และ Windsurf ใช้ไฟล์กฎ

แต่ถ้า ตัวแทนเก็บข้อเท็จจริงหรือความสัมพันธ์ในจำนวนมาก (เช่น “ความทรงจำจากความหมาย”) การคัดเลือกก็เป็นเรื่องที่ยากขึ้น ChatGPT เป็นตัวอย่างที่ดี มันเก็บข้อมูลแล้วคัดเลือกจากความทรงจำที่เก็บไว้เฉพาะผู้ใช้

เทคนิคการดึงข้อมูลที่ใช้กันทั่วไปเพื่อช่วยในการคัดเลือกคือ การฝังเวกเตอร์และ/หรือแผนที่ความรู้ แม้ว่าการคัดเลือกความทรงจำยังเต็มไปด้วยความท้าทาย ในงาน AI Engineer World Expo Simon Willison ได้แบ่งปันตัวอย่างปัญหาในการคัดเลือก โดย ChatGPT ได้รับข้อมูลเกี่ยวกับตำแหน่งของเขา และดำเนินการแทรกลงไปในรูปภาพที่เขาขอ ซึ่งความค้นหาในความทรงจำที่ไม่คาดคิดหรือไม่พึงประสงค์นี้ทำให้ผู้ใช้บางคนรู้สึกว่าหน้าต่างบริบท “ไม่ใช่ของตนเองอีกต่อไป”!

เครื่องมือ (Tools)

ตัวแทนจำเป็นต้องใช้เครื่องมือ แต่ถ้ามีเครื่องมือมากเกินไป ตัวแทนอาจไม่สามารถจัดการได้ นี่มักเกิดจากการอธิบายเครื่องมืออาจทับซ้อนกัน ทำให้โมเดลรู้สึกสับสนในการเลือกเครื่องมือวิธีการหนึ่งที่ใช้คือการใช้ RAG (การสร้างข้อมูลเพิ่มเติม) เพื่อค้นหาเครื่องมือที่เกี่ยวข้องที่สุดสำหรับภารกิจตามความคล้ายคลึงเชิงสัญญะ งานวิจัยล่าสุดบางชิ้นพบว่าการใช้วิธีนี้สามารถเพิ่มความแม่นยำในการเลือกเครื่องมือได้ 3 เท่า

ความรู้ (Knowledge)

การสร้างข้อมูลเพิ่มเติม (RAG) เป็นหัวข้อที่ใหญ่และสามารถเป็นความท้าทายหลักของการจัดการบริบท ตัวแทนเขียนโค้ดเป็นตัวอย่างที่ดีที่สุดของ RAG ในแอปพลิเคชันที่ผลิตในขนาดใหญ่ Varun จาก Windsurf ได้สรุปความท้าทายเหล่านี้ได้ดี:

การทำดัชนีโค้ด ≠ การค้นหาบริบท ……สิ่งที่เรากำลังทำคือการวิเคราะห์โค้ดด้วย AST (ต้นไม้ไวยากรณ์นามธรรม) และแบ่งออกตามขอบเขตที่มีความหมาย… แต่เมื่อขนาดของโค้ดอูนเพิ่มขึ้น การค้นหาโดยการฝังแทรก (vector embedding search) ในน้ำนามธรรมจึงไม่เชื่อถือได้ เราต้องพึ่งพาการรวมกันของเทคนิคหลายอย่าง เช่น grep/การค้นหาไฟล์, การค้นหาตามแผนที่ความรู้ และ… กระบวนการรีสั่งที่บริบทจะถูกจัดระเบียบตามความเกี่ยวข้อง

การบีบอัดบริบท (Compress Context)

การบีบอัดบริบทหมายถึงการเก็บเฉพาะ token ที่จำเป็นต่อการทำภารกิจ

การสรุปบริบท (Context Summarization)

การโต้ตอบของตัวแทนอาจมีร้อย ๆ รอบและใช้เครื่องมือที่ใช้ token มาก การสรุปเป็นวิธีการที่ใช้กันทั่วไปเพื่อตอบสนองต่อความท้าทายเหล่านี้ หากคุณเคยใช้ Claude Code คุณอาจพบการประยุกต์ใช้ที่แท้จริง เมื่ออัตราการใช้หน้าต่างบริบทเกิน 95% Claude Code จะทำการ “บีบอัดอัตโนมัติ” สรุปการโต้ตอบทั้งหมดระหว่างผู้ใช้กับตัวแทน การบีบอัดเส้นทางการทำงานของตัวแทนสามารถใช้กลยุทธ์ได้หลากหลาย เช่น การสรุปแบบวนซ้ำหรือการสรุปในระดับชั้น

การเสริมขั้นตอนการสรุปในการออกแบบตัวแทนในเวลาที่เหมาะสมก็มีประโยชน์ โดยเฉพาะอย่างยิ่งสำหรับการประมวลผลมาตรฐานใหม่หลังจากการเรียกใช้เครื่องมือบางอย่าง (โดยเฉพาะเครื่องมือที่ใช้ token มาก เช่น เครื่องมือค้นหา) นอกจากนี้ Cognition ยังแนะนำให้ทำการสรุปที่จุดเชื่อมต่อระหว่างตัวแทน เพื่อให้ลดการใช้ token ในกระบวนการส่งต่อความรู้ หากต้องการจับเหตุการณ์หรือการตัดสินใจเฉพาะ สรุปอาจเป็นงานที่ไม่ง่าย Cognition ใช้โมเดลการปรับแต่งเพื่อเปล่งเสียง เพื่อให้เห็นถึงการทำงานอย่างมุ่งมั่นในขั้นตอนนี้

การตัดบริบท (Context Trimming)

สรุปมักใช้งาน LLM เพื่อตัดข้อมูลบริบทที่เกี่ยวข้อง ในขณะเดียวกัน การตัดบริบทนั้นเป็นเรื่องที่คล้ายกันมากขึ้น เช่น การกรองหรือตามที่ Drew Breunig อธิบายคือ “การตัด” บริบท ซึ่งสามารถใช้กฎที่กำหนดไว้อย่างเข้มงวด เช่น การลบข้อความที่เก่ากว่าออกจากรายการข้อความ Drew ยังได้แนะนำ Provence ซึ่งเป็นเครื่องตัดบริบทที่ฝึกอบรมสำหรับภารกิจการถาม-ตอบ

การแยกบริบท (Isolating Context)

การแยกบริบทหมายถึงการแบ่งข้อมูลบริบทออกเป็นส่วน ๆ เพื่อตัวแทนสามารถทำงานได้

ตัวแทนหลายตัว (Multi-agent)

หนึ่งในวิธีที่ได้รับความนิยมในการแยกบริบทคือการกระจายไปยังตัวแทนย่อยหลายตัว ไลบรารี Swarm ของ OpenAI มีวัตถุประสงค์หนึ่งคือ “การแยกประเด็น” ให้กลุ่มตัวแทนจัดการกับภารกิจย่อย แต่ละตัวแทนมีชุดเครื่องมือ คำสั่ง และหน้าต่างบริบทที่เป็นอิสระของตน

ระบบศึกษาตัวแทนหลายตัวของ Anthropic มีการยืนยันที่ชัดเจน: ตัวแทนหลายตัวที่มีบริบทเป็นอิสระนั้นมีประสิทธิภาพดีกว่าตัวแทนคนเดียว เป็นหลักเนื่องจากหน้าต่างบริบทของแต่ละตัวแทนเฉพาะโฟกัสไปที่งานย่อยที่แคบลง อย่างที่กล่าวในบล็อก:

ตัวแทนย่อยทำงานพร้อมกันโดยมีหน้าต่างบริบทของตนเอง ขณะสำรวจด้านต่าง ๆ ของปัญหา

แน่นอนว่า ตัวแทนหลายตัวก็มาท้าทายในเรื่องการใช้ token (เช่น Anthropic รายงานว่าการใช้ token ของพวกเขาคือ 15 เท่าของการสนทนา), ที่ต้องการการออกแบบคำแนะนำที่ประณีตในการวางแผนการทำงาน, และการประสานงานระหว่างตัวแทนย่อย

การแยกบริบทในสภาพแวดล้อม (Context Isolation with Environments)

โครงการ Deep Research ของ HuggingFace แสดงให้เห็นถึงอีกตัวอย่างหนึ่งของการแยกบริบทที่น่าสนใจ ตัวแทนส่วนใหญ่ใช้การเรียก API เครื่องมือซึ่งส่งกลับอ็อบเจ็กต์ JSON (พารามิเตอร์เครื่องมือ) ซึ่งจะถูกส่งไปยังเครื่องมือ (เช่น API การค้นหา) เพื่อรับข้อมูลย้อนกลับ (เช่น ผลลัพธ์การค้นหา) แต่ HuggingFace ใช้ CodeAgent ซึ่งส่งออกโค้ดที่ประกอบไปด้วยการเรียกเครื่องมือที่ต้องการ โค้ดเหล่านี้จะถูกดำเนินการในสภาพแวดล้อมของ sandbox ข้อมูลบริบทเฉพาะที่ส่งกลับ (เช่นค่าที่ส่งคืน) จะถูกส่งกลับไปยัง LLM

นี่ทำให้บริบทสามารถแยกออกจาก LLM ได้ในสภาพแวดล้อม Hugging Face กล่าวว่านี่เป็นวิธีที่ยอดเยี่ยมในการแยกอ็อบเจ็กต์ที่ใช้ token อย่างมาก:

Code Agents สามารถจัดการสถานะได้ดีกว่า … ต้องการเก็บภาพ/เสียง/ข้อมูลอื่นๆ ไว้ในภายหลัง? ไม่มีปัญหา เพียงแค่กำหนดให้เป็นตัวแปร คุณก็สามารถใช้มันในภายหลัง

สถานะ (State)

น่าสังเกตว่าสถานะของตัวแทนในการทำงานก็เป็นวิธีที่ดีในการแยกบริบท ซึ่งอาจทำหน้าที่คล้ายกับ sandbox สถานะสามารถออกแบบตามที่เป็นมาตรฐาน (Schema เช่น โมเดล Pydantic) ซึ่งรวมฟิลด์ที่จะเขียนเข้าไปในบริบท ขยายฟิลด์ในมาตรฐาน (เช่น messages) สามารถเปิดเผยให้ LLM ในทุกขั้นตอนการโต้ตอบของตัวแทน แต่แนวทางสามารถแยกข้อมูลในฟิลด์อื่น ๆ เพื่อให้ใช้เลือกสรรโดดเด่นได้ดีขึ้น

สรุป

รูปแบบของการจัดการบริบทสำหรับตัวแทนยังคงพัฒนาไปเรื่อย ๆ แต่เราสามารถสรุปวิธีการทั่วไปได้เป็นสี่ประเภท ได้แก่ การเขียน, การคัดเลือก, การบีบอัด และการแยกแยะ:

• • การเขียนบริบทหมายถึงการเก็บข้อมูลไว้ภายนอกหน้าต่างบริบทเพื่อให้ตัวแทนใช้ในขณะทำภารกิจ
• • การคัดเลือกบริบทหมายถึงการนำข้อมูลที่ต้องการเข้าสู่หน้าต่างบริบทเพื่อตัวแทนทำภารกิจได้
• • การบีบอัดบริบทหมายถึงการเก็บเฉพาะ token ที่จำเป็นสำหรับการทำภารกิจ
• • การแยกบริบทหมายถึงการแบ่งข้อมูลบริบทออกเป็นส่วน ๆ เพื่อช่วยให้ตัวแทนทำงานได้

การเข้าใจและใช้รูปแบบเหล่านี้เป็นงานหลักในการสร้างตัวแทนที่มีประสิทธิภาพในปัจจุบัน

• Batasan agen AI tidak hanya ditentukan oleh ukuran model, tetapi juga oleh keterampilan dalam “manajemen konteks.” Ini seperti mengonfigurasi memori untuk CPU, yang menentukan kedalaman dan efisiensi pemikiran agen.
• Jendela konteks bukan tempat sampah: Kelebihan informasi dapat “menyuntik racun”, mengganggu, dan membingungkan penilaian AI. Ketepatan jauh lebih penting daripada volume.
• Para ahli menggunakan empat prinsip “Menulis, Menyaring, Mengompres, dan Mengisolasi” untuk mengelola konteks AI, memanfaatkan “memori” yang terbatas di tempat yang tepat, mencapai pengurangan biaya dan peningkatan efisiensi.
• Persaingan di masa depan adalah persaingan efisiensi sistem. Menggunakan arsitektur multi-agen untuk “mengisolasi” tugas, agar setiap agen dapat berfungsi secara maksimal dalam jendela kecilnya, adalah kunci untuk membangun sistem tugas kompleks.

Ringkasan Inti

Agen (Agent) tidak bisa melaksanakan tugas tanpa konteks (Context). Apa yang disebut “rekayasa konteks” adalah seni dan ilmu menambahkan informasi yang tepat ke dalam jendela konteks agen di setiap langkah tugasnya. Artikel ini akan merangkum strategi rekayasa konteks yang diterapkan oleh agen utama saat ini, menjadi beberapa pola umum.

Rekayasa Konteks (Context Engineering)

Seperti yang dikatakan Andrej Karpathy, model bahasa besar (LLM) seperti “sistem operasi baru.” LLM adalah CPU, sementara “jendela konteks” adalah RAM, berfungsi sebagai memori kerja model. Seperti kapasitas RAM yang terbatas, jendela konteks LLM juga menghadapi kendala saat mengolah berbagai sumber konteks. Salah satu tugas inti sistem operasi adalah mengelola penggunaan RAM CPU yang efisien, dan “rekayasa konteks” berperan dalam hal yang sama. Karpathy merangkum hal ini dengan sangat baik:

Rekayasa konteks adalah “… seni dan ilmu yang cermat dalam mengisi jendela konteks agar tepat pada langkah berikutnya (perhitungan).”

Saat membangun aplikasi LLM, kita perlu mengelola jenis konteks apa saja? Konsep umum dari rekayasa konteks mencakup beberapa jenis konteks yang berbeda:

• • Instruksi (Instructions) – Prompt, memori, contoh dengan sedikit sampel, deskripsi alat, dll.
• • Pengetahuan (Knowledge) – Fakta, memori, dll.
• • Alat (Tools) – Informasi umpan balik dari pemanggilan alat.

Rekayasa Konteks untuk Agen

Tahun ini, dengan peningkatan kemampuan LLM dalam penalaran dan pemanggilan alat, minat terhadap agen semakin meningkat. Agen menyelesaikan tugas dengan bergantian memanggil LLM dan alat, khususnya unggul dalam menangani tugas kompleks yang berjalan lama.

Namun, tugas jangka panjang dan umpan balik pemanggilan alat yang terus bertambah berarti agen seringkali menghabiskan banyak token. Ini dapat menyebabkan berbagai masalah: melebihi kapasitas jendela konteks, yang mengarah pada lonjakan biaya dan keterlambatan, bahkan menurunkan kinerja agen. Drew Breunig telah menggarisbawahi dengan jelas bahwa konteks yang terlalu panjang dapat menyebabkan masalah performa dengan beberapa cara berikut:

• • Racun Konteks (Context Poisoning): Ketika informasi tersesat (khayalan) masuk ke dalam konteks.
• • Gangguan Konteks (Context Distraction): Ketika terlalu banyak informasi konteks mengaburkan pengetahuan pelatihan model asli.
• • Kebingungan Konteks (Context Confusion): Ketika informasi konteks yang tidak relevan mempengaruhi respons model.
• • Konflik Konteks (Context Clash): Ketika bagian-bagian dalam konteks saling bertentangan.

Menghadapi masalah ini, perusahaan Cognition AI menekankan pentingnya rekayasa konteks:

“Rekayasa konteks” … sebenarnya adalah tugas utama bagi para insinyur dalam membangun agen AI.

Perusahaan Anthropic juga menegaskan bahwa:

Agen biasanya perlu melakukan ratusan putaran percakapan, yang mengharuskan kita mengadopsi strategi manajemen konteks yang hati-hati.

Lalu, bagaimana pengembang masa kini menghadapi tantangan ini? Saya merangkum metode yang ada menjadi empat kategori — Menulis (Write), Menyaring (Select), Mengompres (Compress), dan Mengisolasi (Isolate) — dan masing-masing akan saya jelaskan dengan contoh.

Menulis Konteks (Write Context)

Menulis konteks berarti menyimpan informasi di luar jendela konteks, untuk digunakan saat agen melaksanakan tugas.

Tambalan (Scratchpads)

Manusia sering mencatat dan mengingat beberapa hal saat menyelesaikan masalah, untuk digunakan kembali di masa depan. Agen juga semakin memiliki kemampuan ini! Menggunakan “tambalan” untuk mencatat adalah cara untuk menyimpan informasi selama agen melaksanakan tugas. Inti dari ide ini adalah menyimpan informasi di luar jendela konteks, tetapi tetap dapat diakses oleh agen kapan saja. Sistem penelitian multi-agen dari Anthropic memberikan contoh yang jelas:

“Peneliti utama” terlebih dahulu mempertimbangkan metode penyelesaian masalah dan menyimpan rencananya ke dalam “memori” untuk memelihara konteks, karena jika jendela konteks melebihi 200.000 token, bisa jadi terputus, dan menyimpan rencana sangatlah penting.

Ada berbagai cara untuk mengimplementasikan tambalan. Ini bisa berupa pemanggilan alat sederhana, seperti menulis file; atau bisa juga berupa field dalam objek status runtime yang tetap sama sepanjang sesi. Terlepas dari cara mana yang digunakan, tambalan memungkinkan agen menyimpan informasi berguna untuk menyelesaikan tugas dengan lebih baik.

Memori (Memories)

Menggunakan tambalan membantu agen dalam menyelesaikan tugas dalam satu sesi, tetapi terkadang agen perlu mengingat hal-hal dari beberapa sesi yang berbeda. Model Reflexion memperkenalkan gagasan untuk merenungkan setelah setiap aksi agen dan menggunakan kembali memori yang dihasilkan sendiri. Model Generative Agents dapat secara berkala menyintesis memori dari kumpulan umpan balik agen di masa lalu.

Konsep-konsep ini telah diterapkan dalam produk populer seperti ChatGPT, Cursor, dan Windsurf. Semua memiliki mekanisme untuk secara otomatis menghasilkan memori jangka panjang berdasarkan interaksi pengguna dengan agen.

Menyaring Konteks (Select Context)

Menyaring konteks berarti membawa informasi yang diperlukan ke dalam jendela konteks, untuk membantu agen melaksanakan tugas.

Tambalan (Scratchpad)

Mekanisme untuk menyaring konteks dari tambalan tergantung pada cara implementasinya. Jika ia adalah sebuah alat, agen hanya perlu menggunakan panggilan alat untuk membacanya. Jika merupakan bagian dari status runtime agen, pengembang bisa memilih untuk mengekspos beberapa bagian dari status pada setiap langkah. Ini memberikan kontrol yang lebih baik dalam menyediakan konteks tambalan pada LLM di putaran berikutnya.

Memori (Memories)

Jika agen dapat menyimpan memori, mereka juga memerlukan kemampuan untuk menyaring memori yang relevan dengan tugas saat ini. Ini sangat berguna karena beberapa alasan: agen dapat memilih contoh dengan sedikit sampel (memori situasi) untuk belajar pola perilaku yang diharapkan; dapat memilih instruksi (memori program) untuk mengarahkan perilakunya sendiri; atau memilih fakta (memori semantis) untuk memberikan konteks yang relevan bagi tugas.

Salah satu tantangan besar adalah memastikan memori yang disaring adalah relevan. Beberapa agen populer hanya menggunakan sebagian kecil file yang tetap, yang selalu dimuat ke dalam konteks. Sebagai contoh, banyak agen kode menggunakan file untuk menyimpan instruksi (memori program), atau kadang-kadang menyimpan contoh (memori situasi). Claude Code menggunakan CLAUDE.md, sementara Cursor dan Windsurf menggunakan file aturan.

Namun, jika agen menyimpan sejumlah besar fakta atau hubungan (seperti jenis “memori semantis”), maka penyaringan menjadi lebih rumit. ChatGPT adalah contoh yang baik, yang menyimpan dan menyaring dari sejumlah besar memori eksklusif pengguna.

Embedding vektor dan/atau grafik pengetahuan adalah teknik umum untuk mengindeks memori, untuk mendukung penyaringan. Meskipun demikian, penyaringan memori tetap penuh tantangan. Di AI Engineer World Expo, Simon Willison berbagi contoh di mana ada kesalahan dalam penyaringan memori: ChatGPT mengambil informasi lokasi dari memorinya dan secara tidak sengaja menyuntikkannya ke dalam gambar yang dimintanya. Pengambilan memori yang tidak terduga atau yang tidak diinginkan ini dapat menyebabkan beberapa pengguna merasa bahwa jendela konteks “tidak lagi milik mereka sendiri”!

Alat (Tools)

Agen perlu menggunakan alat, tetapi jika terlalu banyak alat yang disediakan, mereka mungkin merasa terbebani. Ini sering terjadi karena deskripsi alat dapat tumpang tindih, yang menyebabkan model bingung saat memilih alat mana yang akan digunakan. Salah satu pendekatan adalah menerapkan RAG (Pengambilan Diperkuat Generatif) pada deskripsi alat, untuk mencari alat yang paling relevan untuk tugas berdasarkan kesamaan semantik. Beberapa penelitian terbaru menunjukkan bahwa pendekatan ini dapat meningkatkan akurasi pemilihan alat hingga 3 kali lipat.

Pengetahuan (Knowledge)

Pengambilan Diperkuat Generatif (RAG) merupakan topik besar yang bisa menjadi tantangan inti dalam rekayasa konteks. Agen kode adalah salah satu contoh terbaik penerapan RAG dalam aplikasi produksi skala besar. Varun dari Windsurf sangat baik dalam merangkum beberapa tantangan yang dihadapi:

Mengindeks kode ≠ Pengambilan konteks… Apa yang kami lakukan adalah menganalisis kode melalui AST (pohon sintaksis abstrak) dan memotongnya di sepanjang batas-batas yang memiliki makna semantik… Namun dengan pertumbuhan ukuran repositori kode, pencarian embedding vektor sebagai metode heuristik pencarian menjadi tidak dapat diandalkan… Kami harus bergantung pada kombinasi berbagai teknik, seperti grep/pencarian file, pencarian berbasis grafik pengetahuan, dan… langkah penyortiran ulang, di mana konteks diurutkan berdasarkan relevansi.

Mengompres Konteks (Compress Context)

Mengompres konteks berarti hanya menyimpan token yang diperlukan untuk tugas yang dijalankan.

Ringkasan Konteks (Context Summarization)

Interaksi agen mungkin melintasi ratusan putaran, menggunakan alat yang menghabiskan banyak token. Merangkum adalah cara umum untuk menghadapi tantangan ini. Jika Anda pernah menggunakan Claude Code, Anda mungkin sudah melihat aplikasi nyata dari ini. Ketika penggunaan jendela konteks melebihi 95%, Claude Code akan menjalankan “kompresi otomatis”, merangkum seluruh jejak interaksi antara pengguna dan agen. Proses kompresi atas jejak agen ini dapat menggunakan berbagai strategi, seperti ringkasan rekursif atau ringkasan berlapis.

Menambahkan langkah ringkasan dalam desain agen juga bermanfaat. Misalnya, ini bisa digunakan untuk memproses kembali beberapa pemanggilan alat (terutama alat pencarian yang banyak menghabiskan token). Misalnya, perusahaan Cognition mencatat bahwa merangkum di batas tempat agen beralih dapat mengurangi konsumsi token selama proses transfer pengetahuan. Jika perlu menangkap peristiwa atau keputusan tertentu, ringkasan mungkin lebih menantang. Untuk itu, Cognition menggunakan model yang disesuaikan, yang menunjukkan bahwa langkah ini mungkin memerlukan banyak kerja.

Pemangkasan Konteks (Context Trimming)

Ringkasan biasanya menggunakan LLM untuk mengekstrak bagian konteks yang paling relevan, sedangkan pemangkasan lebih seperti menyaring atau “memangkas” konteks, seperti yang disebutkan oleh Drew Breunig. Ini dapat menggunakan aturan heuristik berbasis kode keras, seperti menghapus pesan yang lebih lama dari daftar pesan. Drew juga menyebutkan Provence, yang merupakan alat pemangkas konteks yang dilatih untuk tugas tanya jawab.

Mengisolasi Konteks (Isolating Context)

Mengisolasi konteks berarti membagi konteks untuk membantu agen melaksanakan tugas.

Multi-agen (Multi-agent)

Salah satu cara paling populer untuk mengisolasi konteks adalah dengan menyebarkannya ke beberapa subagen. Salah satu motif dari perpustakaan Swarm milik OpenAI adalah “pemisahan fokus”, di mana sebuah tim agen menangani sub-tugas. Setiap agen memiliki set alat, instruksi, dan jendela konteks yang independen sendiri.

Sistem penelitian multi-agen dari Anthropic memberikan bukti kuat untuk hal ini: beberapa agen dengan konteks independen menunjukkan kinerja yang lebih baik daripada satu agen tunggal, sebagian besar karena jendela konteks setiap subagen dapat fokus pada sub-tugas yang lebih sempit. Seperti yang tercantum dalam blog mereka:

Subagen bekerja secara paralel dengan jendela konteks masing-masing, sembari menjelajahi berbagai aspek masalah.

Tentu saja, multi-agen juga menghadapi tantangan, termasuk konsumsi token (misalnya, Anthropic melaporkan bahwa konsumsi token mereka 15 kali lipat dari percakapan), perlu adanya rekayasa prompt yang cermat untuk merencanakan pekerjaan subagen, serta masalah koordinasi antar subagen.

Pengisolasian Konteks Melalui Lingkungan (Context Isolation with Environments)

Proyek Deep Research dari HuggingFace menunjukkan contoh menarik lainnya dalam pengisolaan konteks. Kebanyakan agen menggunakan pemanggilan alat API, yang mengembalikan objek JSON (parameter alat), kemudian disalurkan ke alat (seperti API pencarian) untuk mendapatkan umpan balik (seperti hasil pencarian). HuggingFace menggunakan CodeAgent, yang langsung mengeluarkan kode yang menyertakan pemanggilan alat yang diperlukan. Kode ini kemudian dijalankan dalam lingkungan sandbox. Konteks tertentu yang kembali dari pemanggilan alat (misalnya, nilai kembali) kemudian dikirim kembali ke LLM.

Ini memungkinkan konteks dipisahkan dari LLM dalam lingkungan. Hugging Face mencatat bahwa ini adalah cara yang sangat baik untuk mengisolasi objek yang menghabiskan banyak token:

Code Agents dapat menangani status dengan lebih baik… perlu menyimpan gambar/audio/data lain untuk referensi di masa depan? Tidak masalah, cukup alokasikan sebagai variabel, dan Anda dapat menggunakannya nanti.

Status (State)

Perlu dicatat bahwa objek status runtime agen juga merupakan cara baik untuk mengisolasi konteks. Ini berfungsi dengan cara yang mirip dengan sandbox. Objek status bisa dirancang dengan pola (Schema, seperti model Pydantic), yang mencakup field yang dapat ditulis ke dalam konteks. Salah satu field dalam pola (seperti messages) dapat diekspos ke LLM di setiap interaksi agen, tetapi pola juga dapat mengisolasi informasi di field lainnya untuk digunakan dengan lebih selektif.

Kesimpulan

Pola rekayasa konteks agen masih terus berkembang, tetapi kita dapat merangkum metode umum menjadi empat kategori — Menulis, Menyaring, Mengompres, dan Mengisolasi:

• • Menulis konteks berarti menyimpan informasi di luar jendela konteks, untuk digunakan saat agen melaksanakan tugas.
• • Menyaring konteks berarti membawa informasi yang diperlukan ke dalam jendela konteks, untuk membantu agen melaksanakan tugas.
• • Mengompres konteks berarti hanya menyimpan token yang diperlukan untuk tugas yang dijalankan.
• • Mengisolasi konteks berarti membagi konteks untuk membantu agen melaksanakan tugas.

Memahami dan menerapkan pola-pola ini adalah pekerjaan inti dalam membangun agen yang efisien saat ini.

• Обмеження AI агентів залежить не лише від розміру моделі, але й від майстерності в „управлінні контекстом“. Це можна порівняти з налаштуванням пам’яті для процесора, адже це визначає глибину і ефективність мислення агента.
• Контекстне вікно не є сміттєзвалищем: інформаційна перевантаженість може „отруювати“, перешкоджати та плутати судження AI. Точність важливіша за обсяг.
• Професіонали управляють контекстом AI за допомогою чотирьох стратегій: „запису, відбору, стиснення та ізоляції“, акцентуючи на використанні обмеженої „пам’яті“ для досягнення максимальної ефективності.
• Майбутня конкуренція — це конкуренція за ефективність систем. Використання архітектури з багатьма агентами для „ізоляції“ завдань, дозволяє кожному агенту досягти максимальних результатів у своєму власному маленькому вікні, що є ключем до створення складних систем завдань.

Основне резюме

Агенти (Agent) виконують завдання за допомогою контексту (Context). Термін „контекстне інженерство“ означає мистецтво та науку точного впровадження відповідної інформації в контекстне вікно агента на кожному етапі виконання задачі. У цій статті ми підсумовуємо основні стратегії контекстного інженерства, що використовуються сьогодні популярними агентами.

Контекстне інженерство (Context Engineering)

Як сказав Андрій Карпаті, великі мовні моделі (LLM) можна вважати „новим типом операційної системи“. LLM є ЦП, а його „контекстне вікно“ — це ОП, що слугує робочою пам’яттю моделі. Як і в ОП, обсяг контекстного вікна LLM обмежений, що створює проблеми обробки різних джерел контексту. Однією з основних завдань операційної системи є ефективне управління ОП для ЦП, що є схожою роллю для контекстного інженерства. Карпаті точно сформулював це так:

Контекстне інженерство — це „…мистецтво і наука точного заповнення контекстного вікна для наступного кроку (розрахунку)“.

При створенні додатків на основі LLM, з якими типами контексту нам потрібно працювати? Контекстне інженерство охоплює кілька різних типів контексту:

• • Інструкції (Instructions) – підказки, пам’ять, приклади з невеликою кількістю зразків, описи інструментів тощо.
• • Знання (Knowledge) – факти, пам’ять тощо.
• • Інструменти (Tools) – зворотна інформація з викликів інструментів.

Контекстне інженерство для агентів

Цього року, з покращенням можливостей LLM у розумінні та використанні інструментів, інтерес до агентів зріс. Агенти виконують завдання, по черзі використовуючи LLM та інструменти, особливо ускладнені довгострокові завдання.

Проте довгострокові завдання та постійно накопичувані відгуки з інструментів означають, що агенти зазвичай споживають велику кількість токенів. Це може призвести до багатьох проблем: перевантаження контекстного вікна, збільшення витрат та затримок, а також зниження продуктивності агента. Дрю Бреуінг чітко підкреслив, що занадто довгий контекст може призвести до проблем з продуктивністю у кількох випадках:

• • Отруєння контексту (Context Poisoning): коли в контекст потрапляють помилки (неправильна інформація).
• • Відволікання контексту (Context Distraction): коли надлишок контекстної інформації затоплює первинні знання моделі.
• • Плутанина контексту (Context Confusion): коли безвідносна інформація контексту впливає на відповіді моделі.
• • Конфлікт контексту (Context Clash): коли різні частини контексту суперечать одна одній.

Зважаючи на ці проблеми, компанія Cognition AI підкреслила важливість контекстного інженерства:

„Контекстне інженерство“… насправді є основним завданням інженерів, що створюють AI агентів.

Компанія Anthropic також зазначила:

Агенти зазвичай потребують сотень раундів діалогу, що вимагає від нас обережних стратегій управління контекстом.

То як нині розробники вирішують цю проблему? Я підсумував існуючі методи в чотирьох категоріях — запис, відбір, стиснення та ізоляція — і навів приклади.

Запис контексту (Write Context)

Запис контексту означає збереження інформації поза межами контекстного вікна для використання агентом під час виконання завдань.

Тимчасове сховище (Scratchpads)

Люди під час розв’язання проблем ведуть нотатки і запам’ятовують інформацію, щоб використовувати її в майбутніх завданнях. Агенти також поступово набувають цих можливостей! Використання „тимчасового сховища“ для нотаток — це один із способів зберігати інформацію під час виконання завдань агентом. Основна ідея полягає в тому, що інформація зберігається поза контекстним вікном, але має бути доступною для агента в будь-який момент. Дослідницька система з багатьма агентами від Anthropic надає яскравий приклад:

„Головний дослідник“ спочатку продумує метод розв’язання проблеми та зберігає свій план у „пам’яті“ для збереження контексту, оскільки, якщо токени в контекстному вікні перевищать 200 тис., це може призвести до його обрізки, тоді як збереження плану є критично важливим.

Існує кілька способів реалізації тимчасового сховища: це може бути простий виклик інструмента, наприклад запис у файл, або поле в об’єкті стану під час виконання, яке залишається незмінним протягом всієї сесії. У будь-якому випадку, тимчасове сховище дозволяє агентам зберігати корисну інформацію для кращого виконання завдань.

Пам’ять (Memories)

Тимчасове сховище допомагає агентам вирішувати завдання в межах однієї сесії, але іноді агентам потрібно запам’ятовувати речі на кількох сесіях. Модель Reflexion впровадила концепцію рефлексії після кожного раунду дій агентів, а модель Generative Agents може періодично синтезувати пам’ять з набору відгуків попередніх дій агентів.

Ці концепції вже застосовуються в популярних продуктах, таких як ChatGPT, Cursor та Windsurf. Вони всі мають механізми автоматичного генерування довгострокової пам’яті на основі взаємодії користувача з агентом.

Відбір контексту (Select Context)

Відбір контексту означає перенесення необхідної інформації в контекстне вікно, щоб допомогти агенту виконувати завдання.

Тимчасове сховище (Scratchpad)

Механізм відбору контексту з тимчасового сховища залежить від його реалізації. Якщо це інструмент, агент може звертатися до нього через виклик. Якщо це частина стану агента під час виконання, розробники можуть на кожному етапі вибірково відкривати певні частини стану для агента. Це надає тонкий контроль над тим, як на надалі контекст з тимчасового сховища передаватимся LLM.

Пам’ять (Memories)

Якщо агент може зберігати пам’ять, він також повинен мати можливість відбирати пам’ять, що стосується поточного завдання. Це є досить корисним, оскільки дозволяє агентам вибирати приклади з невеликою кількістю зразків (ситуаційна пам’ять), щоб навчитися бажаним моделям поведінки; вибирати інструкції (програмна пам’ять), щоб направити свою поведінку; або вибирати факти (семантична пам’ять), щоб надати актуальний контекст для завдання.

Однією з великих проблем є забезпечення того, щоб відібрана пам’ять була релевантною. Деякі популярні агенти використовують лише невелику частину фіксованих документів, які завжди завантажуються в контекст. Наприклад, багато кодових агентів використовують файли для збереження інструкцій (програмна пам’ять), або в деяких випадках збереження прикладів (ситуаційна пам’ять). Claude Code використовує CLAUDE.md, а Cursor і Windsurf — правила з файлами.

Проте, якщо агент зберігає велику кількість (наприклад, типу „семантична пам’ять“) фактів або взаємин, відбір стає більш складним. ChatGPT є відмінним прикладом, оскільки він зберігає і відбирає факти з великої кількості пам’яті, специфічної для користувача.

Векторні вклади та/або графи знань є популярними техніками індексації пам’яті для підтримки відбору. І незважаючи на це, відбір пам’яті залишається складним. На виставці AIEngineer Саймон Уіллісон поділився прикладом помилок під час відбору пам’яті: ChatGPT отримав його місце розташування з пам’яті і випадково вплив на зображення, яке він запитував. Таке неочікуване або небажане повернення пам’яті може зробити так, що деякі користувачі відчувають, що їхнє контекстне вікно „більше не належить їм“!

Інструменти (Tools)

Агенти повинні використовувати інструменти, але якщо доступних інструментів занадто багато, це може призвести до перевантаження. Це часто відбувається через те, що описи інструментів можуть бути перетворені, ускладнюючи агентам вибір необхідного інструмента. Один зі способів — застосування RAG (пошук, посилений генерацією) на описах інструментів, щоб знаходити найбільш релевантний інструмент для завдання на основі семантичної схожості. Останні дослідження показують, що цей метод може підвищити точність вибору інструментів втричі.

Знання (Knowledge)

Пошук, посилений генерацією (RAG), сам по собі є величезною темою і може становити основний виклик контекстного інженерства. Кодові агенти — один з найкращих прикладів RAG у масштабних виробничих програмах. Варун з Windsurf прописав деякі з викликів:

Індикація коду не дорівнює пошуку контексту… ми намагаємося розпізнати код за допомогою AST (абстрактного синтаксичного дерева) і виконувати розділення за семантични

ми межами… Але зі збільшенням масштабу кодової бази пошук векторних вкладок як метод пошуку стає ненадійним… Ми маємо покладатися на комбінацію різних технологій, таких як grep/пошук по файлах, пошук на основі графів знань, а також… етап повторного сортування, де контекст буде відсортовано за релевантністю.

Стиснення контексту (Compress Context)

Стиснення контексту означає збереження тільки тих токенів, які необхідні для виконання завдання.

Підсумування контексту (Context Summarization)

Взаємодії агента можуть тривати до сотень раундів, використовуючи інструменти, що споживають велику кількість токенів. Підсумування — це звичайний метод для подолання таких труднощів. Якщо ви використовували Claude Code, ви вже помітили, як це працює. Коли використання контекстного вікна перевищить 95%, Claude Code запускає „автоматичне стиснення“, яке підсумовує повну взаємодію між користувачем і агентом. Це підсумування може бути реалізоване через різні стратегії, такі як рекурсивне підсумовування чи ієрархічне підсумування.

Доцільно інтегрувати кроки підсумування у дизайн агентів. Наприклад, це може бути корисно для післяобробки деяких викликів інструментів (особливо таких, як інструменти пошуку, що споживають велику кількість токенів). Компанія Cognition також зазначила, що підсумування вздовж меж, де агенти переходять один до одного, може допомогти зменшити споживання токенів під час передачі знань. Якщо необхідно зафіксувати певні події або рішення, підсумування може бути складним. Cognition для цього використовує налаштовану модель, що підкреслює, скільки зусиль може знадобитися для цього кроку.

Обрізка контексту (Context Trimming)

Зазвичай підсумування використовує LLM, щоб витягти найбільш релевантні частини контексту, а обрізка може бути більш схожою на фільтрацію або, як зазначив Дрю Бреуінг, „обрізання“ контексту. Це може бути зроблено за допомогою жорсткокодованих евристичних правил, наприклад, через видалення старіших повідомлень із списку повідомлень. Дрю також згадував Provence, контекстний обрізувач, налаштований для завдань запит-відповідь.

Ізоляція контексту (Isolating Context)

Ізоляція контексту означає розділення контексту для допомоги агенту у виконанні завдань.

Багатоагентна система (Multi-agent)

Одним із найпопулярніших способів ізоляції контексту є його розподіл між кількома підагентами. Однією з мотивацій бібліотеки Swarm від OpenAI є „розділення фокусу“, тобто команда агентів, що займається підзадачами. Кожен агент має свій специфічний набір інструментів, інструкцій та незалежне контекстне вікно.

Досліджувана система з багатьма агентами від Anthropic переконливо демонструє, що кілька агентів зі незалежними контекстами перевершують єдиного агента в значній мірі, оскільки контекстні вікна кожного підагента можуть зосереджуватися на більш вузьких підзадачах. Як зазначено у їхньому блозі:

Підагенти працюють з власними контекстними вікнами паралельно, досліджуючи різні аспекти проблеми.

Звичайно, багатоагентні системи також стикаються з викликами, включаючи споживання токенів (наприклад, Anthropic повідомляє, що їхнє споживання токенів у 15 разів більше, ніж у чатових викликах), потребує продуманого процесу налаштування підказок для планування роботи підагентів, а також проблеми координації між підагентами.

Ізоляція контексту через середовища (Context Isolation with Environments)

Проект HuggingFace для глибоких досліджень демонструє ще один цікавий приклад ізоляції контексту. Більшість агентів використовують виклики інструментів API, які повертають JSON об’єкти (параметри інструментів), а потім передаються інструменту (наприклад, API пошуку) для отримання зворотного зв’язку (такого як результати пошуку). HuggingFace використовує CodeAgent, який безпосередньо виводить необхідний код для викликів інструментів. Цей код далі виконується у піщаному середовищі. Конкретний контекст, отриманий від викликів інструментів (таких як значення, що повертаються), потім передається назад до LLM.

Це дозволяє контексту бути ізольованим у середовищі від LLM. Hugging Face зазначає, що це чудовий спосіб ізолювати об’єкти, які споживають велику кількість токенів:

Code Agents краще справляються з обробкою стану… потрібно зберегти зображення/аудіо/інші дані для майбутнього? Немає проблем, просто визначте їх як змінну, і ви зможете використовувати її пізніше.

Стан (State)

Слід зазначити, що об’єкт стану агента під час виконання також є хорошим способом ізоляції контексту. Це може слугувати подібною до піщаного середовища функцією. Об’єкт стану може бути налаштований схему (Schema, наприклад, модель Pydantic), яка містить поля, що можуть бути записані в контекст. Одне з полів в схемі (наприклад, messages) може бути відкрито для LLM під час кожної взаємодії агента, але інші поля в схемі можуть ізолювати інформацію, щоб їх можна було використовувати більш вибірково.

Висновок

Моделі контекстного інженерства агентів постійно еволюціонують, але ми можемо підсумувати звичайні методи в чотири основні категорії — запис, відбір, стиснення та ізоляція:

• • Запис контексту — це збереження інформації поза контекстним вікном для використання агентом під час виконання завдань.
• • Відбір контексту — це перенесення необхідної інформації в контекстне вікно, щоб допомогти агенту виконувати завдання.
• • Стиснення контексту — це збереження тільки тих токенів, які необхідні для виконання завдання.
• • Ізоляція контексту — це розділення контексту для полегшення виконання завдань агентом.

Розуміння та використання цих методів є основною роботою при створенні ефективних агентів сьогодні.

• Limity inteligencji AI nie zależą tylko od wielkości modelu, ale również od umiejętności w zakresie „zarządzania kontekstem”. To tak, jakby prawidłowo skonfigurować pamięć RAM dla CPU — decyduje o głębokości i efektywności myślenia agenta.
• Okno kontekstowe to nie kosz na śmieci: nadmiar informacji może „zatruty”, zakłócać, mylić ocenę AI. Precyzja jest znacznie ważniejsza niż ilość.
• Mistrzowie zarządzają kontekstem AI przy pomocy czterech kroków: „pisz, wybieraj, kompresuj, izoluj”, wykorzystując ograniczoną „pamięć” w najbardziej efektywny sposób, co pozwala na redukcję kosztów i zwiększenie efektywności.
• Przyszła konkurencja to konkurencja wydajności systemów. Używając architektury wieloagentowej do „izolacji” zadań, możemy sprawić, że każdy agent osiągnie doskonałość w swoim małym oknie — to klucz do budowy skomplikowanych systemów zadaniowych.

Kluczowe podsumowanie

Agenci wykonujący zadania potrzebują kontekstu. Tak zwana „inżynieria kontekstowa” to sztuka i nauka precyzyjnego wstrzykiwania odpowiednich informacji do okna kontekstowego agenta na każdym kroku jego działania. W artykule zbiorczo przedstawiam aktualne strategie inżynierii kontekstowej stosowane przez współczesne agenty.

Inżynieria kontekstowa

Jak powiedział Andrej Karpathy, duże modele językowe (LLM) są jak nowoczesny system operacyjny. LLM działa jak CPU, a jego „okno kontekstowe” to RAM, pełniący rolę pamięci roboczej modelu. Podobnie jak RAM ma ograniczoną pojemność, okno kontekstowe LLM napotyka ograniczenia pojemności podczas przetwarzania różnych źródeł kontekstu. Jednym z głównych zadań systemu operacyjnego jest zarządzanie efektywnym wykorzystaniem RAM CPU, a „inżynieria kontekstowa” pełni podobną rolę. Karpathy bardzo trafnie podsumował to stwierdzeniem:

Inżynieria kontekstowa to „…sztuka i nauka precyzyjnego wypełniania kontekstu na następny krok (obliczenie)”.

Jakie typy kontekstu musimy zarządzać podczas budowania aplikacji LLM? Pojęcie inżynierii kontekstowej obejmuje następujące różne typy kontekstu:

• • Instrukcje (Instructions) – podpowiedzi, pamięci, przykłady z ograniczoną próbą, opisy narzędzi itp.
• • Wiedza (Knowledge) – fakty, pamięci itp.
• • Narzędzia (Tools) – informacje zwrotne z użycia narzędzi.

Inżynieria kontekstowa dla agentów

W tym roku, wraz z poprawą zdolności LLM w zakresie rozumowania i używania narzędzi, zainteresowanie agentami rośnie w szybkim tempie. Agenci wykonują zadania, naprzemiennie korzystając z LLM i narzędzi, zwłaszcza w długoterminowych, złożonych zadaniach.

Jednak długoterminowe zadania i ciągle gromadzące się informacje zwrotne z narzędzi oznaczają, że agenci zazwyczaj zużywają dużą ilość tokenów. Może to rodzić różne problemy: przekroczenie limitu pojemności okna kontekstowego, co prowadzi do wzrostu kosztów i opóźnień, a nawet obniżenia wydajności agenta. Drew Breunig wyraźnie wskazał, że zbyt długi kontekst może prowadzić do problemów z wydajnością na kilka sposobów:

• • Zatrucie kontekstu (Context Poisoning): gdy zniekształcone informacje (fałszywe dane) pojawiają się w kontekście.
• • Zakłócenie kontekstu (Context Distraction): gdy nadmiar informacji w kontekście przytłacza oryginalną wiedzę modelu.
• • Mieszanie kontekstu (Context Confusion): gdy nieistotne informacje w kontekście wpływają na odpowiedzi modelu.
• • Konflikt kontekstu (Context Clash): gdy różne części kontekstu są sprzeczne.

Biorąc pod uwagę te problemy, firma Cognition AI podkreśla znaczenie inżynierii kontekstowej:

„Inżynieria kontekstowa”…… faktycznie jest priorytetowym zadaniem inżynierów budujących inteligencję AI.

Firma Anthropic również wyraźnie zauważa:

Agenci często muszą przeprowadzić setki rund dialogów, co wymaga od nas ostrożnych strategii zarządzania kontekstem.

Jak więc obecni deweloperzy radzą sobie z tym wyzwaniem? Podzieliłem obecne metody na cztery główne kategorie — pisanie (Write), selekcja (Select), kompresja (Compress) oraz izolacja (Isolate) — i podam odpowiednie przykłady.

Pisanie kontekstu (Write Context)

Pisanie kontekstu polega na przechowywaniu informacji poza oknem kontekstowym, tak aby mogły być użyte przez agenta w trakcie wykonywania zadania.

Strefa robocza (Scratchpads)

Ludzie podczas rozwiązywania problemów robią notatki i pamiętają pewne rzeczy, aby móc wykorzystać je w przyszłości przy podobnych zadaniach. Agenci również zyskują te umiejętności! Używając „strefy roboczej” do notowania, można trwałe przechowywać informacje w trakcie wykonywania zadania przez agenta. Kluczowa idea polega na przechowywaniu informacji poza oknem kontekstowym, ale z możliwością łatwego ich wykorzystania przez agenta. System badawczy wieloaspektowy firmy Anthropic przedstawia jasny przykład:

„Główny badacz” najpierw myśli o sposobie rozwiązania problemu i zapisuje swoje plany w „pamięci”, aby zachować kontekst. Ponieważ po przekroczeniu 200 000 tokenów okno kontekstowe może zostać obcięte, zachowanie planu jest niezwykle ważne.

Strefy robocze można zaimplementować na różne sposoby. Może to być proste wywołanie narzędzia, na przykład zapisanie informacji do pliku; lub pole w obiekcie stanu podczas uruchomienia, które pozostaje niezmienne przez cały czas trwania sesji. Bez względu na metodę, strefa robocza pozwala agentowi przechowywać przydatne informacje, aby lepiej wykonać zadanie.

Pamięć (Memories)

Strefa robocza pomaga agentom w rozwiązywaniu zadań w pojedynczej sesji, ale czasami agenci muszą zapamiętać rzeczy przez wiele sesji. Model Reflexion wprowadza koncepcję refleksji po każdej akcji agenta i ponownego użycia tych samodzielnie wygenerowanych pamięci. Model Generative Agents potrafi cyklicznie syntetyzować pamięć na podstawie zbioru informacji zwrotnych od przeszłych agentów.

Te koncepcje są już wykorzystywane w popularnych produktach takich jak ChatGPT, Cursor i Windsurf. Wszystkie one mają mechanizm automatycznego generowania pamięci długoterminowej na podstawie interakcji z użytkownikami.

Selekcja kontekstu (Select Context)

Selekcja kontekstu polega na wprowadzaniu potrzebnych informacji do okna kontekstowego, aby pomóc agentowi w wykonywaniu zadania.

Strefa robocza (Scratchpad)

Mechanizm selekcji kontekstu ze strefy roboczej zależy od sposobu jej wdrożenia. Jeśli jest to narzędzie, to agent po prostu wywołuje to narzędzie, aby uzyskać dostęp do informacji. Jeśli jest to część stanu działania agenta, deweloper może w każdej chwili selektywnie ujawniać pewne części tego stanu agentowi. To zapewnia precyzyjną kontrolę nad kontekstem strefy roboczej dostarczanym do LLM w kolejnych rundach.

Pamięć (Memories)

Jeśli agent potrafi przechowywać pamięć, musi również mieć zdolność do selekcji związanych z aktualnym zadaniem informacji. Jest to bardzo przydatne z kilku powodów: agenci mogą wybierać przykłady z ograniczonej próby (pamięć sytuacyjna), aby nauczyć się oczekiwanego wzoru zachowań; mogą selekcjonować instrukcje (pamięć programu), aby kierować swoim działaniem; lub wybierać fakty (pamięć semantyczna), aby zapewnić kontekst dla zadania.

Dużym wyzwaniem jest zapewnienie, że wyselekcjonowana pamięć jest relewantna. Niektóre popularne agenty korzystają tylko z małego zasobu stałych plików, które zawsze są ładowane do kontekstu. Na przykład wiele agentów programistycznych używa plików do przechowywania instrukcji („pamięć programu”) lub w niektórych przypadkach przykładów („pamięć sytuacyjna”). Claude Code używa CLAUDE.md, podczas gdy Cursor i Windsurf korzystają z plików reguł.

Jednak, jeśli agent przechowuje dużą ilość faktów lub relacji (na przykład typu „pamięć semantyczna”), selekcja staje się bardziej skomplikowana. ChatGPT jest dobrym przykładem, wykorzystującym i przeprowadzającym selekcję z ogromnych zbiorów pamięci użytkownika.

Techniki indeksowania, takie jak osadzenia wektorowe i/lub grafy wiedzy, są powszechnie stosowane, aby ułatwić proces selekcji. Niemniej jednak, selekcja pamięci pozostaje dużym wyzwaniem. Na targach AIEngineer, Simon Willison podzielił się przykładem błędnej selekcji pamięci: ChatGPT uzyskał jego lokalizację z pamięci i przypadkowo wprowadził ją do obrazka, który zażyczył sobie użytkownik. Tego rodzaju nieoczekiwane lub niepożądane pobrania pamięci mogą sprawić, że użytkownicy poczują się tak, jakby kontekstowe okno „już nie należało do nich”!

Narzędzia (Tools)

Agenci potrzebują korzystać z narzędzi, ale jeśli dostępnych jest zbyt wiele narzędzi, mogą być przytłoczeni. Często wynika to z overlapped opisów narzędzi, co prowadzi do zamieszania w wyborze narzędzia przez model. Jednym ze sposobów jest zastosowanie RAG (retrieval-augmented generation) do opisów narzędzi, aby wybrać najbardziej odpowiednie narzędzie dla zadania na podstawie semantycznego podobieństwa. Ostatnie badania pokazują, że ta metoda może zwiększyć precyzję wyboru narzędzi trzykrotnie.

Wiedza (Knowledge)

Retrieval-augmented generation (RAG) sam w sobie jest szerokim tematem i może stać się kluczowym wyzwaniem w inżynierii kontekstowej. Agenci programistyczni są jednym z najlepszych przykładów RAG w szerokim zastosowaniu. Varun z Windsurf dobrze podsumował niektóre z tych wyzwań:

Indeksowanie kodu ≠ wyszukiwanie w kontekście…… To, co robimy, to analiza kodu za pomocą AST (drzewo składniowe) i segmentacja wzdłuż granic znaczeniowych…… W miarę jak rozrasta się biblioteka kodu, wyszukiwanie oparte na osadzeniach wektorowych staje się niewiarygodne…… Musimy polegać na kombinacji różnych technik, takich jak grep/wyszukiwanie plików, wyszukiwanie oparte na grafach wiedzy oraz…… etap przeszukiwania kontekstu, gdzie konteksty są sortowane w zależności od ich odpowiedniości.

Kompresja kontekstu (Compress Context)

Kompresja kontekstu polega na zachowaniu tylko tych tokenów, które są niezbędne do wykonania zadania.

Podsumowanie kontekstu (Context Summarization)

Interakcje agenta mogą obejmować setki rund i używać narzędzi, które konsumują dużą ilość tokenów. Podsumowywanie to powszechnie stosowana metoda radzenia sobie z tymi wyzwaniami. Jeśli korzystałeś z Claude Code, już widziałeś praktyczne zastosowanie tej zasady. Gdy użycie okna kontekstowego przekracza 95%, Claude Code uruchamia „automatyczną kompresję”, podsumowując pełną interakcję pomiędzy użytkownikiem a agentem. Kompresja trajektorii agenta może przybierać różne formy, takie jak podsumowywanie rekurencyjne lub wielopoziomowe podsumowanie.

W projektowaniu agenta pomocne jest wprowadzenia kroków podsumowania w odpowiednich momentach. Na przykład, może to być użyte przy przetwarzaniu pewnych wywołań narzędzi (szczególnie takich, które zużywają dużą ilość tokenów, jak narzędzia wyszukujące). Na przykład, firma Cognition wspomniała o zastosowaniu podsumowania na granicy przejścia pomiędzy agentami, aby zmniejszyć zużycie tokenów w procesie przekazywania wiedzy. Chociaż podsumowywanie może być wyzwaniem, gdy trzeba uchwycić konkretne zdarzenia lub decyzje, Cognition korzysta ze specyficznego modelu jak fine-tune, co podkreśla, jak wiele pracy może wymagać ten krok.

Przycinanie kontekstu (Context Trimming)

Podsumowanie zwykle wykorzystuje LLM do wyodrębnienia najbardziej istotnych fragmentów kontekstu, podczas gdy przycinanie przypomina bardziej filtrację lub, jak wspomniał Drew Breunig, „przycinanie” kontekstu. Może to być oparte na zasadach heurystycznych, takie jak usuwanie starszych wiadomości z listy wiadomości. Drew wspomniał również o Provence, narzędziu do przycinania kontekstu przeszkolonym na zadania pytania-odpowiedzi.

Izolowanie kontekstu (Isolating Context)

Izolowanie kontekstu polega na rozdzielaniu kontekstu w celu wsparcia agenta w realizacji zadań.

Wieloagenci (Multi-agent)

Jednym z najpopularniejszych sposobów izolowania kontekstu jest rozdzielanie go na różne podagenty. Motywacją dla biblioteki Swarm OpenAI jest „separacja punktów uwagi”, czyli przydzielanie zespołu agentów do obsługi podzadań. Każdy agent dysponuje swoim zestawem narzędzi, instrukcją i niezależnym oknem kontekstowym.

System badawczy wieloagentowy firmy Anthropic dostarcza solidnych dowodów na to, że kilku agentów z niezależnym kontekstem działa lepiej niż pojedynczy agent, ponieważ okna kontekstowe każdego podagenta mogą skupić się na węższym podzadaniu. Jak opisano w ich blogu:

Podagenty pracują równolegle z własnymi oknami kontekstowymi, a równocześnie eksplorują różne aspekty problemu.

Oczywiście wieloagenci również napotykają wyzwania, w tym zużycie tokenów (na przykład Anthropic zgłasza, że zużycie tokenów wynosi 15 razy więcej niż w przypadku rozmowy), konieczność starannych strategii inżynieryjnych w celu zaplanowania pracy podagentów oraz problemy ze współpracą między nimi.

Izolacja kontekstu z użyciem środowisk (Context Isolation with Environments)

Projekt badawczy HuggingFace pokazuje interesujący przykład izolacji kontekstu. Większość agentów używa wywołania API narzędzi, które zwracają obiekty JSON (parametry narzędzi), a następnie przekazywane są do narzędzi (jak API wyszukiwarki) w celu uzyskania odpowiedzi (jak wyniki wyszukiwania). HuggingFace wykorzystuje CodeAgent, który bezpośrednio zwraca kod z potrzebnymi wywołaniami narzędzi. Te kody są następnie uruchamiane w izolowanym środowisku. Tylko konkretne konteksty zwracane przez wywołania narzędzi (jak zwrócona wartość) są przesyłane z powrotem do LLM.

Dzięki temu kontekst może być izolowany w środowisku od LLM. Hugging Face wskazuje, że to doskonały sposób na izolację obiektów, które konsumują dużą ilość tokenów:

Agenci kodowi lepiej radzą sobie z stanem…… potrzebujesz przechowywać obrazy/dźwięki/inne dane do późniejszego użycia? Żaden problem, wystarczy przydzielić je jako zmienną, a potem skorzystasz z nich później.

Stan (State)

Warto również zauważyć, że obiekt stanu agenta również jest dobrą metodą na izolację kontekstu. Może to działać podobnie jak piaskownica. Obiekt stanu może mieć zaprojektowany schemat (na przykład model Pydantic), który zawiera pola mogące być zapisywane do kontekstu. Pewne pole w schemacie (np. messages) może być ujawniane agentowi w każdej interakcji, ale schemat może izolować informacje w innych polach w celu ich bardziej selektywnego wykorzystania.

Wnioski

Modele inżynierii kontekstowej agentów są w ciągłym rozwoju, ale możemy je podsumować w czterech głównych kategoriach: pisanie, selekcja, kompresja i izolacja:

• • Pisanie kontekstu, polega na przechowywaniu informacji poza oknem kontekstowym, aby można je było wykorzystać, gdy agent wykonuje zadanie.
• • Selekcja kontekstu, polega na wprowadzaniu potrzebnych informacji do okna kontekstowego, aby wspierać agenta w realizacji zadania.
• • Kompresja kontekstu, polega na zachowaniu tylko tych tokenów, które są niezbędne do wykonania zadania.
• • Izolowanie kontekstu, polega na rozdzielaniu kontekstu, aby wspierać agenta w realizacji zadań.

Zrozumienie i stosowanie tych wzorców jest kluczowym aspektem budowania efektywnych agentów dzisiaj.

• Giới hạn của AI không chỉ phụ thuộc vào kích thước mô hình, mà còn vào kỹ năng “quản lý ngữ cảnh”. Nó giống như việc cấu hình bộ nhớ cho CPU, quyết định độ sâu và hiệu quả trong suy nghĩ của tác nhân.
• Cửa sổ ngữ cảnh không phải là thùng rác: Quá tải thông tin có thể “gây ô nhiễm”, làm nhiễu loạn, và khiến AI đưa ra phán đoán sai. Độ chính xác quan trọng hơn nhiều so với việc có quá nhiều thông tin.
• Những người khéo tay sử dụng bốn nguyên tắc “Viết, Lọc, Nén, Tách” để quản lý ngữ cảnh AI, tập trung vào việc sử dụng “bộ nhớ” có hạn một cách hiệu quả, nhằm gia tăng hiệu suất và giảm chi phí.
• Sự cạnh tranh trong tương lai chính là sự cạnh tranh về hiệu suất hệ thống. Việc sử dụng kiến trúc đa tác nhân để tách biệt nhiệm vụ và cho phép mỗi tác nhân phát huy tối đa tại “cửa sổ nhỏ” của mình là điều quyết định trong việc xây dựng các hệ thống nhiệm vụ phức tạp.

Tóm Tắt Chính

Tác nhân (Agent) thực hiện nhiệm vụ không thể thiếu ngữ cảnh (Context). Kỹ thuật “ngữ cảnh” chính là nghệ thuật và khoa học trong việc chính xác cung cấp thông tin phù hợp cho cửa sổ ngữ cảnh của tác nhân tại từng bước thực hiện nhiệm vụ. Bài viết này sẽ tổng hợp các chiến lược ngữ cảnh hiện nay mà các tác nhân nổi bật đang sử dụng thành một số mô hình chung.

Kỹ Thuật Ngữ Cảnh (Context Engineering)

Như Andrej Karpathy đã nói, mô hình ngôn ngữ lớn (LLM) giống như một “hệ điều hành mới”. LLM là CPU, còn “cửa sổ ngữ cảnh” của nó giống như RAM, đóng vai trò là bộ nhớ làm việc của mô hình. Cũng giống như RAM có dung lượng hạn chế, cửa sổ ngữ cảnh của LLM cũng gặp phải giới hạn dung lượng khi xử lý nhiều nguồn ngữ cảnh khác nhau. Một trong những công việc chính của hệ điều hành là quản lý cách sử dụng RAM của CPU một cách hiệu quả, và “kỹ thuật ngữ cảnh” đóng vai trò tương tự. Karpathy đã tóm tắt điều này rất chính xác:

Kỹ thuật ngữ cảnh là “… một nghệ thuật và khoa học tinh tế trong việc chính xác bổ sung thông tin vào cửa sổ ngữ cảnh cho bước tiếp theo (tính toán).”

Khi xây dựng ứng dụng LLM, chúng ta cần quản lý những loại ngữ cảnh nào? Khái niệm tổng quát về kỹ thuật ngữ cảnh bao gồm các loại ngữ cảnh khác nhau sau đây:

• • Hướng dẫn (Instructions) – Từ khóa, trí nhớ, ví dụ với số lượng ít, mô tả công cụ, v.v.
• • Kiến thức (Knowledge) – Sự thật, trí nhớ, v.v.
• • Công cụ (Tools) – Thông tin phản hồi từ các lệnh gọi công cụ.

Kỹ Thuật Ngữ Cảnh Hướng Tới Tác Nhân

Năm nay, với sự gia tăng khả năng của LLM trong việc suy luận và gọi công cụ, sự quan tâm đối với các tác nhân ngày càng tăng lên. Tác nhân thực hiện nhiệm vụ bằng cách luân phiên gọi LLM và công cụ, đặc biệt xuất sắc trong việc xử lý các nhiệm vụ phức tạp kéo dài.

Tuy nhiên, các nhiệm vụ dài hạn và phản hồi từ việc gọi công cụ liên tục có nghĩa là tác nhân thường tiêu tốn nhiều token. Điều này có thể dẫn đến nhiều vấn đề: vượt quá giới hạn dung lượng của cửa sổ ngữ cảnh, dẫn đến gia tăng chi phí và độ trễ, thậm chí giảm hiệu suất của tác nhân. Drew Breunig đã chỉ ra rõ ràng rằng, ngữ cảnh quá dài có thể gây ra các vấn đề hiệu suất qua những cách sau:

• • Ngữ cảnh bị ô nhiễm (Context Poisoning): Khi thông tin sai lệch (mê mờ) vào ngữ cảnh.
• • Ngữ cảnh phân tán (Context Distraction): Khi thông tin ngữ cảnh quá nhiều, làm cho mô hình bị ngợp trước kiến thức huấn luyện ban đầu.
• • Ngữ cảnh bị nhầm lẫn (Context Confusion): Khi thông tin ngữ cảnh không liên quan ảnh hưởng đến phản hồi của mô hình.
• • Ngữ cảnh mâu thuẫn (Context Clash): Khi các phần khác nhau trong ngữ cảnh mâu thuẫn với nhau.

Xem xét các vấn đề này, công ty Cognition AI đã nhấn mạnh tầm quan trọng của kỹ thuật ngữ cảnh:

“Kỹ thuật ngữ cảnh”… thực sự là nhiệm vụ hàng đầu của kỹ sư xây dựng AI.

Công ty Anthropic cũng chỉ ra rõ ràng:

Tác nhân thường cần thực hiện hàng trăm lượt đối thoại, điều này yêu cầu chúng tôi áp dụng các chiến lược quản lý ngữ cảnh cẩn trọng.

Vậy, hiện nay các nhà phát triển đang đối mặt với thách thức này như thế nào? Tôi sẽ tổng hợp các phương pháp hiện có thành bốn loại — Viết (Write), Lọc (Select), Nén (Compress) và Tách Rời (Isolate) — và đưa ra ví dụ cho từng loại.

Viết Ngữ Cảnh (Write Context)

Viết ngữ cảnh là chỉ việc lưu giữ thông tin bên ngoài cửa sổ ngữ cảnh, để tác nhân có thể sử dụng khi thực hiện nhiệm vụ.

Bảng Ghi Chú (Scratchpads)

Con người trong quá trình giải quyết vấn đề thường ghi chú và nhớ một số điều để sử dụng trong tương lai khi xử lý các nhiệm vụ liên quan. Tác nhân cũng đang dần có được những khả năng này! Việc ghi chú trong “bảng ghi chú” là một phương pháp lâu dài giúp lưu trữ thông tin trong khi tác nhân thực hiện nhiệm vụ. Ý tưởng cốt lõi là lưu trữ thông tin bên ngoài cửa sổ ngữ cảnh nhưng lại có thể được truy cập bất cứ lúc nào. Hệ thống nghiên cứu đa tác nhân của Anthropic cung cấp một ví dụ rõ ràng:

“Nghiên cứu viên chính” sẽ suy nghĩ về cách giải quyết vấn đề và lưu kế hoạch vào “trí nhớ” để duy trì ngữ cảnh, bởi vì một khi cửa sổ ngữ cảnh vượt quá 200,000 token, nó có thể bị cắt đứt, do đó việc giữ kế hoạch rất quan trọng.

Có nhiều cách để thực hiện bảng ghi chú này. Nó có thể là một lệnh gọi công cụ đơn giản, chẳng hạn như ghi vào một tệp; hoặc có thể là một trường trong đối tượng trạng thái tại thời điểm chạy, giữ nguyên trong suốt phiên làm việc. Dù theo cách nào, bảng ghi chú cho phép tác nhân lưu giữ thông tin hữu ích để hoàn thành nhiệm vụ tốt hơn.

Trí Nhớ (Memories)

Bảng ghi chú giúp tác nhân giải quyết nhiệm vụ trong một phiên, nhưng đôi khi tác nhân cần nhớ những điều qua nhiều phiên. Mô hình Reflexion đã cho ra ý tưởng về việc phản ánh sau mỗi lượt hành động của tác nhân và tái sử dụng trí nhớ tự tạo. Mô hình Generative Agents có khả năng tổng hợp trí nhớ định kỳ từ bộ phản hồi của các tác nhân trong quá khứ.

Những khái niệm này đã được áp dụng trong các sản phẩm phổ biến như ChatGPT, Cursor và Windsurf. Tất cả đều có cơ chế tự động tạo trí nhớ lâu dài dựa trên sự tương tác giữa người dùng và tác nhân.

Lọc Ngữ Cảnh (Select Context)

Lọc ngữ cảnh là việc kéo thông tin cần thiết vào cửa sổ ngữ cảnh, để giúp tác nhân thực hiện nhiệm vụ.

Bảng Ghi Chú (Scratchpad)

Cơ chế lọc ngữ cảnh từ bảng ghi chú phụ thuộc vào cách thức thực hiện. Nếu nó là một công cụ, tác nhân chỉ cần gọi công cụ để đọc. Nếu nó là một phần của trạng thái hoạt động của tác nhân, nhà phát triển có thể chọn lọc từng phần của trạng thái để cung cấp cho tác nhân ở mỗi bước. Điều này cho phép kiểm soát chính xác việc cung cấp ngữ cảnh từ bảng ghi chú cho LLM trong các lượt sau.

Trí Nhớ (Memories)

Nếu tác nhân có khả năng lưu trữ trí nhớ, chúng cũng cần khả năng lọc trí nhớ có liên quan đến nhiệm vụ hiện tại. Điều này rất hữu ích vì một số lý do: tác nhân có thể chọn ví dụ với số lượng ít (trí nhớ bối cảnh) để học mẫu hành vi mong muốn; có thể chọn hướng dẫn (trí nhớ chương trình) để định hướng hành vi của chính mình; hoặc chọn sự thật (trí nhớ ngữ nghĩa) để cung cấp bối cảnh liên quan cho nhiệm vụ.

Một thách thức lớn là đảm bảo rằng trí nhớ được lọc ra là liên quan. Một số tác nhân phổ biến chỉ sử dụng một lượng nhỏ tệp tĩnh, những tệp này luôn được nạp vào ngữ cảnh. Ví dụ, nhiều tác nhân mã sử dụng tệp để lưu ý hướng dẫn (“trí nhớ chương trình”), hoặc trong một số trường hợp, lưu giữ ví dụ (“trí nhớ bối cảnh”). Claude Code sử dụng CLAUDE.md, trong khi Cursor và Windsurf sử dụng tệp quy tắc.

Tuy nhiên, nếu tác nhân lưu trữ một số lượng lớn thông tin (ví dụ như loại “trí nhớ ngữ nghĩa”), việc lọc trở nên khó khăn hơn. ChatGPT là một ví dụ tốt, nó lưu trữ và lọc từ một lượng lớn trí nhớ của người dùng.

Embedding vector và/hoặc đồ thị tri thức là những kỹ thuật chỉ mục trí nhớ thường được sử dụng để hỗ trợ lọc. Dù vậy, việc lọc trí nhớ vẫn gặp nhiều thách thức. Tại Hội nghị Thế giới về kỹ sư AI, Simon Willison đã chia sẻ một ví dụ về việc lọc trí nhớ gây lỗi: ChatGPT đã lấy thông tin vị trí của anh từ trí nhớ và vô tình đưa nó vào bức ảnh mà anh yêu cầu. Việc truy xuất trí nhớ khó lường hoặc không mong muốn này có thể khiến một số người dùng cảm thấy cửa sổ ngữ cảnh “không còn thuộc về họ” nữa!

Công Cụ (Tools)

Tác nhân cần sử dụng công cụ, nhưng nếu công cụ cung cấp quá nhiều, chúng có thể bị quá tải. Thường thì điều này xảy ra vì mô tả công cụ có thể chồng chéo, gây bối rối cho mô hình khi lựa chọn công cụ nào. Một phương pháp là ứng dụng RAG (Tìm kiếm Tăng cường) vào mô tả công cụ, nhằm tìm kiếm công cụ có liên quan nhất cho nhiệm vụ dựa trên độ tương đồng ngữ nghĩa. Một số luận văn gần đây đã chỉ ra rằng phương pháp này có thể cải thiện độ chính xác trong việc lựa chọn công cụ gấp ba lần.

Kiến Thức (Knowledge)

Tìm kiếm Tăng cường (RAG) tự thân nó là một chủ đề rộng lớn và có thể trở thành thách thức chính trong kỹ thuật ngữ cảnh. Tác nhân mã là một trong những ví dụ tốt nhất về việc RAG được ứng dụng quy mô lớn. Varun của Windsurf đã tóm tắt một số thách thức:

Lập chỉ mục mã ≠ tìm kiếm ngữ cảnh…… Những gì chúng tôi đang làm là phân tích mã thông qua AST (Cây cú pháp trừu tượng) và phân khúc theo các ranh giới có ý nghĩa ngữ nghĩa…… Tuy nhiên, với việc mở rộng quy mô thư viện mã, tìm kiếm bằng embedding vector như một phương pháp tìm kiếm trở nên không đáng tin…… Chúng tôi phải dựa vào tổ hợp nhiều công nghệ, chẳng hạn như tìm kiếm grep/tệp, tìm kiếm dựa trên đồ thị tri thức, và…… một bước tái sắp xếp, trong đó ngữ cảnh sẽ được sắp xếp theo độ liên quan.

Nén Ngữ Cảnh (Compress Context)

Nén ngữ cảnh là việc chỉ giữ lại những token cần thiết cho việc thực hiện nhiệm vụ.

Tóm Tắt Ngữ Cảnh (Context Summarization)

Sự tương tác của tác nhân có thể kéo dài hàng trăm lượt, và sử dụng các công cụ tiêu tốn nhiều token. Tóm tắt là một phương pháp phổ biến để đối phó với những thách thức này. Nếu bạn đã sử dụng Claude Code, bạn đã thấy ứng dụng thực tế của nó. Khi mức sử dụng cửa sổ ngữ cảnh vượt quá 95%, Claude Code sẽ thực hiện “nén tự động”, tóm tắt toàn bộ chuỗi tương tác giữa người dùng và tác nhân. Việc nén chuỗi tương tác của tác nhân có thể thực hiện theo nhiều chiến lược, chẳng hạn như tóm tắt đệ quy hoặc tóm tắt phân cấp.

Việc kịp thời bổ sung bước tóm tắt trong thiết kế của tác nhân cũng rất có lợi. Chẳng hạn, nó có thể được sử dụng để xử lý một số lần gọi công cụ (đặc biệt là những công cụ tiêu tốn nhiều token như công cụ tìm kiếm). Ngoài ra, công ty Cognition đã đề xuất tiến hành tóm tắt ở các ranh giới khi chuyển giao giữa tác nhân với tác nhân, nhằm giảm tiêu hao token trong quá trình truyền đạt kiến thức. Nếu cần nắm bắt các sự kiện hoặc quyết định cụ thể, việc tóm tắt có thể trở nên khó khăn. Cognition đã sử dụng một mô hình tinh chỉnh cho điều này, cho thấy rằng bước này có thể đòi hỏi một khối lượng công việc lớn.

Cắt Bớt Ngữ Cảnh (Context Trimming)

Tóm tắt thường dùng LLM để chiết xuất các đoạn ngữ cảnh có liên quan nhất, trong khi việc cắt bớt thì giống như việc lọc hay “cắt tỉa” như cách Drew Breunig đã nói. Điều này có thể được thực hiện theo quy tắc hướng dẫn được mã hóa cứng, chẳng hạn như loại bỏ các thông điệp cũ hơn khỏi danh sách thông điệp. Drew cũng đã đề cập đến Provence, một trình cắt bớt ngữ cảnh được huấn luyện cho nhiệm vụ hỏi đáp.

Tách Rời Ngữ Cảnh (Isolating Context)

Tách rời ngữ cảnh là việc chia nhỏ ngữ cảnh ra để giúp tác nhân thực hiện nhiệm vụ.

Đa Tác Nhân (Multi-agent)

Một trong những cách phổ biến để tách rời ngữ cảnh là phân chia nó thành nhiều tác nhân phụ. Một động lực cho thư viện Swarm của OpenAI chính là “phân tách điểm chú ý”, tức là để một đội ngũ tác nhân xử lý các nhiệm vụ con. Mỗi tác nhân có bộ công cụ riêng, hướng dẫn và cửa sổ ngữ cảnh độc lập.

Hệ thống nghiên cứu đa tác nhân của Anthropic đã cung cấp chứng cứ mạnh mẽ cho điều này: nhiều tác nhân với ngữ cảnh độc lập thể hiện hiệu suất tốt hơn so với một tác nhân đơn lẻ, phần lớn là nhờ vào việc mỗi cửa sổ ngữ cảnh của các tác nhân phụ có thể tập trung vào một nhiệm vụ con hẹp hơn. Như blog của họ đã đề cập:

Các tác nhân phụ hoạt động song song trong khi mang theo những cửa sổ ngữ cảnh của riêng mình, khám phá các khía cạnh khác nhau của vấn đề.

Tất nhiên, đa tác nhân cũng phải đối mặt với những thách thức, bao gồm việc tiêu tốn token (ví dụ: Anthropic báo cáo rằng lượng token sử dụng của họ cao hơn gấp 15 lần so với một cuộc trò chuyện), cần phải có kỹ thuật gợi ý cẩn thận để lập kế hoạch cho công việc của các tác nhân phụ, và các vấn đề phối hợp giữa chúng.

Tách Rời Ngữ Cảnh Bằng Môi Trường (Context Isolation with Environments)

Dự án Deep Research của HuggingFace đã trình bày một ví dụ thú vị khác về việc tách rời ngữ cảnh. Hầu hết các tác nhân sử dụng các lệnh gọi công cụ API, những API này trả về các đối tượng JSON (các tham số công cụ), rồi được gửi cho công cụ (như API tìm kiếm) để lấy phản hồi (như kết quả tìm kiếm). HuggingFace thì sử dụng một CodeAgent, nó trực tiếp xuất mã bao gồm các lệnh gọi công cụ cần thiết. Những mã này sau đó được chạy trong một môi trường sandbox. Chỉ có ngữ cảnh cụ thể từ lệnh gọi công cụ (như giá trị trả về) được truyền lại cho LLM.

Điều này cho phép ngữ cảnh được tách rời trong môi trường với LLM. Hugging Face chỉ ra rằng đây là một cách tuyệt vời để tách rời các đối tượng tiêu tốn nhiều token:

Các Code Agents có khả năng quản lý trạng thái tốt hơn…… Cần lưu trữ hình ảnh/âm thanh/dữ liệu khác để sử dụng sau? Không thành vấn đề, chỉ cần phân bổ nó như một biến, và bạn có thể sử dụng nó sau này.

Trạng Thái (State)

Điều đáng lưu ý là trạng thái đang chạy của tác nhân cũng là một cách tốt để tách rời ngữ cảnh. Nó có thể hoạt động tương tự như môi trường sandbox. Trạng thái có thể được thiết kế theo một mẫu (Schema, chẳng hạn như mô hình Pydantic) với các trường có thể ghi vào ngữ cảnh. Một trường trong mẫu (như messages) có thể được đưa ra cho LLM trong mỗi lượt tương tác của tác nhân, nhưng mẫu có thể giữ thông tin tách biệt ở các trường khác để sử dụng một cách chọn lọc hơn.

Kết Luận

Các mô hình kỹ thuật ngữ cảnh cho tác nhân vẫn đang liên tục phát triển, nhưng chúng ta có thể tổng hợp các phương pháp phổ biến thành bốn loại — Viết, Lọc, Nén và Tách Rời:

• • Viết ngữ cảnh, là việc lưu giữ thông tin bên ngoài cửa sổ ngữ cảnh, để tác nhân có thể sử dụng khi thực hiện nhiệm vụ.
• • Lọc ngữ cảnh, là việc kéo thông tin cần thiết vào cửa sổ ngữ cảnh, để giúp tác nhân thực hiện nhiệm vụ.
• • Nén ngữ cảnh, là việc chỉ giữ lại những token cần thiết cho việc thực hiện nhiệm vụ.
• • Tách rời ngữ cảnh, là việc chia nhỏ ngữ cảnh ra, để giúp tác nhân thực hiện nhiệm vụ.

Hiểu và áp dụng những mô hình này là công việc trung tâm trong việc xây dựng các tác nhân hiệu quả trong thời đại ngày nay.

• AI 에이전트의 한계는 모델의 크기뿐만 아니라 ‘컨텍스트 관리’라는 기술에도 달려 있습니다. 이는 CPU에 메모리를 배치하는 것과 같아, 에이전트의 사고 깊이와 효율성을 결정합니다.
• 컨텍스트 윈도우는 쓰레기통이 아닙니다: 정보 과부하는 AI 판단에 ‘독을 주고’, 방해하며, 혼란을 일으킬 수 있습니다. 정확성이 대량보다 더 중요합니다.
• 숙련된 사람은 ‘쓰기, 선별, 압축, 격리’의 네 가지 기술로 AI 컨텍스트를 관리하며, 한정된 ‘메모리’를 효율적으로 사용하여 비용 절감과 효율성을 동시에 이룩합니다.
• 미래의 경쟁은 시스템 효율성에 대한 경쟁입니다. 다중 에이전트 구조를 통해 작업을 ‘격리’시키고, 각 에이전트가 자신의 작은 창에서 최선을 다할 수 있도록 하는 것이 복잡한 작업 시스템 구축의 핵심입니다.

핵심 요약

에이전트(Agent)는 작업 수행에 컨텍스트(Context)가 필수적입니다. ‘컨텍스트 엔지니어링’은 에이전트가 작업을 수행하는 모든 단계에서, 그들의 컨텍스트 윈도우에 적절한 정보를 정확하게 주입하는 기술과 과학의 예술입니다. 본문에서는 현재 주요 에이전트들이 채택하고 있는 컨텍스트 엔지니어링 전략을 몇 가지 일반적인 모드로 요약합니다.

컨텍스트 엔지니어링 (Context Engineering)

Andrej Karpathy가 말했듯이, 대형 언어 모델(LLM)은 일종의 ‘신형 운영 체제’와 같습니다. LLM은 CPU와 같고, 그 ‘컨텍스트 윈도우’는 RAM의 역할을 하여 모델의 작업 기억을 담당합니다. RAM의 용량이 한정된 것처럼, LLM의 컨텍스트 윈도우도 다양한 컨텍스트 출처를 처리할 때 용량의 병목현상에 직면합니다. 운영 체제의 핵심 작업 중 하나는 CPU의 RAM을 효율적으로 사용하는 방법을 관리하는 것이며, ‘컨텍스트 엔지니어링’도 비슷한 역할을 합니다. Karpathy는 이를 매우 잘 요약했습니다:

“컨텍스트 엔지니어링은 다음 단계(계산)에 정확히 맞는 컨텍스트 윈도우를 채우는 정교한 예술과 과학입니다.”

LLM 애플리케이션을 구축할 때 어떤 유형의 컨텍스트를 관리해야 할까요? ‘컨텍스트 엔지니어링’이라는 총괄 개념은 다음과 같은 다양한 컨텍스트 유형을 포함합니다:

• • 지시(Instructions) – 프롬프트, 기억, 소수 샘플 예시, 도구 설명 등
• • 지식(Knowledge) – 사실, 기억 등
• • 도구(Tools) – 도구 호출에 대한 피드백 정보

에이전트를 위한 컨텍스트 엔지니어링

올해 LLM이 추론과 도구 호출 능력에서 발전함에 따라, 에이전트에 대한 관심이 날로 증가하고 있습니다. 에이전트는 LLM과 도구를 교차적으로 호출하여 작업을 수행하며, 특히 장기간의 복잡한 작업을 처리하는 데 강점을 보입니다.

하지만 장기 작업과 누적되는 도구 호출 피드백은 에이전트가 일반적으로 많은 수의 토큰을 소모하게 만듭니다. 이로 인해 여러 가지 문제가 발생할 수 있습니다: 컨텍스트 윈도우의 용량 제한 초과, 비용과 지연의 급증, 심지어는 에이전트 성능 저하까지. Drew Breunig는 지나치게 긴 컨텍스트가 성능 문제를 초래할 수 있는 몇 가지 방법을 명확하게 지적했습니다:

• • 컨텍스트 독성(Context Poisoning): 환각(잘못된 정보)이 컨텍스트에 포함될 때.
• • 컨텍스트 방해(Context Distraction): 컨텍스트 정보가 과도하게 많아 모델의 원래 훈련 지식을 압도할 때.
• • 컨텍스트 혼란(Context Confusion): 관련 없는 컨텍스트 정보가 모델의 응답에 영향을 미칠 때.
• • 컨텍스트 충돌(Context Clash): 컨텍스트의 서로 다른 부분이 상충할 때.

이러한 문제를 고려하여, Cognition AI는 컨텍스트 엔지니어링의 중요성을 강조했습니다:

“컨텍스트 엔지니어링”은 AI 에이전트를 구축하는 엔지니어에게 주된 과제입니다.

Anthropic 또한 명확하게 언급했습니다:

에이전트는 일반적으로 수백 차례의 대화를 수행해야 하므로, 신중한 컨텍스트 관리 전략이 필요합니다.

그렇다면 요즘의 개발자들은 이 도전에 어떻게 대응하고 있을까요? 저는 현재의 방법을 네 가지 범주로 요약했습니다 — 쓰기(Write), 선별(Select), 압축(Compress), 격리(Isolate) — 각 항목에 대한 예를 들어 설명하겠습니다.

컨텍스트 쓰기 (Write Context)

컨텍스트 쓰기는 정보를 컨텍스트 윈도우 밖에 저장하여, 에이전트가 작업을 수행할 때 사용할 수 있도록 하는 것을 의미합니다.

임시 저장소(Scratchpads)

인간은 문제를 해결할 때 메모를 하거나 어떤 것을 기억해 두어, 나중에 관련 작업을 처리할 때 참고합니다. 에이전트도 이러한 능력을 점차 갖추고 있습니다! ‘임시 저장소’를 통해 메모를 하는 것은 에이전트가 작업 수행 중에 정보를 영구적으로 저장하는 방법입니다. 핵심 아이디어는 정보를 컨텍스트 윈도우 밖에 보관하되, 언제든지 에이전트가 접근할 수 있도록 하는 것입니다. Anthropic의 다중 에이전트 연구 시스템은 이를 명확하게 보여줍니다:

“수석 연구원”은 먼저 문제 해결 방법을 생각하고, 그것을 ‘기억’에 저장하여 컨텍스트를 영구화합니다. 왜냐하면 컨텍스트 윈도우가 20만 토큰을 초과하면 단절될 수 있기 때문에, 계획을 보존하는 것이 매우 중요합니다.

임시 저장소는 다양한 방식으로 구현될 수 있습니다. 단순한 도구 호출처럼 파일에 정보를 기록하거나, 실행 시 상태 객체의 필드로 유지하여 전체 세션 동안 변하지 않도록 할 수 있습니다. 어떤 방식이든 이 임시 저장소는 에이전트가 유용한 정보를 보존하여 작업을 보다 잘 수행할 수 있도록 합니다.

기억(Memories)

임시 저장소는 에이전트가 단일 세션에서 작업을 해결하는 데 도움이 되지만, 때때로 에이전트는 여러 세션에 걸쳐 일을 기억해야 할 필요가 있습니다. Reflexion 모델은 에이전트의 행동 후 반성하는 과정을 도입하고, 이러한 자가 생성된 기억을 재활용하는 개념을 제안했습니다. Generative Agents 모델은 과거 에이전트의 피드백 집합에서 주기적으로 기억을 합성할 수 있습니다.

이러한 개념은 ChatGPT, Cursor 및 Windsurf와 같은 인기 있는 제품에 적용되었습니다. 이들 모두는 사용자와 에이전트 간의 상호작용을 기반으로 자동으로 장기 기억을 생성하는 메커니즘을 갖추고 있습니다.

컨텍스트 선별 (Select Context)

컨텍스트 선별은 필요한 정보를 컨텍스트 윈도우로 가져와 에이전트가 작업을 수행하는 데 도움을 주는 것입니다.

임시 저장소(Scratchpad)

임시 저장소에서 컨텍스트를 선별하는 메커니즘은 그 구현 방식에 따라 다릅니다. 만약 그것이 도구라면, 에이전트는 도구 호출을 통해 읽기만 하면 됩니다. 에이전트의 실행 상태의 일부라면, 개발자는 각 단계에서 상태의 일부를 선택적으로 에이전트에게 노출할 수 있습니다. 이는 후속 라운드에서 LLM에 임시 저장소의 컨텍스트를 제공하는 데 세밀한 제어를 제공합니다.

기억(Memories)

에이전트가 기억을 저장할 수 있는 능력이 있다면, 현재 작업과 관련된 기억을 선별할 수 있는 능력도 필요합니다. 이는 여러 이유로 매우 유용합니다: 에이전트는 소수 샘플 예시(상황 기억)를 선택하여 기대하는 행동 패턴을 학습할 수 있고; 지시(프로그램 기억)를 선택하여 자신의 행동을 안내할 수 있으며; 또는 사실(의미 기억)을 선택하여 작업에 관련된 배경을 제공할 수 있습니다.

주요 도전 과제는 선별된 기억이 관련성이 있는지를 보장하는 것입니다. 일부 인기 있는 에이전트는 항상 고정된 소량의 파일만 사용하여, 이 파일들은 항상 컨텍스트에 로드됩니다. 예를 들어, 많은 코드 에이전트는 지시 사항(“프로그램 기억”)을 저장하는 파일을 사용하거나, 경우에 따라 예시(“상황 기억”)를 저장합니다. Claude Code는 CLAUDE.md를 사용하고, Cursor와 Windsurf는 규칙 파일을 사용합니다.

하지만 에이전트가 많은 양의(예: “의미 기억” 유형의) 사실이나 관계를 저장하면, 선별이 더욱 어려워집니다. ChatGPT는 많은 사용자 전용 기억을 저장하고 그 중에서 선별하는 훌륭한 예시입니다.

벡터 임베딩 및/또는 지식 그래프는 선별을 돕기 위한 일반적인 기억 인덱스 기술입니다. 그럼에도 불구하고 기억 선별은 여전히 도전과제가 많습니다. AIEngineer 세계 박람회에서는 Simon Willison이 기억 선별에서의 오류 사례를 공유했습니다: ChatGPT는 그의 위치 정보를 기억에서 가져와, 그가 요청한 이미지에 원치 않게 삽입했습니다. 이러한 의도치 않거나 바람직하지 않은 기억 검색은 일부 사용자에게 컨텍스트 창이 “더 이상 자신에게 속하지 않는다”라는 느낌을 줄 수 있습니다!

도구(Tools)

에이전트는 도구를 사용할 필요가 있지만, 제공되는 도구가 너무 많은 경우, 에이전트는 과부하에 시달릴 수 있습니다. 이는 종종 도구 설명이 중복되어 어떤 도구를 선택할지 혼란스러워지기 때문입니다. 한 가지 방법은 도구 설명에 RAG(검증 강화 생성)를 적용하여, 의미의 유사성에 따라 가장 관련성이 높은 도구를 검색하는 것입니다. 최근의 몇몇 논문에서는 이러한 방법이 도구 선택의 정확도를 3배 향상할 수 있음을 보여주었습니다.

지식(Knowledge)

검색 강화 생성(RAG) 자체는 방대한 주제이며, 컨텍스트 엔지니어링의 핵심 도전이 될 수 있습니다. 코드 에이전트는 발전된 RAG의 대규모 실용 사례 중 하나입니다. Windsurf의 Varun은 이와 관련된 몇 가지 도전 과제를 잘 정리했습니다:

코드 인덱싱은 ≠ 컨텍스트 검색입니다… 우리가 하고 있는 것은 AST(추상 구문 트리)를 통해 코드를 분석하고 의미적으로 의미가 있는 경계에 따라 분할하는 것입니다… 하지만 코드 라이브러리의 규모가 커짐에 따라, 벡터 임베딩 검색이 검색의 열쇠 방법으로서 신뢰할 수 없게 됩니다… 우리는 grep/파일 검색, 지식 그래프 기반 검색 및 관련성을 기준으로 정렬하는 단계와 같은 여러 기술의 조합에 의존해야 합니다.

컨텍스트 압축 (Compress Context)

컨텍스트 압축은 작업 수행에 필요한 토큰만 남기는 것을 말합니다.

컨텍스트 요약 (Context Summarization)

에이전트의 상호작용은 수백 번에 걸쳐 진행될 수 있으며, 토큰을 많이 소비하는 도구를 사용할 수 있습니다. 요약은 이러한 도전 과제에 대응하는 일반적인 방법입니다. 만약 당신이 Claude Code를 사용해 본 적이 있다면, 그 실제 적용 사례를 이미 보았을 것입니다. 컨텍스트 윈도우의 사용율이 95%를 초과하면, Claude Code는 ‘자동 압축’을 실행하여 사용자와 에이전트 간의 전체 상호작용 경로를 요약합니다. 이러한 에이전트 경로의 압축은 여러 가지 전략으로 이루어질 수 있으며, 예를 들어 재귀적 요약이나 계층적 요약이 포함될 수 있습니다.

에이전트 설계에서 적절한 시점에 요약 단계를 포함하는 것도 유용합니다. 예를 들어, 특정 도구 호출(특히 많은 토큰을 소모하는 검색 도구 등)의 후처리에 사용되거나, Cognition 회사에서는 에이전트 간의 정보 전달 과정에서 요약을 수행하여 토큰 소모를 줄이는 방법을 제안했습니다. 특정 사건이나 결정을 포착해야 할 경우, 요약이 어려울 수 있습니다. Cognition은 이러한 이유로 미세 조정 모델을 사용하여 이 단계가 필요한 많은 작업을 강조했습니다.

컨텍스트 잘라내기 (Context Trimming)

요약은 일반적으로 LLM을 사용하여 가장 관련성 높은 컨텍스트 조각을 정리하는 반면, 잘라내기는 Drew Breunig가 언급한 것처럼 “전정(pruning)”으로 컨텍스트를 필터링하는 데 더 가깝습니다. 이는 메시지 목록에서 비교적 오래된 메시지를 제거하는 등 개발자의 하드코딩된 휴리스틱 규칙을 사용할 수 있습니다. Drew는 또한 Q&A 작업을 위해 훈련된 컨텍스트 잘라내기 도구인 Provence를 언급했습니다.

컨텍스트 격리 (Isolating Context)

컨텍스트 격리는 컨텍스트를 나누어 에이전트가 작업을 수행하는 데 도움을 주는 것입니다.

다중 에이전트 (Multi-agent)

컨텍스트 격리의 가장 대중적인 방법 중 하나는 이를 여러 하위 에이전트에 분산시키는 것입니다. OpenAI의 Swarm 라이브러리의 한 동기는 ‘집중점 분리’이며, 하나의 에이전트 팀이 하위 작업을 처리하도록 하는 것입니다. 각 에이전트는 자신만의 도구 세트, 지시 및 독립적인 컨텍스트 윈도우를 가집니다.

Anthropic의 다중 에이전트 연구 시스템은 이를 강력하게 입증합니다. 여러 독립적인 컨텍스트를 가진 에이전트들은 단일 에이전트보다 더 나은 성과를 내며, 이는 각 하위 에이전트의 컨텍스트 윈도우가 더 좁은 하위 작업에 집중할 수 있기 때문입니다. 블로그에서 언급된 바와 같이:

하위 에이전트들은 각자의 컨텍스트 윈도우를 가지고 병렬로 작업하며, 문제의 다양한 측면을 탐색합니다.

물론, 다중 에이전트는 도전 과제에 직면하기도 합니다. 예를 들어, token 소비 문제(Anthropic은 그들의 token 사용량이 대화의 15배에 달한다고 보고했음), 하위 에이전트 작업 계획을 위한 세심한 프롬프트 엔지니어링 필요성, 그리고 하위 에이전트 간의 조정 문제 등이 있습니다.

환경을 통한 컨텍스트 격리 (Context Isolation with Environments)

HuggingFace의 심층 연구원 프로젝트는 또 다른 흥미로운 컨텍스트 격리 사례를 보여줍니다. 대부분의 에이전트는 도구 호출 API를 사용하며, 이들 API는 JSON 객체(도구 매개변수)를 반환한 후, 도구(예: 검색 API)로 전달되어 피드백(예: 검색 결과)을 가져옵니다. 그러나 HuggingFace는 필요한 도구 호출을 포함하는 코드를 직접 출력하는 CodeAgent를 사용하고 있습니다. 이 코드들은 이후 샌드박스 환경에서 실행됩니다. 도구 호출에서 반환된 특정 컨텍스트(예: 반환 값)는 다시 LLM으로 전달됩니다.

이로 인해 컨텍스트는 환경에서 LLM과 격리될 수 있습니다. Hugging Face는 이를 토큰을 대량으로 소비하는 객체를 격리하는 훌륭한 방법으로 제안합니다:

Code Agents는 상태를 더 잘 처리할 수 있습니다… 이미지를 저장해야 합니까? 문제없습니다. 변수를 할당하면 나중에 사용할 수 있습니다.

상태 (State)

특히 주목할 점은 에이전트의 실행 시 상태 객체 또한 컨텍스트 격리의 좋은 방법이라는 것입니다. 이는 샌드박스와 유사한 역할을 할 수 있습니다. 상태 객체는 컨텍스트에 쓸 수 있는 필드를 포함하는 패턴(Schema, 예: Pydantic 모델)을 설계하여, 에이전트의 각 상호작용 라운드에서 LLM에 노출할 수 있습니다. 하지만 이 패턴은 다른 필드에 정보를 격리하여 선택적으로 사용할 수 있도록 합니다.

결론

에이전트의 컨텍스트 엔지니어링 패턴은 지속적으로 진화하고 있지만, 우리가 흔히 접하는 방법은 네 가지 범주—쓰기, 선별, 압축, 격리—로 요약할 수 있습니다:

• • 컨텍스트 쓰기: 정보를 컨텍스트 윈도우 밖에 저장하여, 에이전트가 작업을 수행할 때 사용할 수 있도록 하는 것.
• • 컨텍스트 선별: 필요한 정보를 컨텍스트 윈도우로 가져와 에이전트가 작업을 수행하는 데 도움을 주는 것.
• • 컨텍스트 압축: 작업 수행에 필요한 토큰만 남기는 것.
• • 컨텍스트 격리: 컨텍스트를 나누어 에이전트가 작업을 수행하는 데 도움을 주는 것.

이러한 패턴을 이해하고 적용하는 것은 현재 효율적인 에이전트를 구축하는 핵심 작업입니다.

• AI akıllı ajanlarının sınırları, sadece model boyutuna değil, aynı zamanda “bağlam yönetimi” becerisine de bağlıdır. Bu, CPU için bellek yapılandırmak gibidir; ajanın düşünme derinliğini ve verimliliğini belirler.
• Bağlam penceresi bir çöp kutusu değildir: Bilgi aşırı yüklenmesi, AI’nın yargısını “zehirler”, karıştırır ve kafa karışıklığı yaratır. Kesinlik, çokluktan çok daha önemlidir.
• Usta kişiler, akıllı ajanın bağlamını “yazma, seçme, sıkıştırma ve izole etme” dört adımı ile yönetir, sınırlı “belleği” etkili bir şekilde kullanarak maliyetleri düşürür ve verimliliği artırır.
• Gelecekteki rekabet, sistem verimliliği üzerinedir. Çoklu akıllı ajan yapısını kullanarak görevleri “izole” etmek ve her ajanın kendi küçük penceresinde mükemmel bir şekilde çalışmasını sağlamak, karmaşık görev sistemleri oluşturmanın anahtarıdır.

Temel Özeti

Ajanlar, görevleri yerine getirmek için bağlama ihtiyaç duyarlar. “Bağlam mühendisliği” kavramı, akıllı ajanın görevleri yerine getirirken bağlam penceresine doğru bilgiyi ekleme sanatı ve bilimidir. Bu makalede, mevcut popüler ajanların benimsediği bağlam mühendisliği stratejileri ana hatlarıyla birkaç genel modele indirgenmiştir.

Bağlam Mühendisliği (Context Engineering)

Andrej Karpathy’nin de söylediği gibi, büyük dil modelleri (LLM) aslında bir “yeni nesil işletim sistemi” gibidir. LLM, CPU gibi çalışır ve onun “bağlam penceresi” RAM işlevi görerek modelin iş belleği olur. Tıpkı RAM’in kapasitesi sınırlı olduğu gibi, LLM’nin bağlam penceresi de çeşitli bağlam kaynakları ile çalışırken kapasite sınırlamalarıyla karşılaşır. İşletim sisteminin en önemli görevlerinden biri CPU’nun RAM’ini verimli kullanmayı yönetmektir; “bağlam mühendisliği” de benzer bir rol üstlenir. Karpathy bu durumu çok iyi özetlemiştir:

Bağlam mühendisliği, “… bir sonraki adım için bağlam penceresini hassas bir şekilde doldurmanın ince sanatı ve bilimidir.”

LLM uygulamaları geliştirirken, hangi bağlam türlerini yönetmemiz gerektiğini biliyor muyuz? Bağlam mühendisliği, aşağıdaki farklı bağlam türlerini kapsamaktadır:

• • Talimatlar (Instructions) – İpuçları, bellekteki notlar, az sayıda örnek, araç tanımlamaları vb.
• • Bilgi (Knowledge) – Gerçekler, anılar vb.
• • Araçlar (Tools) – Araç çağırma geri bildirim bilgisi

Ajanlara Yönelik Bağlam Mühendisliği

Bu yıl, LLM’nin akıl yürütme ve araç çağırma konusundaki yeteneklerinin artmasıyla, insanlarda akıllı ajanlara olan ilgi giderek arttı. Ajanlar, görevleri yerine getirmek için LLM ve araçları dönüşümlü olarak kullanarak, özellikle uzun süre devam eden karmaşık görevleri işleme konusunda uzmandır.

Ancak, uzun süreli görevler ve sürekli biriken araç çağırma geri bildirimleri, ajanların genellikle büyük miktarda token tüketmesi anlamına gelir. Bu, çeşitli sorunlara yol açabilir: bağlam penceresinin kapasite sınırlarının aşılması, maliyetlerin ve gecikmelerin artması hatta ajan performansının düşmesi. Drew Breunig, çok uzun bir bağlamın şu şekillerde performans sorunlarına yol açabileceğini açıkça ifade etmiştir:

• • Bağlam zehirlenmesi (Context Poisoning): Yanlış bilgilerin bağlama girmesi durumunda.
• • Bağlam dikkat dağılması (Context Distraction): Bağlam bilgisi aşırı olduğunda, modelin orijinal eğitim bilgilere gömülmesi durumunda.
• • Bağlam kafa karışıklığı (Context Confusion): İlgisiz bağlam bilgileri modelin yanıtlarını etkilediğinde.
• • Bağlam çelişkisi (Context Clash): Bağlamdaki farklı parçaların birbiri ile çelişmesi durumunda.

Bu problemleri göz önünde bulundurarak, Cognition AI şirketi bağlam mühendisliğinin önemini vurgulamıştır:

“Bağlam mühendisliği”… aslında AI akıllı ajanların inşasında mühendislerin öncelikli görevidir.

Anthropic şirketi ise şunları belirtmiştir:

Ajanlar genellikle yüzlerce diyalog turu gerçekleştirmektedirler; bu da dikkatli bir bağlam yönetimi stratejisi benimsememizi gerektirir.

Peki günümüz geliştiricileri bu zorluklarla nasıl başa çıkıyorlar? Mevcut yöntemleri dört ana kategoriye - yazma (Write), seçme (Select), sıkıştırma (Compress) ve izole etme (Isolate) - ayırdım ve her birine örnekler verdim.

Bağlam Yazma (Write Context)

Bağlam yazma, bilgilerin bağlam penceresinin dışında biriktirilmesini ve akıllı ajanın görevlerini yerine getirirken kullanılması için depolanmasını ifade eder.

Geçici Alanlar (Scratchpads)

İnsanlar bir sorunu çözmek için not alır ve gelecekte ilgili görevleri işlerken kullanmak amacıyla bazı bilgileri hatırlayarak işler. Akıllı ajanlar da bu yetenekleri kazanmaya başlıyor! “Geçici alanlar” kullanarak not almak, ajanın görevleri yerlerine getirirken bilgileri kalıcı hale getirmenin bir yoludur. Temel fikir, bilgileri bağlam penceresinin dışında saklamak fakat gerektiğinde akıllı ajanın erişebilmesini sağlamaktır. Anthropic’in çoklu ajan araştırma sistemi bu konuda net bir örnek sunmaktadır:

“Baş araştırmacı”, bir sorunun çözümü için düşünür ve bağlamı kalıcı hale getirmek için planını “belleğe” kaydeder; zira bağlam penceresi 200.000 token’i geçtiğinde kesilebilir ve bu yüzden planı korumak kritik öneme sahiptir.

Geçici alanların uygulanma yöntemleri çeşitlidir. Bu basit bir dosya yazma işlemi gibi bir araç çağırma olabilir; aynı zaman da yürütme zamanında sabit kalacak bir durum nesnesinin bir parçası olabilir. Her iki durumda da, geçici alanlar akıllı ajanın görevleri daha iyi yerine getirmesi için faydalı bilgileri saklayabilmesini sağlar.

Anılar (Memories)

Geçici alanlar, akıllı ajanın tek bir oturumda görevleri çözmesine yardımcı olur, ancak bazı durumlarda ajanın birçok oturum boyunca bilgileri hatırlaması gerekebilir. Reflexion modeli, her turdan sonra ajanın düşünme yeteneğini artırarak, kendiliğinden ürettiği anıları yeniden kullanma fikrini tanıtmaktadır. Generative Agents modeli ise önceki ajanın geri bildirim koleksiyonundan dönemsel olarak anılar sentezleyebilmektedir.

Bu kavramlar, ChatGPT, Cursor ve Windsurf gibi popüler ürünlerde kullanılmaktadır. Kullanıcı ve akıllı ajan etkileşimine dayalı olarak, otomatik olarak uzun vadeli anılar üretebilme yeteneğine sahiptirler.

Bağlamı Seçme (Select Context)

Bağlamı seçme, akıllı ajanın görevlerini yerine getirmesine yardımcı olmak amacıyla gerekli bilgileri bağlam penceresine çekmeyi ifade eder.

Geçici Alanlar (Scratchpad)

Geçici alandan bağlam seçme mekanizması, uygulama biçimine bağlıdır. Eğer bir araç ise, akıllı ajanın sadece araç çağırma ile erişmesi yeterlidir. Eğer ajanın yürütme durumunun bir parçası ise, geliştirici her adımda durumu belli ölçüde açığa çıkarabilir. Bu, sonraki turlarda LLM’ye geçici alan bağlamını sunma konusunda hassas bir kontrol sağlar.

Anılar (Memories)

Eğer akıllı ajanın anıları saklama yeteneği varsa, o zaman mevcut görevle ilgili anıları seçme yeteneğine de ihtiyaç duyarlar. Bunun birkaç nedeni vardır: Ajan belirli bir davranış modelini öğrenmek için az sayıda örneği (durum belleği) seçebilir; kendi davranışlarını yönlendirmek için talimatları (program belleği) seçebilir; ya da görev için ilgili bir arka plan sağlamak üzere gerçekleri (anlamsal bellek) seçebilir.

Bu, seçilen anıların ilgili olmasını sağlamanın bir zorluğudur. Bazı popüler akıllı ajanlar, her zaman bağlama yüklenen küçük bir dosyayı kullanmaktadırlar. Örneğin, birçok kod akıllı ajansı, talimatları (program belleği) saklamak veya bazı durumlarda örnekleri (durum belleği) ziyaret etmek için dosyalar kullanmaktadır. Claude Code, CLAUDE.md dosyasını kullanırken, Cursor ve Windsurf ise kural dosyası kullanmaktadır.

Ancak, eğer akıllı ajanda çok sayıda (örneğin “anlamsal bellek” türünde) gerçek veya ilişki saklanıyorsa, seçme işlemi daha karmaşık hale gelir. ChatGPT, birçok kullanıcıya özgü anılar saklar ve bunlardan seçme yapar; bu konuda iyi bir örnektir.

Vektör gömme teknikleri ve/veya bilgi grafikleri, süzme işlemlerine yardımcı olmak için yaygın bellek indeksleme teknikleridir. Ancak, bellek seçme süreçleri hala zorludur. AIEngineer Dünya Fuarı’nda, Simon Willison, bir bellek seçme hatası örneği paylaştı: ChatGPT, onun konum bilgisini hafızasından alarak yanlışlıkla istediği resme ekledi. Beklenmedik veya istenmeyen bu bellek geri alımı, bazı kullanıcıların bağlam penceresinin “artık kendi” olmadığını hissetmelerine neden olmaktadır!

Araçlar (Tools)

Akıllı ajanların araç kullanmaları gerekir; fakat sağlanan araç sayısı fazla olursa, bunlar aşırı yüklenebilir. Bu genellikle, araç tanımlarının örtüşmesinden kaynaklanır ve bu durumda model hangi aracı seçeceği konusunda kafası karışır. Araç tanımlamaları üzerinde RAG (geri kazanım destekli üretim) uygulamak, görev için en alakalı aracı almak için anlamlı benzerliklere dayanmak amacıyla bir yöntemdir. Son zamanlardaki bazı yayınlar, bu yöntemin araç seçiminin doğruluğunu üç kat artırabileceğini göstermiştir.

Bilgi (Knowledge)

Geri kazanım destekli üretim (RAG) aslında büyük bir konudur ve bağlam mühendisliğinin temel zorluklarından biri olabilir. Kod akıllı ajansı, RAG’nin büyük ölçekli üretim uygulamalarındaki en iyi örneklerinden biridir. Windsurf’un Varun, bu zorlukların bazılarını çok iyi özetlemiştir:

Kodu indekslemek = bağlam geri kazanımı değil… Yaptığımız şey, AST (soyut sözdizim ağacı) kullanarak kodu çözümlemek ve anlamsal olarak anlamlı sınırlar boyunca bölmektir… Ancak kod deposunun büyümesiyle, vektörlere göre arama, geri kazanım destekli bir yaklaşım olarak güvenilir hale gelmiyor… Çeşitli teknolojilerin kombinasyonuna güvenmemiz gerekiyor; grep/dosya araması, bilgi grafiğine dayalı arama ve… bağlamı alaka düzeyine göre yeniden sıralama adımı.

Bağlamı Sıkıştırma (Compress Context)

Bağlamı sıkıştırma, yalnızca görevlerin yerine getirilmesi için gerekli olan token’ların saklanmasını ifade eder.

Bağlam Özeti (Context Summarization)

Ajanlarla olan etkileşimler yüzlerce tur sürebilir ve bu süreçte büyük miktarda token tüketen araçlar kullanılabilir. Özelleştirme, bu zorlukların üstesinden gelmek için yaygın bir yöntemdir. Eğer Claude Code kullanmışsanız, bu uygulamanın gerçek bir örneğini görmüşsünüzdür. Bağlam penceresi

• 大多数AI翻车不是模型太笨，而是上下文工程缺席——信息没被正确“写入、选取、压缩、隔离”。
• 忽视上下文=真金白银的损失：从 Bard 发布翻车到“260块鸡块”，企业都在为记忆缺陷买单。
• 盲目拉长上下文只会放大噪音与攻击面；小而准的上下文管控才是性能与安全之解。
• 先做上下文，后谈大模型：常见收益是**输入成本 -80%、准确度 +15~90%**，比换更大模型划算得多。

2023-2025年的企业实践证明，AI 应用失败的根本原因不是模型不够智能，而是”上下文工程”的缺失。谷歌因此损失1000亿美元市值，而掌握这项技术的企业却实现了40-90%的性能提升。

一、1000亿美元的教训：当AI”失忆”时会发生什么

谷歌Bard的致命一击

2023年2月，谷歌满怀信心地向世界展示其AI聊天机器人Bard。然而，在这场万众瞩目的发布会上，Bard犯了一个令人震惊的错误。

当被问及詹姆斯·韦伯太空望远镜的成就时，Bard自信地回答：”它拍摄了太阳系外行星的第一张照片。”这个答案听起来很专业，但有一个致命问题——它是错的。实际上，第一张系外行星照片是在2004年由欧洲南方天文台拍摄的，比韦伯望远镜发射早了近20年。

这个看似微小的错误引发了雪崩效应。投资者立即意识到，如果谷歌的AI连基本事实都无法准确把握，那么它在更复杂的商业场景中如何能够可靠运作？当天，Alphabet（谷歌母公司）的股价暴跌9%，市值蒸发超过1000亿美元。[来源：CNN, NPR, Time报道]

加拿大航空的昂贵”误导”

2023年底，加拿大乘客Jake Moffatt因祖母去世需要紧急购买机票。他咨询了加拿大航空的AI客服助手，得到了一个看似贴心的回复：”您可以先购买全价机票，然后在90天内申请丧亲折扣退款。”

Moffatt按照AI的建议行事，却在申请退款时被告知：丧亲折扣必须在购票前申请，不能追溯。原来，AI客服提供了完全错误的政策信息。

这个案例最终闹上了法庭。加拿大民事仲裁庭做出了历史性判决：企业必须对其AI系统的错误建议承担法律责任。加拿大航空被判赔偿812.02加元，并被要求更新其AI系统。[来源：CIO报道的AI灾难案例]

麦当劳的”260块鸡块”噩梦

2024年6月，麦当劳终止了与IBM为期三年的AI点餐合作。这个决定的背后，是一连串令人啼笑皆非的失败案例。

最著名的事件发生在一家麦当劳得来速餐厅。一位顾客原本只想点几块鸡块，但AI系统突然”疯了”，不断往订单里添加鸡块。顾客焦急地喊着”停！停！”，但AI充耳不闻，最终订单上出现了260块麦乐鸡。

这个视频在社交媒体上疯传，成为AI失败的经典案例。麦当劳不得不关闭了100多家门店的AI测试系统，三年的研发投入付诸东流。[来源：CIO的企业AI失败案例分析]

二、揭开真相：不是AI不够聪明，而是”记忆系统”出了问题

像患了严重”阿尔茨海默症”的天才

想象一下这样一个场景：您聘请了一位智商180的顶级专家作为助手，他精通各个领域的知识，计算能力超群。但有一个问题——他患有严重的短期记忆障碍，每隔几分钟就会忘记之前的对话内容。

这就是当前大多数企业AI系统的真实写照。它们并不缺乏”智慧”（模型能力），而是缺乏有效的”记忆管理”（上下文工程）。

什么是”上下文”？用会议纪要来理解

在人类的日常工作中，”上下文”无处不在。想象您参加一个重要的项目会议：

• 会议背景：为什么召开这次会议？（相当于AI的系统提示）
• 历史记录：之前几次会议讨论了什么？（相当于对话历史）
• 相关文档：需要参考的报告、数据、合同（相当于知识库）
• 参会人员：每个人的角色和权限（相当于工具和权限定义）
• 会议纪要：关键决策和行动项（相当于记忆总结）

如果缺少这些”上下文”，即使是最优秀的专家也无法做出正确决策。这正是谷歌Bard犯错的根本原因——它在回答问题时，缺少准确的历史数据和事实验证机制。

制造业的惨痛教训

根据Gartner的研究，制造业在AI应用中面临着特别严峻的挑战：

• 仅20%的生成式AI项目被认为成功
• 85%的AI项目未能实现预期目标
• 42%的公司计划在2025年放弃AI计划（2024年这一比例仅为17%）

[来源：Appinventiv, SupplyChainBrain的制造业AI报告]

为什么制造业的失败率如此之高？答案还是上下文工程的缺失：

1. 历史数据断层：新AI系统无法访问旧系统中的关键生产数据
2. 实时信息缺失：AI在做决策时看不到当前的设备状态、库存水平
3. 知识孤岛：不同部门的AI系统各自为政，无法共享关键信息
   

三、上下文工程：让AI拥有”完整记忆”的解决方案

为AI配备一个”智能秘书”

上下文工程的本质，就像为您的AI系统配备一个极其称职的秘书。这个秘书的工作包括：

1. 记录重要信息（Write/写入）

   • 把关键决策和结论保存下来
   • 就像秘书会整理会议纪要

2. 筛选相关资料（Select/选取）

   • 从海量信息中找出当前需要的
   • 就像秘书会为您准备相关文件

3. 总结关键要点（Compress/压缩）

   • 把冗长的报告浓缩成精华
   • 就像秘书会做执行摘要

4. 协调团队分工（Isolate/隔离）

   • 让不同专家处理各自擅长的部分
   • 就像秘书会安排专门会议

真实案例：保险公司的华丽转身

Five Sigma保险公司通过实施上下文工程，彻底改变了理赔处理流程：[来源：MarkTechPost案例研究]

改造前的困境：

• AI系统经常给出与保单条款矛盾的理赔建议
• 无法识别欺诈模式，因为看不到历史理赔数据
• 处理复杂案件时频繁出错

实施上下文工程后：

• 系统能同时访问：保单条款、理赔历史、法规要求、欺诈数据库
• 理赔处理错误减少80%
• 理赔员工作效率提升25%
• 承保准确率超过95%

关键在于，他们没有更换AI模型，只是改进了信息的组织和传递方式。

微软的开发者工具革命

微软的AI编程助手展示了上下文工程的威力：[来源：Microsoft官方博客]

通过整合以下上下文信息：

• 开发者的项目历史
• 团队的编码规范
• 相关的技术文档
• 代码库的依赖关系

取得的成果：

• 软件任务完成率提升26%
• 代码错误减少65%
• 新员工入职时间缩短55%
• 代码质量提升70%

四、长上下文的陷阱：为什么”记得越多”不等于”做得越好”

AWS安全团队的警告

2024年，AWS安全研究团队发现了一个严重问题：当AI系统的”记忆”过载时，会出现致命漏洞。[来源：Towards Data Science的技术分析]

想象一个场景：您的AI助手需要处理一份1000页的报告。理论上，新的AI模型可以”记住”所有内容。但实际发生的是：

1. 前面的重要指令被”挤出”记忆
2. 恶意用户可以通过大量无关信息”污染”AI的记忆
3. AI开始产生幻觉，基于错误信息做决策

这就像一个人试图同时记住一整本百科全书——信息太多反而会造成混乱。

特斯拉自动驾驶的解决方案

特斯拉的全自动驾驶（FSD）系统是最复杂的上下文工程实现之一：[来源：Tesla官网, Wikipedia]

• 48个神经网络协同工作
• 每个时间步输出1000个不同的张量
• 处理8个摄像头的实时视频流
• 累计行驶里程超过10亿英里

特斯拉是如何管理如此庞大的信息流的？答案是”智能过滤”：

• 不是所有信息都同等重要
• 紧急信息（如突然出现的行人）优先处理
• 历史信息按重要性分级存储
• 不同的神经网络负责不同类型的信息

五、巨头们的最新突破：从1000亿美元的教训中学到了什么

OpenAI的模型上下文协议（MCP）

2024年底，OpenAI推出了革命性的MCP协议，解决了”M×N问题”：[来源：Pluralsight, Microsoft Learn]

传统方式的困境：

• 10个AI模型 × 100个数据源 = 需要1000个定制接口
• 每个接口都需要单独开发和维护

MCP的解决方案：

• 创建统一的”通用语言”
• 任何AI模型都能通过标准接口访问任何数据源
• 将集成成本降低90%以上

Anthropic的”宪法AI”

Anthropic（Claude的开发公司）采用了独特的方法：[来源：Anthropic官方研究]

他们邀请了1000名美国公民参与制定AI的”行为准则”，确保AI系统：

• 理解并遵守人类的价值观
• 在复杂情况下做出符合伦理的决策
• 将恶意利用成功率从86%降至4.4%

谷歌Gemini的百万级上下文

谷歌从Bard的失败中吸取教训，Gemini 1.5 Pro实现了：[来源：Google官方博客]

• 100万tokens的稳定上下文（相当于70万字的中文）
• 同时处理音频、视频、文本和代码
• 可以分析整部电影或数百页文档

但谷歌也承认：更大的上下文不等于更好的性能，关键在于如何组织和使用这些信息。

微软Azure的智能路由

微软在Azure AI Foundry中提供了多个模型变体：[来源：Microsoft Azure博客]

• GPT-5：272K上下文，适合复杂推理
• GPT-5 mini：为实时体验优化
• GPT-5 nano：超低延迟响应
• 智能路由器自动选择最合适的模型，节省60%成本

六、多智能体协作：亚马逊和沃尔玛的实践

亚马逊的75万机器人军团

亚马逊的仓库自动化系统展示了大规模上下文管理的威力：[来源：Amazon官方报道, LinkedIn分析]

• 75万个移动机器人在2023年部署
• Sequoia系统将订单处理时间缩短25%
• 通过路线优化节省3000万英里的行驶距离
• 减少9400万磅CO₂排放
• 包裹损坏率保持在0.1%以下

成功的秘诀在于”分层上下文管理”：

• 每个机器人只需要知道自己的任务
• 区域控制器协调局部的机器人群
• 中央AI系统掌握全局优化

沃尔玛的AI库存革命

沃尔玛在4700多家门店部署的AI系统整合了：[来源：Walmart官方新闻, Walmart Tech博客]

多维度上下文信息：

• 历史销售数据
• 天气预报（影响购买模式）
• 宏观经济趋势
• 当地人口统计
• 社交媒体趋势

独特创新：

• “异常遗忘”专利技术：自动排除一次性事件（如疫情囤货）对预测的影响
• 动态调整算法：根据节假日、促销活动实时调整

成果：

• 2023年Q3增长24%
• 路线优化避免3000万英里不必要的驾驶
• 目标到2026财年实现65%的门店自动化

七、通用电气的”谦逊AI”：知道自己不知道什么

120万个数字孪生的智慧

通用电气（GE）在2016-2017年间创建了超过120万个数字孪生，创造了6000亿美元的价值：[来源：Emerj, Microsoft研究]

他们的”谦逊AI”框架特别值得关注：

• AI系统能够识别自己的能力边界
• 当遇到超出理解范围的情况时，自动切换到安全模式
• 主动请求人类专家介入

实际成果：

• 风电场发电量提升20%
• 每年预防400次计划外维护（航空领域）
• **计划外维护减少30%**（通过预测性维护）

这种方法避免了AI”不懂装懂”导致的灾难性后果。

八、上下文工程的四大核心技术

基于Phil Schmid、Lance Martin等专家的研究，以及LangChain、LlamaIndex的实践，上下文工程包含四个核心操作：[来源：philschmid.de, rlancemartin.github.io, blog.langchain.com]

1. 写入（Write）：建立AI的”长期记忆”

就像人类会写日记、做笔记，AI系统也需要记录重要信息：

会话内写入：

• 临时草稿（如计算过程）
• 中间思考步骤
• 当前任务的规划

持久化写入：

• 用户偏好总结
• 关键业务规则
• 历史决策记录

ChatGPT和Cursor等应用正是通过这种方式，让AI在与用户的持续交互中”学习”和”成长”。

2. 选取（Select）：找到”此时此刻”最需要的信息

想象您的助手需要准备一份报告，他不会把整个图书馆的书都搬来，而是精准选择需要的资料：

确定性选取：

• 固定加载某些关键文档（如公司政策）

模型驱动选取：

• 让AI自己判断需要哪些信息

检索式选取：

• 通过相似度搜索找到相关内容

3. 压缩（Compress）：把”战争与和平”变成一页纸

当信息太多时，需要智能压缩：

自动摘要：

• 将1000字的邮件压缩成3句话的要点

重要性排序：

• 保留最关键的20%信息，覆盖80%的价值

增量更新：

• 只记录变化的部分，而不是完整复制

4. 隔离（Isolate）：专家团队的分工协作

复杂任务需要多个AI专家协作：

任务分解：

• 财务分析专家处理数字
• 法律专家审查合规性
• 写作专家负责最终报告

信息隔离：

• 每个专家只获得相关信息
• 避免信息过载和混淆

结果整合：

• 主AI综合各专家意见
• 做出最终决策
  

九、投资回报率：为什么上下文工程比升级模型更划算

惊人的成本效益比

根据行业数据，上下文工程的投资回报率远超模型升级：[来源：多个案例综合]

上下文工程：

• 占AI预算的5%
• 带来40-90%的性能提升
• 实施周期：2-3个月

模型升级：

• 占AI预算的60-70%
• 带来10-20%的性能提升
• 实施周期：6-12个月

一家科技公司的真实账单

某中型科技公司的实际数据：

• 实施上下文工程后，每月节省23,000美元的计算成本
• 通过上下文裁剪，输入大小减少80%
• API调用成本相应减少80%
• 性能反而提升了15%

这就像通过更好的交通规划，既节省了油费，又缩短了通勤时间。

十、2025年展望：从”演示”到”生产”的关键一步

行业专家的共识

“大多数AI代理的失败不再是模型失败，而是上下文失败。”这已成为业界共识。

Cognition（Devin AI的开发团队）明确指出：**”上下文工程是构建AI代理的首要工作”**。[来源：cognition.ai博客]

企业的三个行动建议

1. 立即进行”上下文健康检查”

记录您的AI系统失败的具体场景：

• AI给出错误答案时，缺少什么信息？
• 哪些环节存在信息断层？
• 现有系统能访问哪些数据源？

2. 选择一个高价值试点

不要试图一次改造所有系统，选择一个：

• 使用频率高
• 失败成本大
• 改进空间明显的场景

例如：客户服务、订单处理、报告生成

3. 建立跨部门协作机制

上下文工程需要：

• IT部门：提供技术支持
• 业务部门：定义信息需求
• 数据团队：确保数据质量
• 合规团队：确保信息安全

避开常见陷阱

陷阱1：盲目追求大模型

• 错误想法：模型越大越好
• 正确做法：先优化上下文，再考虑升级模型

陷阱2：信息越多越好

• 错误想法：给AI所有可能的信息
• 正确做法：精准提供相关信息

陷阱3：忽视信息质量

• 错误想法：有信息就行
• 正确做法：确保信息准确、及时、结构化

结语：一个新时代的开始

2023-2025年将被历史记住为”上下文工程元年”。从谷歌1000亿美元的教训，到特斯拉、亚马逊、沃尔玛的成功实践，我们看到了一个清晰的趋势：

AI的成功不再取决于”更聪明的大脑”，而是”更好的记忆系统”。

掌握上下文工程的企业正在获得可持续的竞争优势：

• 运营效率大幅提升
• 客户体验显著改善
• 投资回报率成倍增长
• 风险和错误大幅降低

而那些忽视这一趋势的企业，可能会像当年错过互联网革命的公司一样，被时代抛在身后。

正如一位行业领袖所说：”在AI时代，上下文工程可能是您的AI投资中回报率最高的部分。”

现在，是时候重新审视您的AI战略了。不是问”我们需要更强大的AI吗？”而是问”我们如何让现有的AI更好地理解和记住关键信息？”

答案，就在上下文工程中。

本文基于2023-2025年国际领先企业的实践案例编写，所有数据均来自公开报道和官方发布。

• معظم فشل الذكاء الاصطناعي ليس بسبب غباء النماذج، بل هو غياب هندسة السياق — المعلومات لم تُكتب أو تُختار أو تُضغط أو تُعزل بشكل صحيح.
• التجاهل للسياق = خسائر حقيقية: من فشل إصدار Bard إلى “260 قطعة دجاج”، كل الشركات تدفع ثمن نقص الذاكرة.
• محاولة توسيع السياق بلا ضوابط لن تؤدي إلا إلى زيادة الضوضاء والأخطار؛ التحكم الدقيق في السياق هو الحل لتحسين الأداء والسلامة.
• يجب القيام بهندسة السياق أولاً، ثم الحديث عن النموذج الكبير: الفوائد الشائعة تتضمن **خفض تكلفة الإدخال بنسبة -80%**، **زيادة الدقة بنسبة +15 إلى 90%**، وهذا أكثر جدوى من تغيير النموذج إلى نموذج أكبر.

أثبتت الممارسات التجارية بين 2023 و2025 أن السبب الجذري للفشل في تطبيقات الذكاء الاصطناعي ليس عدم ذكاء النموذج، بل هو غياب “هندسة السياق”. تكبدت شركة جوجل خسارة بقيمة 100 مليار دولار، بينما حققت الشركات التي تمتلك هذه التقنية تحسينات تتراوح بين 40% إلى 90% في الأداء.

1. درس بقيمة 100 مليار دولار: ماذا يحدث عندما “يفقد” الذكاء الاصطناعي ذاكرته

الضربة القاتلة لبرد من جوجل

في فبراير 2023، عرضت جوجل بشكل واثق روبوت الدردشة الذكي الخاص بها، Bard، للعالم. ومع ذلك، خلال مؤتمر الإطلاق هذا المليء بالحضور، ارتكب Bard خطأ مذهلاً.

عندما سُئل عن إنجازات تليسكوب جيمس ويب، أجاب Bard بثقة “لقد التقط الصورة الأولى لكوكب خارج النظام الشمسي”. بدت هذه الإجابة محترفة، لكنها تحتوي على مشكلة قاتلة — إنها خاطئة. في الواقع، تم التقاط الصورة الأولى لكوكب خارجي في عام 2004 بواسطة المرصد الجنوبي الأوروبي، قبل إطلاق تليسكوب ويب بـ 20 عامًا تقريبًا.

أدى هذا الخطأ الذي يبدو صغيرًا إلى تفاعلات مدمرة. سرعان ما أدرك المستثمرون أنه إذا كان الذكاء الاصطناعي لجوجل غير قادر على التعامل مع الحقائق الأساسية بدقة، فكيف يمكن أن يعمل بموثوقية في حالات تجارية أكثر تعقيدًا؟ في ذلك اليوم، انخفض سهم Alphabet (الشركة الأم لجوجل) بنسبة 9%، وتلاشت 100 مليار دولار من قيمتها السوقية. [المصدر: تقارير CNN وNPR وTime]

“معلومات مضللة” باهظة الثمن من خطوط الطيران الكندية

في نهاية عام 2023، اضطر الراكب الكندي جاك موفات بسبب وفاة جدته لشراء تذكرة طيران بشكل عاجل. استشار مساعد خدمة العملاء الذكي في خطوط الطيران الكندية وحصل على استجابة تبدو مهتمة: “يمكنك شراء تذكرة بسعر كامل أولاً، ثم الطلب لاسترداد الخصم على التذكرة بعد 90 يومًا.”

لكن موفات أُبلغ عند تقديم الطلب للاسترداد أن الخصم على التذكرة يجب أن يُطلب قبل الشراء، ولا يمكن رفعه بأثر رجعي. للأسف، قدم مساعد خدمة العملاء معلومات خاطئة تمامًا عن السياسة.

انتهى الأمر بهذا الموقف في قاعة المحكمة. حكمت المحكمة المدنية الكندية حكما تاريخيا: يجب أن تتحمل الشركات المسؤولية القانونية عن النصائح الخاطئة التي يقدمها أنظمة الذكاء الاصطناعي لديها. وصدرت بحق خطوط الطيران الكندية حكمًا بدفع 812.02 دولارًا كنديًا، وطُلب منها تحديث نظام الذكاء الاصطناعي الخاص بها. [المصدر: تقارير CIO حول حالات الكوارث في الذكاء الاصطناعي]

كابوس “260 قطعة دجاج” من ماكدونالدز

في يونيو 2024، أنهت ماكدونالدز شراكتها التي استمرت ثلاث سنوات مع IBM بشأن الذكاء الاصطناعي في نظام طلب الطعام. جاء هذا القرار بعد سلسلة من الفشل المضحكة.

أشهر الحوادث وقعت في أحد مطاعم سلسلة ماكدونالدز. أراد أحد الزبائن طلب عدد قليل من قطع الدجاج، لكن النظام الذكي فشل فجأة، مضيفاً قطع دجاج أخرى باستمرار إلى الطلب. كان الزبون مرتبكًا وهو ينادي “توقف! توقف!”، لكن الذكاء الاصطناعي لم يسمع، وفي النهاية كان الطلب يحتوي على 260 قطعة دجاج.

انتشر هذا الفيديو بشكل جنوني في وسائل التواصل الاجتماعي، وأصبح نموذجًا كلاسيكيًا لفشل الذكاء الاصطناعي. اضطرت ماكدونالدز إلى إغلاق أنظمة اختبار الذكاء الاصطناعي في أكثر من 100 مطعم، مما أدى إلى تفويت سنوات من الاستثمارات في البحث والتطوير. [المصدر: تحليل لحالات فشل الذكاء الاصطناعي من CIO]

2. كشف الحقيقة: ليس الذكاء الاصطناعي غبيًا، بل “نظام الذاكرة” هو المشكلة

مثل عبقري مصاب بمرض “ألزهايمر” شديد

تخيل هذا السيناريو: لقد استأجرت خبيرًا من ذوي المعدلات العليا بذكاء 180 كمساعد، وهو خبير في جميع المجالات ومتفوق في القدرة على الحوسبة. ولكن هناك مشكلة — إنه يعاني من ضعف شديد في الذاكرة قصيرة المدى، ويفقد محتوى المحادثات السابقة كل بضع دقائق.

هذه هي الصورة الحقيقية لمعظم أنظمة الذكاء الاصطناعي التي تستخدمها الشركات حاليًا. فهي ليست تفتقر إلى “الذكاء” (قدرة النموذج)، بل تفتقر إلى “إدارة الذاكرة” الفعالة (هندسة السياق).

ما هو “السياق”؟ لنفهمها عبر محضر الاجتماع

في العمل اليومي للإنسان، يتواجد “السياق” في كل مكان. تخيل أنك تحضر اجتماعًا مهمًا للمشروع:

• خلفية الاجتماع: لماذا تم عقد هذا الاجتماع؟ (مماثل للتوجيه النظامي للذكاء الاصطناعي)
• السجلات السابقة: ماذا تم مناقشته في الاجتماعات السابقة؟ (مماثل لسجل المحادثة)
• المستندات ذات الصلة: التقارير والبيانات والعقود التي يحتاج إلى إشارة إليها (مماثل لقواعد البيانات المعرفية)
• المشاركون: دور كل شخص وصلاحياته (مماثل لتعريف الأدوات والصلاحيات)
• محضر الاجتماع: القرارات الرئيسية والعناصر الإجرائية (مماثل لملخص الذاكرة)

إذا كان هناك نقص في هذه “السياقات”، حتى أفضل الخبراء لن يتمكنوا من اتخاذ قرار صحيح. وهذا هو السبب الجذري لخطأ Bard في جوجل — فقد lacked بيانات تاريخية دقيقة وآلية تحقق من الحقائق عند إجابته على الأسئلة.

الدروس المؤلمة في الصناعة

وفقًا لدراسة Gartner، تواجه الصناعة تحديات خاصة في تطبيق الذكاء الاصطناعي:

• فقط 20% من مشاريع الذكاء الاصطناعي من الجيل الجديد تعتبر ناجحة
• 85% من مشاريع الذكاء الاصطناعي لم تحقق الأهداف المتوقعة
• 42% من الشركات تخطط للتخلي عن مشاريع الذكاء الاصطناعي بحلول عام 2025 (كانت النسبة في عام 2024 17% فقط)

[المصدر: تقرير برمجة الذكاء الاصطناعي في الصناعة من Appinventiv وSupplyChainBrain]

لماذا تتواجد نسبة فشل عالية بهذا الشكل في الصناعة؟ الجواب هو نقص هندسة السياق:

1. انقطاع البيانات التاريخية: لا يمكن للنظام الذكي الجديد الوصول إلى البيانات الإنتاجية الحيوية في الأنظمة القديمة
2. نقص المعلومات الفورية: لا يستطيع الذكاء الاصطناعي رؤية حالة الأجهزة الحالية ومستويات المخزون أثناء اتخاذ القرارات
3. جزر المعرفة: أنظمة الذكاء الاصطناعي في الإدارات المختلفة تتصرف بشكل مستقل ولا يمكنها مشاركة المعلومات الحيوية

3. هندسة السياق: الحل لتمكين الذكاء الاصطناعي من “امتلاك ذاكرة كاملة”

تجهيز الذكاء الاصطناعي بمساعد “ذكي”

جوهر هندسة السياق هو مثل تجهيز نظام الذكاء الاصطناعي الخاص بك بمساعد أمين يمتلك مهارات عالية. تشمل مهام هذا المساعد:

1. تدوين المعلومات الحيوية (Write/كتابة)

   • حفظ القرارات والتوصيات الرئيسية
   • تمامًا مثلما يقوم المساعد بتنظيم محاضر الاجتماعات

2. تصفية المعلومات ذات الصلة (Select/اختيار)

   • العثور على ما تحتاجه حاليًا من بين كم هائل من المعلومات
   • تمامًا كما يفعل المساعد في تحضير الوثائق المتعلقة بك

3. تلخيص النقاط الرئيسية (Compress/ضغط)

   • تكثيف التقارير المطولة في جوهرها
   • تمامًا مثلما يقوم المساعد بعمل الملخص الوجيز

4. تنسيق العمل الجماعي (Isolate/عزل)

   • يسمح لمتخصصين مختلفين بالتعامل مع نطاقاتهم الخاصة
   • تمامًا كما يقوم المساعد بترتيب الاجتماعات المتخصصة

حالة حقيقية: تحول التأمين إلى الإيرادات المثمرة

شركة Five Sigma للتأمين غيرت تمامًا عملية تقديم المطالبات من خلال تنفيذ هندسة السياق: [المصدر: دراسة حالة MarkTechPost]

الصعوبات قبل التحويل:

• غالبًا ما كانت أنظمة الذكاء الاصطناعي تقدم نصائح تقديم مطالبات تتعارض مع شروط وثائق التأمين
• لم يتمكن من تحديد أنماط الاحتيال لأنه لم يكن لديه الوصول إلى بيانات المطالبات السابقة
• تكررت الأخطاء عند معالجة القضايا المعقدة

بعد تنفيذ هندسة السياق:

• أصبح النظام قادرًا على الوصول إلى: شروط الوثائق، تاريخ المطالبات، المتطلبات القانونية، قاعدة بيانات الاحتيال
• انخفضت أخطاء معالجة المطالبات بنسبة 80%
• ازدادت كفاءة العمل لدى موظفي المطالبات بنسبة 25%
• زادت دقة التأمين إلى أكثر من 95%

الجوهر يكمن في أنها لم تستبدل نموذج الذكاء الاصطناعي، بل حسنت فقط تنظيم المعلومات وطريقة نقلها.

ثورة أدوات المطورين في مايكروسوفت

أظهر مساعد البرمجة الذكي في مايكروسوفت قدرة هندسة السياق: [المصدر: مدونة مايكروسوفت الرسمية]

من خلال دمج المعلومات السياقية التالية:

• تاريخ مشاريع المطورين
• معايير الترميز للفريق
• الوثائق الفنية ذات الصلة
• علاقات الاعتماد في المكتبات البرمجية

تحققت النتائج:

• ازدادت نسبة إتمام المهام البرمجية بنسبة 26%
• انخفضت الأخطاء البرمجية بنسبة 65%
• انخفض زمن إدخال موظفي العمل الجدد بنسبة 55%
• تحسن جودة الكود بنسبة 70%

4. فخ السياقات الطويلة: لماذا “تذكر المزيد” لا يعني “القيام بشكل أفضل”

تحذير فريق الأمان في AWS

في عام 2024، اكتشف فريق الأمان في AWS مشكلة خطيرة: عندما يزداد “حمل الذاكرة” على نظام الذكاء الاصطناعي، تتعرض الأنظمة لثغرات قاتلة. [المصدر: تحليل فني من Towards Data Science]

تخيل سيناريو: يحتاج مساعد الذكاء الاصطناعي الخاص بك إلى معالجة تقرير مكون من 1000 صفحة. نظريًا، يمكن للنموذج الذكي الجديد “تذكر” كل المحتوى. ولكن ما يحدث فعليًا هو:

1. يتم “دفع” التعليمات الهامة خارج الذاكرة
2. يمكن أن يقوم المستخدمون الخبيثون بـ “تلوث” ذاكرة الذكاء الاصطناعي من خلال إغراقه بمعلومات غير ذات صلة
3. يبدأ الذكاء الاصطناعي في خلق أوهام، مُتخذًا قرارات بناءً على معلومات خاطئة

هذا يشبه شخصًا يحاول تذكر موسوعة كاملة في نفس الوقت - المعلومات الكثيرة تسبب الفوضى.

حل القيادة الذاتية في تسلا

نظام القيادة الذاتية الكامل (FSD) في تسلا هو أحد أكثر تطبيقات هندسة السياق تعقيدًا: [المصدر: الموقع الرسمي لتسلا، ويكيبيديا]

• 48 شبكة عصبية تعمل بالتنسيق
• كل خطوة زمنية تُنتج 1000 تانسور مختلف
• تعالج التيار الوارد من الفيديو في 8 كاميرات في الوقت الحقيقي
• اجتازت أكثر من مليار ميل في القيادة

كيف تدير تسلا هذا الحجم الهائل من المعلومات؟ الجواب هو “الفلترة الذكية”:

• ليست كل المعلومات ذات أهمية متساوية
• تتم معالجة المعلومات العاجلة (مثل مظهر شخص عابر فجأة) أولًا
• يتم تخزين المعلومات التاريخية وفقًا لأهميتها
• كل شبكة عصبية مسؤولة عن نوع محدد من المعلومات

5. الاختراقات الحديثة من الشركات الكبرى: ماذا تعلموا من درس الـ 100 مليار دولار؟

بروتوكول سياق نموذج OpenAI (MCP)

في نهاية عام 2024، أصدرت OpenAI بروتوكول MCP الثوري، الذي عالج “مشكلة M×N”: [المصدر: Pluralsight، Microsoft Learn]

مأزق الأسلوب التقليدي:

• 10 نماذج ذكاء اصطناعي × 100 مصدر بيانات = 1000 واجهة مخصصة تحتاج للتطوير
• كل واجهة تحتاج إلى تطوير وصيانة بشكل منفصل

حل الـ MCP:

• إنشاء “لغة عامة” موحدة
• يمكن لأي نموذج ذكاء اصطناعي الوصول إلى أي مصدر بيانات من خلال واجهة قياسية
• خفض تكلفة التكامل بأكثر من 90%

“AI الدستورية” من Anthropic

تتبع Anthropic (شركة Claude) نهجًا فريدًا: [المصدر: البحث الرسمي لـ Anthropic]

دعونا 1000 مواطن أمريكي يساهمون في صياغة “مدونة سلوك” الذكاء الاصطناعي لضمان أنظمة الذكاء الاصطناعي:

• تفهم وتلتزم بالقيم الإنسانية
• تتخذ قرارات أخلاقية في المواقف المعقدة
• خفضت معدل استغلال الذكاء الاصطناعي الخبيث من 86% إلى 4.4%

السياقات الواسعة لمشروع جوجل Gemini

استفادت جوجل من دروس Bard الفاشلة وحقق Gemini 1.5 Pro ما يلي: [المصدر: المدونة الرسمية لجوجل]

• سياق مستقر بمعدل 1,000,000 توكن (ما يعادل 700,000 كلمة باللغة الصينية)
• القدرة على معالجة الصوت والفيديو والنص والكود بشكل متزامن
• القدرة على تحليل فيلم كامل أو مئات الصفحات من الوثائق

ومع ذلك، اعترفت جوجل أيضًا: سياق أكبر لا يعني بالضرورة أداءً أفضل، المفتاح هو كيفية تنظيم هذه المعلومات واستخدامها.

التوجيه الذكي من مايكروسوفت أزور

توفر مايكروسوفت في Azure AI Foundry عدة نماذج مختلفة: [المصدر: مدونة Microsoft Azure]

• GPT-5: سياق 272K، مناسب للتفكير المنطقي المعقد
• GPT-5 mini: مُحسن لتجربة الوقت الحقيقي
• GPT-5 nano: استجابة بأقل زمن تأخير
• الموجه الذكي يختار النموذج الأنسب تلقائيًا، موفرًا 60% من التكاليف

6. التعاون بين الوكلاء المتعددين: ممارسات أمازون وول مارت

جيش الروبوتات في أمازون

نظام أتمتة المخازن في أمازون يعرض قوة إدارة السياق على نطاق واسع: [المصدر: تقارير رسمية من أمازون، تحليل LinkedIn]

• 750,000 روبوت متحرك تم نشرها في عام 2023
• اختصر نظام Sequoia زمن معالجة الطلبات بنسبة 25%
• وفر 30 مليون ميل من المسافة عبر تحسين الطريق
• قلل من انبعاثات CO₂ بما يعادل 94 مليون رطل
• حافظت على معدل تلف الطرود عند أقل من 0.1%

سر النجاح يكمن في “إدارة السياق ذات المستويات”:

• كل روبوت يحتاج فقط إلى معرفة مهمته الخاصة
• المنظمون في المناطق تنسيق الحمولة الروبوتية المحلية
• النظام المركزي للذكاء الاصطناعي يتحكم في التحسين الكلي

ثورة المخزون الذكية في وول مارت

تقوم أنظمة الذكاء الاصطناعي التي تُستخدم في ما يزيد عن 4700 متجر من وول مارت بدمج: [المصدر: أخبار وول مارت الرسمية، مدونة وول مارت تك]

معلومات سياقية متعددة الأبعاد:

• البيانات التاريخية للمبيعات
• توقعات الطقس (تؤثر على أنماط الشراء)
• الاتجاهات الاقتصادية الكبرى
• التركيبة السكانية المحلية
• اتجاهات وسائل التواصل الاجتماعي

ابتكار فريد:

• تقنية “نسيان الشذوذ” الحاصلة على براءة اختراع: استبعاد التأثيرات الناتجة عن الأحداث الفردية (مثل تخزين السلع أثناء الجوية العالمية)
• خوارزميات الضبط الديناميكي: لضبطها في الوقت الفعلي وفقًا للأعياد والنشاطات الترويجية

النتائج:

• زيادة بنسبة 24% في الربع الثالث من عام 2023
• تجنب 30 مليون ميل من القيادة غير الضرورية عبر تحسين الطرق
• الهدف هو تحقيق 65% من الأتمتة في المتاجر بحلول السنة المالية 2026

7. الذكاء المتواضع من جنرال إلكتريك: معرفة ما لا يعرفونه

حكمة 1.2 مليون توأم رقمي

أنشأت جنرال إلكتريك (GE) أكثر من 1.2 مليون توأم رقمي في الفترة من 2016 إلى 2017، مما خدمهم في تحقيق 600 مليار دولار من القيمة: [المصدر: Emerj، دراسة استخباراتية من مايكروسوفت]

إطار “الذكاء المتواضع” لديهم يستحق الدراسة بشكل خاص:

• يمكن لنظام الذكاء الاصطناعي التعرف على حدود قدراته
• عند مواجهة مواقف تتجاوز نطاق فهمه، يتحول تلقائيًا إلى وضع الأمان
• يطلب تدخل الخبراء البشريين بشكل استباقي

النتائج الفعلية:

• زادت الطاقة المنتجة في مزارع الرياح بنسبة 20%
• تجنب 400 حالة صيانة غير مخطط لها سنويًا (في مجال الطيران)
• انخفضت حالات الصيانة غير المخطط لها بنسبة 30% (يمثل هذا نتيجة للعمليات التنبؤية)

تساعد هذه الطريقة في تجنب نتائج كارثية ناتجة عن “عدم فسح الذكاء الاصطناعي” لفهم الأمور.

8. أربع تقنيات أساسية لهندسة السياق

استنادًا إلى أبحاث Phil Schmid وLance Martin، بالإضافة إلى ممارسات LangChain وLlamaIndex، تحتوي هندسة السياق على أربعة عمليات أساسية: [المصدر: philschmid.de، rlancemartin.github.io، blog.langchain.com]

1. الكتابة (Write): بناء “الذاكرة الطويلة الأجل” للذكاء الاصطناعي

كما يدون البشر اليوميات والملاحظات، تحتاج أنظمة الذكاء الاصطناعي أيضًا لتدوين المعلومات المهمة:

التسجيل داخل المحادثة:

• مسودات مؤقتة (مثل عمليات الحساب)
• خطوات التفكير المتوسطة
• تخطيط المهام الحالية

التدوين المستدام:

• ملخصات تفضيلات المستخدم
• القواعد التجارية الرئيسة
• سجلات القرارات التاريخية

تعمل تطبيقات مثل ChatGPT وCursor بهذه الطريقة لتمكن الذكاء الاصطناعي من “التعلم” و”النمو” خلال التفاعل المستمر مع المستخدمين.

2. الاختيار (Select): إيجاد المعلومات الأكثر احتياجًا “في هذه اللحظة”

تخيل مساعدك يحتاج إلى إعداد تقرير، لن يأخذ كل الكتب من المكتبة، بل يختار المواد المطلوبة بدقة:

اختيار حتمي:

• تحميل بعض الوثائق الأساسية (مثل سياسات الشركات)

اختيار مدفوع بالنموذج:

• السماح للذكاء الاصطناعي بالحكم بنفسه على المعلومات المطلوبة

اختيار قائم على البحث:

• العثور على المحتوى المماثل من خلال البحث عن التشابه

3. الضغط (Compress): تحويل “الحرب والسلام” إلى ورقة واحدة

عند وجود معلومات كثيرة، من المهم ضغطها بكفاءة:

تلخيص تلقائي:

• تُلخص بريدًا إلكترونيًا مؤلفًا من 1000 كلمة إلى 3 جمل رئيسية

ترتيب الأهمية:

• الاحتفاظ بـ 20% من المعلومات الأكثر أهمية، لتغطية 80% من القيمة

تحديث تدريجي:

• تسجيل الأجزاء المتغيرة فقط، بدلاً من النسخ الكاملة

4. العزل (Isolate): التعاون بالتعاون بين فرق الخبراء

تتطلب المهام المعقدة تعاون عدة خبراء في الذكاء الاصطناعي:

تجزئة المهام:

• يتولى خبير التحليل المالي الأرقام
• يتولى الخبير القانوني فحص الامتثال
• يتولى خبير الكتابة إعداد التقرير النهائي

عزل المعلومات:

• يحصل كل خبير على المعلومات المعنية فقط
• تجنب الضغط المعلوماتي والخلط

دمج النتائج:

• يقوم الذكاء الاصطناعي المركزي بتجميع آراء الخبراء المختلفة
• يتخذ القرار النهائي

9. العائد على الاستثمار: لماذا هندسة السياق أكثر جدوى من ترقية النموذج

نسبة تكلفة مدهشة

وفقًا لبيانات الصناعة، فإن العائد على الاستثمار في هندسة السياق يتجاوز بكثير ترقيات النموذج: [المصدر: عدة دراسات حالة مجمعة]

هندسة السياق:

• تشغل 5% من ميزانية الذكاء الاصطناعي
• تجلب 40-90% من تحسين الأداء
• فترة التنفيذ: 2-3 أشهر

ترقية النموذج:

• تشغل 60-70% من ميزانية الذكاء الاصطناعي
• تجلب 10-20% من تحسين الأداء
• فترة التنفيذ: 6-12 شهرًا

فاتورة حقيقية من شركة تكنولوجيا

البيانات الفعلية لشركة تكنولوجيا متوسطة الحجم:

• بعد تنفيذ هندسة السياق، تم توفير 23,000 دولار أمريكي شهريًا من تكاليف الحوسبة
• من خلال قص السياق، انخفض حجم الإدخال بنسبة 80%
• انخفضت تكاليف استدعاء API بنفس النسبة 80%
• بينما تحسن الأداء بنسبة 15%

شبيهًا كما هو الحال مع التخطيط المروري الأفضل، مما يوفر تكلفة الوقود ويختصر زمن التنقل.

10. آفاق 2025: خطوة حاسمة من “العرض” إلى “الإنتاج”

توافق آراء الخبراء في الصناعة

“فشل معظم وكلاء الذكاء الاصطناعي أصبح ليس فشل النماذج بل فشل السياق.” هذه هي القناعة التي توصل إليها الجميع في الصناعة.

تحدد Cognition (فريق تطوير Devin AI) بوضوح: “هندسة السياق هي العمل الأساسي لبناء وكلاء الذكاء الاصطناعي”. [المصدر: مدونة cognition.ai]

توصيات ثلاثية للشركات

1. إجراء “تحقق صحي للسياق” على الفور

دوّن السيناريوهات الفاشلة لأنظمة الذكاء الاصطناعي لديك:

• ما المعلومات التي كانت مفقودة عندما أعطى الذكاء الاصطناعي إجابة خاطئة؟
• ما النقاط التي وُجدت بها فجوات معلوماتية؟
• ما مصادر البيانات المتاحة حاليًا في الأنظمة القائمة؟

2. اختيار مشروع تجريبي عالي القيمة

لا تحاول إصلاح جميع الأنظمة دفعة واحدة، بل اختر مشروعًا يتمتع بـ:

• تكرار الاستخدام العالي
• تكاليف فشل كبيرة
• مساحة تحسين واضحة

على سبيل المثال: خدمة العملاء، معالجة الطلبات، إنشاء التقارير

3. إنشاء آلية تعاون بين الأقسام

تتطلب هندسة السياق:

• قسم تكنولوجيا المعلومات: تقديم الدعم الفني
• القسم التجاري: تحديد طلبات المعلومات
• فريق البيانات: ضمان جودة البيانات
• فريق الامتثال: ضمان أمان المعلومات

تجنب الفخاخ الشائعة

فخ 1: السعي الأعمى وراء نماذج أكبر

• الفكرة الخاطئة: النموذج كلما كان أكبر كان أفضل
• الممارسة الصحيحة: قم بتحسين السياق أولاً، ثم ضع في اعتبارك ترقية النموذج

فخ 2: كلما كانت المعلومات أكثر كان أفضل

• الفكرة الخاطئة: قدم كل المعلومات الممكنة للذكاء الاصطناعي
• الممارسة الصحيحة: توفير المعلومات ذات الصلة بدقة

فخ 3: تجاهل جودة المعلومات

• الفكرة الخاطئة: إذا كان هناك معلومات فهذا يكفي
• الممارسة الصحيحة: ضمان دقة المعلومات، وتوقيتها، وتنظيمها

خاتمة: بداية عصر جديد

من المتوقع أن تُسجل الفترة من 2023 إلى 2025 في التاريخ بأنها “عام هندسة السياق”. من درس جوجل الذي كلف 100 مليار دولار، إلى الممارسات الناجحة في تسلا وأمازون وول مارت، نشهد اتجاهًا واضحًا:

نجاح الذكاء الاصطناعي لم يعد يعتمد على “دماغ أذكى”، بل “نظام ذاكرة أفضل”.

تكتسب الشركات التي تتمكن من احتواء هندسة السياق ميزة تنافسية مستدامة:

• تحسينات كبيرة في الكفاءة التشغيلية
• تحسينات ملحوظة في تجربة العملاء
• عائدات استثمار متنامية
• تقليل كبير في المخاطر والأخطاء

بينما قد تواجه الشركات التي تتجاهل هذا الاتجاه مصير الشركات التي فوتت ثورة الإنترنت في الماضي، وبذلك تُترك متأخرة زمنياً.

كما قال أحد القادة في الصناعة: “في عصر الذكاء الاصطناعي، قد تكون هندسة السياق هي الجزء الأكثر عائدًا من استثماراتك في الذكاء الاصطناعي.”

الآن، حان الوقت لإعادة النظر في استراتيجيات الذكاء الاصطناعي الخاصة بك. لا تسأل “هل نحن بحاجة إلى ذكاء اصطناعي أقوى؟” بل اسأل “كيف نجعل الذكاء الاصطناعي الحالي لدينا يفهم ويتذكر المعلومات الحيوية بشكل أفضل؟”

الإجابة، تكمن في هندسة السياق.

هذا المقال مستند إلى حالات عملية للشركات العالمية الرائدة من 2023 إلى 2025، وجميع البيانات مأخوذة من تقارير رسمية وإعلانات عامة.