5 个 Agent 协同处理金融业务，我用 Kiro + AgentCore 半天就部署上线了

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 的输入大概是这样：

业务需求：
创建自动化金融逾期处理流程 Multi Agent，
从逾期识别到触达处理，全流程自动化。

技术要求：
- 使用 Strands Agent SDK
- 部署在 Amazon Bedrock AgentCore
- 后端 Python，部署 ECR + Fargate
- 前端 React + Node.js
- 数据库 Aurora PostgreSQL Serverless with Data API
- 触达用 Amazon SNS 邮件通知
- 认证用 Amazon Cognito 集成 AgentCore

Kiro 花了大概十分钟，生成了三份文档。

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

业务流程是一条链：

逾期事件 → Orchestrator 接收
  → Data Agent 建案件 + 查客户数据
    → Scoring Agent 算 B卡/C卡 评分
      → Allocation Agent 匹配策略规则
        → Outreach Agent 发通知
          → Data Agent 记录结果

用 Strands Agent SDK 写 Agent，代码很清爽：

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 大概是这样：

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：

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 输出，外加一层解析校验：

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。

# 构建阶段
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 第一次查库的时候超时了。

解决办法：加重试逻辑 + 指数退避。

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…