调研时间：2026 年 10 月 30 日。本文中的 Grok Bot 指 xAI 官方产品，不是 X 上的 @Grok 机器人。结论来自官方产品说明和文档，未独立实测其可靠性、费用或效果；产品和价格可能变化。

一个个人助理最难的地方，往往不是再接一个更强的模型，而是让人知道：它是否记得上文，是否真的查到了资料，动作有没有完成，以及中断后该怎么办。Grok Bot 把这些问题摆在了产品设计中心。它的答案有值得借鉴的地方，也有不适合照搬到我们项目的地方。

它到底是什么

官方介绍把 Grok Bot 描述为可持续工作的 AI 队友：通过对话接收任务，在云端计算机里使用浏览器、文件和终端，与外部应用交互，遇到需要授权的动作时请求用户处理。当前概览列出桌面和移动客户端，并称后台任务可以在客户端关闭后继续。它强调的不只是给出建议，而是尽量让工作发生在实际工具中。

有两个容易误解的细节。第一，多个 Bot 的独立身份不等于每个 Bot 一台隔离计算机：FAQ称同一账户的 Bot 共享一台云端计算机及其文件、浏览器会话和登录状态，因此不能把不同 Bot 当成安全隔离边界。第二，云端计算机与用户眼前的 Windows 电脑是两种不同的执行环境；本地命令执行另有授权设置。它的服务和计划条件会变化，应以当前文档为准。

启示一：连续性要分层，而不是把聊天一直拼长

设计文章将 Bot、聊天、提示、工具和成果作为主要产品对象；Bot 文档描述了偏好、长期事实和工作记录与聊天历史的区别。官方还说明 Bot 会自行决定保存部分记忆，个人 Bot 的记忆通过对话查看、纠正或删除，重置会话不会同时删除记忆。

我们的场景需要更克制的分层。当前代码保留进程内最多 12 轮、48000 UTF-8 字节的已送达对话；重启清空，淘汰时提示前文缺失。真实 Lark 长对话及资源消耗尚待验收。QPC 多维表格是用户明确整理的长期知识来源，Lark 日历是日程来源；不能把所有对话自动变成 QPC 事实，也不必为了模仿 Grok Bot 立刻实现长期自动记忆。

下一步可以先做一组可重复的长对话验收：在第一轮给出合成约束，跨多轮追问并观察约束是否仍在；再故意超过窗口，确认提示出现、模型不编造。记录调用量与实际延迟，而不是把窗口大小等同于理解能力。

启示二：从“回答”到“可核验的结果”

Grok Bot 的产品主张是工作落在真实应用中。对我们的单用户 Lark 助理，这意味着一次“查知识库”应能指出具体记录，而不是让模型凭印象回答。当前 QPC 只读检索已在代码中实现：明确输入关键词，分页查配置中的表，返回匹配片段及记录 ID；部分扫描失败不会说“没有结果”。它尚未完成真实权限与私聊链路验收。

这条路径比先做通用工具平台更适合现在：先验证本人身份、表访问权限、分页、超时和输出；再根据真实需求决定是否支持自然语言路由。若以后要写入 QPC 或日历，至少要记录目标、参数和外部系统返回的可核验结果。返回成功、明确失败和结果不明应分开：网络超时可能发生在对方已处理之后，不能自动重复创建。

调研时间：2026 年 10 月。本文依据 Manus 官方公开材料和本项目现状分析，并非独立测评；产品和订阅规则可能变化。

向一个聊天机器人提问，通常得到一段文字；向一个任务型 agent 提问，我们期待的是一份可以使用、检查、继续修改的成果。Manus 对后者的探索，值得我们研究。但我们要建设的是单用户、Lark 优先、资源节制的个人助理，不必把云端通用工作平台的整套基础设施搬回本机。

Manus 做了什么：把回答变成工作过程

Manus 将任务组织为模型决策与工具执行的循环。其工程文章描述：收到请求后，模型从已有动作空间中选择工具，运行工具得到观察，再把动作和观察加入上下文，直到任务结束。这是厂商对其工程设计的描述，并不意味着每次执行都正确。来源：Context Engineering for AI Agents

官方介绍称，每项任务可获得隔离的云端虚拟机，有文件系统、网络、浏览器和工具。隔离环境可以让 agent 做调研、操作文件、编写和执行代码；它仍需要对外部服务的权限和审计，不能因为称作“沙箱”就假设任何联网动作都安全。来源：Manus Sandbox

此外，Manus 提供本地浏览器和本地计算机接入方式。Browser Operator 文档描述单次授权、任务标签页、人工介入和停止；My Computer 文档描述本地文件夹授权与命令执行许可。这些是特定产品功能的授权机制，不可推导为所有动作都自动安全。浏览器操作 · 本地计算机

对我们最有价值的不是“加一个浏览器”，而是从结果倒推每一步应该留下什么证据：用户要求查询知识库，最终应能看到来源；要求登记日程，应能看到实际创建的事件；遇到超时，应明确“结果未知”，而不是让模型把计划中的动作当作已完成。

上下文工程：保留可以找回的线索

Manus 在工程文章中提到，长上下文会增加成本，过度压缩也会损失信息；它使用文件系统存放可按需重新读取的信息，并尽量保留 URL、文件路径等可恢复线索。文章也讨论稳定前缀与缓存、保留错误以便恢复，以及通过约束动作选择而不是随意删除工具定义来控制工具集。这些是其公开经验；缓存是否可用、是否节省费用，仍取决于具体模型服务。来源

我们的边界不同：当前上下文是进程内最多 12 轮、48,000 UTF-8 字节，按完整轮次淘汰；前文被淘汰后会提示，重启清空。它解决了短期衔接，不能保证任意长对话都不遗忘；真实 Lark 长对话与资源消耗尚待验收。

因此，下一步不必先做一个“自动永久记忆”系统。可以围绕真实对话，区分三类信息：

1. 近期对话：用于连续回答，有明确容量上限和截断提示。
2. 知识来源：用户明确让助理查询或记录的知识，来源放在已有 QPC 多维表格；长期内容不是聊天摘要。
3. 外部状态：日程、知识记录等以 Lark 实际结果为准，保留对应记录标识，而不是以模型自述为准。

例如用户问“继续刚才讨论的方案”，如果关键事实已被淘汰且没有可引用的知识记录，助理应该说缺少依据，请用户补充；只有明确请求查询时，才从获准的 QPC 表中检索相关记录。当前 QPC 只读检索已在开发分支实现，但真实权限、字段和端到端收发仍待验证；写入、修改和删除尚未实现。

从演示走向可靠闭环

Manus 对自动化的介绍强调，可以定义触发条件、数据来源、测试运行、确认方式和失败后的查看与暂停。来源：Automations。这启发我们：功能是否可靠，不在于是否能展示一次成功，而在于它能否处理重复输入和不确定结果。

以“帮我记一条 QPC 知识”为例，一条未来可实现的最小流程应该是：

• 用户明确要求记录，助理检查已有表结构与允许的字段；不改表头，不把所有聊天自动存入知识库。
• 程序校验内容与权限，发送一次写入请求；只有获得可验证的记录标识后，才报告保存成功。
• 接口超时后，不能简单重试或声称失败；先查证是否已经创建，无法查证时明确报告结果未知。
• 重复消息、进程重启和发送结果不明都要有独立测试，保证恢复流程不会绕过授权。

这是设计提议，并非本项目已有能力。第一步仍应先完成 QPC 只读检索的真实验收；之后再根据实际需要选择写入或日历查询。

并行与成本：有用，但不必提前拥有

Manus 的 Wide Research 面向需要对大量独立对象逐项调研的任务；其公开介绍描述主任务拆解、独立子任务并行执行以及结果汇总。来源。文中的质量提升是厂商对架构的论述，不应当直接当成对所有问题有效的独立基准结论。

mem0 最小部署：193MB 跑起来的 Agent 记忆层，瓶颈却不在内存

mem0 是这两年的 Agent 记忆层网红。但当你真的想把它塞进一个个人项目时，第一个问题不是"怎么用"，而是"它到底要吃多少资源"。

Meta Muse 拆解：消费级 Agent 的玩法全解，与上线六周暴露的七个问题

2026 年 9 月 8 日，Meta 发布 Muse，自称「世界首个为所有人打造的个人 AI Agent」。六周之后，它交出的成绩单是双面的：美国日活约 60 万、专用硬件 Muse Charm 定档 12 月发货；同时它也比任何一个同类产品更快地踩中了地址外泄、零日漏洞、被电商平台封禁、被指抄袭开源框架这一整串问题。

这篇文章不站队，只做一件事：把 Muse 的产品设计、技术架构和商业模式拆开，让你看清一个消费级 Agent 到底是怎么运转的，以及这套设计在哪里漏了风。

一、30 秒结论

1. 它是什么：一个「执行型」而非「对话型」的个人 Agent。用户告诉它要完成什么，它自己去开浏览器、填表单、发邮件、谈价格、下单付款；关掉 App 也继续跑，只在敏感动作前回来找你要授权。
2. 最有价值的设计：Muse Secure VM + Sentinel 双 Agent 架构。每个用户独占一台云端虚拟机，另有一个系统级隔离的守门 Agent，Muse 的任何出网动作都要经它批准。这是目前消费级产品里对「Agent 越权」最认真的一次工程回应。
3. 最有商业含义的动作：支付走 Stripe Link，且是第一个被 Link 购买保护覆盖的 AI Agent——虚拟一次性卡号、丢件/降价/退货有保。Meta 明确说长期变现靠交易抽佣，不是订阅费。
4. 最能说明问题的部分：六周内的七个事故。它们不是孤立的运维失误，而是指向同一个结构性矛盾——给 Agent 的权限越大，可被诱导的路径就越多。
5. 一个关键背景：Muse 的文件体系（SOUL.md、memory、tools）与开源 Agent 框架 OpenClaw 高度同源。理解这一点，才能理解它的安全边界是从哪来的。

二、它到底能替用户做什么

先交代一个容易被忽略的前提：Muse 由 Meta 自研模型 Muse Spark 1.3 驱动（该版本 9 月 2 日发布，官方称其主打真实世界的 agentic 工作）。产品和模型共用「Muse」这一系列名，意味着 Meta 走的是自研模型 + 自研 Agent 的垂直整合路线——这一点与后文要对照的 Manus 恰好相反。

Manus 2.0 拆解：Cascade、云电脑与 Cue——把 Agent 做成「卖电脑的生意」

2026 年 9 月 28 日，Manus 发布 2.0。此时距它 9 月 1 日正式恢复独立运营，只过了 27 天。

官方开篇第一句就把调子定死了：「Manus 2.0 不是一次版本更新。它是围绕一个根本问题构建的新架构、新产品和新能力：下一代 Manus 应该是什么样的？」

这篇文章要回答的是：这个「全家桶」里，哪些是真变化，哪些只是把已有能力重排了一遍；以及为什么它和同月上线的 Meta Muse，走的几乎是相反的两条路。

一、30 秒结论

1. 最硬的一项：自研 Agent 框架 Cascade。官方数据是 token 消耗降 23.2%、任务耗时降 28.2%、运行成本降 32%——注意官方同时声明这是单项测试配置的结果，不是全场景平均，这个自我限定比数字本身更值得注意。
2. 最实用的两项：Cloud Computer（可购买的云电脑，让项目在用户合上笔记本后继续跑）与 Automations（把「定时任务」升级为「事件触发」——一封邮件、一条 Slack 消息、一次 Notion 更新都能启动工作流）。
3. 最有想象力的一项：个人 Agent 产品 Cue。每个 Agent 拥有独立的邮箱、电话号码、钱包和自己的电脑，可以在预算内付款、代接电话并留摘要，还能把多个 Agent 拉进同一个群聊协作。
4. 最好记的一句定位：创始人肖弘说「我一直觉得 Manus 挺像是一个卖电脑的生意」——工作之外也得能看视频、打游戏。这句话解释了 2.0 为什么要把视频、游戏、远程控制全塞进来。
5. 和 Meta Muse 的分野：Muse 追求「尽可能多的人」，用 WhatsApp 触达二十亿用户；Manus 追求「尽可能深的活」，把 Agent 做成一个可购买、可常驻、可协作的工作空间。

二、Cascade：这一版的重点，是「省」

Agent 框架这个层面，用户的感知最弱，但它决定了产品的成本结构和上限。

阿里云电力 AI 调研（一）：总览——全栈版图与产品矩阵

本系列共八篇，逐环节拆解阿里云在电力行业「发、输、变、配、用」的 AI 与 Agent 落地现状。 全部结论标注信源等级：A 官方（阿里云/客户官网、官方技术博客）、B 权威媒体 / 行业白皮书 / 信通院、C 厂商 PR 稿或会议演讲、D 二手转载（仅作线索）。 本系列刻意区分「已投产」与「方案宣传」，并对厂商口径保留独立判断。

一、为什么要做这个调研

「AI + 电力」是 2025—2026 年 to-B 领域声量最高的赛道之一。阿里云在这条赛道上的位置看起来非常牢固：2025 年 9 月云栖大会披露，中国超 70% 的能源央企已接入阿里 AI，阿里云已与所有能源央企建立合作（C，阿里云政企业务稿）。

但这个数字经不起细看。同一主题在 2026 年的现场推进会上，口径已经变成了 80%——这本身就是一个典型的信源漂移。更关键的是，“接入"是一个极低成本的动作：买了云、部署了平台、跑了一个知识库问答，都可以叫"接入”。它对回答下面这些真正重要的问题毫无帮助：

• 哪个环节做到了可验证的生产级落地？哪个环节还停留在方案卡片阶段？
• 那些亮眼的效率数字（“效率提升 8 倍"“准确率 98%"）究竟是谁的成果？AI 在其中贡献了多少边际价值？
• 电力这种强安全约束行业，大模型的幻觉问题是怎么被工程手段压住的？
• 一个省级电网能用的东西，一家地市供电局或者一家民营新能源企业能不能用？

本系列的定位是做一次「可核查」的梳理。 不重复厂商稿的叙事结构，而是把每个案例按"客户主体 → 时间线 → 可查数字 → 信源等级 → 归属判定"逐项过一遍，该说"未找到公开信源"的时候就直说。

二、三条总结论（结论先行）

读完八篇之后，最值得记住的是这三条。它们是全系列的骨架，各环节篇的细节都可以挂在这三条下面。

结论一：版图是「底座强、应用分层不均」

阿里云的电力 AI 产品是三层结构：算力与数据底座层、模型与平台层、智能应用层。这三层的证据强度完全不同：

• 底座层与平台层证据最足。飞天企业版、百炼专属版、通义系列模型都有官方文档级的公开信息，技术细节可验证（详见第七篇）。
• 应用层差异极大。同样是"五环节”，用电侧的公开可查案例数量是输电侧的数倍。输电侧甚至找不到一个阿里云主导的线路本体视觉识别客户案例（详见第三篇）。

所以"阿里云电力 AI 解决方案"这个说法，实际上是一个平台 + 若干不均匀落点，而不是一张均匀铺满五个环节的网。

结论二：客户侧是解耦的多供应商格局

这是本系列最重要的一条方法论。不要把客户的技术栈整体归给某一家厂商。

阿里云电力 AI 调研（二）：发电侧——从功率预测到「擎源」的归因边界

本系列共八篇，逐环节拆解阿里云在电力行业「发、输、变、配、用」的 AI 与 Agent 落地现状。 全部结论标注信源等级：A 官方（阿里云/客户官网、官方技术博客）、B 权威媒体 / 行业白皮书 / 信通院、C 厂商 PR 稿或会议演讲、D 二手转载（仅作线索）。 本系列刻意区分「已投产」与「方案宣传」，并对厂商口径保留独立判断。

引子：问题的性质变了

中国可再生能源发电总装机占比已超 50%（B，央广网，2024-11-18）；2026 年 6 月，南方五省区新能源装机达 2.9 亿千瓦，占区域电源总装机超 40%，部分时段渗透率最高突破 58%（B，北极星电力新闻网）。新能源成为第一大电源后，间歇性不再是补充能源的调度问题，而是电网稳定运行的核心约束（B，新华网，2024-11-06）。

这给发电侧 AI 提了一个很不 AI 的要求：可考核。按「两个细则」，功率预测偏差直接扣减结算电费，华北区域要求中短期准确率不低于 85%、超短期不低于 90%；2022 年 3 月山东预测净收益最高的新能源电厂超 10 万元，偏差较大者面临最高 26.18 万元考核费用（B）。2026 年南方能源监管局征求意见稿又把光伏中期第 4 日门槛从 45% 上调至 60%，考核改为按日考核、月度累加，并删除新能源受限时段豁免（B，北极星电力新闻网，2026-09）。

场景地图

产品线索一句话：企业侧靠「飞天企业版 + 通义/百炼」承接央国企的大模型工程化，调度侧靠达摩院「八观 + eForecaster + MindOpt」做预测与优化——前者卖底座，后者卖精度，客户不是同一批人。

阿里云电力 AI 调研（三）：输电侧——公开案例最稀缺的一环

本系列共八篇，逐环节拆解阿里云在电力行业「发、输、变、配、用」的 AI 与 Agent 落地现状。 全部结论标注信源等级：A 官方（阿里云/客户官网、官方技术博客）、B 权威媒体 / 行业白皮书 / 信通院、C 厂商 PR 稿或会议演讲、D 二手转载（仅作线索）。 本系列刻意区分「已投产」与「方案宣传」，并对厂商口径保留独立判断。

先说结论

输电侧是阿里云公开案例最少的一环。官网与「输」相关的只有三张卡片——无人机巡检、电力视频 AI 防控、电网一张图，全部没有客户名、没有准确率数字（A 级，方案宣传层级），与变电侧、用电侧卡片带客户名形成鲜明对比。

而阿里云在输电侧拿得出手的成果，无一例外落在非视觉方向：调度故障研判、气象大模型、算力与数据底座。在输电线路本体（杆塔、导线、绝缘子）的视觉识别上，阿里云既没有公开的自研行业模型，也没有公开的标杆客户——它拿到的是底座，不是眼睛。

输电侧的结构性变化

规模在膨胀：截至 2025 年 6 月全国已建特高压通道 42 条，西北电网外送能力 8671 万千瓦（B 级，证券时报）；国网 220kV 及以上适航区线路无人机自主巡检覆盖率已达 100%，年巡检杆塔超 1000 万基、年识别图像近 1 亿张（B 级，经济日报）。

容错在收缩：跨区通道加密放大送受端气候差异，覆冰、舞动、山火、外破的处置窗口均以分钟计。一年一亿张图，人工看不完；一次故障十余分钟，电网等不起。

场景一：无人机自主巡检

背景与痛点：人工巡检不可持续——国网山东李敏 2013 年起步时「每天只能巡视 3-5 基杆塔」，人工约 10 基/天（B 级）。

阿里云公开程度：仅有方案描述，无客户案例。官网「偏远山区及复杂线路实时巡检」卡片无客户无数字（A 级），社区有端边云协同的通用方案文章（C 级）；达摩院有可复用视觉能力，但未见官方以电力巡检产品交付（D 级）。技术路径（推测）：端-边-云协同加云侧复判，该范式描述来自国网与百度合作稿（B 级）。

案例与收益：阿里云主体未找到公开信源；收益只有行业整体口径（山东人工 10 基/天对无人机 0.5 小时，B 级）。局限：复杂地形航线规划未过关，国网湖南新宁直到 2026 年才出现自适应巡航试点（B 级）。

场景二：输电通道可视化

背景与痛点：通道内吊车、施工、异物、山火是外破跳闸主因。佛山供电局管辖约 4500 公里线路、16000 余基杆塔，自述监测照片「到达百万级，漏审核越来越多」（A 级）；误报是行业通病，广东电网披露输电在线视频隐患误报率下降 75%（B 级，南网官网）。

阿里云电力 AI 调研（四）：变电侧——归属比能力更值得讨论

本系列共八篇，逐环节拆解阿里云在电力行业「发、输、变、配、用」的 AI 与 Agent 落地现状。 全部结论标注信源等级：A 官方（阿里云/客户官网、官方技术博客）、B 权威媒体 / 行业白皮书 / 信通院、C 厂商 PR 稿或会议演讲、D 二手转载（仅作线索）。 本系列刻意区分「已投产」与「方案宣传」，并对厂商口径保留独立判断。

结构性变化

新能源并网带来潮流双向化与电压波动，特高压换流站把设备复杂度推上新量级，设备总量增长而运维人力不增长——三股压力同时落在变电环节。阿里云 2021 年把变电侧痛点归为三条：任务繁重、设备繁多、智能升级（C，厂商口径）。

但本篇要回答的不是「阿里云能做什么」，而是「那些已有好看数字的变电案例，到底有多少是阿里云做的」。

场景一：变电站智能巡检

痛点。 国网系统内机器人、无人机 AI 的研发制造主体是国网智能科技股份有限公司（B）。机器人有三大故障：自动回充失败、定位丢失、巡检图片偏移，后果是无法完整执行巡检任务——本质即机器人领域的「绑架」难题（B）。

阿里云电力 AI 调研（五）：配电侧——自愈率 80% 这个数字需要先拆开

本系列共八篇，逐环节拆解阿里云在电力行业「发、输、变、配、用」的 AI 与 Agent 落地现状。 全部结论标注信源等级：A 官方（阿里云/客户官网、官方技术博客）、B 权威媒体 / 行业白皮书 / 信通院、C 厂商 PR 稿或会议演讲、D 二手转载（仅作线索）。 本系列刻意区分「已投产」与「方案宣传」，并对厂商口径保留独立判断。

配电侧承载了绝大多数停电事件，却长期是数字化投入最少、感知最薄的环节。新型电力系统的结构性变化几乎全部压在末端——分布式光伏从台区侧并网使配网潮流双向化，储能与充电桩大规模接入让台区线损由"单向损耗"转为"双向波动"，并网逆流与电压越限成为常态性问题（A 级，阿里云口径）。那里恰恰是数据最黑的地方。结论先行：这是阿里云电力版图中公开信息最薄的一环，也是被误传数字最多的一环。

场景一：配网智能调度——落地细节最含糊

截至 2024 年底，山东电网风光装机已突破 1 亿千瓦，是全国首个风光装机过亿的省级电网（B 级）。分布式光伏在台区侧直接并网使母线负荷预测难度剧增；分钟级采集下传统数据库"存不住、算不动、管不细"，并网逆流与电压越限威胁电能质量（A/B 级）。