想要一个个人AI助手，不是聊天机器人，也不是副驾驶，而是真能干活的家伙：控制桌面、读取屏幕、跟智能家居对话、用芬兰语或英语回答问题，而且永远不把数据发到别人控制的服务器上。

云端方案确实好用，但那些不属于他。于是他动手自己造了一个。

这个项目目前还在推进中：docker-compose已经就绪，Ollama实例跑起来了，第一个智能体是下一步的事。他把架构文档写了出来，因为设计决策本身有意思，也因为可能有人想照着搭一套。

它是什么，不是什么

这不是托尼·斯塔克那种贾维斯。按他的说法，它更接近一个尊重隐私的家用自动化大脑，或者说是把优秀的命令行助手和智能家居中枢捏在一起，再给它装上眼睛。

核心思路很清晰：轻量编排器Ollama负责决定做什么，专职智能体负责怎么做。每个智能体跑在自己的Docker容器里，所有东西都留在本地网络。

它能做的事包括：

  • 控制Linux桌面（音量、亮度、窗口管理）
  • 在收到指令时读取屏幕
  • 对接Home Assistant（灯光、传感器、自动化）
  • 回答问题、解释代码、芬兰语与英语互译
  • 完全在消费级硬件上本地运行

它不做的事只有一件：把命令、屏幕内容或语音发给OpenAI、谷歌或任何其他方。

为什么用Ollama当大脑

Ollama能在本地跑小而够用的模型，关键在于函数调用能力。它不直接执行命令，而是返回一个结构化的JSON决策，比如“调用set_volume函数，参数level为75”。

这比把原始bash权限交给模型干净得多。函数列表是一份严格的允许清单，用JSON Schema定义，模型只能调用明确许可的接口。不管指令措辞多有创意，也碰不到rm -rf /。

他选的模型刻意偏小，中端GPU能轻松容纳，纯CPU也能跑。他那台英特尔i5台式机应付得来。

三个智能体各管一摊

系统智能体负责Linux桌面控制，通过wmctrl、xdotool、playerctl和DBus操作当前会话：调音量、调亮度、启动应用、获取活动窗口信息、控制音乐播放、读取CPU内存磁盘等系统状态。没有原始bash，每个函数都明确定义。

视觉智能体是“眼睛”。它截屏或读取摄像头画面，再交给轻量视觉语言模型Moondream2分析，能回答“前台是哪个窗口”“那个构建成功了吗”“我第二块显示器上现在是什么”这类问题。

Home Assistant智能体通过WebSocket API对接家里的实例，灯光、开关、温控、传感器都能访问。他可以下这样的指令：“关掉办公室的灯，但只在没人的时候”——系统会先查占用传感器再动手。

此外还有媒体与数据智能体，按需拉取外部数据：天气预报、电价（在芬兰很实用）、InfluxDB日志，或通过无头浏览器做网络搜索。

安全层：敏感操作要人点头

让AI系统控制桌面是一条重要的信任边界。对敏感操作，他做了人在回路的设计：系统不会直接执行，而是先弹出桌面通知说明拟执行的动作，等待点击或快捷键确认，只有明确批准后才动手。

按他的说法，这不是多疑，是合理。函数允许清单在模型层面挡掉了大部分问题，确认提示则兜住剩下的边缘情况。

语音输入用Faster-Whisper，纯CPU环境可用whisper.cpp，热键按下即说；输出用Piper TTS，速度快、本地运行，芬兰语语音自然得出乎意料。整条链路是：热键、Whisper、Ollama、函数调用或文本、Piper TTS、扬声器，端到端延迟目标定在1秒以内。

为什么不直接用Home Assistant自带的Assist

Home Assistant确实有Assist功能，支持wyoming-satellite和兼容OpenAI的端点。他的长期计划正是接入Assist管道，这样就能用上HA的语音按钮。

但先把智能体独立建起来，意味着它们不依赖HA也能工作，以后还能以其他方式组合。模块化是设计的一部分。

接下来的安排：本周让Ollama跑起qwen2.5:3b，用Python脚本测试函数调用；然后做第一个智能体，以音量和亮度控制作为概念验证；再往后是语音管道和Home Assistant集成。代码会在值得分享时放到GitHub上。