用AI Agent重构SaaS验证流程：最小验证方案与LangGraph实战

这几年的SaaS创业圈有个特别有意思的现象：大家嘴上都在讨论AI Agent，手上却还是按老一套流程在做事——花三个月画原型，再花半年写完整业务系统，然后才敢去找用户聊。等产品终于上线了，发现用户早就被别的AI原生产品拐跑了。

我自己也踩过这个坑，所以现在逢人就劝一句话：别急着做完整SaaS，AI 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(model="gpt-4o-mini", temperature=0) 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 state

4.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(f"agent:task:{task_id}", json.dumps(result, ensure_ascii=False)) @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(f"agent: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(code=4001, reason=str(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版RBAC

Agent拥有调用外部工具的能力后，权限设计会变成一个安全问题。如果让Agent直接持有公司数据库的读写权限，它就具备了破坏性生产能力。我在产品化阶段加了一个轻量级的权限中间层：每个外部工具声明“可调用角色列表”和“最大调用次数”，用户在会话里发起操作时先检查权限。

举个具体例子：会议纪要Agent同时具备“读取客户信息表”和“写入周报系统”两个工具。普通员工只允许用第一个，Team Leader两个都用，但每天最多写20条。这个权限层的代码在十万火急的产品化阶段用中间件模式实现，没有改动主循环，只对工具注册表做包装。

6.3 服务扩容：从单机到多Worker

验证阶段用户量突破某些天花板之后，单机上跑三个进程就够了。但当你的Agent开始同时服务多个客户，单机的承载能力就会见底。这时候不是盲目加机器，而是要把无状态Worker从主服务中拆出去，用Redis的brpop做任务分发，多台Worker消费统一队列。

这一步做好之后再扩容就很轻巧：加一台机器、跑一个Worker进程、改一下.env里的Redis地址，完事。Agent逻辑本身完全没有变化，因为所有状态都已经是分布式的了。顺便提示一个常见误区：不要过早引入Kubernetes这套体系，验证阶段复杂度是最大的敌人，很多项目是死在架构一夜之间从一台机器膨胀到二十个微服务上。

6.4 哪些代码要坚持自研，哪些继续用托管服务

产品化过程中最贵的研发资源应该花在“Agent编排状态机”和“工具链路封装”上，因为这是核心差异化。模型调用走的是API，Embedding服务可以用托管版本，向量数据库可以用云服务，语音转文字也可以用第三方接口，这些通用能力没必要自己造轮子。

语音转文字、文档解析、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 常见问题速查表

7.5 避免过度设计：验证阶段的“少即是多”

最后一个经验，可能也是最有价值的一条：验证阶段一定别做过度设计。

我见过有团队在验证Agent产品的第一天就规划好了“我们要做一个智能体编排平台，支持拖拽式工作流、多模型路由、插件市场”。这个愿景很美，但验证阶段真正的任务只有一个：确认一个任务、找到一类用户、让他们为结果付费。Agent编排平台是等到至少三五个垂直Agent都验证成功之后才值得开始思考的事情。

验证阶段需要代码，但需要的是能跑通主循环的代码，不是支持任意流程编排的代码；需要数据库，但需要的是能存储用户状态和ttok的数据库，不是能支撑千万级用户的分库分表架构；需要能扛住一定并发，但需要的是单机几百路不崩，不是分布式扩展到几万台机器的容量规划。

结尾

最后分享一个让我彻底转变观念的案例。之前做完整SaaS项目时，最怕的就是用户量增长太慢、系统空置率高。但用Agent验证新方向时，我接触到一个用户，他每个月光是在某个报表整理上的时间成本就有好几千块，Agent帮他做这件事，每次只要五分钟。这个用户很穷，付不起整套SaaS的年费，但他愿意按次付费、按结果付费。因为对他来说，Agent不是一个需要学习、维护、升级的软件系统，而是一个能替他省钱省时间的雇工。

传统SaaS验证的是“管理软件能不能被接受”，Agent验证的是“一个数字帮手有没有被需要”。前者需要你搭一个完整的组织架构，后者只需要你证明一件具体的事可以更便宜、更快地完成。而证明这件事，现在只需要写一次Prompt、调一个API、跑一轮真实验证就够了。

如果你正在纠结要不要“把完整SaaS先做出来再去验证”，我的建议很简单：先找一件具体的、枯燥的、高频的、用户愿意为结果买单的事，用一个最小Agent把它自动跑通，然后把结果发给用户看。看他们的反应。反应好，再考虑把Agent演进成SaaS；反应不好，你再换下一个场景试试。验证的成本已经低到可以天天做实验了，就别再押上几个月的开发周期去赌一个未经验证的假设。