从头构建多智能体系统学到的经验

📌 One-Sentence Summary

Shopify 的一位高级工程师分享了从头构建多智能体系统的历程，揭示了专注特定领域的智能体优于通才型智能体，并且为领域专家提供工具比组建 AI 特种部队更有效。

📝 Summary

这份演讲实录详细介绍了 Paulo Arruda 在 Shopify 的经历，从早期使用依赖图进行测试生成的实验，到发现智能体搜索（如 Claude Code 中的方式）优于代码库索引。一个关键的黑客马拉松项目表明，两个 Claude Code 实例能够解决单个实例无法解决的问题，这促使他创建了一个名为 Swarm 的多智能体编排工具。演讲涵盖了该工具在 Shopify 的采用情况，并分享了成功案例，例如将主题审查时间从 22 小时缩短至 7-20 分钟。关键经验包括：将智能体视为专注特定领域的专家，避免在角色设定上浪费 token，以及赋能领域专家而非集中化 AI 知识。演讲最后展望了 2026 年，认为通过上下文工程让智能体大规模发挥作用将成为现实，并提出了一个名为 'llm-fuse' 的适配器层，用于高效地向智能体暴露数据，以及一个包含 'Defrag' 工具的记忆系统来管理上下文膨胀。

💡 Main Points

1. 专注特定领域的专家型智能体优于使用庞大提示词的通才型智能体。 将复杂任务分解为小型、专门的智能体（例如，为每个主题审查标准分配一个智能体）能显著提升效果并减少 token 浪费，主题审查时间从 22 小时降至 7 分钟就是例证。
2. 用工具赋能领域专家，而不是组建一个集中式的 AI 特种部队。 集中式的 AI 团队无法扩展。最有效的方法是构建工具（如 SwarmSDK），让领域专家能够创建自己的智能体，因为他们最了解自己的具体业务问题。
3. 对于代码理解而言，智能体搜索比代码库索引更有效、更具可扩展性。 Claude Code 的智能体搜索（使用 Grep、Read、Glob 等工具）被证明优于作者昂贵且难以维护的依赖图方法，使得智能体无需预先索引就能在任何代码库中有效运作。
4. MCP 工具导致的上下文膨胀是一个主要挑战；适配器层可能是解决方案。 将所有 MCP 工具加载到上下文中会浪费 token。提议的 'llm-fuse' 适配器层将标准的智能体工具（如 Read、Grep）转换为对任何数据源（例如数据库）的调用，使智能体能够访问信息而不会造成上下文污染。

💬 Key Quotes

• 等等。Claude Code 不知道怎么做。我也不知道怎么做，但两个 Claude Code 知道怎么做，这太棒了，让我震惊。
• 把智能体当作精简、专注的工具，是专家，而不是通才。
• 不要组建 AI 特种部队，要构建工具来赋能每个人。
• 理想的智能体，是其上下文窗口中的每一个 token 都与目标相关，并将结果引向期望方向的智能体。
• 我认为 2026 年将是我们真正让它们变得有用的一年。

📊 Article Meta

Read Full Article