从零开始构建多智能体系统的经验教训

从零开始构建多智能体系统的经验教训

原文链接：https://www.infoq.com/presentations/multi-agent-system-lessons/

发布日期：2026-05-13T12:01:00+0000

摘要

保罗·阿鲁达（Paulo Arruda）讨论了Shopify在人工智能采用方面的演变，从简单的聊天工具发展到复杂的专门化智能体群。他解释了从庞大的“一揽子”提示过渡到专注于特定任务的智能体微服务，这些微服务将任务完成时间从数小时缩短到了几分钟。他还分享了一个关于使用基于文件系统的适配器来解决上下文膨胀问题的前瞻性假设。

个人简介

保罗·阿鲁达是Shopify的一名高级工程师，目前在Shopify的收入数据团队工作，负责推动收入数据领域的AI编排策略。此前，他是公司增强工程开发者体验团队的技术负责人。他创建了Claude Swarm（GitHub星标数超过1.4k）及其继任者SwarmSDK。保罗结合平台思维与务实的怀疑态度，倡导增强而非替代开发者的AI技术。

关于会议

QCon AI 是一个完全专注于安全扩展这些工作负载所需的工程学科的实践者主导活动。它提供了直接访问同行组织在生产中使用的架构方案和失败指标的机会。

INFOQ 会议

• /filters:no_upscale()/sponsorship/eventsnotice/3ecacfe1-02d1-4d54-a048-8ee8571a77bb/resources/1EonWebinarMay21-transcript-1774373522295.png)

2026年5月21日，东部时间下午12点 [设计可移植性：多云系统中的数据移动与恢复模式](https://www.infoq.com/url/t/1a93d975-e86c-4056-bef8-1226c10a404b/?label=Eon-Transcripts)

演讲嘉宾：李奥尔·沙伊（Lior Shai）- Eon解决方案架构师

• /filters:no_upscale()/sponsorship/eventsnotice/1302f11a-f90f-4a79-96d1-3dd20d032144/resources/1HarnessWebinarMay28-Transcripts-1776246863928.png)

2026年5月28日，东部时间下午1点 [更快地交付，更频繁地出错：在AI时代重新思考交付系统](https://www.infoq.com/url/t/220a7c0e-bb35-4591-8ef0-76c0fcdc9c42/?label=Harness-Transcripts)

演讲嘉宾：埃里克·明尼克（Eric Minick）- Harness高级DevOps解决方案总监，以及亚伦·纽科姆（Aaron Newcomb）- Harness高级产品市场经理

• /filters:no_upscale()/sponsorship/eventsnotice/7dd71c7c-4b0e-4760-b97d-232ac1816637/resources/1NeuBirdWebinarJune25-Transcripts-1777458459989.png)

2026年6月25日，东部时间下午1点 [为自主可靠性架构：将AI嵌入您的可观测性堆栈](https://www.infoq.com/url/t/1799cc66-1076-4f38-ba1e-fe340c13a7b2/?label=NeuBirdAI-Transcripts)

演讲嘉宾：贾斯汀·格里芬（Justin Griffin）- NeuBird AI产品经理

会议转录

保罗·阿鲁达：大家好，我是保罗·阿鲁达，目前是Shopify的一名高级工程师，主要在收入数据团队工作。大约两个月前我加入这个团队，但在那之前，我在增强工程开发者体验团队担任技术负责人。我想谈谈我在探索和尝试构建能够相互交流的计算机和智能体过程中的一些经历。这将更多地像一个故事，其中会有一些技术细节，但我想传达给你们的主要是一些无法在网上找到的见解和个人经验。

Shopify的人工智能采用

首先，让我们看看Shopify的人工智能采用情况。快进到2024年，但在此之前，当GPT-3.5推出时，我们与OpenAI签订了一份合同，获得了他们的模型，并且内部有一些聊天工具。快进到2024年，这些工具已经对所有人开放。我们与所有主要提供商签订了合同。我们有LibreChat，这是一个开源聊天界面，你可以设置智能体并与其对话，设定系统提示，等等。我们还有VSCode中的Copilot，以及当时大约有一年历史的Cursor。然而，仍然有一部分工程师每天并不使用AI，这在很大程度上是因为人们都很忙，没有时间尝试，或者曾经用GPT-3.5试过一次但体验不佳，因此产生了怀疑和抵触情绪。

这里有一点背景，我之所以喜欢 Shopify，是因为它真的拥有浓厚的黑客文化。这种文化源自我们的 CEO Tobi。好奇心在这里得到了极大的鼓励和奖励，并且他们为我们提供了所有必要的工具来探索。Tobi描述说，他希望 Shopify 成为一个工匠的乐园。这真是一个很好的特点。我的旅程始于测试生成。我从一些关于测试和 AI 的演讲中了解到一些信息。随着公司在测试方面采用 AI 的增多，人们会开始使用 AI 来生成代码，随之而来的就是各种问题。你会看到有包含 1,500 行代码的 PR 提交，最初的时候，人们会付出很大的努力来进行审查。但随着时间的推移，如果 AI 能够很好地工作，那么这些代码就可能会逐渐漏网。考虑到这一点，我们思考如何解决这个问题，假设开发者最终会推送一些由 AI 生成的低质量代码。于是我们想到了测试，特别是测试生成。如果我们能够改进我们的测试套件，就可以在 PR 中及时发现这些问题。大约在 2024 年 10 月，我们就开始考虑这个问题了。然后我做了一个实验。我们有“黑客日”这个概念，在这三天里，我们可以自由选择想做的事情，做一些纯粹的黑客项目，还可以组建团队来完成这些项目。我的项目是能够在现有大型代码库中生成测试用例。Shopify 就是一个基于 Rails 构建的巨大单体应用。我认为，为了能够为尚未有测试的代码生成测试用例，必须理解代码中的内容，才能写出正确的测试来理解其行为。这就是我当时的想法。然后我进行了一个快速实验，只是映射文件之间的关系。这只是我可能尝试的众多方法之一的假设。我选择了这个方向。例如，Cursor 在这个过程中对代码库进行了索引并进行了搜索。这还不错，但它仍然会错过很多语义上的关系。你们是否熟悉 Rails？Ruby 中也有很多隐含的行为。有些东西并不是那么显而易见。我试图构建一个文件之间的依赖图。这是一个非常昂贵的实验。我为每一份源代码文件生成了 GPT 总结。然后把这些总结作为图中的节点。我获取了边，即它们之间的连接，包括常量声明与使用的关联，以及方法定义与使用的关联。然后我开始生成这些关系的总结，因为我想要找到那些纯粹通过代码搜索无法发现的隐藏关系。这是一个实验，结果还算不错，但代价非常高昂。你无法持续更新它。我们每天有成百上千个 PR 提交。要保持这个索引的实时性，会非常困难，这也使得它变得毫无用处。

初露曙光（Claude Code 研究预览）

再补充一点背景。到了二月底，Claude Code 作为一个研究预览版发布了。这彻底改变了局面，因为这些家伙表示，他们实际上尝试过对代码库进行索引，但他们发现代理型搜索效果更好。我自己也看到了这一点。我在使用 Claude Code。你们中有多少人也在使用 Claude Code？它就像 Grep 和 Read 这样的工具，能够很好地找到代码。它的效果和 Cursor 进行索引的效果一样好，但没有额外的开销，因此可以在任何代码库中运行。这真是太棒了。四月初，Tobi 向整个公司发送了一封电子邮件，随后在社交媒体上泄露了消息，基本上是说：“大家，我们必须加入这场 AI 赛道。”他说，在招聘新人之前，我们需要确保 AI 不能胜任这项工作。但这并不意味着我们不会招聘人。当时他并不是这个意思，但后来的文章对此有一些曲解。我的观点是，这实际上激发了 Shopify 上下对 AI 的探索。Shopify 大约有 6,000 名员工。现在，即使是非 R&D 部门、非工程师的人也开始在 Shopify 上编写代码原型。这真是令人惊叹，看看那封单一的电子邮件产生了多大的影响。

2025年5月：峰会期间的黑客日

在今年5月，我在我们公司每年举行的峰会期间参加了一场黑客松活动。那时我有一个宠物项目，想尝试一下代码理解。Agentic搜索表现得相当不错。如果我给Claude Code提供自由导航AST的工具会怎样呢？我很好奇，它会表现如何？我能得到比纯粹的Agentic搜索更好的结果吗？于是我就开始了这个项目。我的目标是构建一个Ruby Gem，使其成为一个MCP服务器。我会将其连接到Claude Code，并赋予它使用Prism（Ruby解析器）的工具。我只想添加一个适配层，使它像Read、Grep、Glob一样工作，即Claude Code常用的工具，并且让这两个调用能够导航AST而不是文件。因为只有大约三天时间，所以我想快速完成。这就是所谓的“vibe code”。第一次尝试时，Claude Code对Prism了解不多，文档中缺乏示例。它的表现非常糟糕，根本无法完成任务。然后我想，我将回到老方法，亲自阅读Prism的代码库。文档不是很好，我将学习如何使用Prism，然后告诉Claude Code根据我读的内容来构建我的库。这感觉像是去年的事情。接着我想，好吧，我克隆了Prism的仓库，并在里面启动了一个Claude Code实例。你知道Claude Code是怎么做的。当你问它如何使用Prism时，它会扫描代码库，学习如何操作，并给出答案。然后我觉得太棒了，我向Prism的Claude Code询问了这个问题，然后直接复制粘贴到正在构建库的Claude Code实例中。真是令人惊叹的进步，但过程非常繁琐。

然后有了一个大想法，即能否自动化这个过程？这次，我认为可以通过MCP获取一个非交互式的Claude Code实例，并将其连接到我正在构建库的主要实例所在的仓库中。这样确实有效。我从头开始，一次完成了我想做的事情。虽然我想要实现的功能并不复杂，但Claude Code本身无法做到。这次它做到了。实验失败了，因为它速度很慢，效果还不如文件搜索，是一个失败的假设。这个想法也就此终结。等等，Claude Code不知道怎么做。我不知道怎么做，但有两个Claude Code知道怎么做，这真是太神奇了。我觉得这里有些东西值得探索。于是我决定将这个功能封装成一个Ruby Gem，供其他人在黑客松活动中快速尝试并使用。因为现在，突然间，如果我在克隆的代码库中拥有Claude Code实例，它们可以使用所有这些库，并且这会使主要的Claude Code更加智能。我将它封装成了一个Ruby Gem。你可以通过YAML设置这些Claude Code实例。它们将以树状结构运行，就像你在图片中看到的那样。它可以构建任意多的层级。那时我只是想看看它能做什么。我完全不知道这是否会奏效。你可以将它们放在多个目录或同一个目录中。我们的代码库庞大，单个Claude Code实例无法理解整个库。如果你在代码库的不同部分构建一些小的专业化实例，效果会更好。我增加了一个特性Vibe: true!，这会让Claude Code以危险的方式跳过权限运行。你们有试过这个特性吗？真是太酷了。让它尽情发挥吧。我现在就是这样做的。

采用情况

随后，在工程团队中，人们开始采用这个工具。今天，我仍然在日常开发中使用它。当时我们在进行增强工程，需要大规模生成测试用例。我们使用了一个Claude Code实例来生成测试用例，然后使用Gemini 2.5 Pro来批评这些测试用例。我们也使用o3-pro来批评它们。这样我就能得到更好的结果。此外，人们还用它来回答关于大型代码库的问题。实际上，我的解决方案相当粗糙，很难弄清楚日志，我不得不从创建的日志文件夹中窃取日志。这并不是一个好的做法。大约在六月初，我联系他们说：“你们是否想将这个功能集成到你们的工具中，因为我们想使用它，我认为你们可以做得更好？”然后在七月初，我们开始用它进行一些重要的项目，其他团队也在利用它做其他事情。我还需要为测试生成添加多提供商支持，正如我之前所说。我们使用Gemini和o3来验证Claude的工作成果。7月24日，Anthropic发布了子代理。对我来说，这是模型工作的验证。到了八月，公司的另一部分非R&D人员也发现了这个工具。许多新的应用场景开始浮现。我发现的一个模式是，他们之前的想法是在LibreChat中使用一个大型LLM，带有大量的提示。然而，这会导致太多无关的标记和指令，使得LLM迷失方向，结果非常差。于是，我开始帮助他们用多个Claude Code实例构建这些应用。

我在运营方面发现的第一个重大成功是在主题审查中。当你向Shopify商店提交一个主题时，我们有一个团队对其进行审查。为了审查，他们需要验证大量的合规性检查项。最初，这些工作都是由人类完成的，后来借助AI，他们开始使用包含所有规则的一条巨大提示来尝试解决这些问题。这已经让他们完成了一半的工作。即使这样，整个过程仍然需要22个小时。当我们使用Claude Swarm将每个审查标准拆分成单独的代理后，他们能够将完成时间缩短到7到20分钟。这是一个巨大的时间节省。此外，我们还有另一个内部职位评估的例子，用于评估员工的候选人角色。这些任务耗费了负责该工作的人员大量时间，通过将它们拆分成多个代理，过程得以在不到一小时内完成。这也节省了大量的时间。随后，公司高层开始利用这些代理回答需要深入研究内部系统的问题。例如，在这个例子中，他们构建了一个由15个Claude Code实例组成的群集，用于研究内部文档系统以确定我们在第二季度发布了哪些内容。每个实例都针对特定的业务功能。他们试图通过一条巨大的提示来解决这个问题，然后将其拆分成多个专注于特定领域的代理。这真的帮助他们得到了想要的答案。之后我们又取得了一些成功。有人使用这些代理来进行产品设计、跟踪语言翻译、构建工作分解结构、进行多维度研究以及研究多个系统以解决问题。他们还开始使用这些代理来评估供应商。这是一个有趣的案例，因为供应商会做出一些声明，并需要提供文档来支持这些声明，但有时这些文档会有很多PDF文件和幻灯片。你需要使用多个代理来审查这些文档，并基于这些文档验证他们对你的问题的回答。显然，我所说的这一切都不是完全自动化的。人类仍然需要验证一切。

这是一个重大的突破，但也存在很多限制。对于非开发人员来说，设置YAML文件并进入Claude Code实例太难了。他们必须输入命令。这并不是一个好的体验。有时，即使是开发者也觉得设置YAML编程很困难。有些人对此并不满意。多提供商实现是一个巨大的hack。基本上，使用另一个库并将它注入框架中，以便从Claude Code访问所有提供商，然后日志记录方式不同。这简直就是一场噩梦。另一个问题是，我发现人们不再希望代理委托给其他代理。他们更希望进行工作流操作。很多时候，你希望运行一些确定性的步骤，或者按阶段运行某些东西。你有一个计划阶段，然后是执行阶段。你不一定想告诉AI，用提示写那个工作流，因为你知道，在大规模应用时，它可能会无法遵循指令。

工作变动观察到的模式

九月到来时，我的工作发生了彻底的变化。这种变化在整个公司范围内传播开来，每个人都来找我，询问：“你能帮我团队吗？”我开始四处奔波，整天参加各种会议，试图理解他们的工作。模式基本上就像一个AI突击队：“他是那个AI家伙，去找Paulo谈谈吧。”这是一种反模式，无法扩展。每个团队都有自己的关键人物，即AI爱好者。你需要赋予他们权力，支持他们，因为他们了解自己的领域。我不懂如何为财务部门构建代理，但他们懂。我们需要支持这些家伙。我观察到了两个模式。大量的重复建设。在这里，开发人员喜欢自己动手做。我在整个公司范围内看到，人们都在构建相同的系统。人们在构建用于运行AI和CI的管道，每个团队都在构建自己的工作流系统，每个团队都在构建自己的多代理系统。AI的采用非常碎片化。那些没有构建自己系统的团队则选择了不同的框架，比如一个团队使用LangChain，另一个团队使用其他框架。有很多不同的框架可供选择。从这一经验中获得的一个见解是鼓励实验，但要利用这些学习成果来构建正确的东西。为了解决重复建设的问题，我说：“我会把这些家伙召集在一起，看看我们是否可以开始协作，互相分享你们正在做什么？”我联系了那些正在进行赞助工作并涉及构建AI工具的人。现在每个月第三个星期四，我都把他们都召集到一起开会，至今仍在继续。我们讨论我们正在构建的内容，并思考如何减少重复建设，例如，如果你正在构建一个管道，而我并不需要再构建一个，我可以直接使用你的。

对未来的愿景

一个快速暂停

在处理其他问题之前，我们先来谈谈碎片化的问题。如果事情继续按现在的方向发展，你可以想象，公司内部的团队将会各自开发自己的代理，并且这些代理会与公司的内部产品、工作流程和过程进行交互。随后，可能会有人提出，如果我们能够把这些代理组合起来，以回答更高级的问题或更复杂的问题，那该多好。另一个认识随之而来，这就是我所说的代理微服务架构。如果公司在AI采用方面非常碎片化，每个人都使用自己的框架独自开发，那么将来如果我们想把这些代理组合起来，最终也会面临同样的问题。我们需要让这些代理通过某种网络手段（如A2A、MCP）相互交流，从而带来与微服务相同的问题，比如网络重试、可观测性挑战和追踪难题。这就像是说，到这里就停下来吧。让我们回头解决这个问题，而不是让它发展到那个地步。然后，我决定自己动手建设。我继续坚持统一编排策略的想法。这个想法是，如果公司里的每个人都使用相同的编排系统，定义代理的方式也是一致的，那么实际上我们不需要使用MCP或其他手段让它们互相交流。我可以直接导入这些定义，在同一个进程中运行它们，这在Ruby中表现得非常好。如果你熟悉Ruby，它非常适合使用协程（fibers）。大多数LLM的工作都是I/O绑定的，只需要进行网络请求获取答案，然后运行一些工具。这些工具通常就是MCP工具。接着再进行一次网络请求。你可以利用协程在同一个进程中运行大量这些工具，通过协程调度实现。于是，我构建了SwarmSDK。虽然它与OpenAI的Swarm无关，但我称之为SwarmSDK是因为我们之前曾这样称呼它。Swarm使得公司内的每个人都能轻松使用。基本上，这是一个Ruby gem，支持多提供者。你可以用YAML或Ruby DSL构建代理定义，赋予开发者更多权力。除了树形结构或组织图式的代理组合外，你还可以构建工作流。它还提供了事件钩子，就像Claude Code一样，可以为每个事件编写代码或调用脚本。内置了可观测性的成本跟踪功能，所有操作都在同一个进程中完成，因此在中间事件发生时，我可以很容易地追踪到发生了什么。它还具有插件系统，你可以扩展功能。利用插件系统，我构建了一个内存插件，同时附带了内存功能。在这次演讲中，我会稍微介绍一下内存功能。

经验教训

经验教训。最好的解决方案始于我的个人痛点。我在尝试解决问题。将代理视为精简、专注于特定任务的工具，而不是泛用型工具。我看到很多人在构建人设或简历之类的东西。对我来说，这些都是浪费tokens。除非你需要用这些来控制AI给出的答案，对于多代理编排的小任务来说，其实并不需要那么多。使用的tokens越少越好。第三，不要组建一支AI突袭队，而是要为所有人提供工具。

展望未来

我已经给你们介绍了三点需要注意的地方，但我想再谈一些别的东西。还有一点。2025年，我听说这一年将是代理的年份，确实如此。我看到大家都在公司内构建代理：代理、代理、代理。人们在争论什么是代理。我认为到2025年底，许多公司将已经在其公司内拥有各种各样的编排系统。他们会有许多代理，但接下来呢？情况仍然有些模糊。我认为2026年将是真正让这些代理发挥作用的一年。其中一些代理现在已经很有用了，但我说的是通过上下文工程在大规模应用中的有用性。我心里的问题是：我们如何以最大化精确度和召回率的方式向代理暴露数据？为此，我必须解决这里的大象——MCP。目前MCP的使用方式是增加一堆工具。你在客户端添加一堆MCP服务器，然后加载一堆工具，这些工具自带描述和参数。这些参数的描述很多时候与你正在执行的任务无关。有时你可能只需要Gmail MCP，如果你只是想读取邮件，就不需要在上下文中包含关于如何发送邮件的tokens，因为这纯粹是浪费。理想的代理是其上下文窗口中的每一个token都相关，并引导结果朝着预期的方向发展。由于MCP导致的上下文膨胀，我们看到了许多应对措施。Anthropic正在努力开发两项功能，例如技能和工具搜索工具。我觉得这只是把问题转移到另一个层面。

未来展望

我给你们介绍了三点需要记住的内容，但我想再谈一些别的东西。还有一点。2025年，我听说这一年将是代理的年份，确实如此。我看到大家都在公司内构建代理：代理、代理、代理。人们在争论什么是代理。我认为到2025年底，许多公司将已经在其公司内拥有各种各样的编排系统。他们会有许多代理，但接下来呢？情况仍然有些模糊。我认为2026年将是真正让这些代理发挥作用的一年。其中一些代理现在已经很有用了，但我说的是通过上下文工程在大规模应用中的有用性。我心里的问题是：我们如何以最大化精确度和召回率的方式向代理暴露数据？为此，我必须解决这里的大象——MCP。目前MCP的使用方式是增加一堆工具。你在客户端添加一堆MCP服务器，然后加载一堆工具，这些工具自带描述和参数。这些参数的描述很多时候与你正在执行的任务无关。有时你可能只需要Gmail MCP，如果你只是想读取邮件，就不需要在上下文中包含关于如何发送邮件的tokens，因为这纯粹是浪费。理想的代理是其上下文窗口中的每一个token都相关，并引导结果朝着预期的方向发展。由于MCP导致的上下文膨胀，我们看到了许多应对措施。Anthropic正在努力开发两项功能，例如技能和工具搜索工具。我觉得这只是把问题转移到另一个层面。

我不知道答案，但我有一个假设想要与你们分享。这是我希望你们带回公司思考的东西。这不一定能奏效，但或许可以成为一个解决方案。模型，尤其是那些前沿模型，它们主要经过了大量编程任务的训练。坦率地说，如果你解决了编程问题，你就解决了大多数问题。因此，对这些模型进行编程任务的训练有着巨大的兴趣。当你想到模型擅长编程时，有两点需要注意。首先，它们必须知道如何编写代码。为此，它们需要看到大量的例子，也就是通过训练来实现。其次，它们需要非常擅长发现代码，即我们所说的代理搜索。我的假设是，如果能够创建一个适配层，我称之为llm-fuse。这里有没有人熟悉Fuse？基本上，Fuse允许你将事物暴露为文件系统。实际上，你不需要将这些东西挂载为文件系统并让LLMs读取它。如果你控制这些工具，比如Read、Grep、Glob、Search，你可以进行向量搜索和关键词搜索，并结合一些不错的排名技术。如果你控制这些工具，Write、Edit、Delete，以及稍后我会提到的Defrag，你可以在这两者之间创建一个适配层。这样，你就可以将这些调用转换为你所拥有的任何数据源。我在内部已经有一个这种适配层的原型。我的数据存储在一个Postgres数据库中。我创建了一个适配层。这些代理认为自己在读取文件，但实际上它们是在访问数据库。这样一来，就像电影《黑客帝国》中的场景一样，尼尔拿起电话说：“嘿，我想学会如何驾驶这架直升机。”我们可以通过这个系统向这些代理注入知识。你只需要为每个数据源系统开发适配层。最后一个工具是Defrag，因为这些代理也可以写入这些记忆。它们可以从与你的互动中学到东西，并且你可以指派它们一项任务。给你一个网络搜索工具，说：“去学习关于X的一切吧。”然后它们会去学习。它们也可以使用内部系统并将所有内容存储在内存中。随着时间的推移，这些记忆会变得碎片化。然后我想起了Defrag。我创建了一个Defrag工具，它可以遍历所有记忆，对其进行优化，合并相似的记忆，并保持整洁以优化读取效率。每条记忆都有元数据，包括标题、标签、来源（是否来自用户）、点击次数以及相关记忆。当你提示一个代理之前，在发送请求给LLM之前，它会基于关键词搜索和其他技术返回可能相关的记忆。然后，在发送请求给LLM之前，它会在提示的底部加上一条系统提醒：“这些记忆可能或可能不与查询相关，这是文件路径，这是记忆的标题。”LLM可以根据这些信息做出决定，是否阅读这些记忆。每次LLM阅读记忆时，也会得到一个提醒，告诉你你刚才阅读的记忆，但这里标记的记忆与此记忆相关。你是否想阅读这些标记的记忆呢？LLM会根据这些信息做出是否阅读的决定。我已经在这个技术上得到了很好的早期结果，但再次强调，这只是实验性的。我希望你们能将这个想法带回去思考。

查看更多[带有转录的演讲](https://www.infoq.com/transcripts/presentations/)

录制于：

2026年5月13日