Andej Karpathy之前提出“#氛围编程”（vibe coding）大火特火，今天AK又造了一个新词“#细菌式编程”
在软件开发的世界里，我们时常陷入关于最佳实践的无尽讨论中：是应该构建一个大而全的单体应用（Monolith），还是拥抱灵活的微服务（Microservices）？是该追求零依赖，还是善用成熟的第三方库？
细菌式编程
一、细菌编码的三大法则
Karpathy 指出，如果我们想构建一个蓬勃发展的开源社区，就应该学习细菌基因组的演化智慧。细菌的“代码”（即基因组）有三个显著特点：
小巧（Small）：在生物世界里，复制和维护每一行“代码”（DNA碱基对）都需要消耗能量。因此，自然选择的压力使得细菌的基因组非常精简，杜绝任何不必要的膨胀
模块化（Modular）：细菌的基因（功能）被组织成可插拔的“操纵子”（Operon，功能相关的基因簇）。这种模块化的设计使得不同的功能单元可以被轻松地组合或替换
自包含（Self-contained）：细菌通过“水平基因转移”（Horizontal Gene Transfer）的方式，可以直接“复制粘贴”有用的基因片段，而无需理解对方整个基因组的上下文。这种能力是它们快速适应环境的关键
Karpathy 向所有开发者提出了一个灵魂拷问：
对于你写的任何一个函数（基因）或类（操纵子），你能想象有人在不了解你项目其余代码、也无需导入任何新依赖的情况下，直接“顺手牵羊”（yoink）地拿走它，并立即从中获益吗？你的这段代码，有没有潜力成为一个热门的 GitHub Gist？
如果答案是肯定的，那么你就掌握了“细菌式编程”的精髓。正是这种编码风格，让细菌能够在地球深处、太空真空、酷热、严寒、强酸、强碱等各种极端环境中繁衍生息，并演化出千奇百怪的代谢能力
二、从“细菌”到“真核生物”：平衡
这种“细菌式”编码风格极擅长快速原型设计和创新，因为它鼓励代码的自由传播与重组，极大地促进了社区的“水平基因转移”
然而，Karpathy 也承认它的局限性：它无法构建复杂的生命体。
相比之下，更高级的真核生物（比如人类）的基因组，就像一个巨大、复杂、高度耦合的单体仓库（Monorepo）。它的创新性远不如细菌基因组，但这种高度的组织性和协调性，是构建完整器官并使其协同工作所必需的
那么，我们该如何选择？Karpathy 认为，凭借人类的智慧设计，我们完全可以兼得二者之长：
“如果你必须这样做，那就去构建一个‘真核生物式’的单体仓库骨架，但要在这个骨架之内，最大化‘细菌DNA’的比例。”
换言之，我们可以在一个统一、结构化的项目（Monorepo）中进行开发，以确保大型系统的复杂协调。但在这个大框架内，我们应该竭力将每一个功能、每一个模块写得像细菌基因一样——小巧、独立、自包含、易于“复制粘贴”
三、现实困境：“依赖噩梦”
有网友对Karpathy 想法不买账，比如当前流行的“预构建软件包”（pre-built packages）和包管理器（如 npm, pip）的初衷似乎正是为了实现这种模块化，但结果却事与愿违，演变成了一场难以解决的“依赖噩梦之网”
Karpathy 认为问题的根源是：
依赖泛滥的问题已经像一场瘟疫。在生物学中，代码（基因）是昂贵的，因为它消耗能量，所以基因组有自然的正则化（natural regularization）机制来防止臃肿。但在软件世界里，代码的成本太低了，导致它疯狂膨胀，最终变成一个脆弱不堪的烂摊子
聚焦 AI 大模型技术和应用，模型的训练与部署！7.25-7.26，DataFun主办的DA数智大会将在深圳举办。70+行业专家将探讨如何通过AI大模型技术赋能业务，同时提升企业内部的大数据和大模型结合应用的水平，期待你的加入~
Andrej Karpathy 不久前火了一个词——Context Engineering。
Shopify CEO Tobi Lütke 的一条推特引发了行业对此的广泛讨论，Andrej Karpathy 转发并表示强烈认同。
这不是一个新概念，只是业内共识的逐渐形成：决定 AI 应用效果的关键，已经不是你怎么问，而是你给 AI 喂了什么料。
提供完整且恰当的上下文往往比编写好的提示词更重要。
到底什么是「上下文工程」，在应用的落地开发中怎么更好使用「上下文工程」？接下来让我们回顾一下“#上下文工程” 我们整理了 DeepMind 工程师 Philipp Schmi、以及 LangChain 对此的讨论，希望在一篇文章里介绍清楚「上下文工程」的概念以及实操落地的问题。
Karpathy：「上下文工程」既是科学也是艺术
图：Andrej Karpathy 推特内容
支持「上下文工程」而不是「提示工程」。
人们通常将提示词（prompt）与日常使用中给 LLM 的简短任务描述联系起来。但在每个工业级 LLM 应用中，上下文工程（Context Engineering）是一门精妙的艺术与科学——它需要精准地为上下文窗口填充恰到好处的信息。
说它是科学，因为这项工作涉及任务描述与解释、少量示例、检索增强生成（RAG）、相关（可能是多模态的）数据、工具、状态与历史记录、信息压缩...提供太少或形式不当，LLM 就缺乏最优表现所需的上下文；过量或相关性不足，则会导致成本上升性能下降。做好这件事绝非易事。
而称之为艺术，则源于对人类心理与 LLM 行为之间微妙互动的直觉把握。
除了上下文工程本身，一个 LLM 应用还必须能够实现：
将问题恰到好处地分解为（control flows）；
恰到好处地填充上下文窗口
调度类型和能力都合适的 LLMs
处理「生成-验证」的用户交互（UI/UX）流程；
还有很多方面 - 安全护栏、防护措施、评估机制、并行处理、数据预取......
因此，上下文工程只是新兴复杂软件层中的一小部分，这些软件将单个 LLM 调用（以及更多内容）协调成完整的 LLM 应用。「ChatGPT 包装器」（ChatGPT wrapper）这个说法已经过时，而且大错特错。
在交流中，Karpathy 表示：
我并不是要造新词。只是觉得人们使用「prompt」这个词时，往往（错误地）低估了这个相当复杂的组件。你给 LLM 一个提示让它解释天空为什么是蓝色的。但应用程序会（精心）为 LLMs 构建上下文来解决它们的定制任务。
一、什么是上下文工程？
要理解上下文工程，我们首先得拓宽对「上下文」的定义。它不仅仅是发给大语言模型的一句提示词，而是模型生成回答之前所看到的一切信息。
图：上下文工程所包含的范围
上下文工程包括：
指令 / 系统提示词： 定义模型整体行为的初始指令，可以（也应该）包含示例、规则等。
用户提示词： 用户提出的即时任务或问题。
当前状态或对话历史（短期记忆）： 用户和模型此前的对话内容，展现当前交流的背景。
MCP" style='font-size: 15px;font-family: "mp-quote", -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;'>长期记忆： 跨多次对话积累的持久性知识库，比如用户喜好、历史项目摘要、记住的特定事实。
检索的信息（RAG）： 外部的、最新的信息，包括从文档、数据库或 API 获取的相关内容，用于回答特定问题。
可用工具： 模型可以调用的所有函数或内置工具定义（如检查库存、发送邮件等）。
结构化输出： 明确定义模型输出的格式，例如 JSON 格式的对象。
二、提示词工程、上下文工程到底啥区别？
提示词、提示词工程、上下文工程，三者的区别是什么？
提示词（Prompt）
提示词很好理解，就是用户给 AI 模型的 输入文本，直接向模型输入的问题或指令。 比如用户让 ChatGPT 总结一段文本、调用模型 API 传入提示词去翻译一篇文章等。简单理解，提示词是一段文本，有点像代码。
提示词工程 （Prompt Engineering）
提示词工程是一个过程，系统化地设计、测试、优化提示词的过程。
就像软件工程，我们为了完成某个需求，要有一套科学的方法来帮助完成软件开发的过程，有方法论（比如敏捷开发），要使用工具，要保证质量，不断迭代，最终交付软件，或者说代码。
简单来说，对翻译提示词「设计」、「测试」、「优化」的整个过程就是提示词工程。
上下文工程 （Context Engineering）
上下文工程是一门设计和构建动态系统的学科，能够在正确的时间，以正确的格式，为大语言模型提供恰当的信息和工具，使其能够完成任务。
上下文工程的特点包括：
它是个系统，而不是一句话： 上下文并不仅仅是一条静态的提示词模板，而是在模型调用之前运行的完整系统的输出。
动态生成： 根据即时任务需求动态生成。例如，某个请求可能需要日历数据，而另一个请求可能需要邮件内容或网络搜索结果。
在恰当的时间提供正确的信息和工具： 它的核心职责是确保模型不会遗漏关键细节（输入错误，输出必然错误）。这意味着只在需要时提供有用的知识（信息）和功能（工具）。
格式的重要性： 信息的呈现方式至关重要。清晰简洁的摘要好于杂乱无序的数据堆砌；明确的工具结构优于模糊的指令。
宝玉老师整理的一张图，非常直观地呈现了这三者之间的关系与区别。
图：提示词、提示词工程与上下文工程的关系
三、为什么「上下文工程」很重要？
构建真正有效的 AI Agent 的秘诀，不是取决于写的代码有多复杂，而是提供给 Agent 的上下文质量。
创建 Agent，真正关键的不是代码或框架，而在于提供的上下文信息质量。举个例子，假设你让 AI 助手基于一封简单的邮件来安排会议：
嘿，想确认一下，你明天方便快速碰一下吗？
一个普通的 Agent 只有糟糕的上下文，它只看到了用户的请求，尽管代码完全正确——调用大语言模型并获得了回应——但输出却呆板无用：
感谢您的信息。明天我可以，请问你想几点碰面？
「神奇的」Agent 则拥有丰富的上下文。它的主要任务并不是决定「怎么」回应，而是去「收集信息」，以让大语言模型顺利实现目标。在调用模型前，你需要扩展上下文，比如包括：
你的日历信息（显示明天已满）。
你和发件人的历史邮件（决定适当的随意语气）。
你的联系人列表（识别对方是关键合作伙伴）。
可用的工具，比如发送邀请或邮件。
然后生成如下回应：
嘿，Jim！明天我的日程已经排满了，一整天都是背靠背的会议。周四上午我有空，不知道你是否方便？我已经发了个邀请，看看是否合适。
这种效果，并不是来自更聪明的模型或更精巧的算法，而是来自提供了适合任务的正确上下文。这正是上下文工程的意义所在。Agent 的失败不再只是模型问题，而是上下文的失败。
四、「上下文工程」的四种落地策略
Langchain 近期发布的一篇博客文章，总结了四种常见的上下文工程策略。
图：上下文工程的一般类别
4.1 写入上下文 （Write Context）
写入上下文，是指将信息保存到上下文窗口之外，以辅助 Agent 完成任务。
草稿板 （Scratchpads）
当人类在解决任务时，会做笔记并为未来相关的任务保留记忆。如今，Agent 也正逐步具备这些能力，通过「草稿板」做笔记，是在 Agent 执行任务期间持久化保留信息的一种方法。核心思想是将信息保存在上下文窗口之外，同时又能让 Agent 随时取用。
Anthropic 的多 Agent 研究员给出了一个清晰的例子：
LeadResearcher 首先会思考整个处理流程，并将计划保存到内存中，以确保上下文的持久化，因为一旦上下文窗口超过 200,000 个 token，内容就会被截断，而保留计划至关重要。
草稿板可以通过几种不同方式实现。它可以是一个仅将内容写入文件的工具调用；也可以是运行时状态对象中的一个字段，保持在整个会话期间保持不变。但无论是采用哪种方式，草稿板都让 Agent 能够保存有用信息，从而更好地完成任务。
记忆 （Memories）
草稿板帮助 Agent 在单次会话（或线程）中解决任务，但有时，Agent 需要跨越多个会话来记忆信息，这会带来更大地助益。Reflexion 引入了在 Agent 每一轮行动后进行反思，并复用这些自我生成记忆的理念。而「生成式 Agent」（Generative Agents）则会从过往的 Agent 反馈集合中，周期性地合成记忆。
图：LLM 可用于更新或创建记忆
这些概念已经被 ChatGPT、Cursor 和 Windsurf 等热门产品所应用，这些产品都拥有能够根据用户与 Agent 的交互，自动生成可跨会话持久化的长期记忆的机制。
4.2 筛选上下文 （Select Context）
筛选上下文，是指将所需信息拉入上下文窗口，来辅助 Agent 完成任务。
草稿板 （Scratchpad）
从草稿板中筛选上下文的机制，取决于草稿板的具体实现方式。如果它是一个工具，那么 Agent 只需通过工具调用便可读取内容。如果它是 Agent 运行时状态的一部分，那么开发者则可以在每一步选择将状态的哪些部分公开给 Agent。这些在为之后地后续回合中向 LLM 提供草稿板上下文提供了精细化的控制。
记忆 （Memories）
如果 Agent 具备保存记忆的能力，它们也需要能够筛选出与当前执行任务相关的记忆。这样做有几个好处：Agent 可以筛选出少样本示例（情景记忆）作为期望行为的范例；可以筛选出指令（程序性记忆）来引导自身行为；或者可以筛选出事实（语义记忆）作为与任务相关的上下文。
图：几种记忆类型
挑战之一是确保筛选出来的记忆是相关的。一些主流的 Agent 仅使用一小部分固定文件，并能将它们拉入到上下文中。例如，许多编码 Agent 使用特定文件来保存指令（「程序性」记忆），或在某些情况下保存示例（「情景」记忆）。Claude Code 使用 CLAUDE.md 文件，Cursor 和 Windsurf 则使用规则文件。
但是，如果 Agent 存储了大量的记忆（例如语义记忆），包括事实或关系，筛选就更难了。ChatGPT 就是一个很好的例子，这款主流产品能够从大量用户专属记忆中进行存储和筛选。
使用嵌入（Embeddings）或知识图谱进行记忆索引，是一种辅助筛选的常用方法。尽管如此，记忆筛选仍然充满挑战。在 AI Engineer World's Fair 大会上，Simon Willison 分享了一个筛选出错的案例：ChatGPT 从记忆中获取了他的位置信息，并意外地将其注入到一张他要求的图片中。这种意料之外或不希望出现的记忆检索，会让一些用户感觉上下文窗口「不再属于他们自己」了！
工具 （Tools）
Agent 需要使用工具，但如果提供的工具过多，可能会不堪重负。通常是因为工具描述之间存在重叠，导致模型在选择使用哪个工具时感到困惑。一种方法是对工具描述采用 RAG 技术，以便只检索与任务最相关的工具。一些近期的论文表明，这种方法可以将工具选择的准确率提升 3 倍。
知识 （Knowledge）
RAG 是一个内容丰富的话题，也可能成为上下文工程中的一个核心挑战。编码 Agent 是在大规模生产环境中应用 RAG 的最佳范例之一。来自 Windsurf 的联创兼 CEO Varun Mohan 很好地概括了其中的一些挑战：
「代码索引 ≠ 上下文检索，我们正在进行索引和嵌入搜索，包括对代码进行 AST 解析，并沿着有语义意义的边界进行分块。随着代码库规模的增长，嵌入搜索作为一种检索启发式方法变得不再可靠，我们必须依赖多种技术的组合，例如 grep/文件搜索、基于知识图谱的检索，以及一个重排序步骤，在此步骤中，上下文会按相关性进行排序。」
4.3 压缩上下文 （Compressing Context）
压缩上下文，指的是仅保留执行任务所必需的 token。
上下文摘要 （Context Summarization）
Agent 的交互可能长达数百轮，并使用消耗大量 token 的工具调用。摘要是应对这些挑战的一种常见方法。如果你用过 Claude Code，应该见过这个功能的实际应用。当上下文窗口超过 95% 时，它会运行「自动压缩」（auto-compact）功能，总结用户与 Agent 交互的整个轨迹。这种贯穿 Agent 执行轨迹的压缩可以采用多种策略，如递归或分层摘要。
图：摘要技术可以应用的几个环节
在 Agent 设计的特定环节加入摘要功能也可能很有用。例如，它可以用于后处理某些工具调用（如消耗大量 token 的搜索工具）。再比如，Cognition 提到在 Agent 之间进行知识传递时进行摘要，来减少 token 的消耗。如果需要精准捕捉特定的事件或决策，摘要可能会成为一项挑战。Cognition 为此使用了一个精调模型，这也突显了这一步可能需要投入的大量工作。
上下文修剪 （Context Trimming）
如果说摘要通常是利用 LLM 来提炼上下文中最相关的部分，那么修剪则通常是过滤或（如 Drew Breunig 所指出的）「裁剪」（prune）上下文。这可以采用硬编码的启发式规则，比如从列表中删除较早的消息。此外，Drew 还提到了一个为问答任务训练的上下文裁剪器「Provence」。
5.1 隔离上下文 （Isolating Context）
隔离上下文，指的是通过拆分上下文来辅助 Agent 完成任务。
多 Agent （Multi-agent）
将上下文分散到不同的子 Agent 中，是隔离上下文最主流的方法之一。OpenAI 的 Swarm 库的动机之一是实现「关注点分离」（separation of concerns），即让一个 Agent 团队处理特定的子任务。每个 Agent 都拥有一套特定的工具、指令和自己的上下文窗口。
图：将上下文分散到多个 Agent 中
Anthropic 的多 Agent 研究员也为此提供了论据：多个拥有独立上下文的 Agent 的表现优于单个 Agent，这很大程度上是因为每个子 Agent 的上下文窗口都可以分配给一个更专注的子任务。正如其博客文章所说：
「 子 Agent 在各自的上下文窗口中并行运作，同时探索问题的不同方面。」
当然，多 Agent 也面临挑战，包括 token 使用量（据 Anthropic 报告，最高可达聊天模式的 15 倍）、需要精心的提示工程来规划子 Agent 的工作，以及子 Agent 之间的协调问题。
利用环境隔离上下文 （Context Isolation with Environments）
HuggingFace 的 Deep Researcher 项目展示了另一个有趣的上下文隔离示例。大多数 Agent 使用工具调用 API，这些 API 返回 JSON 对象（工具参数），参数被传递给工具（如搜索 API）以获取工具反馈（如搜索结果）。而 HuggingFace 使用的是一个 CodeAgent，它会输出包含所需工具调用的代码。然后，这些代码在一个沙盒（sandbox）中运行。从工具调用中筛选出的上下文（如返回值）再被传回给 LLM。
图：沙盒可以将上下文与 LLM 隔离开来
这使得上下文可以在环境中与 LLM 隔离开来。Hugging Face 指出，这是一种隔离消耗大量 token 的对象的好方法：
「代码 Agent 可以更好地处理状态，那如果需要存储这个图像/音频/或其他内容以备后用呢？没问题，只需在你的状态中将其赋值给一个变量，你就可以稍后使用它。」
状态 （State）
值得一提的是，Agent 的运行时状态对象本身也是一种隔离上下文的好方法。这可以起到与沙盒相同的作用。可以为状态对象设计一个包含多个字段的模式（schema），上下文可以写入这些字段中。模式中的一个字段（如消息）可以在 Agent 的每一轮交互中暴露给 LLM，但模式可以将信息隔离在其他字段中，以供更有选择性地使用。
