Always-On Agent

What is it（这是什么）

Always-On Agent 是一种「始终在线、按实际工作时间计费」的 AI 代理形态。传统 SaaS 按席位或按月订阅收费，无论你是否使用都要付费；Always-On Agent 则反过来——agent 常驻待命，随时可被唤起，但只在真正执行任务的那段时间计费。技术本质是把 LLM 推理从「会话式」变成「常驻服务式」：agent 保持状态、监听事件、按需触发，计费粒度下沉到分钟甚至秒级。商业意义在于它解决了 AI agent 最大的付费摩擦——用户不愿为一个「可能用不上」的常驻服务付固定月费，而按工时计费让成本与价值直接对齐。对独立开发者来说，这意味着可以卖「agent 工时」而不是卖「软件许可证」。

Why now（为什么现在出现）

三个条件在 2026 年同时成熟。第一，推理成本下降到可承受区间——2024 年跑一个常驻 agent 的 token 成本让按工时计费无法盈利，到 2026 年主流模型推理单价已降至两年前的十分之一量级，分钟级计费才具备毛利空间。第二，用户心智从「聊天框」转向「数字同事」：ChatGPT 式会话交互的教育期结束，用户开始期待 agent 主动待命、后台执行，Rex、Botel 这类产品正是踩在这个转折点上。第三，按用量计费的商业模式在开发者群体中已被验证（API 计费、云函数、Vercel 的按调用计费），「按工时付费」不再需要从零教育市场。一年前推理成本撑不住这个模型，一年后这个形态可能已被大厂收编为标准功能——2026 年 Q4 是独立开发者的窗口期。

Market Evidence（市场证据）

信号本身很弱但方向清晰。3 个独立信源（producthunt、v2ex、showhn）各贡献 1 次提及，总提及 3 次，增长率 100%——这个 100% 是「从 1 到 2」式的低基数增长，不能解读为爆发。趋势分数 72/100 属于中上，说明语义层面的关注度高于实际讨论量，即「这个词被讨论时评价积极，但还没形成讨论潮」。成熟度 nascent 的判断准确：目前处于概念验证期，Rex 和 Botel 是两个已知的探路者，都还没有形成品类标准。信号质量判断：这是真实需求的前哨，不是纯社区热点——v2ex 和 showhn 的讨论者是有付费能力的开发者和早期采用者，他们讨论的是「怎么计费」而非「要不要」，这比纯概念讨论有价值得多。但 3 次提及不足以证明市场存在，只证明有人在想这件事。

Who's Behind It（谁在推动）

目前没有「庄家」。已知玩家是 Rex 和 Botel 两个早期产品，都在探索常驻 agent 的交互模型与计费方式，体量小、无公开融资信息，属于独立开发者或小团队级别。真正在底层推动的是模型厂商——OpenAI、Anthropic 的 agent 框架和长时运行能力（持久会话、后台任务）是这个形态的技术地基，但它们不会自己做垂直场景的按工时 agent，这恰恰留出了空间。开源社区方面，AutoGPT、OpenHands 一类项目提供了常驻 agent 的运行时参考实现。结论：这是一个「无主之地」，没有大厂卡位，也没有强势开源标准，独立开发者进入的竞争门槛极低，但同样意味着没有生态红利可借。

TAM & Market Size（市场规模）

需求分 0/100、机会分 0/100 说明数据侧尚未捕捉到可量化的付费信号，市场规模的判断只能从邻近市场外推。潜在用户是「有间歇性 AI 任务、但不愿为闲置时间付费」的中小团队和个人开发者：客服值班、数据监控、定时内容生成、代码审查守夜等场景。全球独立开发者与小微 SaaS 团队规模在数百万量级，若其中 1% 愿意为 agent 工时付费、人均月支出 20-50 美元，对应年市场规模在数亿美元级别——是个「够养活一批独立开发者、但引不起大厂兴趣」的甜蜜区间。付费意愿是真实的：按工时计费本质是「用多少付多少」，比订阅制更符合这类用户的风险偏好。市场处于早期增长阶段，尚未定型。

Competitive Landscape（竞争格局）

竞争分 0/100 反映的是「还没有人认真做」。现有玩家 Rex、Botel 处于产品探索期，优势是先发和概念清晰，劣势是没有规模、没有渠道、计费模型未验证。市场空白非常明显：目前没有「agent 工时计费基础设施」——即帮其他开发者给自己的 agent 接上按分钟计费、计量、结算的中间层。大公司会不会做？OpenAI、Anthropic 会做 agent 运行时，但不会做跨平台的工时计费与结算层；Stripe 会做计费原语，但不会做 agent 语义的计量。这意味着中间层有 12-18 个月窗口。差异化机会在于：不做又一个 agent 产品，而做「让所有 agent 都能按工时收费」的计费与计量基础设施。

Business Model（商业模式）

推荐「免费增值 + 按用量抽成」的混合模式，而非纯订阅。理由：Always-On Agent 的价值主张就是「只为使用付费」，你如果自己卖固定月费，逻辑自相矛盾。具体设计：基础功能免费（每月 100 分钟 agent 工时），超出部分按 0.05-0.10 美元/分钟计费，或按抽成 3-5% 收取平台费。定价依据：对标云函数和 API 计费的行业惯例，开发者对「按调用付费」的接受度远高于按席位订阅。12 个月收入预测：保守 3,000 美元/月（50 个付费用户、人均 60 美元）、基准 12,000 美元/月（200 个付费用户）、乐观 35,000 美元/月（600 个付费用户 + 抽成）。获客成本估算：开发者工具类 CAC 约 30-80 美元，通过 showhn、v2ex、Product Hunt 冷启动可压到 20 美元以下，回本周期 2-4 个月。关键指标是「分钟消耗量」而非「注册数」。

MVP Blueprint（MVP 蓝图）

核心功能只保留四件：① agent 会话的分钟级计量（开始/暂停/结束打点）；② 工时账本与余额扣减；③ 一个极简的开发者 API（三个端点：start、stop、usage）；④ 一个仪表盘显示消耗与账单。砍掉：多租户权限、复杂计费规则、发票系统、agent 编排能力。

技术栈：后端用 Node.js + Fastify（或 Python + FastAPI），Postgres 存工时账本（用 append-only 事件表保证可审计），Redis 做实时计量，部署在 Railway 或 Fly.io，前端用 Next.js + shadcn/ui 模板，支付直接接 Stripe Metered Billing，省掉自建计费。

最快上线路径：用 Stripe 的 usage-based billing 做计费底座，自己只写计量 SDK 和仪表盘，一周内可上线一个「给 agent 加按分钟计费」的 API 产品，在 showhn 发帖验证。建议产品形态是 API + SaaS 仪表盘的组合。

Commercial Opportunities（商业化机会）

方向一：Agent 工时计费基础设施。目标用户是正在做 agent 产品的独立开发者，他们需要给自己的 agent 接上计量与结算但不想自建。预期月收入 5,000-15,000 美元。优于其他方向的原因：卖铲子而非淘金，客户越多越稳，且不承担 agent 本身的产品风险。

方向二：垂直场景的常驻 agent，如「客服守夜 agent」——夜间按分钟计费接管客服工单。目标用户是电商小卖家，预期月收入 3,000-8,000 美元。优势是场景明确、计费逻辑天然契合。

方向三：Agent 工时市场（marketplace），让企业按小时租用预配置的 agent。目标用户是中型企业的运营团队，预期月收入 10,000 美元以上，但需要双边冷启动，优先级最低。

Product Ideas（产品创意）

🥇 MeterAgent — 一句话：给你的 AI agent 装上按分钟计费的电表。目标用户是正在商业化 agent 的独立开发者，场景是「我不想自建计量和结算系统」。为什么现在：品类尚无标准，先发者定义接口。用 Stripe Metered Billing 三天可出可用版本。

🥈 NightShift — 一句话：只在夜间和周末工作的客服 agent，按实际处理工单的分钟数收费。目标用户是独立电商卖家，场景是下班后的工单积压。为什么现在：人力客服夜间成本高，按分钟计费的 agent 是纯增量价值。

🥉 AgentTimesheet — 一句话：记录并审计你的团队用了多少 agent 工时。目标用户是已在使用多个 agent 工具的中小团队，场景是成本归集与预算控制。为什么现在：企业一旦开始按工时付费 agent，就需要工时报表，这是自然衍生需求。

SEO Opportunity（SEO 机会）

搜索量趋势：上升，但基数极小，属于「抢先占词」阶段而非「收割流量」阶段。有价值的长尾词：always-on agent pricing、pay per minute AI agent、agent usage-based billing、AI agent timesheet、metered billing for LLM agents。竞争程度极低（SEO 难度 0/100），几乎无内容竞争。内容策略：做「对比页 + 计算器」最容易拿排名——例如「按工时 vs 按席位：agent 计费成本计算器」，这类工具页既拿长尾词又直接转化。

Risk Assessment（风险评估）

判断可能错的情形：按工时计费最终被证明是伪需求，用户其实更接受「包月不限量」——因为大多数 agent 任务时长不可预测，分钟计费会带来账单焦虑。这是最大的市场风险。三大风险：技术风险是计量准确性（漏计、重复计费会直接摧毁信任）；市场风险是模型厂商把「常驻 + 计费」做成平台原生能力；执行风险是双边市场冷启动失败。最低成本验证方式：不写产品，先写一篇「agent 按分钟计费的计量方案」技术文章发到 v2ex 和 showhn，看有多少人问「哪里能买到」。如果两周内没有 20 个以上主动询价，就该放弃或转向垂直场景。

Action Plan（行动建议）

第一步（今天）：在 v2ex 和 showhn 各发一帖，问「你们给 agent 计费时怎么处理闲置时间」，收集 10 个以上真实回答，验证计费痛点是否存在。

第一周：用 Stripe Metered Billing + 一个 200 行的计量 SDK 做出可演示的 demo，录 90 秒视频，再发一次 showhn，目标 50 个 waitlist。

第一个月：上线 MeterAgent 的公开 beta，免费额度 100 分钟，重点盯「分钟消耗量」和「付费转化率」两个指标，达到 20 个付费用户即确认信号。

第三个月：若基准收入达 5,000 美元/月，扩展垂直场景 agent；若付费转化低于 3%，转向方向二（垂直常驻 agent），不再在基础设施层投入。

Related Terms（相关趋势）

• AI Agent — 上位概念，Always-On Agent 是其「常驻 + 计费」子形态，依赖关系
• Usage-Based Pricing — 计费模式母体，Always-On Agent 是其向 agent 场景的延伸，互补关系
• Agent Runtime / Agent Framework — 常驻 agent 的技术底座，提供持久会话能力，依赖关系