Field note · 2026
Manus 为什么要把 Agent 拆成另一个 App？
CUE 不只是 Manus 的手机简化版，它把 Agent 从项目里的执行能力，变成了有身份、能持续行动的代理人。
图 1：Cue 官方产品插图，展示 Agent 列表与单个 Agent 的配置界面。来源：Manus 2.0 官方发布页。
第一眼看上去，CUE 像是 Manus 的移动端减法。Manus 里已经有项目、文件、工作流、专业工具和桌面控制，放进手机确实显得拥挤。
再单独做一个 App，似乎只是把复杂界面拆开；里面再建几个不同 profile 的 Agent，分头做事。
这个判断抓住了界面问题，但还没碰到产品设计的核心。
Manus 2.0 给每个 CUE Agent 配了自己的邮箱、电话号码、钱包和电脑。它可以在你离开后继续工作、接听转给它的电话，也可以把多个 Agent 拉进同一场群聊，让它们分工完成一个目标。
此时 Agent 已经不只是某个项目里被调用的一项能力，而更像一个有持续身份、能在自己的环境里行动的代理人。
但“独立 App”说的是用户和产品的边界，不等于底层技术另起一套。Manus 明确说 CUE 建在与 Manus 相同的基础设施上。更像是共用执行底座，在上层分出不同的交互、身份和授权体验。
我倾向于把 CUE 理解成 Manus 对一个新问题的回答：当 Agent 从“帮我完成一项任务”变成“替我持续处理一些事情”，它还应该住在原来的工作台里吗？
工作台里的 Agent，和通讯录里的 Agent
Manus 最初让人记住的，是给一个目标，然后看它自己搜索资料、操作浏览器、写代码、生成文档，最后交回一份结果。
它的基本对象是任务或项目：我带着一个问题进入 Manus，Agent 在一个工作空间里执行，产出一个可以查看、修改或分享的东西。
这和 CUE 公开展示的对象不太一样。CUE 里可以有不同职责的 Agent，它们各自有邮箱、电话、钱包和 computer workspace，可以连接 Gmail、Trip.com、Oura 等服务，也能设置重复执行的 routine。
你不只是在启动一次任务，而是在建立一个以后还会继续接活的执行者。CUE 产品页
“给 Agent 不同 profile”因此只说对了一半。Profile 主要回答“它怎么说话、会哪些技能”；独立邮箱、电话和工作空间回答的是“它以什么身份行动、行动在哪里发生”。
这是产品语义的变化。
Manus 没有公开 CUE 背后的身份系统和隔离机制，不能据此断言每个 Agent 都拥有独立进程、独立记忆数据库或独立虚拟机。
如果把两者放在同一张桌面上，区别会更清楚：Manus 像一个工作台，桌上有正在处理的项目；CUE 更像一个通讯录，里面有几个可以托办事务的人。
工作台关心任务如何完成，通讯录关心谁会持续替我处理哪类事情。
“手机上看起来太复杂”确实是一个问题，但它还不是全部答案。手机端的 CUE 有电话、通知、扫码创建 Agent、群聊和稍后回来看结果等交互。
图 2：Cue 官方产品页展示的手机端 Agent 对话演示。来源：Cue。
把这些塞进原来的项目工作区，未必只是多几个按钮的问题。用户进入产品时，究竟是在建造、编辑一个成果，还是在把事情交给一个人？
两种心智的节奏不同，分成两个入口有它的合理性。
从产品形态看，两个入口面向不同的工作对象：一边围绕项目、产物和编辑过程组织；另一边围绕 Agent 身份、持续委托和行动反馈组织。
图 3：Cue 官方产品页展示“扫描二维码创建 Agent”的场景。来源：Cue。
多个 Agent 不是多几个聊天头像
Manus 用三个 Agent 协作准备一个发布活动作例子：一个找场地，一个整理候选名单，另一个起草演示文稿。这个故事很容易让人想到 Grok Bot。
xAI 把 Grok Bot 介绍成一组有自己的云端电脑、能跨应用做工作的 AI 同事。
多个 Bot 可以并行处理工作、互相传递上下文，再把需要人判断的部分交回来。xAI 对 Grok Bot 的介绍
两者的共同点，是把多个 Agent 放到产品表面，让用户感觉自己在管理一支小队，不必一直给万能聊天框换提示词。
差别在于公开叙事的重心：Grok Bot 更像给工作任务配 AI 同事；CUE 把小队协作延伸到生活事务，Agent 可以用自己的电话和邮箱联系外部服务。
图 4：Cue 官方产品页展示多个 Agent 在同一群聊中分工交接。来源：Cue。
多个 Agent 本身并不会自动带来团队协作。一个团队要有清楚的任务切分、共享目标、交接规则和结果核验。
缺少这些机制时，把工作拆进多个聊天窗口，最后仍然要由用户复制上下文、协调重复劳动。
CUE 的产品页展示了群聊协作的设想，但它如何分配状态、检测冲突、追踪来源、避免互相覆盖，公开信息还不够。
Meta Muse 是另一个参照，但它的产品形态又不同。Meta 把 Muse 描述为一个持续了解个人目标的私人 Agent，运行在专属 VM 中，另有与 Muse 系统级隔离的 Sentinel 检查其对外行动。
Meta 还称，发送邮件、付款等敏感操作前会征求许可。Meta 对 Muse 的设计说明
因此，CUE、Grok Bot 和 Muse 都在从回答问题转向跨应用行动，但各自采用不同的组织方式：一支 Agent 小队、一个 AI 同事组织，或者一个深度个性化的个人助理。
Hermes Agent 又是另一类东西。它是开源、可自行部署和配置的 Agent 运行环境，更像用户自己搭建和运营的系统，而不是开箱即用的消费级个人助理。Hermes Agent 项目
“自己的电脑”不等于已经知道它的技术内幕
Manus 的确公开过一些底层设计。它早期的技术文章把 Agent 描述成一个反复“选择动作—执行工具—读取观察结果”的循环；工具结果会继续进入上下文。
文章还谈到用文件系统外置较长任务的状态、用状态机控制当前可用动作，以及保留失败记录来帮助模型调整后续行动。
Manus 的 Context Engineering 文章
它的运行环境也不只有一种。Manus 过去说明，常规任务可以分配临时 sandbox；需要长期运行的应用和脚本则可以放进持久的 Cloud Computer。
前者适合有明确交付物的任务，后者适合离开对话后还得继续工作的服务。Manus Sandbox 说明；Cloud Computer 说明
Manus 2.0 把内部 Agent harness 称为 Cascade，称它会按项目需要引入专门能力。这个方向与产品形态有关：同一套底层能力可以服务不同任务，但 Manus 没有公开 Cue Agent 与项目型 Agent 是否走相同的 runtime、记忆和调度路径。
现有公开资料也没有说明 CUE 具体如何实现身份隔离、凭证托管、电话能力、操作审批和审计记录。
尤其要小心把“每个 Agent 有自己的电脑”直接等同于“每个 Agent 有一个经过严格隔离的安全 VM”。Meta 对 Muse 的 VM 和 Sentinel 边界讲得相当具体；Manus 对 CUE 目前公开的是产品资源和权限控制的描述，并没有给出同等细度的安全架构。
两个产品都说 Agent 能行动，不代表它们在身份、环境隔离和出站审批上采用了同一套实现。
技术上真正值得观察的，可能不是 Agent 能不能多开，而是系统怎样管理一组持续存在的执行环境：身份和凭证如何绑定，工作状态如何延续，用户如何调权限，失败后谁来接管。聊天界面可以很轻，背后的责任链不能含糊。
一场产品发布，也是一场关系设计
Manus 在 2026 年 9 月 1 日宣布恢复独立运营，随后在 9 月 28 日发布 Manus 2.0 和 CUE。
独立运营公告提到，下一阶段会让 Manus 更深入日常工作流、更直接地与外部世界交互，并更主动地替用户行动。
时间上的相邻让 CUE 看起来像这条产品方向的具体落地，但目前没有证据证明“独立运营”就是拆分 App 的直接原因。Manus 恢复独立运营公告
发布后的社区讨论也还很早。Linux DO 的帖子里，几位用户在找邀请码入口，也有人好奇 Agent 能否拥有美国电话号码；还有用户遇到 Agent 命名与邮箱前缀冲突。这些小信号更贴近 CUE 的产品形态：用户正在摸索如何创建、命名和配置一个有独立身份的 Agent。Linux DO 讨论
样本只有少数发布日帖子，不能据此推断整体使用体验。CUE 仍处于 early access，Manus 表示 iOS 版本还在等待 App Store 审核。Manus 2.0 发布说明
眼下更值得追踪的问题是：用户会不会把 Agent 当作持续协作的角色；跨应用工作能否稳定完成；权限边界和行动记录能否让人放心；多个 Agent 是否真的减少了人亲自协调的步骤。
所以，我现在不把 CUE 看成“Manus 为手机做了一个精简版”，也不只把它看成“多 profile 的 Agent”。它在尝试把 Agent 从工作流里的一个工具，变成一个有身份、能持续工作、可以接受委托的角色。
独立 App 是用户与这个角色相处的空间；邮箱、电话、钱包和电脑，则是它走出聊天框所需的行动接口。
这个想法有吸引力，也有一道很实际的门槛：当 Agent 有了自己的电话和钱包，用户想知道的不只是“它能不能做到”，还包括“它刚才以谁的名义做了什么，出了问题我能不能停下来”。
CUE 真正要证明的，最终不是 Agent 有多少个，而是人能不能放心地把一件事交出去，再把注意力拿回来。