调研时间：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 长对话与资源消耗尚待验收。
因此，下一步不必先做一个“自动永久记忆”系统。可以围绕真实对话，区分三类信息：
- 近期对话：用于连续回答，有明确容量上限和截断提示。
- 知识来源：用户明确让助理查询或记录的知识，来源放在已有 QPC 多维表格；长期内容不是聊天摘要。
- 外部状态：日程、知识记录等以 Lark 实际结果为准，保留对应记录标识，而不是以模型自述为准。
例如用户问“继续刚才讨论的方案”，如果关键事实已被淘汰且没有可引用的知识记录，助理应该说缺少依据，请用户补充；只有明确请求查询时，才从获准的 QPC 表中检索相关记录。当前 QPC 只读检索已在开发分支实现，但真实权限、字段和端到端收发仍待验证；写入、修改和删除尚未实现。
从演示走向可靠闭环
Manus 对自动化的介绍强调，可以定义触发条件、数据来源、测试运行、确认方式和失败后的查看与暂停。来源：Automations。这启发我们：功能是否可靠，不在于是否能展示一次成功，而在于它能否处理重复输入和不确定结果。
以“帮我记一条 QPC 知识”为例，一条未来可实现的最小流程应该是：
- 用户明确要求记录，助理检查已有表结构与允许的字段；不改表头，不把所有聊天自动存入知识库。
- 程序校验内容与权限，发送一次写入请求；只有获得可验证的记录标识后，才报告保存成功。
- 接口超时后，不能简单重试或声称失败；先查证是否已经创建，无法查证时明确报告结果未知。
- 重复消息、进程重启和发送结果不明都要有独立测试，保证恢复流程不会绕过授权。
这是设计提议，并非本项目已有能力。第一步仍应先完成 QPC 只读检索的真实验收；之后再根据实际需要选择写入或日历查询。
并行与成本：有用，但不必提前拥有
Manus 的 Wide Research 面向需要对大量独立对象逐项调研的任务；其公开介绍描述主任务拆解、独立子任务并行执行以及结果汇总。来源。文中的质量提升是厂商对架构的论述，不应当直接当成对所有问题有效的独立基准结论。
对于个人助理的大多数日常消息，多 agent、云端虚拟机和浏览器并不自然意味着更好。它们增加运行成本、排错路径和权限面。只有出现明确的大规模独立调研任务，并能测量质量、耗时和成本时，才值得做有上限的并行实验。
Manus 的帮助中心将积分消耗与模型 token、虚拟机和部分第三方接口关联，并说明任务复杂度和持续时间影响消耗。来源。我们的模型预算则是数据库累计的调用次数，默认 20 次；它不是账户余额，也不是费用上限。长上下文会增加输入 token，未来引入工具循环时还需要限制每项任务的调用次数、总时间和输出规模。
我们接下来应该做什么
- 完成当前 Lark 长对话和 QPC 只读检索的真实使用验收，记录结果、用量和异常，而不是把合成测试当成真实证明。
- 选择一个明确的后续动作：例如一条 QPC 知识写入，或者只读查询当天日历。先做好权限、可核验结果和失败处理。
- 当实际任务证明“查询后还要根据结果决定下一步”时，再引入小步、有上限的模型工具循环；程序负责校验和执行，模型不能自行扩权。
- 保持手动启停及用户触发边界。定时摘要只是未来场景，示例本身不代表已经授权或建立计划。
Manus 给我们的核心启示是：一个实用 agent 要能够把目标、动作、观察和结果连起来，并让人知道哪些事已经完成、哪些事仍不确定。对一个个人助理而言，这条链路可以很小，但必须可信。