用本地小模型与云端模型搭建分流式智能体

查设备状态和分析整栋楼的能耗，不该默认调用同一个大模型。AWS 这篇文章用 Strands Agents 搭了一个分层 Agent：本地小模型负责选工具，日常查询和图像处理留在本地，复杂问题再交给 Amazon Bedrock。

它值得借鉴的是任务分流的方法。但「约 80% 流量不调用付费 API」能不能变成你的成本收益，得先看请求分布、路由准确率和本地硬件账单。原文提供了架构与示例，没有提供完整的性能对照实验。

小模型负责分流，工具负责把事情办完

作者把这套方案称为 Adaptive Agentic Intelligence Framework，简称 AAIF，分成三层：

• 编排层使用 llama3.2:1b，理解请求并选择工具。
• 本地处理层通过 Ollama 获取设备数据，或调用 llama3.2-vision 分析图片。
• 云端处理层通过 boto3 调用 Amazon Bedrock，回答复杂分析与优化建议。

这里容易产生一个误解：查询设备状态，并不需要小模型自己生成遥测数据。数据由 get_device_telemetry 返回，模型负责判断该调用它。视觉任务交给 analyze_camera_feed，复杂问题交给 get_expert_insights。

小模型的价值，是让简单请求在本地完成，并把需要更强推理的问题送到云端。

为什么可能省钱？如果大量请求只是取状态、看图片，就能减少云端推理调用，也省去相应的网络往返。本地工具与模型可用时，这部分任务还能脱离云端运行。不过，原文只有延迟估算表的标题，输入材料没有具体数值，不能据此判断到底快了多少。

它也没有展示一个会根据预算、实时延迟自动调整的调度器。「自适应」在示例里主要体现为：模型按请求选择工具，以及部署时可以替换模型和工具。

路由不用关键词匹配，但仍然需要明确规则

准备环境需要 Python 3.10+、配置好凭证的 AWS CLI，以及对应 Region 的 Amazon Bedrock 模型访问权限。依赖安装命令是 pip install strands-agents strands-agents-tools 和 pip install boto3。

项目通过 mkdir aaif-demo && cd aaif-demo 创建，再用 ollama serve 启动服务，执行 ollama pull llama3.2:1b 与 ollama pull llama3.2-vision 下载模型，主要代码放进 aaif_agent.py。

下面这段配置最能说明方案如何运作：把本地模型、工具清单和分流要求交给 Strands Agents。

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 = """You are a monitoring assistant for operational facilities.
You have access to device telemetry tools, analysis capabilities,
and expert insights to help monitor operations effectively.

When users ask for:
- Device status or telemetry: use get_device_telemetry
- Image or data analysis: use analyze_camera_feed
- Expert advice or complex questions: use get_expert_insights

Always return the complete tool results directly to the user."""

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

要看的是 system_prompt：设备状态、图像分析、复杂咨询分别对应哪个工具，作者已经写清楚了。所谓「没有硬编码规则」，指没有用 if/else 匹配关键词；路由策略仍然存在，只是用自然语言表达。

这种做法能处理更灵活的问法，但正确率需要验证。原文没有给出路由测试集、误选工具比例，也没有展示本地回答失败后自动升级云端的判断机制。

示例工具还有两处影响可运行性的缺口。get_device_telemetry() 没有设备参数，而是随机选取 sensor-001、camera-001 或 hvac-001 的模拟数据，不能保证回答用户指定的设备。analyze_camera_feed(image_path: str) 需要图片路径，调用示例却只说分析 camera-001，没有实现设备到图片文件的映射。

视觉工具使用 ollama.chat、stream=True，要求用一句话描述图片并指出 3 个重要内容。输出虽然冠以「Object Detection Report」，代码并没有展示检测框、置信度或结构化检测结果，不能直接当成完整的目标检测接口。

混合部署能否省钱，要把整条调用链算进去

云端工具使用 boto3.client("bedrock-runtime", region_name="us-east-1")，通过 client.converse 发送上下文和问题，参数为 maxTokens: 512、temperature: 0.5、topP: 0.9。

其中 modelId 还是占位符，且原文 Python 代码夹入了 // 注释，复制后需要修正。清理部分提到了 Amazon Nova Lite，但前面的示例没有确定模型，不能把它当成已验证的默认配置。

作者提出三种部署方式。纯云端把编排模型换成 BedrockModel；默认混合模式保留本地编排与处理，复杂任务上云；完全离线则建议用 llama3.2:3b 等更大的本地模型承担中等复杂度任务，接受困难问题上的推理能力取舍。

这里有两个前提需要拆开看。

第一，作者称混合模式可让约 80% 流量避开付费 API，但没有交代样本来源、统计周期、任务质量和总成本。少调用云端不等于总成本同比下降，本地设备、运行维护和路由开销也要算进去。

第二，原文提到可在 8 GB 内存的 Raspberry Pi 上部署，却没有提供同时运行编排与视觉模型的配置和实测。清理部分所说释放约 2 GB 磁盘，也没有按模型拆分说明，不能拿来做硬件预算。

生产扩展方面，作者建议通过 MCP（Model Context Protocol）共享工具：Device 1 运行编排与遥测，Device 2 提供视觉服务，Device 3 作为 Amazon Bedrock 网关。MCP 统一工具发现和调用接口，但远程工具仍有网络延迟与失败问题。

安全控制同样要检查实际路径。作者建议给 Strands BedrockModel 配置 Guardrails 的 ID 和版本，本地层则调用独立的 ApplyGuardrail API。可是当前云端工具直接使用 boto3，给另一个 BedrockModel 加配置，不会自动覆盖这条调用。完全离线部署也不能直接依赖云端 ApplyGuardrail，需要另行设计本地控制。

我的判断

我认可把简单任务和复杂任务分开处理，尤其是工具边界清楚、日常查询占多数的系统。模型未必需要独自完成所有工作，稳定的数据接口往往比更大的参数量更有价值。

但是否需要模型来路由，应当先和确定性规则做比较。 页面按钮已经明确选择「查看遥测」时，直接调用接口通常更省事。用户通过自由文本混合表达多个意图时，小模型路由才更值得评估。

这篇文章属于架构演示。它没有给出云端单模型、规则路由和小模型路由的对照数据，也没有证明 llama3.2:1b 能可靠识别所有需要升级处理的问题。80% 的流量比例和部署收益，应当视为有待验证的经验判断。

还有一个容易忽略的点：相机图片留在本地，不代表整条链路的数据都留在本地。get_expert_insights 接收 context_data，本地分析结果仍可能被送往云端。数据边界要落实到工具参数，而不是只看模型部署位置。

能拿来做什么

• 给现有监控助手整理一组真实请求，标明应调用的工具，再比较固定规则、llama3.2:1b 路由和直接云端处理的正确率、延迟与成本。
• 如果前端提供设备查询对话框，先让后端工具支持明确的设备 ID，并补齐 camera-001 到图片路径的映射，避免模型选对工具却取错数据。
• 给云端分析入口明确规定允许上传哪些遥测字段、图片摘要和用户输入，并确认 Guardrails 覆盖实际的 boto3 调用路径。
• 从单机工具验证开始，确认多个 Agent 确实需要共享能力后再引入 MCP，同时处理远程调用的超时、错误返回和访问控制。