Speedle AI · 模式

构建与运行 AI 的策略模式

从模型上线前的构建阶段,到模型服务与执行操作的运行阶段,Speedle 策略引擎都能管理 AI 系统对数据、模型、工具和其他智能体的访问。这里介绍的是解决方案模式,不是任何机器学习或智能体平台的已发布集成。

以下 SPDL 示例都用 Speedle 文件存储解析并评估过,覆盖允许和拒绝两种用例。名称、路径和属性仅作示例,实际由应用在请求决策时传入。策略执行点必须传入条件引用的所有属性。

构建

模型上线前:数据、训练与发布

01 / 数据与训练

哪些流水线能用哪些数据训练?

训练任务要读数据集、用算力、写检查点。每次读取数据集、启动任务或导出检查点前,应用都会先请求授权,并传入数据敏感度、租户、同意状态和区域等属性。

主体
训练流水线(实体)、机器学习工程师及其团队。
资源与操作
数据集:read。训练任务:start。检查点:export。
策略执行点
数据加载器打开数据集前、任务调度器分配算力前,以及制品库导出前。
training.spdlSPDL 示例
[service.ml-training]
[policy]
# Pipelines read only consented data from their own region
grant role training-pipeline read expr:^/datasets/ if consent == true && data_region == job_region
# Restricted datasets never enter training
deny role training-pipeline read expr:^/datasets/restricted/
grant role ml-engineer start /jobs/training if gpu_hours <= 64
grant role ml-engineer export expr:^/checkpoints/
[rolepolicy]
grant entity pipeline-churn training-pipeline
grant group ml-team ml-engineer

逐数据集检查同意状态和区域,直接拒绝受限数据;启动任务时还会检查 GPU 小时数上限。

02 / 模型发布

谁可以发布模型?

模型注册、审批、晋升和回滚分开授权,各由不同角色负责。职责分离后,训练模型的人不能审批同一个模型。

主体
机器学习工程师、发布经理和发布流水线的服务身份。
资源与操作
模型和端点:register、approve、promote、rollback。
策略执行点
模型注册表和发布流水线会在每次更改模型或端点状态前检查。
release.spdlSPDL 示例
[service.model-registry]
[policy]
grant role ml-engineer register expr:^/models/
grant role release-manager approve, promote, rollback expr:^/models/
# Separation of duties: nobody approves a model they trained
deny role release-manager approve expr:^/models/ if trained_by == request_user
[rolepolicy]
grant group ml-team ml-engineer
grant user dana release-manager

工程师可以注册,但不能晋升模型;trained_by 与请求用户相同时,发布经理不能审批该模型。

运行

AI 运行:检索与各类调用

03 / 推理与 RAG

提示词只放用户可读内容

用户、应用和租户都会调用模型。要实现权限感知的 RAG(检索增强生成),检索器会在内容进入提示词前,逐文档或逐集合向 Speedle 请求授权,让模型只看到请求用户有权阅读的内容。

  1. 1检索器查找候选文档。
  2. 2检索器带上用户的租户和许可级别,逐文档或逐集合向 Speedle 请求授权。
  3. 3获准内容才能进入提示词。
主体
发起请求的用户及其用户组;客户端应用和租户作为实体。
资源与操作
集合和文档:retrieve。模型:invoke。
策略执行点
检索器在文档进入提示词前检查;API 网关或推理服务在路由请求前检查。
rag.spdlSPDL 示例
[service.rag]
[policy]
# The retriever asks per document, before its content enters the prompt
grant role tenant-user retrieve expr:^/collections/ if doc_tenant == user_tenant && doc_label in user_clearances
# Documents on legal hold never reach a prompt
deny role tenant-user retrieve expr:^/collections/legal-hold/
# Apps call only the model tiers in their tenant's plan
grant role tenant-app invoke expr:^/models/ if model_tier in plan_tiers
[rolepolicy]
grant group acme-staff tenant-user
grant entity acme-helpdesk tenant-app

只有文档属于用户所在租户、标签也在用户许可范围内,才允许检索;法律保全文档直接拒绝,应用也只能调用套餐内的模型层级。

04 / 智能体代用户操作

AI 智能体能代用户做什么?

智能体有自己的身份;用户的委托由签名的委托令牌证明,而不是靠请求里的声明。策略执行点先验证令牌,再向 Speedle 查询两次,两次都通过才放行:一次查智能体是否在令牌范围内,一次查委托用户此刻本人是否有这项权限。令牌签发后,用户一旦失去某项权限,智能体在下一次请求时也会随之失去。超过 100 的退款还需要一条由用户以外的人做出的审批记录。

  1. 1验证令牌:签名、签发方、有效期,以及令牌是否签发给这个智能体。
  2. 2智能体范围:以智能体为主体查询 Speedle,令牌范围作为属性传入。
  3. 3委托用户当下的权限:以令牌 sub 声明中的用户为主体查询 Speedle。
主体
范围检查以智能体(实体)为主体;第二次检查以委托用户为主体,用户取自已验证的令牌。
资源与操作
工单:read、update;订单:refund,金额作为属性传入。都仅限令牌范围内的操作和资源。
策略执行点
智能体运行时或应用后端在操作到达业务系统前检查。它负责验证令牌,只把验证过的声明传给 Speedle。
人工审批
策略执行点验证这笔退款的签名审批记录,并在第二次检查中把审批人作为 approved_by 传入。审批人不能是用户本人。
自托管选项
也可以只查一次,由自定义函数 DelegationValid 和 DelegatorAllowed 评估令牌和委托用户。Speedle Cloud 不支持自定义函数。
agents.spdlSPDL 示例
[service.crm]
[policy]
# Check 1: the agent, only while its verified token covers the request
grant role in-scope read, update expr:^/tickets/
grant role in-scope refund expr:^/orders/
# Check 2: the delegating user (the token's sub), with their roles now
grant role support read, update expr:^/tickets/
grant role support refund expr:^/orders/ if amount <= 100
# Larger refunds: a verified approval by someone other than the user
grant role support refund expr:^/orders/ if approved_by != request_user
[rolepolicy]
# Check 1 in three steps, each role needing the one before:
# the token has not expired,
grant entity triage-agent in-time if request_time < token_expires
# it lists this action,
grant role in-time in-action if request_action in token_actions
# and it lists this resource
grant role in-action in-scope if request_resource in token_resources
# Check 2: the user's own role
grant user alice support

检查 1 分三步授予智能体角色,所以只在令牌过期前、且只对令牌列出的操作和资源成立。检查 2 只看用户本人,所以撤销用户的角色后,智能体在下一次请求时就会被拒绝。超过 100 的退款只有在审批人不是用户本人时才能通过检查 2。

GitHub 上两种模式的可运行示例

05 / 工具调用(MCP)

MCP 工具能这样调用吗?

每次调用工具,都要先检查再执行。工具是资源,调用是操作,参数则变成属性,退款金额上限等规则就能直接写进策略。

主体
每个智能体都有独立的实体身份和角色,权限可以按智能体、按工具分别控制。
资源与操作
工具:call,工具参数作为属性。
策略执行点
MCP 客户端宿主,或 MCP 服务器前的网关,在工具执行前检查。
mcp.spdlSPDL 示例
[service.mcp-gateway]
[policy]
# Tool arguments arrive as attributes and are checked before the tool runs
grant role research-agent call /tools/web-search
grant role billing-agent call /tools/issue-refund if amount <= 100 && customer_verified == true
# Admin tools stay out of reach for research agents
deny role research-agent call expr:^/tools/admin/
[rolepolicy]
grant entity agent-research-1 research-agent
grant entity agent-billing-1 billing-agent

研究智能体可以用网页搜索,但不能用管理工具;计费智能体只能为已验证客户办理不超过 100 的退款。

06 / 智能体间调用(A2A)

A2A 授权:谁能调用谁?

委托链每一跳都要检查。接收方只能拿到调用方已有的权限范围,跳数也有上限,因此每次委托都只会收窄权限。

主体
调用方智能体,以实体标识。
资源与操作
其他智能体及其技能:call。属性包括请求权限范围、调用方权限范围和跳数。
策略执行点
调用方发送任务前,或接收方接受任务前,由对应的智能体检查。应用根据收到的委托确定调用方的权限范围。
a2a.spdlSPDL 示例
[service.a2a]
[policy]
# A callee gets only scopes the caller already holds, within two hops
grant role planner-agent call /agents/researcher if IsSubSet(requested_scopes, caller_scopes) && hops <= 2
grant role researcher-agent call /agents/writer if IsSubSet(requested_scopes, caller_scopes) && hops <= 2
[rolepolicy]
grant entity planner-1 planner-agent
grant entity researcher-1 researcher-agent

IsSubSet 会拒绝调用方没有的请求权限范围,第三跳同样不允许。

07 / 零常驻权限 · 自托管

即时令牌支撑零常驻权限模式

签发和管控到位时,即时签发、短期有效、范围受限的授权凭证,结合 Speedle 的策略决策和应用侧执行控制,可以构建零常驻权限模式。示例检查有效期、生效时间和令牌状态;生产环境还需要可信组件验证令牌,把声明绑定到主体、资源、操作和任务范围,并原子消费单次使用的凭证。

zsp.spdlSPDL 示例
[service.zsp]
[policy]
# A just-in-time token: positive lifetime up to 600 s, inside its validity window, unused
# request_time defaults to the ADS clock; attributes passed by the enforcement point take precedence
# 60 s is the explicit clock-skew allowance
grant role agent-runtime invoke /api/orders if expires_at > issued_at && expires_at - issued_at <= 600 && issued_at <= request_time + 60 && not_before <= request_time + 60 && request_time < expires_at && TokenUnused(token_id)
[rolepolicy]
grant entity agent-billing-1 agent-runtime

GitHub 上的完整可运行示例

第一部分计划中

AI 风险检测的目标流程

该方案正在探索和构建,尚未发布。它在确定性策略决策之上增加审查,风险信号不能把策略的拒绝改成允许。

目标流程示意

策略先行,风险后查

计划中
  1. 01 / 请求

    明确操作

    请求包含智能体、用户、数据、操作和任务上下文。

    执行前
  2. 02 / 策略决策

    策略划定边界

    策略给出明确结果:拒绝就停在这里,允许才能继续。

    否决权 · 拒绝不可推翻
  3. 03 / AI 风险信号

    排查更多关联

    正在构建的方案会从更多维度和关联中发现其他风险。

    计划中
  4. 04 / 最终决策

    只增强防护,不增加权限

    风险信号可加强审查或防护;策略结果和否决权始终不变。

    策略否决权不变

风险信号不能把策略的拒绝改成允许。此图仅示意正在构建的方案,AI 风险检测尚未发布。

返回 Speedle AI 中文首页