AI Agent 真正接入企业环境后，难点通常不在于“能不能调用工具”，而在于“谁可以调用什么、以什么身份调用、调用过程是否可审计，以及风险上升时如何快速收紧权限”。Amazon Bedrock AgentCore Gateway 可以作为 Agent 与企业工具之间的治理边界，让团队在不把所有工具基础设施集中到一处的情况下，逐步建立受控、可追踪的工具访问方式。
一个实用的采用路径可以分为四个范围：Connect、Control、Catalog、Harden。它们不是必须一次性全部实现的产品清单，而是一套成熟度模型：只有当真实的治理问题出现时，才推进到下一个范围。
Connect：先把工具接入统一入口
第一步是让 Agent 通过 Gateway 访问企业工具，而不是让每个 Agent 自己保存数据库连接、内部 API 地址或第三方服务凭证。
这里的重点不是立即重构所有后端，而是建立一条稳定的访问路径：
Agent -> AgentCore Gateway -> 企业工具或服务
工具可以继续由不同团队维护，部署在不同环境中，甚至使用不同的协议。Gateway 负责提供面向 Agent 的统一工具入口，后端服务仍然保留自己的生命周期和运维边界。
接入阶段至少应该明确以下内容：
- 工具名称和版本
- 输入参数及其类型
- 调用超时时间
- 失败和重试行为
- 工具的实际后端负责人
- Agent 是否允许读取、写入或执行副作用操作
可以先用一个简单的工具描述文件建立契约。下面的 YAML 是一个可改造的示例，字段名称代表治理设计，具体部署字段需要按照你的 AgentCore Gateway 配置方式调整：
# tools.yaml
# 这是工具接入契约示例，部署时映射到实际的 Gateway 配置。
tools:
- name: ticket.search
version: "1"
description: Search support tickets by customer or status.
endpoint: https://support.internal.example.com/tools/ticket-search
method: POST
access:
mode: read-only
allowed_agents:
- support-assistant
input_schema:
type: object
required: [customer_id]
properties:
customer_id:
type: string
status:
type: string
enum: [open, pending, closed]
timeout_ms: 3000
owner: support-platform
- name: ticket.update
version: "1"
description: Update a support ticket.
endpoint: https://support.internal.example.com/tools/ticket-update
method: POST
access:
mode: write
allowed_agents:
- support-assistant-approved
requires_confirmation: true
timeout_ms: 5000
owner: support-platform
这个文件本身不等于完整的安全控制，但它能迫使团队回答几个关键问题：工具是否只读，哪些 Agent 可以使用，写操作是否需要确认，以及谁对工具负责。
Control：把身份、权限和审批放到调用路径上
当 Agent 数量增加后，仅仅“所有 Agent 都经过 Gateway”并不够。Gateway 需要知道调用者是谁、调用的是哪个工具、请求是否属于允许的操作范围。
治理控制通常应覆盖四个维度：
- 调用身份：区分 Agent、用户、应用和服务账号，不要让所有请求共享一个高权限凭证。
- 工具权限：按工具授予权限，而不是按网络位置授予权限。
- 参数约束：限制可访问的客户、区域、资源类型或数据范围。
- 副作用确认：对发送邮件、修改工单、执行付款等操作增加人工确认或独立审批。
下面是一个可以直接改造成网关前置策略的 JSON 示例。它不是某个 AWS API 的固定请求格式，而是用于表达策略的最小结构；实际项目中可以将这些字段映射到 AgentCore Gateway 的身份、授权和审计配置中：
{
"policy_version": "2025-01",
"agent": "support-assistant",
"principals": ["user:alice@example.com"],
"allow": [
{
"tool": "ticket.search",
"operations": ["read"],
"constraints": {
"customer_id_source": "session.customer_id",
"max_results": 50
}
}
],
"require_confirmation": [
{
"tool": "ticket.update",
"operations": ["write"],
"reason": "Ticket changes affect customer-visible state"
}
],
"deny": [
{
"tool": "ticket.update",
"when": "request.environment != 'production-approved'"
}
],
"audit": {
"record": [
"request_id",
"agent_id",
"principal",
"tool",
"arguments_hash",
"decision",
"latency_ms",
"backend_status"
],
"redact": ["authorization", "customer_email", "ticket_content"]
}
}
实践中，策略判断应该发生在工具执行之前。请求被拒绝时，要返回可供 Agent 理解的结构化错误，例如 authorization_denied、confirmation_required 或 invalid_argument，而不是把内部堆栈直接暴露给模型。
一个适合本地联调或服务端适配层的调用示例：
#!/usr/bin/env bash
set -euo pipefail
: "${GATEWAY_URL:?Set GATEWAY_URL to your AgentCore Gateway endpoint}"
: "${AWS_REGION:?Set AWS_REGION}"
# 下面的 Authorization 获取方式取决于你的部署方案。
# 生产环境应使用短期 AWS 凭证或企业身份系统签发的令牌。
TOKEN="${GATEWAY_TOKEN:?Set GATEWAY_TOKEN}"
curl --fail-with-body --silent --show-error \
--request POST "${GATEWAY_URL}/tools/ticket.search" \
--header "Authorization: Bearer ${TOKEN}" \
--header "Content-Type: application/json" \
--header "X-Agent-Id: support-assistant" \
--header "X-Request-Id: $(uuidgen)" \
--data '{
"customer_id": "cust-12345",
"status": "open"
}'
运行前需要设置 GATEWAY_URL、GATEWAY_TOKEN 和 AWS_REGION，并根据实际认证方案替换令牌获取逻辑。这个请求的价值不在于某个固定的 URL，而在于它把 Agent 身份、工具名称、请求 ID 和业务参数放进了可治理的调用边界。
Catalog：让工具可发现，也让工具可理解
当工具数量达到几十或几百个时，权限问题之外还会出现发现问题：Agent 不知道哪个工具适合当前任务，人类开发者也无法快速判断工具是否安全、是否仍然受支持。
Catalog 阶段要解决的不是“把所有工具列出来”，而是建立可供 Agent 和工程团队共同使用的工具目录。每个工具至少应包含：
- 人类可读的用途说明
- 结构化输入和输出模式
- 只读、写入或执行类型
- 数据敏感级别
- 所需权限
- 版本和弃用状态
- 所有者、SLO 和联系人
- 常见失败码和重试建议
- 是否需要用户确认
工具描述应该让模型能够做出边界清晰的选择。例如，下面两个描述比笼统的 manage_ticket 更容易被正确使用：
[
{
"name": "ticket.search",
"summary": "Read open or closed support tickets for the current customer.",
"side_effects": false,
"requires_confirmation": false,
"data_classification": "internal"
},
{
"name": "ticket.update",
"summary": "Change the status or priority of one support ticket.",
"side_effects": true,
"requires_confirmation": true,
"data_classification": "internal"
}
]
目录还应参与发布流程。新增工具时进行所有者审核，修改输入模式时进行兼容性检查，删除工具时先标记弃用并保留迁移窗口。否则，目录会很快变成过期文档，Agent 仍然会依赖已经失效的工具。
Harden：针对真实风险加固关键路径
Harden 阶段并不意味着给每个工具都加上同样复杂的控制。更合理的做法是根据风险分层：读操作、低敏感数据和可重复查询可以使用较轻的控制；写操作、高价值交易和敏感数据访问则需要更严格的保护。
可以重点增加以下机制：
- 短期凭证和自动轮换，避免在提示词或 Agent 配置中保存长期密钥
- 工具级和参数级授权，而不只是网络层访问控制
- 请求、决策、工具响应状态和延迟的审计记录
- 敏感字段脱敏或哈希化，避免把完整业务数据写入日志
- 幂等键和超时，降低 Agent 重试造成重复副作用的风险
- 速率限制和预算限制，防止循环调用耗尽后端资源
- 高风险动作的人工确认或双人审批
- 异常调用告警，例如短时间内大量导出、跨区域访问或连续拒绝
一个容易被忽视的边界是：日志必须同时满足审计和隐私要求。记录“调用了哪个工具、谁发起、策略是否允许、后端返回什么状态”通常很有价值，但不应默认记录完整的提示词、客户内容或授权令牌。可以记录参数摘要或不可逆哈希，并把需要调查的原始数据放在访问受控的系统中。
什么时候推进到下一个范围
四个范围可以用实际信号来驱动，而不是按固定日期推进：
- 从 Connect 到 Control：出现共享凭证、越权调用、无法区分 Agent 身份，或写操作没有审批边界。
- 从 Control 到 Catalog：工具数量增长，模型频繁选错工具，开发者无法判断工具用途和所有者。
- 从 Catalog 到 Harden：出现敏感数据访问、重复写入、异常调用、审计调查或合规要求。
这个顺序也保留了团队的基础设施独立性。工具后端不需要一次性迁移到同一个平台，Gateway 负责治理调用关系，工具团队仍然可以按照自己的技术栈和发布节奏维护服务。
落地检查清单
在生产环境扩大 Agent 工具权限前，可以检查以下问题：
- 每个工具是否有明确的所有者和版本？
- Gateway 是否能识别具体 Agent 和最终用户？
- 读操作和写操作是否使用不同的权限边界？
- 工具参数是否经过 schema 校验和范围限制？
- 高风险操作是否需要确认或审批？
- 审计记录是否包含请求 ID、决策结果和后端状态？
- 日志是否避免保存令牌和不必要的敏感内容？
- 重试是否可能造成重复执行？是否有幂等设计？
- 工具被弃用或权限变更时，Agent 是否能得到明确反馈？
Amazon Bedrock AgentCore Gateway 的价值不只在于增加一个调用入口，而在于把工具访问变成可以逐步治理的系统边界。先连接工具，再控制身份和权限；当规模带来发现成本时建立目录；当真实风险出现时，再针对敏感数据和副作用操作加固。这样的节奏能让治理跟着风险增长，同时保留企业现有工具基础设施的独立演进能力。