5 个 Agent 协同处理金融业务，我用 Kiro + AgentCore 半天就部署上线了
Agent demo 人人会写，上生产十个人九个卡。
上周我接了个金融逾期处理的项目（要做五个 Agent 协同工作：识别逾期 → 客户画像 → 风险评分 → 分拨决策 → 自动触达。听着挺顶畅，实际一做发现全是坑------沙箱隔离、会话管理、弹性扩缩、认证鉴权，每一个都够折腾半天。
后来换了个思路：用 Kiro IDE 的 Spec 模式做需求和架构，用 Amazon Bedrock AgentCore 跑生产环境。整个流程从头到尾不到五个小时。
这篇文章把我的完整经历写出来。
Demo 到生产之间的鸿沟
先聊为什么 Agent 项目大部分停在 demo 阶段。
写个 Agent demo 太简单了。装个 SDK，写几十行代码，调一下大模型 API，搞几个 tool，完事。但真要上生产，问题多到你数不过来。
第一个问题：隔离。Agent 运行时要访问数据库、调外部 API，如果所有会话跑在同一个进程里，一个用户的请求出了问题，可能把整个服务搞挂。你说用容器隔离？容器的隔离级别其实不够硬，而且启动速度也不够快。
第二个问题：扩缩容。金融场景的特点是流量波动大。月初月末逾期案件集中涌入，平时可能没几个。预置大量实例太贵，按需启动又慢。传统虚拟机启动要几分钟，根本跟不上。
第三个问题：Agent 之间怎么通信。五个 Agent 互相调用，Session 怎么传递？上下文怎么保持？每个 Agent 需要不同的云服务权限，认证怎么管理？
第四个问题：出了问题怎么查。Agent 的推理过程不透明，它调了哪些工具、做了什么决策、消耗了多少资源，这些信息不收集的话，线上出 bug 你两眼一抹黑。
我之前的做法是一个一个手动解决这些问题。搞了整整一周，心态都崩了。
Kiro Spec 模式：先想清楚再写代码
后来重新来过，决定用 Kiro IDE 的 Spec 模式。
Kiro 有两种模式。Vibe 模式就是普通的对话编程，说一句干一句。Spec 模式走的是另一条路：requirements → design → tasks，先生成需求文档，再生成架构设计，最后拆成开发任务。
区别在哪？Vibe 模式像是跟实习生聊天，你说啥它干啥，但它不看全局。Spec 模式像是有个技术 Lead 帮你先把项目规划好，然后按计划执行。
我的初始 Prompt
我给 Kiro 的输入大概是这样：
diff
业务需求：
创建自动化金融逾期处理流程 Multi Agent，
从逾期识别到触达处理，全流程自动化。
技术要求：
- 使用 Strands Agent SDK
- 部署在 Amazon Bedrock AgentCore
- 后端 Python，部署 ECR + Fargate
- 前端 React + Node.js
- 数据库 Aurora PostgreSQL Serverless with Data API
- 触达用 Amazon SNS 邮件通知
- 认证用 Amazon Cognito 集成 AgentCoreKiro 花了大概十分钟，生成了三份文档。
requirements.md 把需求结构化了。每个功能都有 User Story 和 Acceptance Criteria，用的是 EARS 符号。比如 Orchestrator Agent 的需求：
THE Orchestrator_Agent SHALL receive processing requests and coordinate other agents to complete business workflows.
WHEN a business process requires data operations, THE Orchestrator_Agent SHALL invoke the Data_Agent using AgentCore Runtime API calls.
这种格式的好处是，验收标准很明确，测试用例可以直接从这里推导出来。
design.md 做了架构决策。它选择了混合模式------核心流程用确定性 DAG（有向无环图），协调层用 Orchestrator Agent。五个 Agent 的职责、工具集、接口都定义清楚了。
tasks.md 把实现拆成了具体的开发步骤，每步都有完成标准。
我花十五分钟审了一遍，觉得方案合理，开始让 Kiro 按 tasks 执行。
五个 Agent 的分工
先说架构。五个 Agent，每个有明确的职责和工具集：
| Agent | 职责 | 核心工具 |
|---|---|---|
| Orchestrator | 接收请求，协调流程 | 调用其他 Agent 的 API |
| Data Agent | 数据库读写 | query_database, insert_case, update_status |
| Scoring Agent | 风险评分 | calculate_b_card, calculate_c_card, risk_profile |
| Allocation Agent | 分拨决策 | apply_rules, select_channel, optimize_timing |
| Outreach Agent | 客户触达 | send_email (SNS), check_compliance |
业务流程是一条链：
css
逾期事件 → Orchestrator 接收
→ Data Agent 建案件 + 查客户数据
→ Scoring Agent 算 B卡/C卡 评分
→ Allocation Agent 匹配策略规则
→ Outreach Agent 发通知
→ Data Agent 记录结果用 Strands Agent SDK 写 Agent，代码很清爽：
python
from strands import Agent
from strands.models.bedrock import BedrockModel
model = BedrockModel(
model_id="amazon.nova-pro-v1:0",
region_name="us-west-2"
)
scoring_agent = Agent(
model=model,
system_prompt="""你是金融风险评分专家。
根据客户交易行为、还款历史、征信数据，
计算 B 卡评分和 C 卡评分。
输出必须是 JSON 格式。""",
tools=[
calculate_b_card_score,
calculate_c_card_score,
analyze_transaction_patterns,
generate_risk_profile
]
)每个 Agent 都有独立的 system prompt 和工具集，职责边界很清晰。
AgentCore 部署：这才是重头戏
Agent 写完了/��本地跑通了。上生产才是难点。
Amazon Bedrock AgentCore 本质上是一个面向 Agent 的托管运行时，底层用 Firecracker microVM 技术。
Firecracker microVM 是什么
Firecracker 是亚马逊云科技开源的轻量级虚拟化技术。每个 Agent 会话跑在独立的 microVM 里------不是容器，是真正的虚拟机，硬件级隔离。
几个关键数字：
- 启动时间：毫秒级。请求来了瞬间拉起一个隔离环境。
- 会话隔离：独立的 CPU、内存、网络。一个会话崩了不影响别人。
- 自动销毁：会话结束后 microVM 自动销毁，数据清零。
这意味着什么？每个用户的 Agent 会话都跑在自己的小虚拟机里，互不干扰。金融场景最怕的数据泄露问题，从架构层面就解决了。
扩缩容不用管
AgentCore Runtime 自动处理并发。流量来了自动创建 microVM，流量走了自动销毁。因为启动只要毫秒级，所以不需要预置实例，按需启动就行。
几百个并发会话？没事，毫秒级启动，扛得住。
部署代码
部署到 AgentCore 大概是这样：
python
import boto3
client = boto3.client(
'bedrock-agentcore',
region_name='us-west-2'
)
response = client.create_runtime(
runtimeName='overdue-processing-agents',
networkConfiguration={
'networkMode': 'PUBLIC'
},
workerConfigurations=[{
'containerConfiguration': {
'containerUri': (
'123456789.dkr.ecr.us-west-2.'
'amazonaws.com/overdue-agents:latest'
)
},
'port': 8080,
'cpu': '2 vCPU',
'memory': '4 GB'
}],
authorizationConfiguration={
'authorizationType': 'COGNITO',
'cognitoConfiguration': {
'userPoolId': 'us-west-2_xxxxx'
}
}
)几个要点：
- 端口固定 8080，这是 AgentCore 的约定
- 认证直接对接 Amazon Cognito，省事
- Agent 代码打包成容器推到 ECR
配套的生产级组件
AgentCore 不只是一个运行环境。它带了一整套生产级组件：
Memory（记忆）：每次会话生成一个 Session，对话历史自动存储。短期记忆管理当前对话上下文，长期记忆保存跨会话信息。在金融场景里，这意味着 Agent 可以记住之前跟客户沟通的结果。
认证：集成 Cognito，用户登录后的 Token 直接透传给 Agent，不用自己搞一套鉴权。
安全策略：可以定义 Agent 能访问哪些数据库表、能调用哪些 API。金融场景的权限管控要求高，这个很有用。
可观测性：每次 Agent 推理的日志、工具调用记录、Token 消耗、响应时间------都有。出了问题一查就知道哪个 Agent 在哪一步出的错。
踩坑实录
分享几个我踩过的坑。
坑 1：Session ID 传丢了
Orchestrator 调用 Scoring Agent 的时候，我一开始没传 session ID。结果每次调用都是新会话，之前 Data Agent 查到的客户信息，Scoring Agent 压根不知道。
修复方法简单------每次调用都带上同一个 session ID：
python
session_id = str(uuid.uuid4())
# 所有 Agent 调用共享同一个 session
data_result = invoke_agent(
agent_name='data-agent',
session_id=session_id,
prompt='查询客户 C001 的逾期信息'
)
scoring_result = invoke_agent(
agent_name='scoring-agent',
session_id=session_id,
prompt='根据已有数据计算风险评分'
)坑 2：LLM 输出格式不稳定
Scoring Agent 有时候返回标准 JSON，有时候返回一大段自然语言解释加 JSON。下游 Allocation Agent 解析就崩了。
我的处理方式：在 system prompt 里强制要求 JSON 输出，外加一层解析校验：
python
import json
import re
def extract_score(raw_output):
# 先试直接解析
try:
return json.loads(raw_output)
except json.JSONDecodeError:
pass
# 尝试从文本中提取 JSON 块
json_match = re.search(
r'\{[\s\S]*\}', raw_output
)
if json_match:
try:
return json.loads(json_match.group())
except json.JSONDecodeError:
pass
return None # 让 Agent 重试坑 3：容器镜像太大
第一版镜像 2.3GB，AgentCore 拉取部署慢得让人抓狂。后来用 multi-stage build + Alpine 基础镜像，压到了 480MB。
dockerfile
# 构建阶段
FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# 运行阶段
FROM python:3.12-alpine
COPY --from=builder /usr/local/lib/python3.12 /usr/local/lib/python3.12
COPY . /app
WORKDIR /app
EXPOSE 8080
CMD ["python", "main.py"]坑 4：Aurora Serverless 冷启动
Aurora PostgreSQL Serverless 如果一段时间没请求会暂停，下次连接要等几秒冷启动。Data Agent 第一次查库的时候超时了。
解决办法：加重试逻辑 + 指数退避。
python
import time
def execute_with_retry(sql, params=None, max_retries=3):
for attempt in range(max_retries):
try:
return rds_client.execute_statement(
resourceArn=cluster_arn,
secretArn=secret_arn,
database='overdue_db',
sql=sql,
parameters=params or []
)
except Exception as e:
if attempt < max_retries - 1:
wait = 2 ** attempt
time.sleep(wait)
else:
raise时间复盘
贴一下整个项目的时间线：
| 阶段 | 耗时 | 说明 |
|---|---|---|
| 写初始 Prompt | 30min | 描述业务需求和技术要求 |
| Kiro 生成 Spec | 10min | 自动生成 requirements + design + tasks |
| 人工 Review | 15min | 检查方案合理性，微调 |
| Kiro 生成代码 | 2h | 按 tasks 逐步执行 |
| 本地联调测试 | 1h | 五个 Agent 端到端跑通 |
| AgentCore 部署 | 30min | 配置 + 镜像推送 + 部署 |
| 生产验证 | 30min | 线上端到端测试 |
| 合计 | ~5h |
五个小时，从需求到生产。换传统开发模式，两周起步。
适用场景判断
最后聊聊什么场景适合这套方案。
适合：
- 多 Agent 协同的复杂业务流程
- 对安全隔离要求高（金融、医疗、政务）
- 并发量波动大，需要弹性扩缩
- 需要会话记忆和可观测性
不适合：
- 单 Agent 简单场景，杀鸡用牛刀了
- 对延迟要求在微秒级的实时交易系统
总结一下，Kiro Spec 模式让你「先想清楚再动手」，AgentCore 让你「不用操心底层运维」。两个搭配起来，Agent 上生产的成本确实降了一个量级。
建议先从两个 Agent 的简单项目试手，跑通流程后再搞复杂的。
参考资源：
- Amazon Bedrock AgentCore：aws.amazon.com/cn/bedrock/...
- Kiro IDE：kiro.dev
- Strands Agents SDK：github.com/strands-age...