Transcript
00:00:00SQLite 用 Rust 进行了重写。
00:00:02我知道我们刚才聊过用 Rust 重写 Bun 的事，
00:00:04你可能会好奇为什么大家都在用 Rust
00:00:06重写一切，但今天重点不是 Rust。
00:00:09甚至重点也不是 SQLite。
00:00:11我知道有个叫 Turso 的数据库，
00:00:15它已经是 SQLite 在 Rust 中
00:00:18的一个现代化重新实现版本。
00:00:19如果你想在生产环境中使用
00:00:21基于 Rust 的 SQLite 数据库，
00:00:23那才是你应该选择的方案。
00:00:26相反，这次的实验性项目 mini-sqlite
00:00:29（下方有链接，大家可以去看看），
00:00:32核心并不是为了 SQLite 或 Rust。
00:00:34它是 Cursor 团队做的一个实验，
00:00:37重点完全在于 AI 智能体蜂群（agent swarms）以及构建
00:00:40AI 智能体系统，摸索什么行得通、
00:00:44什么行不通，从而纯粹根据文档
00:00:47构建出像 SQLite 这样的项目，
00:00:51因为这才是该实验的真正目的。
00:00:53他们写了一篇非常详细、有趣的博客文章，
00:00:56我们稍后会深入探讨。
00:00:57里面有很多值得讨论的精彩经验，
00:00:59文章链接也在下方，
00:01:02文中解释了他们是如何运行这个实验的。实验的起点
00:01:07和核心构想，是直接拿 SQLite 的官方文档——
00:01:12如果全部整理成一个文档，总共有 835 页——
00:01:18而这些文档显然主要是写给人看的。
00:01:23我的意思是，这并不是我见过最平易近人的文档，
00:01:27但很明显它是给人类读的，因为它比所有 AI 智能体技术都要早得多。
00:01:32尽管如此，它也充当了一份超详细的规范，
00:01:37一份极其详尽的技术规范，因为它详细描述了如何使用 SQLite
00:01:43以及它的预期行为和预期的功能特性。
00:01:48Cursor 团队拿到了这份文档，
00:01:52然后又引入了一个公开的测试集 SQLogicTest，
00:01:57这是一套用于测试 SQLite 行为
00:02:02或专门测试查询语句的测试集。
00:02:05他们用这套测试集来验证
00:02:09智能体根据文档构建出的实现
00:02:13是否真的能通过这个官方的大型测试套件。
00:02:19不过，在此之前有几点重要的注意事项需要提前说明。
00:02:23这个测试套件完全是用来测试查询和查询行为的。
00:02:29它并没有测试 SQLite 的所有功能和全部特性。
00:02:35它不测试整体性能，
00:02:38也不测试并发性能。
00:02:40SQLite 中有很多内容是该测试集没有覆盖到的。
00:02:44而作为该实验成果之一的 mini-sqlite，
00:02:49实际上他们用不同的智能体组合多次重构了 SQLite。
00:02:53我们稍后会深入讲解，它纯粹只是一个探索性的产物。
00:02:57它不具备生产可用性，
00:02:59并不是你实际想拿去用的东西。
00:03:01它只是一个实验的输出结果，实验的目标是利用文档
00:03:06重新构建 SQLite，并让这个重构版本通过所有那些测试。
00:03:13Cursor 团队在这里使用了多种模型组合。
00:03:17为什么要组合？
00:03:18因为我们后面会看到，他们采用了一种
00:03:21多智能体协作的方法，包括规划者（planner）、执行者（worker）和审查者（reviewer）智能体。
00:03:28他们用不同的模型组合重新构建了这个 SQLite 数据库，并对比测量了达到相近质量时的表现。
00:03:37这些组合都达到了相同的质量水平、通过了相同数量的测试，但他们测量了不同组合的成本差异。
00:03:45例如，全程使用 GPT-5.5 来担任规划者和执行者，根据文档在 Rust 中实现 SQLite 的成本大约为 10,000 美元。
00:03:59另一方面，将 Opus 4.8 与 Composer 2.5 结合使用——Composer 2.5 是 Cursor 开发的超快、极便宜、高效率但智商并非顶尖的模型——将这两者结合，可以在达到相同质量、通过相同数量测试的情况下，成本仅为其他组合的一小部分，只要 1,300 美元。
00:04:24这里的思路是利用能力更强的高阶模型 Opus 4.8 来做规划和任务拆解，然后把拆分好的任务下发给使用 Composer 2.5 的执行者智能体。
00:04:39而这正是本文给出的一个重要启示，当然这也不算全新的概念。
00:04:44你在开发软件时也可以自己采用这种策略。
00:04:47根据工作的复杂程度，将工作拆分为由不同智能体（或子智能体）执行的特定任务是个好主意，其中一部分智能体专注于规划，
00:05:03负责设计整体任务中的具体子任务（可以说是一项独立的工作），然后再安排大量智能体去具体实现该任务。
00:05:14因为事实证明，只要上下文足够优质，仅为了输出高质量代码并不一定需要顶尖的旗舰级智能。
00:05:24也就是说，只要任务定义清晰，所有有用的信息都包含在任务描述中即可，当然，其他因素也很关键。
00:05:33例如，周边代码库的结构如何、给智能体提供的示例质量如何，这些都很关键。
00:05:39这些都会影响最终输出，但只要任务规范明确且上下文优良，单纯写代码的执行者智能体完全可以靠数量胜出。
00:05:49这正是本次实验的核心研究方向：
00:05:52如何设计一个能够应对如此大规模任务的系统。
00:05:57因为正如我所说，在你自己的项目中，采用“规划者+执行者”智能体架构也是非常值得考虑的。
00:06:07当然，并不是所有任务都适用。
00:06:10如果只是快速修复一个 Bug 或非常简单的任务，直接告诉你的 Codex、Claude Code 或其他智能体就完全足够了：
00:06:19“嘿，我遇到这个难题了，
00:06:20帮我把这个搞定。”
00:06:21提供一些额外的上下文，让它去干活就行。
00:06:24根据编程智能体框架的不同，它可能会自动启动子智能体。
00:06:28比如 Claude Code 可能会这么做，
00:06:31而像 Pi 这样的框架，如果你没给它配置合适的扩展，可能就不会。
00:06:36但即使没有子智能体，很多任务单靠一个智能体也能解决得很好。
00:06:43不过对于更复杂的项目和任务，分工协作会非常有用，包括引入审查者智能体。
00:06:51这也是我个人非常喜欢的一种做法，
00:06:54当然，这依然取决于任务的复杂程度。
00:06:56但这种职责分离的效果确实非常出彩。
00:06:59这自然称不上是什么开天辟地的突破。
00:07:02真正具有创新性的是，在重写 SQLite 这种大型项目中，你会拥有多个并行运行的规划者、执行者和审查者智能体流程，不仅有多个执行者，还有多个规划者和审查者。
00:07:18而它们时刻都在发生碰撞。
00:07:19这正是 Cursor 团队最终得出的结论。
00:07:22在这篇非常非常有趣的博客文章里，
00:07:26他们提到今年早些时候，他们就用智能体框架做过一个从零构建 Web 浏览器的实验。
00:07:33现在他们又用同一个框架（或者准确地说是同一套智能体系统）来完成 SQLite 的重构。
00:07:40同时，他们还根据最新的经验积累，构建了一套全新的实验系统。
00:07:47在这项实验和博客文章中，他们对比了这些不同的方法，并深入探讨了在试图搭建和运行这套重构 SQLite 的系统时所遇到的所有挑战。
00:07:59当面对一个成百上千甚至成千上万个执行者同时工作的系统时，他们遇到的首要挑战之一，就是传统的版本控制系统 Git 已经不堪重负了。
00:08:13正如他们在一篇关于蜂群架构的前期文章中所写：我们知道像 Git 和 Cargo 这样的工具依赖粗粒度的锁来进行并发控制，这意味着同一块数据会被加锁，从而无法支持多个写入者同时修改。
00:08:30这对于单个开发者来说完全没问题，但根本无法应对几百个并发智能体产生的天量工作成果。
00:08:36今年早些时候构建浏览器的智能体蜂群，峰值大约是每小时 1000 次提交（commit）。
00:08:41那是当时重构浏览器的蜂群数据。
00:08:45而他们为本次实验设计的全新系统，峰值达到了每秒大约 1000 次提交。
00:08:52也就是说，他们今年早些时候运行的旧蜂群是每小时 1000 次提交，这当然已经比大多数人类程序员高多了；
00:09:02然而新系统达到了每秒约 1000 次提交，这简直令人震惊，也显而易见绝非 Git 设计之初所能承受的。
00:09:14显而易见。
00:09:15“为了支持这种级别的活动频率，我们从零构建了一套全新的版本控制系统。”
00:09:21“吞吐量并不是我们选择自主掌控这一层的唯一原因。”
00:09:25“系统中的每一次变更都会经过这个版本控制系统，”
00:09:29“因此这里是冲突最早暴露的地方。”
00:09:31“下一节要介绍的几种协调机制，就是直接在该系统内部实现的。”
00:09:37这真的很令人瞩目。
00:09:39他们为 AI 智能体时代打造了一套全新的版本控制系统。
00:09:43因为大家都在用的旧系统 Git，虽然本身没有任何问题——
00:09:48这里需要先澄清一下。
00:09:49我们讨论的是这种极具规模和特定任务的实验，我们绝大多数人至少在短期内都不会接触到。
00:09:57但即便如此，像 Git 这样的旧系统并不是为了几百个智能体、几百个主体同时在同一个代码库上工作而设计的。
00:10:07因此，他们构建了一个全新的版本控制系统，不仅能够处理极高的并发量，还能协助通过 Agent 解决冲突。
00:10:19因为很显然，当两次修改触及文件中同一段代码时，版本控制系统就是冲突最先浮出水面之处。
00:10:28所以这是第一个关键要点：
00:10:30他们专门为这个实验量身定制了一套全新的版本控制系统，以便能够高效地运行并完成这项实验。
00:10:37自然而然地，正如他们在文章中所述，在每秒 1000 次提交的高频变更和巨大规模下，他们遇到了大量棘手问题。
00:10:48比如，他们遇到的所有这些问题以及相应的解决方案都非常引人入胜，因为这能让我们一窥未来的软件工程形态（至少在某些特定场景下）。
00:11:01第一个是“双脑架构设计问题（split brain design problem）”。
00:11:03两个互不知晓对方存在的规划者，在代码库的不同位置用不同的方式实现了同一个概念。
00:11:10这就是代码重复：同一个概念在不同的地方重复实现。
00:11:16通常情况下，你肯定希望把这段逻辑抽取出来重用，对吧？
00:11:21“我们通过提示词工程（prompting）解决了这个问题。”
00:11:24这里并没有构建什么高深的新系统，而是靠调整 Prompt 解决的。
00:11:28让规划者智能体自己做出设计决策，而不是把决策权向下委派；
00:11:34同时要求它们确保任意两个下分派的子树不会去决定同一个问题。
00:11:39所以这是一个架构设置问题。
00:11:40关键在于当把系统拆分为规划者、执行者等角色时，必须确保各个不同的规划者（因为不仅执行者是并行的，规划者也是并行的）拥有清晰定义的任务边界，极力避免任务冲突和重叠。
00:12:02因此，这归根结底始于人类的设计——
00:12:08即你如何搭建任务、如何撰写提示词，对吧？
00:12:11“我们通过提示词工程解决了这个问题。”
00:12:13然后这种逻辑会顺着智能体树向下传递到所有的并行节点和叶子节点，在智能体将任务拆分为子任务时，通过 Prompt 引导它们去切分重叠概率极低的子任务。
00:12:34归根结底，这对人类来说是一个规划层面上的挑战，核心在于人类如何以正确的方式搭建这套系统。
00:12:43这就是他们解决或应对该问题的方式。
00:12:47他们面临的另一个难题是“规划者之间的争用（contention between planners）”。
00:12:51“一种更严重的争用形式是，两个规划者感知到了彼此的存在，并通过对相同文件进行反复修改而互相拉扯。”
00:12:59“问题在于存在两套不同的现状认知，而合并工具无法解决这种分歧。”
00:13:04“相反，我们让智能体将决策记录在共享的设计文档中。”
00:13:08“依赖某项决策的代码会附带一个指向其对应文档的编译检查引用。”
00:13:13“当规划者在不知情的情况下产生冲突时，调和者（reconciler）会合并文档，并将决议顺流传递到下游引用。”
00:13:21接上一点，即便在规划者之间分配了工作，但在软件开发中，完全避免重叠、共享领域、公共逻辑或是需要规划者及执行者共同触及的共享区域，依然是不可能的。
00:13:43因此，当规划者智能体开始为某项具体实现产生拉扯时，他们通过引入一个“调和者”智能体（我推测是智能体）来合并这些规划者编写的设计文档。
00:13:59也就是合并那些准备下发给执行者的文档。
00:14:02他们在中间加入了这个调和步骤，用来合并相互冲突的规划者智能体文档，使它们统一口径并对实现方案达成一致，这有助于防止在代码库的不同地方以不同方式重复实现同一功能。
00:14:21据我理解，这两者是配合工作的。
00:14:24当然，他们不可避免地也遇到了代码合并冲突（merge conflicts）。
00:14:29做好规划并确保没有重叠（或尽量减少重叠）、让规划者达成共识，是至关重要的第一步。
00:14:38但即便如此，当多个执行者（甚至是针对同一个计划工作的多个执行者）并行时，极有可能会修改相同的文件，从而产生冲突。
00:14:50因为还有很多其他执行者并不可能时时刻刻保证自己不接触重复文件。
00:14:55所以他们难免会修改相同的文件。
00:14:57难免会触及同一个文件。
00:14:58“为了解决碰撞，它们必须停下来，理解另一个智能体的上下文，并围绕它进行合并。”
00:15:03很自然，如果两个智能体（或两个人）在同一个文件上工作，为了解决冲突，双方都必须停下来——无论智能体还是人类——通常都必须暂停，才能找到决议，
00:15:19找到能解决冲突的具体实现。
00:15:23“然而，执行者智能体并不擅长这一点，实际操作中要么直接覆盖别人的修改，要么直接放弃自己的修改。”
00:15:29也许你也注意到了这一点。
00:15:31我绝对深有同感。
00:15:32如果你在一个代码库里和一个或多个 AI 智能体一起工作，而你手动做了一项修改。
00:15:38好吧，我知道这听起来很神奇，但人类确实还在写代码。
00:15:40假设你做了一项修改。
00:15:42你在代码里改了些东西。
00:15:44智能体往往只会直接撤销并覆盖你的修改。
00:15:48它根本不尊重你的那些修改。
00:15:50它有自己的既定任务路线。
00:15:52如果它决定要修改某个特定文件，它就会直接动手。
00:15:57它根本不管你在此期间是否对它做过修改。
00:16:01如果你把修改提交（commit）了，情况会稍好一些，因为这些智能体经过后训练和微调，不会轻易撤销你的提交等等。
00:16:13但如果是未提交的修改，执行者根本不在乎。
00:16:17智能体完全无所谓。
00:16:19而这恰恰也是他们在此处遇到的情况。
00:16:21“为了解决这个问题，我们创建了一个系统，由中立的第三方智能体介入合并冲突，代表所有参与方来解决冲突。”
00:16:29“它的唯一目标就是保持公正和高效，类似于工程团队中合并队列（merge queue）的工作方式。”
00:16:35我觉得这一点也非常耐人寻味。
00:16:38这同样是一种调和形式。
00:16:41据我理解，这依然是关于让那些智能体停下来，就像在旧世界里你不得不停下脚步、后退一步去寻找
00:16:49解决冲突的方案一样。
00:16:51但这清晰地表明（虽然这也不是什么全新的认知），在给予正确上下文的前提下，保持崭新、干净的上下文（fresh context）是极其极其关键的。
00:17:03所以，不论你是像 Cursor 那样去挑战超大规模的任务（我们一般不会做），还是仅仅在一个较小规模的项目里开发，
00:17:12将智能体划分为规划者、执行者和审查者的巨大优势，核心往往在于（至少绝大多数情况下）你可以基于全新的上下文窗口去工作。
00:17:24这并不意味着上下文窗口是空无一物的，
00:17:26而是意味着你拥有全新的智能体会话，里面仅填充了针对当前特定任务最精准的上下文。
00:17:33例如，执行者智能体非常不擅长审查自己的工作，因为它的上下文窗口里充斥着实现该代码时的全部上下文。
00:17:41因此它会带有偏见（如果你想这么形容的话）。
00:17:44这就是为什么审查者智能体应该在一个全新的上下文窗口中启动，只需要获取执行者做了什么、计划是什么、修改了哪些文件的信息，而不需要其他杂质。
00:17:55这样它才能客观公正地审查该项工作。
00:17:59这就是为什么填充了恰当上下文的全新上下文窗口会如此重要。
00:18:04而在当前这个场景下也是完全相同的道理：他们通过一个拥有刚好合适上下文、毫无先入为主偏见的全新智能体来解决合并冲突。
00:18:17然后我推测系统会进行设置，让那些执行者智能体接收到“这就是冲突解决方案且不得覆盖”的指令，或者干脆直接启动全新的执行者智能体。
00:18:30文中在这里并没有完全说明白。
00:18:32他们遇到的另一个问题是“巨型文件（mega files）”。
00:18:35“有些文件是智能体特别喜欢在其中编写代码的热门区域。”
00:18:39“每个智能体可能只添加少量代码，没有任何一个单独的智能体有责任保持文件精简。”
00:18:45“这些巨型文件会让整个系统拥堵不堪。”
00:18:49“它们的传输、Diff 比对和合并成本极高，并且会频繁成为冲突爆发的场所。”
00:18:54同样地，即便是在小得多的规模下，你可能也遇到过这种状况。
00:19:00我肯定遇到过。
00:19:01这也是我们经历过的事情之一。
00:19:02特别是为了测试。
00:19:03我的经验是，代理喜欢在同一个文件中添加越来越多的测试。
00:19:08当然，这不仅仅发生在测试中，但这是我经常能看到的一个领域。
00:19:13特别是有多个代理在工作，并且每个代理都有自己的议程时。
00:19:18它们不在乎，因为它们不是人类。
00:19:21它们怎么可能在乎任何事情？
00:19:23它们只是在执行任务，对吧？
00:19:24它们不在乎文件的大小或系统的整体架构。
00:19:30如果你只是让一堆代理执行它们的任务，你的代码库在某个时刻就会陷入混乱。
00:19:37因为代理根本不在乎。
00:19:39它们只在乎执行自己的任务。
00:19:42而这些巨型文件，当然，就是这个问题的一个明显指标。
00:19:48随着越多的代理在你的项目中工作更长的时间，它们就越容易成为一个问题。
00:19:55那里没有负责拆分该文件或保持代码库架构良好的代理。
00:20:02那根本不是它们的议程。
00:20:04因此，为了解决这个问题，我们为工作代理提供了一种标记臃肿文件的方法。
00:20:09一旦被标记，我们就会阻止新的提交，并由一个外部代理将过度生长的文件分解为较小的模块。
00:20:16所以，同样，这是一个新加入的代理。
00:20:19这是我们在这里看到的一个模式。
00:20:21对于所有这些问题，关键在于识别问题，然后使用被赋予正确任务的新代理，
00:20:28并在给定正确上下文的情况下，来解决该问题，以便其他代理能够继续它们的工作。
00:20:35对于巨型文件也是如此。
00:20:38僵化，是他们面临的另一个问题。
00:20:40代理从在有人类参与的现有代码库中工作学到，
00:20:44即使核心代码需要更改，也不要触碰它。
00:20:48所以，这不是我之前表达的意思。
00:20:50当你在代理正在处理的文件中进行更改时，它就直接把它丢弃了。
00:20:55相反，它是关于一般情况的。
00:20:57代理基于计划、基于你给出的提示，有一个明确的任务。
00:21:03当然，这确实涉及到更改某些文件。
00:21:07现在，我们在使用代理时已经知道或每天都能看到的一件事是，根据模型的不同，
00:21:16有些模型非常不愿放弃现有代码。
00:21:21它们宁愿添加10个后备方案、10个if检查以及越来越多的遗留代码到代码库中，而不是删除和清理它。
00:21:31你必须明确地进行提示，以确保代理真正删除某个函数或去掉某个代码文件。
00:21:39由于微调的原因，它们自己并不会真正这么做，因为很明显，这些模型提供商不想构建
00:21:47那种可以自由游走并破坏各种生产代码的模型。
00:21:50但是，如果不是在棕地项目（现有项目）中工作，不是在一个可能正在生产环境中运行的现有代码库中工作时，
00:21:57那么这种不愿真正触碰代码、并永远保留所有代码的倾向可能会非常成问题且令人烦恼。
00:22:05它还可能导致其他副作用，就像他们在这里遇到的那样：代理根本不会去改进其他代理编写的代码，
00:22:16而只是一次又一次地在其基础上进行构建，这当然最终会导致代码库变得臃肿。
00:22:23为了解决这个问题，我们授权进行有意的破坏。
00:22:27判断核心更改有价值的代理可以在其范围之外制作一个重点补丁，并留下注释解释这样做的原因。
00:22:36同样，在更小的规模上，这也是你在你的项目中可以做的，就像我正在做的一样。
00:22:41你想明确地授权并告诉你的代理，嘿，我们正在构建这个。
00:22:46我们正处于早期开发阶段。
00:22:48这还没有上线。
00:22:49我想要破坏性的更改。
00:22:51所以大胆地清理代码吧。
00:22:54欢迎进行重构。
00:22:56诸如此类的话。
00:22:58你要鼓励代理和这些AI模型，并覆盖它们的微调指令。
00:23:04可以说也就是摆脱它们的内置知识限制，以确保它们确实能够演进代码库，而不仅仅是向其中添加越来越多的代码。
00:23:14所以同样，我们在这里能以较小的规模看到的东西，当然在更大的规模上也能看到。
00:23:19现在关于代码审查，他们使用了一种叫做审查视角的方法。
00:23:24所以我们有规划者和工作者代理，但当然这项工作必须经过审查，然后创建后续工作并重新启动循环，直到修复某个bug，直到代码库处于更好的状态。
00:23:38在一个长期运行且多代理的系统中，错误会不断累积，群体需要一种方法来自我纠正，以免小错误变成基础性错误。
00:23:47再说一次，这很有道理。
00:23:48我们也都在较小的规模上看到过这种情况。
00:23:50我们尝试了许多种审查视角，例如给审查代理提供工作者的完整记录，或仅提供其输出，或者只提供代码库。
00:24:00我们还尝试了运行在不同模型上、具有不同训练和不同性格的审查者。
00:24:05没有单一的视角能捕捉到所有问题，但相关联的视角会像自动驾驶系统那样叠加起来，即使没有任何单一完美的组件，也能达到超越人类的可靠性。
00:24:16花在审查上的算力是高回报的，因为审查比它所审计的工作要便宜得多。
00:24:21我们怀疑这种堆叠审查系统是这些运行能保持持续高质量的一个主要原因。
00:24:28所以这里的关键要点是。
00:24:30不可能让一个或多个审查代理各自审查整个代码库。
00:24:39那太多了。
00:24:41相反，他们尝试了不同的方法，比如给它完整的记录，或者仅给输出，或者只给代码库。
00:24:47他们最终发现，对他们有帮助的是拥有不同角色的不同审查者，带有不同的焦点视角，他们会关注不同的方面。
00:25:00我的理解是，把代码库交给它们，也许再提供一些关于工作者做了什么的信息。
00:25:06然后是这种组合，从本质上讲，是多个审查者输出的组合，导致了一个整体的审查结果，然后规划者可以再次接收它并将其转化为计划，并让工作者修复代码。
00:25:23再说一次，在更小的范围内，我认为这是你或我们可以应用的东西。
00:25:28现在，很明显，我们再次声明，我们并没有在构建那样的东西。
00:25:34但在我的经验中，非常有效的方法是让多个审查代理承担不同的任务，其中一个可能关注：嘿，这是符合惯用法的Rust代码吗？
00:25:46如果条件允许，另一个可能关注性能和安全问题。
00:25:51另一个审查者可能会关注命名模式，如果这是你想要关注的点的话，等等。
00:25:58所以你有不同的视角，然后你给这些审查者提供恰到好处的上下文。
00:26:03同样，比如：嘿，我们让工作者处理了那个功能。
00:26:07也许给它们提供工作者的计划，以及关于工作者所做的大致步骤的一些信息，但仅此而已。
00:26:15然后你就有了来自不同审查者的所有这些输出，你可以再次将它们组合起来，也许是与另一个审查者一起。
00:26:22我还喜欢的一点是让一个审查者审查审查结果，这仅仅是因为，同样取决于模型，它们往往喜欢找出些问题来。
00:26:36不管你给它们什么代码，哪怕只是一行代码。
00:26:40我有时觉得它们都能在里面挑出五个问题来。
00:26:43所以在我的经验中，让一个审查者对这些审查发现进行分类，并剔除那些并非真正问题的内容，效果会非常好。
00:26:55正如他们所写的那样，又是这种审查者的组合，这种审查者堆栈可以帮助产生良好的结果，然后可以再次被接收和实现。
00:27:06不过再说一遍，这总是取决于你的任务规模以及你正在构建的软件。
00:27:11显然，对于许多许多软件来说，这一切都太复杂了，但这也是对未来软件工程和此类系统可能是什么样子的一个很好的窥见，我个人觉得这非常非常有趣。
00:27:27现在，他们还做的最后一件事是让代理塑造环境。
00:27:32这里的想法是，他们让代理编写一本现场指南，最终是一份文件或一组文件，在这里他们除了让这本现场指南作为整个任务的上下文之外，没有给代理任何其他指示，因此代理可以在这里建立记忆，你可以说是共享记忆，全都是关于学到的东西或可能发现的关键问题等等。
00:28:00这样它们就有了一个额外的记忆系统（如果你想这么叫的话），供代理保留笔记并记录决策。
00:28:10总的来说，我发现，就像用Rust重写BUN一样，我觉得这个实验非常非常有趣。
00:28:16它也可能令人恐惧。
00:28:17我完全明白这一点。
00:28:18而且我认为我们不应该推断出从现在开始所有软件都应该这样构建。
00:28:24我的意思是，首先，这甚至不是一个生产就绪的软件。
00:28:28而要让它达到生产就绪状态肯定需要相当长的时间。
00:28:33这是不可低估的。
00:28:35并不是说你能在几个小时内构建出这样的东西，然后再花几个小时就能让它达到生产就绪状态。
00:28:43前80%的完成速度可能比后20%要快得多。
00:28:48我们都知道这一点。
00:28:49所以这是一个重要的收获。
00:28:51当然，同样重要的是要认识到，重写SQLite这个特定的任务，是的，它可能只是接收了那些文档，然后使用了这里的这个测试套件。
00:29:04但很明显，首先，这里有一个极其详细的规范，这是你在新项目中无法拥有的。
00:29:13如果你正在构建一个新软件，你不可能有像拥有20多年历史的软件文档那样详细的规范。
00:29:24当然，即使只有文档被提供给那些代理，SQLite源代码，或许还有其他源代码（比如像Terso在这里用Rust做的其他重新实现），可能并且很有可能是被使用的大多数或所有这些模型训练数据的一部分。
00:29:46所以对于这些模型来说，这并不像是个全新的东西。
00:29:51这和构建一个全新的软件不一样，在构建新软件时，迭代也是很重要的一部分。
00:29:58你会非常艰难，我甚至会说，无论是什么软件，想要从头开始构建一个新软件而不在过程中不断修改，是不可能的。
00:30:11因为你无法预先写出一个完美的规范，然后就大功告成了。
00:30:17无论在多大的规模上，你在构建东西的时候，总是会发现新的东西或想要改变的事情。
00:30:26因此，当然，这并不代表通常情况下软件将如何被构建，或应该如何被构建。
00:30:34不过，这确实是一个非常有趣的实验。
00:30:37这是一个非常有趣的实验，它包含对我们所有人都有重要意义的关键经验。
00:30:43这些关键经验当然不是全新的，比如拆分你的工作，以及拥有带有恰到好处的上下文的新鲜上下文窗口。
00:30:50比如未来可能会出现并需要新的版本控制系统这样有趣的见解。
00:30:57当然，还有多代理编排正在成为现实。
00:31:01现在，当然，这一切也证明了人类在设计这些系统、这些代理系统，当然还有为新软件的人类，特别是决定该软件应该如何架构方面的重要性。
00:31:21编写规范文件（即使它们不像这样详细），提出软件架构，然后构建能够实现它们的代理系统，然后对其进行审查，这才是重要的。
00:31:33这就是我们都在努力的方向，尽管一切都在改变，并且绝对不同于我们六年前构建软件的方式，但这确实让我感到兴奋。
00:31:45我认为，我们正在进入那种系统性思维领域，无论是在构建代理系统方面，还是在设计软件架构本身方面，这都非常有趣。
00:31:59然后我们让两者协同工作。
00:32:01我发现像这样的实验非常非常有趣。
00:32:04这里的经验也非常非常有趣。
00:32:07其中一些在更小、更简化规模上的经验，可能也对日常的软件和开发项目具有重要意义。
00:32:17但像往常一样，请告诉我你的想法，以及你对这种实验的看法。