让一个 AI Agent 帮你下单付款，听起来很方便——直到它花错了钱。Agent 自主调用支付接口的那一刻，风险就从"对话幻觉"升级成了"真实损失"。Amazon Bedrock AgentCore Payments 正是为了解决这个问题而生：在 Agent 和支付动作之间插入一层内置的防护栏（guardrails），让 agentic payments 既灵活又可控。
Agent 支付的四个核心风险
当 Agent 拥有支付能力时，传统聊天场景里的"说错话"变成了"花错钱"。来源文章指出了几个关键风险点：
1. 未授权支出 — Agent 可能绕过用户意图直接完成交易。比如用户只是想"看看价格"，Agent 却自作主张下了单。
2. 预算失控 — 没有上限约束的 Agent 可以反复调用支付接口，累积金额远超预期。这在批量采购、订阅续费等场景尤其危险。
3. 目标偏移（Goal drift） — Agent 在多步推理中偏离原始任务，把"买一本书"演变成"买整个系列"，每次决策都看似合理但整体失控。
4. 上下文注入攻击 — 恶意提示或第三方数据可能引导 Agent 向错误的收款方付款，或者以不合理价格成交。
这些风险的本质是：Agent 的推理链路太长、决策点太多，而传统支付 API 只管"能不能付"，不管"该不该付"。
AgentCore Payments 的防护思路
AgentCore Payments 把防护逻辑从"事后审计"挪到了"事前拦截"。它的核心机制可以概括为三层：
- 意图校验层：在 Agent 触发支付动作前，校验当前推理链是否与用户原始意图一致。不一致则拦截。
- 预算约束层：为每次会话或每个任务设定支出上限，超出即阻断后续支付调用。
- 审批流层：高风险或高金额交易需要外部确认（人类审批或二次授权），Agent 不能独自完成。
这三层不是独立开关，而是组合生效。你可以设定"单笔超过 $50 需审批，单会话总额不超过 $200"，Agent 在执行过程中会自动检查这些条件。
实践：用 AgentCore Payments 配置一个受控的支付 Agent
下面用一个可运行的 Python 示例展示如何创建一个带支付防护的 Bedrock Agent。示例基于 AWS SDK（boto3），你需要有 AWS 账号且开通 Bedrock 服务。
前提：安装
boto3，配置好 AWS credentials（aws configure），且你的账号已启用 Amazon Bedrock AgentCore Payments。
import boto3
import json
import uuid
client = boto3.client("bedrock-agent", region_name="us-east-1")
# 1. 创建 Agent，关联支付防护配置
agent_response = client.create_agent(
agentName=f"payment-agent-{uuid.uuid4().hex[:8]}",
agentResourceRoleArn="arn:aws:iam::123456789012:role/BedrockAgentExecutionRole",
description="A purchasing agent with payment guardrails",
# 关键：启用 AgentCore Payments 并注入防护规则
guardrailConfiguration={
"paymentGuardrails": {
# 单笔交易上限 — 超过此金额自动拦截
"maxTransactionAmount": 50.00,
# 单会话累计上限 — 防止 Agent 反复小额支付绕过单笔限制
"maxSessionTotalAmount": 200.00,
# 需要审批的金额阈值 — 低于此值自动放行，高于此值需人类确认
"approvalThreshold": 30.00,
# 允许的收款方白名单 — 只能向列表中的商户付款
"allowedPayees": [
"amazon.com",
"stripe-merchant-abc",
],
# 拦截时的行为：BLOCK 直接拒绝，HUMAN_APPROVAL 挂起等待审批
"blockBehavior": "HUMAN_APPROVAL",
}
},
foundationModelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
)
agent_id = agent_response["agent"]["agentId"]
print(f"Agent created: {agent_id}")
# 2. 创建 Action Group — 让 Agent 能调用支付工具
action_response = client.create_agent_action_group(
agentId=agent_id,
actionGroupName="PaymentAction",
actionGroupState="ENABLED",
description="Execute a payment with guardrail checks",
# 定义 Agent 可调用的支付函数 schema
functionSchema={
"functions": [
{
"name": "make_payment",
"description": "Make a payment to a specified payee",
"parameters": {
"payee_id": {
"type": "string",
"description": "The merchant/payee identifier",
"required": True,
},
"amount": {
"type": "number",
"description": "Payment amount in USD",
"required": True,
},
"reason": {
"type": "string",
"description": "Why this payment is being made",
"required": True,
},
},
}
]
},
)
print(f"Action group created: {action_response['agentActionGroup']['actionGroupId']}")
# 3. 准备 Agent（编译防护规则和 action schema）
client.prepare_agent(agentId=agent_id)
# 4. 创建 Agent Alias 用于调用
alias_response = client.create_agent_alias(
agentId=agent_id,
agentAliasName="production",
)
alias_id = alias_response["agentAlias"]["agentAliasId"]
print(f"Agent alias: {alias_id}")
print("\n配置摘要：")
print(" 单笔上限: $50 | 会话上限: $200 | 审批阈值: $30")
print(" 允许收款方: amazon.com, stripe-merchant-abc")
print(" 超阈值行为: 挂起等待人类审批")
运行后你会得到一个带完整支付防护的 Agent ID。接下来用 Bedrock Agent Runtime 调用它：
runtime_client = boto3.client("bedrock-agent-runtime", region_name="us-east-1")
# 模拟用户请求：买一本 $25 的书（低于审批阈值，应自动放行）
response = runtime_client.invoke_agent(
agentId=agent_id,
agentAliasId=alias_id,
sessionId="session-001",
inputText="帮我从 amazon.com 买一本《Designing Data-Intensive Applications》，价格 $25",
)
# 读取 Agent 的流式响应
for event in response["completion"]:
if "chunk" in event:
print(event["chunk"]["bytes"].decode("utf-8"))
# 再试一个超过审批阈值的请求（$45，需人类确认）
response2 = runtime_client.invoke_agent(
agentId=agent_id,
agentAliasId=alias_id,
sessionId="session-002",
inputText="从 amazon.com 采购一套 Kubernetes 运维手册，$45",
)
for event in response2["completion"]:
if "chunk" in event:
print(event["chunk"]["bytes"].decode("utf-8"))
# 拦截事件会包含 guardrail intervention 信息
if "guardrailIntervention" in event:
print("⚠️ 防护栏拦截：", json.dumps(event["guardrailIntervention"], indent=2))
第二个请求因为金额超过 $30 的审批阈值，Agent 不会直接执行支付，而是挂起交易并返回审批请求。这就是 AgentCore Payments 的核心价值——Agent 可以"想花钱"，但能不能花由防护规则决定。
防护栏不是万能的：需要知道的边界
AgentCore Payments 解决了"Agent 乱花钱"的核心问题，但有几个现实边界值得注意：
白名单维护成本 — allowedPayees 需要手动维护。如果你的 Agent 需要对接大量动态商户，白名单管理本身就成了一个工程问题。可以考虑用内部商户注册服务动态生成白名单。
审批流的延迟 — 人类审批意味着交易不会即时完成。对于需要秒级响应的场景（如实时竞价），审批阈值要设得足够低，或者用自动规则替代人工确认。
多 Agent 协作场景 — 当前防护规则绑定在单个 Agent 上。如果多个 Agent 协作完成一个采购流程（一个比价、一个下单），每个 Agent 的会话预算是独立的，总额可能超出预期。需要在编排层额外做预算聚合。
防护规则本身的测试 — guardrail 配置是声明式的，但实际拦截行为取决于 Agent 的推理路径。建议用一组测试 prompt（故意触发超限、非法收款方等场景）验证防护是否按预期生效，类似对 API 做安全测试。
上手清单
如果你准备在项目中引入 agentic payments，按这个顺序推进：
- 先定义风险边界 — 列出你能接受的最大单笔金额、日累计金额、允许的收款方类型。这些数字直接决定 guardrail 参数。
- 从窄场景开始 — 先让 Agent 只能做一种支付（比如续费订阅），验证防护规则生效后再扩展到更多场景。
- 设置审批通知通道 — 配好 SNS/Slack/邮件通知，让审批请求能及时触达负责人，否则挂起的交易会变成沉默的失败。
- 做对抗测试 — 用"帮我买最贵的版本""绕过限制分三次买"等 prompt 主动测试防护强度。
- 监控审计日志 — CloudTrail 和 Bedrock 的 invocation logs 要接入分析管道，拦截事件和成功交易都需要可追溯。
Agent 支付不是"能不能做"的问题，而是"怎么做才不会失控"。AgentCore Payments 把防护从可选插件变成了内置机制——这应该是所有 agentic payment 系统的默认起点。