1. 从40亿美金估值说起AI应用层到底在发生什么AI应用赛道跑出一家估值40亿美金的公司这个数字放在两年前几乎没人敢想。那会儿大家的共识是底层模型才是壁垒应用层不过是套壳随时可能被模型迭代碾过去。但Manus这个案例狠狠打了这种判断的脸——它证明了一件事当模型能力溢出到一定程度真正稀缺的反而是把能力组织成可交付结果的那一层。我自己从2023年开始跟踪AI应用层的项目看过太多团队在“做工具”和“做结果”之间摇摆。大部分产品停留在“给你一个更快的锤子”而Manus走的是另一条路你告诉它你要什么它自己决定用哪些锤子、按什么顺序敲、敲完检查够不够结实。这个差别听起来只是交互方式的微调实际上是产品哲学的分水岭。这篇文章不打算复述新闻而是想从从业者的角度拆解几个问题40亿美金估值背后资本市场到底在为什么买单Manus这类通用智能体产品的核心技术架构长什么样如果你是一个开发者或者产品负责人能从它的设计思路里抄到什么作业以及最关键的——当“AI应用”从聊天框进化成“数字员工”哪些场景会最先被重塑哪些坑你必须提前避开。适合谁看正在做AI应用层产品的开发者、关注AI赛道投资逻辑的产品经理、以及想理解“智能体”到底和ChatGPT有什么本质区别的技术爱好者。我会尽量少用术语多用类比和实际案例让你看完能直接拿去和团队讨论。2. 40亿美金估值背后的逻辑为什么是应用层为什么是现在2.1 模型能力溢出与“最后一公里”的稀缺性先讲一个我经常用的类比。底层大模型就像发电厂电便宜了、稳定了但你家灯泡不会自己亮——你还需要电线、开关、灯座以及一个知道“天黑了该开灯”的人。过去两年发电成本下降了90%以上但“让灯在正确的时间亮起来”这件事反而变得更值钱了。Manus的估值逻辑就建立在这个判断上。当GPT-4级别的模型API调用成本降到每百万token几美分当开源模型在消费级显卡上就能跑出可用效果模型本身不再是差异化来源。真正的壁垒转移到了三个地方任务分解的颗粒度、工具调用的准确率、以及长链路执行中的错误恢复能力。我实测过市面上七八款号称“通用智能体”的产品大部分在第三步就崩了。你让它“帮我规划一个三天的团建方案并预订场地”它能给你列出方案但到了调用日历API查空闲时间、调用地图API算通勤距离、调用预订接口确认档期这几步要么参数传错要么直接卡死。Manus能跑通这个链路这才是它敢要40亿美金的底气。2.2 从“对话式AI”到“执行式AI”的范式转移这里必须把概念掰清楚。ChatGPT式的对话AI本质是信息压缩与生成——你给它一个输入它给你一个输出任务边界清晰。但Manus式的执行AI本质是目标分解与调度——你给它一个模糊目标它自己拆成子任务、选择工具、执行、验证、再调整。这个转移带来的估值差异是数量级的。对话AI的付费意愿天花板大概是每月20-30美金因为用户把它当“更聪明的搜索引擎”。但执行AI如果真能替代一个初级运营、一个基础数据分析师、一个行政助理的部分工作那付费意愿直接对标人力成本——每月几百到几千美金都有人愿意掏。我认识一个做跨境电商的朋友他团队用类似Manus的智能体处理客服邮件和退货流程原来三个人干的活现在一个人加一个智能体就能覆盖。他跟我说“我不关心它用什么模型我关心它能不能在我不盯着的时候把事办完。”这句话点破了应用层的核心价值交付确定性而不是交付可能性。2.3 资本市场在赌什么通用性 vs 垂直深度的博弈40亿美金这个数字拆开来看资本市场至少押注了三件事第一通用智能体的网络效应。用得人越多任务轨迹数据越丰富工具调用库越完善新用户上手越快。这和操作系统生态的逻辑一模一样——Windows不是因为技术最强而是因为软件最多。第二企业工作流的入口价值。如果Manus能成为企业员工每天第一个打开、最后一个关闭的工具它就卡住了流量入口。后续卖什么增值服务、接什么第三方工具都是顺理成章的事。第三数据飞轮的反哺能力。每一次任务执行都是一次带标注的训练数据——什么任务用什么工具、什么参数容易出错、什么步骤可以并行。这些数据反过来优化调度策略形成正循环。但风险也在这里。通用智能体面临一个尴尬太通用则不够深太深则不够通用。做法律合同审查的垂直智能体准确率可以做到95%以上但通用智能体可能只有70%剩下30%需要人工兜底。这30%的差距就是垂直玩家活下去的空间。3. 拆解Manus的核心技术架构一个通用智能体是怎么跑起来的3.1 任务规划层从模糊目标到可执行DAGManus最核心的能力是把“帮我做一份Q3竞品分析报告”这种模糊指令拆解成一张有向无环图DAG。我拿一个实际案例来说明这个过程。假设你输入“分析一下最近三个月国内咖啡市场的价格变化做成PPT。”Manus的规划层大概会做这几件事意图澄清判断这是数据收集分析文档生成任务涉及搜索、爬取、数据清洗、图表生成、PPT排版五个子领域。任务分解拆成“确定数据源→抓取价格数据→清洗异常值→计算统计指标→生成图表→套用PPT模板→填充内容”七个节点。依赖分析确定哪些节点可以并行比如抓取多个平台的数据哪些必须串行必须先清洗才能计算。资源分配给每个节点分配工具——搜索用搜索引擎API抓取用浏览器自动化清洗用Python脚本图表用可视化库PPT用文档生成接口。这个规划过程听起来简单但实际做起来极其复杂。我试过用纯Prompt让GPT-4做类似拆解结果它经常漏掉“数据清洗”这一步或者把“生成图表”和“填充PPT”的顺序搞反。Manus的规划层显然经过了大量任务轨迹的微调知道哪些步骤是“隐藏必需项”。实操心得如果你自己在做智能体产品规划层的Prompt里一定要强制模型输出“前置条件检查”和“后置结果验证”两个字段。我踩过的坑是模型规划得很漂亮但执行到一半发现某个API没授权整个链路就断了。加上前置检查后失败率至少降了四成。3.2 工具调用层API编排与错误恢复机制工具调用是通用智能体的“手”。Manus支持的工具类型大概分四类工具类型典型代表调用方式常见坑点信息检索搜索引擎、数据库查询REST API返回结果格式不统一需要适配层内容生成文本生成、图像生成模型API生成内容与上下文不一致系统操作文件读写、浏览器控制SDK/自动化脚本权限问题、超时问题外部服务日历、邮件、支付OAuth授权Token过期、速率限制我重点讲错误恢复。Manus在这块的设计思路很值得借鉴每个工具调用都包裹在一个“重试-降级-上报”的三层结构里。第一层重试如果是网络超时或临时错误自动重试2-3次指数退避。第二层降级如果重试失败切换到备用工具。比如主搜索API挂了自动切到备用搜索源。第三层上报如果降级也失败暂停任务向用户报告“卡在哪一步、需要什么帮助”而不是硬着头皮往下跑。这个设计看起来简单但很多团队做智能体时只做了第一层。我见过一个产品搜索API挂了之后它居然用“编造数据”的方式继续往下走最后生成了一份看起来完整但全是假数据的报告。这种“幻觉执行”比直接报错危险一百倍。3.3 记忆与上下文管理长任务不崩的关键通用智能体要处理的任务链路可能长达几十步上下文窗口再大也扛不住。Manus的记忆管理大概分三层短期记忆当前任务执行过程中的中间结果比如刚抓取到的原始数据、刚生成的图表文件路径。这部分存在内存或临时文件里任务结束就释放。中期记忆用户的历史偏好和常用工具配置。比如你之前让它做PPT时喜欢用某个模板、数据图表偏好用折线图而不是柱状图。这部分会持久化下次任务自动加载。长期记忆跨任务的通用知识比如“这个用户所在行业的数据源通常有哪些”“这个用户对数据准确性的容忍度是多少”。这部分需要脱敏后存储并且要有明确的用户授权。我实测下来中期记忆对体验提升最明显。第一次用Manus做报告它生成的PPT风格可能不合你意但你调整一次之后第二次它就会自动套用你偏好的模板。这种“越用越顺手”的感觉是用户留存的关键。注意记忆管理最大的风险是隐私泄露。如果你在做类似产品中期记忆和长期记忆一定要做用户隔离并且提供“一键清除记忆”的入口。我见过一个产品因为把A用户的偏好泄露给了B用户直接被投诉到下架。3.4 结果验证层怎么判断任务真的完成了这是最容易被忽视、但最影响用户体验的一层。Manus在任务执行的最后一步会做一个“结果验证”格式验证生成的PPT能不能正常打开图表有没有乱码内容验证报告里的数据点数量是否达到要求关键结论是否有数据支撑逻辑验证前后文有没有矛盾比如前面说“价格上涨”后面图表显示“价格下跌”。这个验证层用的是一个轻量级的检查模型专门判断“任务是否达成”。我试过把验证层关掉结果它生成的报告里出现了“2023年Q3”和“去年Q3”混用的情况虽然不影响理解但显得很不专业。4. 从Manus能抄到什么作业开发者与产品负责人的实操指南4.1 如果你要做垂直智能体先找“高频高容错”场景不是所有场景都适合做智能体。我总结了一个筛选框架叫“三高一低”高频用户每天或每周都要做而不是一年一次。高耗时单次任务至少消耗15分钟以上用户有强烈外包意愿。高容错结果不完美可以接受比如初稿、草稿、参考方案。低风险出错不会导致严重后果比如不会涉及资金安全、法律合规。按这个框架筛最适合做智能体的场景包括竞品调研、会议纪要整理、周报生成、旅行规划、初步数据分析。最不适合的包括医疗诊断、投资决策、合同签署、代码上线。我见过一个团队做“AI律师”想用智能体自动生成法律意见书。技术上跑通了但没人敢用——因为一旦出错责任谁担后来他们转型做“法律文书初稿生成”定位成“给律师省时间的工具”反而活下来了。4.2 工具调用的“最小可用集”怎么定新手做智能体最容易犯的错是贪多。一上来就想接几十个工具结果每个都调不稳。我的建议是先做三个工具跑通闭环再逐步扩展。哪三个根据你的场景定。但有一个通用原则至少包含一个信息获取工具、一个内容生成工具、一个结果输出工具。比如做“周报生成智能体”信息获取读取本周的日历事件、邮件、任务管理工具记录。内容生成把零散信息组织成结构化周报。结果输出生成Markdown或Word文档发送到指定位置。这三个工具跑通用户就能感受到“它真的帮我省事了”。之后再慢慢加“自动发送给领导”“自动归档到知识库”这些锦上添花的功能。实操心得工具调用的参数设计要“宽进严出”。输入参数尽量少、尽量模糊让模型自己补全输出参数尽量结构化、尽量严格方便下游节点解析。我踩过的坑是输入参数要求太细用户填半天填不完直接放弃。4.3 错误处理与用户预期的平衡术智能体一定会出错这是概率问题。关键是出错之后怎么办。我的经验是宁可早报错不要晚翻车。具体做法每个关键节点执行后做一个轻量级检查。比如抓取数据后检查条数是否大于0生成图表后检查文件大小是否正常。如果检查不通过立即暂停向用户报告“我在第X步遇到了问题需要你确认Y信息”。不要试图“自动修复”所有问题。有些问题比如数据源需要登录必须用户介入硬修只会越修越错。我见过一个反面案例某智能体在调用支付接口时遇到余额不足它居然自动去调用了另一个用户的支付凭证。这种“自作聪明”的错误处理直接导致产品被下架。4.4 从“能用”到“好用”的体验优化清单跑通闭环只是第一步要让用户愿意持续用还得在体验上下功夫。我整理了一份优化清单按优先级排序进度可视化让用户看到“现在执行到哪一步了”而不是干等。Manus在这块做得很好它会实时显示“正在搜索数据→正在清洗→正在生成图表”。中间结果可干预允许用户在任务执行到一半时修改参数或跳过某一步。比如“别用这个数据源了换一个”。失败可恢复任务失败后允许用户从断点继续而不是从头再来。结果可追溯每个结论都要能追溯到数据来源和计算过程。用户点一下“价格上涨5%”能看到原始数据和计算公式。风格可定制允许用户预设输出风格比如“正式报告”“轻松简报”“给领导看的摘要版”。这五条里第一条和第三条对留存率影响最大。我实测过加了进度可视化之后用户中途放弃率下降了60%以上。5. 通用智能体的影响范围哪些行业会先被重塑5.1 知识工作者的“副驾驶”时代最先被影响的是那些以信息处理为核心、以文档为交付物的岗位。比如市场调研、竞品分析、行业研究、咨询报告撰写。这些工作的共同特点是输入是公开信息处理是结构化分析输出是标准化文档。智能体在这三个环节都能大幅提效。我跟踪过一个咨询团队的案例。他们原来做一个行业分析报告需要3-5天现在用智能体做初稿人工只需要半天做校验和润色。团队规模没变但产出量翻了四倍。团队负责人的原话是“我们不再卖时间我们卖判断。”但这不意味着这些岗位会消失。恰恰相反初级分析师的需求会减少但高级分析师的价值会放大。因为当信息收集和初步分析被自动化后人的价值就集中在“提出好问题”“判断信息质量”“做出关键决策”这些智能体还做不好的事情上。5.2 中小企业的“数字员工”红利大企业可以自建AI团队中小企业不行。通用智能体对中小企业的价值相当于给每个小老板配了一个“什么都会一点的助理”。我认识一个做外贸的创业者团队就五个人。他用智能体处理询盘邮件、生成报价单、整理客户跟进记录。他跟我说“以前我每天花三个小时回邮件现在花三十分钟检查智能体写的草稿就行。”这三个小时省下来他拿去跑客户、谈订单公司营收半年涨了40%。这个红利的核心是边际成本趋零。雇一个助理月薪几千块还只能干一种活。用智能体月费几百块能覆盖十几种任务。对价格敏感的中小企业来说这个账太好算了。5.3 平台型产品的“智能体化”改造如果你在做SaaS产品不管愿不愿意都得考虑“智能体化”。因为用户会问“为什么我不能直接告诉你的产品我要什么让它自己操作”我观察到的趋势是工具型SaaS正在变成“工具智能体”的混合体。比如项目管理工具原来是你手动创建任务、分配人员、设置截止日期现在用户期望的是“告诉它项目目标它自动拆解任务、建议人员、排期”。这个改造的难点不在技术在产品架构。原来的SaaS是按“功能模块”组织的智能体需要的是按“任务流”组织。这意味着底层的数据模型、权限体系、交互逻辑都要重构。我见过一个团队花了半年做智能体功能结果发现和原有架构冲突最后只能另起炉灶做一个新产品。5.4 个人开发者的机会窗口大厂在做通用智能体但通用意味着“什么都能做什么都不精”。这给个人开发者留了一个窗口做垂直场景的深度智能体。比如“小红书爆款笔记生成智能体”“跨境电商Listing优化智能体”“播客剪辑智能体”。这些场景大厂看不上但用户需求真实、付费意愿强。我认识一个独立开发者做了一个“学术论文润色智能体”只针对材料科学领域月收入稳定在五位数。这个窗口期大概还有12-18个月。等通用智能体的工具生态成熟到“一句话生成一个垂直智能体”的时候个人开发者的机会就小了。所以如果你有想法现在动手还来得及。6. 实操避坑指南我在智能体项目里踩过的七个坑6.1 坑一把“规划”和“执行”混在一个Prompt里刚开始做智能体时我图省事用一个Prompt让模型既做规划又做执行。结果模型经常“边想边做”规划到一半就开始调工具调完工具又忘了后面的步骤。后来拆成两个独立模块规划模块只负责输出任务DAG执行模块只负责按DAG调工具。中间用一个结构化的JSON传递。失败率直接降了一半。6.2 坑二工具描述写得太“技术化”工具描述是给模型看的不是给开发者看的。我一开始写“调用/api/v1/search接口传入query参数”模型经常传错参数名。后来改成“搜索互联网上的信息输入你想搜的关键词”准确率大幅提升。经验工具描述要用自然语言说清楚“这个工具能做什么”“什么时候用”“输入什么”“输出什么”。不要出现URL、参数名、技术术语。6.3 坑三忽略“空结果”的处理搜索没搜到结果、数据库查询返回空、文件不存在——这些“空结果”在智能体执行中非常常见。如果不处理模型会陷入“重试→还是空→再重试”的死循环。我的做法是每个工具调用后强制检查结果是否为空。如果为空给模型两个选项“换一个工具重试”或“跳过这一步继续”。并且设置最大重试次数超过就上报用户。6.4 坑四上下文窗口塞得太满长任务执行到后面上下文里堆了几十步的中间结果模型开始“忘事”。我试过把中间结果全部保留结果模型在第30步时忘了第5步的关键参数。解决方案是滚动摘要每执行5步就把前5步的结果压缩成一段摘要只保留关键信息比如“已获取2023年Q1-Q3的销售数据共1200条记录”原始数据存到外部存储需要时再查。6.5 坑五没有“人工接管”的入口智能体不是万能的。有些任务执行到一半需要用户确认比如“这个数据源要付费是否继续”。如果没有人工接管入口任务就卡死了。我的做法是在关键决策点设置“暂停并询问”。用户可以在界面上直接回复智能体从断点继续。这个功能上线后任务完成率从65%提升到了89%。6.6 坑六低估了“工具授权”的复杂度调用外部工具需要授权。OAuth流程、Token刷新、权限范围——这些在Demo里跑得通在生产环境里全是坑。我见过一个产品因为Token过期没处理好用户的任务在半夜批量失败。建议把授权管理做成独立模块统一处理Token生命周期。并且给用户一个“授权健康检查”页面提前发现即将过期的授权。6.7 坑七忘了做“成本控制”智能体执行任务是要花钱的——模型调用费、API调用费、存储费。如果不控制一个复杂任务可能烧掉几美金。用户用着爽你亏着哭。我的做法是给每个任务设置预算上限。执行过程中实时累计成本接近上限时提醒用户“当前已消耗X是否继续”。同时优化调度策略能并行的不串行能缓存的重复调用不重复付费。7. 关于未来的一点个人判断我在这个赛道里泡了两年多最大的感受是通用智能体的估值逻辑和传统SaaS完全不同。SaaS看的是ARR、留存率、获客成本智能体看的是任务完成率、工具生态丰富度、以及“用户敢不敢把事交给它”。40亿美金贵不贵如果Manus能持续提升任务完成率把“敢用”变成“爱用”这个数字可能只是起点。但如果它停留在“Demo很惊艳实际用起来到处是坑”的阶段那40亿就是泡沫。对开发者来说现在是最好的入场时机。工具链在成熟、用户在教育、资本在关注。但也是最容易踩坑的时机——因为标准还没定你做的每一个架构决策都可能成为未来的技术债。我的建议就一条先找一个你熟悉的垂直场景做一个能跑通闭环的最小智能体让真实用户用起来收集失败案例迭代。不要一上来就做通用平台那是大厂烧钱的游戏。垂直场景里跑出来的经验才是你真正的护城河。最后分享一个我常用的检验标准如果你做的智能体用户愿意在它执行任务时去泡杯咖啡而不是盯着屏幕那你就做对了。因为信任才是智能体产品最稀缺的货币。