摘要:Agent 不会凭空替代企业数据、权限和交易系统,它首先改写的是人通过 UI 串联多个系统的路径。本文从 System of Record、Capability Layer、Job Agent 三层结构出发,讨论 Headless、MCP、最小权限和状态回读的工程边界。
"Agent 会不会杀死 SaaS"听起来像产品经理和投资人会吵一晚的问题。对开发者更实用的问法是:当调用者从人变成 Agent,软件的哪些层还必须存在?
Salesforce 8 月 26 日公布的 FY27 Q2 数据里,订阅和支持收入仍同比增长 12%。一季财报不能证明 SaaS 整体安全,但它至少说明 Agent 增长与软件订阅增长可以同时发生。
Headless 360 给出的架构信号更直接:应用内的数据、身份、权限、元数据、工作流和业务逻辑不被扔掉,而是包装成授权 Agent 可发现、可调用的能力。

从 UI-first 变成 capability-first
过去的软件调用链通常是:
text
Human → UI → Application Service → Data
Agent 时代会多一条主路径:
text
Goal → Job Agent → Capability → Application Service → Data
↓
Human Review
这不是绕开 SaaS,而是把 UI 从唯一入口降为多个入口之一。
三层结构
System of Record
负责事实和状态:客户、订单、内容、文件、权限、审计记录。这里需要稳定 ID、幂等、事务、版本和可追溯性。
Capability Layer
它不是把所有 REST endpoint 原样丢给模型,而是把业务动作包装成有语义的受控能力:
ts
type Capability = {
name: string
inputSchema: JSONSchema
permission: string
idempotencyKey?: string
risk: 'read' | 'reversible-write' | 'irreversible'
requiresApproval: boolean
}
MCP、API、Skill 和 computer use 都可以承载这一层。协议只是入口,真正决定能否生产使用的是权限、校验、可观测性、错误恢复和结果回读。
Job Agent
岗位 Agent 负责把目标拆成能力调用,维护任务状态,遇到不确定性时升级给人。它不应拥有所有能力;发布助手不需要付款权限,数据分析助手也不需要删文章。

最先消失的是"人肉 RPC"
很多业务集成今天仍靠员工:从 A 复制字段,粘到 B,截屏发群,等一句"可以"再点提交。人实际上在充当跨系统 RPC、格式转换器和重试队列。
Agent 适合替代的是这些确定性接力,不是所有判断。一个较稳的状态机可以是:
text
prepared → prefilled → reviewed → submitted → verified
↑ ↓
human gate state readback
如果系统只记录 button_clicked=true,那不是交付状态。必须回读目标系统的作品 ID、审核状态或交易记录。
UI 为什么还会留下
UI 会从主路径变成四种控制面:
- 配置身份、权限和业务规则;
- 处理低频异常与复杂编辑;
- 展示执行轨迹和审计记录;
- 让人完成高风险确认。
完全无界面的 Agent 系统,一旦失败,常常连"它现在卡在哪"都很难说明。
SaaS 的风险不在订阅,而在价值过薄
如果一个产品主要价值是几张表单和数据搬运,而数据没有粘性、规则不复杂、导出也很容易,Agent 会压低它的界面溢价。
如果产品承载可信记录、权限体系、行业流程和交易,它更可能成为 Agent 的能力底座。竞争重点从"页面是否好点"转向"能力是否可发现、可授权、可复用、可审计"。
小团队怎么迁移
不必先建一套宏大中台。挑一条重复链:
- 找出唯一事实来源;
- 把动作按风险分级;
- 只给岗位 Agent 必需能力;
- 在不可逆动作前加人工闸门;
- 保存每一步状态和错误;
- 最终回读目标系统。
我们在 Tipkay 里采取的也是"连接现有系统"而不是"重建所有系统":岗位 AI 员工各自配置流程、Skill 与 MCP,平台登录态和本地素材留在客户端,公开发布由用户确认。产品关系需要说清楚------这并不意味着任何流程都能自动化,也不保证业务结果;它只是把可重复的人肉接力交给受限岗位。
Agent 时代并不是 SaaS 和 Agent 二选一。更可能出现的新分工是:SaaS 保存可信状态,能力层开放动作,岗位 Agent 组织交付,人负责目标、例外和责任。
参考: