记得去年 Manus 在中文互联网刷屏时很多人的第一反应是“又一个 AI 产品要被挤爆了”。没过多久舆论就转向了另一面排队时间长、任务执行不稳定、退款流程被反复提及。可短短几个月后又有消息称 Manus 的收入翻了数倍。这个反差很容易被当成商业八卦但对开发者来说这其实是一个非常有价值的 AI Agent 产品工程案例。本文不打算追逐“Manus 内部数据”这类无法核实的信息而是从工程视角拆解一个 AI Agent 产品从“被大量退货”到“收入恢复增长”的完整逻辑。你会看到 AI Agent 产品的核心模块是什么、为什么计费和可观测性会直接影响用户留存以及如何用一套极简的数据分析脚本量化“退款率”和“增长倍数”这两个关键指标。如果你正在做 AI 应用、智能体开发或者打算把 Agent 能力商业化这篇文章应该能给你一套可以落地的参考框架。1. 背景从“被退货”到“收入翻五倍”的产品逻辑1.1 Manus 是什么它为什么重要Manus 是一个通用型 AI Agent 产品。传统 ChatGPT 类产品主要做“对话”用户问一句模型回答一句。Manus 做的事情更接近“执行任务”用户给出目标Agent 自己拆解步骤、选择工具、操作网页、执行代码最后交付一份结果。它更像是把“AI 大脑”和“能动手的双手”结合在了一起。从产品形态来看AI Agent 与聊天机器人的最大区别是闭环交付。聊天机器人只负责生成文字Agent 则需要对结果负责。这个差异带来了完全不同的工程复杂度Agent 不仅要理解用户意图还要管理任务状态、工具调用、上下文记忆、异常恢复和资源消耗。Manus 之所以在初期引发大量关注是因为它第一次让很多普通用户直观感受到“AI 可以不只聊天还能干活”。但正因为这种预期被拉得很高当服务不稳定时用户的失落感也会被放大。1.2 “被退货”的本质原因是什么“被退货”是 2025 年 3 月前后围绕 Manus 最热的话题之一。从公开讨论和产品反馈看用户退款并不是不认可 Agent 方向而更多是预期管理出了问题叠加基础服务没有跟上。核心原因有几类服务容量不足大量用户同时涌入任务队列积压用户等待几个小时还拿不到结果。任务执行不稳定Agent 执行过程中出现超时、中断、上下文丢失导致交付结果不完整。计费规则不清晰付费前对任务次数、耗时、模型成本的预期不一致用户觉得“花钱没换来等价结果”。缺少退款与信任机制退款入口深、处理慢用户产生的负面体验会被社交网络放大。本质上这些都不是“AI 能力不行”而是“产品工程化没跟上”。Demo 可以只演示顺利路径但真实产品必须要处理异常路径。1.3 收入翻五倍的背后做对了什么后续 Manus 的收入出现数倍增长虽然具体数字我们无从考证但从产品演进方向可以看到几条清晰的改善路径明确商业化边界区分免费体验、订阅付费、企业版 API 等不同模式让用户对成本有明确预期。异步任务体验优化放弃“请求-立即响应”的同步模式改为任务队列 结果通知用户不需要一直盯着页面。交付可感知结果不仅给“执行过程”还提供结构化结果、文件、截图让用户觉得任务真的完成了。企业场景延伸进入工作流、数据分析、自动化执行等更垂直的场景提高客单价和复购率。这给开发者的启发是AI Agent 产品能不能赚钱不完全取决于模型强不强更取决于任务可靠性、计费清晰度和用户信任感。2. 环境准备与项目设计2.1 本文示例环境为了把“退款”和“增长”这两个抽象概念变成可量化的指标我会用 Python SQLite 搭建一个极简的 Agent 计费与增长分析系统。这个示例不代表 Manus 的真实技术栈仅用于展示数据分析思路。建议环境如下Python 3.10 或更高版本SQLite 3Python 内置支持pandas 库命令行终端或 Jupyter Notebook安装依赖pip install pandas如果你本机还没有 Python可以先安装 Python 3.10再执行上面的命令。2.2 项目目录结构建议创建一个独立目录方便保存脚本和数据agent_metrics/ ├── agent_metrics.py # 核心分析脚本 ├── agent.db # SQLite 数据库运行时自动生成 └── output/ └── metrics.csv # 输出的指标报表项目核心目标是模拟三种数据订单表记录用户购买套餐的金额和时间。退款表记录用户退款金额、原因和时间。指标计算按月统计 GMV、退款额、净收入、退款率和增长倍数。2.3 为什么用 SQLite 而不是 MySQL这个示例使用 SQLite 主要是为了降低上手门槛。SQLite 是文件型数据库不需要单独启动服务所有数据都保存在一个.db文件中。如果你的项目已经使用 MySQL、PostgreSQL分析逻辑是完全一样的只需要把sqlite3.connect()换成对应的数据库连接即可。生产环境建议用集中式数据库方便多个服务共享数据。3. AI Agent 的核心原理与模块拆解3.1 Agent 的核心执行循环在写分析系统之前先梳理 AI Agent 产品本身的工程结构。一个最小可用的 Agent 通常是这样的循环用户输入 ↓ 任务理解与规划 ↓ 选择工具 → 执行工具 → 观察结果 ↓ 是否需要继续执行 ↓ 输出最终结果这个循环看起来简单但每一步都有大量工程细节。任务理解不只是把用户输入丢给大模型而是要做意图识别、参数抽取、上下文补全。比如用户说“帮我查一下上周广州的天气并整理成报表”Agent 需要识别出时间范围、地点、输出格式三个关键参数。规划是整个 Agent 的核心难点。简单任务可以一步完成复杂任务则要拆成多步每一步依赖前一步的结果。规划模块不仅要生成步骤还要处理步骤失败后的重试和回退。工具调用是 Agent 与外部世界交互的通道。常见工具有搜索引擎、数据库查询、代码执行器、网页操作、文件读写等。每个工具都需要定义清晰的输入输出协议否则模型很容易生成无效参数。观察结果包括工具返回的数据、执行日志、错误信息。Agent 需要把观察结果转成下一步决策的依据。这个过程容易被忽略但特别关键因为很多 Agent 任务失败都是因为模型无法正确理解工具返回的异常状态。3.2 商业化 Agent 需要哪些额外模块Demo 阶段的 Agent 可以只有“输入-规划-执行-输出”这四个模块但商业化产品还必须额外加上几个模块。第一个是任务队列。Agent 任务通常是异步的用户提交后可能几十秒甚至几分钟才能完成。如果使用同步请求一旦任务超时用户只会看到一个白屏或“超时”错误。引入任务队列后系统可以快速返回“任务已受理”用户稍后再查看结果。用户请求 ↓ 写入任务队列Redis Stream / RabbitMQ / Celery ↓ Worker 拉取任务执行 ↓ 状态更新 结果存储 ↓ 用户拉取结果或接收通知第二个是上下文管理。Agent 在多轮任务中需要记忆前置步骤的结果。如果直接把全部历史都塞给大模型Token 成本会快速增长还可能超出模型上下文窗口。所以工程上通常会用摘要、向量检索或结构化状态来压缩上下文。第三个是计费与配额控制。Agent 的成本不仅来自大模型 Token还来自工具调用、计算资源、存储资源。如果上线前没有搭好计费系统用户流量稍大一点成本就会失控。3.3 为什么退款率和净收入比 GMV 更重要很多团队喜欢看 GMV也就是订单总金额但实际上 GMV 会掩盖很多问题。举个例子某个月订单总额 100 万看起来不错但退款 80 万真正落袋的只有 20 万。如果只看 GMV你可能觉得业务正在起飞但看退款率才知道产品体验已经出现严重问题。所以我在后面的分析例子里会重点计算两个指标退款率退款金额 / 订单金额。反映产品交付质量。净收入订单金额 - 退款金额。反映真实收入。这两个指标不仅适用于 AI Agent也适用于所有需要付费的 SaaS、API 服务。4. 完整实战极简 Agent 计费与增长分析系统4.1 创建数据表先创建 SQLite 数据表。订单表记录用户购买行为退款表记录退款行为。为了便于统计这里用created_at字段记录业务发生时间而不是数据库默认的插入时间。文件路径agent_metrics/agent_metrics.pyimport sqlite3 DB_PATH agent.db def create_tables(): conn sqlite3.connect(DB_PATH) cursor conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS orders ( order_id TEXT PRIMARY KEY, user_id TEXT NOT NULL, plan_type TEXT NOT NULL, amount REAL NOT NULL, status TEXT NOT NULL, created_at TEXT NOT NULL ) ) cursor.execute( CREATE TABLE IF NOT EXISTS refunds ( refund_id TEXT PRIMARY KEY, order_id TEXT NOT NULL, amount REAL NOT NULL, reason TEXT, created_at TEXT NOT NULL ) ) conn.commit() conn.close()表结构说明orders.amount是订单支付金额单位可以用元。orders.status用于标识订单状态比如paid、refunded。refunds.reason记录退款原因后续可以按原因聚合分析。4.2 写入演示数据为了演示效果我手动构造三个月的数据。2025 年 3 月是高退款阶段4 月服务逐步稳定5 月收入明显回升。DEMO_ORDERS [ # 2025-03 订单 (O1001, U001, pro_monthly, 100, paid, 2025-03-01 10:00:00), (O1002, U002, pro_monthly, 100, paid, 2025-03-02 11:30:00), (O1003, U003, pro_monthly, 100, paid, 2025-03-03 09:20:00), (O1004, U004, pro_monthly, 100, paid, 2025-03-05 14:40:00), (O1005, U005, pro_monthly, 100, paid, 2025-03-06 16:10:00), (O1006, U006, pro_monthly, 100, paid, 2025-03-08 20:30:00), (O1007, U007, pro_monthly, 100, paid, 2025-03-10 08:50:00), (O1008, U008, pro_monthly, 100, paid, 2025-03-12 18:00:00), # 2025-04 订单 (O2001, U009, pro_monthly, 100, paid, 2025-04-01 10:00:00), (O2002, U010, pro_monthly, 100, paid, 2025-04-03 11:00:00), (O2003, U011, pro_yearly, 1080, paid, 2025-04-05 15:00:00), (O2004, U012, pro_monthly, 100, paid, 2025-04-08 09:30:00), (O2005, U013, pro_monthly, 100, paid, 2025-04-12 13:20:00), (O2006, U014, pro_monthly, 100, paid, 2025-04-15 17:45:00), (O2007, U015, pro_monthly, 100, paid, 2025-04-18 21:10:00), (O2008, U016, pro_monthly, 100, paid, 2025-04-22 10:40:00), (O2009, U017, pro_monthly, 100, paid, 2025-04-25 19:30:00), (O2010, U018, pro_monthly, 100, paid, 2025-04-28 12:00:00), # 2025-05 订单 (O3001, U019, pro_yearly, 1080, paid, 2025-05-01 10:00:00), (O3002, U020, pro_monthly, 100, paid, 2025-05-03 11:00:00), (O3003, U021, pro_monthly, 100, paid, 2025-05-06 15:30:00), (O3004, U022, pro_yearly, 1080, paid, 2025-05-08 09:20:00), (O3005, U023, pro_monthly, 100, paid, 2025-05-10 14:10:00), (O3006, U024, pro_monthly, 100, paid, 2025-05-13 18:00:00), (O3007, U025, pro_monthly, 100, paid, 2025-05-15 20:30:00), (O3008, U026, pro_monthly, 100, paid, 2025-05-18 22:00:00), (O3009, U027, pro_yearly, 1080, paid, 2025-05-20 10:00:00), (O3010, U028, pro_monthly, 100, paid, 2025-05-23 13:30:00), (O3011, U029, pro_monthly, 100, paid, 2025-05-26 16:50:00), (O3012, U030, pro_monthly, 100, paid, 2025-05-29 11:20:00), ] DEMO_REFUNDS [ # 2025-03 退款较多原因是服务不稳定、排队慢 (R001, O1001, 100, service_unstable, 2025-03-03 10:00:00), (R002, O1002, 100, queue_too_long, 2025-03-04 11:00:00), (R003, O1003, 100, result_incomplete, 2025-03-06 09:30:00), # 2025-04 退款减少 (R004, O2001, 100, not_satisfied, 2025-04-05 10:00:00), (R005, O2004, 100, no_need, 2025-04-10 15:00:00), # 2025-05 退款进一步减少 (R006, O3001, 1080, not_satisfied, 2025-05-04 10:00:00), (R007, O3003, 100, price_sensitive, 2025-05-08 18:00:00), ]写入数据的函数def insert_demo_data(): conn sqlite3.connect(DB_PATH) cursor conn.cursor() cursor.executemany( INSERT INTO orders (order_id, user_id, plan_type, amount, status, created_at) VALUES (?, ?, ?, ?, ?, ?), DEMO_ORDERS, ) cursor.executemany( INSERT INTO refunds (refund_id, order_id, amount, reason, created_at) VALUES (?, ?, ?, ?, ?), DEMO_REFUNDS, ) conn.commit() conn.close()4.3 编写按月指标统计脚本统计脚本的核心流程是从订单表读取数据。从退款表读取数据。把时间字符串转成月份。按月聚合 GMV、退款额和净收入。计算退款率和增长倍数。完整代码如下import pandas as pd def compute_metrics(): conn sqlite3.connect(DB_PATH) orders_df pd.read_sql_query(SELECT * FROM orders, conn) refunds_df pd.read_sql_query(SELECT * FROM refunds, conn) conn.close() orders_df[created_at] pd.to_datetime(orders_df[created_at]) refunds_df[created_at] pd.to_datetime(refunds_df[created_at]) orders_df[month] orders_df[created_at].dt.to_period(M).astype(str) refunds_df[month] refunds_df[created_at].dt.to_period(M).astype(str) # GMV: 订单总额 gmv orders_df.groupby(month)[amount].sum() # 退款金额 refund_amount refunds_df.groupby(month)[amount].sum() # 净收入 GMV - 退款 net_revenue gmv.sub(refund_amount, fill_value0) # 退款率 退款额 / GMV * 100 refund_rate (refund_amount / gmv * 100).round(2) # 组装结果表 result pd.DataFrame({ gmv: gmv, refund_amount: refund_amount, net_revenue: net_revenue, refund_rate: refund_rate, }).fillna(0) # 以第一个月的净收入为基数计算增长倍数 base_revenue result[net_revenue].iloc[0] result[growth_vs_base] (result[net_revenue] / base_revenue).round(2) # 退款原因分布 reason_dist refunds_df[reason].value_counts() return result, reason_dist def main(): create_tables() insert_demo_data() result, reason_dist compute_metrics() print( 每月收入与退款指标 ) print(result) print() print( 退款原因分布 ) print(reason_dist) result.to_csv(output/metrics.csv, encodingutf-8-sig) print() print(报表已保存到 output/metrics.csv) if __name__ __main__: main()4.4 运行与结果说明在命令行中执行cd agent_metrics python agent_metrics.py预期输出如下 每月收入与退款指标 gmv refund_amount net_revenue refund_rate growth_vs_base 2025-03 800.0 300.0 500.0 37.50 1.00 2025-04 1680.0 200.0 1480.0 11.90 2.96 2025-05 3720.0 1180.0 2540.0 31.72 5.08 退款原因分布 not_satisfied 2 service_unstable 1 queue_too_long 1 result_incomplete 1 no_need 1 price_sensitive 1这里有两个值得关注的点。第一个是净收入增长倍数。3 月净收入 500 元5 月净收入 2540 元增长约 5.08 倍。这正是标题里“收入翻了五倍”的技术表达不是看 GMV而是看净收入。第二个是退款率的波动。5 月退款率 31.72%金额比 3 月还高原因是 5 月出现了一笔 1080 元的“pro_yearly”订阅退款。这说明高客单价产品会放大退款对收入的影响。真实业务中不能只盯“退款率”一个指标还要结合退款金额和退款原因一起看。如果免费用户或小额订单退款多产品问题通常出在体验环节如果大额订单退款多问题可能出在售前承诺和产品价值不匹配。4.5 扩展到真实业务上面的示例虽然数据是模拟的但计算逻辑可以直接用在真实业务中。你只需要把create_tables()和insert_demo_data()替换成自己的真实数据源再把compute_metrics()接入定时任务就能实现日报或周报自动输出。推荐的扩展方向把month维度细化到day观察日均变化。增加“用户画像”维度比如新用户退款率、老用户退款率。增加“渠道来源”维度分析哪个渠道带来的用户退款率最高。对退款原因做文本分类自动打标签。5. 常见问题与排查思路5.1 常见问题排查表做 AI Agent 产品时开发者最容易遇到的问题如下问题现象常见原因解决思路任务排队时间过长消费者 Worker 数量不足或任务队列堆积增加 Worker设置队列告警超出水位时自动扩容Agent 任务执行到一半丢失上下文只保存在内存没有持久化把状态写入数据库或 Redis支持断点续跑用户重复下单被重复扣费缺少幂等性校验用幂等键或订单号做唯一约束重复请求直接返回已有结果账单金额和预期不一致多模型调用计费口径不统一统一计费事件埋点按 Task、Token、Tool 分别记账退款率突然上升模型质量下降、服务不稳定或政策变动建立退款率监控告警加入原因分析面板用户反馈结果“答非所问”工具调用参数抽取失败或规划拆解不合理记录每次工具调用入参和出参方便定位错误环节5.2 为什么退款数据需要单独建模很多团队一开始只建订单表退款只是在订单上加一个状态字段这种做法在后期会非常痛苦。原因是退款不是订单的简单属性它有独立的时间、金额、原因和操作人。如果把退款拆成单独的refunds表统计逻辑会清晰很多。此外退款业务往往有“时间差”。用户可能在 3 月购买4 月才申请退款。如果只按订单时间统计退款会发现上个月的收入被本月的退款冲掉。所以我在示例里特意让退款表拥有自己的created_at字段统计时按退款时间归属月份。5.3 排查 Agent 任务失败的关键步骤如果 Agent 任务经常失败建议按下面的顺序排查先看日志任务卡在哪个阶段是规划阶段、工具调用阶段还是结果生成阶段再看模型输入丢给大模型的上下文是否正确有没有把错误结果当成下一步输入再看工具返回工具返回的数据格式是否符合预期超时和异常是否被正确捕获最后看基础设施内存、CPU、网络带宽是否成为瓶颈不要一上来就改 Prompt。很多时候问题并不在模型而在状态管理和异常处理。6. 最佳实践与工程建议6.1 用状态机管理 Agent 任务周期Agent 任务不是“开始”和“结束”两个状态就能描述的。一个真实任务通常会经历pending → queued → running → tool_calling → completed → failed / refunded / canceled无论你用 Redis、数据库还是专门的工作流引擎都应该把任务状态持久化。这不仅能帮你复盘问题还能在任务中断时恢复执行。示例状态字段可以是pending: 已创建未进入队列 queued: 已进入队列等待 Worker 处理 running: Worker 正在执行 tool_calling: 正在调用外部工具 completed: 执行完成 failed: 执行失败等待重试或人工介入每一步切换都要写日志记录时间和原因。这个日志是你排查退款问题最重要的依据。6.2 异步优先避免同步阻塞很多 AI Agent 的初次实现都是同步接口用户发请求后端等模型返回再响应给用户。这在 demo 阶段没问题但一旦任务耗时变长就会面临 HTTP 超时、用户体验差等问题。设计上建议采用异步模式用户提交任务后接口立即返回task_id。后台 Worker 拉取任务执行实时更新任务状态。前端通过轮询或 WebSocket 展示执行进度。任务完成后发送结果通知。异步化之后即使某个任务执行失败也不会阻塞后续请求退款率和流失率都会有所下降。6.3 计费系统要前置而不是补救AI Agent 产品的成本有很强的“按量”属性。每次模型调用都要花钱每次工具执行也要消耗资源。如果计费系统上线晚了可能会出现两种情况用户免费大量使用成本无法控制。收费规则改一次用户信任降一次。建议在第一个付费版本上线之前就完成三个件事统一的计费事件埋点。按用户、按任务的用量统计。配额限制和告警。计费数据要尽量原子化。比如一次任务中调用了 3 次大模型接口就记录 3 条计费明细而不是只记录 1 条任务账单。明细是后续处理争议和退款的关键依据。6.4 把退款原因当成产品改进信号退款并不完全是坏事。它能直接告诉你产品在哪个环节让用户失望了。我在示例中把退款原因分成了service_unstable、queue_too_long、result_incomplete、not_satisfied、price_sensitive等几类。真实产品里可以做更细的分类模型生成结果质量差。工具调用失败。等待时间过长。价格超出预算。功能不符合预期。每周对退款原因做一次归因分析再结合任务日志基本能定位出产品短板。修复这些短板比一味做流量投放更能提升净收入。6.5 安全与数据隔离AI Agent 往往需要访问用户的私有数据比如网盘、邮箱、数据库。商业化产品必须在架构层面做好隔离每个用户的任务要有独立的沙箱环境。工具调用的 API Key 不能暴露给前端。任务日志中敏感信息要脱敏。删除用户时要能级联清理关联数据。退款率高不一定是因为产品不好也可能是因为用户不信任你的安全能力。在官网或产品页明确展示数据隔离和删除机制是提升付费转化的重要一步。6.6 灰度发布与容量规划AI Agent 产品的流量波动通常很剧烈。一次热门话题、一条推荐新闻都可能导致任务量一夜之间翻数倍。如果没有容量规划就会出现“被退货”阶段的排队和崩溃。推荐做法是新功能先在小范围灰度观察任务成功率、模型调用成本和退款率。核心模型版本切换时用 A/B 测试对比用户满意度。为任务队列设置最大并发数超过阈值时排队而不是无限扩容。定期压测提前识别模型调用瓶颈和数据库瓶颈。7. 总结与学习路线“被退货的 Manus 收入翻了五倍”这个话题说到底反映了 AI Agent 产品从概念到商业化的完整过程。用户退款不是终点而是产品迭代的起点。真正决定产品能否增长的因素不只是模型能力还有任务可靠性、计费清晰度、数据可观测性和退款处理机制。从本文你可以掌握四件事AI Agent 的核心模块包括任务理解、规划、工具调用、状态管理和计费控制。退款率、净收入比 GMV 更能反映产品健康度。用 Python SQLite 可以快速搭建一套按月统计退款和增长的指标系统。异步任务、状态持久化、灰度发布和退款归因是商业化 Agent 的工程底线。如果你想继续深入可以从三个方向展开学习Agent 框架与编排了解主流的 Agent 开发框架理解任务规划、工具注册和多 Agent 协作的实现方式。异步任务工程学习 Redis Stream、Celery 或消息队列的高级用法把任务调度做到可恢复、可追踪、可扩容。商业化数据体系学习数据仓库建模、BI 报表设计和退款风控把收入指标做成团队日常可见的看板。希望这篇文章能帮你少踩一些“被退货”的坑。如果你正在做 AI Agent 产品建议先用本文的脚本把退款和收入指标跑通再逐步搭建完整的任务观测体系。资料可以收藏备用动手实践时按自己的业务数据替换示例即可。