使用 Strands Agents 的适应性代理智能框架

人工智能

使用 Strands Agents 的适应性代理智能框架

构建AI agents的组织面临共同的挑战：每一个请求，无论是例行状态检查还是复杂分析，一般都会被引导到一个单一的大型，昂贵的模型。 这种一刀切的做法可以驱动API成本上升，引入不可预测的延迟，并消除离线运营的可能性。 甚至可以解决本地问题的例行查询也最终需要全网往返到云托管的大语言模型(LLM).

与Strands Agents共同构建的适应剂智能框架(AAIF)采取了不同的方法。 AAIF没有将所有请求都导向一个单一的大模型，而是使用小语言模型(SLMS)处理本地的例行任务。 更复杂的请求通过Amazon Bedrock被路由到云托管的模型。 这种方法以Belcak等人在NVIDIA的研究立场为基础。 他们认为，小语言模式“对于代理体系中的许多引用来说，足够强大，本质上更合适，而且必然更经济。” 该架构建于Strands Agents上，展示了智能模型管弦乐如何有助于降低成本，同时保持当地操作的低延迟。

在此帖子中，我们通过Ollama和云模型通过Amazon Bedrock，用Strands Agents与本地的可持续土地管理穿过AAIF的关键组件。 我们使用“物联网”监测方案作为参考。

解决方案概述

AAIF组织AI处理为三层，每层优化为不同任务类型，如图1 显示：

- 智能管弦法使用轻量级可持续土地管理(llama3.2:1b)作为决策层。 这个管弦乐团将收到的请求进行分类，并将它们引导到没有硬码规则的适当处理层。

- 本地处理处理诸如设备遥测检索和图像分析等常规任务，使用通过Ollama运行于本地硬件上的SLM. 这些任务完成时不耐久，也不依赖云层。

- 云处理通过Amazon Bedrock的前沿模型处理复杂的模式分析和战略建议。 这些请求需要更广泛的背景和多步骤推理，而可持续土地管理无法可靠地提供。

图1 显示完整的AAIF系统架构。 中心坐落着Strands agent，它连接了Ollama运行时间，同时托管了1B参数管弦乐器模型和视觉模型。 agent曝光了三种工具：为本地传感器数据检索获取 device 遥测，通过llama3.2-vision分析 camera feed用于端侧视觉处理，以及通过boto3调用Amazon Bedrock进行复杂分析的Get Expertent insights. 收到的用户请求通过可持续土地管理管弦乐团进行，该管弦乐团对每项请求进行分类，并根据任务的复杂性将其发送到当地的工具或云端点。

框架适应了您的部署限制，而不是要求您调整周围的基础设施。 这种架构运行在边缘设备上，如具有8GB内存的Raspberry Pi，在全云部署中，所有推论达到 Amazon Bedrock，或结合局部速度和云推理的混合配置。 灵活性来自将路由逻辑(SLM管弦乐器)与处理工具分开，根据现有的硬件和网络连接，可以独立交换或重新配置。

先决条件

对于这次行走，你应该具备以下先决条件：

- AWS账户。

- Amazon Bedrock模型访问配置在所需的区域。

- Python 3.10+安装。

- Ollama安装了下列型号：

- ollama 牵引 llama3.2:1b(操作器).

- ollama拉动llama3.2-视觉(视觉分析).

- Strands Agents安装：pip安装线条-agents线条-agents工具。

- AWS命令行接口(AWS CLI)，配置有适当的证书。

- Boto3安装：pip安装boto3.

建立环境

创建工程目录并启动 Ollama 服务器：

调用所需的模型：

创建一个名为aif agent.py的文件并添加以下组件。

执行本地处理工具

Strands Agents使用@tool装饰器来定义agents可以引用的能力。 开始为本地处理创建工具。

第一个工具检索设备遥测数据。 在生产环境中，这将连接到实际的IOT传感器。 对于这种走过，它使用模拟设备数据：

第二个工具利用当地可持续土地管理进行远景分析。 llama3.2-视觉模型完全运行在本地硬件上

实施云处理

对于需要更广泛的推理的复杂分析，创建一个名为Amazon Bedrock的工具。 只有当乐团确定本地模型无法处理请求时，才会引用此工具：

以智能管弦乐配置 Strands agent

AAIF的核心是Strands agent配置。 agent使用当地可持续土地管理(llama3.2:1b)作为管弦乐器。 Strands Agents支持多个模型提供商，在这里我们使用Ollama提供商在本地运行管弦乐器：

可持续土地管理驱动的管弦乐团分析每一项请求，并将请求引向适当的工具，而不进行硬码关键词匹配。 路由通过模型对请求的理解发生：

表1：与云推论相比，当地的请求、路径和延迟估计

运行 agent

agent配置后，您可以直接与其交互：

agent将每个请求自动分类，并引导到相应的处理层。 不需要明确的路线规则。

适应不同的部署情况

AAIF架构通过改变模型配置来适应不同的基础设施要求：

当您的工作量完全运行在云中且没有边缘硬件可用时，将Ollama模型配置替换为Amazon Bedrock，用于所有处理。 这通过管理下的云推论来引导每个请求，给您自动缩放而不需要本地 GPU 资源。 具有可靠低相关性连通性且没有数据存储限制的团队从这一配置中受益最大：

混合组合保持了当地可持续土地管理管弦乐手的完整，同时为超过当地模式能力的请求增加了云模型。 这是在此行进中显示的默认 AAIF 配置。 它适合大多数请求都是例行公事、足以在当地解决的环境，但有些要求更广义地推理一个更大的模型。 成本节省可能来自大约80%的流量

对于全空加装或有严格数据主权要求的环境，用更大的局部模型取代云工具，运行所有处理端侧。 一个运行在具有足够内存的硬件上的3B参数模型可以处理中度复杂的任务，否则1B管弦乐器会升级。 在最困难的询问上，取舍减少推理深度，但好处是数据没有离开前提：

展望未来：使用 MCP 服务器调用中央化工具

本帖中的执行使用agent代码直接定义的本地工具呼叫。 对于拥有多个agents共享工具跨服务的生产部署，将这些工具曝光为模式背景协议(MCP)服务器。 MCP为工具的发现和引用提供了一个标准化的界面，因此可以在不同的agents和环境上集中工具管理和再利用工具。 在图3中，我们展示了如何将AAIF工具转换为MCP服务器，用于分布式，集中式的工具调用。

如图3所示，在分布式配置中，装置1充当管弦乐中心，用可持续土地管理路由器和当地遥测工具运行Strands agent. 它通过MCP协议连接到设备2，它运行一个边缘视觉处理服务器，使用llama3.2-vision. 设备3充当连接Amazon Bedrock的云分析网关。 从管弦乐家的角度来看，所有的远程工具都作为局部函数调用出现，因为MCP运输层会透明地处理序列化和网络通信。

清理

为了避免今后产生费用，应完成下列清理步骤：

- 禁用 Amazon Bedrock模型访问：打开Amazon Bedrock控制台，选择Model访问，并取消Amazon Nova Lite的访问。 详细步骤请参见管理模式访问Amazon Bedrock用户指南。

- 停止 Ollama 服务器并移除模型以释放本地磁盘空间(约2GB):

- 如果不再需要样本代码，删除项目目录：

结论

我们示范了如何利用与Strands Agents的适应性剂情报框架建立成本效益高的AI agents. 通过向当地可持续土地管理提出例行请求，并在Amazon Bedrock上保留云模型进行复杂的分析，AIF可以帮助降低API成本，同时保持常规操作的低延迟。

在生产中运行此模式之前，在云推导路径中加入负责任的AI控制，因为这些请求包含工具输出，检索数据和用户输入。 你可以将Amazon Bedrock Guardrails 附加到Strands Bedrock Model 上，并配有护栏ID和版本。 然后对有害类别使用内容过滤器，提示词注入过滤器，并进行背景定位检查，以阻断源数据不支持的响应。 将同样的政策适用于地方可持续土地管理层面，将独立的应用Guardrail API称为其投入和产出。 这样，无论哪个型号处理，每一个请求都遵循一个安全标准。

这种建筑格局适用于IOT监测之外。 一个保健组织可以在当地进行病人监测，同时向云模型提供路径诊断支助。 金融服务公司可以处理房地交易和后备云能力，进行风险分析。 制造团队可以在边缘运行质量控制视觉模型，同时向云端发送优化请求。

为了更多地了解与Strands Agents一起建造agents的情况，参观Strands Agents文献。 关于现有基础模型的信息，见Amazon Bedrock.

本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

Artificial Intelligence

Adaptive agentic intelligence framework using Strands Agents

Organizations building AI agents face a common challenge: Every request, whether a routine status check or complex analysis, typically gets routed to a single large, expensive model. This one-size-fits-all approach can drive up API costs, introduce unpredictable latency, and remove the possibility of offline operation. Even routine queries that could resolve locally end up requiring a full network round-trip to a cloud-hosted large language model (LLM).

The Adaptive Agentic Intelligence Framework (AAIF), built with Strands Agents, takes a different approach. Instead of routing all requests to a single large model, AAIF uses small language models (SLMs) to handle routine tasks locally. More complex requests are routed to cloud-hosted models through Amazon Bedrock. This approach builds on the research position from Belcak et al. at NVIDIA. They argue that small language models are “sufficiently powerful, inherently more suitable, and necessarily more economical for many invocations in agentic systems.” Built on Strands Agents, the framework demonstrates how intelligent model orchestration can help reduce costs while maintaining low latency for local operations.

In this post, we walk through the key components of AAIF using Strands Agents with local SLMs through Ollama and cloud models through Amazon Bedrock. We use an Internet of Things (IoT) monitoring scenario as a reference implementation.

Solution overview

AAIF organizes AI processing into three layers, each optimized for different task types, as Figure 1 shows:

- Smart orchestration uses a lightweight SLM (llama3.2:1b) as the decision-making layer. This orchestrator classifies incoming requests and routes them to the appropriate processing layer without hardcoded rules.

- Local processing handles routine tasks like device telemetry retrieval and image analysis using SLMs running on local hardware through Ollama. These tasks complete with low latency and no cloud dependency.

- Cloud processing handles complex pattern analysis and strategic recommendations through frontier models in Amazon Bedrock. These requests need broader context and multi-step reasoning that SLMs cannot reliably provide.

Figure 1 shows the complete AAIF system architecture. At the center sits the Strands agent, which connects to an Ollama runtime hosting both the 1B-parameter orchestrator model and the vision model. The agent exposes three tools: get_device_telemetry for local sensor data retrieval, analyze_camera_feed for on-device vision processing through llama3.2-vision, and get_expert_insights which calls Amazon Bedrock through boto3 for complex analysis. Incoming user requests flow through the SLM orchestrator, which classifies each request and dispatches it to either a local tool or the cloud endpoint based on task complexity.

The framework adapts to your deployment constraints rather than requiring you to restructure your infrastructure around it. This architecture runs on edge devices like a Raspberry Pi with 8 GB of memory, in full cloud deployments where all inference hits Amazon Bedrock, or in hybrid configurations that combine local speed with cloud reasoning. The flexibility comes from separating the routing logic (the SLM orchestrator) from the processing tools, which you can swap or reconfigure independently depending on available hardware and network connectivity.

Prerequisites

For this walkthrough, you should have the following prerequisites:

- An AWS account.

- Amazon Bedrock model access configured in the required Region.

- Python 3.10+ installed.

- Ollama installed with the following models pulled:

- ollama pull llama3.2:1b (orchestrator).

- ollama pull llama3.2-vision (vision analysis).

- Strands Agents installed: pip install strands-agents strands-agents-tools.

- AWS Command Line Interface (AWS CLI) configured with appropriate credentials.

- Boto3 installed: pip install boto3.

Set up the environment

Create a project directory and start the Ollama server:

Pull the required models:

Create a file called aaif_agent.py and add the following components.

Implement local processing tools

Strands Agents uses the @tool decorator to define capabilities that agents can invoke. Start by creating tools for local processing.

The first tool retrieves device telemetry data. In a production environment, this would connect to actual IoT sensors. For this walkthrough, it uses simulated device data:

The second tool performs vision analysis using a local SLM. The llama3.2-vision model runs entirely on local hardware, which means sensitive camera feeds don’t leave the device:

Implement cloud processing

For complex analysis that requires broader reasoning, create a tool that calls Amazon Bedrock. This tool is invoked only when the orchestrator determines that local models can’t handle the request:

Configure the Strands agent with smart orchestration

The core of AAIF is the Strands agent configuration. The agent uses a local SLM (llama3.2:1b) as its orchestrator. Strands Agents supports multiple model providers, and here we use the Ollama provider to run the orchestrator locally:

The SLM-powered orchestrator analyzes each request and routes it to the appropriate tool without hardcoded keyword matching. The routing happens through the model’s understanding of the request:

Table 1: Request, routing, and latency estimates for local compared to cloud inference

Run the agent

With the agent configured, you can interact with it directly:

The agent automatically classifies each request and routes it to the appropriate processing layer. No explicit routing rules are needed.

Adapt to different deployment scenarios

The AAIF architecture adapts to different infrastructure requirements by changing the model configuration:

When your workload runs entirely in the cloud and no edge hardware is available, replace the Ollama model configuration with Amazon Bedrock for all processing. This routes every request through managed cloud inference, giving you auto scaling without requiring local GPU resources. Teams with reliable low-latency connectivity and no data residency constraints benefit most from this configuration:

The hybrid configuration keeps the local SLM orchestrator intact while adding cloud models for requests that exceed local model capabilities. This is the default AAIF configuration shown in this walkthrough. It suits environments where most requests are routine enough to resolve locally, but some require the broader reasoning of a larger model. Cost savings can come from the roughly 80 percent of traffic that doesn’t hit a paid API endpoint.

For environments that are fully air-gapped or have strict data sovereignty requirements, replace the cloud tool with a larger local model and run all processing on-device. A 3B-parameter model running on hardware with adequate memory can handle moderately complex tasks that the 1B orchestrator would otherwise escalate. The trade-off is reduced reasoning depth on the hardest queries, but the benefit is data not leaving the premises:

Looking ahead: Centralized tool calling with MCP servers

The implementation in this post uses local tool calls defined directly in the agent code. For production deployments with multiple agents sharing tools across services, expose these tools as Model Context Protocol (MCP) servers. MCP provides a standardized interface for tool discovery and invocation, so you can centralize tool management and reuse tools across different agents and environments. In Figure 3, we show how to convert AAIF tools into MCP servers for distributed, centralized tool calling.

In the distributed configuration as shown in Figure 3, Device 1 acts as the orchestrating hub, running the Strands agent with the SLM router and a local telemetry tool. It connects through the MCP protocol to Device 2, which runs an edge vision processing server with llama3.2-vision. Device 3 serves as a cloud analytics gateway connected to Amazon Bedrock. From the orchestrator’s perspective, all remote tools appear as local function calls because the MCP transport layer handles serialization and network communication transparently.

Cleaning up

To avoid incurring future charges, complete the following cleanup steps:

- Disable Amazon Bedrock model access: Open the Amazon Bedrock console, choose Model access, and revoke access for Amazon Nova Lite. For detailed steps, see Manage model access in the Amazon Bedrock User Guide.

- Stop the Ollama server and remove models to free local disk space (approximately 2 GB):

- Delete the project directory if you no longer need the sample code:

Conclusion

We showed how to build cost-effective AI agents using the Adaptive Agentic Intelligence Framework with Strands Agents. By routing routine requests to local SLMs and reserving cloud models on Amazon Bedrock for complex analysis, AAIF can help reduce API costs while maintaining low latency for routine operations.

Before you run this pattern in production, add responsible AI controls to the cloud inference path, since those requests carry tool outputs, retrieved data, and user input. You can attach Amazon Bedrock Guardrails to the Strands BedrockModel with a guardrail ID and version. It then applies content filters for harmful categories, prompt injection filters, and contextual grounding checks that block responses not supported by the source data. To apply the same policies to the local SLM tier, call the standalone ApplyGuardrail API on its inputs and outputs. This way, every request follows one safety standard no matter which model handles it.

This architectural pattern applies beyond IoT monitoring. A healthcare organization could run patient monitoring locally while routing diagnosis support to cloud models. A financial services firm could process transactions on-premises and reserve cloud capacity for risk analysis. A manufacturing team could run quality control vision models at the edge while sending optimization requests to the cloud.

To learn more about building agents with Strands Agents, visit the Strands Agents documentation. For information about available foundation models, see Amazon Bedrock.

Auto-fetched and translated by AI Atlas. All rights belong to the original author.