1. 从“最惨”说起：Manus到底踩了什么坑

Manus这家公司，如果你在过去一年里关注过AI Agent赛道，大概率不会陌生。它一度被看作通用智能体方向最有想象力的选手之一，产品演示里那种“一句话交代任务、AI自己拆解步骤、自己调用工具、自己交付结果”的流畅体验，让不少人惊呼“Agent的iPhone时刻来了”。但热度退去之后，围绕它的讨论逐渐变成了另一种画风：融资节奏不顺、产品落地困难、用户留存惨淡、团队动荡。于是就有了“今年AI圈最惨的一家公司”这个说法。

我先把结论放在前面：Manus的“惨”，不是因为它技术不行，恰恰相反，它在Agent架构上的探索相当超前。它惨在把通用Agent这件事想得太理想化，低估了工程落地的复杂度，也高估了市场对“通用”二字的付费意愿。这个判断，是我在拆解了它的产品形态、技术路线和同类竞品的生存状态之后得出的。

这篇文章适合三类人看：一是正在做AI Agent产品、想知道别人踩过哪些坑的从业者；二是想用Agent能力解决实际业务问题、正在选型的技术负责人；三是对AI创业逻辑感兴趣、想看清这个赛道真实面貌的观察者。我会从Manus的产品设计、技术架构、商业化困境、以及它给整个Agent赛道留下的经验教训几个维度，把这件事讲透。中间会穿插大量实操层面的细节，比如Agent的任务拆解怎么做、工具调用怎么设计、Token成本怎么控制，这些都是我自己在搭Agent时反复验证过的东西。

先明确一个概念，免得后面混淆。AI Agent不是简单的聊天机器人。聊天机器人是你问一句它答一句，被动响应；Agent是你给一个目标，它自己规划路径、调用工具、执行动作、检查结果，必要时还会自我修正。Manus做的就是这个方向，而且它想做的不是垂直场景的Agent，是“什么都能干”的通用Agent。这个定位，既是它的光环，也是它的枷锁。

2. 通用Agent的技术架构到底难在哪

2.1 任务规划：从“听懂”到“拆对”的鸿沟

通用Agent最核心的能力是任务规划。用户说“帮我整理一下这份Word文件，把里面的表格提取出来做成Excel，再按日期排序”，这句话人听起来很简单，但Agent要做的拆解是：识别文件格式、解析Word内容、定位表格结构、提取表格数据、判断日期列、执行排序、生成Excel文件、返回结果。每一步都可能出错。

Manus在这块用的是典型的“规划-执行-反思”循环架构。规划层用大模型把用户意图拆成子任务序列，执行层调用具体工具去完成每个子任务，反思层检查执行结果是否符合预期，不符合就重新规划。这个架构听起来很合理，但实际跑起来问题很多。

第一个问题是规划粒度不好把握。拆得太粗，执行层不知道怎么做；拆得太细，Token消耗爆炸，而且中间任何一步出错都会导致整个链条崩溃。我自己的经验是，规划粒度控制在“每个子任务对应一个明确的工具调用”比较合适。比如“解析Word文件”对应一个文档解析工具，“提取表格”对应一个结构化数据提取工具，“生成Excel”对应一个文件生成工具。Manus早期版本在这块偏粗，导致执行层经常需要二次规划，效率很低。

第二个问题是反思层的判断标准。什么叫“执行结果符合预期”？这个标准很难定义。比如提取表格，提取出来5行数据，但原文可能有10行，Agent怎么知道自己漏了？Manus的解法是让反思层用另一个模型实例去交叉验证，但这又带来了成本和延迟问题。实测下来，这种交叉验证在简单任务上准确率能到90%以上，但在复杂文档上会掉到70%左右，而且Token消耗直接翻倍。

2.2 工具调用：生态缺失是致命伤

Agent的能力边界，本质上取决于它能调用多少工具。Manus在这方面做了很多努力，支持文件操作、网页浏览、代码执行、API调用等。但问题在于，通用Agent需要的工具生态太庞大了，靠自己一个个接根本不现实。

我举个例子。用户让Agent“帮我订一张明天去上海的机票”。这个任务需要：查航班工具、比价工具、支付工具、身份验证工具、订单确认工具。Manus不可能自己把这些全做了，它需要接入携程、飞猪这类平台的API。但接入这些API需要商务谈判、需要分成协议、需要处理各种异常情况。这不是技术问题，是商业问题。

更麻烦的是，很多工具调用需要用户授权。Agent要访问你的邮箱、你的日历、你的文件系统，每个授权都是一个信任门槛。Manus在这块的设计是让用户手动配置，但普通用户根本没耐心做这些配置。我试过让一个非技术背景的朋友用Manus整理他的工作文档，光授权和配置就花了二十分钟，最后他放弃了，说“还不如我自己手动弄”。

这里有个关键认知：通用Agent的“通用”，不是靠一个模型实现的，是靠一个庞大的工具生态和授权体系实现的。Manus在模型能力上不差，但在生态建设上远远不够。这就像你造了一辆性能很好的车，但路上没有加油站，车再好也跑不远。

2.3 上下文管理：长任务的记忆难题

Agent执行长任务时，上下文会越来越长。比如一个“帮我调研一下新能源汽车市场”的任务，Agent要浏览几十个网页、提取信息、做对比分析、生成报告。这个过程产生的上下文可能超过十万Token。怎么管理这些上下文，是个大难题。

Manus用的是“滑动窗口+摘要压缩”的方案。简单说就是只保留最近N轮对话的完整内容，更早的内容压缩成摘要。这个方案的问题是，摘要会丢失细节。比如Agent前面查到“某品牌电池续航500公里”，摘要可能变成“某品牌续航不错”，后面做对比分析时就用不上具体数字了。

我自己的做法是分层记忆：短期记忆保留最近几轮的完整上下文，中期记忆用结构化方式存储关键信息（比如用JSON存提取到的数据），长期记忆存任务目标和阶段性结论。这样既能控制Token消耗，又不会丢失关键细节。Manus后来也往这个方向调整了，但早期版本在这块吃亏不少。

3. 商业化困境：为什么叫好不叫座

3.1 通用Agent的付费意愿悖论

Manus的定价策略一直是个争议点。它早期走的是订阅制，月费不低。但问题是，普通用户对“通用助手”的付费意愿远低于对“专用工具”的付费意愿。你让用户花几十块钱一个月买一个“什么都能干但什么都干不太精”的Agent，大部分人会觉得不值。但如果你告诉他“这个工具能帮你自动整理发票，每月省你五个小时”，他可能愿意付钱。

这就是通用Agent的付费意愿悖论：能力越通用，用户越难感知到具体价值；价值越难感知，付费意愿越低。Manus的演示很惊艳，但用户真正用起来，发现大部分任务还是得自己盯着，Agent经常卡在某个步骤上需要人工干预。这种体验下，用户很难产生“离不开”的感觉。

我对比过几个垂直Agent产品的留存数据。一个专门做合同审查的Agent，付费用户月留存能到70%以上；一个做简历筛选的Agent，月留存也有60%左右。但通用Agent的留存普遍在30%以下。原因很简单：垂直Agent解决的是高频、刚需、痛点明确的问题，通用Agent解决的是“偶尔想起来用一下”的问题。

3.2 Token成本：每多一步都是钱

Agent执行任务时，每一步规划、每一次工具调用、每一次反思，都在消耗Token。一个复杂任务跑下来，Token成本可能几块钱甚至几十块钱。如果用户付的月费是几十块，但一个月跑了上百个复杂任务，那平台就是亏的。

Manus在这块的压力特别大，因为它做的是通用Agent，任务复杂度不可控。用户可能让它整理一个简单文档，也可能让它做一份深度调研报告。后者的Token消耗是前者的几十倍。平台没法预测成本，也就没法定价。

我算过一笔账。一个中等复杂度的Agent任务，平均需要5到8轮模型调用，每轮调用平均消耗2000到5000 Token。按主流模型的价格算，单任务成本在0.1到0.5元之间。如果用户每天跑10个任务，一个月就是30到150元。而Manus的月费远低于这个数。这个账算下来，规模越大亏得越多。

3.3 竞争挤压：大厂入场后的生存空间

Manus面临的另一个困境是竞争。它做通用Agent的时候，这个赛道还没那么挤。但很快，大厂开始入场了。大厂有模型、有算力、有生态、有用户基础，它们做通用Agent，成本结构比创业公司好太多。Manus夹在中间，往上打不过大厂的资源，往下又没有垂直Agent的专注度。

更致命的是，大厂可以把Agent能力作为现有产品的附加功能免费提供。比如一个办公套件里内置Agent，用户不需要额外付费就能用。这种情况下，独立通用Agent产品的生存空间被极大压缩。Manus的“惨”，很大程度上是赛道选择的问题：它选了一个看起来很美、但实际上很难独立生存的定位。

4. 从Manus的教训看Agent开发的实操要点

4.1 任务拆解的具体实现方法

说了这么多Manus的问题，接下来讲点实用的。如果你正在做Agent开发，任务拆解这块我建议用“意图识别+模板匹配+动态规划”三层结构。

第一层意图识别，用一个小模型或者规则引擎快速判断用户意图属于哪个大类。比如“整理文件”“查资料”“发邮件”这些大类。这一层不需要太精确，目的是缩小后续处理范围。

第二层模板匹配，每个大类下预置几个常见的任务模板。比如“整理文件”下面有“提取表格”“格式转换”“内容摘要”等模板。模板里定义了标准的子任务序列和对应的工具调用。这一层能覆盖大部分常见需求，执行效率高。

第三层动态规划，当模板匹配不上时，才启用大模型做自由规划。这一层成本高、速度慢，但能处理长尾需求。我实测下来，三层结构能把平均任务处理成本降低60%以上，因为大部分请求在前两层就解决了。

代码层面，模板可以用JSON定义，比如：

{ "intent": "organize_file", "template": "extract_table", "steps": [ {"action": "parse_document", "tool": "doc_parser"}, {"action": "extract_table", "tool": "table_extractor"}, {"action": "generate_excel", "tool": "excel_writer"} ] }

这种结构化定义的好处是可测试、可复用、可监控。每个步骤的成功率都能单独统计，出问题容易定位。

4.2 工具调用的容错设计

Agent调用工具时，失败是常态。网络超时、API限流、参数错误、权限不足，各种问题都会遇到。Manus早期在这块做得比较粗糙，工具调用失败就直接报错，用户体验很差。

我的做法是每个工具调用都配三重保障：重试机制、降级方案、人工兜底。

重试机制很简单，失败后自动重试2到3次，每次间隔递增。但要注意，不是所有失败都值得重试。参数错误重试多少次都没用，网络超时才值得重试。所以重试前要先判断错误类型。

降级方案是给每个工具准备一个备用实现。比如主力的文档解析工具挂了，就切到备用工具。备用工具可能精度差一点，但至少能跑通流程。这个思路在工程上叫“优雅降级”。

人工兜底是最后一道防线。当自动流程实在跑不通时，把任务状态和上下文保存下来，提示用户“这一步需要您手动确认”。虽然打断了自动化流程，但总比整个任务失败强。

4.3 Token成本控制的五个技巧

Token成本是Agent产品的生命线。我总结了五个实操技巧，都是真金白银换来的经验。

第一个技巧是上下文裁剪。每次调用模型前，检查上下文里有没有无关内容。比如用户的历史对话、已经完成的子任务详情，这些都可以裁掉。我见过一个Agent项目，每次调用都把全部历史对话带上，Token消耗是必要值的五倍以上。

第二个技巧是模型分级。不是所有步骤都需要用最强的模型。意图识别、简单分类这些用轻量模型就够了，只有复杂推理才用大模型。模型分级能把成本降低一半以上。

第三个技巧是结果缓存。很多任务是重复的，比如“把这份文档转成PDF”。第一次执行后把结果缓存起来，同样的请求直接返回缓存，不消耗Token。缓存命中率在办公场景下能到30%以上。

第四个技巧是批量处理。如果用户一次提交多个类似任务，合并成一次模型调用。比如用户要整理十个文档，不要一个个跑，把十个文档的元信息一起发给模型，让它一次性规划。这样能省掉大量重复的规划开销。

第五个技巧是设置预算上限。每个任务设定Token消耗上限，超过就中止并提示用户。这能防止某个异常任务把成本拉爆。我一般把上限设在平均消耗的三倍左右，既能覆盖复杂任务，又能防止失控。

5. 常见问题与排查技巧实录

5.1 Agent执行到一半卡住了怎么办

这是最高频的问题。Agent跑到某个步骤不动了，既不报错也不继续。排查思路是这样的：

先看日志，确认卡在哪一步。如果是工具调用卡住，大概率是网络超时或API无响应。检查工具的超时设置，一般设30秒比较合理，太长会拖慢整体流程，太短会误杀正常请求。

如果是模型调用卡住，可能是上下文太长导致推理变慢，或者模型服务本身有问题。这时候可以尝试缩短上下文，或者切换到备用模型。

如果日志显示Agent在“思考”但一直没输出，可能是陷入了循环。有些Agent会在规划层反复调整方案，但始终找不到可行路径。这时候需要设置最大规划轮数，比如5轮，超过就中止并提示用户。

我踩过的一个坑是：Agent卡住后没有超时机制，任务一直挂着，占着资源不释放。后来加了全局超时，单个任务最长跑10分钟，超过就强制中止并保存状态。这个机制救了好几次。

5.2 工具调用返回结果不符合预期

Agent调用工具拿到了结果，但结果不对。比如让Agent提取表格，它提取出来的数据缺行少列。这种问题排查起来比较麻烦，因为可能是工具本身的问题，也可能是Agent传参的问题。

我的排查顺序是：先手动调用工具，用同样的参数跑一遍，看结果对不对。如果手动调用没问题，那就是Agent传参有问题。检查Agent生成的参数，看有没有格式错误、字段缺失、类型不对。

如果手动调用也有问题，那就是工具本身的bug。这时候要看工具的文档，确认输入格式要求。很多工具对输入格式很敏感，比如日期格式、编码格式、分隔符，差一点就解析失败。

还有一种情况是工具返回了结果，但Agent理解错了。比如工具返回“成功”，但实际数据是空的。这种需要在工具层面做更明确的返回定义，不要用模糊的“成功/失败”，要用结构化的状态码和错误信息。

5.3 常见问题速查表

5.4 几个独家避坑技巧

第一个技巧：给Agent加“自言自语”日志。让Agent在每一步执行前输出它的计划和理由，这些日志不返回给用户，但存在后台。出问题时看这些日志，能快速定位Agent的决策逻辑哪里出了问题。这个技巧帮我省了大量调试时间。

第二个技巧：用真实用户任务做回归测试。不要只用自己设计的测试用例，要把真实用户跑过的任务保存下来，每次发版前跑一遍。真实任务的复杂度和多样性远超想象，我遇到过用户上传加密文档、上传超大文件、上传格式损坏文件等各种边界情况，都是自己设计用例时想不到的。

第三个技巧：监控“人工干预率”。统计有多少任务需要用户手动介入才能完成。这个指标比成功率更能反映产品体验。成功率可以通过放宽标准来美化，但人工干预率骗不了人。我的经验是，人工干预率超过20%，用户就会觉得“这东西不好用”。

第四个技巧：给用户“撤销”和“重做”的能力。Agent执行错了，用户能一键撤销，回到上一步重新来。这个功能看似简单，但极大提升了用户对Agent的信任感。因为用户知道，就算Agent搞砸了，他也能控制局面。

6. 通用Agent的未来：从“什么都能干”到“什么都干得好”

Manus的经历给整个Agent赛道提了个醒：通用Agent的愿景很美好，但落地路径需要重新思考。我个人判断，接下来Agent的发展会呈现两个趋势。

第一个趋势是垂直深耕。与其做一个什么都能干但什么都干不精的通用Agent，不如在特定场景做到极致。比如专门做法律文书处理的Agent、专门做财务报销的Agent、专门做代码审查的Agent。这些场景需求明确、价值可量化、付费意愿强。我认识几个做垂直Agent的团队，规模不大但活得很好，就是因为找准了场景。

第二个趋势是能力嵌入。Agent不再是一个独立产品，而是嵌入到现有工作流里。比如在文档编辑器里嵌入Agent，用户选中一段文字就能让Agent改写、翻译、总结；在邮件客户端里嵌入Agent，收到邮件自动分类、提取待办、生成回复草稿。这种模式下，用户不需要专门打开一个Agent产品，Agent能力无处不在但又无感。

对于正在做Agent的开发者，我的建议是：不要追求通用，先追求有用。找到一个具体场景，把任务成功率做到90%以上，把人工干预率降到10%以下，把单任务成本控制在用户愿意付的范围内。这三件事做到了，再考虑扩展场景。Manus的教训就是步子迈得太大，想一口吃成胖子，结果每个场景都做得不够好。

最后分享一个我在实际项目中的体会：Agent产品的核心竞争力不是模型能力，是工程能力。模型能力大家都能买到，但怎么拆任务、怎么调工具、怎么控成本、怎么做容错，这些工程细节才是拉开差距的地方。Manus在模型能力上不输任何人，但在工程落地上吃了大亏。这个教训，值得每个做Agent的人记在心里。