一批演示日志的笔记：为什么“把一切都包装成Agent来做SaaS”是荒谬的幻想
内容提要
文章通过分析桌面Agent演示日志指出，将一切功能塞进Agent并做成SaaS是荒谬幻想。演示的完美结果依赖数百字防御性提示词、本地特权环境和大量美化工程，极其脆弱。LLM作为概率引擎，无法提供ACID保证和审计追踪，且边际成本高、责任边界模糊。Agent应定位为人机认知桥梁和桌面助手，确定性业务须由数据库和规则引擎处理。
延伸解读
演示的完美依赖脆弱工程
文章指出，演示中Agent的出色表现依赖数百字防御性提示词、本地特权环境和大量美化工程。这些条件在真实业务中难以复现，一旦提示词不完整或环境变化，Agent可靠性骤降。因此，仅凭演示效果判断Agent可产品化是危险的。
LLM无法替代确定性系统
LLM本质是概率引擎，无法提供ACID保证和审计追踪。企业业务规则和状态转换需要数据库和规则引擎处理，试图让LLM猜测业务逻辑是偷懒。将确定性业务塞进Agent，如同在流沙上建城堡，结构必然失败。
经济与责任的结构矛盾
Agent SaaS边际成本极高，每次运行消耗数万token，计费波动大；责任边界模糊，输出仅作参考，需人工验证。传统SaaS边际成本近零，提供确定性和审计追踪。这种矛盾使Agent难以成为无人值守的企业级SaaS。
Agent应定位为认知桥梁
文章认为，Agent的真正价值在于作为人机认知桥梁和桌面助手，处理非结构化数据、生成草稿和探索性分析。确定性业务应交由数据库和规则引擎。承认模型边界，扎实做好数据建模和基础设施，比幻想Agent重塑企业软件更可信。
Q&A
为什么说把一切都包装成Agent来做SaaS是荒谬的幻想？
因为演示的完美结果依赖数百字防御性提示词、本地特权环境和大量美化工程，极其脆弱。LLM作为概率引擎，无法提供ACID保证和审计追踪，且边际成本高、责任边界模糊。Agent应定位为人机认知桥梁和桌面助手，确定性业务须由数据库和规则引擎处理。
桌面Agent演示中，完美的结果背后隐藏了哪些工程问题？
演示依赖300-500字的防御性提示词来维持确定性，否则Agent会瘫痪；运行在本地特权环境，存在环境隔离冲突；大量美化工程消耗资源，如一次换主题消耗13.8万token。这些使得演示极其脆弱。
为什么LLM不适合处理确定性业务规则？
LLM是概率引擎，无法提供ACID保证和数据一致性。确定性业务规则如复式记账、审批矩阵需要精确的状态转换和审计日志，而LLM只能基于对话上下文猜测，容易产生幻觉，导致系统不可靠。
Agent在SaaS中的合理定位是什么？
Agent应作为人机认知桥梁和桌面助手，擅长从杂乱数据中提取信号、合并中间数据、调整报告主题等灵活任务。确定性代码和关系数据库处理状态，Agent处理语言理解和临时编排。
将Agent包装成SaaS面临哪些经济与责任问题？
边际成本极高（每次运行消耗数万token），计费不可预测；责任边界模糊，输出仅作参考，不承担法律责任；最终交付物只是分析、建议或草稿，无法实现实际业务状态变更。
传统SaaS与幻想中的Agent SaaS在架构上有何根本区别？
传统SaaS基于确定性核心：关系数据库、状态机、规则引擎、RBAC和审计追踪。幻想中的Agent SaaS基于概率黑盒：模糊提示、LLM推理、临时脚本，输出不可预测，缺乏可靠性和一致性。
