From zero-shot forecast to purchase order with Amazon Bedrock AgentCore从零样本预测到采购订单：基于 Amazon Bedrock AgentCore 的实现

Authors: Hyunsoo Kim, Chloe Kwak
Learning level: 300 – Advanced Post type: Best Practices作者：Hyunsoo Kim, Chloe Kwak 学习级别：300 – 高级 文章类型：最佳实践

Every inventory manager faces the same question each morning: How much should I order today? The answer depends on dozens of variables (sales history, upcoming promotions, pricing changes, day-of-week seasonality, supplier lead times) and the cost of getting it wrong is asymmetric. Over-order and you carry capital in slow-moving stock. Under-order and you lose revenue, damage customer trust, and scramble for emergency replenishment.每天早上，每位库存经理都会面临同一个问题：今天应该订购多少？答案取决于几十个变量（销售历史、即将到来的促销活动、价格变动、周内季节性、供应商提前期），而决策失误的代价是不对称的。订购过多，会导致资金积压在周转缓慢的库存中；订购过少，则会损失收入、损害客户信任，并被迫进行紧急补货。

The case for zero-shot forecasting零样本预测的必要性

Classical time-series methods (ARIMA, Holt-Winters, seasonal decomposition) require per-SKU model fitting. A retailer with 10,000 SKUs must train, validate, and maintain 10,000 separate models. Each requires its own hyperparameter tuning, retraining schedule, and cold-start problem for new products. The operational burden scales linearly with catalog size, and the engineering team spends more time managing infrastructure than improving forecast quality.传统的时序方法（如 ARIMA、Holt-Winters、季节性分解）需要针对每个库存单位（SKU）进行模型拟合。一家拥有 10,000 个 SKU 的零售商必须训练、验证并维护 10,000 个独立模型。每个模型都需要进行超参数调优、重新训练计划，并面临新产品的冷启动问题。运营负担随产品目录规模线性增长，工程团队花费在管理基础设施上的时间远多于提升预测质量的时间。

Gradient boosting and deep learning approaches (LightGBM, DeepAR, Temporal Fusion Transformer) improve accuracy but compound the operational complexity: feature engineering pipelines, training jobs, model registries, A/B testing infrastructure. For many organizations, the time from “we want better forecasts” to “forecasts are running in production” often takes a full quarter or more.梯度提升和深度学习方法（如 LightGBM、DeepAR、Temporal Fusion Transformer）提高了准确性，但也增加了运营复杂性：特征工程流水线、训练任务、模型注册表、A/B 测试基础设施等。对于许多组织而言，从“我们想要更好的预测”到“预测在生产环境中运行”，往往需要一个完整的季度甚至更长时间。

From manual rules to automated decisions从手动规则到自动化决策

Even with a reliable forecast, converting a demand signal into a purchase order requires applying business rules: safety stock buffers, minimum order quantities, budget constraints, promotional lift adjustments. These rules are typically encoded in spreadsheets or institutional knowledge, applied inconsistently across buyers, and nearly impossible to audit or explain at scale.即使有了可靠的预测，将需求信号转化为采购订单也需要应用业务规则：安全库存缓冲、最小订购量、预算约束、促销提升调整等。这些规则通常编码在电子表格或机构知识中，在不同采购员之间的执行不一致，且在大规模场景下几乎无法审计或解释。

The architecture this post builds本文构建的架构

This post describes how to combine two complementary capabilities to address both problems simultaneously:本文介绍了如何结合两种互补的能力来同时解决上述两个问题：

• Amazon Chronos2: A time-series foundation model that performs zero-shot forecasting, returning probabilistic demand predictions without per-product training.Amazon Chronos2：一种时序基础模型，执行零样本预测，无需针对每个产品进行训练即可返回概率性需求预测。
• Multi-agent orchestration with the Strands Agents SDK and Amazon Bedrock AgentCore: A system of four LLM agents that coordinate deterministic tools, converting raw forecasts into validated purchase orders with full auditability.使用 Strands Agents SDK 和 Amazon Bedrock AgentCore 进行多智能体编排：一个由四个 LLM 智能体组成的系统，用于协调确定性工具，将原始预测转化为经过验证且具备完整可审计性的采购订单。

The result is an end-to-end inventory automation pipeline where adding a new product requires zero ML model training, adding a new business rule requires changing one tool, and each decision is auditable, observable, and recoverable from failure. In internal testing across 50 SKUs over a 4-week horizon, this architecture achieved a median weighted absolute percentage error (WAPE) of 12.3% (P50 forecast compared to actuals), reduced per-SKU onboarding time from 2–3 weeks of model training to under 5 minutes of CSV upload, and cut monthly inference cost from ~$1,091 (always-on GPU) to ~$15 (Serverless) — a 98% reduction. End-to-end pipeline latency averaged 8 seconds per SKU excluding cold start.其结果是一个端到端的库存自动化流水线：添加新产品无需训练机器学习模型，添加新业务规则只需更改一个工具，且每项决策均可审计、可观察并可在故障后恢复。在涵盖 50 个 SKU、为期 4 周的内部测试中，该架构实现了 12.3% 的中位数加权绝对百分比误差（WAPE，P50 预测与实际值对比），将每个 SKU 的上线时间从 2–3 周的模型训练缩短至 5 分钟以内的 CSV 上传，并将每月推理成本从约 1,091 美元（常驻 GPU）降低至约 15 美元（无服务器），降幅达 98%。排除冷启动后，端到端流水线延迟平均为每个 SKU 8 秒。

Solution overview解决方案概览

This section describes the end-to-end system architecture, explains why Chronos2 is well suited for inventory forecasting, and outlines the benefits of a multi-agent design over a monolithic approach.本节描述了端到端系统架构，解释了为什么 Chronos2 非常适合库存预测，并概述了多智能体设计相较于单体架构的优势。

End-to-end architecture端到端架构

The system is organized into three logical layers:系统分为三个逻辑层：

Data layer. Amazon Simple Storage Service (Amazon S3) serves as the single source of truth. A single CSV per product encodes both historical sales and future covariate values. Business rules (lead times, safety stock, warehouse capacity, minimum order quantities) live in a separate JSON config. Adding a new product requires only uploading these two files, with no changes to code.数据层。Amazon Simple Storage Service (Amazon S3) 作为单一事实来源。每个产品对应一个 CSV 文件，编码了历史销售数据和未来的协变量值。业务规则（提前期、安全库存、仓库容量、最小订购量）存储在单独的 JSON 配置中。添加新产品只需上传这两个文件，无需更改代码。

Inference layer. Amazon SageMaker Serverless Inference hosts the Chronos2 endpoint for zero-shot time-series forecasting. This is the only external model inference call in the pipeline — the LLM reasoning runs through Amazon Bedrock within the orchestration layer.推理层。Amazon SageMaker Serverless Inference 托管用于零样本时序预测的 Chronos2 端点。这是流水线中唯一的外部模型推理调用——LLM 推理通过编排层中的 Amazon Bedrock 运行。

Orchestration layer. Four LLM agents — Supervisor, Preprocessing, Forecasting, and Reporting — are built with the Strands Agents SDK and deployed on Amazon Bedrock AgentCore. Each agent uses Claude on Amazon Bedrock for reasoning and calls deterministic tools to execute the computational work.编排层。四个 LLM 智能体——主管（Supervisor）、预处理（Preprocessing）、预测（Forecasting）和报告（Reporting）——使用 Strands Agents SDK 构建并部署在 Amazon Bedrock AgentCore 上。每个智能体使用 Amazon Bedrock 上的 Claude 进行推理，并调用确定性工具来执行计算工作。

Amazon Bedrock AgentCore is a fully managed platform to build, deploy, and optimize agents at scale, with any framework or model. The orchestration layer runs on AgentCore, which provides six sub-services: Runtime, Gateway, Policy, Memory, Observability, and Evaluations. This system uses each of the six, but each for a specific, single purpose. The architecture deep dive section maps each service to the production concern it addresses in this design — including why the Gateway surface is deliberately small (one tool out of eight).Amazon Bedrock AgentCore 是一个全托管平台，可使用任何框架或模型大规模构建、部署和优化智能体。编排层运行在 AgentCore 之上，提供六个子服务：运行时（Runtime）、网关（Gateway）、策略（Policy）、内存（Memory）、可观测性（Observability）和评估（Evaluations）。本系统使用了这六个服务，但每个服务仅用于特定的单一目的。架构深度解析部分会将每个服务映射到其在本设计中解决的生产问题——包括为什么网关表面被有意设计得很小（八个工具中仅有一个）。

Why Chronos2: zero-shot, covariates, what-if为什么选择 Chronos2：零样本、协变量、假设分析

Chronos2 is an encoder-only transformer that closely follows the T5 encoder design, pre-trained on a large and diverse corpus of real-world time series. The model generates multi-step probabilistic forecasts using in-context learning and a group attention mechanism — no fine-tuning on your data required.Chronos2 是一种仅编码器的 Transformer 模型，紧随 T5 编码器设计，并在大规模、多样化的真实世界时序语料库上进行了预训练。该模型利用上下文学习和组注意力机制生成多步概率预测——无需对您的数据进行微调。

Three properties make it the right choice for inventory forecasting at scale:三个特性使其成为大规模库存预测的正确选择：

1. Zero-shot generalization: A new SKU requires no training job. Historical sales window in, probabilistic forecast out — including for products with sparse or short histories.零样本泛化：新 SKU 无需训练任务。输入历史销售窗口，输出概率预测——即使对于历史数据稀疏或较短的产品也是如此。
2. Covariate support: Chronos2 accepts past-only covariates (historical features known only for past periods) and known covariates (features whose future values are given for the forecast horizon, such as a scheduled promotion or price change). In the Python API these are passed via the context_df and future_df dataframes to pipeline.predict_df(). Covariates transform the model from a univariate forecaster into a conditional one.协变量支持：Chronos2 接受仅过去协变量（仅在过去周期已知的历史特征）和已知协变量（在预测范围内已知未来值的特征，例如计划中的促销或价格变动）。在 Python API 中，它们通过 context_df 和 future_df 数据帧传递给 pipeline.predict_df()。协变量将模型从单变量预测器转换为条件预测器。
3. What-if scenario analysis: Because covariates are explicit inputs, you can generate multiple forecasts — with a promotion and without one, at the current price and at a discounted price — and compare them before committing to an order.假设场景分析：由于协变量是显式输入，您可以生成多个预测——有促销和无促销、当前价格和折扣价格——并在提交订单前进行比较。

Chronos2 is well-suited for this workload because it satisfies all three requirements simultaneously: zero-shot inference (no per-SKU training), explicit support for both past-only and future covariates via the predict_df() API, and a one-click deployment path to Amazon SageMaker Serverless Inference. This combination means that onboarding a new product requires only data — no pipeline changes, no model registry entries, no retraining schedule. The evaluator framework introduced in the architecture deep dive makes it straightforward to benchmark any alternative forecasting model on the same traces without rebuilding the pipeline.Chronos2 非常适合此工作负载，因为它同时满足了所有三个要求：零样本推理（无需针对每个 SKU 进行训练）、通过 predict_df() API 对仅过去和未来协变量的显式支持，以及通往 Amazon SageMaker Serverless Inference 的一键部署路径。这种组合意味着上线新产品只需数据——无需更改流水线、无需模型注册表条目、无需重新训练计划。架构深度解析中引入的评估器框架使得在不重建流水线的情况下，在相同的跟踪记录上对任何替代预测模型进行基准测试变得非常简单。

Why multi-agent over monolithic为什么选择多智能体而非单体架构

A single LLM prompt that performs all reasoning steps — data loading, covariate selection, forecast interpretation, order calculation, validation, and result saving — would exceed practical context window limits for large catalogs, be impossible to unit test at the component level, and fail catastrophically when any single step encounters an error.一个执行所有推理步骤（数据加载、协变量选择、预测解释、订单计算、验证和结果保存）的单一 LLM 提示词，对于大型目录而言会超出实际上下文窗口限制，无法在组件级别进行单元测试，并且在任何单个步骤遇到错误时都会导致灾难性失败。

An agent-per-reasoning-responsibility architecture solves each of these problems directly. Critically, this architecture makes a firm distinction: LLM agents handle judgment. Deterministic tools handle computation. Bedrock inference happens in exactly four places: the four agents. The operations they coordinate (loading files, running the replenishment formula, generating charts, writing to S3) run as plain Python functions that the agents call as @tools. The agent determines when to call each tool and with what arguments: the tool itself contains no LLM inference. This separation keeps per-run LLM cost bounded and reasoning quality high by ensuring each agent’s context window carries only what it needs to reason about, not the raw byproducts of every tool call.“每个推理职责一个智能体”的架构直接解决了这些问题。关键在于，该架构做出了明确区分：LLM 智能体负责判断，确定性工具负责计算。Bedrock 推理仅发生在四个地方：即四个智能体。它们协调的操作（加载文件、运行补货公式、生成图表、写入 S3）作为普通 Python 函数运行，智能体将其作为 @tools 调用。智能体决定何时调用每个工具以及使用什么参数：工具本身不包含任何 LLM 推理。这种分离通过确保每个智能体的上下文窗口仅携带其推理所需的内容，而不是每次工具调用的原始副产品，从而限制了每次运行的 LLM 成本并保持了高质量的推理。

Prerequisites先决条件

Four things need to be in place before deploying this architecture. Other components (the S3 bucket, IAM roles, folder layout, and the agent runtime package) are provisioned by the CDK stack and deploy scripts described in the following sections.在部署此架构之前，需要准备好四件事。其他组件（S3 存储桶、IAM 角色、文件夹布局和智能体运行时包）由以下章节中描述的 CDK 堆栈和部署脚本进行配置。

• AWS account with Amazon Bedrock, Amazon SageMaker, and Amazon S3 access in the same AWS Region (the following examples assume us-east-1).在同一 AWS 区域（以下示例假设为 us-east-1）拥有 Amazon Bedrock、Amazon SageMaker 和 Amazon S3 访问权限的 AWS 账户。
• Amazon Bedrock model access for Claude Sonnet 4.5 (Anthropic), enabled in the Bedrock console under Model access → Manage model access. For model availability by Region, refer to Supported models by AWS Region in Amazon Bedrock .在 Bedrock 控制台的“模型访问权限 → 管理模型访问权限”下启用的 Claude Sonnet 4.5 (Anthropic) 的 Amazon Bedrock 模型访问权限。关于各区域的模型可用性，请参考 Amazon Bedrock 中的“按 AWS 区域支持的模型”。
• Chronos2 endpoint deployed on Amazon SageMaker Serverless Inference. The deployment procedure uses a single SageMaker Serverless endpoint configuration with the Chronos2 model package.部署在 Amazon SageMaker Serverless Inference 上的 Chronos2 端点。部署过程使用带有 Chronos2 模型包的单个 SageMaker Serverless 端点配置。
• Python 3.10+ and Node.js 20+ on the local machine. Install the SDKs and CLIs:

  pip install -e .                          # from repo root
  npm install -g aws-cdk @aws/agentcore

  Bash
  本地机器上安装 Python 3.10+ 和 Node.js 20+。安装 SDK 和 CLI： pip install -e . # 从仓库根目录 npm install -g aws-cdk @aws/agentcore

Technical implementation技术实现

This section walks through the data format, agent definitions, coordinator logic, and deployment configuration.本节将逐步介绍数据格式、智能体定义、协调器逻辑和部署配置。

Data format design数据格式设计

The input format intentionally blurs the boundary between historical and forecast periods. A single CSV file covers both:输入格式有意模糊了历史时期和预测时期之间的界限。单个 CSV 文件涵盖了两者：

date,sales,promotion,day_of_week,is_weekend,price
2024-01-01,120,0,1,0,29.99
2024-01-02,95,0,2,0,29.99
...
2024-01-20,140,0,6,1,29.99
2024-01-21,,1,7,1,24.99
2024-01-22,,1,1,0,24.99
2024-01-23,,0,2,0,29.99

Rows where sales are null define the forecast horizon. Covariates are fully populated for both historical and future periods. This design makes the distinction between past and future a data concern, not a code concern — the Preprocessing Agent reads the same schema regardless of forecast horizon length. When the operations team knows a promotion is planned next week, they fill in the promotion column for those future rows and re-upload the file.销售额为空的行定义了预测范围。协变量在历史和未来时期都已完全填充。这种设计使过去和未来的区分成为数据问题，而非代码问题——预处理智能体无论预测范围长度如何，读取的模式都是相同的。当运营团队知道下周有计划中的促销活动时，他们只需在未来行的促销列中填入数据并重新上传文件即可。

Product-level business rules live in a separate JSON config:产品级业务规则存储在单独的 JSON 配置中：

{
  "SKU-00142": {
    "name": "Wireless Earbuds Pro",
    "safety_stock": 150,
    "lead_time_days": 5,
    "warehouse_capacity": 2000,
    "min_order_quantity": 50,
    "unit_cost": 12.50,
    "supplier": "Supplier-A"
  }
}

By treating business rules as data rather than code, adjusting a supplier’s lead time or safety stock threshold requires only a config update in S3 — no deployment.通过将业务规则视为数据而非代码，调整供应商的提前期或安全库存阈值只需在 S3 中更新配置——无需部署。

The four LLM agents and their tools四个 LLM 智能体及其工具

The central design principle: use an LLM agent where the output depends on interpretation or context. Use a deterministic tool where the output is fully determined by the input.核心设计原则：在输出取决于解释或上下文时使用 LLM 智能体；在输出完全由输入决定时使用确定性工具。

Supervisor agent主管智能体 (Supervisor agent)

The Supervisor is the entry point for every user request. Its responsibility is pure orchestration: parse the user’s intent in natural language, construct the execution plan, route work to the three specialist agents in sequence, and handle conditional branching based on their outputs.主管是每个用户请求的入口点。其职责是纯粹的编排：解析用户意图的自然语言，构建执行计划，按顺序将工作路由给三个专业智能体，并根据它们的输出处理条件分支。

When a user sends “Run the weekly replenishment forecast for wireless earbuds — there’s a promotion this weekend,” the Supervisor:当用户发送“运行无线耳机的每周补货预测——这个周末有促销活动”时，主管会：

• Identifies the product scope and resolves “wireless earbuds” to its SKU.识别产品范围并将“无线耳机”解析为其 SKU。
• Notes the promotional context and passes it explicitly to the Preprocessing Agent.记录促销上下文并将其显式传递给预处理智能体。
• Constructs the sequential execution plan.构建顺序执行计划。
• Monitors agent outputs and triggers the conditional retry loop if validation fails.监控智能体输出，并在验证失败时触发条件重试循环。

This requires genuine LLM reasoning. The Supervisor is not a router with a hardcoded lookup table — it interprets ambiguous instructions, surfaces missing parameters as clarifying questions, and makes branching decisions based on downstream agent outputs.这需要真正的 LLM 推理。主管不是一个带有硬编码查找表的路由器——它解释模糊的指令，将缺失的参数作为澄清问题提出，并根据下游智能体的输出做出分支决策。

The Supervisor does not call data or computation tools directly. Its only job is to reason about the workflow.主管不直接调用数据或计算工具。它的唯一工作是思考工作流。

In production, Amazon Bedrock Guardrails protects each agent’s LLM reasoning steps as a mandatory control, not an optional add-on. The Supervisor agent — which interprets natural-language requests and makes branching decisions that ultimately determine order quantities — runs behind a Guardrails configuration that enforces content filtering, denied topic policies, and grounding validation against the structured tool outputs. This prevents the Supervisor from hallucinating constraint overrides or generating purchase decisions outside its authorized scope. For implementation details, refer to Amazon Bedrock Guardrails.在生产环境中，Amazon Bedrock Guardrails 将每个智能体的 LLM 推理步骤作为强制控制而非可选附加项进行保护。主管智能体（它解释自然语言请求并做出最终决定订购量的分支决策）运行在 Guardrails 配置之后，该配置强制执行内容过滤、拒绝主题策略以及针对结构化工具输出的接地验证。这防止了主管产生幻觉、覆盖约束或在授权范围之外生成采购决策。有关实施细节，请参考 Amazon Bedrock Guardrails。

Preprocessing agent预处理智能体 (Preprocessing agent)

The Preprocessing Agent loads raw data via deterministic tools and then applies LLM reasoning to decide how to prepare it for Chronos2.预处理智能体通过确定性工具加载原始数据，然后应用 LLM 推理来决定如何为 Chronos2 准备数据。

import json
import boto3
from strands import Agent, tool
from strands.models import BedrockModel

@tool
def load_sales_from_s3(product_id: str) -> dict:
    """Load sales time-series CSV from S3 for the given product ID."""
    response = s3.get_object(Bucket=BUCKET, Key=f"sales/{product_id}.csv")
    return parse_csv(response["Body"].read())

@tool
def load_inventory_from_s3() -> dict:
    """Load current inventory levels for all products from S3."""
    response = s3.get_object(Bucket=BUCKET, Key="inventory/current_stock.json")
    return json.loads(response["Body"].read())

@tool
def load_product_config_from_s3(product_id: str) -> dict:
    """Load business rules (lead time, safety stock, capacity) for a product."""
    response = s3.get_object(Bucket=BUCKET, Key="config/product_config.json")
    return json.loads(response["Body"].read())[product_id]

preprocessing_agent = Agent(
    model=BedrockModel(model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0"),
    tools=[load_sales_from_s3, load_inventory_from_s3, load_product_config_from_s3],
    system_prompt=(
        "You are a data preprocessing specialist. Load the required data, "
        "then decide which covariates to include in the Chronos2 input based on "
        "data quality and the business context provided by the Supervisor. "
        "Return a structured Chronos2 payload as JSON."
    )
)

The three load_* functions are plain Python — without LLM inference. The Preprocessing Agent’s LLM reasoning kicks in after the data is loaded, when it must decide which covariates to include. The Supervisor passes the user’s natural-language request (for example, “there’s a promotion this weekend”) down to the Preprocessing Agent as part of the task description, which signals that the promotion column must be included. But the agent also evaluates data quality: if promotion is sparsely populated or shows near-zero variance across the training period, the agent may exclude it and note the decision. A deterministic function does not make this call — it requires reading both the numbers and the business context together.三个 load_* 函数是普通的 Python 函数——没有 LLM 推理。预处理智能体的 LLM 推理在数据加载后启动，此时它必须决定包含哪些协变量。主管将用户的自然语言请求（例如，“这个周末有促销活动”）作为任务描述的一部分传递给预处理智能体，这标志着必须包含促销列。但智能体也会评估数据质量：如果促销列数据稀疏或在训练期间显示出近乎零的方差，智能体可能会排除它并记录该决定。确定性函数无法做出此判断——这需要同时读取数字和业务上下文。

Forecasting agent预测智能体 (Forecasting agent)

The Forecasting Agent calls the Chronos2 endpoint via a deterministic tool and then applies LLM reasoning to interpret the results.预测智能体通过确定性工具调用 Chronos2 端点，然后应用 LLM 推理来解释结果。

@tool
def call_chronos2(payload: str) -> dict:
    """
    Invoke the Chronos2 SageMaker endpoint.
    Retries up to 3 times with 30-second backoff for cold starts.
    """
    for attempt in range(3):
        try:
            response = sagemaker_runtime.invoke_endpoint(
                EndpointName=CHRONOS2_ENDPOINT,
                ContentType="application/json",
                Body=payload
            )
            return json.loads(response["Body"].read())
        except ClientError as e:
            if e.response["Error"]["Code"] == "ModelNotReadyException":
                time.sleep(30)
                continue
            raise
    raise TimeoutError(f"Chronos2 endpoint not ready after 3 attempts")

@tool
def calculate_order_quantity(
    forecast_p50: list,
    current_stock: int,
    safety_stock: int,
    lead_time_days: int,
    min_order_quantity: int
) -> dict:
    """Deterministic replenishment formula."""
    lead_time_demand = sum(forecast_p50[:lead_time_days])
    order_qty = max(0, lead_time_demand + safety_stock - current_stock)
    if 0 < order_qty < min_order_quantity:
        order_qty = min_order_quantity
    return {"order_quantity": int(order_qty), "lead_time_demand": int(lead_time_demand)}

@tool
def validate_constraints(
    order_quantity: int,
    current_stock: int,
    warehouse_capacity: int,
    budget_cap: float,
    unit_cost: float,
) -> dict:
    """Deterministic constraint check against warehouse capacity and budget."""
    new_stock = current_stock + order_quantity
    within_capacity = new_stock <= warehouse_capacity
    total_cost = order_quantity * unit_cost
    within_budget = total_cost <= budget_cap
    return {
        "approved": within_capacity and within_budget,
        "capacity_used": round(new_stock / warehouse_capacity, 2),
        "budget_used": round(total_cost, 2),
        "budget_remaining": round(budget_cap - total_cost, 2),
        "violations": [v for v in [
            None if within_capacity
                else f"Exceeds warehouse capacity ({new_stock}/{warehouse_capacity})",
            None if within_budget
                else f"Exceeds budget (${total_cost:.2f}/${budget_cap:.2f})",
        ] if v],
    }

forecasting_agent = Agent(
    model=BedrockModel(model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0"),
    tools=[call_chronos2, calculate_order_quantity, validate_constraints],
    system_prompt=(
        "You are a forecasting and order planning specialist. "
        "Invoke Chronos2 with the provided payload, interpret the probabilistic "
        "forecast results, calculate the recommended order quantity, and validate "
        "it against business constraints. Flag any anomalies with a brief explanation."
    )
)

call_chronos2, calculate_order_quantity, and validate_constraints are each deterministic functions. The Forecasting Agent’s LLM reasoning provides two things these tools cannot: anomaly contextualization (“day 7 P90/P50 ratio is 1.36 — above the 1.3 anomaly threshold, consistent with the promotional covariate for that day”) and a natural language rationale for the order recommendation (for example, “753 units covers a 5-day lead-time demand of 648 plus a 150-unit safety stock buffer, net of 45 current inventory”). The numbers in this rationale are drawn from data/product_config.json — the same values used in the Running the agent walkthrough later in this post.call_chronos2、calculate_order_quantity 和 validate_constraints 都是确定性函数。预测智能体的 LLM 推理提供了这些工具无法提供的两点：异常情境化（“第 7 天 P90/P50 比率为 1.36——高于 1.3 的异常阈值，与当天的促销协变量一致”）以及订单建议的自然语言理由（例如，“753 个单位涵盖了 648 个单位的 5 天提前期需求加上 150 个单位的安全库存缓冲，扣除 45 个单位的当前库存”）。此理由中的数字取自 data/product_config.json——与本文后面“运行智能体演练”中使用的值相同。

The probabilistic output — P10, P50, and P90 quantiles — is central to inventory planning, not incidental. Ordering to the P50 (median) without any buffer would mean running out of stock roughly half the time, which is why safety stock exists as a separate parameter. calculate_order_quantity uses the P50 forecast for expected lead-time demand, and the safety_stock parameter in the product config absorbs the uncertainty between P50 and P90 (teams typically tune safety stock toward a target service level such as P90 or P95). For products with high P90/P50 ratios — indicating volatile or promotion-driven demand — the Forecasting Agent flags the anomaly explicitly so the Reporting Agent can surface elevated uncertainty to the buyer rather than hiding it behind a single order number.概率输出（P10、P50 和 P90 分位数）对于库存规划至关重要，而非偶然。如果不加缓冲地按 P50（中位数）订购，意味着大约有一半的时间会缺货，这就是为什么安全库存作为单独参数存在的原因。calculate_order_quantity 使用 P50 预测来计算预期的提前期需求，而产品配置中的 safety_stock 参数吸收了 P50 和 P90 之间的不确定性（团队通常将安全库存调优至目标服务水平，如 P90 或 P95）。对于具有高 P90/P50 比率的产品（表明需求波动或由促销驱动），预测智能体会明确标记异常，以便报告智能体能够向采购员突出显示升高的不确定性，而不是将其隐藏在单个订单数字之后。

The violations array returned by validate_constraints is what makes the conditional retry loop actionable. When the constraint check fails, the array contains a human-readable string per violated constraint (for example, "Exceeds budget ($9412.50/$500.00)"), which the Forecasting Agent passes up to the Supervisor. The Supervisor uses this specific message, not a generic “validation failed” signal. Based on the violation details, it decides whether to re-invoke the Forecasting Agent with adjusted constraints or escalate to the user.validate_constraints 返回的违规数组是使条件重试循环可操作的关键。当约束检查失败时，数组包含每个违规约束的人类可读字符串（例如，“超出预算 ($9412.50/$500.00)”），预测智能体将其传递给主管。主管使用此特定消息，而不是通用的“验证失败”信号。根据违规详情，它决定是使用调整后的约束重新调用预测智能体，还是升级给用户。

Reporting agent报告智能体 (Reporting agent)

The Reporting Agent consumes the structured output from the Forecasting Agent and produces the final deliverables: a visualization and a persisted decision record. The tools are deterministic. The agent provides the natural language summary that makes the output actionable for a business user.报告智能体使用来自预测智能体的结构化输出，并生成最终交付成果：可视化图表和持久化的决策记录。工具是确定性的。智能体提供自然语言摘要，使输出对业务用户具有可操作性。

import io
import json
import boto3
import matplotlib
matplotlib.use("Agg")
import matplotlib.pyplot as plt
from strands import Agent, tool
from strands.models import BedrockModel

BUCKET = os.environ["INVENTORY_BUCKET"]

@tool
def generate_forecast_chart(forecast_data: str, output_path: str) -> str:
    """Generate forecast quantile chart and upload to S3.

    Args:
        forecast_data: JSON string (Strands serializes tool arguments as strings)
        output_path: S3 key for the output PNG
    """
    data = json.loads(forecast_data)
    forecast = data["forecast"]
    days = list(range(1, len(forecast["p50"]) + 1))

    fig, ax = plt.subplots(figsize=(10, 5))
    ax.fill_between(days, forecast["p10"], forecast["p90"],
                    alpha=0.2, color="#147EBA", label="P10-P90 range")
    ax.plot(days, forecast["p50"], color="#147EBA", linewidth=2, label="P50 median")
    ax.set_xlabel("Forecast day")
    ax.set_ylabel("Predicted demand (units)")
    ax.set_title(f"Demand forecast - {data.get('product_id', '')}")
    ax.legend()
    plt.tight_layout()

    buf = io.BytesIO()
    fig.savefig(buf, format="png", dpi=150, bbox_inches="tight")
    buf.seek(0)
    plt.close(fig)

    s3 = boto3.client("s3")
    s3.put_object(Bucket=BUCKET, Key=output_path,
                  Body=buf.read(), ContentType="image/png")
    return json.dumps({"chart_s3_path": f"s3://{BUCKET}/{output_path}", "status": "uploaded"})

@tool
def save_decision_record(decision_data: str, output_path: str) -> str:
    """Persist the complete decision record as JSON to S3."""
    s3 = boto3.client("s3")
    s3.put_object(
        Bucket=BUCKET,
        Key=output_path,
        Body=decision_data.encode("utf-8"),
        ContentType="application/json",
    )
    return json.dumps({"record_s3_path": f"s3://{BUCKET}/{output_path}", "status": "saved"})

reporting_agent = Agent(
    model=BedrockModel(model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0"),
    tools=[generate_forecast_chart, save_decision_record],
    system_prompt=(
        "You are a reporting specialist. Generate the forecast visualization, "
        "persist the decision record, and produce a concise natural language "
        "summary of the recommendation and its business rationale."
    )
)

Coordinator pattern: sequential + conditional retry协调器模式：顺序 + 条件重试

User Request
     │
     ▼
Supervisor Agent
     │
     ▼
Preprocessing Agent ──── tools: load_sales_from_s3,
     │                          load_inventory_from_s3,
     │                          load_product_config_from_s3
     ▼
Forecasting Agent ──────── tools: call_chronos2,
     │                            calculate_order_quantity,
     │                            validate_constraints
     ├── validated ──────► Reporting Agent ── tools: generate_forecast_chart,
     │                                               save_decision_record
     │                          │
     │                          ▼
     │                    Final Response
     │
     └── constraint violated
               │
               ▼
         back to Forecasting Agent
         (with adjusted constraints from Supervisor)
               │
               └── max 3 iterations, then escalate to user

Pattern: agents-as-tools模式：智能体即工具 (Agents-as-Tools)

The preceding coordinator diagram is a behavioral view. Structurally, this implementation follows the Agents-as-Tools pattern: the Supervisor is a single Strands agent whose tool list contains the three specialist agents, each wrapped as a @tool. There is no explicit multi-node graph in the Strands SDK’s orchestration layer — the graph is a single Supervisor node with max_node_executions=10 (enough headroom for the base preprocessing → forecasting → reporting sequence plus up to three retry iterations, then a safety stop). Orchestration happens inside the Supervisor’s tool-use loop.前面的协调器图是行为视图。在结构上，此实现遵循“智能体即工具”模式：主管是一个单一的 Strands 智能体，其工具列表包含三个专业智能体，每个都封装为 @tool。Strands SDK 的编排层中没有显式的多节点图——该图是一个单一的主管节点，max_node_executions=10（足以容纳基础的预处理→预测→报告序列，外加最多三次重试迭代，然后是安全停止）。编排发生在主管的工具使用循环内。

This matters for context isolation. Each specialist @tool invocation spawns a fresh Strands agent with its own context window, own system prompt, and its own tool subset. Results return to the Supervisor as a compressed labeled-output block (a CLUES_FORMAT envelope defined by the Strands SDK) that carries the specialist’s labeled output instead of its full reasoning transcript — so the Supervisor sees labeled deltas and its context stays bounded as the workflow grows.这对上下文隔离很重要。每次专门的 @tool 调用都会生成一个新的 Strands 智能体，拥有自己的上下文窗口、系统提示词和工具子集。结果以压缩的标记输出块（Strands SDK 定义的 CLUES_FORMAT 信封）返回给主管，该块携带专家的标记输出而不是其完整的推理记录——因此主管看到的是标记后的增量，随着工作流增长，其上下文保持在有限范围内。

Deploying to Amazon Bedrock AgentCore部署到 Amazon Bedrock AgentCore

The preceding Strands agent definitions run as local Python processes with Amazon Bedrock as the LLM backbone. To move them to managed execution, package the Supervisor entry point as an AgentCore application:前面的 Strands 智能体定义作为本地 Python 进程运行，以 Amazon Bedrock 作为 LLM 骨干。要将其移动到托管执行，请将主管入口点打包为 AgentCore 应用程序：

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from memory.session import get_session_manager
from observability.tracing import set_session_context
from src.graph.nodes import supervisor_node

app = BedrockAgentCoreApp()

@app.entrypoint
async def handler(payload: dict, context=None):
    user_request = payload.get("prompt", payload.get("user_request", ""))
    session_id = getattr(context, "session_id", None) or payload.get("session_id", "default-session")
    actor_id = getattr(context, "user_id", None) or payload.get("actor_id", "system")

    # Attach telemetry context for this session
    set_session_context(session_id, product_id=payload.get("product_id"))

    # Create memory session manager (returns None if MEMORY_ID not configured)
    session_manager = get_session_manager(session_id, actor_id)
    result = await supervisor_node(task={"request": user_request}, session_manager=session_manager)
    return result.get("text", "No response generated.")

Deploy with the AgentCore CLI: agentcore deploy. AgentCore wraps each invocation in an isolated microVM, injects session context for short-term memory reads and writes, and streams agent traces automatically to Amazon CloudWatch — no additional instrumentation required. Full end-to-end deployment is a sequence of steps — CDK infrastructure, Gateway with save_decision registered, Cedar policies, Memory resource, Runtime package, and post-deploy Evaluations setup — orchestrated by a single deployment script.使用 AgentCore CLI 部署：agentcore deploy。AgentCore 将每次调用封装在隔离的微型虚拟机（microVM）中，注入用于短期内存读写的会话上下文，并自动将智能体跟踪记录流式传输到 Amazon CloudWatch——无需额外的仪器。完整的端到端部署是一系列步骤——CDK 基础设施、注册了 save_decision 的网关、Cedar 策略、内存资源、运行时包和部署后评估设置——由单个部署脚本协调。

The sequential chain is enforced by data dependency: the Forecasting Agent cannot run without the preprocessed payload. The Reporting Agent cannot run without a validated order decision.顺序链由数据依赖性强制执行：没有预处理的有效负载，预测智能体无法运行。没有经过验证的订单决策，报告智能体无法运行。

The conditional retry loop handles constraint violations as a first-class workflow state rather than an error condition. When validate_constraints returns approved: false, the Forecasting Agent surfaces the violation explanation. The Supervisor interprets it, adjusts the constraint parameters (for example, reducing the order to fit within the budget cap), and re-invokes the Forecasting Agent. The Supervisor tracks iteration count in the short-term session memory of AgentCore and escalates to the user if three iterations do not converge — avoiding silent infinite loops.条件重试循环将约束违规视为一等工作流状态，而非错误条件。当 validate_constraints 返回 approved: false 时，预测智能体会显示违规解释。主管对其进行解释，调整约束参数（例如，减少订单以符合预算上限），并重新调用预测智能体。主管在 AgentCore 的短期会话内存中跟踪迭代次数，如果三次迭代仍未收敛，则升级给用户——避免了静默的无限循环。

Cost optimization: scale to zero成本优化：缩减至零

The most significant cost decision is the SageMaker deployment mode for the Chronos2 endpoint.最重要的成本决策是 Chronos2 端点的 SageMaker 部署模式。

For batch inventory forecasting — a nightly or weekly job — a 30–60 second cold start is fully acceptable. Serverless Inference reduces inference costs by over 98% compared to an always-on GPU endpoint.对于批量库存预测（每晚或每周任务），30–60 秒的冷启动是完全可以接受的。与常驻 GPU 端点相比，无服务器推理将推理成本降低了 98% 以上。

The AgentCore Runtime follows the same scale-to-zero cost model: microVM isolation per session, up to 8-hour session duration, and no idle cost between workflow runs. Both the agent runtime and the inference endpoint scale to zero when not in use.AgentCore 运行时遵循相同的缩减至零成本模型：每个会话的微型虚拟机隔离，最长 8 小时的会话持续时间，工作流运行之间没有空闲成本。智能体运行时和推理端点在不使用时都会缩减至零。

How the numbers break down. The $15/month Serverless estimate assumes approximately 500 invocations averaging eight seconds of compute each, priced against the ml.g5.xlarge Serverless rate, with storage and inter-service data transfer excluded (the forecast payload and response each sit well under a megabyte). The $1,091/month always-on estimate is a ml.g5.2xlarge endpoint running 24×7, which pays for idle GPU memory every hour the agent is not forecasting. For nightly or weekly batch jobs, the duty cycle makes Serverless the correct default. For latency-sensitive real-time forecasting with a high invocation rate, the break-even point is roughly a few thousand invocations per month and tips toward the always-on endpoint.成本构成分析。每月 15 美元的无服务器估算假设大约 500 次调用，每次平均计算时间 8 秒，按 ml.g5.xlarge 无服务器费率定价，不包括存储和跨服务数据传输（预测有效负载和响应均远小于 1MB）。每月 1,091 美元的常驻估算是一个 24×7 运行的 ml.g5.2xlarge 端点，它需要为智能体未进行预测的每小时空闲 GPU 内存付费。对于每晚或每周的批处理任务，工作周期使得无服务器成为正确的默认设置。对于高调用频率的延迟敏感型实时预测，盈亏平衡点大约是每月几千次调用，之后倾向于常驻端点。

Architecture deep dive: design patterns and trade-offs架构深度解析：设计模式与权衡

This section examines the key design decisions behind the system: how to decompose work into agents versus tools, how agents communicate through data contracts, and how to handle failures and control costs.本节检查系统背后的关键设计决策：如何将工作分解为智能体与工具，智能体如何通过数据契约进行通信，以及如何处理故障和控制成本。

The agent versus tool decision framework智能体与工具的决策框架

The most consequential design decision in a multi-agent system is not which framework to use or how many agents to create — it is deciding, for each unit of work, whether it requires an LLM or a deterministic function.多智能体系统中最重要的设计决策不是使用哪个框架或创建多少智能体——而是对于每个工作单元，决定它需要 LLM 还是确定性函数。

The practical test:实践测试：

“If I fix the input, will the output always be the same?”“如果我固定输入，输出是否总是相同的？”

• Yes → Implement as a @tool. The LLM calls it. The function does the work.是 → 实现为 @tool。LLM 调用它。函数执行工作。
• No → The agent’s LLM reasoning IS the logic. The variability is intentional.否 → 智能体的 LLM 推理就是逻辑。变异是有意的。

Applying this test to every component in this system:将此测试应用于本系统中的每个组件：

The pattern: deterministic computation belongs in tools. Judgment, interpretation, and context-dependent recommendation belong in agent reasoning. Wrapping a deterministic formula in an LLM agent adds cost, latency, and non-determinism with no benefit. Asking a deterministic function to interpret “there’s a promotion next week” will fail.模式：确定性计算属于工具。判断、解释和上下文相关的建议属于智能体推理。将确定性公式包装在 LLM 智能体中会增加成本、延迟和不确定性，而没有任何好处。要求确定性函数解释“下周有促销活动”将会失败。

This framework also prevents scope creep. When a new requirement arrives — “add a second validation check for seasonal buffer stock” — the answer is clear: add a @tool, not a new agent.该框架还可以防止范围蔓延。当出现新需求时——“为季节性缓冲库存添加第二个验证检查”——答案很明确：添加一个 @tool，而不是一个新的智能体。

Data contract design: structured JSON between agents数据契约设计：智能体之间的结构化 JSON

Each agent in the sequential chain outputs a typed JSON structure that the next agent consumes. A representative contract between the Forecasting Agent and the Reporting Agent:顺序链中的每个智能体都输出一个下一个智能体可以消费的类型化 JSON 结构。预测智能体和报告智能体之间的代表性契约：

{
  "product_id": "SKU-00142",
  "forecast_horizon_days": 14,
  "covariates_used": ["promotion", "price", "day_of_week"],
  "forecast": {
    "p10": [95, 98, 118, 128, 105, 112, 135, 92, 96, 100, 105, 112, 140, 148],
    "p50": [110, 115, 145, 158, 120, 128, 158, 106, 110, 115, 119, 127, 154, 166],
    "p90": [132, 138, 183, 206, 150, 160, 215, 130, 138, 150, 155, 165, 195, 210]
  },
  "order_decision": {
    "order_quantity": 753,
    "lead_time_demand": 648,
    "safety_stock": 150,
    "current_stock": 45,
    "supplier": "Supplier-A",
    "approved": true,
    "warehouse_utilization": 0.40
  },
  "anomaly_flags": [
    {
      "day": 7,
      "note": "P90/P50 ratio of 1.36 on day 7 exceeds the 1.3 anomaly threshold; elevated uncertainty consistent with the promotional covariate on that day"
    }
  ],
  "rationale": "Recommended order of 753 units covers a 5-day lead-time demand of 648 units plus a 150-unit safety stock buffer, net of 45 units current stock. Warehouse utilization after delivery: 40%.",
  "model": "chronos2",
  "inference_latency_ms": 1840
}

The contract is explicit about which covariates were actually used (the Preprocessing Agent’s decision is visible and auditable), includes the order rationale as a first-class field, and carries anomaly flags in structured form rather than buried in prose. This makes the contract machine-readable for downstream tools and human-readable for debugging.该契约明确了实际使用了哪些协变量（预处理智能体的决定是可见且可审计的），将订单理由作为一等字段包含在内，并以结构化形式携带异常标志，而不是埋在散文中。这使得契约对于下游工具是机器可读的，对于调试是人类可读的。

Implicit coupling through unstructured text — where one agent returns a paragraph and the next tries to extract numbers from it — is the most common failure mode in multi-agent systems. Explicit JSON contracts prevent it.通过非结构化文本进行的隐式耦合——其中一个智能体返回一段话，下一个试图从中提取数字——是多智能体系统中最常见的故障模式。显式 JSON 契约可以防止这种情况。

Failure handling: retry, degradation, and isolation故障处理：重试、降级和隔离

Three failure strategies, matched to component criticality:三种故障策略，对应组件的关键性：

Per-agent retry with backoff: Applied to load_* tools (S3 transient errors) and call_chronos2 (SageMaker Serverless cold starts). The Forecasting Agent’s tool handles cold starts with up to 3 retries at 30-second intervals, catching ModelNotReadyException transparently before surfacing an error to the agent.带退避的每智能体重试：应用于 load_* 工具（S3 瞬态错误）和 call_chronos2（SageMaker 无服务器冷启动）。预测智能体的工具以 30 秒间隔最多重试 3 次来处理冷启动，在向智能体显示错误之前透明地捕获 ModelNotReadyException。

Graceful degradation: If the Preprocessing Agent determines that a covariate column is too sparse to be reliable, it proceeds without that covariate and notes the degradation in the output contract. The Forecasting Agent receives a valid — if potentially less accurate — input and continues. The Reporting Agent surfaces the degradation flag in its summary.优雅降级：如果预处理智能体确定某个协变量列过于稀疏而不可靠，它将在没有该协变量的情况下继续，并在输出契约中记录降级。预测智能体接收到有效（虽然可能不太准确）的输入并继续。报告智能体在其摘要中显示降级标志。

Failure isolation for non-critical paths: generate_forecast_chart and save_decision_record run within the Reporting Agent. If chart generation fails (rendering error, S3 write timeout), the Reporting Agent can still complete its primary output: the natural language summary and the decision record. The order recommendation is never blocked by a visualization failure.非关键路径的故障隔离：generate_forecast_chart 和 save_decision_record 在报告智能体中运行。如果图表生成失败（渲染错误、S3 写入超时），报告智能体仍然可以完成其主要输出：自然语言摘要和决策记录。订单建议绝不会因可视化失败而受阻。

In-process versus gateway: a second boundary进程内与网关：第二道边界

The agent versus tool framework draws one line: is the output determined by the input? A second line sits underneath it, and it matters just as much for a production system: does this tool cross a trust, durability, or cost-of-mistake boundary?智能体与工具框架划出了一条线：输出是否由输入决定？第二条线位于其下方，对于生产系统同样重要：该工具是否跨越了信任、持久性或错误代价的边界？

The practical test:

“If the agent hallucinates and calls this tool wrongly, does the mistake propagate to external systems or stop at the agent’s memory?”“如果智能体产生幻觉并错误地调用此工具，错误是传播到外部系统，还是停留在智能体的内存中？”

• Stops at the agent → In-process Strands @tool. The agent’s IAM role and Strands type system already bound it. Adding Gateway adds latency and cost with no safety gain.停留在智能体 → 进程内 Strands @tool。智能体的 IAM 角色和 Strands 类型系统已经限制了它。添加网关会增加延迟和成本，而没有任何安全收益。
• Propagates externally → Gateway. This is where Cedar authorization, JWT identity, and the audit trail of “who asked for this write, and what was persisted” need to live.传播到外部 → 网关。这是 Cedar 授权、JWT 身份以及“谁请求了此写入，以及持久化了什么”的审计跟踪需要存在的地方。

Applying this to every tool in the system:将此应用于系统中的每个工具：

Of the eight tools in this system, exactly one needs Gateway. That proportion is the norm, not the exception: most “tools” in an agent system are reads and pure functions where Gateway adds cost without adding safety. The services AgentCore provides are opt-in for a reason — pick the one sub-service that guards each distinct boundary, not all six for every tool.在该系统的八个工具中，只有一个需要网关。这种比例是常态，而非例外：智能体系统中的大多数“工具”都是读取和纯函数，网关在其中增加了成本而没有增加安全性。AgentCore 提供的服务是可选的，原因在于——选择一个保护每个不同边界的子服务，而不是为每个工具使用所有六个服务。

A natural follow-up: generate_forecast_chart also writes to S3 — why is it in-process rather than behind the Gateway? Because the chart is a visualization, not a decision of record. If it fails or is silently wrong, the order recommendation still stands and the write can simply be retried. save_decision is the opposite: once the decision record is persisted, downstream systems treat the order as real. The Gateway earns its place where a faulty write would create downstream inconsistency, not where it would at worst inconvenience a buyer.一个自然的后续问题：generate_forecast_chart 也写入 S3——为什么它是进程内的而不是在网关之后？因为图表是可视化，而不是记录决策。如果它失败或静默错误，订单建议仍然有效，并且写入可以简单地重试。save_decision 则相反：一旦决策记录被持久化，下游系统就会将订单视为真实订单。网关在错误写入会导致下游不一致的地方发挥作用，而不是在最坏情况下只会给买家带来不便的地方。

The Gateway Lambda (mcp/lambda/handler.py) exposes save_decision as an MCP-compatible tool endpoint. Infrastructure complexity stays proportional to the actual policy surface, not to the number of tools the agent calls.网关 Lambda (mcp/lambda/handler.py) 将 save_decision 公开为 MCP 兼容的工具端点。基础设施复杂性与实际策略表面保持比例，而不是与智能体调用的工具数量成比例。

Cost-aware architecture: token budget per agent成本感知架构：每个智能体的令牌预算

Beyond infrastructure cost, the four-agent design enables explicit token budget allocation. Each agent’s context window is bounded by its single responsibility:除了基础设施成本外，四智能体设计还实现了显式的令牌预算分配。每个智能体的上下文窗口都由其单一职责限制：

This partitioning keeps per-run LLM inference cost flat as catalog size scales. A monolithic agent carrying all data, all conversation history, and all intermediate results through every step would accumulate a context window that grows with catalog size and conversation length — and incur that cost on every invocation.这种分区使得每次运行的 LLM 推理成本随着目录规模的扩大而保持平稳。一个在每一步都携带所有数据、所有对话历史和所有中间结果的单体智能体，其上下文窗口会随着目录规模和对话长度的增加而积累——并在每次调用时产生这些成本。

One boundary per AgentCore service每个 AgentCore 服务一个边界

The two decision frameworks discussed earlier (agent versus tool, in-process versus gateway) leave us with a clear map of where each AgentCore sub-service earns its place in this system. The following table maps each service to a single production concern. The paragraphs that follow explain why that service is the right answer to that concern — not only what the service does.前面讨论的两个决策框架（智能体与工具、进程内与网关）为我们提供了一张清晰的地图，标明了每个 AgentCore 子服务在本系统中发挥作用的位置。下表将每个服务映射到一个单一的生产关注点。随后的段落解释了为什么该服务是该问题的正确答案——不仅是服务做了什么。

Runtime guards where agents execute. AgentCore Runtime hosts the Supervisor inside a per-session microVM with up to 8-hour session duration and zero idle cost between runs. For batch inventory forecasting — weekly or nightly jobs — paying for an always-on container is waste. Runtime provides session isolation and scale-to-zero-between-sessions as the default behavior, so the team does not have to engineer either separately.运行时保护智能体执行的位置。AgentCore 运行时将主管托管在每个会话的微型虚拟机中，会话持续时间最长 8 小时，运行之间没有空闲成本。对于批量库存预测（每周或每晚任务），支付常驻容器的费用是浪费。运行时提供会话隔离和会话间缩减至零作为默认行为，因此团队不必单独设计这两者。

Gateway and Policy guard what writes are allowed to reach external systems. Gateway is designed to be paired with Policy: Gateway validates who is calling (JWT from Cognito), Policy decides whether this specific call is allowed (Cedar evaluates principal, action, resource, and the full tool-call payload via context.input). Without Policy, Gateway would grant each authenticated caller access to each registered tool.网关和策略保护允许哪些写入到达外部系统。网关旨在与策略配对：网关验证调用者是谁（来自 Cognito 的 JWT），策略决定是否允许此特定调用（Cedar 评估主体、操作、资源以及通过 context.input 获得的完整工具调用有效负载）。如果没有策略，网关将授予每个经过身份验证的调用者访问每个已注册工具的权限。

Because only save_decision is registered on the Gateway, the authorization surface is scoped to the single point where an order becomes a persisted record — the last gate before downstream systems (dashboards, ERP integration) treat the decision as real. Two Cedar policies apply:因为只有 save_decision 在网关上注册，所以授权表面被限制在订单成为持久化记录的单点——即下游系统（仪表板、ERP 集成）将决策视为真实决策之前的最后一道关卡。应用两条 Cedar 策略：

• allow_write_reporting_only — save_decision may only be invoked by the Reporting workflow’s identity.allow_write_reporting_only — save_decision 只能由报告工作流的身份调用。
• deny_high_value_orders — any save_decision call where context.input.budget_used > 50000 is denied, regardless of principal:deny_high_value_orders — 任何 context.input.budget_used > 50000 的 save_decision 调用都会被拒绝，无论主体是谁：

forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InventoryTools___save_decision",
  resource is AgentCore::Gateway
) when {
  context.input has budget_used &&
  context.input.budget_used > 50000
};

Putting the high-value deny anywhere upstream — say, on calculate_order — would be ineffective: the agent could re-run the calculation until it passed, and the denial wouldn’t map to any durable effect. The policy is meaningful only at the write boundary.将高价值拒绝放在上游的任何地方——例如在 calculate_order 上——都是无效的：智能体可以重新运行计算直到通过，并且拒绝不会映射到任何持久影响。该策略仅在写入边界处才有意义。

Memory guards what the agent carries across sessions. AgentCore Memory supports three long-term strategies. This system uses two of them: semanticMemoryStrategy for SKU-level forecast accuracy history and userPreferenceMemoryStrategy for constraint overrides such as “this buyer always sets a 20% higher safety stock for electronics.” summaryMemoryStrategy is not used here because session-level summarization adds little for a structured forecast workflow. The Strands AgentCoreMemorySessionManager wires these into the Supervisor with no bespoke retrieval code.内存保护智能体在会话间携带的内容。AgentCore 内存支持三种长期策略。本系统使用了其中两种：用于 SKU 级预测准确性历史的 semanticMemoryStrategy 和用于约束覆盖（例如“该买家总是为电子产品设置高出 20% 的安全库存”）的 userPreferenceMemoryStrategy。此处未使用 summaryMemoryStrategy，因为会话级摘要对于结构化预测工作流几乎没有增加价值。Strands AgentCoreMemorySessionManager 将这些连接到主管中，无需定制检索代码。

Observability guards whether we can reconstruct why a decision was made. Each agent invocation — inputs, outputs, tool calls, retry attempts, latency — is traced automatically and streamed to Amazon CloudWatch. For an inventory pipeline, each order decision acquires a complete, auditable trail: which agent ran, which tools were called, what Chronos2 returned, and why the Forecasting Agent recommended a specific quantity. CloudWatch Logs Insights queries surface operational patterns like “which SKUs trigger the most constraint violations” or “which products show the highest P90/P50 forecast uncertainty” — directly informing improvements to business rules and covariate selection without re-running the pipeline.可观测性保护我们是否能重构决策原因。每次智能体调用——输入、输出、工具调用、重试尝试、延迟——都会自动跟踪并流式传输到 Amazon CloudWatch。对于库存流水线，每个订单决策都获得了一个完整的、可审计的跟踪记录：哪个智能体运行了，调用了哪些工具，Chronos2 返回了什么，以及为什么预测智能体建议了特定数量。CloudWatch Logs Insights 查询显示了操作模式，如“哪些 SKU 触发了最多的约束违规”或“哪些产品显示出最高的 P90/P50 预测不确定性”——直接为业务规则和协变量选择的改进提供信息，而无需重新运行流水线。

Evaluations guards whether the agent is still behaving after deployment. AgentCore Evaluations runs online quality monitoring against a sampled portion of production traffic (configurable. This system samples 100% during initial rollout). Two built-in evaluators — Builtin.GoalSuccessRate and Builtin.Helpfulness — provide generic quality signal, and a custom LLM-as-a-Judge evaluator scores constraint compliance on a 3-point scale:评估保护智能体在部署后是否仍在正常运行。AgentCore 评估针对生产流量的采样部分运行在线质量监控（可配置。本系统在初始推出期间采样 100%）。两个内置评估器——Builtin.GoalSuccessRate 和 Builtin.Helpfulness——提供通用质量信号，自定义“LLM 即评委”评估器根据 3 分制对约束合规性进行评分：

• 1.0 — Silent violation: order violates constraints and the agent did not flag it.1.0 — 静默违规：订单违反约束且智能体未标记它。
• 2.0 — Flagged violation: order violates constraints but the agent explicitly surfaced the flag.2.0 — 已标记违规：订单违反约束但智能体明确显示了标志。
• 3.0 — Compliant: order respects all constraints.3.0 — 合规：订单遵守所有约束。

The scale deliberately rewards agents that flag violations rather than hide them. This is the failure mode the retry loop is designed to prevent, and the evaluator is designed to detect. Without this rubric, an agent that quietly truncates orders to fit the budget scores the same as one that escalates to the user — even though only the second is safe for production. The 3-point rubric catches the failure mode where an agent hides a constraint violation. The next subsection adds a second evaluator for the complementary question — was the forecast itself accurate?该量表特意奖励那些标记违规而不是隐藏违规的智能体。这是重试循环旨在防止的故障模式，也是评估器旨在检测的故障模式。没有这个准则，一个悄悄截断订单以符合预算的智能体与一个升级给用户的智能体得分相同——尽管只有后者对于生产是安全的。3 分制准则捕获了智能体隐藏约束违规的故障模式。下一小节为补充问题添加了第二个评估器——预测本身准确吗？

The throughline: AgentCore is not a monolithic “agent platform” you either adopt or refuse. It is a set of services, each addressing one specific concern that production agent systems face. Picking the right service for each concern — and not stretching one service to cover two — is the architecture work. The preceding map is the output of that work for this system. The map for a different domain (customer support, code generation, research) will look different, but the exercise of drawing one is the same.主线：AgentCore 不是一个您要么采用要么拒绝的单体“智能体平台”。它是一组服务，每个服务都解决生产智能体系统面临的一个特定问题。为每个问题选择正确的服务——而不是强行用一个服务覆盖两个问题——是架构工作。前面的地图是该系统这项工作的产出。不同领域（客户支持、代码生成、研究）的地图看起来会不同，但绘制地图的练习是一样的。

Two layers of evaluation: behavior and accuracy两层评估：行为与准确性

The Evaluations described earlier answer one question: did the agent behave safely? That is necessary but not sufficient. For an inventory system, a second question is equally important: was the forecast the agent produced actually accurate? An agent that flags each constraint violation correctly is still useless if its P50 forecast is systematically off by 30%.前面提到的评估回答了一个问题：智能体（agent）的行为是否安全？这是必要的，但还不够。对于库存系统，第二个问题同样重要：智能体生成的预测是否真正准确？如果一个智能体能正确标记出每一次约束违规，但其 P50 预测系统性地偏离了 30%，那么它依然是无用的。

These two questions map to the two evaluator types that AgentCore Evaluations supports. The choice between them follows the same logic as the agent versus tool framework from the architecture deep dive, one layer up: if the correct output is fully determined by the inputs, use a deterministic function, not an LLM. A forecast accuracy score is a calculation, not a judgment call.这两个问题对应着 AgentCore Evaluations 支持的两种评估器类型。它们之间的选择遵循与架构深度解析中智能体与工具框架相同的逻辑，即高出一个层级：如果正确的输出完全由输入决定，请使用确定性函数，而不是大语言模型（LLM）。预测准确度评分是一项计算，而不是主观判断。

The pattern: agent behavior needs subjective scoring. Forecast accuracy needs arithmetic. Use the evaluator type that matches the question, not the one that feels more sophisticated.模式如下：智能体行为需要主观评分，而预测准确度需要算术计算。请使用与问题相匹配的评估器类型，而不是选择听起来更高级的那一种。

LLM-as-a-Judge evaluators score subjective dimensions — did the agent flag the violation, was the rationale coherent, was the response helpful. Good for behavior, wrong tool for arithmetic.“LLM 作为评判者”（LLM-as-a-Judge）评估器用于对主观维度进行评分，例如：智能体是否标记了违规、逻辑是否连贯、回复是否有帮助。这适用于评估行为，但对于算术计算来说是错误的工具。

Code-based evaluators invoke a Lambda function against the session trace with optional ground truth injected via evaluationReferenceInputs. Good for deterministic metrics — WAPE, signed bias, pinball loss, coverage — that have a correct numeric answer.基于代码的评估器通过 evaluationReferenceInputs 注入可选的基准真值（ground truth），针对会话追踪记录调用 Lambda 函数。这适用于具有正确数值答案的确定性指标，如 WAPE（加权平均百分比误差）、符号偏差（signed bias）、分位数损失（pinball loss）和覆盖率（coverage）。

Forecast accuracy evaluator (code-based)预测准确度评估器（基于代码）

The evaluator is a Lambda function that reads the Chronos2 forecast from the session trace, pairs each horizon day with the actual sales value supplied as ground truth, and returns WAPE as the primary numeric score alongside signed bias, pinball loss at P90, and P10–P90 coverage.该评估器是一个 Lambda 函数，它从会话追踪记录中读取 Chronos2 预测结果，将每个预测时段的天数与作为基准真值提供的实际销售额进行配对，并返回 WAPE 作为主要数值分数，同时还会返回符号偏差、P90 分位数损失以及 P10–P90 覆盖率。

# lambda/forecast_accuracy_evaluator/handler.py
import numpy as np

def handler(event, context):
    """Code-based evaluator for forecast accuracy.
    Runs after actual sales are known (horizon + lead time later)."""
    spans = event["evaluationInput"]["sessionSpans"]
    ground_truth = event.get("evaluationReferenceInputs", [])

    forecast = extract_forecast_from_spans(spans)  # Forecasting Agent span
    actual = np.array([g["actual_sales"] for g in ground_truth])
    p10 = np.array(forecast["p10"])
    p50 = np.array(forecast["p50"])
    p90 = np.array(forecast["p90"])

    if len(actual) != len(p50):
        return {
            "errorCode": "HORIZON_MISMATCH",
            "errorMessage": f"forecast={len(p50)}, actual={len(actual)}",
        }

    # Primary metric: WAPE (weighted absolute percentage error).
    # Preferred over MAPE because it weights errors by volume, avoiding
    # MAPE's well-known blow-up on low-volume days.
    wape = float(np.abs(actual - p50).sum() / actual.sum())

    # Signed bias (SCM convention: bias = forecast - actual, normalised).
    # Positive => chronic over-forecast => excess inventory risk.
    # Negative => chronic under-forecast => stock-out risk.
    bias = float((p50 - actual).sum() / actual.sum())

    # Pinball loss at P90:
    #   L_q(y, ŷ) = max(q·(y-ŷ), (q-1)·(y-ŷ))
    # At q=0.9, under-coverage (y > ŷ_p90) is penalised 9x more than
    # over-coverage — matches the operational cost of stock-outs.
    q = 0.9
    diff = actual - p90
    pinball_p90 = float(np.mean(np.maximum(q * diff, (q - 1) * diff)))

    # Coverage of the P10–P90 band (nominal target: 0.80).
    coverage = float(((actual >= p10) & (actual <= p90)).mean())

    # Composite label. Thresholds are retail-demand defaults; tune per
    # catalog. WAPE < 15% aligns with M5 competition 'strong' baseline.
    if wape < 0.15 and abs(bias) < 0.05 and 0.75 <= coverage <= 0.85:
        label = "ACCURATE"
    elif wape < 0.25:
        label = "ACCEPTABLE"
    else:
        label = "POOR"

    return {
        "label": label,
        "value": wape,  # primary score surfaced in CloudWatch
        "explanation": (
            f"WAPE={wape:.3f}, bias={bias:+.3f}, "
            f"pinball@P90={pinball_p90:.2f}, coverage={coverage:.2%}"
        ),
    }

A note on thresholds. WAPE < 15 percent is a common ‘strong baseline’ reference for retail demand at SKU-week granularity, anchored by the M5 forecasting competition. Treat the cut-offs as starting values and tune per catalog. The coverage target (0.75–0.85 for a P10–P90 band) and the pinball loss together tell you whether the quantiles are calibrated: if coverage drifts below the band year-over-year while point WAPE stays flat, the model has grown over-confident and the safety stock multiplier, not the point forecast, is the thing to revisit.关于阈值的说明。以 M5 预测竞赛为基准，WAPE < 15% 是 SKU 周粒度零售需求常见的“强基准”参考。请将这些临界值视为起始值，并针对每个目录进行调整。覆盖率目标（P10–P90 区间为 0.75–0.85）与分位数损失共同反映了分位数是否校准：如果覆盖率同比下降，而点预测 WAPE 保持不变，则说明模型变得过于自信，此时需要重新审视的是安全库存乘数，而非点预测本身。

Two implementation notes worth flagging for readers reusing the evaluator. First, the signed-bias convention here is the SCM standard (positive = over-forecast), which matches Tracking Signal conventions used in most inventory-planning systems. Second, the pinball loss at P90 is asymmetric by design: under-coverage of the upper quantile is penalised 9× more than over-coverage, mirroring the asymmetric cost of stock-outs compared to carrying cost.有两个实现细节值得向复用该评估器的读者指出。首先，这里的符号偏差约定采用 SCM 标准（正值 = 高估），这与大多数库存规划系统中使用的跟踪信号（Tracking Signal）约定一致。其次，P90 分位数损失在设计上是不对称的：对上限分位数的覆盖不足所受的惩罚是过量覆盖的 9 倍，这反映了缺货成本与持有成本之间的不对称性。

Register the evaluator once through the AgentCore control plane, then reference it by ARN in every session-level evaluation:通过 AgentCore 控制平面注册一次评估器，然后在每次会话级评估中通过 ARN 引用它：

agentcore eval evaluator create \
  --name "ForecastAccuracyEvaluator" \
  --level SESSION \
  --lambda-arn arn:aws:lambda:us-east-1:$ACCOUNT:function:forecast-accuracy-evaluator \
  --lambda-timeout 60

Ground truth arrives late: on-demand, not online基准真值滞后：按需获取，而非在线获取

The 3-point behavior rubric runs online — every session, in real time — because its inputs (agent trace, tool outputs) exist at the moment the session ends. The accuracy evaluator is different. On the day the order decision is made, the “correct” demand for the next 14 days does not yet exist. It materialises one horizon later, as each forecast day passes and actual sales are recorded in the data warehouse.3 点行为准则是在线运行的——即在每个会话实时运行——因为其输入（智能体追踪记录、工具输出）在会话结束时就已经存在。准确度评估器则不同。在做出订单决策当天，未来 14 天的“正确”需求尚未产生。它会在一个预测时段之后，随着每一天预测的过去以及实际销售额被记录到数据仓库中，才会显现出来。

The code-based evaluator handles this naturally. A nightly job collects sessions whose forecast horizon has fully elapsed, pulls actual sales from the data warehouse, and invokes the evaluator on-demand with evaluationReferenceInputs populated:基于代码的评估器可以自然地处理这种情况。一个夜间作业会收集预测时段已完全结束的会话，从数据仓库中提取实际销售额，并在填充 evaluationReferenceInputs 后按需调用评估器：

import boto3

agentcore = boto3.client("bedrock-agentcore")

EVALUATOR_ID = "forecast-accuracy-evaluator-id"  # from create_evaluator

for session_id, session_spans, actuals in sessions_ready_for_scoring():
    response = agentcore.evaluate(
        evaluatorId=EVALUATOR_ID,
        evaluationInput={"sessionSpans": session_spans},
        evaluationTarget={"traceIds": session_trace_ids(session_spans)},
        evaluationReferenceInputs=[
            {"day": i + 1, "actual_sales": y}
            for i, y in enumerate(actuals)
        ],
    )
    for result in response["evaluationResults"]:
        # EvaluationResultContent schema: label, value, explanation,
        # evaluatorId, evaluatorName (see AWS SDK docs)
        if "errorCode" in result:
            emit_alarm(session_id, result["errorCode"], result["errorMessage"])
            continue
        emit_dashboard_metric(
            session_id=session_id,
            wape=result["value"],
            label=result["label"],
            explanation=result["explanation"],
        )

Scores stream into the same CloudWatch Evaluations namespace as the online evaluators, so the team queries behavior and accuracy through the same dashboards and alarms. A P50 forecast with four consecutive weeks of negative bias triggers the same operational response as a run of silent-violation sessions: investigate, fix, redeploy.评分流向与在线评估器相同的 CloudWatch Evaluations 命名空间，因此团队可以通过相同的仪表板和警报查询行为和准确度。一个连续四周出现负偏差的 P50 预测会触发与一系列静默违规会话相同的操作响应：调查、修复、重新部署。

The preceding snippet is the on-demand path — one evaluator call per session, invoked explicitly after ground truth arrives. When you want the evaluator to run automatically against every session’s trace as it lands in CloudWatch, register it in an Online Evaluation Config:前面的代码片段是按需执行路径——每个会话调用一次评估器，在基准真值到达后显式调用。如果您希望评估器在每次会话的追踪记录落入 CloudWatch 时自动运行，请在在线评估配置（Online Evaluation Config）中注册它：

import boto3

control = boto3.client("bedrock-agentcore-control")

control.create_online_evaluation_config(
    onlineEvaluationConfigName="inventory-live-eval",
    rule={"samplingConfig": {"samplingPercentage": 100.0}},  # initial rollout
    dataSourceConfig={
        "cloudWatchLogs": {
            "logGroupNames": ["/aws/bedrock-agentcore/inventory-supervisor"],
            "serviceNames": ["inventory-supervisor.DEFAULT"],
        }
    },
    evaluators=[
        {"evaluatorId": "Builtin.GoalSuccessRate"},         # session-level
        {"evaluatorId": "Builtin.Helpfulness"},             # trace-level
        {"evaluatorId": "constraint-compliance-judge-id"},  # custom LLM-as-a-Judge
    ],
    evaluationExecutionRoleArn="arn:aws:iam::$ACCOUNT:role/AgentCoreEvaluationRole",
    enableOnCreate=True,
)

Note what is not in the online list: the ForecastAccuracyEvaluator. Ground truth is not available at trace-emit time, so registering it online would produce HORIZON_MISMATCH errors on every invocation. The two cadences — online for behavior, on-demand for accuracy — are a consequence of the data arriving at different times, not a configuration preference.注意在线列表中没有包含的内容：ForecastAccuracyEvaluator。由于在发出追踪记录时无法获得基准真值，因此将其在线注册会导致每次调用都产生 HORIZON_MISMATCH 错误。这两种节奏——行为评估在线，准确度评估按需——是由于数据到达时间不同造成的，而非配置偏好。

The complete evaluation map完整的评估映射

The first three evaluators guard how the agent acted. The fourth guards what the model was right about. Together they close the gap that either alone would leave open: an agent that behaves perfectly while quietly under-forecasting, or a model with excellent WAPE whose recommendations are silently truncated by an agent. Both failure modes are invisible to a single-layer evaluation. Both become visible when the two layers run side by side.前三个评估器监控智能体的行为方式，第四个评估器监控模型预测的正确性。它们共同弥补了单独使用其中任何一个都会留下的空白：一个行为完美但却在悄悄低估预测的智能体，或者一个 WAPE 表现出色但其建议被智能体静默截断的模型。单层评估无法发现这两种失败模式。当两层评估并排运行时，它们就会显现出来。

Production targets and throughput生产目标与吞吐量

These evaluators only matter if they feed operational targets. For this system the targets are explicit: P95 end-to-end latency under 90 seconds for a batch-scheduled session, constraint-compliance rubric score of at least 2.0 on 95 percent of sessions (flagged violations count. Silent violations do not), and rolling 4-week WAPE under 20 percent across the top-20 SKUs by revenue. Each target has a CloudWatch alarm routed to oncall. The error budget — 5 percent of sessions scoring below 2.0 — gives the team room to iterate on prompts and constraints without treating every regression as a page.这些评估器只有在为运营目标提供数据时才有意义。对于本系统，目标是明确的：批处理会话的 P95 端到端延迟低于 90 秒；95% 的会话中约束合规准则得分至少为 2.0（标记的违规计入，静默违规不计入）；按收入排名前 20 的 SKU 的 4 周滚动 WAPE 低于 20%。每个目标都有一个路由到值班人员的 CloudWatch 警报。错误预算（5% 的会话得分低于 2.0）让团队有空间迭代提示词和约束，而不必将每一次回归都视为一次紧急事故。

Throughput at catalog scale. A full session for one SKU completes in roughly eight seconds end to end (Chronos2 Serverless cold path excluded, which amortises after the first call in a run). A 10,000-SKU nightly run finishes in under thirty minutes at roughly 100-way parallelism, bounded by the SageMaker Serverless concurrency quota. Per-run cost at that scale is on the order of a few dollars in Bedrock reasoning plus a few dollars in SageMaker inference — small enough that the daily-run cadence is a pricing choice, not a constraint.目录规模下的吞吐量。单个 SKU 的完整会话端到端耗时约为 8 秒（不包括 Chronos2 Serverless 冷启动路径，该路径在运行中的首次调用后会摊销）。10,000 个 SKU 的夜间运行在约 100 倍并行度下可在 30 分钟内完成，受限于 SageMaker Serverless 并发配额。该规模下的单次运行成本约为几美元的 Bedrock 推理费用加上几美元的 SageMaker 推理费用——成本足够低，以至于每日运行的节奏是一个定价选择，而不是约束条件。

Running the agent: a constraint-violation walkthrough运行智能体：约束违规演练

After deploying all components, invoke the agent with a scenario that deliberately forces the conditional retry loop to fire. The following test case overrides the product’s default budget cap to $500 — well under what a full lead-time order would cost — so that the system’s response to constraint violation is observable end-to-end.部署所有组件后，使用一个刻意触发条件重试循环的场景来调用智能体。以下测试用例将产品的默认预算上限覆盖为 500 美元——远低于完整提前期订单的成本——以便可以端到端地观察系统对约束违规的响应。

agentcore invoke "Forecast replenishment for SKU-00142 this weekend \
  (promotion active). My budget for this order is $500." \
  --session-id test-session-chronos2-inventory-001

The agent executes the full pipeline and returns a structured recommendation. The following numbers derive from data/product_config.json (safety_stock = 150, lead_time_days = 5, min_order_quantity = 50, unit_cost = $12.50) and the Chronos2 P50 forecast with the promotion covariate active:智能体执行完整流水线并返回结构化建议。以下数字源自 data/product_config.json（安全库存 = 150，提前期天数 = 5，最小订货量 = 50，单位成本 = 12.50 美元）以及激活促销协变量后的 Chronos2 P50 预测：

• Product: SKU-00142 (Wireless Earbuds Pro)产品：SKU-00142（无线耳机 Pro）
• Current stock: 45 units.当前库存：45 个。
• Forecast P50 (5-day lead time, with promotion): ~648 units.预测 P50（5 天提前期，含促销）：约 648 个。
• Optimal order: 753 units = $9,412.50.最优订单：753 个 = 9,412.50 美元。
• User budget cap: $500 → violation detected.用户预算上限：500 美元 → 检测到违规。
• Adjusted order (bounded by min_order_quantity): 50 units = $625.00 — still over budget.调整后的订单（受最小订货量限制）：50 个 = 625.00 美元——仍然超出预算。
• Projected shortfall: ~553 units over the 5-day lead-time window.预计缺口：在 5 天提前期窗口内约 553 个。

The behaviour at this point is the whole point of the design. Rather than silently truncating the order to whatever number fits the budget and creating a large stock-out, the Supervisor surfaces the three actionable options — raise the budget, accept the shortfall and pre-position expedited delivery, or delay the promotion — and asks the user to choose. This is the conditional retry loop doing its job: a constraint violation is treated as a workflow state requiring input, not as a silent failure.此时的行为正是设计的核心所在。主管（Supervisor）没有将订单静默截断为符合预算的数字并造成严重的缺货，而是提出了三个可操作的选项——提高预算、接受缺口并预设加急交付，或推迟促销——并要求用户做出选择。这就是条件重试循环发挥的作用：约束违规被视为需要人工输入的流程状态，而不是静默失败。

Observability and Evaluations both capture this event for inspection afterwards. The CloudWatch trace shows each tool call in the retry loop, and the Evaluations custom evaluator scores this session at 2.0 (flagged violation), confirming the agent behaved as designed rather than silently failing.可观测性和评估功能都会捕获此事件以供后续检查。CloudWatch 追踪记录显示了重试循环中的每一次工具调用，评估器的自定义评估器将此会话评分为 2.0（标记违规），确认智能体是按设计运行，而不是静默失败。

Cleaning up清理

To avoid incurring future charges, delete the resources you created during this walkthrough in the following order:为避免产生后续费用，请按以下顺序删除在此演练中创建的资源：

1. Tear down AgentCore resources (Runtime, Gateway, Policy engine, Memory, Evaluations):

   agentcore destroy

   Bash
   拆除 AgentCore 资源（运行时、网关、策略引擎、内存、评估）： agentcore destroy
2. Destroy the CDK stack (S3 bucket, Gateway Lambda, Cognito user pool, IAM roles):

   cd cdk && npx cdk destroy

   Bash
   销毁 CDK 堆栈（S3 存储桶、网关 Lambda、Cognito 用户池、IAM 角色）： cd cdk && npx cdk destroy
3. Delete the SageMaker Serverless endpoint to stop Chronos2 inference charges:

   aws sagemaker delete-endpoint \
     --endpoint-name chronos2-serverless-endpoint

   Bash
   删除 SageMaker Serverless 端点以停止 Chronos2 推理费用： aws sagemaker delete-endpoint \ --endpoint-name chronos2-serverless-endpoint
4. Revoke Amazon Bedrock model access under Model access in the Bedrock console if it is no longer needed for other workloads.如果不再需要用于其他工作负载，请在 Bedrock 控制台的“模型访问”下撤销 Amazon Bedrock 模型访问权限。

Conclusion结论

This architecture demonstrates that zero-shot forecasting and multi-agent automation are complementary abstractions that remove different categories of operational burden.该架构证明了零样本预测和多智能体自动化是互补的抽象概念，它们消除了不同类别的运营负担。

Chronos2 removes the ML pipeline. Adding a new SKU to the forecast requires no training job, no feature engineering, no model validation. The only inputs required are historical sales data and covariate values for the forecast horizon — both of which are standard operational data.Chronos2 移除了机器学习流水线。向预测中添加新 SKU 不需要训练作业、特征工程或模型验证。所需的唯一输入是历史销售数据和预测时段的协变量值——这两者都是标准的运营数据。

Multi-agent orchestration removes the manual workflow. Converting a demand forecast into a purchase order with business rule compliance, natural language rationale, and an audit trail requires coordinating judgment and computation across multiple steps. Four LLM agents handle the judgment. A set of deterministic tools handle the computation.多智能体编排移除了手动工作流。将需求预测转换为符合业务规则、具有自然语言逻辑说明和审计追踪的采购订单，需要跨多个步骤协调判断和计算。四个 LLM 智能体负责判断，一套确定性工具负责计算。

What you gain:您的收获：

The patterns described here — the agent versus tool, in-process versus gateway, and subjective versus deterministic evaluation decision frameworks, structured JSON contracts between agents, conditional retry as a first-class workflow state, and mapping each AgentCore service to one production concern — apply beyond inventory management to any domain where deterministic computation and contextual judgment must work together.此处描述的模式——智能体与工具、进程内与网关、主观与确定性评估决策框架、智能体之间的结构化 JSON 契约、作为一等工作流状态的条件重试，以及将每个 AgentCore 服务映射到一个生产关注点——不仅适用于库存管理，还适用于任何需要确定性计算与上下文判断协同工作的领域。

To get started, deploy the CDK stack in your AWS account using the infrastructure patterns described in the technical implementation section, then run the constraint-violation walkthrough with your own product data to see the full agent coordination in action.要开始使用，请使用技术实现部分中描述的基础设施模式在您的 AWS 账户中部署 CDK 堆栈，然后使用您自己的产品数据运行约束违规演练，以查看完整的智能体协调过程。

Cost figures for SageMaker Serverless Inference are estimates based on us-east-1 pricing and assume approximately 500 inference calls per month. Actual costs vary by Region and usage pattern.SageMaker Serverless 推理的成本数字是基于 us-east-1 定价的估算值，并假设每月约有 500 次推理调用。实际成本因区域和使用模式而异。

About the authors关于作者