AI Agent 从单个实验走向企业级部署后，难点往往不再是模型能否调用工具，而是能否回答三个问题：这次操作代表谁、经过了哪些委托、最终由谁承担责任。AWS 发布的开源参考平台 Loom，围绕这些治理问题给出了一套可研究和改造的实现：它基于 Strands Agents 与 Amazon Bedrock AgentCore Runtime，通过 RFC 8693 Token Exchange 传递身份，使用配置驱动部署，并要求资源携带标签。
需要先划清边界：Loom 是 AWS Labs 中的开源参考平台，不是 AWS 托管服务。团队需要自行评估、部署、维护和加固，不能把“参考实现”直接等同于生产级控制平面。
Agent 链条不能只剩一个服务账号
传统后端通常可以用“用户调用 API，API 使用服务身份访问下游”来描述。但 Agent 会把链条拉长：用户委托协调 Agent，协调 Agent 再委托专业 Agent，专业 Agent 最终调用数据库、工单系统或云 API。
如果整条链最终都表现为同一个高权限运行时身份，审计日志只能说明“Agent 服务执行了操作”，却无法可靠回答：
- 哪个用户发起了任务；
- 哪个 Agent 接受了用户委托；
- 中间是否发生了二次委托；
- 当前 Agent 获得了什么范围和期限的权限。
Loom 采用 RFC 8693 Token Exchange 处理这类身份传播。核心思想不是把用户 Token 原样传到所有下游，而是用已有 Token 交换一个面向特定资源、权限更窄、有效期更短的新 Token，并保留委托参与者的信息。
一次典型链路可以抽象为：
User -> Orchestrator Agent -> Billing Agent -> Billing API
actor=A actor=B audience=billing-api
这样，资源服务器既能识别任务所代表的主体，也能知道当前代表主体执行操作的参与者。实现授权时，应同时检查主体、参与者、受众、权限范围和有效期，而不是看到一个合法签名就放行。
可以这样实践 Token Exchange
下面是符合 RFC 8693 形式的通用请求示例。它用于说明 Loom 所采用的身份委托模式，不代表 Loom 或 AWS 某个端点的固定地址。运行前需要替换 Token 服务地址、客户端凭据、主体 Token、参与者 Token和目标受众。
export TOKEN_ENDPOINT="https://identity.example.com/oauth2/token"
export CLIENT_ID="agent-orchestrator"
export CLIENT_SECRET="replace-me"
export SUBJECT_TOKEN="user-access-token"
export ACTOR_TOKEN="orchestrator-agent-token"
curl --fail-with-body \
--request POST "$TOKEN_ENDPOINT" \
--user "$CLIENT_ID:$CLIENT_SECRET" \
--header "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
--data-urlencode "subject_token=$SUBJECT_TOKEN" \
--data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
--data-urlencode "actor_token=$ACTOR_TOKEN" \
--data-urlencode "actor_token_type=urn:ietf:params:oauth:token-type:access_token" \
--data-urlencode "audience=https://billing.internal.example.com" \
--data-urlencode "scope=billing.invoice.read"
一个兼容实现通常会返回新的访问 Token：
{
"access_token": "exchanged-access-token",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
"token_type": "Bearer",
"expires_in": 300,
"scope": "billing.invoice.read"
}
生产环境还要补齐几项约束：Token 不应写入 Agent 对话记录或调试日志；受众必须绑定具体下游；权限范围应按工具收窄；Token 生命周期应短于 Agent 任务；资源服务器必须校验委托链，而不能只依赖上游完成验证。
配置驱动部署，减少运行时的不确定性
Loom 强调配置驱动部署，并避免在运行时生成代码。这一点对 Agent 平台尤其重要：如果 Agent 可以临时拼接并执行基础设施代码，安全审查、变更追踪和部署复现都会变得困难。
配置驱动并不意味着配置天然安全。它的价值是把 Agent、运行时、权限、标签等输入变成可审查的声明，并让 CI/CD 在部署前执行 Schema 校验、策略检查和审批。
由于摘要没有给出 Loom 的具体配置 Schema，下面是一个可改造的示意文件，不应视为项目原生格式：
# loom-agent.example.yaml
# 假设性示例：字段需要映射到实际仓库提供的配置格式。
apiVersion: platform.example/v1
kind: GovernedAgent
metadata:
name: billing-reader
tags:
owner: finance-platform
environment: production
data-classification: confidential
cost-center: cc-1042
spec:
runtime: bedrock-agentcore
framework: strands-agents
identity:
tokenExchange: true
audience: https://billing.internal.example.com
scopes:
- billing.invoice.read
deployment:
runtimeCodeGeneration: false
可以在流水线中先用 yq 实施最小标签门禁：
#!/usr/bin/env bash
set -euo pipefail
file="${1:-loom-agent.example.yaml}"
required_tags=(owner environment data-classification cost-center)
for tag in "${required_tags[@]}"; do
value="$(yq -r ".metadata.tags.\"${tag}\" // \"\"" "$file")"
if [[ -z "$value" ]]; then
printf 'missing mandatory tag: %s\n' "$tag" >&2
exit 1
fi
done
if [[ "$(yq -r '.spec.deployment.runtimeCodeGeneration' "$file")" != "false" ]]; then
printf 'runtimeCodeGeneration must be false\n' >&2
exit 1
fi
printf 'governance checks passed: %s\n' "$file"
运行方式：
chmod +x validate-agent.sh
./validate-agent.sh loom-agent.example.yaml
真实项目还应使用 JSON Schema、Open Policy Agent、Conftest 或云资源策略执行结构化校验，避免只靠 shell 脚本覆盖复杂规则。
强制标签不是资产装饰
标签只有在强制执行并被后续系统消费时才具备治理价值。对 Agent 平台而言，标签至少可以连接四类控制：
- 资产归属：明确负责团队与升级联系人；
- 成本归集：区分环境、业务单元和成本中心；
- 数据治理：标记 Agent 可接触的数据等级；
- 策略执行：按环境或分类限制模型、工具与网络出口。
“标签存在”仍然不够。例如，owner: unknown 虽然通过非空校验，却不能支持事故响应。企业落地时应建立允许值、格式、负责人目录和生命周期规则，并在资源创建入口统一阻断不合规部署。
采用前的工程检查
Loom 更适合作为治理架构样板和实验基础，而不是开箱即用的托管产品。评估时可以按下面的顺序推进：
- 先画出用户、Agent、工具和资源服务器之间的委托链，确认每一跳需要保留哪些身份信息。
- 用一个只读 Agent 验证 Token Exchange，检查受众、权限范围、过期时间和审计记录。
- 将 Agent 声明纳入版本控制，在 CI 中校验配置与强制标签，禁止部署阶段动态生成并执行代码。
- 验证撤销、超时、下游拒绝和身份服务不可用等失败路径，避免 Agent 在交换失败后退回共享高权限凭据。
- 明确团队自行承担的部分，包括部署、升级、监控、密钥管理、安全补丁和运行支持。
Loom 最值得关注的并不是新增了一个 Agent 框架，而是把身份委托、可复现部署和资源治理放进同一个参考平台。对于已经开始运行多 Agent 工作流的团队，这三项能力应当在扩大规模之前完成验证。