多用戶智能體需要細粒度上下文控制
Multiplayer agents need fine-grained context
Mastra 以 Fine-Grained Context(FGC)描述多用戶智能體按用戶權限及對話參與者,控制特定互動可使用上下文的設計概念。FGC 目前仍是設計概念;文章建議結合細粒度授權、分範圍記憶、processors 和工具 payload 控制,並在權限或參與者變動時重新檢查上下文。文章以日曆私隱資料可能經工具結果或記憶洩露為例,並建議測試跨用戶及對話的權限邊界。
We've been pondering this concept of Fine-Grained Context (FGC) in internal conversations for a few weeks now, so I wanted to put it in writing here.
It comes from multiple discussions with our clients in multiplayer agent environments, when you have multiple users interacting with the same agent, like in Slack, with shared conversations.
For example, last week a client asked me:
“How do we ensure that the context is correct for multiplayer agents when we have users with different authorization levels interacting with the same agent?”
And that’s where FGC comes in.
So what is Fine-Grained Context?
We use FGC to describe control over the context an agent may use for a particular user and conversation in a multiplayer environment. Those controls cover source data and the information derived from it.
At the user level, the same agent should adapt to each user's authorization level, using the information they are permitted to see.
At the conversation level, the agent should take into account who has access to the conversation and not leak any information users without access are not supposed to see.
For example, a finance employee may have permission to view a draft budget privately, but that doesn’t mean they should be able to ask an agent to share details from it in a group chat with employees who don’t have access.
Their permission to read the budget does not authorize sharing it with everyone there.
How FGC builds on fine-grained authorization
Fine-grained authorization checks whether a user or agent can perform an action on a particular resource.
FGC applies these permissions when assembling context. It covers retrieved information, tool results, conversation history, and memory. It also accounts for who will access the conversation.
Each model call receives context selected for that interaction. You need to repeat the checks when new tool results arrive, permissions change, or when new users with different permissions join the multiplayer session.
Permissions need to follow information
Now imagine you privately ask your company agent to schedule a meeting. The agent reads your calendar and finds a private "Medical Appointment" event overlapping and answers with a quick explanation telling you that you already have a medical appointment at this time and cannot schedule it.
Later, you and a co-worker who can only see your availability (and cannot see any details about your medical appointment) continue scheduling in a shared conversation.
If the company agent keeps the calendar tool result in its context, it can reveal details in the conversation without another calendar tool call.
The information about the medical appointment may even be recorded in a stored memory, so even removing the initial answer from the context might leave the information exposed in the shared context with the wrong design.
How to implement FGC with Mastra
Today FGC is a design concept. You can build FGC in multiplayer environments using Fine-Grained Authorization, well-defined memory scopes, and by implementing context checks when needed.
We might add it as a primitive in the future, but for now, here is how you can build multiplayer agents with Fine-Grained Context in Mastra.
Scope context to the requester and audience
Start with verified identities and permissions. Establish who made the request, whose authority permits each operation, and who will receive the answer.
We provide fine-grained authorization through our Enterprise Edition to check access to resources. When using our APIs for stored records, also configure which records each user may access.
Use those permissions to decide what enters each model call. Our processors let you filter context before the model receives it. For shared answers, start with information every recipient is allowed to access.
Our tool payload transforms let you shape model, browser, and transcript payloads separately so you can apply the sharing policy to each destination.
Keeping private and shared memory separate for multi-player agents
Memory scopes organize where memories are stored and recalled. Your application must map thread and resource identifiers to its access rules.
Our guide to multi-user threads shows how to preserve speaker attribution in shared conversations.
Store source references and permissions with context records. Preserve those links in summaries and recalled memories so your application can recheck access later.
Build shared summaries from inputs already authorized for their audience. This avoids relying on a summarizer to remove every private detail.
Recheck context when the audience changes
Check permissions for each request and whenever the destination or participants change. Permission revocation also needs to trigger a check.
Before releasing a late tool result or continuing a response stream, confirm that it is still permitted for the current audience. You may need to stop the run and rebuild its context.
Apply these checks to model input, visible history, and tool payloads.
Build allowed context before optimizing cache reuse. Cached answers and summaries also need access checks.
Test across users and conversations
Test cases where context could cross a permission boundary:
- Two people ask the same question with different permissions.
- An authorized user continues a private discussion in a shared conversation.
- A private fact survives a memory summary and is recalled later.
- A participant or permission changes during a tool call.
Our multi-turn evals can help test these conversations and catch regressions. They complement the access checks your application enforces at runtime.
Inspect model input, tool payloads, visible history, and answers. Check for paraphrases that expose private facts. Also test that permitted availability and shared project decisions remain usable after private context is excluded.
Get started designing fine-grained context
Multiplayer agents need context that understands who is asking, who is listening, and what each person is allowed to know.
You can build that pattern in Mastra today using fine-grained authorization, scoped memory, processors, and tool payload controls. Start with the Mastra Slack Agent template and adapt it for your own multiplayer agent.
來源:Mastra Blog · mastra.ai