如果你只是把 AaaS（Agent as a Service，即“代理即服务”）理解为“带有集成 AI Agent 的 SaaS”，那你就错过了更大的图景。
SaaS 是为人完成任务的软件。用户登录、操作界面、输入数据、验证、审批、产出成果。SaaS 的进化是为了让这一系列操作更高效。
随着 Agent 的成熟，产品的基本前提正在改变。
用户不再是使用工具来执行工作，而是将工作交给 Agent。Agent 读取信息、收集决策材料、创建草稿，并进行必要的处理。人类则从执行所有工作，转变为审查异常、做出判断和提供审批。
SaaS 提供了执行工作的功能。
AaaS 提供的是工作的完成。
软件的可达市场正在扩大
当 AI Agent 进化到足够成熟时，产品开发中的问题就会从“我们如何让人类的工作更高效？”转变为“我们能把这个工作委托给 Agent 吗？”
这里被替代的不仅仅是现有的 SaaS 功能。它包括内部运营、以前外包的任务、委托给 BPO 的流程、由顾问或 SIer（系统集成商）处理的上游和执行工作，以及初级专业工作。
因此，如果仅用 SaaS 预算来衡量，AaaS 的市场看起来很小。我们应该看的是企业为完成工作所支付的预算：劳动力成本、外包费用、BPO 费用、咨询费、SI 费用和运营成本。AaaS 正在进入的是劳动力和服务市场，而不仅仅是软件市场。
当前运营流程是起点，而非蓝图
在思考 AaaS 时，仅仅用 AI 去追踪现有的运营流程是不够的。
许多 AI 的实施都是基于当前的业务流程：人类看到的界面、人类更新的 Excel 文件、人类运行的审批流程、以及人类创建的报告。他们试图用 AI 来缩短其中的一部分。
当然，这有其价值。然而，如果你假设有一个 Agent 的存在，那么有些步骤根本没必要保留。
当前的业务流程仅仅是观察对象。从中应该读取的不是界面或程序，而是业务试图达成的“完成状态”。
处理客户问询的目的不是为了通过聊天回复，而是为了解决客户的问题。
图纸分析 AI 的目的不是为了读取图纸，而是为了推动估算、图纸检查、变更影响分析和订购准备等任务。
需求定义 AI 的目的不是为了生成需求定义文档，而是为了收集现场问题、用原型验证、明确应该构建什么，并创建准备订购的状态。
AaaS 的设计需要从工作的完成状态反向推算，而不是对现有运营流程的复制。
以工作为单位思考，而非功能
在传统 SaaS 中，产品通常按功能单元设计：搜索、输入、审批、通知、报告和仪表盘。这些功能组合起来，使人类更容易执行工作。
在 AaaS 中，首先要定义工作的单元。
一次问询。一次估价请求。一套图纸。一次合同评审。一个需求定义项目。一次 RFP 响应。一次会计处理。一次候选人互动。
Agent 按这些单元接收工作，并一直进行到完成。
这里绝不能含糊不清的是完成条件。需要满足什么条件，才能说这项工作完成了？
对于一次问询，意味着客户的问题得到解决，并且必要的流程已完成。对于一次估价，意味着已创建可提交的估价，并验证了理由和风险。对于一次图纸审查，意味着关键点已被提取，分配给负责人，并保留了审批日志。对于需求定义，意味着现场验证过的原型、业务需求、功能需求、RFP 和验收标准都已准备就绪。
仅仅“支持”工作，并不能成为 AaaS。
只有当你定义了什么是“完成”，你才能将工作委托给 Agent。
人机协同（Human-in-the-loop）是建立信任的设计
Agent 不需要从一开始就完全自主地执行一切。
在许多任务中，Agent 读取信息、分类、创建候选方案、草稿，并识别风险区域。人类则进行检查、必要时修改并进行审批。只有获批的项目才会被执行。
这并非一个由于 AI 不成熟而不得已让人参与的故事。这是一个让企业能够放心地将重要工作委托给 Agent 的信任设计。
在关键业务中，仅仅正确是不够的。为什么做出那个判断？谁批准的？有多少是自动执行的？出现故障时如何回滚？保留了什么日志？人类可以在哪里介入？
AaaS 需要证据展示、可靠性指标、操作日志、权限管理、审批流程、审计日志、升级处理、回滚机制、服务等级协议（SLA）以及清晰的责任边界。没有这些，企业无法将工作委托给 Agent。
UI 的角色也随之改变。传统 SaaS 提供人类工作的界面。AaaS 的 UI 则是用于将工作交给 Agent、检查工作计划、监督进度、审查高风险区域、处理异常以及提供最终审批。
它更像是一个操作 Agent 的“控制塔”，而不是一个工作区。
定价更贴近工作量和成果，而非用户数
在 AaaS 中，定价设计也在改变。
在传统 SaaS 中，按席位计费或按月收费是很自然的。然而，Agent 功能越强大，其人类用户数量可能越少。如果你以用户数量作为标准，客户价值和收费就会产生分歧。
在 AaaS 中，定价的标准更可能是“完成了多少工作”，而不是“有多少人使用”。这需要结合按交易计费、按完成计费、按效果计费、按使用量计费、管理服务费、成功费以及初始实施费等多种方案。
从该工作的当前成本反向推算价格，比从软件功能出发要自然得多。
该运营流程涉及多少人？外包成本是多少？BPO 费用是多少？出错时的损失是多少？延迟带来的机会损失是多少？
客户购买的不是 AI 本身。
他们购买的是更快、更便宜、更稳定完成的工作。
产品改进目标：自动完成率与毛利率
在 AaaS 中，产品改进指标也在改变。
在传统 SaaS 中，使用率、登录频率、席位数量和流失率很重要。虽然留存率在 AaaS 中仍然重要，但这还不够。
应该关注的是处理单个工作单元的经济性。
从每单位收入中减去模型/API 成本、人工审核成本、运营成本、异常处理成本和错误处理成本后，还剩多少毛利？
AaaS 的产品改进不仅仅是增加功能。还需要提高自动完成率、降低人工审核率、减少异常处理、稳定处理质量并提高单位毛利率。
客户能委托的工作范围扩大，Agent 的自主程度提高，单位经济效益改善。这种积累构成了 AaaS 产品的进化。
护城河建立在运营闭环中，而非模型本身
仅靠模型很难建立 AaaS 的竞争优势。
基础模型不断进化。许多功能会被模仿。LLM 包装器的差异化变得微乎其微。
真正能留存下来的是在执行工作的过程中所创造的闭环。
Agent 做工作。人类修正它。它被批准。结果作为记录返回。异常和失败被积累。从下一次开始，Agent 变得更好。
当这个闭环开始运转时，它就不再仅仅是一个 AI 功能。
积累下来的是输入数据、Agent 的初始输出、人类的修正、审批结果、客户特定的规则、行业特定的模板、交付物以及与实际结果的差异。由于这些与客户的业务场景紧密相连，因此很难被简单复制。
AaaS 的护城河不仅在于模型的智能，更在于持续执行工作中积累的业务智能。
思考 AaaS 所需提出的问题
如果你在设计 AaaS，首先问的不会是“我应该构建什么样的 AI 功能？”
你正在替代哪些人类任务、外包任务、BPO 任务或专业任务？工作的单位是什么？是一次问询、一套图纸、一次估价请求，还是一个需求定义项目？
为了完成那项工作，需要发生什么？那项工作当前的成本是多少？你正在替代哪个预算？Agent 需要什么输入才能开始工作？交付给客户的成果是什么？
Agent 在多大程度上自主执行，人类在哪些环节进行审查？你将如何构建证据、权限、审批、审计、SLA 和责任边界？你将按处理量、成果、使用量、月费、管理服务还是成功费来收费？每个被处理的单元是否都产生利润？随着使用，什么东西被积累起来，又如何实现改进？
任何无法回答这些问题的东西，可能仍然只是一个 AI 功能、一个带 AI 的 SaaS，或者 AI 承包，而不是真正的 AaaS。
总结
AaaS 不仅仅是 SaaS 的下一个功能。
这是一个软件从“工具”转变为“劳动力”的转变。
未来能够打造强大产品的公司，仅仅创造便捷的 AI 功能是不够的。他们需要定义客户可以放心委托的工作，创建一个让 Agent 执行工作、让人专注于异常和判断、并且能够根据结果和信任来收费的结构。
在 AaaS 中，要问的第一个问题很简单。
你的 Agent 将承担什么工作？
我相信，我们应该从这个问开始。
