# 从一堆 Agent 演示日志说起：为什么说‘套壳 Agent 就能做 SaaS’是个荒谬的幻想

Source: https://blog.ferstar.org/posts/the-illusion-of-agent-saas/





昨天在翻内部某款桌面端 Agent 研发版本的一批演示日志。从 PPT 生成、跨部门清单，到复杂的财务现金流测算与销售合同合规检查，演示用例排得很满。

单看表面输出，效果确实挑不出大毛病：能分析合同风险、能算现金流拐点、能用 Python 跑脚本渲染深色科技蓝的内嵌 SVG 和单文件 HTML，甚至离线双击就能打开。

但顺着底层的调用链路、Token 消耗和执行状态查下去，工程上的违和感非常重。

现在圈子里无论是客户、老板还是部分做产品的，都在蔓延一种既偷懒又危险的想法：**“以前做套 CRM、ERP 或审批流要理几十张表、写半年代码；现在只要给大模型套个 Agent 的壳，挂几个工具和脚本，‘一句话自动搞定所有业务’，这不就是一个现成的新一代 AI-Native SaaS 吗？”**

把啥业务都想往 Agent 这个壳里塞，以为这样就能轻轻松松做出一个企业级 SaaS。结合实际运行的日志，以及现场复盘扒出来的一堆环境和链路问题，这种想法不仅不切实际，甚至有点反工程常识。

---

## 一、惊艳 Demo 背后真实的工程狼狈

翻看昨天的 9 个 Demo 会话，那些能跑出“惊艳效果”的场景，背后几乎全踩在工程临界点上：

### 1. 极度脆弱的确定性：全靠保姆式 Prompt 吊着一口气
在“财务现金流跟踪”和“跨部门行动清单”这类硬核业务 Demo 里，首轮 Prompt 根本不是普通用户写得出来的，而是长达三五百字、写满了防御性限制的“小合同”：

> “区分已确认回款和预计回款……不要编造回款日或审批结果……原始文件不要覆盖……负责人和截止时间仅使用材料中有明确承诺的信息，没有的标记‘待确认’……”

这不是什么智能交互，这是技术人员提前把系统里缺失的防御逻辑，人肉写进了 Prompt 里。
今天换成真实用户的常规输入（比如日志里随手敲的一句：“*我需要先优化你的工作逻辑*”），模型当场抓瞎，反手弹出好几个确认框找用户要上下文。

脱离了这种全天候保姆式的 Prompt 喂饭，Agent 在业务上的可靠性会直接断崖式下跌。

### 2. 本地特权与环境隔离的撕扯
为什么那几个 Demo 看着很能打？因为它是跑在本地桌面特权环境下的：
- 本地读写用户的 `.xlsx`、`.docx`、`.pptx`；
- 调本地 Python runtime 就地跑脚本处理数据、动态生成自包含页面；
- 本地直接看渲染结果。

但这套环境在工程上脆弱得很：宿主机环境稍微带点脏变量（比如用户系统里的特定 Python 版本或虚拟环境），就能把内置的 Skill 执行环境当场冲垮；测试把文件往工作区外写了一步，沙箱立刻报错；前端界面刚提示完定时任务“创建成功”，后端连外部消息通道到底通不通压根都没做验证。

真实业务的数据和网络全在本地或内网。一旦幻想把它搬到云端多租户的 SaaS 环境下，网络隔离、环境兼容、文件权限、数据隐私和跨系统授权，会瞬间把这套脆弱的执行链路彻底卡死。

### 3. “面子工程”与业务核心的倒挂
日志里反复出现这类指令：“*换个科技蓝配色*”、“*自包含纯内联 SVG，无外部依赖*”、“*换一个科技蓝背景的展示吧*”。

为了在演示时抓人眼球，Agent 需要通读原文件、写一段 Python 脚本做样式替换、再次验证、再重新输出。
单单是给界面换个主题，单轮上下文就拉到了 **13.8 万 tokens**（输入 13.7 万，输出几百字）。虽然我们在 Harness Engineering 上做了大量工程打磨，前缀缓存（Prompt Cache）命中率能稳在 99%+，实际推理延迟和成本基本被兜住了，但这种交互模式本身暴露了核心矛盾：底层业务逻辑半点没变，系统的吞吐负荷却全耗在了这些“为了看起来炫酷”的样式修饰上。

---

## 二、为什么“把一切装进 Agent 就能成 SaaS”是空中楼阁？

传统软件架构与所谓“纯 Agent 架构”有着根本性的范式冲突：

```mermaid
flowchart TD
    subgraph SaaS["传统 SaaS 系统 (确定性中枢)"]
        DB[(关系型数据库 / ACID)] --> Core[状态机 & 业务规则引擎]
        Core --> Auth[RBAC 权限 & 审计追踪]
        Auth --> UI[标准化交互界面]
    end

    subgraph AgentTrap["幻想中的 Agent SaaS (概率黑盒)"]
        Prompt[用户模糊输入] --> LLM{大模型推理}
        LLM -.->|概率判定| Script[临时 Python / 工具脚本]
        Script -.->|易漂移| Out[不可预测的文本/草稿]
    end
```

### 1. 把确定性的业务规则甩给大模型去猜，纯属偷懒
做企业系统最费劲、最繁琐的，本来就是把业务规则和数据流转一条条理清楚：
- 钱从 A 账户进 B 账户，必须走完双向记账、事务一致性检查和审计留痕；
- 审批矩阵对应严格的岗位层级，达到阈值必须且只能由特定角色放行。

很多喊着要搞“Agent SaaS”的人，本质上就是不想干这些苦力活，妄图把这些全跳过去，让大模型看着上下文去“猜”下一步该干嘛。
但大模型的底层是**概率机器**。一个连“下周三到底能收回多少钱”都需要写几百字 Prompt 预防幻觉的系统，根本提供不了最基础的事务隔离（ACID）和数据一致性。拿流沙当地基，上面盖再多层也是危房。

### 2. 混淆了“操作员（Operator）”与“业务中枢（System）”
Agent 的真正优势在于作为一个**灵活的操作员**：
- 擅长从非结构化的邮件和杂乱表格里抓取信息；
- 擅长把两个不同格式的中间数据整理成草稿；
- 擅长根据指令把报表换一套深色主题样式。

但操作员绝不等于业务系统本身。一个打字极快、善于整理档案的优秀行政助理，并不等同于跨国集团的 ERP 核心。
如果一个系统连数据底座、权限引擎和审计流都没有，只凭一个对话框调度几把工具，就声称自己做出了一个 SaaS，这无疑是把皮毛当成了骨髓。

### 3. 商业模型层面的“成本与责任倒挂”
这是所有宣称要让 Agent SaaS 化的团队无法回避的死穴：

| 维度 | 传统 SaaS | 幻想中的 Agent SaaS |
| :--- | :--- | :--- |
| **边际成本** | 几乎为 0（固定服务器开销，单次请求毫秒级且极廉价） | 极高（每次复杂交互消耗数万至数十万 Token） |
| **计费与预期** | 固定的按年/按人头订阅，客户预算可预测 | 随复杂度激增的算力黑洞，按 Token 算客户怕，包年算厂商亏 |
| **责任边界** | 确定性执行，系统对状态流转和历史审计负责 | “仅供参考，不承担责任，请人工复核”，无法真正放手 |
| **最终交付物** | 实际业务状态变更（入账、签约、发货已生效） | 分析、建议、草稿、预览文件（Draft / Preview） |

看各类严肃 Agent 的底层系统约束文件可以发现，末尾无一例外都会包含一条冷酷的边界条款：
> “*除非存在明确授权与用户确认，下列动作必须停在 draft/preview：不得执行付款、不得正式核销、不得替公司决定签约……*”

既然最终风险无法闭环、不能赋予独立决策权、每一步都得人工逐行复核，它就永远不可能独立成为接管企业核心运转的无人值守 SaaS。

---

## 三、结语：放下万能幻觉，回归工具本质

更讽刺的是现场的落差：为了这次演示，台下排练、防御、调样式花了大把力气，原本计划半小时的 Demo，最后因为各种前置拖延和意外耽误，被极致压缩到了 10 分钟左右，在兵荒马乱中草草收场。

台下准备得再花哨、Prompt 垫得再厚，真到了交付和现场的真实世界里，不确定性永远会给虚妄的预期一记耳光。

想借着 Agent 的外壳，轻轻松松把复杂的业务逻辑糊弄进去当 SaaS 卖，不过是技术泡沫期特有的投机幻觉。

这并不意味着 Agent 没有价值。相反，当它剥离掉“颠覆一切系统”的狂妄定位后，其价值反而极其清晰：
- 它不应该替代数据库和业务中枢，而应该作为**人与复杂系统之间的高效连接器**；
- 它更适合以**桌面端辅助工具（Desktop Copilot）**的形式，老老实实呆在离用户最近的最后一公里，帮人处理脏数据、草拟文档、做探索性分析；
- 把确定性的事情留给代码和数据库，把灵活的语言理解与临时操作交给 Agent。

承认大模型的边界，老老实实啃下那些看似枯燥的业务建模与工程基建，远比整天幻想着拿一个 Agent 壳去“重新发明 SaaS”要体面得多。