这几年的SaaS创业圈有个特别有意思的现象大家嘴上都在讨论AI Agent手上却还是按老一套流程在做事——花三个月画原型再花半年写完整业务系统然后才敢去找用户聊。等产品终于上线了发现用户早就被别的AI原生产品拐跑了。我自己也踩过这个坑所以现在逢人就劝一句话别急着做完整SaaSAI Agent 最值钱的地方不是帮你写代码而是帮你把“验证产品”这件事的顺序彻底倒过来。先花一分钟说清楚我理解的AI Agent。它不是聊天机器人套壳也不是一个能调几个API的脚本而是一套能接收目标、拆解任务、调用工具、根据结果自我纠偏的智能执行体。换句话说以前用户面对的是一个需要自己点按钮、填表单的软件现在用户面对的是一个你说句话、它就能替你干活的“数字员工”。这个形态差异恰好把SaaS创业里最烧钱的“前置开发”砍掉了一大半。这篇文章不是什么高屋建瓴的趋势预测而是基于我最近一段时间在真实项目里用 FastAPI LangChain LangGraph 搭出来的最小验证Agent以及把验证周期从三个月压缩到十天左右的实际记录。内容包括选型的底层逻辑、最小验证方案的设计思路、可复制的技术架构、并发瓶颈怎么扛以及在产品化过程中遇到的典型问题和排查实录。无论你是准备All in AI创业的独立开发者还是公司里想用Agent验证新业务的团队这篇都应该能给你省下不少试错费。1. 传统SaaS验证模式到底哪里出了问题1.1 慢且贵的“完整交付”假设传统SaaS创业的基本逻辑是先瞄准一个细分需求做出一个“足够完整”的产品再推向市场验证。这个流程背后有个隐形的假设——你选的赛道和需求理解是对的。但现实是大多数需求都是猜的。完整产品通常意味着账号体系、权限管理、审计日志、多租户隔离、支付计费等一整套基础设施。这些组件单拎出来每一个都很重要但在“验证需求”阶段它们一个都用不上。钱和时间的浪费还不是最致命的最致命的是节奏拖得太久等完整产品上线时市场环境、用户心智、竞对状态全都变了。我自己见过太多团队死在“大楼盖了一半发现地基选错位置”的局面上。之前给一家二手设备交易平台做过咨询他们花了两个多月做了标准的B端订单管理SaaS包含报价、审批、对账、物流跟踪全套流程结果上线后最活跃的功能居然是备注栏。因为客户真正需要的只是“快速把询盘转成可编辑的PDF报价单”而这个需求他们早就能用五个脚本解决。1.2 “MVP思维”在Agent时代也不够用了有人会说我们早就不做完整SaaS了我们做MVP。MVP确实比完整SaaS进了一步但传统MVP仍然偏向于“交付最小可用软件”——一个能注册、能录入数据、能看报表的简化系统。它验证的仍然是“用户能否学会操作这套工具”而不是“用户是否愿意为一个智能体付钱办事”。MVP思维还有个隐藏陷阱它默认产品的核心价值是“功能”。而Agent时代的产品核心价值是“结果”。用户不在乎你后台有没有完整的订单状态机他只知道“我说了一句话事情没办好这工具没用”用户也不在乎你的对话界面里支持多少种富文本格式他只看“我上传一张模糊的发票照片能不能自动把金额录进表格”。这个差异直接决定了验证顺序的颠倒传统流程先验证软件可用性再验证商业付费意愿Agent时代的流程应该先验证“目标结果是否被需要”再考虑要不要沉淀成系统。2. AI Agent 为什么能改变验证顺序2.1 从“软件交付”到“能力交付”的逻辑跃迁完整SaaS的价值主张是“你把数据放进来我帮你管起来”而AI Agent的价值主张是“你把任务交给我我帮你干完”。这是完全不同的交付物。软件交付需要你把流程、权限、数据模型全部想清楚才能开工能力交付只需要你定义清楚“输入是什么、输出是什么、有没有现成的工具帮我执行”。举一个特别直白的例子开一家代记账公司。传统SaaS的做法是开发一套包含账本、凭证、报表、税务计算器的财务系统让客户自己在系统里录数据。Agent的做法则简单得多给Agent一个客户上传的银行流水PDF它自己识别字段、清洗数据、调用本地的记账API然后生成凭证草稿。后者不需要开发任何前端界面、不需要设计复杂的表单交互甚至不需要数据库表结构——你只需要一个上传入口和一段处理逻辑。这也是为什么现在的验证可以按“天”来计。最小验证Agent不追求功能多多益善它只需要覆盖一条完整链路识别输入 → 拆解步骤 → 调用工具 → 输出结果。2.2 用户反馈的市场校准速度快了几个数量级完整SaaS时代用户使用后产生反馈的周期是“使用 → 困惑 → 填反馈表 → 等下一个版本”。这个周期动辄几周。Agent时代反馈周期被压缩成“任务发出 → 结果返回 → 不满意继续调整”。一个上午就能跑五六轮调整。快带来的不仅是速度更是信用。用户看到Agent第一次没能完全理解需求但经过一轮对话调整后给出了满意结果他对产品的信任度反而提升。这种“看着它变对”的过程在传统软件里完全体验不到。传统软件改需求要等迭代Agent改需求只需要改Prompt或工具参数。所以现在完全可以用“实时会话中的调整次数”作为衡量产品价值的指标而不是月活数。2.3 试错成本断崖式下降传统SaaS的试错成本主要来自开发资源和时间沉没成本。写一万行代码搭好的业务逻辑第二天发现方向错了这一万行基本归零。Agent的试错成本来自Prompt设计和工具调用链路的调整绝大多数情况下都不需要重写整个系统。这意味着你可以同时验证好几个方向。我们团队当时并行试过三个场景价格监控与比价、批量生成小红书内容、会议纪要自动归档。前前后后总共花了两周时间每个场景都搭了原型然后根据真实用户反馈砍掉了前两个保留了会议纪要这个付费意愿最强的方向。这种“多线洒网、快速收网”的打法在传统SaaS时代想都不敢想因为三个方向做完最少也要半年。3. 最小验证方案怎么设计目标、场景、用户的三角收敛3.1 目标定义验证“付费冲动”而不是验证“功能完整性”很多人搭建AI Agent验证原型时第一个错误就是把Agent做成什么都想干的万能助理。又想让Agent帮你写周报又想让Agent帮你查天气还想让它帮你在电商平台下单比价。结果就是每个能力都只能做到60分没有一个场景让用户拍着桌子说“我愿意付钱”。我这次的实践心得是在最小验证阶段目标只锁定一个维度——用户是否因为“省时间”而掏钱。其他什么“提高准确率”“增强协同体验”统统靠边站。时间节省是AI Agent最容易量化也最容易感知的收益。你让用户自己手工操作需要二十分钟Agent三分钟干完用户当场就会觉得值。所以设计验证目标时可以给自己定三个前置问题这个任务有没有周期性重复每次完成需要多少步骤用户在决策链路上是否被卡脖子三个问题都是“是”方向基本靠谱。3.2 场景收敛选取“孤岛型任务”作为切入点孤岛型任务指的是不需要和复杂业务系统深度集成、边界清晰、输入输出明确的单点任务。做发票识别就是孤岛型任务做全自动税务申报就不是后者依赖税局接口、企业基本信息、历史申报记录集成复杂度会瞬间拖死验证进度。我们保留的“会议纪要自动归档”就是典型孤岛型任务输入是会议录音或飞书妙记链接输出是结构化的会议纪要和待办事项然后同步到维基。整条链路只依赖两个工具语音转文字的API和维基的开放接口。不存在权限矩阵、多租户隔离、审计系统之类的问题。另外一个经验是别选那些“看着很AI但用户根本没有付费习惯”的任务比如写诗、讲段子、生成头像。AI廉价感太重用户会默认这玩意儿就该免费。付费意愿强劲的任务往往藏在没人觉得“AI应该会”的地方比如合同关键条款抽取、竞品价格追踪、库存盘点表整理。这些任务枯燥、频繁、用户此前从没指望过AI能做。3.3 用户发现先找20个“手工作业重度用户”产品验证里最常被忽略的环节是用户从哪来。传统做法是写一堆SEO文章、投信息流广告、铺媒体通稿然后等着用户注册。对最小验证Agent而言这些都是性价比极低的路子。我用的方法非常简单粗暴去目标用户的聚集地——千人群、垂直论坛、行业社群找到那些经常提出同类问题的人私聊他们“这个东西如果你能直接丢一个文件给我我帮你整理好每次收多少多少你愿意试一次吗”。第一批20个人就够了。20个高频重复劳作的用户反馈足以判断场景真伪样本再多对于早期方向选型意义不大。还有一个细节务必注意跟用户聊需求时不要问“你觉得这个功能怎么样”而要问“你最近一次做这件事花了多少时间卡在哪一步”。前者得到彩虹屁后者得到真实的付费线索。用户说自己“每次整理会议纪要想死要做四十分钟”的时候商业价值已经写在脸上了。4. 技术底座选型从“能用就行”到“扛得住并发”4.1 框架选型FastAPI LangChain LangGraph 的组合逻辑验证阶段的Agent技术选型我最终选的是 FastAPI LangChain LangGraph 这条链。理由不复杂FastAPI提供异步接口能力LangChain提供了大量现成的工具接入和模型封装LangGraph给了Agent状态机编排和循环控制能力。三者合起来可以在没有完整后台的情况下快速搭出“对话→规划→执行→反馈→循环”的完整闭环。如果只用LangChain不加LangGraph很快就会遇到一个问题Agent不具备可控的循环机制。LangChain的Agent框架在简单任务上很好用但遇到需要多个工具协作的场景流程控制就会变得混乱——某个工具返回格式稍微异常整条链路就退化成“模型自言自语”。LangGraph的核心价值是用图结构显式管理节点的状态转移哪一步失败了、要不要重试、需要跳到哪里全都可视化可控。这里也补充一下其他选型的参考。在纯技术团队里基于Rust的Agent框架胜在性能和高并发但Rust的生态目前还不够成熟Agent编排类库少、迭代快、学习成本高用在验证阶段不太划算。Spring AI则适合Java技术栈的团队在集成Spring生态的路由上非常顺滑但上手体验相对笨重最终我选择了Python系因为它离数据处理和AI生态最近改提示词、接工具、调试链路都是阻力最小的。4.2 Agent主循环模型推理编排代码演示下面贴一段简化但完整的主循环代码。这个模块负责接收用户指令、解析目标、调用工具函数并在执行出错时自动回滚给大模型重新规划。在真实项目中这个文件大概是逻辑最重的部分也是排障时最需要盯住的点。from fastapi import FastAPI, WebSocket from langchain_openai import ChatOpenAI from langgraph.graph import StateGraph, END from pydantic import BaseModel from typing import TypedDict, Literal import asyncio # Agent状态结构定义 class AgentState(TypedDict): query: str messages: list next_step: str tool_result: str retries: int # 业务工具会议纪要整理实际项目中可能是API封装 async def summarize_minutes(payload: str) - str: # 模拟一次外部工具调用 await asyncio.sleep(0.5) return f已生成结构化纪要原始长度{len(payload)}字提炼出5条待办事项 class AgentService: def __init__(self): # 生产环境换成gpt-4o等更强推理模型 self.llm ChatOpenAI(modelgpt-4o-mini, temperature0) self.max_retries 3 async def route(self, state: AgentState) - AgentState: # 路由判断决定下一步调工具还是直接回复 if 工具 in state[query]: state[next_step] use_tool else: state[next_step] respond return state async def call_tool(self, state: AgentState) - AgentState: try: state[tool_result] await summarize_minutes(state[query]) except Exception as e: state[tool_result] f工具调用异常: {str(e)} return state async def answer(self, state: AgentState) - AgentState: messages state[messages] [ (system, 你是会议助手Agent基于结果信息回复用户), (human, state[query]), (assistant, state.get(tool_result, )) ] resp await self.llm.ainvoke(messages) state[messages] state[messages] [ (human, state[query]), (assistant, resp.content), ] state[next_step] done return state async def retry_logic(self, state: AgentState) - AgentState: # 简单重试每一步负责模块必须注册重试计数器 if 异常 in state.get(tool_result, ) and state[retries] self.max_retries: state[retries] 1 state[next_step] use_tool # 重新执行工具 return state4.3 用LangGraph编排状态流转图的完整代码LangGraph的真正威力体现在构建显式状态机上。下面这段定义了两个关键节点和节点之间的条件跳转核心价值在于当任务执行出错时流程能自动回到规划节点重新规划而不是一股脑往下走这是靠裸LangChain很难优雅实现的。from langgraph.graph import StateGraph, END # 构建图结构 def build_agent_graph(): service AgentService() graph StateGraph(AgentState) # 注册节点 graph.add_node(route, service.route) graph.add_node(use_tool, service.call_tool) graph.add_node(respond, service.answer) # 入口 graph.set_entry_point(route) # 条件边根据路由结果选择分支 graph.add_conditional_edges( route, lambda state: state[next_step], { use_tool: use_tool, respond: respond } ) # 工具调用后必须经过重试判断异常则回到工具节点重试 graph.add_node(retry_check, service.retry_logic) graph.add_edge(use_tool, retry_check) graph.add_conditional_edges( retry_check, lambda state: state[next_step], { use_tool: use_tool, respond: respond } ) graph.add_edge(respond, END) return graph.compile() # 实际项目挂载到FastAPI agent_app build_agent_graph()这段代码跑通以后你已经拥有了一个具备“目标拆解、工具调用、错误重试、结果答复”能力的最小Agent闭环。看起来只有三四十行但这就是整个验证产品的核心引擎。后续所有业务逻辑插件化扩展比如接入飞书API、生成周报、推送企微全部通过新增工具节点实现主循环源代码基本不怎么动。4.4 对无代码平台的补充观点什么情况可以不写代码国内团队常用的扣子Coze这类AI Agent智能体应用搭建平台也不是不能用。扣子在快速验证“Prompt到底能不能满足用户需求”这个维度上非常高效拖拽节点、接入插件、直接发布到飞书或微信都非常顺滑。如果你完全不会写代码想验证“是否有人愿意用”先用扣子搭个原型去找用户聊是合理路径。但当你需要验证并发能不能扛住、数据能不能闭环回流、用户权限怎么隔离的时候无代码平台的边界很快就到。验证阶段结束、用户量开始增长的那一两天一定要把Agent逻辑迁到工程化代码上否则排队、限流、数据孤岛会让你在增长刚刚冒头的时候就被投诉吞掉。我们团队的做法是用扣子做了第一轮“纯Prompt市场测试”确认需求后立刻在FastAPI里重写逻辑整个过程控制在三天内完成。5. Agent怎么扛并发单机部署到架构升级5.1 先弄清楚Agent并发的瓶颈在哪聊Agent并发前必须先建立一个认知Agent的并发瓶颈和传统Web应用完全不一样。传统Web应用一个请求几毫秒就返回瓶颈在数据库连接和网络IO。Agent请求动辄几秒到几十秒因为期间可能要多次调用大模型API、多次调用外部工具甚至要做流式输出。这个过程中连接是长时间占用的内存和CPU开销也远高于普通请求。形态上一个典型的Agent请求是“长连接多轮IO外部副作用”。这意味着用传统的同步阻塞模型做Agent服务单机连十几个并发请求就会把线程池拖死。FastAPI的异步机制只能解决“等待IO时不占线程”的问题但如果代码里存在一个同步阻塞的OCR调用、一个没做异步封装的SDK、一个在事件循环里执行CPU密集任务的函数整个服务照样卡成PPT。所以扛Agent并发的第一步不是上Redis上Kafka锁队列而是把Agent里的每一条外部调用全部改成真正的异步。一个只有五六秒耗时的外部工具如果同步调用单机撑不起20路并发改成异步之后单机200路并发才会开始出现性能拐点。5.2 实操方案异步、任务队列、WebSocket三件套下面是我验证下来比较稳的单机架构第一层FastAPI异步接口层。WebSocket负责接收大量长连接用户会话标准模式下能扛住一两千个空闲连接。用户在会话中等待消息时提取关键状态借助asyncio任务让模型推理和工具调用并行执行。第二层Redis任务队列。Agent请求不一定全都要立即返回。可以将耗时超过十秒的复杂任务拆成“立即进入队列 → 异步Worker处理 → 通过WebSocket推送状态变化”。这种方式比同步等待好很多因为用户不会卡在HTTP超时上。第三层外部调用超时和降级。模型API偶尔抽风很正常工具API也可能变慢。所有外部调用必须设置显式超时超时后自动降级为“简化Prompt 缓存结果返回”。如果连续失败则踢回调度器让其排队重试而不是无限阻塞用户。from fastapi import FastAPI, WebSocket from redis.asyncio import Redis import json, asyncio app FastAPI() redis_client Redis.from_url(redis://localhost:6379/0) async def process_agent_task(task_id: str, query: str): # 模拟Agent的异步执行 await asyncio.sleep(2) result {task_id: task_id, result: f完成对query的解析: {query[:50]}} await redis_client.publish(fagent:task:{task_id}, json.dumps(result, ensure_asciiFalse)) app.websocket(/ws/{session_id}) async def agent_ws(websocket: WebSocket, session_id: str): await websocket.accept() task_counter 0 try: while True: data await websocket.receive_text() task_counter 1 task_id f{session_id}-{task_counter} # 任务直接丢给异步执行超时任务进入后台队列 asyncio.create_task(process_agent_task(task_id, data)) # 监听Redis结果通道实现状态推送 pubsub redis_client.pubsub() await pubsub.subscribe(fagent:task:{task_id}) async for message in pubsub.listen(): if message[type] message: await websocket.send_text(message[data]) break except Exception as e: await websocket.close(code4001, reasonstr(e))这段代码虽然简单但已经跑通了“长连接异步任务状态推送”的主干。生产环境中还需要加上Redis List存储历史消息、加上任务去重、加上连接心跳检测等增强逻辑但核心骨架就是这样。这个架构下单机扛几百路并发基本没问题验证阶段完全够用。5.3 部署要点从开发机到服务器单机部署除了代码层面还有几个容易踩的系统和进程层面的坑。Python的GIL导致CPU密集型任务无法多线程利用多核Agent服务是IO密集型为主所以GIL影响不大但如果你在Agent里跑了本地嵌入模型做向量化那就是CPU密集这时候要单独把Embedding服务拆出去别和Agent主服务混在一个进程。进程管理上我用的是systemd维护三个服务一个是FastAPI主服务一个是Redis一个是单独的Agent Worker进程。每个服务独立日志、独立重启策略。后来遇到的内存泄漏问题——LangChain的缓存模块在某些版本里会无限堆积历史消息——最后通过在Worker层定期重启解决。还有一个细节容易被忽略模型提供商的API并发配额。你的服务能扛1000路并发没用如果上游API只允许每分钟调用600次超出的请求全被限流。页面看起来依然流畅但Agent内部会疯狂重试用户等到的只有超时。方案是在Agent代码里加一层基于Redis的令牌桶限流做在前面好过被上游API 429后被动降级。5.4 一次真实压测记录简单记录一下我们的实测数据。环境是4核8G的云主机模型走gpt-4o-mini API外部工具是语音转文字接口。压测场景是模拟用户同时发送“整理会议纪要”任务每个任务包含大概五轮模型调用和两次外部工具请求。同步版本跑了30路并发成功率只有70%平均响应时间12秒CPU打满大量请求超时。改成异步版本后再次压测200路并发成功率接近100%平均响应时间4.5秒CPU占用不到40%。这个对比说明Agent扛并发的上限根本不在机器配置而在于你有多认真地做异步化和超时控制。把同步调用改成异步这一行代码带来的性能提升远超堆服务器配置。6. 从最小验证到产品化的平滑演进6.1 会话持久化与数据闭环最小验证阶段可以不用数据库所有上下文放在内存里用户刷新页面一切归零。但当你开始有付费用户的时候会话数据必须落盘原因不光是体验更是Agent优化的依据。我先把Session存进Redis保留最近20轮对话再异步归档到Postgres存全量历史。这样既能支持“最近几轮上下文”的快速读写也能在离线分析时通过SQL看用户在哪个环节尝试次数最多、最容易放弃。数据闭环是Agent产品的命根子——大模型能调用的数据越多Agent越智能产品壁垒越高。6.2 工具权限系统Agent版RBACAgent拥有调用外部工具的能力后权限设计会变成一个安全问题。如果让Agent直接持有公司数据库的读写权限它就具备了破坏性生产能力。我在产品化阶段加了一个轻量级的权限中间层每个外部工具声明“可调用角色列表”和“最大调用次数”用户在会话里发起操作时先检查权限。举个具体例子会议纪要Agent同时具备“读取客户信息表”和“写入周报系统”两个工具。普通员工只允许用第一个Team Leader两个都用但每天最多写20条。这个权限层的代码在十万火急的产品化阶段用中间件模式实现没有改动主循环只对工具注册表做包装。6.3 服务扩容从单机到多Worker验证阶段用户量突破某些天花板之后单机上跑三个进程就够了。但当你的Agent开始同时服务多个客户单机的承载能力就会见底。这时候不是盲目加机器而是要把无状态Worker从主服务中拆出去用Redis的brpop做任务分发多台Worker消费统一队列。这一步做好之后再扩容就很轻巧加一台机器、跑一个Worker进程、改一下.env里的Redis地址完事。Agent逻辑本身完全没有变化因为所有状态都已经是分布式的了。顺便提示一个常见误区不要过早引入Kubernetes这套体系验证阶段复杂度是最大的敌人很多项目是死在架构一夜之间从一台机器膨胀到二十个微服务上。6.4 哪些代码要坚持自研哪些继续用托管服务产品化过程中最贵的研发资源应该花在“Agent编排状态机”和“工具链路封装”上因为这是核心差异化。模型调用走的是APIEmbedding服务可以用托管版本向量数据库可以用云服务语音转文字也可以用第三方接口这些通用能力没必要自己造轮子。语音转文字、文档解析、OCR这类工具是AI Agent应用中最容易拖垮的环节大部分第三方接口都能用不必自己做。真正值得自研的是你的Agent如何拆解任务、如何编排工具、如何重试和兜底——这才是不同Agent之间的差距。把Prompts和工具序列写死在代码里而不沉淀成配置后续每次迭代都要发版这种体验会很痛苦。7. 常见问题与排查技巧实录7.1 Agent“装死”任务进行到一半无响应这是最闹心的问题用户发完消息后Agent石沉大海。排查路径通常是先看模型API调用日志确认是否有转发再看WebSocket连接是否还在可能静默断开了最后看任务是否卡在某个外部工具的同步调用上。很多时候“Agent装死”不是模型变笨而是同步调用把事件循环堵死了。如果在代码中发现任何requests.post()、普通的OpenAI SDK同步调用优先改成httpx.AsyncClient或异步版本。7.2 上下文越长推理越差Token膨胀的代价Agent在长会话里会逐渐遗忘早期信息回答质量呈现“会话越长越傻”的趋势。这不是错觉模型注意力分布和上下文长度是有强关系的。实际解决思路是每一轮对话结束后做一轮压缩把已有结论从完整对话中抽取为核心摘要后续轮次带着摘要运行而不是无限把历史消息全部塞进去。也可以设置上下文窗口长度上限超过后自动丢弃最旧的对话保留最近几轮完整上下文。这一招在会议纪要场景里效果显著因为会议纪要的“多轮”本来就是连续提炼的过程旧信息早已固化在摘要中。7.3 WebSocket与负载均衡器的兼容问题用户数上来以后如果你把Agent服务放到Nginx或云负载均衡后面容易发现WebSocket连接经常被被意外断开。很多网关默认代理超时时间是60秒而Agent的单任务响应时间常常超过这个数。必须显式拉长proxy_read_timeout云服务则要开启WebSocket支持的开关。这个坑排查起来最隐蔽因为本地测试完全正常一上生产环境就周期性断连。7.4 常见问题速查表现象潜在原因排查顺序任务卡住无响应外部工具同步阻塞/上游API延迟1.检查Agent代码是否有同步调用 2.查模型API日志 3.查工具API监控响应质量变差上下文Token膨胀1.查看请求发送的Token量 2.压缩历史摘要 3.限制上下文窗口WebSocket频繁断开网关代理超时1.查Nginx超时配置 2.查云网关WebSocket支持 3.加心跳保活并发一高就大量超时上游模型API限流1.查上游API配额 2.加本地限流 3.做缓存降级内存持续增长历史消息未清理1.查LangChain缓存 2.限制最大消息条数 3.定期重启Worker7.5 避免过度设计验证阶段的“少即是多”最后一个经验可能也是最有价值的一条验证阶段一定别做过度设计。我见过有团队在验证Agent产品的第一天就规划好了“我们要做一个智能体编排平台支持拖拽式工作流、多模型路由、插件市场”。这个愿景很美但验证阶段真正的任务只有一个确认一个任务、找到一类用户、让他们为结果付费。Agent编排平台是等到至少三五个垂直Agent都验证成功之后才值得开始思考的事情。验证阶段需要代码但需要的是能跑通主循环的代码不是支持任意流程编排的代码需要数据库但需要的是能存储用户状态和ttok的数据库不是能支撑千万级用户的分库分表架构需要能扛住一定并发但需要的是单机几百路不崩不是分布式扩展到几万台机器的容量规划。结尾最后分享一个让我彻底转变观念的案例。之前做完整SaaS项目时最怕的就是用户量增长太慢、系统空置率高。但用Agent验证新方向时我接触到一个用户他每个月光是在某个报表整理上的时间成本就有好几千块Agent帮他做这件事每次只要五分钟。这个用户很穷付不起整套SaaS的年费但他愿意按次付费、按结果付费。因为对他来说Agent不是一个需要学习、维护、升级的软件系统而是一个能替他省钱省时间的雇工。传统SaaS验证的是“管理软件能不能被接受”Agent验证的是“一个数字帮手有没有被需要”。前者需要你搭一个完整的组织架构后者只需要你证明一件具体的事可以更便宜、更快地完成。而证明这件事现在只需要写一次Prompt、调一个API、跑一轮真实验证就够了。如果你正在纠结要不要“把完整SaaS先做出来再去验证”我的建议很简单先找一件具体的、枯燥的、高频的、用户愿意为结果买单的事用一个最小Agent把它自动跑通然后把结果发给用户看。看他们的反应。反应好再考虑把Agent演进成SaaS反应不好你再换下一个场景试试。验证的成本已经低到可以天天做实验了就别再押上几个月的开发周期去赌一个未经验证的假设。