大家好，我想向大家介绍我们如何将 AI 智能体从实验阶段过渡到真正的企业环境。在开始之前，先简单介绍一下我自己。我叫 Sharish Gokar，是 Intuit Credit Karma 的高级软件工程师，负责构建和维护 AI 分析基础设施及服务。此外，我还担任顾问、作者和研究员，并作为多个组织的程序委员会成员，指导年轻研究人员。

好的，让我们来看一下议程。首先，我们要讨论在构建 AI 智能体并将其部署到生产系统时面临的挑战，以及如何建立不同的框架来解决这些挑战。接着介绍其架构设计。然后讲解如何构建您自己的 MCP 服务器和 MCP 网关，以及在该网关之上的监控措施。

此外，我们还将探讨不同类型的智能体框架，以及如何围绕记忆管理、跟踪和评估构建额外框架。我们会讨论如何阻止个人身份信息（PII）数据进入大语言模型，以及如何使用上下文优化器来节省令牌。接下来直接进入挑战部分。

当然，许多智能体在生产环境中失败是因为缺乏基础控制措施。主要原因在于缺少网关，以确保智能体能够通过正确的身份验证提供商进行认证，从而重定向到合适的 MCP 服务器。其次，MCP 服务器可能缺乏执行查询的正确工具。

第三，我们是否有足够的跟踪和评估系统来确保每个发送给智能体的请求都被记录，并评估响应质量？第四，是否有记忆管理系统来处理长期或多天的交互，使智能体能够回忆过去的请求？

还有其他框架问题：是否有节省令牌的上下文措施？是否在生产环境中实施了控制，确保任何机密信息不会泄露到大语言模型、跟踪系统或内存数据库中？这些问题都亟待解决。

为了解决这些问题，我们不会在这个演示中构建一个神奇的智能体，而是讨论可以建立的不同的框架。首先是智能体框架。我们选择使用 LangChain 社区提供的 LangGraph 框架，这有助于根据您的问题构建基于任务特定的节点。

这使得轻松集成市场插件、技能和提示成为可能，确保智能体根据您的查询做出高效响应。其次，我们正在构建 MCP 网关，以确保每当智能体或服务账户发起调用时，能够安全地通过该网关进行身份验证，然后被重定向到正确的 MCP 服务器。

第三是定制的 MCP，意味着您正在构建拥有正确工具以执行查询的自有 MCP 服务器。最后是对实际操作的审计记录，以及围绕阻止 PII 机密信息、将跟踪评估存储到云端、处理上下文中的线程和检查点记忆，以及优化整体上下文以避免消耗过多令牌的框架。

现在谈谈智能体基础设施。首先介绍本地开发方法。构建智能体的第一步是将其注册到某个系统中，说明用例及其适用的垂直领域或系统，并提供所有信息以生成智能体 ID。

获得 ID 后，您可以使用内部开发者门户输入详细信息：说明这是您的智能体用例、ID、使用的框架（如 LangGraph 或 LangChain）、编程语言（Python 或 TypeScript），并选择技能、提示，然后提交信息。

一旦提交，开发者门户将创建一个仓库，其中不仅包含智能体框架（如 LangGraph），还包含记忆框架、跟踪评估框架、上下文优化器框架以及 PII 阻止框架。这是因为并非所有开发人员都负责所有这些框架，他们通常只关注 AI 助手工具常用的一个或两个框架。

我们希望确保在推出此类框架时，在公司范围内保持一致，并集中管理以便可视化结果。开发人员克隆该仓库后，可以将智能体构建为 Docker 镜像和容器，并通过查询测试输入输出。

他们还可以跟踪本地内存或云端评估器中的情况，并将这些跟踪和评估数据存储在 SQLite 或 BigQuery等数据库中，以确保智能体在本地完全正常运行。一旦智能体在本地运行正常，就可以准备生成拉取请求（PR）。

获得两个 PR 批准后，代码将进入 CI/CD 管道。首先，PR 会将智能体注册到集中的智能体注册系统，提供链接和 URL 以查看所有跟踪记录。然后 CI/CD 管道将处理本地

你在此处构建的 Docker 容器将被部署到生产系统中。系统会扫描该镜像，确保其中没有漏洞。如果一切看起来都很完美并获得了安全批准，你就可以将该镜像移回注册中心。此外，你拥有自己的部署平台或编排器平台，它将在给定的命名空间中将该代理部署到 Kubernetes 集群中。

这里的好处是，这个开发门户不仅仅是创建代码仓库，它还创建了其他许多生产资源，例如工作负载身份、内存数据库或跟踪和评估表以及代理密钥管理。因此，基于你提供的名称，它不仅创建仓库，还创建了所有这些不同的资源。

当内部编排器部署代理时，代理已经知道它应该与哪个工作负载身份配合使用。这种绑定应该已经完成。一旦 K 到 GSA（Google Service Account）的绑定发生，代理就会开始与所有这些资源进行通信。

一切就绪后，代理将进一步与你其余的端点服务（例如 AI 网关、MCP 服务器或用于跟踪的长度熔断器，或其他一些 API 端点）进行通信。

我们之前也谈到了 MCP 服务器架构，现在我们将进入不同的组件部分。MCP 服务器是你肯定可以使用的外部可用工具之一，但如果你工作在气隙（air gap）环境中，强烈建议你构建自己的 MCP 服务器。

框架的构建方式如下：你可以利用 FastMCP Server 包或包装器来构建这些 MCP 服务器，并可以在该快速 MCP 包装器内创建不同的工具集以构造整体服务器。

然后你要确保，当你在 MCP 服务器中定义每个工具时，都必须经过内部安全团队的全面审查，以确保只有授权的工具才能进入生产环境。

通过这种方式，你可以实施一些过滤器、限制措施，并阻止那些不需要发送给大语言模型（LLM）以获取你不被允许获取的信息的字段。

第三部分是，当然你需要确保构建 MCP 服务器的方式是：当流量从你的 MCP 客户端到达 MCP 网关再到 MCP 服务器时，无论是来自用户服务账户的流量，都必须先向 MCP 网关进行身份验证。

只有这样，它们才能访问你的 MCP 工具以获取正确的信息。现在来看网关部分。如果你再次工作在气隙环境中，你可以构建自己的内部 MCP 网关。

其工作原理是：你正在使用云辅助工具（如本地代码辅助工具）或代理。当你向你的代理提交第一个查询时，它会向 MCP 网关发送一次性身份验证请求。

MCP 网关识别并接受你的请求后，首先会将会话状态保存到 Redis 中，然后将 JWT 访问令牌返回给你的客户端。

一旦客户端收到该 JWT 令牌，它就知道需要调用哪个 MCP 服务器了。因此，它会向给定的命名空间（例如 Artifactory/MCP 或 GitHub/MCP）提交工具调用请求，并在其中附带认证承载者 JWT 令牌。

一旦 MCP 网关收到该请求，它就会理解需要查找哪个命名空间中的 MCP 服务器。然后它会解析 JWT 令牌，并将用户令牌附加到该请求中发送给相应的 MCP 服务器。

MCP 服务器收到后，会向相应服务的端点发出 API 调用，然后根据用户被授权查看的范围交换 ID 令牌并返回响应。

一旦用户收到令牌，MCP 服务器基本上会解析所有数据，制作与 MCP 网关接收兼容的有效载荷。

最终有效载荷将被发送回客户端以查看数据点。这表明我们构建了 MCP 网关，以确保拥有一个集中的身份验证和路由中心，通过该网关和安全地将任何代码辅助工具或代理连接到端点。

不应直接提供对任何端点的访问权限。在到达 MCP 服务器和端点之前，它们必须通过适当的身份验证经过 MCP 网关。

现在部分是关于网关监控的。我们再次谈论架构、MCP 服务器和 MCP 网关，现在是监控部分。

没有持续的监控、评估和反馈，AI 代理是不可信的。这就是我们构建 MCP 网关监控的原因。

其工作原理通常是：当你向你的代理提交任何调用时，它会将所有操作日志发送到日志存储区。你可以使用 ELK、Loki 或 CloudWatch，对吧？

通常这包含诸如“显示我过去 10 分钟调用中的所有最后 401 错误”或 OAuth 在令牌刷新失败时做了什么之类的信息。

这类请求可以发送到日志存储区。此外，还有一些实时跟踪和指标数据也会进入 OpenTelemetry。

OpenTelemetry 再次是一种开源解决方案，它将收集所有的跟踪和指标数据，处理这些数据并将其重定向到后端系统。

在这种情况下，跟踪数据将进入 Tempo。这再次是一种开源解决方案，它将存储所有的跟踪信息，例如哪个工具在此请求中较慢、调用是来自代理还是 IDE，或者此失败调用的确切错误是什么。

这类数据将存储到 Tempo 中（抱歉，说错了）。然后指标部分关于 Prometheus，它包含诸如给定工具的 P95 延迟是多少、在特定时间身份验证拒绝是否激增等信息。

这类指标将存储在 Prometheus

获取所有这些数据点，比如追踪记录和指标。这些聚合后的实际数据现在都保存到图中，用于可视化展示。好了，MCP 网关和监控部分已经介绍完毕。接下来我们要谈谈框架，也就是智能体框架。在大多数情况下，我们使用 LangGraph。它由 LangChain 社区提供，本质上是一种基于图形的架构，支持循环、分支和状态管理，适用于复杂的多智能体 AI 工作流。

其工作原理是这样的：当你提交第一个查询时，我们会先解析你的问题，判断问题的类型以及期望的响应。基于此，它会制定一个计划。然后将其发送到分类区域，以确定这是只读操作、修改级别的操作、删除某些内容还是敏感操作。基于分类结果，它会调整整体结构并相应地制定计划。

下一步的计划本身就是一个子图，你在其中执行大部分操作。这意味着一旦你知道要执行什么操作，它就会进入“获取证据”部分。在解释和分类之后，它会调用 MCP 网关进行身份验证，然后使用正确的工具向 MCP 服务器发起调用以获取数据，并生成相应的证据。

一旦你验证了所有发现结果，它就会检查策略。如果是只读操作，它将继续执行并将所有记录点保存到审计日志中。但如果是写入和敏感操作，则必须经过人工在环（HITL）流程等待批准。如果获得批准，就执行；如果被拒绝，无论哪种情况都会保存到审计日志中。

将 MCP 网关、MCP 服务器和智能体结合起来，整体架构如下所示：无论构建什么样的智能体或提交什么调用，都会先通过 MCP 网关进行身份验证，然后重定向到正确的 MCP 服务器以在给定工具上执行查询。这样它就能向该端点发起 API 调用并获取响应。

从基础设施的角度来看，智能体与 MCP 网关通信，然后连接到 MCP 服务器和端点。之前我们谈了很多关于 MCP 网关、MCP 服务器、监控以及智能体框架的内容。现在我们要讨论构建端到端生态系统时还需要具备的三个额外框架，首先是智能体记忆管理。

这是一个保存和恢复工作流状态的过程，确保在每次查询运行之间提供持久性和无缝恢复。当你向智能体提交任何查询时，它会生成一个线程。在该给定线程上询问第一个问题时，会创建一个运行 ID（Run ID）。当你提出更深入的问题时，它会在 LangGraph 的特定节点上执行该查询。

在该节点上，它会保存相应的检查点（Checkpoint）。如果在线程内提出后续问题，它将创建另一个运行 ID。根据后续问题，它会进入特定节点并在那里保存检查点。对于本地开发数据，你可以使用 SQLite 数据库；但在生产环境中（如在 GCP 上），可以使用 Cloud Spanner。在 Azure 和 AWS 中也可以使用相应的数据库。

这里快速演示一下记忆功能。例如，我刚刚在本地构建了智能体并尝试在 SQLite 数据库中运行查询以查看是否有数据。起初没有任何数据，现在我提交查询，你会看到收到一条记录，显示线程 ID、被问到的问题以及执行该查询的确切时间。

如果我运行下一个查询以查看“在线程上生成了多少条消息”，你可以通过进一步查询获取此信息。如果我想查看关于我的查询的所有元数据级别的信息，我可以再次运行查询并看到详细描述，比如调用了多少个工具、线程 ID 和运行 ID 等。

如果我还想查看执行了哪些工具，你可以看到给定 MCP 服务器上的确切工具名称。此外，我还想查看 LangGraph 框架中的进展过程，这也可以通过在记忆数据库中运行此类查询来看到。你可以在此处看到不同类型的节点在被调用时的情况，即实际执行该查询时调用了哪些节点。

接下来是追踪和评估（Tracking and Eval）。为了确保没有混淆，之前提到的 MCP 网关监控属于基础设施层面，而这是智能体级别的追踪。我们这样做是因为我们需要跟踪提交给智能体的查询、返回的响应、使用的模型、令牌成本以及消耗的令牌数量。还需要了解评估标准，即响应的质量如何。

你需要从第一天起就存储这些数据。想象一下，如果你有上千个智能体，每个智能体都有自己的追踪和评估项目及表结构。例如，如果有 100 个智能体，你就会有 100 个项目和各自相应的追踪评估表。

六个月后如果有人问你智能体的表现如何、响应是什么、质量怎样以及消耗了多少令牌，你可以聚合所有这些数据并围绕其创建执行仪表板以进行查看。

为了了解构建如此多的智能体（Agents）的投资回报率，我将通过跟踪和评估演示来为您梳理。如果您查看这里列出的六个表格，其中一个是作业跟踪表，它包含了关于查询、响应等大部分信息。此外还有质量相关表格、工具调用记录以及节点级执行日志等其他表。在这种情况下，我将向我的智能体提交第一个查询，起初由于需要时间处理，数据可能不会立即显示。

刷新后，您可以看到针对特定查询的请求ID、会话ID、智能体名称、提出的问题及其输出结果。系统还会记录任务是否完成以及耗时，并显示所使用的模型和一些中间层信息。进一步查看质量部分时，每次运行会有八项质量检测指标，包括成功率、延迟、成本、工具准确性、安全性等，这些数据均被存储在此处。

评估分数则以单行形式呈现为记分板，数值在零到一之间变化，将各个质量维度综合在一个行中展示。而质量指标则是对特定运行情况的深入分析，以嵌套字段形式记录响应质量、安全性、延迟、成本及工具状态。关于工具调用，系统记录了每个MCP工具的运行时长及其成功与否的状态信息。

智能体轨迹部分详细描述了运行的逐步过程，包括每次LLM调用和按顺序排列的图状态（如计划、总结等）。接下来是智能体PIR处理机制，这一点至关重要。因为在开发过程中，查询中可能会意外包含敏感信息或API密钥等秘密数据。

我们建立了一个框架来定义不同类型的数据及其严重程度等级。如果数据的严重性超过90%，系统将立即拦截并脱敏这些秘密信息，确保它们绝不会进入LLM模型、内存数据库或跟踪评估表及追踪系统。目标是在数据被摄入的瞬间就阻止敏感信息泄露，即用户在输入时即刻生效。

最后一个框架是关于上下文优化器，这是我最喜欢的领域之一。当提交大量查询或上传许多文件时，确保节省Token至关重要。我们构建了上下文优化器框架，在数据发送给LLM之前对其进行塑造和修剪。

在修剪系统中，我们根据Token限制选择有效载荷，然后重新排序以识别最相关的信息。接着去除重复项，创建独特且精心策划的数据集作为LLM的主要输入数据，最后在大载荷进入LLM之前对其进行压缩。

让我们看一个快速演示：假设我提交第一个查询“在JFrog Artifactory中查找所有工件”。此时尚无数据。一旦提交并刷新，记录便会生成，显示该查询使用了24,000个Token。为了展示效果，我将在后台启用上下文优化器并重新运行完全相同的查询。

再次刷新运行时可以看到，对于同样的查询，此次仅使用了2,400个Token。这意味着几乎节省了90%的开销。我也可以在Slack机器人上重演此演示，询问其“告诉我Artifactory中所有仓库里的Docker镜像”。

初始运行未启用优化器时，记录显示使用了约24,000个Token。随后我在后台开启优化器并重新运行相同的Slack查询，结果显示仅使用了约1,500个Token，同样实现了近90%的节省。在大多数情况下，我们能获得70%到78%的Token节约。

想象一下，如果您有数千个智能体每天运行大量查询，使用此框架能节省多少Token。因此，关键要点在于：我们要构建企业级框架，而不仅仅是开发一个智能体。确保底层具备完整的支撑体系，不要急于快速构建和部署某个智能体而忽视整体框架的完整性。

其次，必须确保拥有适当的网关系统。无论是本地操作还是通过智能体发起的工具调用请求，都必须经过中央化的MCP网关。在到达MCP服务器之前，必须确保身份验证已通过。同时，要确保您的MCP服务器能够控制应使用哪些工具。

为了执行特定的查询，对吧？并确保为该工具的执行设置了监控和完整的审计。当然，你应该始终保持“人在回路”的流程，针对每一个行动项、每一项高风险项目都要如此。确保具备可观测性，并且审计必须到位。最后但同样重要的是，要确保上下文优化器始终存在，以证明你在智能体上的成本合理性。

我想分享的是，我最近在亚马逊上发布了我的 MCP 书籍。欢迎免费下载，Kindle 版免费，也有纸质书版本。好了，非常感谢大家观看这个视频。如果你有任何问题，欢迎通过 LinkedIn 或 Twitter 联系我，我很乐意解答。再次感谢。