独立产品何时不该用 LLM：规则能解决的事别交给概率

说明：成本与延迟对比是说明性示例。规则、传统算法或 LLM 的选择，应按真实输入、错误成本与预算验证。

月度账单寄来时，服务器费用不到 30 美元，API Token 的消耗却砸了 450 美元。仔细翻看日志才明白原因：为了给用户提供“智能Markdown导出”功能，后台把原本几行正则表达式就能完成的 HTML -> Markdown 格式转换，交给了一个配备了 4 个 Tool Calling 的 Agent 架构去逐步解析。

独立开发者手里有了 LLM，很容易把每个功能都改成模型调用。可原本几行确定性代码能完成的任务，换成 Agent 后通常只会增加延迟、费用和排障成本。

---

确定性逻辑死于非确定性 Agent

在一个优秀的产品架构中，确定性逻辑与概率性 AI 应该有极度清晰的物理隔离。但在很多开发现场，界限被搞混了。

我们整理了独立开发全流程中最常发生的三个“伪 AI 需求”反例：

1. 用 Agent 做精确的数据清洗与格式转换：试图让大模型去解析包含上万行的 CSV 并提取手机号。结果模型在处理第 8000 行时开始产生幻觉，格式错乱，且调用耗时高达 40 秒；而使用 Node.js 原生流配合正则，耗时仅仅是 12 毫秒。
2. 让 LLM 担任复杂的业务状态机调度：把订单支付后的履约流程（校验库存 -> 扣款 -> 发送邮件）全写在 Prompt 里让 Agent 决策。因为网络抖动导致工具返回异常，Agent 陷入了“重试 Tool Calling -> 再次失败”的无限死循环，直到触发 Token 窗口溢出。
3. 用向量检索取代结构化精确查询：在查询特定用户的“近 7 天未完成任务”时，不用 SQL WHERE user_id = ? AND status = 0，而是强行用向量相似度匹配。不仅召回结果模棱两可，还经常把其他用户的数据作为“相似上下文”泄露出来。

区分界限很简单：只要输入与输出之间存在明确的数学关系、语法规则或状态转移方程，就绝对不要使用 AI。

---

拿真实耗时与账单说话

不要在脑海里幻想 Agent 有多聪明。跑一遍耗时测量和日志审计，数据会立刻让你清醒。

使用 Linux 内置的 time 命令对比确定性函数与 LLM 调用的执行耗时：

# 测试正则表达式解析文本耗时 (确定性逻辑)
time node -e "const fs=require('fs'); const text=fs.readFileSync('input.txt','utf-8'); text.match(/https?:\/\/[^\s]+/g);"

# 测试通过 OpenAI API 进行 URL 提取耗时 (LLM 概率逻辑)
time curl -s https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"提取这段文本里的URL: http://example.com"}]}' \
  > /dev/null

前者输出是 real 0m0.015s，后者是 real 0m1.420s。耗时相差近 100 倍！

在生产环境运维时，使用 jq 过滤 Agent 工具调用的异常日志，排查无限循环的死锁调用：

# 分析日志中 Agent Tool Calling 循环调用次数 > 5 次的异常 Task
cat /var/log/agent-executor.log | jq -r 'select(.tool_calls_count > 5) | {task_id: .id, duration: .duration_ms, cost: .total_tokens}'

一旦发现某项任务的 Token 耗费异常暴涨，通常意味着 Agent 正在尝试用自然语言解决一个编程语言一行代码就能搞定的逻辑校验。

---

确定性规则门禁（Rule Gate）决策体系

为了阻止开发过程中滥用 AI，我们在架构最外层设计了一套“确定性门禁（Rule Gate）”。只有当请求通过了规则校验，且确定属于“语义理解/创造性生成”时，才会被移交给 Agent 引擎。

下图展示了这种分流架构：

flowchart TD
    A["用户请求/任务指令"] --> B["规则门禁 (Rule Gate)"]
    
    B --> C{"是否属于结构化精确匹配?"}
    C -- "是 (正则/SQL/静态规则)" --> D["执行确定性代码 Engine"]
    D --> E["毫秒级返回结果"]
    
    C -- "否" --> F{"是否属于概率性语义生成/推理?"}
    F -- "否" --> G["拒绝处理，提示无效输入"]
    F -- "是" --> H["推入 Agent 工作流 Engine"]
    
    H --> I["加载 Agent 硬限制 Guardrail"]
    I --> J{"Tool Calling 轮次是否 > 3?"}
    J -- "是" --> K["强行截断并触发确定性 Fallback"]
    J -- "否" --> L["执行工具调用并返回"]
    
    K --> E

这套体系在工程上强制要求：能用确定性代码写的逻辑，Agent 一行都别想碰。

---

可落地的确定性拦截门禁与 Agent 代理代码

下面的 Node.js/TypeScript 代码展示了如何构建一个带规则拦截与硬性轮询截断的 Agent 调度代理。

import { OpenAI } from 'openai';

interface TaskRequest {
  id: string;
  type: 'extract_url' | 'generate_summary' | 'calc_tax';
  payload: string;
}

export class DecisionGateEngine {
  private openai: OpenAI;
  private maxAgentRounds = 3;

  constructor(apiKey: string) {
    this.openai = new OpenAI({ apiKey });
  }

  public async processTask(task: TaskRequest): Promise<{ result: string; source: 'rule_gate' | 'agent_engine' }> {
    // 1. 确定性门禁拦截：能用代码解决的，直接处理
    const ruleResult = this.tryExecuteRuleGate(task);
    if (ruleResult !== null) {
      console.log(`[RuleGate] Task ${task.id} handled by deterministic rule.`);
      return { result: ruleResult, source: 'rule_gate' };
    }

    // 2. 只有真正的非确定性任务，才允许调用 LLM
    console.log(`[AgentEngine] Task ${task.id} routed to LLM execution.`);
    const agentResult = await this.executeAgentWithGuardrails(task.payload);
    return { result: agentResult, source: 'agent_engine' };
  }

  private tryExecuteRuleGate(task: TaskRequest): string | null {
    // 规则 1: URL 提取 -> 正则表达式
    if (task.type === 'extract_url') {
      const urlRegex = /(https?:\/\/[^\s]+)/g;
      const matches = task.payload.match(urlRegex);
      return matches ? matches.join(', ') : 'No URL found';
    }

    // 规则 2: 税率计算 -> 数学公式
    if (task.type === 'calc_tax') {
      const amount = parseFloat(task.payload);
      if (!isNaN(amount)) {
        return (amount * 0.06).toFixed(2);
      }
    }

    // 不匹配任何确定性规则，放行至 Agent
    return null;
  }

  private async executeAgentWithGuardrails(prompt: string): Promise<string> {
    let currentRound = 0;

    // 硬限制：防止 Tool Calling 陷入无限无限重试死循环
    while (currentRound < this.maxAgentRounds) {
      currentRound++;
      const response = await this.openai.chat.completions.create({
        model: 'gpt-4o-mini',
        messages: [{ role: 'user', content: prompt }],
      });

      const content = response.choices[0].message.content;
      if (content) {
        return content;
      }
    }

    throw new Error('Agent execution exceeded max round limit (Guardrail Triggered)');
  }
}

代码的重点在于 tryExecuteRuleGate，这是守护计算成本与系统可靠性的第一道防线。

---

边界确认 检查清单

在决定为新功能编写 Prompt 或者引入 Agent 框架之前，把这五条标准在白板上画一遍：

• 该功能是否要求 100% 的结果准确性与可复现性？如果是，绝对不要用 AI。
• 输入数据的结构是否可以通过 JSON Schema、正则或数据库索引明确表达？如果是，使用确定性代码。
• 是否为 Agent 设置了单次调用的最高预算（Token / 轮次 / 耗时）硬限制？
• 当 API 网络中断或模型超时时，系统是否具备零 AI 依赖的基础功能保底路径？
• 算过这笔账吗：用确定性代码开发的工时成本，是否在 3 个月内低于使用大模型 API 的订阅成本？

做产品时保持清醒。AI 是用来处理模糊的语义与创造力的，至于算术、解析、校验和状态转移，放过大模型，交给 CPU 去做。