Karpathy提出细菌式编程与上下文工程演进

在软件开发思想不断演进的今天，Andrej Karpathy 再次引爆技术社区，提出了“细菌式编程”（Bacterial Coding）这一全新概念。这一理念借鉴了生物学中细菌基因的演化规律，为开源社区的代码协作与单体架构的模块化设计提供了极具启发性的框架。与此同时，Karpathy 也深入探讨了“上下文工程”（Context Engineering）作为构建现代 AI 应用的核心艺术与科学。本文旨在系统性地梳理这两大主题，帮助开发者从零散的观点中抓取重心，掌握从宏观思想到落地实践的全景图。

细菌式编程：像细菌一样优雅的代码哲学

一、细菌式编程的三大法则

Karpathy 指出，要想构建一个欣欣向荣的开源社区，我们应该向细菌的基因组演化智慧学习。细菌的“代码”（即基因组）具有三个显著特点：

小巧（Small）：在生物世界中，复制和维护每一行“代码”（DNA 碱基对）都需要消耗能量。自然选择的压力迫使细菌的基因组极度精简，杜绝任何不必要的膨胀。

模块化（Modular）：细菌的基因（功能）被组织成可插拔的“操纵子”（Operon，功能相关的基因簇）。这种模块化设计使得不同的功能单元可以轻松地被组合或替换。

自包含（Self-contained）：细菌通过“水平基因转移”（Horizontal Gene Transfer），可以直接“复制粘贴”有用的基因片段，无需理解对方整个基因组的上下文。这种能力是其快速适应环境的关键。

Karpathy 向所有开发者提出了一个灵魂拷问：

如果答案是肯定的，那么你就掌握了细菌式编程的精髓。正是这种编码风格，让细菌能够在地球深处、太空真空、酷热、严寒、强酸、强碱等各种极端环境中繁衍生息，并演化出千奇百怪的代谢能力。

小提示： 你可以尝试用“Gist 测试”来检验自己的代码是否具备了“细菌式”基因。每次写完一个函数或模块，问自己：如果把它单独发布成 GitHub Gist，别人能直接复制粘贴并用起来吗？如果不能，尝试重构代码以减少对项目其他部分和外部依赖的耦合。

二、从“细菌”到“真核生物”：在单体架构中寻求平衡

这种“细菌式”编码风格极擅长快速原型设计和创新，因为它鼓励代码的自由传播与重组，极大地促进了社区的“水平基因转移”。

然而，Karpathy 也承认它的局限性：它无法构建复杂的生命体。

相比之下，更高级的真核生物（比如人类）的基因组，就像一个巨大、复杂、高度耦合的单体仓库（Monorepo）。它的创新性远不如细菌基因组，但这种高度的组织性和协调性，是构建完整器官并使其协同工作所必需的。

那么，我们该如何选择？Karpathy 认为，凭借人类的智慧设计，我们完全可以兼得二者之长：

换言之，我们可以在一个统一、结构化的项目（Monorepo）中进行开发，以确保大型系统的复杂协调。但在这个大框架内，我们应该竭力将每一个功能、每一个模块写得像细菌基因一样——小巧、独立、自包含、易于“复制粘贴”。

小提示： 在实际项目中，你可以通过定义明确的接口（Interface）和合约（Contract）来隔离模块。例如，使用面向接口编程，或采用依赖注入的方式，让每个模块的上下文尽可能不依赖外部状态。

三、现实困境：从“依赖噩梦”到“自然正则化”

有网友对 Karpathy 的想法不买账，比如当前流行的“预构建软件包”（pre-built packages）和包管理器（如 npm, pip）的初衷似乎正是为了实现这种模块化，但结果却事与愿违，演变成了一场难以解决的“依赖噩梦之网”。

Karpathy 认为问题的根源是：

依赖泛滥的问题已经像一场瘟疫。在生物学中，代码（基因）是昂贵的，因为它消耗能量，所以基因组有自然的正则化（natural regularization）机制来防止臃肿。但在软件世界里，代码的成本太低了，导致它疯狂膨胀，最终变成一个脆弱不堪的烂摊子。

常见问题：

问：细菌式编程和微服务架构有什么区别？

答： 微服务强调的往往是运行时层面的独立部署和网络通信，而细菌式编程更侧重于代码层面的可读性、可移植性和低耦合性。微服务可能带来额外的网络开销和运维复杂度，而细菌式编程提倡的是在单体仓库内部实现高度的模块化和自包含。两者并不矛盾，但微服务实现的是宏观层面的解耦，而细菌式编程追求的是微观层面每个函数、类的“原子化”品质。

问：如何避免“细菌式编程”演变成代码碎片化？

答： 关键在于建立好“真核生物的骨架”。在顶层架构上，通过清晰的项目结构、统一的风格指南、完善的测试和代码审查制度，来确保这些“细菌 DNA”能够和谐地组成功能完备的器官。避免在无结构的大杂烩中随意堆放独立的函数。

上下文工程：构建AI应用的底层逻辑与实战指南

在软件工程之外，Karpathy 在 AI 领域也提出了一个重要观点：决定 AI 应用效果的关键，已经不再是单纯地“怎么问”，而是你给 AI 喂了什么料。Karpathy 强烈推崇“上下文工程”（Context Engineering），并将其视为一门精妙的艺术与科学。

图：Andrej Karpathy 推特内容（原文插图，此处保留占位）

一、什么是上下文工程？

要理解上下文工程，我们首先得拓宽对“上下文”的定义。它不仅仅是发给大语言模型的一句提示词，而是模型生成回答之前所看到的一切信息。

图：上下文工程所包含的范围（原文插图，此处保留占位）

上下文工程包括：

指令 / 系统提示词： 定义模型整体行为的初始指令，可以（也应该）包含示例、规则等。

用户提示词： 用户提出的即时任务或问题。

当前状态或对话历史（短期记忆）： 用户和模型此前的对话内容，展现当前交流的背景。

长期记忆： 跨多次对话积累的持久性知识库，比如用户喜好、历史项目摘要、记住的特定事实。

检索的信息（RAG）： 外部的、最新的信息，包括从文档、数据库或 API 获取的相关内容，用于回答特定问题。

可用工具： 模型可以调用的所有函数或内置工具定义（如检查库存、发送邮件等）。

结构化输出： 明确定义模型输出的格式，例如 JSON 格式的对象。

二、提示词、提示词工程、上下文工程的区别

提示词（Prompt）

提示词很好理解，就是用户给 AI 模型的输入文本，直接向模型输入的问题或指令。简单理解，提示词是一段文本，有点像代码。

提示词工程（Prompt Engineering）

提示词工程是一个过程，系统化地设计、测试、优化提示词的过程。就像软件工程，要有一套科学的方法来帮助完成需求的开发，有方法论（比如敏捷开发），要使用工具，要保证质量，不断迭代，最终交付软件。

上下文工程（Context Engineering）

上下文工程是一门设计和构建动态系统的学科，能够在正确的时间，以正确的格式，为大语言模型提供恰当的信息和工具，使其能够完成任务。

上下文工程的特点包括：

它是个系统，而不是一句话： 上下文并不仅仅是一条静态的提示词模板，而是在模型调用之前运行的完整系统的输出。

动态生成： 根据即时任务需求动态生成。例如，某个请求可能需要日历数据，而另一个请求可能需要邮件内容或网络搜索结果。

在恰当的时间提供正确的信息和工具： 确保模型不会遗漏关键细节。这意味着只在需要时提供有用的知识（信息）和功能（工具）。

格式的重要性： 信息的呈现方式至关重要。清晰简洁的摘要好于杂乱无序的数据堆砌；明确的工具结构优于模糊的指令。

宝玉老师整理的一张图，非常直观地呈现了这三者之间的关系与区别。

图：提示词、提示词工程与上下文工程的关系（原文插图，此处保留占位）

小提示： 记住一个简单的类比：提示词是“问题”，提示词工程是“如何问出好问题”，而上下文工程则是“为回答问题搭建好资料库和工具箱”。在构建应用时，把重心放在后者上，效果往往事半功倍。

三、为什么上下文工程很重要？

构建真正有效的 AI Agent 的秘诀，不是取决于写的代码有多复杂，而是提供给 Agent 的上下文质量。

创建 Agent，真正关键的不是代码或框架，而在于提供的上下文信息质量。举个例子，假设你让 AI 助手基于一封简单的邮件来安排会议：

一个普通的 Agent 只有糟糕的上下文，它只看到了用户的请求，尽管代码完全正确——调用大语言模型并获得了回应——但输出却呆板无用：

“神奇的”Agent 则拥有丰富的上下文。它的主要任务并不是决定“怎么”回应，而是去“收集信息”，以让大语言模型顺利实现目标。在调用模型前，你需要扩展上下文，比如包括：

你的日历信息（显示明天已满）。

你和发件人的历史邮件（决定适当的随意语气）。

你的联系人列表（识别对方是关键合作伙伴）。

可用的工具，比如发送邀请或邮件。

然后生成如下回应：

这种效果，并不是来自更聪明的模型或更精巧的算法，而是来自提供了适合任务的正确上下文。这正是上下文工程的意义所在。Agent 的失败不再只是模型问题，而是上下文的失败。

常见问题：

问：上下文工程和RAG（检索增强生成）是一个意思吗？

答： 不是。RAG是上下文工程的一种具体实现策略（用于检索外部知识）。上下文工程的范围远大于RAG，它还包括了系统提示词、短期记忆、长期记忆（反射）、工具定义、上下文压缩（摘要/修剪）、上下文隔离（多Agent）等众多方面。可以说，RAG是支撑上下文工程的众多能力的其中一种。

问：上下文窗口用完怎么办？上下文工程如何应对token限制？

答： 这正是“压缩上下文”策略的应用场景。可以通过上下文摘要（Summarization）将冗长的对话历史提炼成简短的摘要；或者通过上下文修剪（Trimming）过滤掉早期不相关的消息。对于超长任务，还可以使用多Agent架构，将大任务拆解到多个独立的、上下文窗口更聚焦的子Agent中。

四、上下文工程的四种落地策略

Langchain 近期发布的一篇博客文章，总结了四种常见的上下文工程策略。

图：上下文工程的一般类别（原文插图，此处保留占位）

4.1 写入上下文（Write Context）

写入上下文，是指将信息保存到上下文窗口之外，以辅助 Agent 完成任务。

草稿板（Scratchpads）

当人类在解决任务时，会做笔记并为未来相关的任务保留记忆。Agent 也正逐步具备这些能力，通过“草稿板”做笔记，是在 Agent 执行任务期间持久化保留信息的一种方法。核心思想是将信息保存在上下文窗口之外，同时又能让 Agent 随时取用。

草稿板可以通过几种不同方式实现：它可以是一个仅将内容写入文件的工具调用；也可以是运行时状态对象中的一个字段，保持在整个会话期间保持不变。

记忆（Memories）

草稿板帮助 Agent 在单次会话（或线程）中解决任务，但有时，Agent 需要跨越多个会话来记忆信息。Reflexion 引入了在 Agent 每一轮行动后进行反思，并复用这些自我生成记忆的理念。而“生成式 Agent”（Generative Agents）则会从过往的 Agent 反馈集合中，周期性地合成记忆。

图：LLM 可用于更新或创建记忆（原文插图，此处保留占位）

这些概念已经被 ChatGPT、Cursor 和 Windsurf 等热门产品所应用，这些产品都拥有能够根据用户与 Agent 的交互，自动生成可跨会话持久化的长期记忆的机制。

4.2 筛选上下文（Select Context）

筛选上下文，是指将所需信息拉入上下文窗口，来辅助 Agent 完成任务。

从草稿板中筛选

从草稿板中筛选上下文的机制，取决于草稿板的具体实现方式。如果它是一个工具，那么 Agent 只需通过工具调用便可读取内容。如果它是 Agent 运行时状态的一部分，那么开发者则可以在每一步选择将状态的哪些部分公开给 Agent。

从记忆中筛选

如果 Agent 具备保存记忆的能力，它们也需要能够筛选出与当前执行任务相关的记忆。这样做有几个好处：Agent 可以筛选出少样本示例（情景记忆）作为期望行为的范例；可以筛选出指令（程序性记忆）来引导自身行为；或者可以筛选出事实（语义记忆）作为与任务相关的上下文。

图：几种记忆类型（原文插图，此处保留占位）

挑战之一是确保筛选出来的记忆是相关的。一些主流的 Agent 仅使用一小部分固定文件，并能将它们拉入到上下文中。例如，Claude Code 使用 CLAUDE.md 文件，Cursor 和 Windsurf 则使用规则文件。

使用嵌入（Embeddings）或知识图谱进行记忆索引，是一种辅助筛选的常用方法。尽管如此，记忆筛选仍然充满挑战。在 AI Engineer World's Fair 大会上，Simon Willison 分享了一个筛选出错的案例：ChatGPT 从记忆中获取了他的位置信息，并意外地将其注入到一张他要求的图片中。

从工具中筛选

Agent 需要使用工具，但如果提供的工具过多，可能会不堪重负。一种方法是对工具描述采用 RAG 技术，以便只检索与任务最相关的工具。一些近期的论文表明，这种方法可以将工具选择的准确率提升 3 倍。

从知识中筛选（RAG）

RAG 是一个内容丰富的话题，也可能成为上下文工程中的一个核心挑战。编码 Agent 是在大规模生产环境中应用 RAG 的最佳范例之一。来自 Windsurf 的联创兼 CEO Varun Mohan 很好地概括了其中的一些挑战：

4.3 压缩上下文（Compressing Context）

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

上下文摘要（Context Summarization）

Agent 的交互可能长达数百轮，并使用消耗大量 token 的工具调用。摘要是应对这些挑战的一种常见方法。如果你用过 Claude Code，应该见过这个功能的实际应用。当上下文窗口超过 95% 时，它会运行“自动压缩”（auto-compact）功能，总结用户与 Agent 交互的整个轨迹。

图：摘要技术可以应用的几个环节（原文插图，此处保留占位）

在 Agent 设计的特定环节加入摘要功能也可能很有用。例如，它可以用于后处理某些工具调用（如消耗大量 token 的搜索工具）。如果需要精准捕捉特定的事件或决策，摘要可能会成为一项挑战。

上下文修剪（Context Trimming）

如果说摘要通常是利用 LLM 来提炼上下文中最相关的部分，那么修剪则通常是过滤或裁剪上下文。这可以采用硬编码的启发式规则，比如从列表中删除较早的消息。

4.4 隔离上下文（Isolating Context）

隔离上下文，指的是通过拆分上下文来辅助 Agent 完成任务。

多Agent（Multi-agent）

将上下文分散到不同的子 Agent 中，是隔离上下文最主流的方法之一。OpenAI 的 Swarm 库的动机之一是实现“关注点分离”（separation of concerns），即让一个 Agent 团队处理特定的子任务。每个 Agent 都拥有一套特定的工具、指令和自己的上下文窗口。

图：将上下文分散到多个 Agent 中（原文插图，此处保留占位）

Anthropic 的多 Agent 研究员也为此提供了论据：多个拥有独立上下文的 Agent 的表现优于单个 Agent，这很大程度上是因为每个子 Agent 的上下文窗口都可以分配给一个更专注的子任务。正如其博客文章所说：

当然，多 Agent 也面临挑战，包括 token 使用量（据 Anthropic 报告，最高可达聊天模式的 15 倍）、需要精心的提示工程来规划子 Agent 的工作，以及子 Agent 之间的协调问题。

利用环境隔离上下文（Context Isolation with Environments）

HuggingFace 的 Deep Researcher 项目展示了另一个有趣的上下文隔离示例。它使用的是一个 CodeAgent，会输出包含所需工具调用的代码，然后在沙盒（sandbox）中运行。从工具调用中筛选出的上下文（如返回值）再被传回给 LLM。

图：沙盒可以将上下文与 LLM 隔离开来（原文插图，此处保留占位）

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

状态（State）

Agent 的运行时状态对象本身也是一种隔离上下文的有效方法。可以为状态对象设计一个包含多个字段的模式（schema），上下文可以写入这些字段中。模式中的一个字段（如消息）可以在 Agent 的每一轮交互中暴露给 LLM，但模式可以将信息隔离在其他字段中，以供更有选择性地使用。

综合来看，无论是“细菌式编程”所追求的代码层面的自包含与模块化，还是“上下文工程”在应用层面追求的精准、动态的信息供给，其核心思想都是相通的：通过将系统拆解为小而精、语义清晰的单元（无论是函数还是上下文片段），来实现更高的复用性、适应性和鲁棒性。掌握这两种思维，将帮助开发者在复杂软件工程和智能应用构建中做出更明智的决策。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Karpathy提出细菌式编程与上下文工程演进要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题