AI Agent 创业下半场：别再卖“智能”，开始交付结果

ReelOS.AI 禅定｜一句话看懂本文

2026 年真正值得做的，不是更多 Agent，而是能够稳定接管一段工作、对结果负责的数字劳动力系统。

模型越来越强。
Agent 开始从回答问题走向执行任务。
但能够执行，不等于能够稳定完成。
企业真正购买的不是“智能感”，而是结果、责任和确定性。
所以，Agent 创业的产品单位应是“可验收的工作”，而不是“更聪明的聊天窗口”。

AI Agent 创业三层机会地图：结果层、执行层、信任层与 90 天验证闭环 — 真正的产品不是模型或聊天窗口，而是一段能够稳定交付、验收和追责的工作。

导读：Agent 市场正在同时加速与淘汰

2026 年，Agent 市场正在发生两件看似矛盾的事。

一方面，Gartner 预测，到 2026 年，最多 40% 的企业应用将集成任务型 Agent，而 2025 年这一比例还不到 5%。

另一方面，Gartner 同样预测，超过 40% 的 Agentic AI 项目可能在 2027 年底前被取消，主要原因包括成本失控、商业价值不清晰和风险治理不足。

这不是 Agent 市场降温。

恰恰相反，这说明 Agent 正在从演示阶段进入生产阶段。

演示阶段比谁更聪明，生产阶段比谁更可靠。

真正的创业机会，不在于再做一个会调用模型、操作工具和自动规划的 Agent，而在于回答四个更难的问题：

它究竟替客户完成哪一段工作？
什么状态才算真正完成？
失败以后如何发现、恢复和追责？
客户为什么愿意持续为这个结果付费？

Agent 创业的下半场，不是模型能力竞争，而是工作系统竞争。

一、先纠正一个误区：六个热门方向并不是同一层级

市场上经常把以下方向并列讨论：

垂直行业 Agent
AI-Native Agency
Coding Agent
Computer Use
语音 Agent
Agent 基础设施

但它们并不是六个平行赛道。

方向	实际属性	回答的问题
垂直后台 Agent	目标市场	为哪个行业、岗位或流程工作
AI-Native Agency	交付模式	卖工具，还是直接出售结果
Coding / Knowledge Agent	工作类型	服务哪一种知识劳动
Computer Use	执行机制	如何操作没有 API 的系统
语音 Agent	交互与执行界面	如何通过实时对话完成业务
Agent Infra	技术与治理层	如何让 Agent 安全、稳定运行

因此，创业者真正需要回答的，不是：

六个方向里应该选哪一个？

而是：

选择哪一段工作，用什么方式执行，以什么结果计费，并通过什么系统保证可靠性？

这四个问题组合在一起，才构成一个完整的 Agent 产品。

二、Agent 创业正在从软件市场进入劳动市场

传统 SaaS 的核心逻辑，是帮助人提高效率。

用户购买软件以后，仍然需要自己完成工作。

Agent 带来的真正变化是：它不再只提供工具，而是开始接管一段完整工作流。

Y Combinator 在最新 Requests for Startups 中明确提出，过去一轮创业公司主要构建 Copilot，而下一阶段更重要的是 AI-Native Companies：它们不再只是出售软件，而是直接出售由 AI 完成的服务结果。

这意味着 Agent 公司竞争的不再只是软件预算。

它开始进入更大的三类预算：

企业人力预算
外包和专业服务预算
因处理缓慢、漏单和出错造成的业务损失

传统 SaaS 优化的是：

人如何使用软件。

垂直 Agent 优化的是：

这项工作是否还需要人从头做到尾。

Bessemer 在 Vertical AI 研究中指出，LLM-native 垂直应用正在进入传统 SaaS 无法覆盖的市场，包括大量语言密集、判断密集和服务密集型工作。

在其 2024 年研究样本中，达到一定规模的 Vertical AI 公司平均获得了约为传统垂直 SaaS 80% 的合同金额，年增长率约为 400%，平均毛利率约为 65%。这些是 Bessemer 投资组合样本，不代表所有公司都能达到同样水平，但足以说明：Vertical AI 已经不只是概念。相关数据可查看 Bessemer State of the Cloud 2024。

Vertical AI 之所以可能比 Vertical SaaS 更大，不是因为界面更智能，而是因为它开始进入劳动力预算。

三、真正值得押注的，是三层机会

第一层：结果层——直接接管一段业务工作

这是目前商业确定性最高的一层。

典型方向包括：

行业	更适合切入的工作
律所	客户 intake、材料整理、案件跟进
医疗机构	排班、计费、保险核验
保险	理赔分流、材料补齐、状态跟进
物流	异常运单处理、对账、承运商沟通
制造	采购询价、工单处理、备件管理
跨境电商	合规、Listing、本地化、退货处理

这些方向的共同点，不是“行业足够传统”，而是具备四个条件：

1. 已经有人在持续执行

存在真实工作人员，意味着需求不是被 AI 创造出来的，预算也已经存在。

2. 输出结果可以验收

例如：

资料是否补齐
订单是否录入
预约是否成功
理赔是否进入下一状态
异常工单是否关闭

结果越容易验证，越适合 Agent 化。

3. 工作高频重复

每周只发生一次的任务，即使能自动化，也未必值得建立一家公司。

真正有价值的是每日、每周大量重复，又不得不由人处理的流程。

4. 存在大量例外

规则完全固定的工作，传统软件和 RPA 已经能够解决。

Agent 的价值，主要出现在输入不标准、需要理解语言、需要跨系统判断，并且存在一定例外的工作里。

因此，后台和支持型工作，往往比行业最核心的专业判断更适合作为创业入口。

让 AI 完全替代律师、医生或财务负责人，责任风险和组织阻力都很大；让它先整理材料、追踪进度、发现遗漏、核对信息，ROI 更容易计算。

创业公司应先进入工作流，再逐步扩大 Agent 的决策权。

而不是第一天就宣称替代一个完整职业。

第二层：执行层——让 Agent 真正进入业务系统

Computer Use、语音、邮件、浏览器操作和 API 调用，本质上都是执行方式，不是独立商业模式。

“我们做 Computer Use”并不能解释客户为什么付钱。

更完整的产品表达应该是：

帮助物流公司自动登录承运商门户，发现异常运单，补齐材料，并将结果更新到内部系统。

而不是：

我们的 Agent 可以像人一样操作浏览器。

Computer Use 的机会确实存在，因为大量银行门户、政务系统、医院 HIS、老旧 ERP 和行业软件不会迅速提供完善 API。

但它的真正壁垒不是“能够点击按钮”，而是：

页面变化后的适应能力
身份和权限管理
重复操作防护
失败恢复
人工审批
操作日志
安全边界

浏览器 Agent 还面临网页内容中的提示词注入风险。Anthropic 的研究表明，恶意网页内容可能诱导 Agent 执行错误操作，因此浏览器自动化必须同时建设安全策略、工具权限和风险识别能力。详见 Mitigating the Risk of Prompt Injections in Browser Use。

Computer Use 不是下一代鼠标，而是下一代不确定流程执行引擎。

第三层：信任层——为 Agent 建设生产基础设施

当 Agent 开始获得写权限、支付权限和外部通信能力，企业购买的就不再只是模型能力。

企业还需要：

Agent 身份
最小权限
状态与记忆
安全运行环境
任务恢复
日志和审计
质量评测
人工审批
成本与资源限制
事故响应

这也是 Agent Infra 真正值得做的部分。

Agent 身份正在成为企业 IT 的新对象

Microsoft Entra已经将 agentic identities 纳入身份与访问管理体系，强调对员工、客户、工作负载和 Agent 身份实施统一但有差异的访问控制。

这意味着未来企业不仅需要管理员工账号，还要管理：

哪个 Agent 可以访问哪些数据
Agent 代表谁执行操作
Agent 可以调用哪些工具
权限何时过期
出错以后如何定位责任

没有独立身份的 Agent，本质上是在借用人的账号裸奔。

Agent 之间需要新的互操作协议

Google 推出的 Agent2Agent Protocol试图解决不同平台、框架和供应商的 Agent 之间如何发现能力、交换信息和协调任务的问题。

2025 年 6 月，Google 又将 A2A 项目捐赠给 Linux Foundation，以推动厂商中立的治理和生态协作。详见 Google Cloud Donates A2A to Linux Foundation。

但这并不意味着“再做一个通用 Agent 框架”就有机会。

横向框架很容易被模型厂商、云厂商和开源社区吸收。

基础设施创业必须切进一个足够深的问题，例如：

高风险业务的权限治理
长任务状态恢复
Agent 回归评测
浏览器任务稳定执行
私有环境下的运行与审计
跨 Agent 的计量与结算

卖基础设施，不能只卖技术先进性，要卖生产事故减少了多少。

四、语音 Agent：声音不是产品，业务闭环才是产品

语音客服已经非常拥挤，但语音 Agent 仍然存在机会。

机会不在于“声音更像真人”，而在于：

预约是否真正写入系统
催收是否完成支付
售后问题是否解决
工单是否关闭
复杂问题是否带着完整上下文转给人工

OpenAI 在 gpt-realtime 与 Realtime API 更新中，重点增加了远程 MCP、图像输入、SIP 电话连接和更可靠的工具调用能力，而不仅是提升声音自然度。

其官方 Voice Agents Guide也明确将语音系统放在完整 Agent 工作流中设计，而不是把语音模型视为独立产品。

因此，语音 Agent 的产品结构应该是：

实时对话
→ 识别客户意图
→ 查询业务状态
→ 调用内部工具
→ 完成业务操作
→ 验证结果
→ 必要时转人工

模态只是入口，闭环才是产品。

缺少业务系统集成的语音 Agent，最终只会成为成本更高的语音聊天机器人。

五、Agent 真正的护城河，不是模型，而是“例外”

模型会越来越强，也会越来越便宜。

单纯依赖某个模型能力形成的优势，很难长期存在。

Agent 产品更持久的壁垒，可以表示为：

Agent 护城河
=
工作流控制权
× 例外处理能力
× 系统集成深度
× 治理与信任
× 获客与分发

1. 工作流控制权

仅仅生成一段文本，通常只是功能。

能够读取上游信息、完成判断、执行操作、更新下游系统并通知相关人员，才是在控制工作流。

产品应覆盖一段完整的状态变化，而不是增加一个 AI 按钮。

2. 例外处理能力

标准流程很容易复制。

真正困难的是：

材料缺失怎么办？
两个系统的数据冲突怎么办？
客户临时改变要求怎么办？
外部系统不可用怎么办？
低置信度时交给谁？
重复执行以后如何撤销？
任务执行到一半如何恢复？

例外不是产品开发中的噪音。

例外是行业知识的压缩包。

每一次人工介入，都应该被记录为：

新场景
新策略
新规则
新评测用例
新的产品边界

因此，“先服务、后产品”不是落后的做法。

人工服务阶段最大的价值，是获得真实任务、失败样本、例外分布和验收标准。

Bessemer 的 Vertical AI 早期创业指南也强调，垂直 AI 创业需要深入理解用户工作流，并从真实客户部署中建立产品优势。

3. 系统集成深度

一个 Agent 越接近业务结果，越需要进入真实系统：

邮件
Excel
CRM
ERP
工单系统
支付系统
企业微信或钉钉
行业门户
内部数据库

集成数量并不是核心指标。

关键不是连接了多少工具，而是有没有完成一条不可中断的业务链路。

4. 治理与信任

对于企业客户，权限、审计和恢复能力不是高级功能。

它们是采购门票。

Gartner 在 2026 年 Agent 治理研究中预测，到 2027 年，40% 的企业可能因为生产事故暴露出的治理缺口，降级或停用自主 Agent。

Agent 产品不能只有“自动”和“不自动”两个状态。

更合理的结构是：

只读观察
→ 提供建议
→ 审批后执行
→ 有限范围自主执行
→ 特定条件下升级给人

Anthropic 对实际 Agent 使用的研究也发现，成熟用户并不是简单地取消监督，而是从“逐次审批”转向“持续监控并在必要时介入”。详见 Measuring AI Agent Autonomy in Practice。

Human-in-the-loop 不是 Agent 失败，而是风险边界设计。

六、结果定价是趋势，但不能只喊“按效果付费”

Agent 从辅助工具变成工作执行者以后，传统的 seat 定价会越来越难解释。

一个能够减少人工工时、提高回款率或者缩短处理时间的产品，更适合围绕业务价值收费。

定价方式	适合场景	主要风险
按任务量	文档、通话、工单	容易鼓励数量而非质量
按完成结果	预约、理赔、问题解决	厂商承担失败和成本波动
按替代人力	稳定后台流程	需要长期证明人效
订阅＋用量	企业工作流	容易理解、便于预算
基础费＋结果费	高价值业务	归因和合同复杂

Bessemer 的 AI Pricing and Monetization Playbook认为，AI 产品正在从按访问权限收费，转向按工作量和结果收费，因为 Agent 更像完成工作的同事，而不只是辅助工具。

但这里有一个经常被忽视的问题：

卖结果，不等于天然拥有软件毛利。

Agent 公司需要承担：

模型推理成本
第三方工具成本
失败重试成本
人工审核成本
实施和集成成本
客户支持成本
退款与责任成本

因此，真正应该计算的是：

单个成功结果贡献毛利
=
结果收入
－ 模型与算力成本
－ 第三方工具成本
－ 人工审核成本
－ 失败与返工成本
－ 实施和支持成本

当创始人的人工时间没有被计算进去时，很多所谓的高毛利 Agent，实际上只是隐藏了服务成本。

七、不要再用 Demo 指标管理 Agent 产品

传统 AI 产品经常关注：

回答看起来是否聪明
Benchmark 得分
工具调用次数
用户发送了多少消息
Agent 自主运行了多久

但这些指标都不能证明工作已经完成。

Anthropic 在 Demystifying Evals for AI Agents中区分了 Transcript 和 Outcome：Transcript 是 Agent 的执行过程，Outcome 是任务结束后外部环境的真实状态。

例如，一个订票 Agent 可以在对话中声称：

已经为您预订成功。

但真正需要验证的是：

订单数据库中是否存在一张有效机票。

因此，Agent 产品应该从“输出评价”转向“环境状态验证”。

Demo 指标	生产指标
Agent 是否给出答案	业务状态是否真正改变
工具调用成功率	端到端任务完成率
自主运行时长	可验证结果率
对话满意度	错误率与返工率
单次模型成本	每个成功结果的完整成本
是否需要人工	人工是否在正确节点介入

推荐重点跟踪五个指标：

1. Verified Outcome Rate

被系统或客户验证为真正完成的任务，占全部已接受任务的比例。

2. Human Intervention Rate

需要人工接管的任务比例，以及人工介入发生在哪个节点。

3. Exception Coverage

已知例外中，有多少已经被规则、策略或评测集覆盖。

4. Cost per Successful Outcome

不是运行一次花多少钱，而是完成一个有效结果花多少钱。

5. Recovery Time

任务失败以后，系统重试、恢复或移交给人工需要多长时间。

Agent 产品的北极星指标，不应是自主程度，而应是受控条件下的可靠完成。

八、如何判断一个 Agent 创业方向是否值得做

可以使用以下六个问题进行初步筛选，每项按照 0—2 分计算。

判断问题	0 分	1 分	2 分
是否已经有人为工作付费	没有预算	存在隐性成本	有明确人力或外包预算
结果是否可以验收	完全主观	部分可验证	有明确完成状态
工作是否高频	偶发	每月发生	每日或每周大量发生
是否可以进入现有系统	无数据和权限	依赖人工导入	可连接或可操作
例外是否具有重复性	完全随机	部分有规律	可分类、可积累
ROI 是否容易证明	软价值	间接效率	直接增收、降本或避险

评分建议：

10—12 分： 值得快速进行付费验证
7—9 分： 可以尝试，但需要进一步缩小场景
4—6 分： 更可能是一个功能，而不是一家公司
0—3 分： 大概率只有演示价值

最重要的是两个问题：

客户现在是否已经在为这项工作付钱？

以及：

你能否明确证明这项工作已经完成？

缺少第一个问题，意味着没有真实预算。

缺少第二个问题，意味着无法形成稳定产品和结果定价。

九、90 天不要先造平台，先跑通一条劳动闭环

第 1—15 天：建立“人力账本”

不要先列功能。

先跟随真实工作人员完成任务，记录：

输入来自哪里
每一步由谁负责
每一步花费多少时间
最容易出现什么错误
谁判断最终是否完成
出错会造成什么损失
哪些情况必须升级给专业人员

最终产物不是 PRD，而是一张真实工作流和例外清单。

第 16—35 天：人工＋AI 交付三个付费客户

这一阶段可以非常手工。

目标不是证明 Agent 能完全自动化，而是证明：

客户愿意为结果付钱
交付结果可以被验收
多个客户之间存在共同流程
例外具有一定复用性

没有付费验证，不要急着产品化。

免费试用很容易获得赞美，却很难获得真实的采购反馈。

第 36—60 天：只自动化一个完整 Loop

不要一开始设计十个 Agent。

选择一条最频繁、最容易验收的闭环：

接收任务
→ 获取上下文
→ 执行操作
→ 验证结果
→ 失败重试或人工接管
→ 更新状态

Anthropic 在 Building Effective AI Agents中建议，优先采用简单、可组合的工作流，只在任务确实需要开放式决策时，才增加 Agent 的自主性和架构复杂度。

Multi-agent 是实现方式，不是产品价值。

第 61—90 天：固定 SKU 和单位经济模型

例如：

每月处理 500 份合同材料
每月解决 1,000 个售后工单
每月完成 300 次保险核验
每月跟进 2,000 条销售线索

同时计算：

每个结果的收入
模型和工具成本
人工接管时间
实施成本
失败与退款成本
毛利随客户规模的变化

90 天结束时，至少需要回答四个问题：

客户购买的是哪一个结果？

这个结果的验证完成率是多少？

每完成一次，真正能够赚多少钱？

第 10 个客户是否会比第 1 个客户更容易交付？

如果这四个问题仍然答不清楚，就不应该继续扩建平台。

十、2026 年不建议继续投入的五类方向

1. 通用 Agent 平台

模型厂商、云厂商和开源社区都会持续提供编排、工具调用、记忆、运行环境和评测能力。

没有分发、数据或企业部署优势的横向平台，很容易被压缩成低利润工具层。

先拥有一个必须被解决的问题，而不是先建设一个什么都能做的平台。

2. 没有岗位定义的“AI 员工”

“销售员工”“运营员工”“财务员工”都太宽泛。

真正可交付的产品必须继续收缩为：

处理什么输入
完成什么动作
更新哪个系统
产生什么结果
由谁进行验收

岗位是市场语言，任务闭环才是产品语言。

3. 只包装 Prompt 的垂直 Agent

行业术语和 Prompt 可以快速复制。

真正的垂直产品必须拥有：

真实工作数据
行业工作流
系统连接
例外处理
评测体系
责任边界

4. 把 Multi-agent 当作核心卖点

客户不关心内部使用了一个 Agent 还是十个 Agent。

客户只关心：

是否完成
是否准确
是否安全
是否比人工划算
出错以后谁负责

架构复杂度必须服务于交付，而不是服务于融资故事。

5. 第一阶段就追求完全自治

在高风险场景中，过早追求完全自治，会同时增加错误风险、治理成本和采购阻力。

更可行的路径通常是：

观察
→ 建议
→ 审批后执行
→ 局部自治
→ 基于风险动态升级

自治程度应该随着生产证据提高，而不是随着市场宣传提高。

十一、若只押三个方向

方向一：极窄垂直工作系统

只服务一个岗位、一条流程或者一种结果。

这是最容易建立现金流、行业数据和客户关系的方向。

先成为某项工作的默认执行者，而不是某个行业的通用平台。

方向二：AI-Native 服务，再逐步产品化

先出售结果，获得客户、流程和数据，再把高频交付步骤逐步自动化。

这不是“先做外包”。

它是在用服务完成产品发现。

但每一次人工交付，都必须沉淀成：

标准流程
例外分类
产品规则
自动化策略
评测数据

否则，公司只会停留在传统人力服务。

方向三：Agent 信任基础设施的一个深切片

可以从以下方向选择一个做透：

权限与身份
状态与恢复
评测与质量门禁
安全执行环境
成本与资源控制
Agent 间通信与结算

基础设施机会很大，但必须绑定真实生产问题。

不要做“所有 Agent 可能都需要”的功能，要做“某类 Agent 上线前必须解决”的问题。

结语：Agent 公司不是一种新的聊天软件公司

Agent 创业最容易产生的幻觉，是把模型能力误认为产品能力。

模型会推理，不代表任务完成。

Agent 会调用工具，不代表业务闭环成立。

Demo 可以连续运行，不代表生产系统可以被信任。

真正的 Agent 公司，实际上同时经营三种能力：

软件公司的自动化能力
+
服务公司的交付能力
+
风险控制公司的治理能力

它需要理解行业、控制流程、承担结果、管理例外、计算成本，并在失败时完成恢复与追责。

因此，2026 年 Agent 创业最重要的问题不是：

哪一个 Agent 方向最热门？

而是：

哪一段已经有人付钱完成的工作，可以被你重新定义、稳定交付，并随着每一次例外变得更强？

先拥有工作，再自动化工作。

先证明结果，再建设平台。

先建立责任边界，再提高自治程度。

Agent 创业的终局，不是制造更多“智能体”。

而是把一段原本依赖人力、经验和协调的工作，变成一套可验收、可恢复、可复制的数字生产系统。