[音乐]
大家好，感谢参加本次课程。我们将进行一场关于智能体工具包（Agent Harnesses）的分享，时间只有一小时。希望我们能充分讨论大家感兴趣的话题。课程大致安排是我用10到15分钟介绍我们将要在工作坊中探讨和解决的问题主题。
工作坊的操作指南可以通过二维码或网站获取。如果您不想听我讲解，或者觉得无聊，可以在我听课时自行开始工作坊练习。本质上，这就是网站上的操作流程：您只需使用GitHub账号注册，系统会自动向您发送仓库的邀请。
工作坊托管在Code Spaces上。您可以直接基于该仓库创建一个Code Space，系统会自动邀请您访问工作坊本身。只需在GitHub Code Spaces中创建环境即可开始工作。为了方便大家，我再展示一次二维码，随后我将正式开始讲解。
如果有任何问题，我的同事Richmond也在现场，他会巡视各个小组提供帮助。如有需要请举手示意他。此外，您可以访问网站 workshopwaitingroom.com 获取更多信息——我花了不少钱买下的这个域名，尽管用起来有点尴尬。
我是Nacho Martinez，一名AI开发者倡导者，也是一名数据科学家出身的人。如果您对关于我的更多信息感兴趣，可以在YouTube上找到我，那里有播客、工作坊等内容。不过我不打算过多介绍自己。
最近我与Andrew Ng及DeepLearning.AI合作发布了一门关于构建自适应AI智能体的课程，这是今天我们要讨论的子组件之一。如果您对如何通过调整模型使其随时间适应和学习感兴趣，可以查看这门免费的一小时课程。
今天我们将讨论哪些内容？由于时间有限，我会尽量简练。首先介绍智能体栈（Agent Stack）及其组成部分；AI应用的不同形态是什么？什么是AI智能体，以及什么是智能体工具包。
我们主要探讨构建或使用智能体工具包的动机，而非直接使用AI智能体或大型语言模型（LLM）。我们将深入分析智能体工具包的各个子组件，例如记忆、上下文工程以及内存工程等。
由于听说有很多来自华尔街金融行业的参与者，我将本次工作坊的背景设定为一家银行场景。当前的普遍观点是：OpenAI等公司推出了成千上万个智能体来解决数学难题，这些智能体完全自主运行。
然而，直到得出最终结论或答案前，人类并不介入循环中。智能体本身不具备这种能力，因为上下文窗口有限，且大型语言模型并不天然具备记忆组件。我们需要自行实现这些功能，使智能体能够自主运行数小时甚至上百小时来解决复杂问题。
因此，许多人的焦点集中在前沿模型上，而我的观点是：我们不必过度依赖前沿模型。虽然可以使用它们，但重点应放在“工具包”上——这才是真正有趣且可高度定制化的部分。
在这个应用场景中，假设有一家中型银行经常遇到可疑交易，并将其分为五类进行标记。例如：如果您存入一百万美元，随后三天内自动通过ATM机提取五万美元的现金。这显然可疑，因为没有人会这样处理资金。
我们的目标是让这家中型银行能够自主决定或至少标记这些交易，从而减少银行工作人员审查此类事务的时间。接下来进入理论部分：什么是智能体栈？
当我们与AI智能体交互时，通常是在与应用层互动。我们可能通过界面、聊天机器人或移动应用等渠道进行交互。接着是模型本身，它是推理核心，我们通常无法干预其决策过程。
此外还有支持这一切的基础设施及计算资源。但今天我们将重点关注数据部分，因为这是我们可以操纵和工作的主要领域。与其他部分相比，尤其是使用第三方非自有模型时，我们对数据层拥有更多的控制权。
首先介绍智能体循环（Agent Loop），这可以说是AI智能体最重要的部分之一。智能体循环负责驱动整个系统，并且它是可定制的。在数据层内部，还包括网关和MCP（模型上下文协议），以便连接第三方外部数据来源。
此外还有记忆层，我们稍后会详细讨论；以及上下文工程部分，它允许自动摘要、压缩和缩小模型的Working Context Window（工作上下文窗口）。最后还有工具和技能模块，通过智能方式限制上下文窗口的增长。这是本次工作坊的核心思想之一。
通常我们交互的应用程序是上述四个部分的组合，例如LLM聊天机器人是最简单的形式。很多人创建AI应用时只是简单地创建一个……
Nacho Martinez 介绍基于 Agent Harnesses 的反洗钱工作坊，强调通过数据层定制而非仅依赖前沿模型来解决长周期自主代理问题
为了让你能够与它对话，我们需要构建聊天机器人。此外还有检索增强生成（RAG）应用，这本质上是一种高级的向量搜索功能。接着是大型语言模型驱动的工作流和人工智能代理（AI Agents）。通常情况下，我们大多数人都在使用这些技术。顺便提一下，请举手示意哪些人没有在使用 AI 代理？比如 Cloud Code 等工具。当然，Cloud Code、CodeEx、Spy、Open Claw、Hermes Agent 等系统都是第三类和第四类的结合体，也就是说它们是大型语言模型驱动的工作流与人工智能代理的组合。
那些提供自动化的工作流，加上那些提供自主性的 AI 代理，这两者的结合被称为“智能体系统”（Agentic Systems）。像 Cloud Code、CodeEx、Spy、Open Claw 和 Hermes Agent 等更优秀的系统，都是这两种类型的结合体。我接触过的许多工程师都意识到这一点，这很重要：我们每天都在使用这些系统。然而，当我们构建自己的 AI 应用时，很多人——虽然并非所有人——却很少去思考这些问题。你可能拥有某个 AI 应用，但你并没有以这种方式去消费它。
这正是我们今天关注的重点，因为我认为通过自动化和自主性的结合来消费 AI 应用，不仅仅是通过聊天机器人或 RAG 应用，这是一种更好的方式。对于那些不了解的人来说，什么是 AI 代理？它是一种由大型语言模型驱动的计算实体。它的推理能力类似于人类的大脑；它通过数据库进行记忆增强，这也像我们的人类大脑一样。它还通过工具来扩展行动能力，这就好比人类拥有四肢并与世界互动。
就像 AI 代理可以通过我们赋予它的工具与操作系统交互一样，它也是基于输入而存在的。例如，这就像人类的感官（如眼睛）让我们感知信息一样。而且上下文类似于我们的注意力也是有限的，正如 AI 代理无法同时观看七部电影而不理解任何一部一样。人类的上下文窗口与 AI 代理类似，我们试图同化这些概念，使其更接近人类体验。这也是我们今天将要探讨的内容之一。
其推理部分由前沿实验室提供，我们对此控制有限。而我们拥有更多控制权的部分是记忆、工具使用和感知能力，这正是“Harness”（ harness 本身）的内容。Harness 本质上是你构建这三个组件——工具使用、记忆和感知——所需的所有脚手架结构。我们不会过多关注模型本身，因为正如我所说，我们在做什么方面选择不多。因此，Harness 实际上是当今 AI 领域最有趣的话题之一，因为它控制了 AI 代理所能做的所有事情。
你给不同的配置，即使是相同的同一款前沿 AI 模型（LLM），其表现也会变得更好或更差。事实证明，仅仅改变 Harness，同一模型在特定任务上的表现就会有所差异。因此重点关注 Harness 非常重要，但很少有人这样做。在一个 Harness 中，有七八个不同的组件（如果算上持续学习的话），你需要做出许多决策。
你有模型，有存储——数据放在哪里？你有一些编码和检索组件——如何确保两个向量之间的距离能正确检索到数据？你在记忆中存储什么？是像人类一样分为短期记忆和长期记忆，还是将其划分为不同的部分或不同类型的记忆？还有语义层，这部分非常有趣。
作为人类，我们处于某种语境中，有些背景信息从未说出口，但我们共享着这些认知。例如我是演讲者，你是听众，你现在没有在唱歌，因为在这种语境下唱歌不合适。模型本身也可以访问语义层，它涉及那些未明确告知但被假设为已知的所有事情。还有代理循环（Agent Loop），这是驱动代理自动且自主地反复工作的所有机制，这也是最重要的部分之一。
此外还有上下文工程（Context Engineering），我们将逐一关注它们，但不会深入挖掘细节，因为我们会在工作坊中进行实操。作为参考，之前曾有过关于文件与数据库的大讨论：许多人认为我们需要用文件存储一切，把所有东西都放进文件里，然后一个月后代理就会变得更好。另一些人则是数据库至上主义者，他们想把所有东西都存入数据库。
这种困境至今仍在继续。我想举个例子：屏幕上显示的这个例子，谁能告诉我代理目前使用什么变通方法来解决这个特定问题？即多个代理向同一个文件写入数据。在当前的 AI 代理中，这是如何运作的？有人知道吗？>> 工作树（Work Trees）。没错。很好。所以，工作树是当前的解决方案。
这是一个变通方案，因为文件本身存在固有的问题：如果有多个写入操作进入同一个文件，就会出现一致性问题——比如哪个写入先发生？如果有人在我修改之前读取了该文件该怎么办？等等，会有很多问题。对于某些事情我要明确告诉你：文件非常棒。在存储大量非结构化数据方面，文件是极好的选择。
另一方面，数据库也用于其他类型的使用场景。我的解决方案是：在某些情况下，基于文件的方案可行；在其他情况下，基于数据库的方案更合适。因此我们需要重新考虑正在发生的一些事情。工作树解决方案或变通方法实际上在 30 年前就被数据库解决了。我们试图用这种方式重新发明轮子，但实际上不需要这样做，因为已经有现成的解决方案了。
例如，如果你试图同时让多个代理写入文件，如果具备事务一致性或 ACID 一致性（即原子性、一致性、隔离性和持久性），你就不会遇到这个问题。文件适合某些用途，而数据库则适合其他用途。我们不必只依赖其中一种方式。因此，在代理框架中，请将其作为一种思考角度。
另一个组件是所有的记忆部分，这包括围绕 AI 代理创建的所有机制和系统，使其能够使用信息。不仅如此，它还能够在适当的时候精炼并恰当地回忆这些信息。作为工程师，你可以选择代理记忆层中要考虑的内容。有些人区分短期和长期记忆。
在本系列的第二部分中，我们有一些短期记忆组件。例如，当我们与 Clot 或 CodeEx 对话时，从上下文窗口本身的角度来看，它具有短期记忆的特性。任何在对话结束后消失的东西都是如此。大多数上下文窗口中的内容都会消失，当你启动新的对话时，一切从零开始。这就是短期记忆，它非常有限，我们无法将所有内容都放入其中。
此外，我们还有长期记忆。在长期记忆中，我们也提出了一些类别。例如，“情景记忆”包括发生的所有事情、我们对话中的所有片段、所有工具日志、之前的对话，以及你与代理进行的先前对话的摘要等。所有这些都属于情景长期记忆类别。
你还拥有“程序性记忆”，其中包括技能、工作流等所有事物，这些是由一系列正在运行的技能组成的序列。所有这些都属于程序性记忆。此外，我们还有“语义记忆”，即代理记得你是谁、你的偏好是什么、你最喜欢的框架等。所有这些都属于语义记忆。
这里的主要问题在于，为什么我们不能将所有内容都放入短期记忆中？因为它是有限的，而且不仅有限，注意力矩阵（本质上就是上下文窗口）越大，性能就越差。这对每个模型都是如此。许多研究表明，如果从上下文窗口的零令牌开始解决问题，其准确性远高于已经拥有 256,000 个令牌且上限为百万的情况。
目前我们处于百万级别，这是因为 KV 缓存的原因。所有这些都需要考虑在内，并且要知道，即使宣传的上限是 256k 或 100 万，如果你继续增加，性能会急剧下降。因此，上下文窗口越小，解决问题的效果越好。这适用于你能想到的所有类型的问题。
有两种方法可以解决这一问题。一种是上下文摘要，即你要求代理生成一个简短的摘要，总结上下文窗口中提到的所有内容。然后你获得这个摘要，并从该摘要开始下一次对话，这是可行的。
另一种方法是压缩（compaction），这与上述方法类似，但在压缩中，你将对话的片段放入数据库或文件中，并为其分配一个 ID。如果 AI 代理稍后需要这些信息，它可以通过该 ID 获取。这就像从文件中读取一样，使用偏移量通过 ID 拉取数据。这些是上下文工程中发生的一些问题。
接下来我们有代理循环，它是驱动我们讨论过的所有组件的动力源或“汽车”。有一个上下文组装部分，它从技能、工具、之前的对话、文件和数据库中拉取信息。所有这些都会动态地引入上下文窗口中。
然后它进行一些推理，向 OpenAI 或你正在使用的任何模型发出 API 调用，并决定需要做什么。如果你愿意，这个过程会自动且无限地进行下去。在我为这次工作坊准备的代理循环中，我设置了最大耐心值，因为我不想耗尽 OpenAI 的积分或其他余额。
在我们的案例中，迭代的最大次数为八次，每次迭代的推理时间最多为 60 秒。但这完全是可配置的。正如我所说，作为工程师，我们必须决定代理循环中包含什么内容。此外还有工具箱模式（toolbox pattern）和技能箱模式（skillbox pattern），这是我们提议用于存储数百个工具和技能的方法。
我不知道你们的情况，但我已经安装了大约一百种技能。我不会在同一时间将 100 种技能放入上下文窗口，因为每种技能大约占用 3,000 到 5,000 个令牌。这会迅速超过宣传的上限，导致我没有空间用于与代理的实际对话。
那么如何解决这个问题呢？有多种方法，但我们建议对工具和技能进行向量化处理，创建向量嵌入。一旦代理循环想要检索有用的技能或工具，你就针对你拥有的这个向量存储库进行向量相似度搜索。
你将拉取最相关的技能或工具来解决问题，解决后将它们卸载掉。这是一种保持上下文窗口在此意义上相关性的方法。使用技能和工具是一种非常常见的模式，每个人都在使用工具，比如 Bash 命令或更改目录等特定工具。
我们 constantly（持续）在使用工具和技能，在某些情况下，这占用了上下文窗口使用量的 50% 以上。因此，我要提醒大家注意技能和工具实际占用的巨大上下文窗口大小。
我们还有一个称为“技能蒸馏”（skill distillation）的概念，即利用之前的对话、运行记录以及你与 AI 代理进行的实际对话，从中尝试创造出有意义的东西。你是如何做到这一点的呢？有多种方法，但最简单的一种方法是……
你可以这样做：创建一个技能模块，并将其放入你之前拥有所有内容的同一个“技能箱”中。这是其中一种方式，例如 Hermes 代理在这方面就是创新者之一，它创建了特别擅长解决特定问题的技能。假设你正在从事前端工作，那么你可能想要创建一个非常适合你的技能模块，包含你所有的偏好设置。比如，“我喜欢这种配色风格”等等。下次当你进行前端工作时，由于你已经基于此生成了向量嵌入（vector embeddings），代理会自动选择最相关的技能。所以，如果你只是提到“嘿，我喜欢我之前在那个其他技能中使用的配色风格”，代理会自动知道你在指代那个新技能，因为你使用了“配色风格”这个词。
因此，“技能蒸馏（skill distillation）”是你用来提高模型随时间学习能力的技术之一。这与我之前所说的动态技能发现有关，即在组装或构建上下文时，代理循环会在需要的时候拉取正确的技能和工具。有些人会问：“冻结模型是如何变好的？”我所说的“冻结”是指我们无法控制前沿模型的底层参数，但我们可以完全控制其数据层。有些人说我们要修改模型权重，另一些人则建议创建一个针对特定问题表现更好的嵌入模型，然后只关注检索更优质的嵌入。
虽然方法各异，但核心思想是：这是持续学习的主要组成部分，而持续学习是让模型变得更好的手段之一。这主要分为三类参数：第一种是参数化记忆（parametric memory），通过修改神经网络权重来工作；第二种是表征性记忆（representational memory），使用嵌入等技术；第三种是非参数化记忆，也就是我们今天讨论的所有内容。不过我们主要聚焦于第三类，另外两类涉及低秩适应（LoRA）、微调模型等技术。
如果你对这三类都感兴趣，可以参考我之前提到的课程，或者在会议结束后与我们交流。我们在活动结束后仍会留在现场。最后我想提到的是，在使用任何 OpenAI 模型或类似服务进行聊天补全 API 调用时，都存在一种固有的“指令层级（instruction hierarchy）”。这意味着赋予模型的不同部分具有不同的权重。例如，用户请求是我们与模型交互的方式，这是我们可以传递给模型的第三重要的东西。
最重要的指令是系统提示词（system prompt），大家都熟悉这个概念。虽然系统提示词很好，但它不能包含所有内容，否则内部就失去了层级关系。你需要将部分内容放入系统提示词，部分放入用户提示词，而所有可用的工具和技能也拥有这种层级结构。这很好，因为它让模型能够更专注于某些方面而非其他方面，我们将在工作坊中深入探讨这一点。
作为参考，这是工作坊的用户界面（UI）。如果你已经在 Code Spaces 中运行它，你会看到已经部署好了。我将带你浏览一遍。这基本上是我设想银行反洗钱（AML）或欺诈检测系统工作人员与自主代理交互的方式。该自主代理在后台 24/7 运行，不睡觉，也不需要人类的需求。它通过“Harness”连接到数据库，具备我们提到的所有功能。
此外，即使在我们离线时，它也会为公司自主做出决策。但它不会像说“嘿，这人可疑，直接把整个银行封锁”那样毁掉人们的生活；相反，它会做出这些决策并打印出来供人类后续检查。这将大大节省发现过程等阶段的时间。在工作坊结束时，如果你完成了练习，你将拥有一个连接到数据库的代理，它就像任何公司的系统一样工作。
它将执行自主分析和决策制定，然后由人类接管并与之互动。这就是我们讨论过的所有组件：Harness 以及更多细节。接下来，我将再次展示二维码或网址 workshopwaitingroom.com。如果你想查看我们其他的任何工作坊，可以访问这个 GitHub 仓库。我们在其中投入了大量精力和进展，包括工作坊、会议笔记等。你可以从代理 Harnesses 等不同主题开始入手。
请查看一下，然后让我打开 Firefox 向你展示这个应用程序是如何工作的。首先，对于那些没有收到邀请的人，如果你访问 workshopwaitingroom.com，你将通过 GitHub API 获得一个针对你用户身份的仓库邀请。如果你点击这里并在 Code Spaces 中打开，它会要求你创建一个代码空间。当然由我来支付费用，所以不用担心。
但在使用硬件部署时要小心，因为成本很高。不过，你将获得一个这样的部署环境，包含几个笔记本文件。我将向你展示工作坊本身的内容。我的计划是几分钟后退下，然后我们将一起解决大家的问题等事宜。但它是自动化的……
自动部署此应用程序，实质上是在追踪所有事务，当然这里使用的是模拟数据。请放心，我并未暴露任何真实信息，这些数据主要用于生成新交易。其中一些交易正常，另一些则存在潜在问题。因此，运行在 OCI 上的 Groq 模型自主代理会做出独立决策。它可能会指出某笔交易可疑，并将其加入名单；随后，您可以在此可视化代理的上下文窗口。您还可以查看数据库中已有的所有数据（如客户信息），以及代理如何实时分析这些信息。
它将执行我们工具箱中提供的工具调用，搜索通过向量存储创建的知识空间中的知识，并大量使用工具。最终，它将自动生成可疑活动报告（SAR）。此处展示的是银行最近发生的 30 个事件的可视化视图。工作坊的核心是笔记本文件，请大家先检查其中的不同组件，因为我们在其中实现了它们。接下来我将引导大家完成第一个待办事项，以确认操作正确。
首先展示工作坊的第一部分：运行在 Oracle 云上的 Rock Model 4.3，并连接数据库。请稍等，让我重启内核并运行该单元格。如果在进入代码空间时遇到任何问题或疑问，请随时告知，我将协助大家并解答问题。目前有人提问吗？好的。关于仓库地址……
是的，您可以在 workshopwingroom.com 找到它。我将展示二维码以便扫描，这将通过 GitHub API 自动授予访问权限。让我重新向 YouTube 观众解释一下刚才的问题：关于情景记忆及其他记忆组件，它们是否会与之前的代理对话产生混淆？这取决于您赋予其的权重。
这就是我之前提到的指令层级结构的原因。如果某些信息非常重要，您需要从特定来源提取，您可以自行决定记忆层的架构。例如，在情景记忆至关重要的情况下，您可能希望将其向量化而非仅保存为纯文本，这很大程度上取决于用例。在此案例中不存在冲突，因为架构中的记忆组件有清晰分离。
技能可以添加到系统提示中。在指令层级结构中，它们通常权重最低（共四个层级）。您可以将其视为即插即用模块。我和 Richmond 正在实验一种方法，允许代理接入外部、内部或第三方的技能中心及工具中心。例如，您可以预计算一组 MCP 的嵌入向量，然后通过矢量搜索获取这些第三方技能或工具。
当然，这些信息包含在您向 OpenAI 或其他模型发送的每个聊天补全 API 请求中。它们附加在底部，通常占整个请求量的约 80%（包括工具和技能）。那么，为什么费用不会比现在高出五倍呢？因为 OpenAI 等系统拥有语义缓存。如果请求的 80% 与上次相同，它不会重新计算，而是直接调用缓存。
这使得我们能够以经济的方式使用前沿实验室模型（尽管仍然昂贵）。我想强调的是，如果没有这个语义缓存来存储工具和技能，成本将高出四到五倍。因为在与前沿 AI 模型交互时，您实际上是通过 HTTP 请求完成所有操作。例如，系统提示可能长达数千甚至数万 token（如“你是 AI 助手……”），加上开发者指令、用户查询以及占请求量 80% 的工具输出和检索文档。
关于如何管理预算的问题：由于技能箱和工具箱模式中包含大量内容，我们如何实现这一目标？我们将上下文窗口视为一个从 0 开始但从未真正为空的 N 维矩阵，其大小接近一万 token。我读过一篇比较不同 Harness 效率的论文，关注它们在首次系统提示和初始补全 API 请求中投入的内容量。
Pi Harness 是最极简且最高效的，因为它在每个请求开始时仅包含约 6,000 token。而其他 Harness 可能高达 3-4 万 token。我们如何保持上下文窗口的清晰分离？
这一切都围绕着智能体循环展开，对吧？所以让我进入智能体循环向您展示一点东西。智能体循环将控制它连接的所有内容，对吧？嗯，所以这里以智能体循环为例。[轻笑] 哦，我在底部了。等一下。作为参考，智能体循环……
所以这里，上下文组装部分，当您使用它时，您本质上会构建内容，您可以在笔记本中浏览这一过程。解释一下这个笔记本……但上下文组装是其中的一部分。首先，我们定义了最大数量的工具或技能以供检索，我认为默认数量是三。所以每次有新请求进来时，它会确定……
这由模型本身完成，它决定要做什么的事情是什么？然后它将尝试组装执行所需内容的上下文。对吧？其中一项内容是检索三个最相关的工具、三个最相关的技能。我们没有使用重排序器（reranker）。但您也可以做的是，在相似度搜索结束时……
您可以放置一个嵌入模型加上重排序器，它将处理这三个结果并告诉您这三者中哪一个最重要。您可以实际上从中获得更好的细化效果，因为您可能不想为每个任务加载总共三个技能。该任务可能仅由一个即可解决。对吧？所以想法是您可以放置……
无论您想要的策略，只需坚持它并与之一致直到最后。所以在这种情况下特定工作坊的想法是，我们总共执行针对一个向量存储的向量搜索，该存储持有工具；另一个向量存储持有技能 k=3。然后从这三个中您可以使用重排序器检索最相关的一个，接着它将……
分发工具当然并构建上下文窗口。但这完全是智能体循环的决定和工作任务。好的，那么与记忆层交互的最重要或有趣的方式是什么？>> 我的意思是效率仅仅来自于您创建实体的数量。所以我的第一个建议就是保持简单，不要……
创建太多的抽象或记忆层的太多组件。例如，首先尝试仅使用短期记忆和长期记忆，并只拥有两个结构。如果您认为或者您有一个智能体考虑到在短期记忆中或上下文窗口中的某些内容值得保留，您可以将其提升为长期记忆……
您只需将原始文本放在某处。这是您可以做的最简单的事情，对吧？一旦它在长期记忆组件或对象中的文本中某处，然后您可以获取它、将其向量化……
然后通过某种方式让智能体循环探索。例如，这里您将在观察和推理之间拥有像中间的一个额外东西……
让智能体回忆记忆或类似的东西。您可以称之为“召回长期记忆”。这将使其在再次解决问题之前进行内省。嗯，所以它将去您的向量存储或您拥有的任何长期记忆……
您在之前的对话中记录的片段，从那里您可以让它看到“好的”，我将让它从中拉取如果它认为……
有趣或者向量相似性如查询向量和我在长期记忆中的内容之间的距离足够相关且距离足够小，那么我会将其考虑进上下文窗口。如果太大或不够相关……
然后我就丢弃它。所以这将是观察和推理部分之间不同的、额外的抽象层。这里我们没有做 MCP，但使用 MCP 的好处之一是解决……
我会说在这种情况下 MCP 并不是那么相关。但这取决于数据库中有什么内容。例如，如果您有一个数据库……
您正在与一个数据库交互就像我们在这里做的那样。拥有一个 MCP 是有趣的，但我喜欢说给人们的其中一个主要问题是……
MCP 到底解决了什么？尤其是数据库中。因为我是数据库专家，因为我工作在 Oracle。嗯……
所以您可以解决的一件事是让 AI 智能体进行 SQL 查询，但不是通过幻觉或试图每次提出一个新的 SQL 查询。这是 AI 智能体在 SQL 方面面临的较大问题之一。SQL 有大约15倍……
像15种引擎，比如 posgres（PostgreSQL），您有 Oracle 数据库，您有 VSQL……
您有很多不同的查询在 SQL 上工作，但它们有特定的提示或细微差别使得它们不能很好地工作。对吧？所以在这种情况下 MCP 解决的主要问题将是“好的”，我将预先创建一些 SQL 查询……
然后让智能体访问那些。所以这些查询已被证明是有效的，而不是拥有……
一个智能体每次试图动态地提出 SQL 查询。对吧？好的问题。嗯，让我给您举个例子。所以最重要的是速度以及句子的含义和技能本身的含义……
而不是将其作为文本，如果您只是将此作为文本存储在 SQL 文件中……抱歉在文件系统中的文件中。那么您将拥有许多方式让智能体执行正则表达式匹配。所以例如，所有搜索基本上将是基于……
关键词或单词搜索进入那个技能，这没问题。嗯但随着它变得更大就越难让智能体处理。首先……
正则表达式匹配对于巨大的文件来说效率低下，而且有时如果文件系统线性增长……
正则表达式匹配的性能呈指数级下降。嗯不，不是指数级，让我们说是二次方（quadratically）。但这是其中一个问题……
它不能像文件大小那样很好地扩展。另一个问题是如果您预先计算技能的嵌入向量，您实际上……
也捕获了这些嵌入中的含义，那种我们人类无法理解的隐藏意义。但与其仅仅用文本描述它……
这对于我们要阅读来说是可以的，但它也有从384到10,000多个维度的预计算。而这个嵌入实际上将持有……
在嵌入矩阵中每个令牌之间的东西，使其更加……
例如，可以通过语义搜索发现它。接着这会引导你尝试混合搜索，即结合语义搜索（嵌入向量）和关键词搜索的 RRF 方法。这是一种混合检索类型，表现更好，因为它同时利用了两者的优势。我可以在工作坊中展示一个例子，因为我制作了一个可视化图表来解释混合搜索的含义。
这是一个结合了关键词搜索和语义搜索能力的绘图，中间的空隙表示在进行混合搜索时比单独使用任何一种都更相关的结果。总之，拥有两种不同类型的搜索各有优势，但结合起来虽然计算量稍大，检索质量会随时间提升。我是从 AI 代理的角度思考这些内容的。
我不指望在座的各位立刻开始构建自己的定制 Harness，因为市场上已有优秀的解决方案，如 Cloud Code 和 CodeEx。顺便问一下，喜欢 Python 的人举手？人数比我预期的少，不过没关系。我仍是从 AI 代理的角度来阐述：你可以为特定问题构建定制 Harness，无需像创建新模型那样复杂。
相反，应简化要解决的问题，然后构建附加于其上的定制 Harness。例如，如果你是顾问，你就是我工作坊的完美用例：你可以为金融代理创建一个包含所需功能的定制 Harness。但如果面对不同数据或约束的客户，比如解决 Navir Stocks 问题或其他具有不同限制的问题时……
例如 OpenAI 提出的数学问题，需要无限的自动上下文压缩或摘要能力，因为这类代理中间没有人类参与。因此，解决这些问题的一切默认都需要自动上下文摘要和近乎无限的耐心。在这种情况下，代理循环简化为最多八个步骤。所有这些考量都取决于具体问题。
我会建议从头开始构建，这样可以剔除 90% 不需要的内容。一切围绕聊天完成 API 构建，尽管 Anthropic 和 OpenAI 都建立了自己的标准来应对这一局面。如果将模型通信视为 Harness 的附加插件，就会更清楚：越小越好。这回答了问题吗？
好的，请大家从代码库和 Code Space 开始设置笔记本。我将巡视一圈，如果有任何问题我们可以私下交流，因为我觉得被观察时会有压力，希望你们也一样。我通过退后一步把压力给你们。好吧，我们继续吧，时间不多了。天哪，时间过得真快。谢谢大家的掌声。
我以为过了 15 或 20 分钟，结果一小时过去了。我会设置好让你们在家也能创建 Code Space，费用由我承担。大家可以随意使用工作坊内容并探索它，不用担心费用。如果想讨论 Agent Harness 的概念，欢迎来 Oracle 展位，我们会待到周三晚上。感谢大家参加本次会话。