调研纪要

**专家观点**

当前 Agent 行业对算力和存储的需求如何？竞争格局和产品壁垒有哪些显著特点？如果未来市场中出现大量 Agent 产品，可能会面临怎样的壁垒？

Agent行业对算力和存储的需求主要体现在其任务执行能力上。由于Agent需要处理复杂任务，包括推理、状态管理、工具调用等，其对高性能计算资源以及稳定可靠的存储系统有较高要求。此外，竞争格局方面，目前市场上已有多款产品，如Manus、Gemini以及OpenAI的operator等，这些产品在技术实现和应用场景上各有侧重。产品壁垒主要体现在技术架构设计、任务执行稳定性以及成本控制能力上。如果未来市场中出现大量Agent产品，互相之间可能形成的壁垒包括：任务分解与执行效率差异、安全风险管理能力、扩展性设计，以及在长时序任务中的失败修复机制。

Manus与其他主流Agent产品（如Gemini和OpenAI operator）相比，在技术实现和应用场景上有哪些核心差异？

Manus与其他主流Agent产品在技术实现和应用场景上的核心差异主要体现在设计初衷及功能定位上。OpenAI operator旨在展示模型能力极限，通过端到端推理完成实时环境中的操作，其特点是线性及时但缺乏状态管理，一旦失败需重新尝试。而Gemini则侧重深度搜索功能，并计划推出Project Marina以扩展操作功能。相比之下，Manus从创立之初就以交付可复用且可扩展的Agent为目标，其设计了一个有状态分布式执行系统，包括任务分解、子任务管理、节点状态机等模块。这种架构使得Manus能够稳定完成评测，并有效控制成本，同时支持多次复用与扩展，从而形成了显著差异化优势。

OpenAI或Google是否能够开发出类似Manus的产品？Manus是否存在数据壁垒或用户优势等独特性？

OpenAI和Google具备强大的模型能力、完善的基础设施、卓越的分发能力以及充足的资本支持，但他们在开发类似Manus的产品时面临诸多挑战。首先，Manus专注于深度工程领域，而非单纯追求模型性能提升。Agent系统需要长时间投入重工程建设，包括状态机设计、故障恢复机制、工具调用管理以及任务回放与恢复功能，这些都是大厂通常不愿意深入参与的领域。此外，Agent系统涉及高风险责任，例如任务执行错误可能导致事故，而企业用户通常将责任归于平台而非模型本身，这进一步降低了大厂对该领域深度投入的意愿。

此外，大厂更倾向于开发基于模型驱动的Agent，其行为不可控且难以满足企业定制化需求。而Manus则通过构建复杂且低可见度的系统级架构，解决了半结构化和非结构化流程中的问题，并实现了跨工具和跨任务场景下的高效协作。这种能力使其能够应对真实任务中的复杂性，而大厂现有生态体系（如谷歌安卓或Chrome浏览器）则难以实现跨系统服务和复购。

开发Manus这样的产品需要哪些关键能力？其独特优势体现在哪些方面？

开发Manus这样的产品需要具备工程惯性、数据惯性以及失败经验积累等关键能力。首先，工程惯性体现在状态机设计、任务回放与恢复机制、安全沙盒环境以及评估管道等方面。这些技术构成了一个分布式系统，使得团队能够持续优化并推进Agent的发展方向。新团队或大厂若仅关注展示型Demo而忽略这些底层架构，很容易偏离正确路径。

其次，数据惯性是核心壁垒之一。Agent的数据不仅包括提示词回复，还涵盖用户动作记录、工具调用结果及失败原因等真实使用轨迹。例如，Manus每月积累数百万条真实用户使用轨迹，通过分析这些数据，可以了解不同模型在同一任务上的表现，包括成本与质量差异。这种数据积累远超模型权重的重要性，为后续优化提供了不可替代的信息。

最后是失败经验积累。Agent开发过程中失败率较高，包括隐形失败、延迟失败及成本爆炸等多种形式。如果团队能够从早期规模化失败中总结经验，就能掌握如何避免常见问题。这些经验无法通过预训练或Demo学习，只能依赖真实用户反馈不断迭代。

Manus在技术架构上有哪些独特设计，使其区别于其他同类产品？

Manus采用了一套状态化执行系统，以确保任务拆解、中断处理及工具调用能够顺利完成。如果没有这一层架构支持，Agent只能停留在展示型Demo阶段，而无法实现实际应用。此外，其可回放与可解释失败机制允许每次任务都能被回放并定位到具体失败节点，从而复现模型决策过程。这种调试能力避免了对模型智能提升的不确定依赖。

另外，Manus内部假设模型本身不可信，因此设计了一套防护围栏机制，为工具设置边界条件并验证参数，同时计算预算与评估风险。这些措施确保操作权限最低限度地开放给模型，从而降低因幻觉（Hallucination）或错误调用工具导致的问题发生概率。

在成本控制方面，Manus采取了哪些策略以优化资源利用？

Manus通过上下文管理、多次重试机制及分阶段推理来优化资源利用。例如，不同场景下选择适配不同类型的模型，并根据需求进行缓存处理。此外，它还针对工具调用延迟时间成本进行精细化管理，以减少资源浪费。同时，通过单位智能成本下降策略，每次任务产出的轨迹均可复用，每次失败教训也会被系统吸收，新加入的模型可以继承旧有经验，从而进一步降低整体运营成本。

Manus有哪些具体护城河，使其在竞争中占据优势地位？

Manus拥有多项技术护城河，包括故障修复策略、任务状态迁移方案、多路径尝试方法以及丰富的工具调用使用经验。这些特点使得它能够应对复杂且动态变化的实际应用场景。此外，其分布式架构设计确保行为可控，同时压缩运营成本，与大厂以能力优先为导向的发展路线形成鲜明对比。随着用户数量增加，每次任务产出的轨迹均可复用，每次失败教训也会被吸收，新加入的新型智能可以继承旧有经验，从而进一步巩固其市场竞争力。

底层模型是否重要？是否可以通过选择不同的底层模型来降低成本？底层模型是否构成技术壁垒？

底层模型的重要性在于其决定了系统的上限，但并非决定Agent能否存活的核心因素。虽然底层模型无法完全省略，但可以通过优化使用策略显著减少使用频率。具体而言，Manus采用的是一套分层选择模型的策略，而非单一模型的选择。例如，某些任务失败并非因为底层模型不够智能，而是由于选错了模型或使用过度，或者将其应用于不适合的场景。因此，底层模型在系统中更像是耗材而非角色，其作用需根据任务需求进行动态调整。

如何选择和使用不同类型的大语言模型以优化成本和性能？Manus内部对认知任务如何分类以匹配不同类型的大语言模型？

Manus内部将认知任务划分为五类，并根据任务需求匹配不同类型的大语言模型，以实现性能与成本之间的平衡。第一类是任务理解与粗略规划，这类高频同步任务通常采用中小型语言模型，因为它们运行速度快且成本低，即使出错也可快速修改。第二类是执行步骤或填充参数，这些需要结构化输出和强约束的场景会使用稍强一些但仍然经济实惠的反推型语言模型。第三类是处理失败情况，此时必须启用强大的大语言模型，以便准确区分问题来源（如环境问题、工程问题或推理问题），从而采取适当措施（如重试、修复或放弃）。第四类涉及关键链路，例如验证、决策或路径选择等，这些环节直接影响用户目标达成及安全边界，因此也需要强大的大语言模型参与。最后，第五类为记忆总结与轨迹压缩，此时则采用中等规模的大语言模型，以实现综合平衡。

Manus中的多Agent架构与基于大语言模型内部多角色提示词驱动的Multi-Agent架构有何区别？

Manus中的多Agent架构与基于大语言模型内部多角色提示词驱动的Multi-Agent架构在概念上完全不同。在大语言模型内部，多Agent实际上是通过提示词模拟多个角色，如计划者、执行者和批评者。这种方式仅存在于一次推理过程中，没有持久状态，也无法真实执行，仅仅是一种思维分叉。而Manus中的多Agent则属于系统性的执行体，每个Agent具有独立职责、私有状态、工具权限以及预算边界等特性。这些Agent能够被调入、中断、恢复或替换，并且具备真实执行权限。例如，Manus常见的Planner Agent负责拆解任务，Executor Agent负责具体操作，Criticizer Agent和Verify Agent负责判断成败，而Repair Agent则用于修复失败。这种少而重、多权隔离且高度可控的设计使得每个Agent都成为一个风险源，同时也是一个真实执行入口，与单纯依赖提示词模拟角色的方法形成显著差异。

在Manus系统中Prompt是否构成技术壁垒？Prompt在系统中的作用是什么？

在Manus系统中，Prompt本身并不构成技术壁垒，但Prompt在整个系统中的位置及用法才是真正意义上的壁垒。在早期AI产品中，Prompt通常作为核心资产，其泄露可能导致产品被复制。然而，在Manus体系内，Prompt仅作为控制接口，用于决定如何与底层大语言模型沟通，并不能直接影响整个智能系统行为稳定性的核心要素。这些核心要素包括状态机设计、执行约束管理、工具权限配置、验证机制以及失败修复策略等。因此，即使复制了Manus中的Prompt，也无法复制其整体功能逻辑及行为稳定性。

Clawdbot和Manus在底层算法及能力方面是否存在差异？两者的工程壁垒分别体现在哪些方面？

Clawdbot是一种以模型为中心的Agent，其核心优势在于基座模型的强大能力，包括更高的推理能力、更长的上下文处理能力以及模型层面的稳定性。这使得Clawdbot能够提供较好的交互体验和较高的单词会话能力。然而，Clawdbot的Agent行为依赖于实时环境中的模型表现，失败后通常需要重新尝试，这导致任务成本随任务长度呈指数级增加，并且难以实现系统级兜底。其设计路径更多是展示基座模型能力。

相比之下，Manus是一种系统中心的Agent，其设计理念是将智能放置在模型之外，以应对模型可能犯错或出现问题的情况。Manus通过分类、规划执行环境工具、失败后的修复、恢复或回滚等机制形成可复用系统，从而建立了工程壁垒。这种设计使得Manus能够稳定完成任务，即使在复杂场景中也不容易出现重大错误。

Clawdbot和Manus在推理与存储需求方面有何差异？尤其是在计算资源消耗（如Tokens使用）和存储需求（如HBM、DRAM及SSD）的具体表现上？

在计算资源消耗方面，Clawdbot作为以模型为中心的Agent，其成本主要来源于上下文读取、自我反思、工具调用及失败后的重试等环节。这些操作形成了乘法效应，使得其Token消耗呈现近似指数级增长。在普通聊天场景中，仅需输入Token加输出Token即可完成任务，成本为线性。然而，在Agent模式下，Clawdbot需要读取全部历史上下文并进行多步推理，每一步都可能涉及工具调用及结果回传至上下文，再进行自我反思与修正。如果失败，还需重试，这进一步增加了Token消耗。具体而言，第K步所需Token量为上下文长度乘以步骤数K，而多步执行时总Token量则接近O(n²)。若加上重试次数与分支数，则复杂度进一步接近指数级。

推理成本方面，由于Transformer架构需要对整个上下文进行attention操作，其复杂度为O(sequence length²)，这导致GPU时间暴涨。此外，由于缺乏显性的状态外置机制以及未广泛采用激进型上下文剪枝技术，每一步都需完整地forward全量上下文，使得GPU部署次数乘以上下文平方成为主要开销来源。

存储需求方面，Clawdbot隐性的存储需求包括调试、安全审计、用户体验优化以及问题浮现等目的所需的数据保存。例如，全量提示词、全量上下文、全量模型输出以及工具返回结果（如HTML、DOM JSON或图像）均需长期保存。估算显示，每个Agent任务可能产生10~100MB的数据存储需求。如果每天处理1万个任务，则每日存储增量约为100GB至1TB，每月则达到3~30TB。此外，由于这些数据无法有效结构化复用，对于长期运行来说是一项显著负担。

相比之下，Manus通过系统中心设计减少了对实时环境中大量数据保存与重复计算的依赖，从而降低了推理与存储成本。这种设计更注重稳定性和可复用性，而非单纯依赖基座模型性能。

在以模型为中心的Agent架构中，数据存储的具体方式是什么？为什么需要保存每一步的返回结果？这种存储方式对数据复用和压缩能力有何影响？

在以模型为中心的Agent架构中，由于缺乏系统级状态，其状态完全依赖上下文，而上下文由token构成，token是唯一可解释的事实记录。因此无法直接保存最终结果，而必须保存每一步操作，包括prompt和output。例如，第一步保存prompt和output；第二步则包含第二步的prompt、output以及第一步的数据；第三步又包含前两步的数据。这种推理及日志架构导致无法有效地进行数据复用和压缩。

数据在任务完成后是否可以删除？热数据与冷数据在这种架构下如何转换？任务结束后保留冷数据有哪些必要性？

数据在任务完成后会从热数据转化为冷数据，但不能立即删除。虽然技术上可以实现删除，但产品安全合规要求迫使其保留。这些冷数据需用于安全审计，例如提示词注入、越权操作、恶意使用或模型误用等。此外，还需满足法务需求，例如验证是否存在危险操作或授权问题，以及系统拦截记录。根据具体情况，这些冷数据通常需保留1个月、3个月或6个月。此外，产品工程调试、用户投诉处理、成功率统计及模型分析也需要这些冷数据支持，因此删除会导致相关功能失效。

ClawdBot与Manus相比，在正常聊天场景下的性能如何？

在正常聊天场景下，ClawdBot性能更优，因为其设计目标是节省Token、算力及存储资源。而Manus并非针对聊天场景优化，其优势体现在执行复杂任务时，通过状态记忆管理实现高效资源利用。

使用Clawdbot或Manus这样的Agent是否会导致服务器端CPU需求暴增？

服务器端CPU需求主要受Agent类型影响。对于ClaudeBot，其运行涉及代码编写、项目读取以及沙盒环境等高频计算任务，因此对服务器端CPU负载要求较高。而Manus作为系统中心型Agent，其设计目标是优化资源利用，通过可预测的调度机制避免指数级重试，从而显著降低服务器端CPU消耗。

Manus有哪些竞争对手？这些竞争对手在功能定位上有何差异？

Manus面临来自多种类型竞争对手的挑战，包括以模型展示为主的大公司、自动化流程升级版（如UIPath）、以及专注于长任务执行的平台（如Adapt）。其中，Adapt定位为action transformer，可操作真实软件完成任务；RepLit专注于软件工程领域，实现端到端开发；此外，还有微软基于企业权限提升系统能力，以及谷歌通过Chrome和Android生态深度绑定提供支持。这些竞争对手各自侧重不同领域，与Manus在功能定位上存在显著差异。

OpenAI、Gemini和Anthropic三家大模型公司目前在综合能力上的排名如何？它们各自具备哪些特点？

OpenAI综合能力最强，包括多模态支持、生态整合成熟度以及工具调用能力，但长推理稳定性表现波动较大。Anthropic以稳定性见长，上下文行为一致且幻觉率低，是工程师偏好的选择，但多模态支持较弱且更新速度较慢。Gemini具备强大的上下文理解、多模态原生支持，并与搜索引擎及Workspace深度绑定，但推理风格不够稳定且prompt波动较大。在综合排名方面，目前OpenAI处于领先地位，但三者均具有独特优势。

市场是否可能因工程难度过高而倾向选择基于模型底座的大规模Agent解决方案，而非像Manus这样需要大量工程投入的小规模解决方案？

基于模型底座的大规模Agent解决方案可能赢得部分用户选择，因为其适合特定阶段的人群与场景。然而，从长期来看，这种模式成本不可控且体验不佳，不符合市场整体趋势。普通用户更关注产品易用性与稳定性，而不是后台资源消耗。因此，大规模解决方案虽能吸引部分用户，但难以成为主流方向。