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 集成 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 的 APIData Agent数据库读写query_database, insert_case, update_statusScoring Agent风险评分calculate_b_card, calculate_c_card, risk_profileAllocation Agent分拨决策apply_rules, select_channel, optimize_timingOutreach 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_idamazon.nova-pro-v1:0, region_nameus-west-2 ) scoring_agent Agent( modelmodel, 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_nameus-west-2 ) response client.create_runtime( runtimeNameoverdue-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 在哪一步出的错。踩坑实录分享几个我踩过的坑。坑 1Session ID 传丢了Orchestrator 调用 Scoring Agent 的时候我一开始没传 session ID。结果每次调用都是新会话之前 Data Agent 查到的客户信息Scoring Agent 压根不知道。修复方法简单——每次调用都带上同一个 session IDsession_id str(uuid.uuid4()) # 所有 Agent 调用共享同一个 session data_result invoke_agent( agent_namedata-agent, session_idsession_id, prompt查询客户 C001 的逾期信息 ) scoring_result invoke_agent( agent_namescoring-agent, session_idsession_id, prompt根据已有数据计算风险评分 )坑 2LLM 输出格式不稳定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.3GBAgentCore 拉取部署慢得让人抓狂。后来用 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 --frombuilder /usr/local/lib/python3.12 /usr/local/lib/python3.12 COPY . /app WORKDIR /app EXPOSE 8080 CMD [python, main.py]坑 4Aurora Serverless 冷启动Aurora PostgreSQL Serverless 如果一段时间没请求会暂停下次连接要等几秒冷启动。Data Agent 第一次查库的时候超时了。解决办法加重试逻辑 指数退避。import time def execute_with_retry(sql, paramsNone, max_retries3): for attempt in range(max_retries): try: return rds_client.execute_statement( resourceArncluster_arn, secretArnsecret_arn, databaseoverdue_db, sqlsql, parametersparams or [] ) except Exception as e: if attempt max_retries - 1: wait 2 ** attempt time.sleep(wait) else: raise时间复盘贴一下整个项目的时间线阶段耗时说明写初始 Prompt30min描述业务需求和技术要求Kiro 生成 Spec10min自动生成 requirements design tasks人工 Review15min检查方案合理性微调Kiro 生成代码2h按 tasks 逐步执行本地联调测试1h五个 Agent 端到端跑通AgentCore 部署30min配置 镜像推送 部署生产验证30min线上端到端测试合计~5h五个小时从需求到生产。换传统开发模式两周起步。适用场景判断最后聊聊什么场景适合这套方案。适合多 Agent 协同的复杂业务流程对安全隔离要求高金融、医疗、政务并发量波动大需要弹性扩缩需要会话记忆和可观测性不适合单 Agent 简单场景杀鸡用牛刀了对延迟要求在微秒级的实时交易系统总结一下Kiro Spec 模式让你「先想清楚再动手」AgentCore 让你「不用操心底层运维」。两个搭配起来Agent 上生产的成本确实降了一个量级。建议先从两个 Agent 的简单项目试手跑通流程后再搞复杂的。