行业正在从「通用叙事」收敛到「垂直场景」
2025 年初 Manus 刷屏的时候，通用 Agent 的故事讲到顶了：一句话让 AI 帮你做调研、写代码、订机票。但一年过去，真正活下来并赚到钱的是垂直场景。写代码有 Cursor 和 Claude Code，这是目前商业化最成功的 Agent 品类，Cursor 的年化收入公开报道过数亿美元量级；办公场景有各家大厂的 Agent 产品嵌在自家生态里；客服、销售外呼这类 B 端场景在按效果计费。通用 Agent 的问题很实际：任务链条一长，成功率就指数下降——单步成功率 90%，十步连乘下来只剩三成多，用户用两次翻车就不来了。所以我的判断是：2026 年做 Agent，「场景选得窄、任务定义得清」比「模型接得强」重要得多。
值得关注的方向一：编程 Agent 的外溢
编程是 Agent 第一个跑通的场景，原因很特殊：代码可验证（能跑、能测）、用户专业（能审阅 AI 产出）、付费意愿强（开发者省的是自己的时间）。2026 年要盯的是这套打法往相邻场景外溢：数据分析、测试运维、自动化报表，这些场景同样满足「产出可机器验证」的特征。作为 PM 要记住一条规律：Agent 落地的先后顺序，基本就是「结果能否自动验证」的顺序。能跑测试的代码最先被接管，能校验数字的报表其次，纯文字判断的活儿最慢。
这个方向还有个容易被忽略的点：编程 Agent 已经把计费模式跑出来了。Cursor 是按订阅加用量混合收费，企业版按席位，背后是「省了多少开发者时间」这笔账客户自己会算。后续每个垂直 Agent 都得回答同样的问题——按什么收费、客户怎么感知价值。按席位、按任务量、按效果分成，三种模式 2026 年会分出高下，PM 选方向时最好连计费模式一起想清楚，这直接决定产品要留什么数据、做什么报表给客户看。
值得关注的方向二：Agent 之间的协作协议
单个 Agent 能力有限，行业共识是走向多 Agent 协作。MCP 协议（Anthropic 推的模型上下文协议）在 2025 年快速普及，阿里、字节、百度都接入了，它解决的是 Agent 调工具、读数据的标准化问题；再往上是 Agent 之间互相调用的协议层。对 PM 来说这意味着产品设计单位变了：以前设计一个功能，现在设计「一个 Agent 暴露什么能力、消费什么能力」。扣子（Coze）、阿里百炼、钉钉 AI 助理这些平台押的就是这个生态位。做平台型 Agent 产品的 PM，要多懂 API 设计和开发者体验，这跟传统 C 端产品很不一样。给想做这个方向的 PM 一个具体建议：去把主流平台的 Agent 编排功能亲手搭一遍，踩过「工具描述写不好 Agent 就调错」这类坑之后，你对协议层的理解会实在得多。
值得关注的方向三：Agent 的「上岗管理」
企业用 Agent，最怕的不是它不干，是它乱干。所以围绕 Agent 的治理层正在变成一个真市场：权限控制（Agent 能操作哪些系统）、预算和成本控制（一次任务烧多少 token 要设上限）、行为审计（每个动作可追溯）、效果评估（任务成功率、人工接管率）。我认识的企业里，用 Agent 最深的都在自建这套「数字员工管理后台」。这个方向不性感，但类似当年云计算起来之后的运维监控市场，是确定性需求。企业为 Agent 付的钱里，治理层的占比会持续上升。
PM 怎么判断一个 Agent 方向靠不靠谱
我自己用四个问题筛：第一，任务结果能不能自动或低成本验证？不能验证就要堆人工审核，经济性马上崩。第二，单次任务的成本和人工比有没有数量级优势？跑一次 Agent 花五块钱 token，替代十块钱的人工，这生意做不大。第三，失败了有没有体面的降级路径？好产品是 Agent 干到 80% 交给人，烂产品是 Agent 干崩了甩给人。第四，用户使用频次够不够？一个月用一次的 Agent 养不出使用习惯和数据飞轮。四个问题过下来，大部分「Agent 创意」都会被毙掉，这很正常——赛道热的时候，会毙需求比会想需求值钱。