【Agent】那个搞远程的向日葵也出 AI 了?!不用买设备,不用复杂配置,还支持多平台

【Agent】那个搞远程的向日葵也出 AI 了?!不用买设备,不用复杂配置,还支持多平台

那个搞远程的向日葵也出 AI 了?!不用买设备,不用复杂配置,还支持多平台


请添加图片描述

🌌你好!这里是 晓雨的笔记本在所有感兴趣的领域扩展知识,感谢你的陪伴与支持~👋 欢迎添加文末好友,不定期掉落福利资讯


写在最前面

版权声明:本文为原创,遵循 CC 4.0 BY-SA 协议。转载请注明出处。

最近一段时间,“AI 操作电脑”这件事越来越火。很多人第一次看到这类演示时,都会觉得有点神奇:原来 AI 不只是会聊天、会写文案,居然真的开始会“用电脑”了。

也正因为这样,很多人会下意识觉得,所有“AI 控电脑”的东西,应该都差不多。无非就是让 AI 帮你点点鼠标、输输文字、开开网页、跑跑流程。

但真往下看,其实不是这么回事。

因为有的方案,本质上更像是让 AI 在当前这台电脑上学会干活;而有的方案,更像是把一整套远程控制能力直接交给 AI,让它不只是操作眼前这一台电脑,而是能去连接、查看、操作更多设备。

向日葵 MCP 更接近后者。它真正值得关注的地方,也不只是“向日葵也做 AI 了”,而是那个大家熟悉的远程控制工具,开始让 AI 真正接手远程设备操作这件事了。

比openclaw更简单的配置过程,没有特定环境的需求

很多人一听到“AI + 远程控制”,第一反应就是复杂。

是不是要额外买设备?

是不是要单独搭环境?

是不是要学很多配置?

是不是只有技术人员才能用?

但向日葵 MCP 比较有吸引力的一点,就是它不是让你为了 AI 再重建一套远程控制系统,而是把原本已有的远控能力,直接接到了 AI 这一侧。

这件事的意义其实很现实:普通用户最怕的,不是功能不够多,而是门槛太高。一旦某个东西上来就要求你买一堆设备、改一堆环境、理解一堆概念,很多人其实第一步就放弃了。

如果只是先体验一次,我更建议直接接入 OpenCode。路径比较直观,也更容易快速看到效果。

参考配置链接:https://service.oray.com/question/50091.html?utm_source=client&utm_medium=redirect&utm_campaign=slrc&utm_term=mcp_help&redirect_id=1991

  • 打开向日葵客户端,进入「设置」> 「MCP服务器」。点击「启用MCP服务器」

根据使用场景选择适合的通信方式:

  • Stdio(推荐):本地进程通信,适用于本地运行的 AI 客户端
  • Streamable HTTP:基于 HTTP 的远程通信,适用于需要跨网络调用的场景

可将如下提示词和上述通信方式发送给AI,让AI来完成配置工作。

AI完成配置后,手动检查对应的配置文件是否写入完毕。

确保配置文件写入完毕后,需要先重启OpenCode客户端才能生效,按如下步骤执行操作验证。

  • 重启 OpenCode 客户端
  • 在输入框输入指令 /mcp 检查MCP服务器连接状态

如上所示,如果显示awesun-mcp-server已连接,并且处理开启状态,则配置完成。

整套流程更像是在已有远控能力上,多接了一层 AI 可以调用的接口,而不是重新搭一套很重的系统。这也是它对普通用户更友好的地方。

真正实用的地方,是它更接近现实场景

很多 AI 控电脑的演示都很酷,但对普通用户来说,真正重要的不是演示有多炫,而是它能不能进入日常场景。

向日葵 MCP 的优势就在这里。因为它本来就是从远程设备控制出发的,所以更适合处理那些和“另一台电脑”有关的事情。

比如你人在外面,但文件、软件、资料都在另一台电脑上。以前要自己远程连回去,一步步找、一点点操作。现在如果 AI 能直接接入这套远程控制能力,很多事情就有机会从“我亲自操作”,变成“我告诉 AI 要做什么,它先替我去做”。

再比如,不少人手上本来就不止一台设备。有主力电脑,也有备用电脑;有时还会有挂着程序的机器。真到要看状态、确认界面、做一些基础操作时,最麻烦的就是来回切换。向日葵 MCP 这种能力,正好能让 AI 接手一部分原本必须人反复折腾的远程操作。

还有一种很实用的场景,就是**“先帮我看一眼”** 。很多时候,我们不是马上要做复杂操作,只是想知道另一台设备现在是什么状态:开着没有、卡在哪个界面、有没有报错。AI 如果能先去看、先去判断、先把情况整理出来,人再决定要不要接手,整个体验会轻很多。

  • 发送一句简单指令,比如:帮我查询下设备列表中XXX
  • 设备的配置信息

多平台、可查看、可接手,才是它更适合大众的原因

很多 AI 产品在演示里看起来都很顺,是因为环境通常很理想:一台电脑、一个系统、一个固定流程。

但真实世界不是这样。有人用 Windows,有人用 macOS;有的人有办公电脑,也有家里电脑;有时候甚至还会碰到 Linux 设备、安卓终端。设备一多、平台一杂,很多看起来简单的自动化就会突然变得麻烦。向日葵 MCP 的价值就在于,它不是只盯着单一环境,而是尽量把更多真实设备场景纳入进来。

另外,很多人对 AI 自动化感兴趣,但也会担心:如果它乱点怎么办?如果它看错了怎么办?

这也是为什么**“可查看、可接手”** 很重要。向日葵 MCP 这类能力的一个优势,就是操作过程更容易被看到和监管。用户可以随时查看过程,必要时也能介入。这样一来,AI 不再是一个完全黑盒的执行者,而更像一个可以先帮你做事、你随时能接回来的助手。

awesun-mcp-example-claude/CLAUDE.md记忆文件,预设系统提示词写的很有意思,感兴趣的朋友可以去看看他实际的逻辑。

结语

所以,那个“搞远程的向日葵也出 AI 了”这件事,真正值得看的,不只是它赶上了 AI 这波热度。

更重要的是,它本来就擅长远程控制设备,现在又把这套能力正式开放给了 AI。这样一来,AI 不只是会在你眼前这台电脑上干活,还有机会开始接手更多远程设备相关的事情。

如果你只是想让 AI 帮你处理本机任务,市面上已经有很多很吸引人的方案;但如果你关心的是跨设备、跨地点、多平台、可查看、可接手的远程操作体验,那向日葵 MCP 这条路,确实会更值得普通用户认真看一眼。


hello,这里是 晓雨的笔记本 。如果你喜欢我的文章,欢迎三连给我鼓励和支持:👍点赞 📁 关注 💬评论,我会给大家带来更多有用有趣的文章。
原文链接 👉 ,⚡️更新更及时。

欢迎大家点开下面名片,添加好友交流。

Read more

前端代码可读性优化:让你的代码不再像天书

前端代码可读性优化:让你的代码不再像天书 毒舌时刻 代码可读性?听起来就像是前端工程师为了显得自己很专业而特意搞的一套复杂流程。你以为随便加几个注释就能提高代码可读性?别做梦了!到时候你会发现,注释比代码还多,维护起来比代码还麻烦。 你以为变量名取长一点就能提高可读性?别天真了!过长的变量名会让代码变得臃肿,反而影响可读性。还有那些所谓的代码规范,看起来高大上,用起来却各种问题。 为什么你需要这个 1. 提高可维护性:良好的代码可读性可以提高代码的可维护性,减少维护成本。 2. 减少错误:可读性高的代码更容易理解,减少出错的概率。 3. 团队协作:良好的代码可读性可以便于团队成员之间的协作,减少沟通成本。 4. 代码复用:可读性高的代码更容易被复用,提高开发效率。 5. 降低学习成本:新团队成员可以更快地理解代码,降低学习成本。 反面教材 // 1. 变量名不清晰 function calc(a, b, c) { let x = a + b;

Qwen3Guard-Gen-WEB跨平台方案:Windows/Mac用户云端无障碍体验

Qwen3Guard-Gen-WEB跨平台方案:Windows/Mac用户云端无障碍体验 在现代跨平台开发团队中,协作效率往往被“环境不一致”问题拖累。尤其是当项目涉及AI大模型如Qwen3Guard时,Mac用户常常因为显卡驱动、CUDA支持或算力不足等问题无法本地运行服务,而Windows用户也可能受限于消费级GPU的性能瓶颈。这不仅影响了开发进度,还导致代码审查、功能测试和联调环节频繁出错。 为了解决这一痛点,Qwen3Guard-Gen-WEB跨平台方案应运而生——它将Qwen3Guard模型推理能力封装成一个可云端部署的Web服务,所有团队成员无论使用Mac、Windows还是Linux设备,只需通过浏览器或API即可无缝接入,真正实现“一次部署,全员可用”。 这个方案的核心优势在于:无需本地安装复杂依赖,不依赖特定操作系统,也不要求高性能硬件。你只需要一台能上网的电脑,就能调用强大的Qwen3Guard生成式安全检测能力。特别适合中小型研发团队、远程办公小组或教育类项目组,在保障内容安全的同时极大降低技术门槛。 本文将带你从零开始,一步步搭建并使用这套云端Qwen3

前端高频面试题-场景题,零基础入门到精通,收藏这篇就够了

1、一般vue开发用什么库来辅助 vantUI elementUI js-cookie socket.io axios ECharts 2、页面刚开始出现一片空白的原因 1、网络设置的问题,有可能是IP、端口等出现问题了 2、网速比较慢导致(加载速度慢) 3、浏览器本身出现问题了 4、网络防火墙的问题,设置安全级别过高 5、病毒导致 6、打包路径不对 3、vue的项目如何做首屏的优化 v-if 和 v-show 区分使用场景 computed 和 watch 区分使用场景 v-for 遍历必须为 item 添加 key,且避免同时使用 v-if 长列表性能优化 事件的销毁 addEventlisenter 事件监听 图片资源懒加载 精灵图

【LLM】Ollama:本地大模型 WebAPI 调用实战指南

1. 为什么选择Ollama部署本地大模型 最近两年大模型技术发展迅猛,但很多开发者面临一个现实问题:公有云API调用不仅费用高昂,还存在数据隐私风险。Ollama的出现完美解决了这个痛点,它就像是你本地的模型管家,可以一键部署各种开源大模型。我去年在开发智能客服系统时就深受其益,既避免了敏感客户数据外泄,又省下了大笔API调用费用。 与传统方案相比,Ollama有三大优势:首先是安装简单,用Docker一条命令就能跑起来;其次是模型丰富,支持Llama、Mistral等主流开源模型;最重要的是API标准化,完全兼容OpenAI的接口规范。实测在16GB内存的MacBook Pro上运行7B参数的模型,响应速度可以控制在2秒以内,完全能满足大多数应用场景。 2. 五分钟快速搭建Ollama环境 2.1 准备工作就像搭积木 在开始之前,我们需要准备两个基础组件:Docker和Python环境。这里有个小技巧分享——建议使用Docker Desktop的WSL2后端(Windows用户),性能比传统虚拟机模式提升30%以上。安装完成后,记得执行以下命令验证版本: docker