基于树莓派与Ollama的智能视觉问答系统：边缘计算与多智能体实践

1. 项目缘起：当边缘计算遇到自然语言交互

最近在折腾一个挺有意思的玩意儿，起因是我想在工作室里搞个“智能监控助手”。需求很简单：工作室里设备多，人来人往，有时候想快速知道“现在房间里有没有人”、“桌子上那台示波器还在不在”，或者“门口是不是有快递”。传统的摄像头监控方案要么得一直盯着屏幕，要么告警规则死板，比如移动侦测，一只飞虫过去都可能误报，信息筛选效率太低。

我琢磨着，能不能让摄像头自己“看懂”画面，并且能用最自然的方式——也就是说话——来告诉我它看到了什么？比如我直接在常用的团队协作工具里问一句：“嘿，看看工作室现在什么情况？”它就能用文字描述回复我。这个想法催生了我手头这个项目：一个基于树莓派、YOLO目标检测模型，并通过Slack和Ollama实现自然语言交互的多智能体框架。

听起来有点复杂，但拆解开来，核心就是三件事：第一，在资源受限的树莓派上稳定、高效地跑起一个靠谱的目标检测模型（YOLO）；第二，搭建一个能接收自然语言指令、理解意图并触发相应检测任务的“大脑”（Ollama大语言模型）；第三，设计一个流畅的通信与协作机制，让“眼睛”（树莓派+YOLO）和“大脑”（Ollama）能通过一个便捷的交互界面（Slack）协同工作，形成一个完整的感知-决策-反馈闭环。这本质上就是一个为特定物理空间设计的、轻量级的多智能体系统，每个智能体（Agent）各司其职，共同完成“视觉问答”任务。

2. 核心组件选型与架构设计思路

为什么是树莓派、YOLO、Slack和Ollama这个组合？这背后是一系列针对边缘计算、实时性、易用性和成本考量的权衡。

2.1 边缘感知单元：树莓派与YOLO的“黄金搭档”

感知层的关键是选择一个够用、便宜且社区支持强大的硬件平台。树莓派几乎是创客和边缘AI项目的首选。我用的是一块树莓派4B 4GB版本，它的算力对于运行轻量化模型已经足够，功耗低，体积小巧，可以直接挂在摄像头旁边。更重要的是，其庞大的社区意味着你在部署过程中遇到的99%的问题，都能找到解决方案。

对于“眼睛”该用什么算法，目标检测领域的选择很多，但YOLO（You Only Look Once）系列因其在速度和精度间的优异平衡而脱颖而出。特别是在资源受限的边缘设备上，YOLO的“单次前向传播”即可完成检测的特性，比传统的两阶段检测器（如Faster R-CNN）快得多。我最终选择了YOLOv8，而不是最新的v9或v10。原因在于v8在模型尺寸、精度和速度上达到了一个非常成熟的平衡点，并且其Ultralytics官方提供的PyTorch实现和导出工具链（支持ONNX, TensorRT, OpenVINO等）异常完善，社区教程和预训练模型也最丰富。对于工作室场景，检测“人”、“椅子”、“电脑”、“包裹”这些常见物体，YOLOv8-nano或YOLOv8-small模型已经能提供相当不错的精度，同时在树莓派上也能达到接近实时的帧率（例如，使用OpenVINO后端在CPU上跑，640x640分辨率下可以达到5-10 FPS，这对于间隔性查询的需求完全足够）。

2.2 交互与决策中枢：Slack + Ollama 的“软”组合

有了能“看”的硬件，接下来需要解决“怎么问”和“怎么理解”的问题。交互界面我选择了Slack。原因很简单：它是我和团队日常沟通的主要工具，无需额外安装APP；它的Bot API非常成熟，可以轻松创建机器人，接收用户@它的消息；而且它支持丰富的消息格式（文本、图片、区块），非常适合用来呈现检测结果。这样一来，监控和查询就无缝集成到了工作流中，体验非常自然。

最核心的部分，是赋予这个系统“理解”和“决策”的能力，这就是Ollama的用武之地。Ollama是一个强大的本地大语言模型（LLM）部署和运行工具。它把下载、运行各种开源LLM（如Llama 2/3, Mistral, Gemma等）的过程变得极其简单。为什么不用云端的API（如GPT）？首先是隐私和成本考虑，工作室的实时画面数据我不想上传到云端；其次是延迟和稳定性，本地化部署可以保证即使外网断开，核心的视觉问答功能依然可用。Ollama让我能在本地的一台性能稍强的机器（比如一台旧的NUC迷你主机，甚至是一台带显卡的台式机）上，以很小的资源开销运行一个7B或13B参数的模型，专门用于处理自然语言指令。

2.3 多智能体协作框架设计

整个系统的架构可以看作三个智能体的协作：

1. Slack Bot Agent（交互代理）：常驻在Slack平台，负责监听特定频道的消息。当用户@机器人并发出指令（如“扫描一下房间”）时，它负责捕获这条指令，并将其转发给“决策代理”。
2. Ollama LLM Agent（决策代理）：运行在本地服务器上。它接收来自Slack Bot的文本指令，利用大语言模型的理解能力，将其解析为一个结构化的“任务”。例如，它需要判断用户是想进行“实时检测”、“定时巡检”还是“查询历史记录”？如果是检测，目标物体是什么？检测到之后需要执行什么动作（仅报告、截图存档、还是触发其他联动）？解析完成后，它会生成一个明确的命令，发送给“感知代理”。
3. Raspberry Pi YOLO Agent（感知代理）：运行在树莓派上。它持续运行着一个视频流捕获程序和YOLO推理引擎（但默认可能处于低功耗监听状态）。当收到来自决策代理的明确检测命令后，它立即启动或激活检测流程，抓取当前帧或一段视频流进行推理，将检测结果（包括物体类别、位置、数量）格式化后，回传给决策代理或直接经由Slack Bot呈现给用户。

它们之间的通信，我采用了轻量级的消息队列（如Redis）或简单的HTTP/RESTful API。对于这个轻量级项目，我最初直接用HTTP POST/GET请求在几个服务间通信，结构清晰，调试方便。整个数据流是：Slack用户指令 -> Slack Bot -> Ollama LLM解析 -> 树莓派执行检测 -> 结果返回Ollama组织语言 -> Slack Bot回复用户。

3. 树莓派端YOLOv8的深度优化部署实战

在树莓派上部署YOLO，直接跑原版PyTorch模型绝对不是最佳选择。树莓派的ARM CPU和有限的内存，需要我们进行一系列“瘦身”和“加速”操作。

3.1 模型选择与转换：从PyTorch到边缘友好格式

第一步是模型选型。Ultralytics提供了从nano到x-large多种尺寸的YOLOv8预训练模型。对于树莓派4B，我强烈建议从YOLOv8n（nano）开始。它的参数量仅约3百万，模型文件约6MB，在精度损失可接受的前提下，为实时性提供了最大保障。

拿到PyTorch的.pt文件后，不能直接使用。我们需要将其转换为更适合边缘设备推理的格式。主要有两个方向：

• ONNX Runtime：通用性强，支持CPU（包括ARM）和多种加速后端。使用Ultralytics的export功能可以轻松导出ONNX模型。命令类似：yolo export model=yolov8n.pt format=onnx。在树莓派上安装onnxruntime库即可运行。
• OpenVINO：英特尔推出的工具套件，对CPU（特别是x86，但对ARM也有优化）的推理优化效果显著。它可以将ONNX模型进一步转换为IR格式，并进行图优化、量化等操作。虽然树莓派是ARM架构，但OpenVINO提供了ARM版的运行时库，实测下来推理速度比纯ONNX Runtime快20%-30%。使用OpenVINO Toolkit的模型优化器进行转换。

我最终选择了OpenVINO路径，因为它的优化确实带来了可观的性能提升。转换后，我们得到.xml（网络结构）和.bin（权重）两个文件。

3.2 推理代码编写与性能调优

推理代码的核心是加载模型、预处理图像、推理、后处理画框。这里有几个关键优化点：

1. 预处理与后处理的效率：使用OpenCV的cv2.dnn.blobFromImage进行预处理时，注意设置swapRB=True（因为OpenCV读图是BGR，而模型通常需要RGB）。后处理中，非极大值抑制（NMS）是计算瓶颈之一。要合理设置置信度阈值（conf_threshold）和NMS阈值（iou_threshold）。对于监控场景，可以适当提高置信度阈值（如0.6）来减少误报，从而减少后续NMS的计算量。
2. 输入分辨率与帧率权衡：YOLOv8默认训练分辨率是640x640。在树莓派上，保持这个分辨率可以获得最佳精度/速度比。不要盲目降低分辨率来求快，因为模型是针对这个尺寸优化的，降低分辨率可能导致小目标检测能力急剧下降。如果帧率还是不够，可以考虑跳帧处理（例如，每3帧处理1帧）。
3. 利用硬件加速（如果有）：树莓派4B的CPU是Cortex-A72，没有NPU。但如果你使用树莓派5，或者像Radxa 5T这类带有NPU的开发板，就需要寻找支持该NPU的推理引擎（如Rockchip的RKNN-Toolkit）。对于树莓派4B/5，专注于优化CPU推理是正道。可以尝试使用onnxruntime时指定执行提供者为OpenVINOExecutionProvider，看看是否能结合两者优势。
4. 内存与功耗管理：树莓派长时间运行，散热和稳定性很重要。可以为树莓派加装散热风扇或散热片。在代码层面，当没有检测任务时，让推理循环进入低功耗等待状态，而不是持续满负荷运行，可以显著降低温度和功耗。

下面是一个基于OpenVINO推理的简化代码框架示例：

import cv2 import numpy as np from openvino.runtime import Core # 1. 初始化OpenVINO核心并加载模型 core = Core() model = core.read_model('yolov8n_openvino_model/yolov8n.xml') compiled_model = core.compile_model(model, 'CPU') # 指定CPU设备 output_layer = compiled_model.output(0) # 2. 准备标签和颜色 CLASSES = [...] # YOLO COCO数据集80类的标签 colors = np.random.uniform(0, 255, size=(len(CLASSES), 3)) # 3. 推理函数 def infer(frame): # 预处理 [height, width, _] = frame.shape input_img = cv2.dnn.blobFromImage(frame, 1/255.0, (640, 640), swapRB=True, crop=False) # 推理 results = compiled_model([input_img])[output_layer] # 后处理 (YOLOv8输出格式为 [1, 84, 8400]) # 需要将8400个预测框根据置信度过滤和NMS处理 # 这里省略详细的后处理代码，可使用ultralytics YOLO自带的处理函数或自己实现 detections = process_results(results, frame.shape) # 画框和标签 for (class_id, confidence, box) in detections: color = colors[class_id] cv2.rectangle(frame, box, color, 2) label = f"{CLASSES[class_id]}: {confidence:.2f}" cv2.putText(frame, label, (box[0], box[1]-10), cv2.FONT_HERSHEY_SIMPLEX, 0.5, color, 2) return frame, detections # 4. 主循环（示例：持续检测并可通过网络API触发） # 实际项目中，这里会嵌入一个简单的Web服务器（如Flask）或消息队列消费者，等待来自Ollama Agent的触发指令。

3.3 避坑指南：树莓派上的那些“坑”

• OpenCV安装慢/失败：不要用pip install opencv-python，在ARM架构上编译极其缓慢且易失败。使用预编译的轮子：pip install opencv-python-headless，或者使用系统包管理器：sudo apt install python3-opencv。
• 内存不足（OOM）：运行YOLO时，如果分辨率大或模型大，可能遇到内存错误。确保系统有足够的交换空间（swap）。可以使用sudo dphys-swapfile swapoff和sudo dphys-swapfile swapon来调整交换文件大小，或使用zram。更根本的方法是换用更小的模型（YOLOv8n）。
• USB摄像头兼容性与帧率：使用lsusb和v4l2-ctl --list-formats检查摄像头。在代码中，用cv2.VideoCapture(index)打开摄像头后，尝试设置cap.set(cv2.CAP_PROP_FPS, 15)和cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640)等属性来稳定帧率。有时USB带宽不足会导致帧率不稳，可以尝试降低分辨率。
• 模型转换后精度下降：从PyTorch到ONNX/OpenVINO的转换，理论上不会损失精度（除非涉及量化）。如果发现精度明显下降，检查转换时是否设置了opset=12或更高（对于YOLOv8），并确保预处理（归一化、通道顺序）在转换和推理时完全一致。

4. Ollama本地大模型部署与智能指令解析

让机器理解“看看工作室有没有人”和“扫描一下房间”是同一回事，这就需要大语言模型的能力。Ollama让本地部署LLM变得异常简单。

4.1 Ollama安装与模型选择

在作为“决策代理”的服务器（我的是一台Ubuntu 22.04的NUC）上安装Ollama，一行命令搞定：curl -fsSL https://ollama.com/install.sh | sh。安装完成后，就可以拉取模型了。模型选择是关键，需要在模型能力、响应速度和资源占用间平衡。

• Llama 3.1 8B：Meta最新推出的8B模型，在指令跟随、推理和代码能力上非常出色，是当前小尺寸模型中的佼佼者。对于我们的指令解析任务，它游刃有余。命令：ollama pull llama3.1:8b。
• Mistral 7B：一个非常高效且能力强大的7B模型，在多项基准测试中表现优于更大的模型，对内存更友好。命令：ollama pull mistral。
• Gemma 2 9B：Google的轻量级模型，在常识推理和安全性上做得不错。命令：ollama pull gemma2:9b。

我最终选择了Llama 3.1 8B，因为它对指令的理解更精准，且8B参数在16GB内存的机器上运行流畅（Ollama运行时会自动使用GPU加速，如果可用）。如果服务器资源非常紧张，Mistral 7B是绝佳的备选。

4.2 构建系统提示词（System Prompt）与指令解析

Ollama的核心是通过API与模型交互。我们需要设计一个强大的“系统提示词”（System Prompt）来塑造LLM Agent的行为，让它成为我们这个多智能体系统的可靠“指挥官”。

这个提示词需要清晰地定义Agent的角色、能力、可用工具（即它能调用的服务）以及输出格式。以下是我设计的提示词核心部分：

你是一个智能视觉助手系统的控制中心。你的任务是理解用户的自然语言请求，并将其转换为给视觉感知模块（摄像头+YOLO检测）的明确指令。 ## 你的能力 1. 你可以命令视觉感知模块进行以下操作： - `single_scan`: 立即对当前场景进行一次目标检测。 - `continuous_monitor`: 开启持续监控模式，持续检测特定目标，直到收到停止指令。 - `list_targets`: 列出当前视觉模块支持检测的所有目标物体类别（如：人、椅子、电脑、背包等）。 ## 指令解析规则 - 当用户询问当前场景状态（如“房间里有人吗？”、“看看桌子”）时，应触发 `single_scan`。 - 当用户要求持续关注某物（如“监控门口，有包裹来了告诉我”）时，应触发 `continuous_monitor`，并明确目标物体（如“包裹”）。 - 当用户问“你能识别什么？”时，触发 `list_targets`。 ## 输出格式 你必须严格按照以下JSON格式回应，且只输出这个JSON对象，不要有任何其他解释： { "action": "single_scan" | "continuous_monitor" | "list_targets", "target_object": "string" | null, // 只有当action为continuous_monitor或用户明确指定时才填充，如“person”, “package” "user_query": "原始用户问题" // 原样记录用户问题 }

通过这样结构化的提示词，我们极大地约束了LLM的输出，使其变得可预测、可解析。这比让LLM自由发挥生成一段文字再让我们去理解要可靠得多。

4.3 实现Ollama Agent服务

接下来，我们用Python创建一个简单的FastAPI应用，作为Ollama Agent的服务端。它提供两个主要端点：一个用于处理Slack Bot转发来的用户消息，另一个用于接收树莓派Agent返回的检测结果并组织成自然语言回复。

from fastapi import FastAPI, HTTPException import requests import json import logging from pydantic import BaseModel app = FastAPI() # 假设树莓派Agent的地址 PI_AGENT_URL = "http://192.168.1.100:5001/detect" # Ollama本地服务 OLLAMA_URL = "http://localhost:11434/api/generate" class SlackMessage(BaseModel): text: str user: str channel: str class DetectionResult(BaseModel): objects: list # 格式如 [{"class": "person", "confidence": 0.95, "bbox": [...]}, ...] def call_ollama_for_parsing(user_query: str) -> dict: """调用Ollama解析用户指令""" prompt = f"{SYSTEM_PROMPT}\n\n用户请求：{user_query}" payload = { "model": "llama3.1:8b", "prompt": prompt, "stream": False, "options": {"temperature": 0.1} # 低温度确保输出稳定，符合JSON格式 } try: response = requests.post(OLLAMA_URL, json=payload, timeout=30) response.raise_for_status() result = response.json() # 从LLM的回复中提取JSON部分 response_text = result.get('response', '').strip() # 有时LLM会在JSON外加个```json ```标记，需要清理 if response_text.startswith('```json'): response_text = response_text[7:-3].strip() elif response_text.startswith('```'): response_text = response_text[3:-3].strip() parsed_action = json.loads(response_text) return parsed_action except (requests.exceptions.RequestException, json.JSONDecodeError) as e: logging.error(f"调用Ollama解析指令失败: {e}") # 可以返回一个默认动作或抛出异常 return {"action": "single_scan", "target_object": None, "user_query": user_query} @app.post("/slack/command") async def handle_slack_command(message: SlackMessage): """接收Slack Bot转发的用户指令""" user_query = message.text # 1. 调用Ollama解析指令 action_command = call_ollama_for_parsing(user_query) # 2. 根据解析结果，调用树莓派Agent if action_command["action"] == "single_scan": # 向树莓派发送检测请求 pi_response = requests.post(PI_AGENT_URL, json={"mode": "single"}) detection_data = pi_response.json() # 3. 将检测结果再次发给Ollama，让其生成自然语言描述 natural_language_summary = summarize_detection_for_user(detection_data, user_query) # 4. 将自然语言描述返回给Slack Bot（实际中Slack Bot会调用另一个接口来发送消息） return {"response": natural_language_summary} elif action_command["action"] == "continuous_monitor": # 处理持续监控逻辑，可能需要建立WebSocket或长轮询连接 pass # ... 其他action处理 def summarize_detection_for_user(detection_data: dict, original_query: str) -> str: """利用Ollama将结构化的检测结果总结成自然语言""" objects_list = detection_data.get("objects", []) objects_desc = ", ".join([f"{obj['class']}({obj['confidence']:.0%})" for obj in objects_list]) if objects_list else "未检测到任何目标物体" summary_prompt = f""" 用户的问题是：{original_query} 视觉系统检测到了以下物体：{objects_desc}。 请根据用户的问题和检测结果，生成一段简洁、友好的自然语言回复，直接回答用户。不要提及JSON或系统内部细节。 回复：""" payload = { "model": "llama3.1:8b", "prompt": summary_prompt, "stream": False, "options": {"temperature": 0.7} # 温度可以稍高，让回复更自然 } response = requests.post(OLLAMA_URL, json=payload) return response.json().get('response', '抱歉，总结结果时出了点问题。')

这个服务是整个系统的大脑，它协调了自然语言理解、任务分发和结果整合。使用FastAPI可以方便地构建RESTful API，并且其异步特性适合处理可能并发的请求。

5. Slack Bot开发与多服务集成

Slack Bot作为用户交互的直接界面，需要做得足够健壮和友好。我们使用Slack的Bolt框架（基于Python）来快速开发。

5.1 创建Slack App与权限配置

首先，在 api.slack.com 上创建一个新的Slack App。需要配置以下主要权限范围（OAuth Scopes）：

• app_mentions:read：读取频道中提及（@）机器人的消息。
• chat:write：在频道中发送消息。
• channels:history（可选）：如果需要读取频道历史。
• groups:history（可选）：如果需要读取私密频道历史。

安装应用到你的工作空间后，你会获得一个Bot User OAuth Token（以xoxb-开头），这就是你的机器人令牌。

5.2 使用Bolt框架搭建Bot服务

Bolt框架大大简化了Slack事件的处理。我们的Bot服务需要做两件事：监听被提及的消息，并将消息内容转发给我们的Ollama Agent服务。

import logging from slack_bolt import App from slack_bolt.adapter.socket_mode import SocketModeHandler import requests # 初始化，使用Socket Mode（适合开发和生产，无需公网IP） app = App(token="xoxb-your-bot-token") # Ollama Agent服务的地址 OLLAMA_AGENT_URL = "http://your-ollama-agent-server:8000/slack/command" # 监听当Bot被@时的事件 @app.event("app_mention") def handle_mention(event, say, client): # 获取事件中的文本和频道 text = event["text"] channel = event["channel"] user = event["user"] # 移除@机器人的部分，得到纯用户指令 # 例如：“<@U123456> 看看房间有人吗” -> “看看房间有人吗” query_text = text.split('>')[1].strip() if '>' in text else text # 立即回复一个“正在处理”的提示，避免用户觉得没反应 say(text=f"收到指令：`{query_text}`，正在分析并启动视觉扫描...", channel=channel) # 构建请求体，转发给Ollama Agent payload = { "text": query_text, "user": user, "channel": channel } try: # 调用Ollama Agent服务 response = requests.post(OLLAMA_AGENT_URL, json=payload, timeout=60) if response.status_code == 200: result = response.json() # 将Ollama Agent返回的自然语言总结发送回Slack频道 say(text=result.get("response", "处理完成，但未返回有效结果。"), channel=channel) else: say(text="抱歉，处理指令时后端服务出现了错误。", channel=channel) logging.error(f"Ollama Agent返回错误: {response.status_code}") except requests.exceptions.RequestException as e: say(text="网络通信异常，无法连接到处理服务器。", channel=channel) logging.error(f"请求Ollama Agent失败: {e}") # 启动服务（使用Socket Mode，需要从Slack App配置页面获取 `app-level token` 以 `xapp-` 开头） if __name__ == "__main__": handler = SocketModeHandler(app, "xapp-your-app-level-token") handler.start()

5.3 消息格式优化与交互增强

为了让回复更美观，我们可以利用Slack的Block Kit来格式化消息。例如，当检测到物体时，除了文字描述，还可以附上一张检测结果的可视化图片（由树莓派Agent生成并上传到图床或Slack本身）。

# 在Ollama Agent服务中，生成更丰富的Slack消息 def generate_slack_blocks(detection_summary: str, image_url: str = None): blocks = [ { "type": "section", "text": { "type": "mrkdwn", "text": detection_summary } } ] if image_url: blocks.append({ "type": "image", "title": { "type": "plain_text", "text": "检测结果可视化" }, "image_url": image_url, "alt_text": "目标检测结果截图" }) return blocks # 在Bot的say函数中，使用blocks参数 # say(blocks=generate_slack_blocks("检测到一个人和一台电脑。", "https://your-image-url.com/result.jpg"), channel=channel)

这样，当用户询问时，回复将包含清晰的文字描述和一张带检测框的图片，体验更佳。

6. 系统联调、优化与真实场景测试

当三个智能体（Slack Bot, Ollama Agent, Raspberry Pi Agent）都开发完成后，真正的挑战在于让它们稳定、高效地协同工作。

6.1 端到端通信与错误处理

整个系统的数据流是异步且跨网络的，任何一个环节出错都会导致用户体验中断。必须实施完善的错误处理和重试机制。

• 超时设置：在所有HTTP请求（Slack Bot -> Ollama Agent, Ollama Agent -> Pi Agent）中设置合理的超时（如30秒）。树莓派的推理可能较慢，超时时间要留足。
• 队列缓冲：在高并发场景下（虽然本项目可能不常见），可以在Ollama Agent前加入一个消息队列（如Redis List或RabbitMQ），将用户请求排队处理，避免同时多个检测请求压垮树莓派。
• 状态反馈：Slack Bot在转发请求后，应立即回复“处理中”。Ollama Agent在调用树莓派时，如果长时间无响应，应主动向Slack发送“检测模块响应超时，请检查设备状态”的提示。
• 服务健康检查：为每个Agent（特别是树莓派Agent）提供一个/health端点，定期检查其是否存活。Ollama Agent可以在收到请求前先ping一下树莓派。

6.2 性能瓶颈分析与优化

在真实测试中，我发现了几个主要瓶颈：

1. 树莓派推理速度：这是最大的延迟来源。优化方法如前所述：使用OpenVINO、选择最小模型、固定输入分辨率、优化后处理代码。实测YOLOv8n + OpenVINO在树莓派4B上，从收到指令到返回结构化结果，大约需要2-3秒（包含摄像头抓图时间）。
2. Ollama LLM响应速度：Llama 3.1 8B在CPU上推理首次响应可能较慢（几秒），但后续对话会有缓存，速度加快。如果追求极致速度，可以考虑更小的模型如Phi-3-mini，或者为服务器配备GPU。对于指令解析这个固定任务，也可以尝试使用llama.cpp进行更极致的量化（如Q4_K_M）来提升速度。
3. 网络延迟：确保树莓派、Ollama服务器、运行Slack Bot的服务器都在同一个局域网内，尽量减少网络跳转。使用有线网络（Ethernet）连接树莓派和核心服务器，比Wi-Fi更稳定。

6.3 真实场景测试与提示词迭代

将系统部署到工作室后，我进行了大量真实场景的测试。发现最初的系统提示词并不完美。例如：

• 用户问：“桌子干净吗？” LLM可能无法直接映射到“检测桌子上的物体（如杯子、书本）”。我们需要在提示词中增加更多场景化示例和推理逻辑：“如果用户询问某个区域的状态（如‘桌子干净吗’、‘门口堵吗’），你应该理解为用户想了解该区域内存在的物体情况，触发single_scan，并在target_object中尽可能指定相关物体（对于‘桌子’，可关联‘cup’, ‘book’, ‘laptop’等）。”
• 用户指令模糊：“看看。” 这时LLM应该主动询问澄清问题，但我们的JSON输出格式是固定的。因此，我修改了逻辑：当Ollama Agent认为指令过于模糊时，它不再调用树莓派，而是直接通过Slack Bot回复一个澄清性问题，例如：“你想让我看什么呢？是看看有没有人，还是检查一下设备？” 这需要修改Ollama Agent的代码，使其具备多轮对话的上下文管理能力（可以简单维护一个以Slack用户或会话为键的短期记忆字典）。

6.4 安全性与隐私考量

这是一个本地化系统，数据不出局域网，隐私性已经很好。但仍需注意：

• Slack Token安全：Bot Token和App-Level Token必须妥善保管，不要硬编码在代码中，应使用环境变量或配置文件。
• 服务访问控制：Ollama Agent和树莓派Agent的API端点不应暴露在公网。如果Slack Bot服务部署在云上（Slack需要能回调到它），则需要使用Ngrok或云服务器，并配置防火墙规则，只允许Slack的IP地址访问回调端点。
• 摄像头权限：明确告知工作室成员摄像头的存在和用途，避免隐私纠纷。

经过几轮迭代和优化，这个多智能体框架已经可以比较可靠地运行。我可以通过Slack随时询问工作室状态，它会调用树莓派摄像头拍一张照，用YOLO分析，然后通过LLM组织成一段话回复我，比如“当前房间内检测到一个人坐在椅子上，面前有一台笔记本电脑，墙角有一个背包。” 这个过程从发出指令到收到回复，总耗时大约在5-8秒，对于非实时监控的查询场景，完全可接受。这个项目成功地将边缘感知、自然语言理解和即时通讯工具串联起来，构建了一个低成本、高可定制性的智能空间感知原型，其中的架构思路和踩坑经验，对于想构建类似多模态交互系统的朋友，应该有一定的参考价值。