一个 AI 产品被大量用户吐槽“不好用”甚至被当成“预期管理翻车”的典型结果收入反而涨了。这个反常识的现象最近被放在 Manus 身上讨论。从公开信息看Manus 早期以邀请码内测方式引爆热度随后体验落差引发大量负面反馈与此同时“收入翻了五倍”的说法又在另一批报道中出现。需要先说明本文不考证具体财务数字是否正确。“被退货”这个词本身也是社交媒体上的比喻指的不是电商订单退款而是大量用户觉得自己被过高的期待“坑了”。真正值得研究的是一个问题一个口碑波动巨大的 AI Agent 产品为什么商业表现可以和舆论表现完全不同频我的判断是你拿什么标准去评价它决定了你会看到哪个“真实”。Chatbot 心智下的用户看重即时对话、聪明应答Agent 产品的付费者看重稳定交付一件具体任务。前者在意“像不像人”后者在意“事情有没有完成”。这篇文章会用四部分展开先说现象再拆原理然后讲开发者如何落地自己的 Agent 工程最后讨论工程化和商业化之间的坑。顺便提醒一下这类产品的开发方式与普通大模型应用并不一样。如果你正准备做一个 Agent 方向的项目这篇文章可以帮你避开几个比较隐蔽的坑。1. 先还原现场“被退货”和“收入翻了五倍”到底指什么“被退货”这个说法最早出现在社交平台对 Manus 的情绪化吐槽里。Manus 走红时邀请码一度成为稀缺资源很多人把“拿到邀请码”当作参与 AI 前沿的象征。真实上手之后用户很快发现它并不是一个“你问它答”的聊天机器人而是一个“浏览器自动化任务执行器”。用户看到的是打开网页、滚动页面、点击按钮、生成文件等过程耗时从几分钟到几十分钟不等一旦中途遇到验证码、页面改版或网络波动任务就可能失败。这种现实与宣传之间的落差会带来非常直接的口碑反噬。很多人觉得自己被“人造神迹”骗了于是开始刷差评、录吐槽视频甚至有人提出“希望退款”。所以“被退货”并不是真的发生了大批订单退款而是用户期待值崩盘后的舆论表达。它反映的是大众市场对一个 AI 产品抱有 Chatbot 式幻想但 Agent 产品交付的是另一个东西。与此同时另一个方向的信息也在流传一些第三方平台和媒体报道称Manus 的收入出现明显增长甚至有“翻了五倍”的说法。收入增长和口碑崩盘同时存在看起来矛盾其实并不难解释。差评主要来自体验型用户他们买的是一次“魔法体验”而付费增长更可能来自目标明确的用户他们买的是结果比如快速整理一批简历、生成一份行业调研报告、把几十个网页里的信息提取成表格。这两类用户对产品的评价标准完全不同。所以我们不需要纠结“到底翻了几倍”这个数字。真正值得关注的信号是一个口碑并不完美的 Agent 产品已经验证了一部分用户愿意为“任务交付”付费。这是 AI Agent 从技术演示走向商业化的一个真实样本。2. 为什么口碑与营收能背离Chatbot 心智与 Agent 交付的冲突要理解这种背离先要理解用户评价体系的分化。传统 Chatbot 的评价体系是即时反馈型。用户问“巴黎有什么好玩的”它两秒内给出结构清晰的回答用户觉得“好聪明”。这种评价维度包括响应速度、语气自然度、知识广度、会话流畅度。Chatbot 的核心交互模型是一来一回的对话用户处在连续反馈中每一条回复都能立刻验证质量。Agent 产品的评价体系完全不同。它的核心是“任务完成度”用户丢过来一个模糊目标比如“帮我整理这 20 份简历按技术栈分类并输出一份表格”Agent 需要自行拆解、执行、验证、输出。整个过程可能持续很久中间还可能出现浏览器卡住、文件读不了、字段提取错误等问题。用户无法在每一秒都获得“聪明感”只能在最后验收交付物。这个等待过程越长差评概率就越高。问题是愿意付费的用户往往不在乎这个过程是否“有魔法感”。他们的诉求非常具体能稳定完成某个重复性任务节省人力时间。如果能做到哪怕过程看起来平平无奇也值得付费。对企业采购来说标准更简单同类任务过去要花两小时现在二十分钟能完成且错误在可接受范围内这就是 ROI 为正。这就像点外卖和找长期供应商的区别。点外卖时你根据餐厅评分和图片决定要不要下单评价体系充满情绪找供应商时你关注交付时间、质量稳定性、售后响应和合同条款评价体系非常理性。一个产品可以同时被两种人用不同的眼光打量得到完全相反的结论。所以口碑与营收背离很正常。大众口碑是一种传播产品营收是一种交付产品。只要交付价值在特定人群中成立营收就能增长哪怕大众舆论一片吐槽。3. Agent 不只是“更大的大模型”核心概念与架构判断很多开发者第一次接触 Agent 时会觉得它无非是“套壳大模型”。这个判断只对了一半。Agent 确实是基于大模型构建的但它的架构核心不是模型本身而是“循环”理解任务、做出计划、调用工具、观察结果、修正计划、继续执行。这个循环使得 Agent 有能力处理多步骤任务而普通 LLM 应用只是单次输入输出。可以做一个比喻如果大模型是一个“聪明但不会动手的专家”Agent 就是给这个专家配了双手、眼睛和一套工作流程。专家负责思考工具负责执行流程负责保证专家不会跑偏。关键的技术点在于模型需要知道有哪些工具、每个工具接受什么参数、工具返回了什么结果以及如何根据结果决定下一步动作。一个实用的 Agent 系统通常包含以下几个核心模块任务理解模块把用户的模糊描述转成明确的目标。任务规划模块把目标拆成有序步骤。工具调用模块定义工具清单执行统一调用。状态管理模块记录已完成的步骤、中间结果、上下文。校验与纠错模块判断步骤是否真正完成失败时自动重试或调整方案。很多人在这个阶段容易误解“记忆”的作用。Agent 的记忆不只是聊天记录更重要的是“执行状态”比如简历已经解析了 30 份还剩 20 份当前工作目录是哪个文件夹上一步生成的中间文件叫什么。没有状态管理Agent 就无法在长任务中保持一致。Manus 这类产品选择云端沙箱方案本质原因也是状态管理。在云端沙箱里Agent 拥有一个相对稳定的文件系统、浏览器环境和执行环境可以按步骤操作并把中间产物保存下来。用户随时切走或断网任务依然可以在云端继续执行。这种架构不仅让 Agent 能处理长任务也为商业化的“异步服务”创造了条件。4. 从用户输入到任务交付Agent 工作链路拆解理解 Agent 产品要看它的完整工作链路。以“整理简历并输出汇总表”为例这条链路可以拆成六步。第一步是需求接收。用户输入自然语言系统需要解析出核心目标、输入文件、输出格式、约束条件。如果用户没说清楚系统还要主动追问。第二步是目标解析。Agent 要把自然语言转成内部结构化任务描述比如“读取 ./resumes/ 目录下所有 PDF 文件提取姓名、工作年限、技能标签输出 Excel”。这一步决定了后续所有步骤是否正确。第三步是任务拆解。Agent 把大任务拆成若干子任务遍历文件、解析文本、抽取字段、去重合并、写入表格。每个子任务对应一个或一组工具调用。第四步是工具执行。Agent 调用文件读取、PDF 解析、正则提取、Excel 写入等工具并处理执行中的异常。第五步是结果校验。Agent 需要确认每个子任务是否真的完成比如文件数量是否对得上、字段是否有遗漏。第六步是汇总交付。最后把结果整理成用户需要的格式并附带执行说明和注意事项。这条链路看起来不复杂但每一步都有坑。需求解析不准后续全部白做工具执行报错时如果只重试不分析原因可能陷入死循环结果校验缺失时用户拿到残缺文件会立刻失去信任。这也是为什么 Agent 工程更像“业务流程设计”而不是“写一个提示词”。Manus 在公开演示里最吸引人的一点是把这条链路完整展示给用户。你能看到它正在打开哪个网页、输入什么关键词、找到了哪些信息。这种过程可视化降低了对黑盒的焦虑也给了用户中途干预的机会。它不是单纯的“技术炫技”而是一种面向非技术用户的设计策略。站在开发者角度你应该把这条链路当成一个可观测的流水线来设计每一步都应该有日志、有状态、有中间产物。只有这样才能定位问题也才能逐步优化每个环节的成功率。5. 开发者视角一个最小 Agent 系统的实现这一节我们用代码实现一个最小可运行的 Agent 系统。它不依赖任何具体云服务只是演示核心架构工具注册、模型决策、循环执行。理解了这套代码再去看 Manus 或其它 Agent 框架的源码会容易很多。5.1 先确定你的场景类型动手写代码前先想清楚你要做哪类 Agent。导航型 Agent以对话为主偶尔调用工具适合客服、助教执行型 Agent多步骤、多工具调用适合数据处理、报表生成自主型 Agent需要定时触发、任务队列、跨天执行适合长期监控、自动化运维。本节示例属于执行型因为它的结构最容易迁移到真实项目。5.2 代码示例一最小 Agent 主循环下面代码定义了一个工具注册表以及一个非常简化的“模型决策”函数。真实项目中ask_model应该调用大模型接口从tools.json中读取工具定义让模型返回tool_calls。这里用规则代替是为了让示例在不申请 API Key 的情况下也能运行。# agent_demo/simple_agent.py from dataclasses import dataclass, field from typing import Any, Callable dataclass class ToolRegistry: 工具注册表集中管理所有可被 Agent 调用的工具。 tools: dict[str, Callable[..., Any]] field(default_factorydict) def register(self, name: str, fn: Callable[..., Any]) - None: self.tools[name] fn def call(self, name: str, **kwargs) - Any: if name not in self.tools: raise ValueError(funknown tool: {name}) return self.tools[name](**kwargs) def parse_resume(resume_text: str) - dict[str, Any]: 模拟解析简历真实项目中这里调用 PDF 解析和字段抽取服务。 lines [line.strip() for line in resume_text.splitlines() if line.strip()] return {file_lines: len(lines), preview: lines[:3]} def send_email(to: str, subject: str, body: str) - dict[str, str]: 模拟发送邮件演示时用 print 代替真实 SMTP/邮件服务。 print(f[send_email] to{to}, subject{subject}) return {status: sent, to: to} def ask_model(task: str, history: list[str]) - dict[str, Any]: 真实项目中这里应该调用大模型的 chat/completions 接口 并把 tools.json 里的工具定义一并传给模型。 当前示例用关键词规则代替模型决策方便直接运行。 if 简历 in task or resume in task.lower(): return { tool: parse_resume, parameters: {resume_text: 张三 5年Java 本科\n熟悉Spring Cloud}, done: False, } if 邮件 in task or email in task.lower(): return { tool: send_email, parameters: { to: zhangsanexample.com, subject: 面试邀请, body: 您好欢迎参加本周六的面试。, }, done: False, } return {done: True, reason: 任务无需调用工具可以直接回答} def run_agent(task: str, registry: ToolRegistry, max_iterations: int 5) - list[str]: Agent 主循环规划 - 调用工具 - 记录结果 - 继续或终止。 真实场景还要加入状态管理、超时控制和失败重试。 history: list[str] [] for step in range(max_iterations): plan ask_model(task, history) history.append(fplan: {plan}) print(f[step {step 1}] {plan}) if plan.get(done): break result registry.call(plan[tool], **plan[parameters]) history.append(fresult: {result}) print(f[result] {result}) return history if __name__ __main__: registry ToolRegistry() registry.register(parse_resume, parse_resume) registry.register(send_email, send_email) run_agent(请帮我整理一份简历并发送邮件邀请面试, registry)这段代码的核心并不在规则本身而在ToolRegistry和run_agent的组合方式。工具注册表让 Agent 的能力边界清晰可控主循环让 Agent 可以连续执行多个步骤。真实项目里模型决策从规则换成大模型主循环从线性执行换成带状态、带重试的调度器整体骨架可以保持不变。5.3 代码示例二Function Calling 的工具定义如果接入 OpenAI 或同类大模型的 Function Calling 能力工具定义通常是一份 JSON 数组。模型看到这份定义后会在需要时返回tool_calls包含工具名和参数。下面这份配置演示了招聘场景下的两个工具。// agent_demo/tools.json [ { name: parse_resume, description: 从简历文本中提取姓名、工作年限、技能列表, parameters: { type: object, properties: { resume_text: { type: string, description: 简历原文 } }, required: [resume_text] } }, { name: send_email, description: 发送一封邮件给候选人, parameters: { type: object, properties: { to: { type: string, description: 收件人邮箱 }, subject: { type: string, description: 邮件主题 }, body: { type: string, description: 邮件正文 } }, required: [to, subject, body] } } ]写这份配置时最需要注意的是description。它不只是给人看的注释也会影响模型判断。描述写得模糊模型就可能不知道该在什么场景调用这个工具。比如parse_resume的 description 如果只写“解析简历”模型可能不知道输入格式是纯文本还是文件路径。建议把输入格式、使用场景、边界条件都写清楚。5.4 代码示例三异步任务调度与状态查询Manus 这类产品很重视异步执行。用户提交任务后系统返回一个task_id后续通过轮询获取状态。这种设计可以把长任务任务和用户请求解耦也让系统具备并发处理能力。下面代码演示一个极简的异步任务客户端。# agent_demo/async_task_client.py import time import requests API_BASE https://your-agent-service.example def submit_task(task: str, tools: list[str]) - str: 提交任务返回 task_id。 resp requests.post( f{API_BASE}/v1/tasks, json{task: task, tools: tools}, timeout10, ) resp.raise_for_status() return resp.json()[task_id] def wait_task(task_id: str, timeout: int 600, interval: int 5) - dict: 轮询任务状态直到成功或超时。 start time.time() while time.time() - start timeout: resp requests.get(f{API_BASE}/v1/tasks/{task_id}, timeout10) resp.raise_for_status() data resp.json() if data[status] in (succeeded, failed): return data time.sleep(interval) raise TimeoutError(ftask {task_id} timeout) if __name__ __main__: task_id submit_task( 阅读 ./resumes/ 下的 50 份简历提取候选人经历并输出 Excel, tools[file_reader, excel_writer], ) result wait_task(task_id) print(result)这里的API_BASE是占位地址运行时会报连接错误因为并没有真实服务。你可以在本地用 FastAPI 或 Flask 实现一个简易服务把上面的submit_task和wait_task接到真实接口上。它想表达的核心是长任务必须从请求响应模型中解放出来否则用户会一直在浏览器里等到超时。这三个示例合在一起就是一个最简 Agent 服务的雏形一份工具定义一个主循环一个异步任务接口。接下来我们看看如何验证它是否真的可用。6. 运行结果与验证如何判断 Agent 跑通了先运行最简 Agent 主循环。命令如下cd agent_demo python simple_agent.py预期输出大致是[step 1] {tool: parse_resume, parameters: {resume_text: 张三 5年Java 本科\n熟悉Spring Cloud}, done: False} [result] {file_lines: 3, preview: [张三 5年Java 本科, 熟悉Spring Cloud]} [step 2] {tool: send_email, parameters: {to: zhangsanexample.com, subject: 面试邀请, body: 您好欢迎参加本周六的面试。}, done: False} [send_email] tozhangsanexample.com, subject面试邀请 [result] {status: sent, to: zhangsanexample.com} [step 3] {done: True, reason: 任务无需调用工具可以直接回答}如果输出与上面接近说明主循环、工具注册、模型决策三个模块工作正常。如果卡在第 1 步不前进多半是ask_model返回了done: True或工具名拼写错误。但“能跑通”不等于“任务做对了”。真实 Agent 产品要建立一套验收维度完成率一百个任务里有多少任务从头到尾没有中断。正确率交付结果中关键字段的准确率是否达到可用线。可解释性用户能否看到每个步骤在做什么失败时能否说清原因。耗时平均任务时长是否符合用户预期能否支撑商业定价。成本每一单消耗多少 token、多少工具调用、多少算力资源。建议用一个小型评测集来验证。挑选 10 到 20 条典型任务覆盖正常情况、边界情况和失败情况。比如简历整理任务可以准备 5 份正常简历、2 份扫描件、1 份空文件、1 份格式混乱的文档然后观察 Agent 的处理结果。人工对每一条打分记录失败原因再针对性修补。如果任务失败第一步不是改提示词而是看执行日志和中间产物。检查 Agent 在哪一步偏离了目标是工具返回格式不对还是模型规划错误还是外部服务不稳定。日志越完整定位越快。这也是为什么前面强调状态管理和中间产物它们是排查问题的“黑匣子”。7. 常见问题与排查思路Agent 项目的问题往往集中在几个位置。下面用表格列出高频问题。问题现象可能原因排查方式解决方案Agent 一直不调用工具工具定义格式不对或模型没有收到工具描述检查请求体中的 tools/messages 结构确认模型返回了 tool_calls修正 Function Calling 配置重试并打印完整请求日志任务陷入死循环缺少最大步数限制模型不断重复同一工具调用查看主循环日志确认每步 tool 和参数是否相同增加 max_iterations增加“连续相同步骤”判定并终止工具返回结果无法解析工具输出不是结构化格式检查工具函数 return 值类型与解析代码是否匹配统一工具输出为 JSON字段名在文档中固定异步任务长时间无结果任务队列阻塞或沙箱资源不足查看任务状态表、沙箱运行日志增加超时、重试、资源上限必要时拆分子任务成本快速飙升每一步都调用大模型步骤过多统计 token 消耗观察工具调用次数引入缓存合并同类型步骤对简单判断用小模型用户数据出现串号沙箱隔离不充分或任务状态共用同一个目录检查沙箱文件系统和任务上下文隔离每个任务独立目录/容器数据加密敏感操作加确认一次执行成功第二次失败外部服务不稳定或依赖页面改版检查失败时的外部响应和页面 DOM 变化增加重试和降级策略锁定页面关键选择器这些问题大多不是模型能力不足而是工程控制不足。写好 Agent 的关键是把不稳定的外部世界变成可控的内部流程。控制程度越高产品越可靠。8. Agent 产品化的工程建议与商业化观察看 Manus 的收入增长不要只把它当成一个营销事件。它背后有一个正在形成的规律AI Agent 的商业价值最终由“任务确定性”决定而不是由“模型智能感”决定。一个能稳定完成“行业调研报告”或“批量简历筛选”的 Agent哪怕没有什么神奇体验也切实创造了生产价值。所以如果你是开发者或产品负责人准备做一个 Agent 产品请先接受一个反直觉的建议场景要窄工具要小。不要一开始就做“万能助理”那会让你的系统在无穷无尽的任务类型中顾此失彼。找到一个可重复、可付费、用户有痛点的窄场景比如“电商商品信息批量核对”“客服工单自动分类”“简历初筛”把它做到错误率在可接受范围内再考虑扩展。工程上有几个建议值得提前制定规范。第一个是工具命名和参数规范。所有工具函数名称统一使用 snake_case参数禁止使用模糊的data、args每个参数都写明类型和说明。第二个是执行轨迹记录。每次工具调用的输入、输出、耗时、错误都要写入日志方便追踪。第三个是安全边界设计。Agent 能访问的目录、网络、数据库资源要按最小权限原则开放高风险操作必须增加人工确认。还有一个往往被忽略的问题成本模型。Agent 比 Chatbot 贵得多因为一次任务可能触发十次以上模型调用和多次外部服务请求。如果在产品设计阶段不计算单任务成本商业化之后很容易陷入“单量越多亏得越多”的困境。建议提前设立成本监控并按任务类型拆分统计为定价提供依据。关于发布与回滚Agent 产品与普通 Web 应用不同。普通应用改个接口可以直接回滚Agent 改一个提示词或工具定义可能影响所有后续任务。建议所有提示词、工具定义、模型参数都走配置管理新版本先在灰度流量上观察完成率和错误率再逐步放量。如果你在做团队协作也建议把 Agent 看作是“会犯错的实习生”而不是“绝对可靠的老员工”。给它的任务要有明确交付物要有验收标准要有危险操作护栏。这样即使它出错也只是局部错误不会酿成事故。9. 留给开发者的问题回到标题里的问题被退货的 Manus 收入翻了五倍这个“矛盾”其实一点也不矛盾。Chatbot 的舆论场上靠的是惊喜感和流畅感Agent 的商业场上靠的是确定性和交付价值。一个产品完全可以在这两个场里得到截然不同的评价。如果你也想在这个方向做点东西不妨先回答三个问题第一你做的 Agent 要稳定交付哪个具体任务如果说不清楚产品就没有立足点。第二你怎么证明它比现有流程更省时间不要用“看起来智能”当答案要有量化对比。第三当它失败时用户找谁、怎么排查、怎么补救这个问题的答案决定了你是否敢把它放到生产环境。这三个问题想清楚你再回头看 Manus 的争议和增长会发现一切都有迹可循。AI Agent 的泡沫不在于技术本身而在于用了太多不属于它的评价标准。回归任务交付回归工程控制才能真正做出有人愿意持续付费的 Agent 产品。
