Multi-Agent Implementation & Cost Control

Architecture: 5-Layer Stack

从底层到顶层，每层独立可部署、独立有价值。2026-03 更新：L1 采用 Inngest 替代自建事件总线，L4 采用 OpenAI Agents SDK (JS) 作为 LLM 调用层。

L1 Event Bus

Inngest (事件驱动 durable workflow) + Socket.IO (前端推送)

业务事件 → Inngest 事件路由 + 多步骤 workflow + 自动重试 + 持久化状态 → Socket.IO 推送到前端。
Inngest AgentKit 原生 Node.js/TS，内置 multi-agent 编排。替代自建事件总线，节省 30-40% 基础设施代码。
备选 Trigger.dev（类似定位但 event purity 不如 Inngest）

~$0

Inngest 免费层足够 MVP

↓

L2 SOP Engine

JSON 状态机 × 工作流类型

每种业务流程（checkout、day-start、reconciliation）= 一个状态机定义。
覆盖 80% 标准操作。确定性执行，零 LLM 调用，100% 准确。
核心护城河领域知识编码为可配置规则。

$0

计算成本

↓

L3 Router

Event Classifier — 规则优先，LLM 兜底

判断每个事件走 SOP Engine 还是 LLM Agent。
90% 用规则分类（event_type 匹配），10% 模糊事件用 gpt-4o-mini 分类。

~$0.5

/store/month

↓

L4 Sub-Agents

3 个领域 Agent — 只处理边界情况

Appointment 非标支付、纠纷处理 Marketing 上下文感知的推荐生成 Finance 异常解释、根因分析
使用 Claude Sonnet / gpt-4o。每天约 15-20 次调用。

~$6

/store/month

↓

L5 Supervisor

跨域编排 + Owner 汇报

批量处理（非实时），聚合 Sub-Agent 状态，生成日报/周报，处理 Owner 指令。
使用 Claude Sonnet。每天 3-5 次调用（含日结汇总）。
注意不用 Opus——Sonnet 足以胜任编排任务，Opus 仅限 Owner 主动请求深度分析时使用。

~$5

/store/month

Cost Model: Per Store / Per Day

假设：中型门店，35 appointments/day，5 walk-ins，总计 ~85 events/day

Plan A: Pure LLM

$55

/store/month

每个事件都调 LLM
27.6% of $199 revenue

Plan B: Tiered LLM

$28

/store/month

按事件复杂度选模型
14% of $199 revenue

Plan C: Hybrid
(Recommended)

$12

/store/month

规则引擎 + LLM 混合
6% of $199 revenue

Component	Events/Day	LLM Calls	Model	Tokens/Day	$/Day	$/Month
L1 Event Bus	85	0	N/A	0	$0	$0
L2 SOP Engine (80% events)	68	0	Rule Engine	0	$0	$0
L3 Router (fuzzy events)	~9	9	gpt-4o-mini	~5K	$0.004	$0.12
L4 Appointment Agent	~7 edge cases	7	Sonnet	~14K	$0.08	$2.40
L4 Marketing Agent	~5 triggers	5	Sonnet	~20K	$0.10	$3.00
L4 Finance Agent	1 day-end	1–3	Sonnet	~10K	$0.05	$1.50
L5 Supervisor (batch)	3 batches	3	Sonnet	~12K	$0.07	$2.10
L5 Daily Summary → Owner	1	1	Sonnet	~8K	$0.05	$1.50
Opus (on-demand deep analysis)	variable	0–2	Opus	~5K	~$0.05	~$1.50
Total (without on-demand Opus)					$0.39	$11.72
Total (with occasional Opus)					$0.44	$13.22

★ 利润率分析

订阅价 $199/mo，AI 成本 ~$12/mo = 6% of revenue。
即使流量翻倍（70 appointments/day），成本也只到 ~$24/mo = 12%。
对比：典型 AI SaaS 的 LLM 成本占比在 15-30%。我们的混合架构把这个数字压到了 行业平均的 1/3。

关键：$99/mo AI Premium add-on 的毛利率 > 85%。

Event Flow: 一个 Appointment 的完整生命周期

EVENT: service.completed     [employee marks service as done on iPad]
  │
  ├─ L1 Event Bus: INSERT into agent_events → PG NOTIFY 'agent_event'
  │
  ├─ L3 Router: Check event_type against SOP registry
  │   ├─ MATCH: 'standard_checkout' (single service, regular customer, no discount)
  │   │   └─ Route to SOP Engine
  │   └─ NO MATCH (gift card + credit split, first-time VIP, active promo)
  │       └─ Route to Appointment Agent (LLM)
  │
  ├─ SOP Engine Path (80%)
  │   ├─ State: CHECKOUT_READY
  │   ├─ Auto-compute: total=$85, suggested_tip=18%, payment=card_on_file
  │   ├─ Socket.IO → iPad: Push To-Do card
  │   │   ┌──────────────────────────────────────┐
  │   │   │ ✅ Checkout: Lisa Chen - Gel Manicure │
  │   │   │ Total: $85 + Tip: $15.30 = $100.30   │
  │   │   │                                        │
  │   │   │ [Execute Standard]  [Customize]       │
  │   │   └──────────────────────────────────────┘
  │   ├─ Employee taps "Execute Standard"
  │   ├─ State: PAYMENT_PROCESSING → COMPLETED
  │   └─ Report to Supervisor: { type: 'checkout_completed', amount: 100.30 }
  │
  └─ LLM Agent Path (20%)
      ├─ Context: customer profile + cart + active promotions + store state
      ├─ Sonnet: Analyze situation, generate suggested action
      │   "Customer has $50 gift card balance + wants to split remaining on card.
      │    Suggested: Apply $50 GC → charge $35.30 to Visa ending 4242."
      ├─ Socket.IO → iPad: Push To-Do card with AI suggestion
      │   ┌──────────────────────────────────────────┐
      │   │ ⚡ Checkout: Lisa Chen - Gel Manicure      │
      │   │ Gift Card: -$50.00 │ Card: $35.30         │
      │   │ Tip: $15.30 → Card                        │
      │   │                                            │
      │   │ [Accept Suggestion]  [Modify]  [Manual] │
      │   └──────────────────────────────────────────┘
      ├─ Employee taps "Accept" or modifies
      └─ Report to Supervisor + log to agent_decisions (for learning)

SOP Engine: State Machine Design

每种工作流 = 一个 JSON 状态机定义。可按租户/门店定制。这是核心护城河。

// Example: Appointment Checkout SOP
{
  "workflow_type": "appointment_checkout",
  "states": {
    "SERVICE_COMPLETED": {
      "trigger": "service.completed",
      "auto_actions": [
        { "type": "compute", "fn": "calculateTotal" },
        { "type": "compute", "fn": "suggestTip", "params": { "default_pct": 0.18 } },
        { "type": "compute", "fn": "resolvePaymentMethod" }
      ],
      "push_to": "assigned_employee",
      "push_template": "checkout_standard",
      "options": {
        "execute_standard": { "next": "PAYMENT_PROCESSING" },
        "customize": { "next": "MANUAL_CHECKOUT" },
        "flag_issue": { "next": "ESCALATED", "notify": "supervisor" }
      },
      "timeout": "10m",
      "timeout_action": "remind_employee"
    },
    "PAYMENT_PROCESSING": {
      "auto_actions": [
        { "type": "execute", "fn": "processPayment" },
        { "type": "execute", "fn": "generateReceipt" }
      ],
      "on_success": "COMPLETED",
      "on_failure": "PAYMENT_FAILED"
    },
    "COMPLETED": {
      "auto_actions": [
        { "type": "report", "to": "supervisor" },
        { "type": "log", "to": "agent_decisions" }
      ]
    }
  },
  // Route to LLM if any of these conditions are true
  "llm_escalation_rules": [
    "cart.has_gift_card_split",
    "cart.has_multiple_payment_methods",
    "customer.is_first_visit AND store.has_active_first_visit_promo",
    "cart.discount_requires_manager_approval"
  ]
}
  

Database Schema: 3 New Tables

所有表加到现有 PostgreSQL，无需新基础设施。

agent_events — 事件存储

Column	Type	Note
id	UUID PK	gen_random_uuid()
tenant_id	UUID NOT NULL	multi-tenancy
store_id	UUID NOT NULL	门店隔离
event_type	VARCHAR(100)	'service.completed', 'day.start', 'payment.anomaly'
source_type	VARCHAR(50)	'appointment', 'payment', 'system'
source_id	UUID	FK to source entity
payload	JSONB	event data
status	VARCHAR(20)	pending → processing → completed / escalated
handler	VARCHAR(50)	'sop_engine', 'appointment_agent', 'supervisor'
result	JSONB	agent response / suggested action
created_at	TIMESTAMPTZ
processed_at	TIMESTAMPTZ

sop_workflows — SOP 定义

Column	Type	Note
id	UUID PK
tenant_id	UUID NOT NULL
store_id	UUID NULL	NULL = tenant-wide default
workflow_type	VARCHAR(100)	'appointment_checkout', 'day_start', 'day_end_reconciliation'
states	JSONB	state machine definition (如上)
llm_escalation_rules	JSONB	触发 LLM 的条件
is_active	BOOLEAN	default true
version	INT	SOP versioning

agent_decisions — 决策审计日志

Column	Type	Note
id	UUID PK
event_id	UUID FK	→ agent_events.id
agent_type	VARCHAR(50)	'appointment', 'marketing', 'finance', 'supervisor'
model_used	VARCHAR(50)	'rule_engine', 'gpt-4o-mini', 'claude-sonnet'
input_tokens	INT	LLM token tracking
output_tokens	INT	LLM token tracking
cost_usd	DECIMAL(10,6)	per-decision cost tracking
decision	JSONB	AI 给出的建议
human_accepted	BOOLEAN	员工是否接受了建议
human_override	JSONB NULL	如果拒绝，员工实际做了什么

★ agent_decisions 的隐藏价值

human_accepted + human_override 这两个字段是飞轮的核心。
当员工多次拒绝某类 AI 建议并手动选择相同替代方案时 → 这说明 SOP 规则需要更新。
这让系统越用越准：人类覆盖 → 发现规则缺口 → 更新 SOP → 减少 LLM 调用 → 成本持续下降。

Key Tech Decisions

引入 Redis / Message Queue？不需要

PostgreSQL LISTEN/NOTIFY + 现有 Socket.IO 足够覆盖当前规模。

PG NOTIFY 延迟 < 1ms，85 events/day 的量级不需要专门的消息队列
agent_events 表本身就是持久化队列（status = pending → processing）
当单店 500+ events/day 时再考虑 Redis Streams

用 LangChain / CrewAI / LangGraph？不用

这些框架全是 Python，而我们后端是 Node.js。引入 Python 微服务增加不必要的复杂度。

CrewAI / LangGraph / AutoGen — 全 Python only，和 Node.js 栈不兼容
AutoGen 已被 Microsoft 转入维护模式，合并到 Microsoft Agent Framework，不建议新项目采用
我们 80% 是规则引擎决策，不需要 LLM agent framework 的 RAG/tool calling chain
LLM 部分用 OpenAI Agents SDK (JS/TS) 或直接 API 调用即可

工作流编排用 Inngest 推荐采用

事件驱动 + durable workflow + 原生 Node.js/TypeScript，替代自建事件总线 + 状态机。

Inngest：事件触发 → 多步骤 durable workflow → 自动重试 → 持久化状态
内置 AgentKit：专为 AI agent 工作流设计，支持 multi-agent 编排
原生 Node.js/TypeScript — 无需引入 Python 微服务
可替代自建的事件路由 + 重试逻辑 + 状态持久化，节省 Agent 层 30-40% 基础设施代码
比 Temporal 轻量得多（Temporal 适合 Uber/Netflix 规模），比 PG LISTEN/NOTIFY 更可靠
备选：Trigger.dev（类似定位但 event purity 不如 Inngest）

LLM 调用层用 OpenAI Agents SDK (JS) 推荐采用

20% edge case 的 LLM 调用，用轻量框架而非重型 agent framework。

OpenAI Agents SDK (JS/TS 版)：19K+ GitHub stars，10.3M+ 月下载
Provider-agnostic — 支持 100+ LLM 包括 Claude（不锁定 OpenAI）
内置 tracing（可视化调试）、guardrails、human-in-the-loop
与 Inngest 官方集成（Temporal 也有官方集成，但 Inngest 更轻）
替代方案：直接 Claude/GPT API + structured output，对简单场景更轻量

用 Temporal.io 做工作流？不用，改用 Inngest

Temporal 太重。35 家店的规模用 Temporal 是杀鸡用牛刀。Inngest 是更好的选择。

Temporal 适合 Uber/Netflix 规模的分布式系统，运维成本高
Inngest 提供类似的 durable execution 保证，但开发体验更简单
如果未来扩展到 500+ 店且需要跨区域编排，再考虑迁移到 Temporal
Inngest → Temporal 迁移路径是可行的（概念模型类似）

Claude vs OpenAI？混合使用

已有 OpenAI 集成，增加 Claude 作为主力推理模型。

gpt-4o-mini：Router 分类（最便宜，足够快）
Claude Sonnet：Sub-Agent 决策（推理质量高，结构化输出好）
Claude Opus：Owner 深度分析（按需，不常驻）
抽象层统一接口，方便切换和 A/B 测试

Finance Agent 用 LLM？规则为主

对账必须 100% 准确。LLM 有幻觉风险，不适合关键财务路径。

规则引擎：POS 记录 × 支付处理器记录 → 自动匹配 → 标记差异
LLM 辅助：仅用于向 Owner 解释异常原因（自然语言生成）
永远不让 LLM 直接修改财务数据

前端推送用什么？ Socket.IO 复用

已有 Socket.IO 基础设施，直接扩展新的 event channel。

新增 channel：agent:todo, agent:suggestion, agent:alert
iPad/POS app（Flutter）：已有 Socket 连接
Web 端：已有 Socket.IO client
支持离线队列：员工重连后补发未读 To-Do

8 Cost Control Strategies

1. Rules First, LLM Second

80% 事件走 SOP 规则引擎，0 token 消耗。只有边界情况才调 LLM。

-80% token cost

2. Model Tiering

简单分类用 gpt-4o-mini ($0.15/M)，决策用 Sonnet ($3/M)，深度分析用 Opus ($15/M)。不一刀切。

-60% vs all-Opus

3. Prompt Caching

同类事件的 system prompt + SOP context 不变。用 Claude prompt caching 减少重复 token。

-50% input tokens

4. Supervisor Batching

Supervisor 不逐事件调用 LLM。每 2 小时或每 N 个事件批量处理一次。

-70% supervisor calls

5. Response Caching

相似事件（同类型 + 相似参数）缓存 LLM 响应。如"标准 VIP 折扣建议"只需要生成一次。

-30% LLM calls

6. Token Budget per Store

每个门店设月度 token 上限。接近上限时 → 更激进地走规则引擎路径。超限 → 降级到基础模型。

cost ceiling guarantee

7. Human Override → SOP Update

员工频繁拒绝某类 AI 建议 → 说明这类事件可以加规则 → 从 LLM 路径移到规则路径。成本持续下降。

flywheel effect

8. Per-Decision Cost Tracking

agent_decisions 表记录每次 LLM 调用的 token 和成本。实时监控，异常预警。

observability

Implementation Roadmap

Week 1-2

Foundation

3 new DB tables + migrations
Event Bus: PG NOTIFY listener
Socket.IO agent channels
Basic SOP Engine (state machine runner)

Week 3-4

First Agent

Appointment→Payment SOP definition
Checkout To-Do push UI (iPad)
"Execute Standard" flow
LLM fallback for edge cases

Week 5-6

Day Start/End

Day Start SOP + push
Finance reconciliation (rule engine)
Day End checkout flow
Anomaly detection → LLM explanation

Week 7-8

Supervisor MVP

Supervisor batch processing
Daily summary generation
Owner notification channel
Cost tracking dashboard

★ MVP in 8 Weeks

Week 4 就可以 demo 给 VC：一个完整的 Appointment → Payment 事件流，展示 push-based UX + "Do As Suggested" 交互。
这已经足够证明范式转变，不需要全部 Agent 就位。

8 周后有完整的 Day Start → Operations → Day End 闭环 + Supervisor 日报。这是一个 可演示、可测量、有真实用户反馈的 MVP。

Risk Mitigation

LLM Hallucination in Finance

Finance Agent 永远不直接修改数据
规则引擎做匹配和计算（确定性）
LLM 只生成解释文本（"这笔差异可能是因为..."）
所有财务操作需人工确认

Agent 故障降级

LLM API 挂了 → circuit breaker 触发 → 自动降级到 SOP Engine
SOP Engine 无法处理 → 推送"需要手动操作"卡片 + 打开传统 GUI
已有 circuit breaker 基础设施可直接复用
永远有 GUI fallback，系统不会完全不可用

信任冷启动

Phase 1：AI 只建议，不自动执行。每次都需要人工确认
Phase 2：当某类决策的接受率 > 95% 时，提供"自动执行"开关
Phase 3：Owner 可配置哪些流程允许自动执行
渐进式放权，不一步到位

Supervisor 校准

初期：宁可 over-escalate（多汇报比漏报安全）
Owner feedback loop：标记"不需要通知我这种事"
Per-owner preference learning：不同 Owner 不同阈值
兜底：Owner 可随时调整通知级别

Multi-Agent Implementation & Cost Control

★ Core Architecture Insight

Plan A: Pure LLM

Plan B: Tiered LLM

Plan C: Hybrid(Recommended)

★ 利润率分析

agent_events — 事件存储

sop_workflows — SOP 定义

agent_decisions — 决策审计日志

★ agent_decisions 的隐藏价值

引入 Redis / Message Queue？ 不需要

用 LangChain / CrewAI / LangGraph？ 不用

工作流编排用 Inngest 推荐采用

LLM 调用层用 OpenAI Agents SDK (JS) 推荐采用

用 Temporal.io 做工作流？ 不用，改用 Inngest

Claude vs OpenAI？ 混合使用

Finance Agent 用 LLM？ 规则为主

前端推送用什么？ Socket.IO 复用

1. Rules First, LLM Second

2. Model Tiering

3. Prompt Caching

4. Supervisor Batching

5. Response Caching

6. Token Budget per Store

7. Human Override → SOP Update

8. Per-Decision Cost Tracking

Week 1-2

Week 3-4

Week 5-6

Week 7-8

★ MVP in 8 Weeks

LLM Hallucination in Finance

Agent 故障降级

信任冷启动

Supervisor 校准

Plan C: Hybrid
(Recommended)

引入 Redis / Message Queue？不需要

用 LangChain / CrewAI / LangGraph？不用

用 Temporal.io 做工作流？不用，改用 Inngest

Claude vs OpenAI？混合使用

Finance Agent 用 LLM？规则为主