多租户才是智能体平台面临的真正问题

大多数智能体演示之所以有效，是因为它们只有一个用户。

一个用户意味着一个存储库、一套工具集和一条“快乐路径”（happy path）。没有什么需要隔离的。

当你将演示转化为平台时，难点不在于提示词（prompts）。难点在于隔离。

每一个数据库查询、缓存键、流、工具调用和内存查找，能否证明它属于哪个租户？如果哪怕有一个做不到，数据泄露的风险就近在眼前。

许多团队专注于模型选择或内存质量，却忘记询问一个租户的数据和成本是否与另一个租户隔离开来。

隔离不是最后才添加的任务，它决定了你平台的架构形态。

要构建一个真正的智能体平台，需要具备以下机制：

• 携带进入图（graph）的有类型请求上下文（typed request context）。
• 在每个边界实现作用域访问控制（scoped access）。
• 在租户泄露演变成事故之前就能将其捕获的测试。

单用户智能体在忽视安全性的情况下可能看起来很惊艳。它可能会在没有租户过滤的情况下调用搜索工具，或者使用简单的 ID 存储历史记录。这在演示中可行，但在平台中会失败。

在平台中，智能体必须在每一步都携带边界。如果智能体丢失了该边界，它可能会给错误的人提供完美的答案。这就是失败。

在模型执行之前，每一个涉及数据、工具或内存的操作都必须按租户进行作用域划分。这是应用于智能体运行时的标准后端安全实践。

架构设计的实践步骤：

• 使用单一的 RequestContext 对象，而不是松散的参数。
• 让每个边界要么接受上下文，要么直接失败。
• 在模型看到工具目录之前对其进行过滤。
• 将向量过滤（vector filtering）作为授权的强制组成部分。
• 确保追踪（traces）和日志使用不透明的租户标签，而非敏感数据。

不要让模型替你记住租户。模型可以对数据进行推理，但不应由它来决定谁拥有这些数据。

让“作用域路径”成为最容易实现的路径。如果你围绕单用户模型构建平台，那么在第一个真正的企业客户加入的那天，你将面临彻底重写的局面。

从追踪一个智能体流程开始。跟随租户上下文从 HTTP 请求一直到最后的工具调用。标记出每一个上下文被复制或丢失的地方。那个映射图就是你真实风险所在。

Source: https://dev.to/luffy_14/multi-tenancy-is-the-real-agent-platform-problem-1dh2

Optional learning community: https://t.me/GyaanSetuAi