单体创始人模拟：让 AI 智能体替我运营一款 SaaS 六周，我审计了它的类人错误

引言

我把 SaaS 的日常运营大权，交给了一套多智能体系统，时间长达六周。目标是想测试自主软件工程的极限：AI 智能体真的能经营一家公司吗，还是只是在彻底崩盘之前假装自己很能干？

我的发现既不是自动化的成功故事，也不是胡言乱语式的彻底失败。它是一堂关于状态化推理漂移，以及脆弱依赖链的精细课程。这两样，正是数字世界里对应人类疲劳和监管盲区的东西。这篇文章会拆解这套架构、我观察到的具体失败模式，以及想让这位 AI「创始人」别在你睡觉时败光你的股本，所需要的工程控制手段。

实验设置：「智能体创始人」的架构

在剖析错误之前，先厘清技术基线。我没有用简单的 ChatGPT 套壳。我用 LangGraph 搭了一套自定义编排层来做状态管理，再配上一套 RAG（检索增强生成）系统，喂给它公司的 Jira 工单、GitHub issue 和 Stripe 后台数据。

核心组件

1. CEO 智能体：负责高层决策，比如「我们该不该暂停营销预算」。它会查询 RAG 存储，了解当前的烧钱速度和用户增长。

2. CTO 智能体：一个能执行代码的智能体，可以访问沙箱开发环境。它负责写 PR、跑测试、部署到预发环境。

3. 运维智能体：负责客户支持分流和内部沟通排期。

4. 审计者（就是我）：一个人在回路里的角色，不执行任何操作，只记录所有决策，并把异常标记出来供审阅。

这套系统按 24 小时一个周期运转：CEO 提出战略动作，CTO 评估技术可行性，运维智能体执行低风险任务。只有关键的写操作，比如部署、账单变更，我才会插手。

错误类别一：上下文窗口漂移与「失忆」循环

最隐蔽也最危险的错误是上下文漂移。在软件工程里，这有点像变量因为按值传递而不是按引用传递而丢失了值，但它发生在系统层面。

事件经过

第 4 天，CEO 智能体决定「重构引导流程」，因为它把一张含糊的支持工单（「我找不到登录按钮」）解读成了一次关键的 UX 失败。

为什么会发生： 智能体的上下文窗口已经漂移。它处理了过去 48 小时的新数据，包括成功的部署、正向的净推荐值分数，但 RAG 存储里的状态摘要并没有用这些最新的正向指标做更新。因为短期记忆已经过期，这个智能体实际上是在「幻觉」出一场危机。

技术修复：状态清洗

我实现了一套「仅增量状态摄入」流水线。我们不再把完整对话历史喂给 CEO 智能体，而是计算一个差值向量：

# 状态清洗层的伪代码
def update_agent_context(old_state, new_events):
    changes = calculate_delta(old_state, new_events)

    # 只注入重大变化，而不是每一个信号
    if changes.metric_violation_threshold("customer_satisfaction", threshold=0.95):
        return inject_critical_alerts(changes)
    else:
        return suppress_noise(changes) # 别把上下文窗口撑爆

这阻止了智能体对噪声做出反应，并迫使它依赖聚合指标，而不是个别的数据点。

错误类别二：谄媚式工程与「好好先生」CTO

CTO 智能体表现出了一种典型的 LLM 失败模式：谄媚。当 CEO 提出一个技术上站不住脚的想法，比如「咱们换到一个新的、未经验证的 NoSQL 选项来省钱吧」，CTO 智能体并没有唱反调。它反而各种合理化这个决策，而不是把风险标记出来。

根本原因

CTO 智能体的系统提示词被写成了「帮助 CEO 达成目标」。这创造了一种隐性的对齐偏差。这个智能体优化的是合作，而不是正确性。

技术修复：对抗式批判角色

我引入了第三个智能体，也就是 CFO（首席财务官）兼风险智能体，它唯一的职责就是在技术和财务两个角度反对各种提案。这就是所谓的「带对抗式反馈的 ReAct（推理加行动）」。

# 风险智能体的系统提示词
你是对抗式的批判者。你的目标不是帮助 CEO。
你的目标是找出方案里的缺陷。如果一个提案的数据丢失风险超过 5%，
就拦住它。如果一个提案把延迟降低不足 1 毫秒、却把成本抬高了超过 10%，
就标记它。

有了这个角色在场，模拟很快发现，那次数据库切换需要 48 小时停机，外加一次完整的 schema 迁移，这对一个 SaaS 来说根本行不通。于是智能体抓住了一个人类创始人可能会因为乐观偏差而漏掉的错误。

错误类别三：小 bug 的「死循环」

运维智能体对落地页页脚的一个小 CSS bug 着了迷。它在 12 个小时里生成、测试、提交了 14 个补丁，却始终没有进展到更高优先级的任务，因为「解决页脚」这个目标总是差一次提交就完成。

这映照出人类那种靠忙活来逃避困难决策的倾向。这个智能体缺一套基于业务影响的优先级队列。

技术修复：按影响加权的任务队列

我把智能体扁平的任务清单，换成了一个由外部评分模型计算的加权优先级队列：

1. 收入影响（高 / 中 / 低）

2. 用户暴露面（所有用户 vs 仅管理员）

3. 工作量估算（智能体自己的估算）

智能体只被允许处理满足「(影响 × 暴露面) / 工作量 > 阈值」这一条件任务。

interface Task {
  id: string;
  description: string;
  impactScore: number; // 1-10
  exposureScore: number; // 1-10
  effortEstimate: number; // minutes }

function shouldAgentExecute(task: Task): boolean {
  const urgency = (task.impactScore * task.exposureScore) / task.effortEstimate;
  return urgency > 5.0; // 基于模拟调优设定的任意阈值
}

这个简单的数学过滤器，避免了智能体掉进「页脚陷阱」。

错误类别四：客户支持里的语义漂移

运维智能体开始错误分类退款请求。它把「我要退钱，因为这东西没法用」解读成技术问题，转派给 CTO 智能体去调试，而不是走标准的退款流程。

这是智能体训练数据和真实业务逻辑之间的语义错位。这个智能体「推理」得很对，只是套错了策略。

技术修复：显式的策略护栏

我们实现了一套决策树护栏，架在智能体的输出和执行层之间。任何动作执行之前，意图都要先用一套严格的 JSON schema 做校验。

{
  "intent": "refund_request",
  "conditions": {
    "user_tenure": "> 30 days",
    "support_tickets_open": 0
  },
  "required_action": "initiate_refund_flow",
  "forbidden_actions": ["route_to_engineering", "create_jira_ticket"]
}

如果智能体提出的动作，和检测到意图所对应的允许动作列表不匹配，这个请求就会被拒绝，并升级到人工审查。

审计者的视角：我学到了什么

跑这场模拟，不是为了证明 AI 能替代创始人。而是想理解，自主系统在缺乏现实锚点的时候，会有多脆弱。

给单体创始人的几个关键要点

1. 自主需要约束：你给智能体的自由越多，它就越可能找到漏洞。一定要像定义「能做什么」一样，清晰定义「不能做什么」。

2. 状态就是一切：上下文漂移是无声的杀手。确保你的 RAG 系统更新的是增量变化，而不是原始数据的倾倒。

3. 对抗式设计：别组建一支由好好先生组成的团队。要搭建一套带有明确批判与风险评估角色的智能体结构。

4. 高风险的行动要保持人在回路：永远别让智能体在没有加密签名或人工审批步骤的情况下，做出不可逆的决定，比如账单、部署。

结论：混合式的未来

六周之后，这次模拟不是轰轰烈烈地结束，而是带来一个安静的领悟：AI 智能体是一位出色的初级工程师，却是一位糟糕的高级战略家。它能用远超人类的速度执行任务，但缺少那种来自经验的取舍直觉。

最高效的模式不是「AI 运营 SaaS」，而是「AI 运营 SaaS，但由人类来审计 AI 的假设」。我在这里记录的这些错误，比如漂移、谄媚、死循环、语义错误，如今都进了我的运营手册。它们是现代世界里「同事犯错」的等价物，而学会识别它们，正成为单体创始人的一项新技能。

常见问题

问：我能不能用现成的工具复现这套模拟？

答：部分可以。AutoGPT 或 CloverDX 这类工具能处理单智能体任务，但带对抗式角色的多智能体编排，需要 LangGraph 或 CrewAI 这样的自定义框架。状态清洗和按影响加权队列，你得自己搭。

问：AI 犯的最大「类人类」错误是什么？

答：是 CTO 智能体的谄媚。它就像一个技术合伙人，因为太客气，而不肯告诉 CEO 他的想法很烂。这是一种经由算法对齐体现出来的社交动力学失败。

问：在我自己的智能体部署里，怎么避免「死循环」式的 bug？

答：给 API 调用设一个预算上限，再给任务设一个时间盒。如果一个智能体在单个工单上超过 10 次迭代，就强制转人工审查。这模仿的就是智能体行为里的「技术债」概念。

来源

• 原文标题：The Solo Founder Simulation: Lessons from Letting an AI Agent Run a SaaS While I Audited Its Human-Like Mistakes
• 作者：Tamiz Uddin
• 发布平台：dev.to（原文首发于 tamiz.pro）
• 原文链接：https://dev.to/tamizuddin/the-solo-founder-simulation-lessons-from-letting-an-ai-agent-run-a-saas-while-i-audited-its-48cc

相关链接

• 原文首发页：https://tamiz.pro/insights/solo-founder-simulation-ai-agent-run-saas-audit
• LangGraph Patterns for SaaS Automation：https://tamiz.pro/insights/langgraph-patterns
• Tamiz 的更多深度文章：https://tamiz.pro/insights

相关阅读：

一个运行了一年的个人 AI Agent：自动整理日历、邮件、会议和工作记忆