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