企业落地 AI Agent，最大的拦路虎不是模型能力，而是成本和运维复杂度。AWS 生成式 AI 创新中心（GenAIIC）与 Works Human Intelligence（WHI）的合作给出了一个相当硬核的答案：用 Amazon Bedrock AgentCore 搭建业务支持 Agent，成本降幅最高达 97%，同时运营效率显著提升。这篇文章拆解他们的做法，并给出可直接动手的 Agent 构建示例。
WHI 面临的真实挑战
WHI 是一家专注于 HR SaaS 的日本企业，核心产品处理大量人力资源数据——入职、考勤、薪酬、合规。这些场景天然适合用 AI Agent 做智能问答和流程自动化，但落地时撞上了几堵墙：
- 调用成本失控：Agent 每次执行任务需要多轮调用 LLM，加上工具编排、记忆检索，单次交互的 token 消耗远超简单问答。
- 冷启动与延迟：业务支持场景对响应时间敏感，Agent 的多步推理链路让用户等待时间拉长。
- 工具编排复杂：HR 系统涉及多个后端 API，Agent 需要准确选择和串联工具，错误率高时反而增加人工干预成本。
这些问题不是 WHI 独有，几乎所有尝试把 Agent 嵌入业务流程的团队都会遇到。
AgentCore 的解题思路
Amazon Bedrock AgentCore 不是又一个 Agent 框架，它更像是一套面向生产环境的 Agent 运行基础设施。WHI 的实践揭示了几个关键设计决策：
1. 用 Code Interpreter 替代多轮 LLM 调用
传统 Agent 靠 LLM 反复推理来处理数据查询和计算，每一步都在烧 token。AgentCore 的 Code Interpreter 让 Agent 生成一段代码（Python），然后直接在沙箱中执行，一步拿到结果。对于 HR 数据的聚合、筛选、计算场景，这比让 LLM 一步步"想"要高效得多——代码执行的成本远低于同等计算量的 LLM 推理。
2. 精准的工具路由减少无效调用
AgentCore 的工具编排机制支持对每个 Action Group 做细粒度的描述和约束。WHI 把 HR 系统的 API 按功能域分组（考勤查询、薪酬计算、合规检查），Agent 根据用户意图直接命中对应 Action Group，避免了"先试错再纠正"的调用浪费。
3. 记忆与上下文的结构化管理
业务支持 Agent 需要记住用户的历史交互和组织上下文。AgentCore 提供内置的 Memory Store，WHI 不再自己维护向量数据库和会话状态，减少了基础设施开销和运维负担。
成本削减 97% 的具体路径
97% 不是魔法数字，而是多个优化叠加的结果。拆开来看：
| 优化手段 | 成本影响 |
|---|---|
| Code Interpreter 替代多轮推理 | 减少 60-70% 的 token 消耗 |
| 精准工具路由 | 减少 15-20% 的无效 API 调用 |
| AgentCore 内置记忆管理 | 省去自建向量库的存储和计算成本 |
| 模型选择优化（小模型处理简单意图） | 降低单次推理单价 |
叠加起来，从"每个交互几美元"降到"每个交互几美分"，量级变化让 Agent 从实验项目变成可规模化部署的生产工具。
动手实践：用 Bedrock AgentCore 创建一个业务支持 Agent
下面给出一个最小可运行的示例，模拟 WHI 场景中一个考勤查询 Agent 的创建流程。你需要一个 AWS 账户，且已启用 Amazon Bedrock 的模型访问权限。
前置准备
# 安装 AWS SDK
pip install boto3
# 确保 AWS CLI 已配置好凭证
aws configure list
创建 Agent 及 Action Group
import boto3
import time
import json
client = boto3.client("bedrock-agent", region_name="us-east-1")
# 1. 创建 Agent
agent_resp = client.create_agent(
agentName="hr-attendance-agent",
description="查询员工考勤数据的 HR 业务支持 Agent",
foundationModel="anthropic.claude-3-5-haiku-20241022-v1:0", # 用小模型处理简单意图，降低成本
instruction="""你是一个 HR 考勤查询助手。
当用户询问考勤信息时，使用 attendance-query 工具查询数据。
如果用户的问题超出考勤范围，礼貌地说明你只处理考勤相关查询。
返回结果时，用简洁的中文总结关键数字，不要输出原始 JSON。""",
idleSessionTTLInSeconds=600, # 10 分钟空闲超时，节省资源
)
agent_id = agent_resp["agent"]["agentId"]
print(f"Agent 创建完成，ID: {agent_id}")
# 2. 定义 Action Group 的 OpenAPI Schema
# 这是工具路由的关键——清晰的描述让 Agent 精准命中工具
api_schema = {
"openapi": "3.0.0",
"info": {"title": "HR Attendance API", "version": "1.0.0"},
"paths": {
"/query-attendance": {
"post": {
"summary": "查询指定员工的考勤记录",
"description": "根据员工 ID 和日期范围，返回出勤天数、迟到次数、请假天数",
"operationId": "queryAttendance",
"requestBody": {
"required": True,
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"employee_id": {
"type": "string",
"description": "员工唯一标识，格式 EMP-XXXX",
},
"start_date": {
"type": "string",
"format": "date",
"description": "查询起始日期，YYYY-MM-DD",
},
"end_date": {
"type": "string",
"format": "date",
"description": "查询截止日期，YYYY-MM-DD",
},
},
"required": ["employee_id", "start_date", "end_date"],
}
}
}
},
"responses": {
"200": {
"description": "考勤查询结果",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"work_days": {"type": "integer"},
"late_count": {"type": "integer"},
"leave_days": {"type": "integer"},
}
}
}
}
}
},
}
}
}
}
# 3. 创建 Action Group
action_resp = client.create_agent_action_group(
agentId=agent_id,
agentVersion="DRAFT",
actionGroupName="attendance-query",
description="查询员工考勤数据，包括出勤天数、迟到、请假统计",
actionGroupExecutor={
"type": "Lambda", # 实际部署时替换为你的 Lambda 函数 ARN
"lambda": "arn:aws:lambda:us-east-1:123456789012:function:hr-attendance-handler",
},
apiSchema={
"payload": json.dumps(api_schema)
},
)
print(f"Action Group 创建完成: {action_resp['agentActionGroup']['actionGroupName']}")
# 4. 准备 Agent 并创建别名（用于生产调用）
prepare_resp = client.prepare_agent(agentId=agent_id)
time.sleep(10) # 等待准备完成
alias_resp = client.create_agent_alias(
agentId=agent_id,
agentAliasName="production",
)
alias_id = alias_resp["agentAlias"]["agentAliasId"]
print(f"Agent 别名创建完成，Alias ID: {alias_id}")
调用 Agent 进行对话
runtime = boto3.client("bedrock-agent-runtime", region_name="us-east-1")
session_id = "hr-session-001"
response = runtime.invoke_agent(
agentId=agent_id,
agentAliasId=alias_id,
sessionId=session_id,
inputText="查一下员工 EMP-0023 在 2024 年 11 月的考勤情况",
)
# 流式读取 Agent 响应
for event in response["completion"]:
if "chunk" in event:
print(event["chunk"]["bytes"].decode("utf-8"))
关键配置说明
运行前需要修改的地方：
- Lambda 函数 ARN：
actionGroupExecutor中的 Lambda ARN 需替换为你自己的。Lambda 函数负责实际调用 HR 后端 API，返回考勤数据。 - 模型选择：示例用了 Claude 3.5 Haiku（小模型），简单意图用小模型是 WHI 成本优化的核心策略之一。复杂推理场景可切换为 Claude 3.5 Sonnet。
- instruction 精度：Agent 的
instruction越精确，工具路由越准确，无效调用越少。WHI 的经验是：把 Agent 的能力边界写清楚，比让它"自由发挥"更省钱。
启用 Code Interpreter 进一步降成本
如果你的 Agent 需要做数据计算（比如统计月度出勤率、生成汇总报表），启用 Code Interpreter 可以把多轮推理变成一次代码执行：
# 在创建 Agent 时启用 Code Interpreter
agent_resp = client.create_agent(
agentName="hr-attendance-agent-with-code",
foundationModel="anthropic.claude-3-5-haiku-20241022-v1:0",
instruction="""你是 HR 考勤助手。对数值计算和统计，优先生成 Python 代码执行，不要逐步推理。""",
idleSessionTTLInSeconds=600,
codeInterpreterConfiguration={
"enabled": True,
"files": [], # 可传入参考文件，如考勤规则 PDF
},
)
Code Interpreter 的运行成本是沙箱执行时间，远低于同等计算量的 LLM token 消耗。WHI 的 97% 成本削减中，这一项贡献最大。
落地前的 Checklist
把 Agent 推向生产之前，逐项确认：
- 模型分级：简单意图用小模型（Haiku），复杂推理用大模型（Sonnet）。不要一刀切。
- Action Group 描述：每个工具的 OpenAPI schema 必须写清楚输入输出和适用场景，这是精准路由的前提。
- Code Interpreter 边界：纯数据计算和统计用 Code Interpreter，需要语义理解的场景（如政策解读）仍靠 LLM 推理。
- 会话 TTL：设置合理的
idleSessionTTLInSeconds，避免空闲会话占用资源。 - 监控与回退：Agent 调用失败时，必须有降级到人工或简单 FAQ 的兜底路径。
- 成本基线：先测量无优化时的单次交互成本，再逐项验证每项优化的实际降幅，97% 是 WHI 的数字，你的场景可能不同。
WHI 的实践证明了一点：Agent 的价值不在于它能做多复杂的事，而在于它能不能在成本可控的范围内稳定地做对简单的事。AgentCore 提供的基础设施让这个平衡点变得可触达。