何时编写代码或使用AI智能体框架

在我上一篇文章《我是如何为 QD 选择 AI 智能体框架的》中，我谈到了所有新的 AI 智能体工具。数量众多！那么，您何时应该用自己的代码构建 AI 智能体，何时又应该使用框架呢？这是一个棘手的问题。框架可以很快，而自定义代码则能提供完全控制。本文旨在探讨这一选择。我们将了解智能体如何工作，为何框架即使对于优秀的程序员也很方便，看看大型科技公司提供了什么，我还会分享我自己的想法。我并不是要说哪个框架是最好的；我只是想为您提供一些思路，帮助您选择适合您和您的项目的方案。

当我们开始构建 AI 智能体时，首先要解决的一个重要问题是关于谁或什么来主导。是应该由常规代码（例如用 Python 编写的代码）作为主要控制器，在需要特定智能任务时调用像 LLM 这样的 AI 模型？还是应该由 AI 模型本身作为主要驱动器，动态决定何时调用其他工具或代码片段？这个决定不仅仅是一个微小的技术细节；它从根本上改变了您构建甚至思考智能体的方式。如果您的代码是主导，那么整个过程感觉更像是常规编程。您编写脚本，当需要一点“智能”（例如理解文本或做出复杂决策）时，您的代码会调用 LLM 来执行该特定任务。之后，您的代码会处理 LLM 的输出并继续执行。这种方法让您对工作流程拥有很大的控制权，并且通常更容易测试和调试，因为您可以精确地看到您的代码正在一步一步地做什么。

另一方面，如果 LLM 处于主导地位，那更像是给 AI 一个目标，让它自己找出必要的步骤。LLM 可能会决定需要使用某个工具，也许是为了搜索网页或查找客户信息，所以它会调用该工具。然后，它分析工具的输出并决定下一步该怎么做。这种方法对于无法预先知道所有步骤的复杂任务来说可能非常强大。支持这种模型的框架通常会提到能够规划和执行任务的“代理”。然而，它也可能更难预测代理会做什么，并且调试可能更棘手，因为您试图理解 LLM 的内部“推理”。许多新的代理框架正试图找到有效的方法来处理这种控制平衡。有些旨在帮助您更容易地构建代码驱动的系统，而另一些则专注于让 LLM 处于主导地位。有些甚至试图融合这两种方法。理解这种基本的设计选择是为您的项目选择正确路径的关键部分。

考虑到这些因素，如果您是一名程序员，您可能会想知道为什么还要费心使用 AI 智能体框架。如果您可以自己编写代码，那还有什么意义呢？这是一个非常合理的问题。对于非常简单的智能体，或者如果您只是在试验，从头开始构建所有东西确实是学习所有组件如何工作的绝佳方式。但是，随着您的智能体想法不断发展，或者如果您需要它足够可靠以用于实际工作，即使您“技术上”可以自己编写所有代码，框架也能为您节省大量时间和精力。这很像构建一个网络应用程序：您“可以”从头开始编写所有基本的网络服务器逻辑，但大多数开发人员会使用 Flask 或 Ruby on Rails 等工具，因为它们能高效处理许多常见问题。

智能体框架旨在通过提供预构建的构建块和清晰的结构，为 AI 智能体开发提供类似的优势。它们通常为您提供一种合理的方式来组织智能体的各个部分，定义组件如何组合以进行决策或记忆，这样您就不必从头开始设计所有内容。框架还可以提供智能体与用户、其他智能体或不同软件服务进行通信的标准方式。对于需要执行多个步骤或按特定顺序管理任务的智能体，这些框架可以提供处理这种复杂性的系统。此外，由于大多数智能体需要使用外部工具，如搜索引擎或数据库，框架通常会使其更容易集成这些“函数调用”。一些框架还包括帮助您跟踪智能体操作和性能的工具，这对于运行时的监控至关重要。本质上，一个好的框架处理了大部分标准、重复的工作，让您可以专注于智能体的独特、智能方面，使其对您的特定问题有用。这可以帮助您更快地构建并创建更可靠的东西。

同样重要的是，不仅仅是初创公司和开源项目在创建这些 AI 智能体框架。科技巨头，那些提供我们已经使用的许多云服务和 AI 模型的公司，也在这个领域进行着重大布局。这尤其有趣，因为当这些巨头发布框架时，它会极大地影响行业趋势，特别是对于那些已经在使用其云服务的企业。这种情况有点像过去的转变，例如移动应用开发领域围绕 iOS 和 Android 出现的专业技能，或者云计算领域围绕 AWS、Azure 和 Google Cloud 形成的云工程专业人才。公司通常更喜欢与他们已经付费使用的系统良好集成的工具。因此，关注这些主要参与者正在提供什么，是明智之举，这并非因为他们的工具必然优越，而是因为它们很可能在企业环境中变得普遍。这些大型公司有强大的潜力将其智能体框架与其他服务捆绑销售，使其成为已经处于其生态系统内的企业的便捷选择。

微软正在大力推动其 **Azure AI Foundry**，将其定位为“AI 应用和代理工厂”。这个全栈平台旨在帮助开发者构建、部署和管理由 AI 驱动的应用和代理，统一并扩展现有工具，如 **AutoGen** 和 **Semantic Kernel**。其主要功能包括“代理服务”、高级多代理编排、更智能的模型路由，以及对可观察性和治理的强烈关注。（链接：微软的代理 AI 框架（旧概览）、AI 代理入门、Azure AI Foundry 代理服务正式发布（以及微软 Build 2025 中更广泛的 Azure AI Foundry 公告））。谷歌也在代理领域取得了显著进展。其产品包括 **Vertex AI** 平台，帮助开发者构建和管理连接到各种系统的代理。为了进一步兑现其互操作性承诺，谷歌最近宣布了 **Agent2Agent (A2A) 协议**，这是一个与许多合作伙伴共同开发的开放标准，允许来自不同供应商的 AI 代理进行通信和协调行动。此 A2A 协议旨在补充其他重要的开放标准，如 Anthropic 的 **模型上下文协议 (MCP)**，该协议专注于提供一种通用的方式，让 AI 系统能够连接到各种数据源。为了补充这些协议，谷歌还推出了 **代理开发工具包 (ADK)**，这是一个开源框架，旨在简化复杂代理和多代理系统的端到端开发。ADK 为谷歌自家产品中的代理提供支持，支持各种模型（Gemini、Vertex AI Model Garden 和通过 LiteLLM 支持的其他模型）和工具，包括兼容 MCP 的工具。它强调多代理设计、内置流处理、灵活编排以及集成的开发者/评估体验。虽然谷歌也为更通用的 AI 驱动应用提供 Genkit，但 ADK 专门针对构建复杂、协作式多代理系统的开发者进行了优化。（链接：使用 Vertex AI 构建和管理多系统代理、宣布 Agent2Agent 协议 (A2A)、介绍谷歌的代理开发工具包 (ADK)、Anthropic 的模型上下文协议 (MCP)）。亚马逊网络服务 (AWS) 提供 **Amazon Bedrock 代理**，用于构建可通过 API 调用执行任务的生成式 AI 应用程序，并最近推出了 **Strands**，这是一个开源 AI 代理 SDK。（链接：Amazon Bedrock 代理、介绍 Strands - 一个开源 AI 代理 SDK）。以网络基础设施闻名的 Cloudflare 提供 **Workers AI 代理**，允许开发者在其全球网络上部署 AI 代理。（链接：Cloudflare Workers AI 代理、在 Cloudflare 上构建 AI 代理）。OpenAI，GPT 等模型背后的公司，也发布了 **代理 SDK**，旨在方便开发者创建其模型能够推理和执行任务的应用程序。（链接：OpenAI 代理 SDK (GitHub)、构建代理的新工具）。作为 AI 硬件和软件的关键参与者，NVIDIA 也凭借 NVIDIA NIM™ 代理蓝图进入了这一领域。这些蓝图被描述为预训练、可定制的 AI 工作流程目录，旨在帮助企业构建和部署用于客户服务、从 PDF 进行检索增强生成 (RAG) 和药物发现等常见用例的生成式 AI 应用程序。这些蓝图包括示例应用程序、参考代码和部署工具，并且是更广泛的 NVIDIA AI Enterprise 平台的一部分，该平台包括 NIM 微服务和 NeMo 框架。NVIDIA 强调全栈方法和强大的合作伙伴生态系统，以帮助企业将 AI 应用程序投入运营。（链接：NVIDIA 和全球合作伙伴发布 NIM 代理蓝图）。这次快速概览表明，主要的云和 AI 平台提供商现在正在认真投资代理框架，这意味着我们可能会看到更多直接在这些平台上构建代理的工具和服务。

所有这些发展都让我思考我自己的工作，坦率地说，也关乎我的工作保障和咨询重点。这不是孤立地选择“最佳”框架。对我来说，这是关于识别一个清晰的行业趋势并战略性地定位自己。我们过去也见过这种模式。想想移动开发，专注于 iOS 或 Android 成为关键路径，因为它们在市场上占据主导地位。同样，在云计算领域，许多专业人士专注于 AWS、Azure 或 Google Cloud，因为企业采纳了这些平台。拥有基础设施的提供商通常在推广其相关工具方面具有显著优势。我在 AI 智能体领域看到了类似的动态。微软、谷歌和 AWS 等公司正在积极地将智能体功能和框架捆绑到其云产品中，鼓励其现有客户使用其集成工具构建和部署智能体。这通常会导致一定程度的“供应商锁定”。

我的预测是，许多企业将遵循这种集成路径，倾向于选择其主要云提供商提供的智能体框架。因此，我的个人策略是精通理解和使用这些大型科技公司的智能体框架。这并不是因为我相信它们在技术上会始终优于所有独立框架；一些规模较小、更专业的框架可能更具创新性，或者更适合特定的利基任务。然而，我相信对 Azure、Google Cloud 和 AWS 提供的产品有深入的理解将非常有价值，因为大部分企业 AI 开发很可能在那里进行。这关乎预判行业发展方向。这种专注有助于我的咨询工作，使我能够指导那些已投入这些生态系统的企业，并有助于确保我的技能在这个快速发展的领域保持相关性。我当然会关注更广泛的框架领域，但大型科技平台是我学习议程的核心部分。

那么，关于构建 AI 智能体，最终的结论是什么：是应该全部自己编写代码，还是使用框架？正如我们所探讨的，没有单一的答案。专家们明确表示，趋势是走向“复合 AI 系统”，即由多个部分协同工作的系统，因为它们通常能提供更好、更可控的结果。真正的问题是您决定如何构建该系统的一部分，以及您赋予 LLM 多少“自主性”或控制权。将 LLM 的自主性视为一个连续体会有所帮助。一端是您的代码牢牢掌控一切，像调用任何其他服务一样调用 LLM（Anthropic 将这些称为“工作流”）。另一端是 LLM 动态指导其自身的行为，决定何时使用哪些工具（Anthropic 将这些称为“智能体”）。许多实际解决方案介于这两个极端之间。

循序渐进几乎总是最好的建议。首先尝试直接调用 LLM API。正如 Anthropic 和 Hugging Face 的专家都建议的那样，许多有用的模式不需要复杂的框架。只有当它能明显改善您的结果或任务的复杂性确实需要时，才添加更多层，例如增加 LLM 驱动的自主性或使用框架。例如，一旦您涉及 LLM 调用外部工具或运行多步循环，您自然会发现自己需要输出解析器、内存管理和一致的提示。正是在此时，框架才通过提供这些基本构建块开始提供真正的价值。

框架，包括大型科技公司的平台，可以加速这些更复杂系统的构建过程。它们提供了结构并处理了许多常见的需求。对我来说，学习大型科技公司的产品是企业工作的战略选择，与我所预见的大规模复合系统构建方向一致。但是，正如许多人提醒的那样，务必注意过度抽象。始终尝试理解任何框架在底层做什么，并且在您的特定情况下，如果更简单的方法甚至纯代码更有效，请不要犹豫使用它们。

最终，构建高效 AI 的关键不是使用最花哨或最热门的工具，而是“巧妙的工程”。这关乎根据您的具体需求做出明智的选择。考虑以下问题：您正在尝试构建什么，它在代码驱动到 LLM 驱动的频谱中处于哪个位置？您和您的团队拥有哪些技能？您需要多快地推进？以及您对性能、成本和延迟有什么要求？AI 世界正在以惊人的速度发展。良好的判断力，包括理解您的需求、可用工具和底层原理，是您最宝贵的资产。持续学习，不断尝试，并始终专注于为您的需求构建“正确”的系统。