本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 示例资源配置
<a name="example-policies-reference"></a>

本节中的示例是针对一个说明性网关编写的，而不是针对您已经拥有的网关编写的。您的账户中没有任何内容。 `InsuranceAPI`，`ClaimsAgent`，而这三个`Claims*`推理目标是保险理赔应用程序的发明名称，选择这些名称是为了让每个示例都可以共享一组工具、参数类型和主体。改编示例时，请替换您自己的网关 ARN、目标名称和工具名称。

每个示例都授权向此网关发出的请求：

```
arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5
```

改编示例时，将此 ARN 替换为您自己的网关的 ARN。该网关属于保险理赔申请，有五个目标，涵盖了保单 AgentCore授权的所有目标类型：一个模型上下文协议 (MCP) 目标、一个 AgentCore 运行时目标和三个推理目标。

本页描述了示例所引用的操作名称、工具架构、请求正文和委托人。读一遍，其余示例无需进一步设置。

## 动作名称
<a name="example-policies-reference-actions"></a>

您在策略中写入的操作名称取决于为请求提供服务的目标的类型。对于除 MCP 之外的所有内容，它还取决于调用者使用的方法和路径。


| Target | 类型 | 操作名称 | 
| --- | --- | --- | 
|  `InsuranceAPI`  | MCP |  `AgentCore::Action::"InsuranceAPI___file_claim"`（每个工具一个动作） | 
|  `ClaimsAgent`  | AgentCore 运行时间 |  `AgentCore::Action::"ClaimsAgent___POST:/invocations"`  | 
|  `ClaimsChat`  | 推理 |  `AgentCore::Action::"ClaimsChat___POST:/v1/chat/completions"`  | 
|  `ClaimsResponses`  | 推理 |  `AgentCore::Action::"ClaimsResponses___POST:/v1/responses"`  | 
|  `ClaimsMessages`  | 推理 |  `AgentCore::Action::"ClaimsMessages___POST:/v1/messages"`  | 

MCP 目标为每个工具生成一个操作，因此策略可以命名单个工具。每种其他目标类型都会为每种方法和路径组合生成一个操作，因此策略会命名目标和路径，而不是单个能力。

### 推理目标和 API 路径
<a name="example-policies-reference-inference-paths"></a>

推理目标是为一个 API 形状配置的，因此提供多个推理 API 的网关每个 API 都有一个目标。这就是为什么参考网关有三个。每个策略都带有不同的请求正文，因此为一个人编写的策略不会延续到另一个请求正文。


| Target | API 路径 | 信封 | 
| --- | --- | --- | 
|  `ClaimsChat`  |  `POST /v1/chat/completions`  | OpenAI 聊天完成次数 | 
|  `ClaimsResponses`  |  `POST /v1/responses`  | OpenAI 的回应 | 
|  `ClaimsMessages`  |  `POST /v1/messages`  | 人类信息 | 

网关也可能公开`GET /v1/models`，其中列出了可用的模型。它不携带请求正文，因此上的策略`ClaimsChat___GET:/v1/models`只能匹配委托人、操作和资源。

**重要**  
要完全控制推理，请为网关上的每个推理操作编写一个策略。策略命名只会`ClaimsChat___POST:/v1/chat/completions`使`/v1/responses`和`/v1/messages`目标没有得到解决，而且由于三个信封将提示放在不同的位置，因此为一个信封写的条件不能逐字重复用于另一个信封。有关更多信息，请参阅[按路径推断请求正文](#example-policies-reference-inference-bodies)。

有关完整规则（包括 HTTP 代理目标），请参阅[按目标类型划分的操作名称](policy-scope.md#policy-guardrails-action-naming)。

## InsuranceAPI 目标上的 MCP 工具
<a name="example-policies-reference-tools"></a>

`InsuranceAPI`目标会暴露八个工具。每个参数的 Cedar 类型遵循其 JSON 架构类型。该类型决定了在条件中可以对参数使用哪些运算符。有关更多信息，请参阅[条件中的参数类型](#example-policies-types)。

insuranceAPI\_\_\_get\_Contract  
检索保险合同的详细信息，例如承保范围和期限日期。  
 **参数：**  
+  `contractId`（字符串，必填）-保险合同标识符

insuranceAPI\_\_\_file\_Claim  
提出保险索赔。  
 **参数：**  
+  `contractId`（字符串，必填）-保险合同标识符
+  `claimType`（字符串，必填）-索赔类型：`health``property`、或 `auto` 
+  `amount`（数字，必填）-索赔金额
+  `policyTermMonths`（整数，必填）-保单期限，以月为单位
+  `description`（字符串，可选）-索赔描述

insuranceAPI\_\_\_update\_coverage  
更新保单覆盖范围。  
 **参数：**  
+  `contractId`（字符串，必填）-保险合同标识符
+  `coverageType`（字符串，必填）-覆盖范围的类型，例如`liability`或 `collision` 
+  `newLimit`（数字，必填）-新的保险限额

insuranceAPI\_\_\_get\_Claim\_status  
查看索赔状态。  
 **参数：**  
+  `claimId`（字符串，必填）-索赔标识符

   **返回：**`claimId`（字符串）、`status`（字符串）

InsuranceAPI\_\_\_计算保费  
计算保险费。  
 **参数：**  
+  `coverageType`（字符串，必填）-承保范围
+  `coverageAmount`（数字，必填）-保险金额
+  `riskFactors`（对象，可选）-风险评估因素，包含`region`（字符串）成员和`priorClaims`（整数）成员

insuranceAPI\_\_\_Approve\_Claim  
批准已提交的索赔。时间示例使用此工具作为付款之前必须先进行审批。  
 **参数：**  
+  `claimId`（字符串，必填）-索赔标识符
+  `approved`（布尔值，必填）-索赔是否获得批准
+  `approvedAmountCents`（整数，必填）-批准金额，以美分为单位

   **返回：**`claimId`（字符串）、`approved`（布尔值）、`approvedAmountCents`（整数）

InsuranceAPI\_\_\_dismanse\_Paymen  
为已批准的索赔支付款项。  
 **参数：**  
+  `claimId`（字符串，必填）-索赔标识符
+  `amountCents`（整数，必填）-要支付的金额，以美分为单位

   **返回：**`claimId`（字符串）、`status`（字符串）、`amountCents`（整数）

insuranceAPI\_\_\_Delete\_Claim  
永久删除索赔记录。示例使用此工具作为大多数委托人不得触及的敏感操作。  
 **参数：**  
+  `claimId`（字符串，必填）-索赔标识符

## 运行时目标上的请求正文
<a name="example-policies-reference-bodies"></a>

运行时目标作为一个操作进行授权，它`context.input`包含请求正文而不是一组已声明的工具参数。

 `ClaimsAgent___POST:/invocations`   
托管理赔助手的 AgentCore 运行时目标。  
 **请求正文：**  
+  `prompt`（字符串）-用户给代理的消息
+  `sessionAttributes`（对象，可选）- Caller-supplied 属性

   **响应正文：**`completion`（字符串）

**重要**  
对于运行时目标，策略可以读取的字段来自在**网关目标上声明的 OpenAPI 架构**，而不是来自运行时实际发送的内容。架构未声明的字段不可寻址——仅`context.output.<field>`适用于架构列出的响应属性，在时间谓词`output.<field>`中也是如此。  
如果运行时字段上的条件因未声明而被拒绝，请检查目标的架构，而不是运行时的代码。

## 按路径推断请求正文
<a name="example-policies-reference-inference-bodies"></a>

对于推理目标，`context.input`保存调用者调用的 API 的请求正文。这三个信封将对话文本放置在不同的结构中，这是根据推理目标编写条件或护栏数据路径之前要知道的最重要的一件事。

 `ClaimsChat___POST:/v1/chat/completions`   
OpenAI 聊天完成。对话是一组消息对象；系统提示是带有的消息`role: system`。  

```
{
  "model": "openai.gpt-oss-120b-1:0",
  "messages": [
    { "role": "system", "content": "You are a claims assistant." },
    { "role": "user",   "content": "What is the status of claim C-1001?" }
  ]
}
```
 **响应正文：**`choices`（数组），每个条目都有一个`message`对象存放`role`和 `content` 

 `ClaimsResponses___POST:/v1/responses`   
OpenAI 的回应。提示是一个`input`成员，可以是一个裸字符串，**也可以**是一个包含数`content`组的项目列表。系统提示符是一个单独`instructions`的成员。  

```
{
  "model": "openai.gpt-oss-120b-1:0",
  "instructions": "You are a claims assistant.",
  "input": "What is the status of claim C-1001?"
}
```
 **响应正文：**`output`（数组），每个条目都有一个包含方块的`content`数组 `text` 

 `ClaimsMessages___POST:/v1/messages`   
人类信息。对话是一个`messages`数组，其`content`可以是字符串或类型化块的数组。系统提示是顶级`system`成员，而不是消息。  

```
{
  "model": "anthropic.claude-sonnet-4-5-20250929-v1:0",
  "max_tokens": 1024,
  "system": "You are a claims assistant.",
  "messages": [
    { "role": "user", "content": "What is the status of claim C-1001?" }
  ]
}
```
 **响应正文：**持有方块的`content`（数组）`text` 

### 每条路径的文字位置
<a name="example-policies-reference-inference-fields"></a>

下表给出了双向对话文本在每条路径上的位置。每当你需要用护栏指向来电者或模特实际说的话时，都可以使用它。


| API 路径 | 入站文本 | 出站文本 | 
| --- | --- | --- | 
|  `/v1/chat/completions`  |  `messages[*].content`  |  `choices[*].message.content`  | 
|  `/v1/responses`  |  `input`, `input[*].content[*].text`, `instructions`  |  `output[*].content[*].text`  | 
|  `/v1/messages`  |  `messages[*].content`, `messages[*].content[*].text`, `system`  |  `content[*].text`  | 

两条路径列出了多个入站位置，因为电线格式各不相同。O `/v1/responses` n，要么`input`是裸字符串，要么是项目列表，所以文本在一种情况下是 a `input` t，`input[*].content[*].text`在另一种情况下是at。启`/v1/messages`用，消息要么`content`是字符串，要么是类型化块的数组。命名这两个形状可以涵盖任何一种电线形式，而不必知道来电者发送了哪个电线。

**重要**  
这些位置位于数组和记录中，因此你**无法**用裸露的`context.input.<field>`路径到达它们 —— `context.input.messages` 是而不是文本`Set<record>`，而且 Dogwood 没有数组投影运算符，字段路径中的解析错误`messages[*].content`也是如此。而是使用带`$`前缀的 jsonPath 字符串到达它们的 Guardrail 数据路径。有关更多信息，请参阅使用 [JSONPath 访问数组内的文本](example-policies-guardrails.md#example-policies-guardrails-jsonpath)。  
对于普通的 Cedar 条件，只有标量成员可用 — `context.input.model` 是 a `String` 和，但`context.input.messages`根本无法进行比较或模式匹配。

## 主体
<a name="example-policies-reference-principals"></a>

委托人实体类型取决于网关如何对入站来电者进行身份验证。这些示例使用模式要求的任何类型，并且大多数模式都适用于任何一种类型。

AgentCore::OAuthUser  
网关使用 JWT 授权器。实体 ID 是令牌的`sub`声明，令牌的其他声明可通过`principal.hasTag("<claim>")`和作为标签获得`principal.getTag("<claim>")`。这些示例使用了三个声明：`username``role`、和`scope`。

AgentCore::IamEntity  
网关使用`AWS_IAM`。实体 ID 是呼叫者的 ARN，删除了所有会话名称，因此代入的角色显示为。`arn:aws:sts::<account>:assumed-role/<role-name>`这种形式在各个会话中都是稳定的，因此你可以将其与角色系列进行匹配`principal ==`或与之匹配`principal.id like`。

有关主体属性的完整列表以及声明如何映射到标签，请参阅[主体](policy-scope.md#policy-principal)。

## 条件中的参数类型
<a name="example-policies-types"></a>

工具参数的 JSON 架构类型决定了其 Cedar 类型，而 Cedar 类型决定了哪些运算符对其有效。如果出现此错误，则会生成一个策略，该策略要么验证失败，要么在运行时拒绝每个请求，因此在为其写入条件之前，请先检查参数的类型。


| JSON 架构类型 | 雪松型 | 如何比较 | 
| --- | --- | --- | 
|  `string`  |  `String`  |  `==`、`!=`、`like`、并使用设置成员资格 `.contains()`  | 
|  `integer`  |  `Long`  |  `==`,`<`,,`⇐`,`>`，`>=`带整数文字 | 
|  `number`  |  `decimal`  | 只有`.lessThan()`、`.lessThanOrEqual()`、、`.greaterThan()``.greaterThanOrEqual()`、和`==`，每个都与`decimal("…​")`字面意思对照。Cedar 没有`<`或`>`运算符`decimal`，也没有浮点文字。 | 
|  `boolean`  |  `Bool`  |  `==`，并在某种条件下直接使用 | 
|  `object`  |  `Record`  | 使用访问成员`.`，并使用测试成员 `has`  | 
|  `array`  |  `Set`  |  `.contains()`, `.containsAll()`, `.containsAny()`  | 
|  `null`  |  `Entity`  | 不可比拟。省略了`null`参数`context.input`，因此请使用以下方法测试其是否存在 `!(context.input has <field>)`  | 

这些是 Cedar 自己的类型名称，也是生成的架构使用的名称。有关包括每次转换注意事项在内的完整映射，请参阅[上下文](policy-schema-constraints.md#policy-context)。

### 数值参数
<a name="example-policies-numeric"></a>

数字是最有可能以服务拒绝的形式写入条件的地方。在编写比较之前，请确认参数的类型以及该类型支持的运算符。

 **An `integer` 变成了雪松`Long`。**将其与普通运算符和整数文字进行比较：

```
context.input.policyTermMonths >= 12
```

 **A `number` 变成 Cedar `decimal`。**Cedar 为定义了 no `<` `⇐` `>`、、、或`>=`运算符，`decimal`并且没有浮点文字，因此请使用比较方法和带引号的文`decimal("…​")`字：

```
context.input.amount.greaterThan(decimal("1000.00"))
```

`context.input.amount > 1000.00`和`context.input.amount < 1000`均无效。第一个没有该类型的运算符；第二个将a与a `decimal` 进行比较`Long`。

 **在`temporal { }`区块内，排序需要一个`integer`。**在排序比较中，A `decimal` 被拒绝，a 也是如此`string`。求和有同样的要求：`sum`需要一个`integer`求和。相等 (`==`,`!=`) 是不受限制的，前提是两边的类型相同。有关更多信息，请参阅[临时策略示例](example-policies-temporal.md)。

在您创建策略时，该服务会报告任何类型的类型错误。该消息使用行和列指针（例如，或在`temporal`块`comparison requires numeric operands on both sides`内）命名预期类型和实际类型。`unexpected type: expected Long but saw decimal`

**提示**  
将临时策略必须达到的总值或阈值的任何值建模为工具架构`integer`中的值。这就是为什么参考网关以两种方式陈述金钱的原因。 `file_claim``amount`视为 a`number`，因为它的规则是时间点比较。 `approve_claim`取整数`approvedAmountCents`并`disburse_payment`取整数`amountCents`，因为时间示例聚合了它们。对于任何临时政策需要合计其价值的工具，都值得采用将货币表示为整数次要单位。

有关十进制精度限制和其他架构限制，请参阅[约束和配额](policy-schema-constraints.md)。

当调用者省略可选参数`context.input`时，它们就不存在了，因此`has`在读取成员之前，请先用它进行测试：

```
context.input has description && context.input.description != ""
```

警卫是必需的，而不是咨询性的。读取不带可选属性的策略创建失败`unable to guarantee safety of access to optional attribute`，并且失败是异步的，后面是 202 `CREATE_FAILED`。架构标记为必填的参数不需要任何保护。

类型不匹配也会以同样的方式失败。 `.contains(1)`在一组字符串报告上`the types Long and String are not compatible`，使用行和列指针。