八成请求不必上云，这套框架用1B小模型分流

一个物联网监控系统，每次例行状态查询都要把请求发到云端大模型，等待网络往返，再等一个昂贵模型给出回答。这套做法在成本和延迟上都很难看。

Adaptive Agentic Intelligence Framework（自适应智能体框架，AAIF）给出的思路是：别把所有请求都塞给同一个大模型。它基于 Strands Agents 构建，用小型语言模型（SLM）在本地处理例行任务，复杂请求才通过 Amazon Bedrock 路由到云端模型。

这一思路引用了 NVIDIA 的 Belcak 等人的研究立场：小型语言模型对于智能体系统中的许多调用来说"足够强大、本质上更合适、也必然更经济"。

三层结构怎么分工

AAIF 把 AI 处理拆成三层，每层针对不同任务类型优化：

• 智能编排层：用一个轻量 SLM（llama3.2:1b）做决策，对进来的请求分类并路由到相应处理层，不依赖硬编码规则。
• 本地处理层：通过 Ollama 在本地硬件上运行 SLM，处理设备遥测读取、图像分析等例行任务，低延迟且不依赖云端。
• 云端处理层：通过 Amazon Bedrock 中的前沿模型处理复杂模式分析和策略建议，这类请求需要更广的上下文和多步推理，SLM 无法可靠提供。

系统中心是 Strands 智能体，它连接到一个 Ollama 运行时，后者同时承载 1B 参数的编排模型和视觉模型。智能体对外暴露三个工具：get_device_telemetry 负责本地传感器数据读取，analyze_camera_feed 通过 llama3.2-vision 做设备端视觉处理，get_expert_insights 则通过 boto3 调用 Amazon Bedrock 做复杂分析。

用户请求先经过 SLM 编排器，由它判断任务复杂度，再分派给本地工具或云端端点。

部署形态跟着硬件走

这套框架适配部署约束，而不是要求围绕它重构基础设施。它可以跑在内存 8 GB 的树莓派这类边缘设备上，也可以全部推理都走 Amazon Bedrock 的纯云部署，或者采用本地速度加云端推理的混合配置。

灵活性来自把路由逻辑（SLM 编排器）和处理工具分开，两者可以按可用硬件和网络状况独立替换或重新配置。

混合配置保留本地 SLM 编排器，同时为超出本地模型能力的请求加上云端模型。这是默认形态，适合大多数请求足够常规、可在本地解决、少数请求需要更大模型推理的环境。成本节省可以来自那部分不触碰付费 API 端点的流量——文中给出的比例是大约 80%。

对于完全物理隔离或数据主权要求严格的环境，可以把云端工具换成更大的本地模型，全部处理在设备上完成。一个 3B 参数模型在内存充足的硬件上，能处理 1B 编排器原本要升级上云的中等复杂度任务。代价是最难的那批查询推理深度下降，好处是数据不出本地。

纯云配置则把所有请求交给托管云推理，获得自动扩缩容能力，不需要本地 GPU 资源，适合连接稳定低延迟、且没有数据驻留限制的团队。

多智能体共享工具的下一步

当前实现用的是直接定义在智能体代码里的本地工具调用。面向多智能体跨服务共享工具的生产部署，可以把这些工具暴露为 Model Context Protocol（MCP）服务器。MCP 提供工具发现和调用的标准化接口，便于集中管理工具并在不同智能体和环境间复用。

在分布式配置中，设备 1 作为编排枢纽，运行带 SLM 路由器和本地遥测工具的 Strands 智能体；它通过 MCP 协议连接运行 llama3.2-vision 边缘视觉处理服务器的设备 2，以及连接 Amazon Bedrock 的云端分析网关设备 3。从编排器视角看，所有远程工具都表现为本地函数调用，序列化和网络通信由 MCP 传输层透明处理。

这套架构模式不限于物联网监控。医疗组织可以在本地跑患者监测，把诊断支持路由到云端模型；金融机构可以在本地处理交易，把云端容量留给风险分析；制造团队可以在边缘跑质量控制视觉模型，把优化请求发往云端。

上生产之前，云端推理路径需要加上负责任 AI 控制，因为这些请求携带工具输出、检索数据和用户输入。可以把 Amazon Bedrock Guardrails 通过 guardrail ID 和版本挂到 Strands 的 BedrockModel 上，它会应用有害类别内容过滤、提示注入过滤和上下文接地检查，拦截没有源数据支撑的回答。要把同样的策略应用到本地 SLM 层，可以对其输入输出调用独立的 ApplyGuardrail API。这样无论哪个模型处理，每个请求都遵循同一套安全标准。