2026 年 9 月中旬,XNet-NGO 在 GitHub 上开源了 Aiope——一个声称拥有 57 个工具、纯端侧运行的 Android AI Agent。Aiope 的工程含义远超一个普通开源应用——它在一个 50 stars 的小项目里,把"端侧 Agent"的所有关键能力都拼到了一起:完整的 Linux 终端(基于 proot Alpine Linux,不需要 root)、实时语音交互
2026 年 9 月中旬,XNet-NGO 在 GitHub 上开源了 Aiope——一个声称拥有 57 个工具、纯端侧运行的 Android AI Agent。Aiope 的工程含义远超一个普通开源应用——它在一个 50 stars 的小项目里,把"端侧 Agent"的所有关键能力都拼到了一起:完整的 Linux 终端(基于 proot Alpine Linux,不需要 root)、实时语音交互(走 Google Gemini Live API)、浏览器自动化、SSH 远程管理、动态 UI 构建、on-device RAG、MCP 协议支持、agent loop 最长 140 轮每 turn。XNet 自己也把 Aiope 定位成"AI 智能体在手机上的旗舰样本"——项目背后是 XNet Inc.,一家"由一个人加 AI 经营的实际公司",投资方包括 Harvard、GitHub、Amazon AWS、Infobip、Mercury。这家公司本身就是一个"AI 经营公司"的活样本——它的主营业务就是构建和运营 Aiope 这个 agent 平台。端侧 Agent 在 2026 年下半年已经从"概念验证"快速推进到"工业可用"——除了 Aiope 之外,同期出现的 Sova AI(Ayconic.io)、heybro、SannaBot、Android-MCP、PicoClaw 等项目共同构成了"Android AI Agent 工具集"的早期生态。把 Aiope 和 Sova 这两个工程上最完整的项目放在一起,可以提炼出 2026 年下半年端侧 Agent 平台的关键工程基线:Agent loop 必须 on-device、凭据治理必须 BYOK、工具集必须广而深、终端/浏览器/SSH 三件套必须齐全、agent loop 长度必须以"完成完整任务"为单位而不是以"一次 prompt-response"为单位。
一、Aiope 的工程全貌:57 个工具 + 5 种运行模式 + 完整 Linux 终端
Aiope 的 README 把整个项目的工程目标写得相当明确:"An AI that doesn't just talk. It acts."——不是聊天机器人,是真正在手机上"做事"的 AI。具体来说,Aiope 在工程上提供了五个层次的能力。
第一层:基础 chat + 语音 + 屏幕感知。Aiope 默认工作模式是 chat,但支持实时双向语音(走 Gemini Live API),并且能"看到"用户当前屏幕——这意味着用户在任何 app 里看到不懂的内容,可以一键召唤 Aiope 来解读,而不需要切换 app。基础模型可以选择任何 OpenAI-compatible API——BYOK(自带 Key),用户的对话、文档、知识库全部保留在设备本地。
第二层:5 种运行模式。Aiope 不只有一种工作模式,而是分了 5 种:Chat(对话式,带工具调用)、Voice(实时语音,带工具调用)、Plan(只读分析模式,AI 探索上下文并产出结构化 plan 但不执行任何动作)、Build(自主执行模式,AI 自主串工具完成完整任务,中间不打断用户)、Media(图像/视频生成直连模式)。这 5 种模式覆盖了从"问个问题"到"替我办件事"到"别动手只给我分析"到"生成图片"的全部常见场景。
第三层:57 个工具 + 8 个内置 agents + 自定义 agent 构建器。57 个工具是 Aiope 最有冲击力的数字——它意味着用户可以用纯语音/纯文本让 Aiope 完成"发短信给朋友"、"加日历事件"、"设闹钟"、"查天气"、"生成图像"、"总结网页"、"搜索并记住"等日常动作。8 个内置 agents 覆盖了不同领域的常用任务;自定义 agent 构建器允许用户自己拼装工具组合,创造新的 agent。
第四层:完整 Linux 终端。Aiope 内嵌一个 proot Alpine Linux 环境——proot 是一种不需要 root 权限的伪 root 技术,允许用户进程以为自己有 root 权限(实际上没有),从而能跑 apt-get、跑 shell 脚本、跑编译器。这条设计让 Android 手机第一次变成了一台"真正的 Linux 机器"——用户可以让 Aiope "在手机上写一段 Python 代码、运行它、捕获错误、修复、再次运行"——整个循环完全在端侧完成。
第五层:agent loop 长度 140 轮每 turn。这是 Aiope 在工程上最关键的指标——传统 chatbot 一次只能"问 + 答",agent 一次可以"问 + 多步推理 + 多个工具调用 + 多个工具结果读取 + 决策 + 再调用 + ......"——140 轮意味着一个 turn 可以完成非常复杂的多步任务。README 给出了一个示例:"research a topic, write code, save it, run it in the terminal, fix the errors, and report back, all in a single turn"——这种"端侧完成完整任务"的能力,在 2026 年下半年的端侧 Agent 里还是相当罕见的。
Aiope 背后的工程栈相当严肃:~1000 commits across 26 repositories,包含一个自托管的 AIOPE Gateway(统一路由到 Google AI Studio / Pollinations 等 provider)、自研的 Compose markdown renderer、自研的 proot Alpine Linux terminal emulator、Go remote-agent daemon、agent framework。整个项目 license 是 BSL 1.1(Business Source License),允许非商业使用但限制直接商业 fork——这是典型"先开源建生态、商业版另行"的策略。
二、Sova AI:端侧 Agent 的另一条路线——Accessibility API 作为虚拟用户
把 Aiope 与同期出现的 Sova AI(ayconic.io/sova,2026-04 HN 发布)对照,可以看到端侧 Agent 在 2026 年下半年出现的两条互补路线。
Sova AI 的定位是"在 Android 上真正操作 app 的 AI 助手"——不是聊天机器人,不是 LLM 包装器。Sova 的工程核心是用 Android Accessibility API 模拟人类用户在屏幕上点击、滚动、输入。用户给出 prompt("帮我打车去机场"、"在抖音里搜索这个产品"),Sova 不会去查文档,而是真的像人一样——它读屏幕 UI 节点树,找到"打开 Uber"、"点击目的地输入框"、"输入机场"、"点击叫车按钮"等 UI 元素,逐一操作。
这条路线与 Aiope 有两个关键差异。
第一个差异:工具集 vs UI 自动化。Aiope 提供 57 个"专门工具"(日历、闹钟、文件、终端、SSH、浏览器等),每个工具都做了深度集成;Sova 不提供专门工具,而是通过通用 UI 自动化能力操作任何 Android app——它能操作任何 app,但操作速度慢、操作准确度受 app UI 复杂度影响。两者本质上是"深度专用" vs "广度通用"的对照——Aiope 速度快但只能做它有工具的事,Sova 速度慢但能做 Android 上几乎任何事。
第二个差异:被 Google Play 拒绝 vs 不受影响。Sova 因为使用 Android Accessibility API 做"通用自动化"(直接操作其他 app),被 Google Play 拒绝上架,只能自己 host APK。Sova 在 HN 上说得很直接:"Google banned us for building the exact agentic behavior that Gemini promises but fails to deliver"。Aiope 没有这个问题——因为它的 57 个工具都是"专门集成",不依赖 Accessibility API。这条差异说明了一个重要的现实:端侧 Agent 在 Android 生态里有两条路,一条是按 Google 规则走"专门工具集成"(Aiope 路线),一条是按用户需求走"通用 UI 自动化"(Sova 路线),后者在合规上有更大摩擦。
三、端侧 Agent 的工程基线:从这两条路线看 2026 下半年的共识
把 Aiope + Sova 放在一起,可以看到 2026 年下半年端侧 Agent 的五条工程基线。
基线一:Agent loop 必须 on-device。Aiope 把 140 轮推理循环完全跑在手机本地;Sova 把 UI 自动化循环完全跑在手机本地。这与传统 SaaS Agent(每次动作都要发到云端)形成鲜明对比——端侧 Agent 在延迟、隐私、可用性(无网络也能跑)三方面都有结构性优势。Aiope README 特别强调"Your conversations, documents, and knowledge base stay on your device"——这条隐私承诺是企业用户采用端侧 Agent 的关键驱动力。
基线二:凭据治理必须 BYOK。Aiope 默认 BYOK(自带 Key),用户可以选择任何 OpenAI-compatible API;Sova 同样强调"100% Free / Bring Your Own Key",由用户自带 OpenAI / Claude / Gemini key。这与 Pangolin 模式(用 SSO + WireGuard 替 key)的思路略有不同——BYOK 模式把"用户拥有凭据"作为隐私基线,而不是把"消除 key"作为隐私基线。两条路线在隐私上殊途同归,但 BYOK 模式让端侧 Agent 更容易被个人开发者直接上手。
基线三:工具集必须广而深。Aiope 提供 57 个工具覆盖"日常使用 + 编程 + 系统管理"三大场景;Sova 通过通用 UI 自动化间接提供"任何 Android app"作为工具。两条路线都把"工具丰富度"作为产品差异化的核心——端侧 Agent 不能只做 chat,必须能"做事"。
基线四:终端/浏览器/SSH 三件套必须齐全。Aiope 提供完整 Linux 终端(基于 proot Alpine Linux)、浏览器自动化、SSH 远程管理——这三件套是"Agent 能做事"的基础设施。Sova 通过 Accessibility API 间接提供"浏览器自动化"(操作 Chrome app)与"SSH"(操作 Termius app),但完整 Linux 终端它没有——这是 Sova 在"开发者场景"里的能力短板。任何想做"Agent for developer"的端侧项目,终端 + SSH 都是标配。
基线五:agent loop 长度必须以"完成完整任务"为单位。Aiope 把 agent loop 长度做到 140 轮每 turn——这意味着一个 turn 可以完成"研究 + 编码 + 测试 + 修复 + 报告"的完整任务链。Sova 的 UI 自动化循环相对短(因为每次动作需要等用户界面响应),但通过多次串联也能完成复杂任务。这条基线的工程意义是:端侧 Agent 不应该被设计成"一次问一次答"的 chatbot,而应该被设计成"一次任务一次完整执行"的 agent。
四、对企业 Agent 平台的具体启示
把端侧 Agent 的工程基线映射到企业 Agent 平台建设,可以提炼出四条启示。
第一,BYOK 与零信任网络两种凭据模式可以并存。Aiope / Sova 的 BYOK 模式适合个人开发者与企业内的"高级用户";Pangolin 的 SSO + WireGuard 模式适合企业统一身份治理。两条路线在隐私上殊途同归(用户拥有凭据或用户身份不被泄漏),但在部署成本上各有优劣。企业 Agent 平台可以同时支持两种模式——给安全敏感业务走 Pangolin,给开发者自由探索走 BYOK。
第二,on-device Agent 与 cloud Agent 不是替代关系,而是分层关系。端侧 Agent 在隐私、延迟、可用性上占优,但在算力(超大模型)、协作(多 Agent 跨设备协调)、持久化(云端知识库)上占劣势。企业 Agent 平台的合理架构是"端侧 Agent 做轻量任务、cloud Agent 做重任务、agent mesh 做跨边界协作"。Aiope 这种 57 工具 + 140 轮的端侧能力,正好对应"端侧处理日常任务"的角色定位。
第三,Android / iOS / 桌面 / 服务器四端 Agent 必须共享同一套协议。Aiope 支持 MCP(Anthropic 主导的 agent 通信协议),这意味着 Aiope 能与 Claude / 其他 MCP 兼容 agent 协作。企业 Agent 平台建设必须从一开始就坚持使用 MCP 这类标准化协议,而不是各家自己定义私有协议——否则 Android Agent 与 iOS Agent 与 Web Agent 之间就无法互联。
第四,端侧 Agent 必须支持"自治运行 + 人在环上"两种模式。Aiope 的 5 种运行模式里,Build 模式是"自治执行,不打断用户";Plan 模式是"只读分析,不执行任何动作"——这两种模式正好对应"高自主性 + 高风险" 与 "低自主性 + 低风险"两个场景。企业 Agent 平台必须让用户能选择 Agent 的自主性级别——同一任务可以选"完全自主"(Build)、"先给我 plan"(Plan)、"边做边确认"(Chat)。这种自主性级别控制本身就是微软责任矩阵里"Human-in-the-loop approval for high-impact actions"的具体落地。
五、从个人 AI Agent 到"公司就是 AI"
Aiope 这个项目的最后一个值得专门展开的工程点,是它背后的 XNet Inc.——一家"由一个人加 AI 经营的实际公司"。XNet 在 README 里直接披露了它的"投资方名单":Harvard、GitHub、Amazon AWS、Infobip、Mercury,并把 Aiope 定位成"这家公司由 AI 经营的事实证据"。
这条故事本身揭示的工程含义是:当端侧 Agent 的能力到达某个临界点之后,"AI 经营一家公司"不再是营销话术,而是工程现实。一个人 + Aiope 这种 57 工具 + 140 轮的端侧 Agent,加上 cloud-side 的 Copilot / Claude Code,加上 server-side 的 Charter / agentctl,实际上已经能跑通"研究产品方向、写代码、跑测试、运营服务、对接客户、做财务"的全流程。XNet 把这个流程跑成了"一家有 Harvard / GitHub 投资的实际公司",而不是一个 demo 项目。
这条现实对企业 IT 的冲击是:未来 5-10 年,大量"小团队 + AI"的初创公司会用类似 Aiope 这种端侧 Agent 工具链跑起来,它们的运营成本会远低于传统公司。这意味着企业内部 IT 在评估"用 Agent 替代某个岗位"时,不能只看单一 Agent 的成本,还要看 Agent 团队 + 协调 + 治理的整体成本——后者才是真正的工程难点。
六、端侧 Agent 的 2026 下半年坐标
把 Aiope、Sova、heybro、SannaBot、Android-MCP、PicoClaw 等项目叠加在一起看,可以画出 2026 年下半年端侧 Agent 的几个清晰坐标。
在能力维度,端侧 Agent 已经从"chatbot + 一两个工具"演进到"57 个工具 + 5 种运行模式 + 140 轮 loop",能力深度已经接近 desktop 级 Coding Agent(Claude Code / Cursor),但运行平台从桌面缩小到了手机。
在生态维度,端侧 Agent 开始与 cloud Agent 共享标准化协议(MCP、A2A),端侧不再孤立——一个手机端 Agent 可以调用 cloud Agent 处理重任务,cloud Agent 可以调用手机端 Agent 收集端侧数据。
在商业模式维度,端侧 Agent 出现 BYOK(免费 + 用户自带 key)与 SaaS 订阅(平台自带 key 并收费)两种模式。BYOK 模式在个人开发者与企业高级用户里快速铺开,SaaS 模式在企业标准化部署里占优。
在企业 IT 维度,端侧 Agent 给企业带来一个新的"设备边界"——员工手机上的端侧 Agent 与企业 server 上的 cloud Agent 必须共享同一套身份治理、同一套审计规则、同一套工具权限,否则就会出现"个人 Agent 替企业办事"的合规风险。
把 XNet 的 Aiope 放在这个坐标里,它不只是又一个开源 Android 项目——它是端侧 Agent 工业能力的一个标杆。当一个 50 stars 的小项目都能把 57 个工具、140 轮 loop、完整 Linux 终端、语音交互、屏幕感知拼在一起时,"端侧 Agent 不可用"的旧假设已经站不住脚了。任何想在 2026 年下半年认真落地企业 Agent 的团队,都应当把 Aiope + Sova 这类项目纳入参考架构——它们不只是个人开发者玩具,而是端侧 Agent 工程基线的新坐标。