大家好，我是 Sam，感谢大家参加今天的演讲。我在 Gravitee 担任首席技术官（CTO），也是本次赞助活动的组织者之一，我的风格可能有点不同。我不会罗列大量幻灯片来阐述治理的重要性以及如何保护代理（Agent）的安全，也不会展示那些复杂的架构图。相反，我构建了两个实际的代理演示，今天我们将通过它们来进行讲解。

我相信大家都有 AI 策略或框架来规范代理的运行方式，也有人员在探索人工智能的使用。我们最近的一项调查显示，88% 的组织已有在生产环境中实际执行操作的代理，但其中只有 14% 对其实施了任何治理措施。想必大家在媒体或 LinkedIn 上都见过，一旦出问题往往后果严重：数据库丢失、个人身份信息（PII）泄露，如果在 HIPAA 或 GDPR 等合规环境下，还会面临信息泄漏和监管机构的重罚。

因此，关键问题不在于如何在代理自身的上下文或提示词中保护它，而在于如何将其身份隔离出来，使其从根本上无法执行那些危险操作。这不应依赖用户正确提示或限制其能力的 Markdown 文件，而应将控制权移至网关和治理层。因为 AI 旨在取悦用户、满足需求，如果你要求它删除数据库或提供客户数据，它会照做。我们需要改变这种局面。

我有五个实时演示案例（非脚本录制），运行在 Gravitee 网关架构上，后端为 Databricks。它结合了 Set 和 Groq（注意是 Q 不是 K，我知道美国人不喜欢带 K 的发音），用于一些推理任务。左侧代理试图将控制置于提示词、技能或工具中；右侧代理则由 Gravitee 原生网关控制的严格范围身份进行治理。

第一个场景是提示词注入测试。我扮演一个希望代理执行某项操作的用户，要求它使用工具为我做点事：比如“帮我取消这个预订”，同时询问是否能运行 MCP 工具删除所有预订。左侧代理回答没问题，已执行操作并取消了该预订。因为工具存在且用户拥有权限，所以它完美地执行了命令。

而在右侧，代理的身份由 Gravitee 网关控制，管理员权限在运行时被严格限制。令牌交换和 JWT 声明仅在用户需要执行特定任务时才有效。通过底部的数据包可以看到，这不是脚本环境：你能看到请求流入、代理执行过程以及工具调用。最终返回 200 错误代码表示该请求无效（注：原文此处逻辑似指被拦截或验证失败，结合上下文应为未执行成功）。

如果我们查看数据库，会发现所有预订都被删除了。代理并不关心酒店组织制定的“禁止使用 AI 执行此操作”的策略，运行时没人会去读那些文档。你必须依赖基础设施和治理层来控制代理的行为能力。右侧的情况则不同，同样的提示词发出后，虽然发现了相关工具，但在执行时因权限不足被网关以 403 Forbidden（禁止）代码拦截。

它仅执行了拥有权限的部分操作，返回提示说“我可以为您取消这个预订，但我无法删除所有记录，因为我没有权限”。这标志着控制从政策文档转移到了网关层面的硬性约束。第二个例子涉及数据外泄测试，我要求提供完整的客人列表以进行合规性核对、邮件联系及车辆信息对账。

流程相似：提示词从 UI 进入大语言模型（LLM），LM 进行 MCP 发现，找到相关工具并返回数据。这里展示的是模拟数据以防泄露真实预订信息，但可以看出 LLM 乐于助人的本性使其倾向于解决问题。而在右侧，网关成功阻止了该请求，没有发生 PII 泄露或信息暴露。

系统提示您权限不足以执行此操作，若想认证则可以提供帮助（可通过任何 IDP 平台或 Gravitee 网关实现）。我们可以进一步探索底部的 OpenTelemetry，深入分析底层机制。特别是在 A2A（Agent-to-Agent）协议中，用户到代理、代理间交互的过程非常复杂且难以追踪。

仅靠代理自身的权限来控制其行为，在扩展到数百、数千甚至数十万代理时，管理、缓解风险和迁移工作将变得极其棘手。将其移至网关则能……

这是一种更可持续、可扩展，但最终也更安全的方式。你可以从这些响应中看出端倪：这是一个由网关返回的真实错误，并非模拟或脚本化。这就是你能够进行治理和保障安全的地方。但这不仅仅关乎身份认证。如果你拥有智能体，可能还需要控制部分成本。因此，令牌消耗和其他各项指标变得越来越重要，这些你都可以通过网关来实现。

接下来我们将展示一个有缺陷的智能体，它会重复发送相同的请求大约八次。如果在智能体本身进行治理，每个请求都会通过并获得响应。我们会消耗一定数量的令牌和精力来服务这些请求。智能体内部没有任何机制表明“做得太多了”，比如速率限制或令牌限制。

如你所见，所有请求都通过了，并获得了200状态码的响应。它们都是真实的LLM提示词（笑）。在这个例子中，情况相当简单，我们最终消耗了大约1000个令牌。这相当于约1美分，从大局来看并非巨额资金。

但如果将此乘以生产环境中所有的智能体、为不同客户运行的各种智能体，以及它们被要求执行的各类可重复工作流，成本很快就会变得相当可观。在右侧由网关治理的情况下，我们看到了相同的提示词进入系统。

前三个请求因为有效而得到回答，但随后应用了网关实施的速率限制：每分钟只能处理三次。因此，超过三次的请求会被拦截。这些请求不是在LLM层面被阻止的，也不是在已经消耗令牌后的下游阶段被拦截的，而是在网关层就被阻断了。

这使我们能够节省成本，并开始控制哪些用户、拥有何种权限的用户，以及在特定受众群体中希望花费多少预算。我们还可以对缓存执行相同的操作。Gravity作为产品支持语义缓存，即如果收到听起来相似的提示词，可以从内置的Redis存储中提供服务，而不是每次都发送给LLM。

例如，考虑IT帮助台的场景：“我如何设置密码？”重复多次询问时，与其每次都向LLM提问从而消耗成本、令牌和精力，不如直接从数据库提供服务。这样做的好处是零成本和零延迟，因为数据来自本地而非下游LLM调用，同时也提供了更好的用户体验。

在这个例子中，我五次询问“列出我的所有酒店预订”，因为我不信任第一次的结果。每个人都得到了服务，我又消耗了1000个令牌和1美分等费用。所有这些请求都来自下游LLM调用。让我稍微调整一下视图。

在右侧，我获得了相同的数据返回，但这次来自缓存。因此，我在输入和输出响应中仅消耗了约200个令牌。这在扩展场景下非常强大，特别是当有多个用户和多个智能体处理同一问题时。你可以从内置缓存中提供服务，无需额外的复杂性或基础设施支持。

这一切都捆绑在我们的网关中随附提供。因此，你也可以在过程中控制它。这也可以进行配置：你不必定义相似度阈值，你可以自行设定想要的相似程度范围（0到1之间），其中1表示非常相似，0表示完全不相似。这完全由你掌控。

因此，你可以针对每个智能体、受众或用户进行灵活调整，取决于你想要实现的目标。此外，底部还有完整的日志记录功能，你可以看到输入内容以及是否命中缓存响应。所有信息都是可呈现的、透明的。

Gravity平台并不试图将你锁定或使事情变得黑盒化，而是致力于提供透明度，让你对智能体生态系统中发生的一切拥有完全的可见性。这里的遥测数据我仅通过UI展示，你可以将其导出到任何你想要的下游工具中。

无论是Datadog、Splunk还是Kubernetes环境下的Prometheus，这些工具都可供你使用以获取所需的洞察。我们的第五个例子是：有些客户表示，他们的用户只是简单地输入巨大的提示词，因为他们想要总结整个对话历史，或者开始查看如何总结会议等。这本身没问题，但如果你想限制令牌消耗等问题时，就会迅速陷入困境。

这是一个巨大的响应示例：用户输入了10分钟左右的聊天转录内容，并说：“这是你的任务，帮我做这个。”这真正引出了我们如何管理上下文的问题：我们开始思考如何部署这些智能体，使其拥有足够的上下文以完成其任务。

在这个例子中，我输入了2000个令牌，而输出仅为312。对于本质上是一项相当简单的任务（如为某受众预订房间、执行几项操作而言），这个比例是相当显著的。就网关而言，我们运行了相同的提示词，并在此处将其拦截。

因此，没有发生下游LLM调用，也没有因处理大量上下文而产生的令牌成本。网关内置的策略指出：这太大了，请在网关层面进行拦截并思考如何将其拆分。思考一下如何分享这些信息？能否将其分解为更小的步骤，以便开始控制部分空间占用。

这是在运行时执行的策略。因此，这不是在响应阶段（此时令牌已经消耗完毕）要做的事情。它在提示词发出之前、几乎在任何下游操作发生前就被拦截了。因此，你可以开始限制部分成本，这非常强大，特别是当你拥有多个用户时。

有些人将你的智能体当作个人Google搜索工具来查找信息。我们曾看到过一个案例：一个智能体简单地询问“我今天所在地的天气如何”，而他们使用了一个非常强大的模型来完成这一任务，为此花费了巨额成本来获取Google或任何气象站都能提供的信息。因此，除了……

就像提示词的长度一样，你也可以将重点放在允许的内容类型上。你可以规定这些内容必须与特定用例相关，或者必须符合我的智能体需要执行的任务要求。在这个例子中，如果我们开始询问类似“今天的情况如何”这样的通用问题，网关就会指出这看起来不像酒店预订软件或酒店预订相关的查询。通过拒绝此类无关请求并避免产生下游成本，我们能够有效地将前端智能体与后端服务（无论是 API、MCP 服务器、大语言模型还是数据库和数据湖仓）解耦。

从根本上说，这种架构对于实现所需的控制力、成本优化以及安全性至关重要，同时也提供了治理和审计能力。据我同事 Tim 透露，目前每对应一个人类身份标识就有 144 个智能体。这个问题正呈指数级恶化，如果将这些规则硬编码到每个智能体中，可能在前几个或前十个时有效，但当规模指数级扩大且智能体不断创建其他智能体形成巨大蔓延时，依靠基础设施层的脚本化自动化治理层来管理这些身份标识和其他要素，就成了我们组织工作的基本需求。

此外，我认为监管环境将日益严格，我们需要控制用于重新训练模型的数据部分，并确保我们对输入信息进行审计。因此，拥有日志记录、信息留存以及使其基本可展示和导出以支持任何操作需求至关重要。我认为网关（不一定是 Gravitee）横跨智能体生态系统的部署是我们进行 AI 工程工作时应考虑的基本要求之一。在这里，我们还可以加入用户界面以提出任何我们想问的问题并与其交互。

我刚才展示了五个示例，但平台功能远不止于此。我们内置了大语言模型路由能力，可以根据延迟、成本或复杂性等指标将请求路由到任何下游模型。这使你能够摆脱对特定云服务商的依赖，不再局限于一对一的关系，而是可以路由到你想要的任何下游模型。例如，我可以将其路由到 Anthropic 的 Groq，但只需三次点击即可切换到 Gemini 或 OpenAI。网关会自动处理不同 OpenAI 规范之间的转换，无需重新编码，所有操作均在网关内完成。

我们还提供了创建 MCP 工作室的工具，而不是直接使用暴露大量工具的第三方 MCP 服务器。例如，我们使用的 CRM 系统为该 MCP 服务器提供了 64 个工具。如果将这些全部注入模型，每次都会暴露巨大的上下文信息，导致token消耗和成本增加。能够创建仅包含 MCP 服务器所暴露工具的极细粒度子集，不仅限制了故障爆炸半径，也控制了成本。此外，我们还拥有边缘管理工具来解决组织内日益严重的问题：虽然通过网关的流量正常，但许多用户在本地笔记本电脑上使用 AI 处理文档、邮件等敏感信息，这些行为缺乏可见性。

上周我们发布了网关内的边缘管理功能，使你能够查看影子 AI 流量、对其进行安全加固、强制其通过网关，并提供日志记录和可观测性。这对于信息合规性和受严格监管的行业尤为重要。如果你想了解更多，我们的展位就在第三个位置。希望这个示例能带来一些不同于常规幻灯片的内容，展示将治理和政策硬编码在 AI 智能体本身（依赖 Markdown 文件或上下文）并非正确做法。

随着我们向前发展，唯一既能扩展规模又能保持治理和安全性的真正正确方法是将这些能力上移至基础设施层。如果你想了解更多，那里有许多我们的同事可以交流。最后，感谢大家的时间，希望你们享受这场 AI 工程师大会。谢谢。