传统 SaaS 执行产品团队预先定义的工作流。AI agent 则会在运行时选择部分步骤来实现目标。这项区别会改变权限、测试、接口、失败处理和单位成本。
许多产品同时包含两者。客服应用可以用普通代码验证客户身份并获取发票，再让 agent 调查含糊的账单问题。把整个产品笼统地称为 agent 应用，会掩盖工程师必须控制的边界。
工作流从哪里来
在 SaaS 中，产品编码了允许的路径。用户选择发票、点击退款、确认金额并收到结果。请求开始前，界面和后端已经知道所有可能状态。
agent 从目标出发，根据收到的上下文选择工具。两次运行可能因搜索结果、工具错误或模型选择不同而采用不同路径，但应用仍需通过硬规则限制允许的路径。
OpenAI 的构建 agent 实用指南建议将 agent 用于决策复杂、规则脆弱或包含大量非结构化数据的工作流。如果普通代码可以表达决策，固定工作流仍是更清晰的设计。
工程层面的区别
| 关注点 | 传统 SaaS | AI agent 应用 |
|---|---|---|
| 工作流 | 在代码中预先确定 | 在允许范围内于运行期间选择 |
| 接口 | 面向已知状态的页面和端点 | 目标、上下文、工具和生成的中间步骤 |
| 授权 | 用户操作映射到已知端点 | 每个选定工具和下游操作都需要授权 |
| 测试 | 已知输入对应预期输出 | 任务成功、工具选择、禁止操作和多次运行差异 |
| 失败 | 通常是在已知步骤显示错误 | 可能基于错误步骤或来源生成看似合理的回答 |
| 恢复 | 重试请求或显示错误 | 核对已完成影响，再从 checkpoint 恢复 |
| 成本 | 主要取决于请求和基础设施 | 还取决于 token、工具调用、重试和运行时长 |
| 可观测性 | 请求、服务和数据库链路追踪 | 再加上模型、工具、策略和评估记录 |
记忆、工具、状态和持久执行中的应用架构正是由这些区别推导而来。
首先改变的是权限设计
SaaS 按钮可以调用一个动作范围很窄的端点。agent 可能从二十个工具中选择，并按产品团队从未编写过的顺序组合。后端必须根据当前用户、租户和资源授权每次调用。system prompt 中的一句话不能授予或移除访问权限。
OWASP 关于过度代理权的指南将问题分为工具功能、权限和自主程度过度。这是一种实用的审查方式：移除工作流不需要的工具，缩小其余工具背后的凭据范围，并在高影响操作前要求审批。
测试变为行为测试
单元测试可以证明退款函数拒绝负数金额，却无法证明 agent 只会在用户要求退款时选择退款工具。因此，agent 评估需要具有代表性的任务、预期工具选择、禁止操作和重复运行。
只看输出并不够。即使回答正确，如果它读取了另一个租户的记录，仍是严重故障。AI agent 上线前评估指南同时介绍了任务断言和链路断言。
接口必须呈现不确定性
传统 SaaS 通常显示已支付、失败或待处理等已知状态。agent 可能面对证据不完整或来源冲突，产品需要显示它使用了哪些信息、哪里存在不确定性，以及下一步建议什么操作。
审批内容应包含确切影响。“继续”过于模糊；“为发票 1842 退款 $42.00”才能让审核者明确知道自己批准了什么。
哪些场景不适合 agent
如果规则稳定、输入结构化，而且正确操作可以直接编码，应保持确定性工作流。即使由 agent 调用，身份验证、配额执行、付款结算、权限检查和数据库约束也应放在普通代码中。
当杂乱上下文需要判断，并会改变工作顺序时再使用 agent。只给它一小组工具，让后端执行绝不能变化的规则。
为一条工作流画出边界
选择一条工作流，将每个步骤标为确定性代码、模型判断、人工审批或外部影响。如果模型步骤没有变化的理由，就将其移回代码。如果外部影响缺少明确身份和恢复路径，上线前先停下来修复。
下方提示词会让 coding agent 找出这条边界，同时避免它在思考过程中重构应用。