--- author: OOMOL author_url: https://oomol.com/zh-cn/about/ datePublished: 2026-09-23 title: 从 Meta Muse 到 Leina：AI 助理要真正懂你，先要连接你的世界 description: 从 Meta Muse 的个人助理体验到 Leina 的团队协作，了解 AI 为什么需要跨应用上下文，以及 OOMOL 与开源 OpenConnector 如何提供授权、账号连接和应用操作基础设施。 lang: zh-CN canonical_url: https://oomol.com/zh-cn/blog/meta-muse-ai-assistant-oomol/ markdown_url: https://oomol.com/zh-cn/blog/meta-muse-ai-assistant-oomol.md --- ![AI 助理通过连接层理解个人生活与企业工作：从上下文、记忆到行动](/img/blog/meta-muse-ai-assistant-oomol/zh-cn-cover.webp) 一个真正了解你的助理，应该知道什么？ 它知道你下周要出差，知道你习惯坐靠过道的位置，也知道那场客户会议刚刚改了时间。你请它安排一次聚餐，它会想到朋友的饮食禁忌、大家的空闲时间，以及你在 Instagram 收藏过的那家餐厅。 这些信息早已存在。它们分散在聊天、邮件、日历、收藏和工作系统里，等着你一次次寻找、复制，再重新解释。 **这就是世界需要 Muse 这类产品的原因：人们希望有人能理解自己的处境，记住交代过的事，并把后续工作推进下去。** 2026 年 9 月 8 日，Meta 正式发布个人 AI 智能体 Muse。按照[官方介绍](https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/)，它可以在自己的云端计算环境中使用浏览器、处理任务、记住用户偏好，并在用户关闭应用后继续工作。用户可以在 Muse 应用或 WhatsApp 中与它交流，决定开放哪些应用和权限。 当这样的体验走进个人生活，也走进企业，背后有一项共同的基础设施需求：**让 AI 在获得授权后，持续连接人们已经使用的系统。** 这正是 OOMOL 所提供的连接网关的价值。 ## 为什么我们需要一个“了解自己”的 AI 助理 试着把两件事交给 AI。 第一件：“给我写一份出差准备清单。” 第二件：“根据下周的客户会议，帮我把这次出差准备好。” 第二件事需要具体得多的信息：会议在哪里、几点开始、客户发来了哪些材料、行程有没有冲突，以及你对交通和住宿有什么偏好。要完成它，助理需要读取最新日历、检索邮件、查看相关文档，再根据你的授权安排下一步。 Meta 的 Muse 设计文章给出了一个很贴近日常的例子：整理孩子返校相关的学校邮件和网站信息，把关键日期加入家庭日历，并协助准备用品。这里最有用的能力，是把散落的信息组合成一件可以完成的事。[产品设计说明](https://introducing.muse.ai/) 个人生活天然跨应用。Facebook、Instagram、WhatsApp 承载社交关系、兴趣和沟通；Gmail、Google Calendar、Google Drive 承载邮件、日程与文件。购物、旅行、支付和各种生活服务，又各自保留着一部分信息。 用户通常不会按软件边界思考。他只会说：“帮我把周末安排好。” **一个有用的助理，需要围绕人的目标组织信息，而这些信息往往来自多个应用。** 具体能读取什么、执行什么，仍取决于各平台开放的接口、账号类型和用户授予的权限。 ## 企业也需要这样的助理，只是上下文更复杂 在企业里，“了解我”进一步变成了“了解我们的业务”。 一位销售说：“帮我准备明天的客户沟通。”助理需要知道的，可能包括 CRM 中的跟进记录、邮件里的最新需求、ERP 中的订单和交付状态，以及知识库里的产品资料。 一位运营负责人说：“看看我们下个月该推哪些产品。”助理需要结合市场研究、客户反馈、现有库存和历史销售情况，才能给出与这家公司有关的建议。 | 助理需要理解什么 | 信息通常在哪里 | 能帮助推进什么工作 | | --- | --- | --- | | 个人的安排与偏好 | 邮件、日历、聊天、收藏 | 行程准备、信息整理、后续提醒 | | 客户正在经历什么 | CRM、邮件、客服与团队消息 | 沟通准备、风险梳理、跟进草稿 | | 业务当前能承诺什么 | ERP、订单、库存与业务数据库 | 交付核对、异常定位、补货分析 | | 团队如何做事 | 企业知识库、共享文档、项目记录 | 查找依据、复用方法、生成交接材料 | | 外部市场发生了什么 | 搜索、研究工具、行业与社媒数据 | 竞品观察、需求研究、机会汇总 | 这些是助理的任务场景示例，实际实施时应逐项确认所需连接、权限和可用操作。 企业还多了一层要求：同一家公司里，不同成员能够访问的信息、能够执行的操作并不相同。销售可以查看自己的客户，并不意味着可以访问所有财务数据；能够读取订单，也不意味着可以修改价格。 因此，企业助理需要把业务上下文、持续记忆和访问权限一起组织好。 ## Leina：让助理在团队日常工作的地方接住任务 [Leina](https://leina.ai/zh-cn/) 把这种需求放进了团队聊天场景：在大家讨论任务、交换信息的地方，加入一位能够调用工具的 AI 员工。 从官网介绍可以看到，Leina 的特色集中在几个与持续工作有关的能力上。 **在熟悉的聊天渠道里交代任务。** 官网展示了飞书、企业微信、钉钉、Slack、Teams 和 Discord 等渠道。接入后，成员可以直接在聊天里交代工作，助理根据任务调用已连接的应用。 **保存工作背景，延续之前的进度。** Leina 使用 Memory 保存团队习惯和项目背景；群聊与私聊分别拥有工作上下文。耗时工作和定时任务可以在后台继续，完成后再反馈结果。 **把跑通的方法变成团队可以复用的 Skill。** 任务步骤、需要使用的应用和检查项可以组织成 Skill。下次遇到类似任务，团队就有一套可以继续完善的方法。 **按组织和成员权限使用账号。** 管理员连接业务账号并设置操作范围，成员无需拿到账号密码或原始 Token，就能在授权范围内使用相关能力。 例如，团队可以从这样一个任务开始设计自己的工作流程： > @Leina，整理本周客户反馈，结合客户记录和交付情况，列出需要跟进的问题，先给我一份草稿。 这项工作需要跨系统查资料，需要知道团队关心什么，也需要清楚哪些数据可以访问。这里，聊天提供入口，记忆保存背景，Skill 组织方法，连接层提供执行工具的路径。 ![从任务到结果的五个环节：聊天接收任务，记忆补充背景，Skill 组织步骤，连接层按权限调用系统，再交付结果](/img/blog/meta-muse-ai-assistant-oomol/zh-cn-workflow.webp) *图：团队助理完成跨系统工作的概念流程，非产品界面或实际任务运行记录。* ## OOMOL：为助理提供连接真实系统的网关 如果你正在开发这样的助理，很快就会遇到一批重复出现的问题。 每个平台怎样授权？Token 过期后怎样处理？用户连接了两个邮箱，这次该用哪一个？这个操作需要什么权限？调用失败后，怎样找到对应的执行记录？ 当应用数量增加，这些问题会变成一项长期维护工作。 **OOMOL 将账号连接、授权与凭证管理，以及具体应用操作，组织成可复用的连接基础设施。** Agent 或产品后端可以使用统一的调用方式访问已授权的服务，把更多精力投入到任务理解、记忆和用户体验上。 ### 连接广度，让更多上下文进入任务 截至 2026 年 9 月 23 日，OOMOL [公开目录接口](https://connector.oomol.com/v1/catalog)列出 **1,559 个服务、18,035 项操作**。这些数字描述的是目录规模，具体任务仍需确认目标服务、操作实现与授权条件。 对助理来说，服务数量的意义最终落在一件事上：当任务涉及邮件、文档、客户记录、分析工具或业务系统时，开发者能否找到相应的访问能力。 操作的深度同样关键。连接一个应用之后，能否检索需要的记录、读取详情、创建内容，或在授权后更新数据，决定了助理能够把任务推进到哪一步。 ### 授权与凭证管理，让连接可以持续使用 在 OOMOL 的托管连接方案里，网关负责持有服务凭证并发起实际调用。应用代码通过连接标识选择账号，无需自行持有每一家服务的原始 Token。[SDK 文档](/zh-cn/docs/connector-sdk/) 如果你在开发面向多个用户的助理产品，`ProjectConnector` 则面向终端用户各自连接账号的场景：让每个用户授权自己的服务，再由产品后端选择正确的账号执行操作。[SaaS 接入指南](/zh-cn/docs/connector-saas/) ### 明确的操作与执行记录，让团队能够管理连接 OpenConnector 提供操作的输入输出结构、所需权限、连接身份、允许或禁止的操作策略，以及脱敏运行记录。开发者可以核对“允许做什么”，也可以在失败后追查具体调用。 这类连接控制，需要与助理产品自身的用户身份、任务确认和业务审批配合。例如，整理一份客户跟进草稿，与真正发送给客户，应当按产品设计采用相应的执行流程。 ![应用层、连接层与业务系统的关系：Leina 或自建助理通过 OOMOL 或 OpenConnector 按权限访问邮件、CRM、ERP 和知识库](/img/blog/meta-muse-ai-assistant-oomol/zh-cn-gateway.webp) *图：OOMOL 在助理架构中的位置。系统名称表示典型接入需求，具体支持以当前目录和接口权限为准。* ## OpenConnector：连接基础设施也应当可以被掌控 助理越深入业务，团队就越关心凭证保存在哪里、连接服务运行在哪里，以及谁能够排查和限制它的行为。 OOMOL 提供托管连接服务，也通过开源项目 [OpenConnector](https://openconnector.io/) 提供自部署路径。团队可以根据上线速度和运维要求选择： | 路径 | 适合怎样的团队 | | --- | --- | | OOMOL 托管服务 | 希望尽快接入应用，由 OOMOL 处理托管连接与凭证层运维 | | 在 Cloudflare 部署 OpenConnector | 希望在自己的 Cloudflare 环境里运行连接服务 | | 自托管 OpenConnector | 希望在自己的环境中管理运行时、凭证、策略和执行记录 | OpenConnector 的开放范围包括连接运行时、服务定义、操作结构，以及有对应实现的本地执行代码。第三方服务本身及其 API 使用条件仍由各平台决定。[自部署指南](/zh-cn/docs/openconnector-self-hosting/) 截至 2026 年 9 月 23 日，[GitHub 仓库](https://github.com/oomol-lab/open-connector)已获得 **5,873 Stars 和 512 Forks**。这些数字体现了开源社区的关注与派生开发活动；对于选择基础设施的团队，更直接的价值是能够查看实现、检查操作契约，并在需要时自行部署和维护。 ## 下一代助理，需要把理解与行动连接起来 Muse 展示了个人助理的一种方向：记住重要的事，在后台推进任务，在需要用户决策时回来确认。Leina 则把持续协作带进团队聊天，让记忆、Skills 和按权限调用应用服务于日常工作。 支撑这些体验，需要模型理解任务，需要记忆延续背景，也需要一条稳定的路径去访问真实系统。 **AI 助理要真正了解一个人或一家企业，就需要在授权范围内接触他们正在使用的信息和工具。OOMOL 为这条路径提供可复用的连接网关。** 想从团队里的一个具体任务开始，可以[试用 Leina](https://leina.ai/zh-cn/)，连接必要的应用，先让它完成一份可核对的工作成果。 如果你正在构建自己的助理产品，可以从 [OOMOL Connector SDK](/zh-cn/docs/connector-sdk/) 开始接入；需要掌控连接运行时，则可以查看 [OpenConnector](https://github.com/oomol-lab/open-connector)。 --- *资料说明：本文依据 Meta 与 Leina 官方公开介绍、OOMOL 文档及 2026 年 9 月 23 日查询的目录和 GitHub 数据撰写，未进行产品实测。文中将 Muse 作为个人 AI 助理的产品案例，不表示 Meta Muse 使用 OOMOL，也不表示两者存在合作关系。配图为原创概念示意图。*