Adaptive agentic intelligence framework using Strands Agents

使用 Strands Agents 的自适应智能体智能框架 | 人工智能

使用 Strands Agents 的自适应智能体智能框架

构建 AI 智能体的组织面临一个共同挑战：无论请求是常规状态检查还是复杂分析，通常都会被路由到单一的大型昂贵模型。这种“一刀切”的方法会增加 API 成本、引入不可预测的延迟，并消除离线操作的可能性。即使是一些本可以本地解决的常规查询，最终也需要通过云端的大型语言模型（LLM）进行完整的网络往返。

基于 Strands Agents 构建的自适应智能体智能框架（AAIF）采用了不同的方法。AAIF 不是将所有请求路由到单一的大型模型，而是使用小型语言模型（SLMs）在本地处理常规任务。更复杂的请求则通过 Amazon Bedrock 路由到云端模型。这种方法基于 NVIDIA 的 Belcak 等人的研究结论。他们认为小型语言模型“在智能体系统中对于许多调用来说足够强大、本质上更合适且必然更具经济性”。基于 Strands Agents 的框架展示了如何通过智能模型编排在降低成本的同时保持本地操作的低延迟。

在本文中，我们将通过 Strands Agents 结合本地 SLM（通过 Ollama）和云端模型（通过 Amazon Bedrock）逐步介绍 AAIF 的关键组件。我们使用物联网（IoT）监控场景作为参考实现。

解决方案概述

AAIF 将 AI 处理分为三层，每层针对不同类型的任务进行优化，如图 1 所示：

• 智能编排层使用轻量级 SLM（llama3.2:1b）作为决策层。该编排器对传入请求进行分类，并通过非硬编码规则将其路由到适当的处理层。

• 本地处理层通过 Ollama 在本地硬件上运行 SLM，处理设备遥测数据获取和图像分析等常规任务。这些任务具有低延迟且无需依赖云端。

• 云端处理层通过 Amazon Bedrock 的前沿模型处理复杂模式分析和战略建议。这些请求需要更广泛的上下文和多步骤推理，而这是 SLM 无法可靠提供的。

图 1：用于智能编排、本地处理和云端处理的 AAIF 三层处理架构

图 1 展示了完整的 AAIF 系统架构。架构中心是 Strands Agent，它连接到托管 1B 参数编排模型和视觉模型的 Ollama 运行时。该 Agent 提供了三个工具：get_device_telemetry 用于本地传感器数据获取，analyze_camera_feed 通过 llama3.2-vision 进行设备端视觉处理，get_expert_insights 则通过 boto3 调用 Amazon Bedrock 进行复杂分析。传入的用户请求通过 SLM 编排器进行处理，该编排器对每个请求进行分类，并根据任务复杂性将其分发到本地工具或云端端点。

图 2：完整 AAIF 系统架构，展示 Strands Agent、Ollama 运行时、工具集成和 Amazon Bedrock 连接性

该框架会适应您的部署约束条件，而无需您围绕其重新构建基础设施。这种架构可以在具有8GB内存的树莓派等边缘设备上运行，也可以在所有推理请求均通过Amazon Bedrock处理的全云部署环境中运行，还可以在结合本地速度与云端推理能力的混合配置中运行。这种灵活性来自于将路由逻辑（SLM协调器）与处理工具分离，您可以根据可用的硬件和网络连接情况独立地替换或重新配置这些工具。

先决条件

要完成本操作指南，您需要具备以下先决条件：

• 一个AWS账户。
• 在所需区域中配置了Amazon Bedrock模型访问权限。
• 安装了Python 3.10+。
• 安装了Ollama并拉取了以下模型：ollama pull llama3.2:1b（协调器）、ollama pull llama3.2-vision（视觉分析）。
• 安装了Strands Agents：pip install strands-agents strands-agents-tools。
• 配置了AWS命令行界面（AWS CLI）并具有适当的凭证。
• 安装了Boto3：pip install boto3。

设置环境

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

mkdir aaif-demo && cd aaif-demo
ollama serve

拉取所需模型：

ollama pull llama3.2:1b
ollama pull llama3.2-vision

创建名为aaif_agent.py的文件并添加以下组件。

实现本地处理工具

Strands Agents使用@tool装饰器来定义代理可以调用的功能。首先创建用于本地处理的工具。

第一个工具用于获取设备遥测数据。在生产环境中，它将连接到实际的物联网传感器。在此操作指南中，它使用模拟的设备数据：

from strands import Agent, tool
import random

DEVICE_TELEMETRY = {
    "sensor-001": {
        "device_type": "Temperature Sensor",
        "location": "Building A - Floor 2",
        "temperature": 72.5,
        "humidity": 45.2,
        "status": "normal"
    },
    "camera-001": {
        "device_type": "Security Camera",
        "location": "Main Entrance",
        "fps": 30,
        "resolution": "1080p",
        "status": "recording"
    },
    "hvac-001": {
        "device_type": "HVAC Controller",
        "location": "Building A - Central",
        "set_temp": 71.0,
        "current_temp": 72.5,
        "mode": "cooling",
        "status": "active"
    }
}

@tool
def get_device_telemetry() -> str:
    """从连接的物联网设备检索当前遥测数据。"""
    device_id = random.choice(list(DEVICE_TELEMETRY.keys()))
    device_data = DEVICE_TELEMETRY[device_id]

    report = f"设备: {device_id} ({device_data['device_type']})\n"
    report += f"位置: {device_data['location']}\n"
    report += f"状态: {device_data['status']}\n"
    for key, value in device_data.items():
        if key not in ['device_type', 'location', 'status']:
            report += f"{key}: {value}\n"
    return report

第二个工具使用本地SLM执行视觉分析。llama3.2-vision模型完全在本地硬件上运行，这意味着敏感的摄像头视频流不会离开设备：

import ollama

@tool def analyze_camera_feed(image_path: str) -> str: """使用本地视觉模型分析摄像头的视觉数据。""" stream = ollama.chat( model='llama3.2-vision', messages=[{ 'role': 'user', 'content': '用一句话描述这张图片。' '你看到的三个最重要的东西是什么？', 'images': [image_path] }], stream=True, )

full_response = "" for chunk in stream: chunk_content = chunk['message']['content'] print(chunk_content, end='', flush=True) full_response += chunk_content

return f"物体检测报告：\n{full_response}"

## 实现云端处理

对于需要更广泛推理的复杂分析，创建一个调用Amazon Bedrock的工具。该工具仅在协调器确定本地模型无法处理请求时才会被调用：

import boto3

@tool def get_expert_insights(context_data: str, question: str) -> str: """通过Amazon Bedrock获取复杂问题的高级分析和专家建议。""" client = boto3.client("bedrock-runtime", region_name="us-east-1")

conversation = [ { "role": "user", "content": [ {"text": f"上下文: {context_data}\n\n问题: {question}"} ], } ]

response = client.converse( modelId="<<model_id>", //参考模型ID 详情 messages=conversation, inferenceConfig={ "maxTokens": 512, "temperature": 0.5, "topP": 0.9 } )

response_text = response["output"]["message"]["content"][0]["text"] return f"专家分析：\n{response_text}"

## 使用智能协调配置Strands代理

AAIF的核心是Strands代理配置。该代理使用本地SLM（llama3.2:1b）作为协调器。Strands代理支持多个模型提供商，此处使用Ollama提供商在本地运行协调器：

from strands.models.ollama import OllamaModel

model = OllamaModel( model_id="llama3.2:1b", host="http://localhost:11434", params={ "max_tokens": 300, "temperature": 0.3, }, )

system_prompt = """你是运营设施的监控助手。 你可访问设备遥测工具、分析功能， 以及专家见解来有效监控运营。

当用户询问：

• 设备状态或遥测数据：使用get_device_telemetry
• 图像或数据分析：使用analyze_camera_feed
• 专家建议或复杂问题：使用get_expert_insights

始终直接向用户返回完整的工具结果。"""

agent = Agent( model=model, system_prompt=system_prompt, tools=[ get_device_telemetry, analyze_camera_feed, get_expert_insights, ], )

由SLM驱动的协调器会分析每个请求并将其路由到适当的工具，而无需硬编码的关键词匹配。路由通过模型对请求的理解实现：

请求

路由

延迟

“检查设备状态”

本地SLM

低（本地推理）

“分析这张图片”

本地视觉AI

“你建议什么优化策略？”

云端（Amazon Bedrock）

高（网络往返）

表1：本地与云端推理的请求、路由和延迟估算

## 运行代理

配置好代理后，您可以直接与之交互：

本地处理 - 设备遥测

response = agent("What's the current status of our devices?") print(response)

本地处理 - 视觉分析

response = agent("Analyze the camera feed from camera-001") print(response)

云端处理 - 复杂分析

response = agent( "Based on current telemetry patterns, " "what optimization strategies do you recommend?" ) print(response)

代理会自动对每个请求进行分类并路由到相应的处理层，无需显式路由规则。

## 适应不同部署场景

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

当工作负载完全在云端运行且没有边缘硬件可用时，将 Ollama 模型配置替换为 Amazon Bedrock 以处理所有请求。这会将每个请求通过托管的云端推理服务进行处理，实现自动扩展而无需本地 GPU 资源。拥有可靠低延迟连接且没有数据驻留限制的团队最能从这种配置中受益：

from strands.models import BedrockModel

model = BedrockModel( model_id="<<model_id>", //Refer model id details region_name="us-east-1" )

混合配置保留本地 SLM 协调器的同时，为超出本地模型能力的请求添加云端模型。这是本文演示中显示的默认 AAIF 配置。它适用于大多数请求足够常规可在本地解决，但部分请求需要更大模型更广泛推理的环境。成本节约可能来自约 80% 的流量不会触及付费 API 端点。

对于完全隔离或有严格数据主权要求的环境，用更大的本地模型替换云端工具，并在设备上运行所有处理。在内存充足的硬件上运行的 3B 参数模型可以处理中等复杂度的任务，这些任务原本会由 1B 协调器升级处理。权衡是对于最难的问题推理深度会降低，但好处是数据不会离开本地环境：

model = OllamaModel( model_id="llama3.2:3b", # Larger local model for complex tasks host="http://localhost:11434", )

## 展望未来：通过 MCP 服务器实现集中式工具调用

本文的实现使用了直接在代理代码中定义的本地工具调用。对于需要多个代理跨服务共享工具的生产部署，应将这些工具作为模型上下文协议（MCP）服务器公开。MCP 为工具发现和调用提供了标准化接口，因此您可以集中管理工具并在不同代理和环境中重用工具。在图 3 中，我们展示了如何将 AAIF 工具转换为 MCP 服务器以实现分布式集中式工具调用。

在如图3所示的分布式配置中，设备1作为协调中心，运行带有SLM路由器和本地遥测工具的Strands代理。它通过MCP协议连接到运行带llama3.2-vision的边缘视觉处理服务器的设备2。设备3作为连接到Amazon Bedrock的云分析网关。从协调器的角度来看，所有远程工具都表现为本地函数调用，因为MCP传输层会透明处理序列化和网络通信。

图3：使用MCP服务器的分布式智能

## 清理

为避免产生后续费用，请完成以下清理步骤：

- 禁用Amazon Bedrock模型访问：打开Amazon Bedrock控制台，选择"Model access"，然后撤销对Amazon Nova Lite的访问权限。详细步骤请参阅《Amazon Bedrock用户指南》中的"Manage model access"。

- 停止Ollama服务器并删除模型以释放本地磁盘空间（约2GB）：ollama stop ollama rm llama3.2:1b ollama rm llama3.2-vision

- 如果不再需要示例代码，请删除项目目录：rm -rf aaif-demo

## 结论

我们展示了如何使用Strands Agents和自适应智能体框架构建成本效益高的AI代理。通过将常规请求路由到本地SLM，同时将复杂分析保留给Amazon Bedrock上的云模型，AAIF可以在保持常规操作低延迟的同时降低API成本。

在将此模式投入生产之前，请向云推理路径添加负责任的AI控制，因为这些请求包含工具输出、检索数据和用户输入。您可以使用防护栏ID和版本将Amazon Bedrock防护栏附加到Strands BedrockModel上。它会应用有害类别内容过滤器、提示注入过滤器和上下文关联检查，阻止与源数据不支持的响应。要将相同策略应用于本地SLM层级，请对其输入和输出调用独立的ApplyGuardrail API。这样，无论哪个模型处理请求，每个请求都将遵循统一的安全标准。

这种架构模式的应用范围超越物联网监控。医疗组织可以在本地运行患者监控，同时将诊断支持路由到云模型。金融服务公司可以在本地处理交易，将云容量保留用于风险分析。制造团队可以在边缘运行质量控制视觉模型，同时将优化请求发送到云端。

欲了解如何使用Strands Agents构建代理，请访问Strands Agents文档。有关可用基础模型的信息，请参阅Amazon Bedrock。

## 作者简介

'"`