5.5 基于 Agent 底座的 MVP 与 v1：建议型 Agent 的最小闭环

承前：本体硬化了、语义层立了、遗留系统接上了——青禾项目的"地基"部分到此完工。现在回到发包的原点：增长副总裁要的是"复购率提升"，运营经理要的是"少干活"。这两个诉求合起来指向同一个产品形态：建议型 Agent——它不直接动手发券，而是把"该对谁、做什么、为什么"想清楚，交给人来决策。这一节讲怎么在标准 Agent 底座上把它搭出来：知识库四层设计、最小闭环、AI 判断 + 规则校验的双重兜底，以及从 MVP 到 v1 的边界怎么划。

---

5.5.1 为什么是"建议型"而不是"全自动"

第一直觉往往是"让 Agent 自动发券"——别。三个理由：

• 北极星指标的干预手段是券，券是花钱的。发错券的成本是真实预算，而建议错了的成本只是一条没人采纳的建议。风险不对称决定自动化程度。
• 干系人的信任是分阶段建立的。运营经理 W2 时还担心"AI 抢我饭碗"，W5 时让他先看到"AI 给的建议比实习生写的好"，采纳率本身就是信任的刻度。
• 监管与归因。每一张券的发出都要能回答"谁批的、依据什么"——建议型形态里这个答案是结构化的（建议单 + 人工审批记录）。

所以产品定位一句话：**Agent 出建议单，人拍板，系统执行（Action），指标说话（语义层）。**这是 MVP 的形态；v1 再把"高频、低风险、历史上采纳率 >95% 的建议类型"升级为半自动——自动化是挣来的，不是设想的。

5.5.2 建议单的技术形态：让 Agent 的输出可评审

在展开知识库之前，先定义清楚 MVP 的交付物长什么样。建议单（Suggestion）是一个结构化 JSON 对象，不是一段自然语言——自然语言只作为它的渲染层：

{
  "id": "R-0307", "cohort_ref": "semantics:sleep_tier=半沉睡 × value_tier=中价值",
  "action_template": "issue_coupon", "params": {"coupon": "C-20-off-99", "channel": "APP"},
  "rationale": [
    {"layer": "L3", "evidence": "近90天客单价中位数112元", "source": "metric:median_aov_90d"},
    {"layer": "L2", "evidence": "同类券核销率18.7% vs 无门槛9.2%", "source": "2025Q4活动复盘"},
    {"layer": "L3", "evidence": "68%到店发生在周四-周六", "source": "ontology:order_at_store"}
  ],
  "budget_cap": 50000, "estimated_exposure": 15167,
  "risk_flags": ["客群标签可信度低(建议先2店试点)", "覆盖率87% caveat"],
  "validation_status": "PASSED(rules_engine@v3)"
}

结构化的收益是三重的：运营经理看渲染层（人话+表格），评审系统读结构层（规则校验、预算检查），回流系统读证据层（采纳率统计、效果归因）。同一个对象服务三种读者——这是"建议"能被治理的前提。如果建议单只是一段聊天回复，它既没法批量审批、也没法统计采纳率、更没法回测——那就退回成一个高级玩具。

5.5.3 知识库四层设计

（四层设计的实操细节见下，先记一个总原则：每条进入 Agent 上下文的知识都带层级标签，Agent 引用时必须声明层级——"根据行业常见做法（L1）……"和"根据贵司 2025Q4 活动复盘（L2）……"在建议单里是两种完全不同的可信度承诺。）

建议型 Agent 的智商上限取决于知识库。青禾项目的四层结构：

知识库四层（从下到上，可信度递增、更新频率递减）

L1 背景层  行业与零售常识、会员运营方法论
           来源：公开资料 + 方法论文档 | 更新：随版本
L2 客户事实层  青禾业务规则、门店画像、历史活动效果
           来源：W2访谈验证事实 + 客户文档 | 更新：每月
L3 数据事实层  实时/近实时的经营数据快照
           来源：语义层API + 本体查询 | 更新：每日T+1
L4 口径与约束层  指标定义、Action规则、权限与合规红线
           来源：语义层注册 + Action规范 | 更新：走变更评审

设计要点逐层说：

• L1 是"通识"，永远标注为最低置信。Agent 引用它时必须说"按行业常见做法"，不许说"青禾的数据显示"。层级即证据等级——这个纪律直接决定 Agent 会不会一本正经地胡说。来源管理上，L1 的内容要有出处（书、论文、行业报告），无出处的"常识"不进知识库——FDE 自己的私人经验也必须标注为"个人判断"而不是行业事实，知识库的第一纪律是诚实标注，不是内容丰富。
• L2 是 W2 访谈资产的变现。进场上做的干系人地图、交叉验证过的事实清单，这时全部变成 Agent 的客户常识——"青禾的门店客群标签质量低"这个事实让 Agent 在建议里主动提示"客群数据可信度有限"。
• L3 不进 prompt 全量，走查询。经营数据按需从语义层/本体拉取，Agent 上下文里只放当次建议所需切片——既是成本控制，也是把数字来源锁死在语义层通道上（5.3 节的"数字走语义层"纪律在此落地）。
• L4 是围栏。发券的约束（面额上限、频次限制、黑名单）以 L4 为最高优先级——L1 的方法论再漂亮，撞上 L4 一票否决。四层冲突时高可信层压倒低可信层，这条规则写进 Agent 的系统配置。

5.5.4 最小闭环：从运营目标到建议单

MVP 只做一个闭环，四步：

**① 自然语言运营目标输入。**运营经理对 Agent 说："这季度想把半沉睡会员拉回来一批，预算控制在 5 万，别骚扰高价值会员。"

**② Agent 解析 → 会员分层。**Agent 把目标翻译成本体查询：目标人群 = sleep_tier = 半沉睡 且 value_tier ∉ 高价值（L4 约束：高价值会员本月已豁免触达）——注意这步没有自由 text-to-SQL：分层定义引用语义层注册的 sleep_tier_definition@v2，人群圈选走本体 Link（member_places_order 拉近 90 天消费）。

解析环节有个值得设计的中间产物：目标 DSL（领域小语言）。运营目标先被 Agent 翻译成一段结构化的目标描述（{"action_intent": "reactivate", "cohort": "sleep_tier=半沉睡", "budget": 50000, "constraints": ["exclude:high_value"]}），再由确定性代码执行。这个中间层的价值：运营经理可以直接修改 DSL（"预算改成 3 万"）而不必重说一遍需求；DSL 可以存为模板复用；最重要的是，Agent 的自然语言理解错误会在 DSL 上暴露出来，人工可检查、可纠正——语言理解和查询执行之间隔一道显式的翻译层，错不了暗错。

**③ 生成运营建议。**对每个子人群给出建议动作（券模板、面额、渠道、时机）——决策依据来自 L1 方法论 × L2 历史活动效果 × L3 当期数据。

**④ 理由与证据。**每条建议附带结构化说明。这是建议型 Agent 的灵魂——建议单不带证据等于噪音：

建议单 #R-0307（摘要）
人群：半沉睡 × 中价值会员，试点门店，共 4,213 人
建议：发 20 元满 99 可用券（APP 渠道），周四上午推送
理由：
  - 近90天客单价中位数 112 元 → 满 99 门槛"够得着"（L3，语义层）
  - 历史同类券核销率 18.7%，优于无门槛券的 9.2%（L2，2025Q4活动复盘）
  - 该人群 68% 的到店发生在周四-周六（L3，本体订单Link）
预算：上限 5 万，实际敞口 = 4,213 × 20 × 预估核销率 18% ≈ 1.5 万 ✓
风险提示：门店客群标签可信度低（L2），建议先抽 2 店试点
数据边界：人群数受双轨ID映射覆盖率87%影响（caveat引用）

运营经理看到这张单子，决策成本从"从头分析"降到"审核判断"——这就是"少干活"承诺的兑现方式。

5.5.5 双重兜底：AI 判断 + 规则校验

建议单发出前，过一个规则校验层——硬编码的业务规则，不经过 LLM：

def validate_suggestion(s: Suggestion) -> list[str]:
    errors = []
    if s.coupon.face_value > 0.3 * s.cohort.median_aov_90d:   # 面额上限
        errors.append("面额超过客单价30%红线")
    if s.channel == "SMS" and s.cohort.size > 8000:            # 批量短信上限
        errors.append("短信触达超量，需拆分报备")
    if overlap(s.cohort, recent_touched(30, "coupon")):         # 频次控制
        errors.append("人群与近30天已触达重叠，剔除重叠部分")
    if s.cohort.matches(L4.exempt_high_value):                  # 豁免名单
        errors.append("含高价值豁免会员，需人工复核")
    return errors

分工哲学：**AI 负责判断（哪些人、什么建议、什么理由），规则负责校验（红线、频次、上限）。**AI 的输出永远被当作"待验证的假设"而不是"决定"。LLM 会漂移、会幻觉、会被 prompt 注入——但规则校验层没有这些失败模式，它是确定性的。这个架构在行业内是共识级实践：生成式输出必须过确定性闸门，尤其当输出连接预算和动作时。

两层之外还有第三道保险——采纳率与效果回流。每张建议单标记是否被采纳、执行后的核销率/复购率回流进 L2 知识库（"2026Q1，20 元满 99 券对半沉睡人群核销率 16.3%……"）。Agent 的建议质量因此随使用时间单调上升——这是建议型 Agent 和静态 BI 报表的本质区别。

5.5.6 MVP 到 v1：边界怎么划

**MVP（第 4-10 周）只做：**单一用例（半沉睡唤醒）、单一渠道（APP 券）、试点门店、全人工审批。验收标准：建议单采纳率 > 40%，执行的活动复购提升 ≥ 1.5 个百分点（对照 3.4 节口径）。

v1（第二期）扩展的顺序，按"信任挣取"排列：

升级项	前置条件（挣来的信任）
人群类型扩展（新客、流失预警）	MVP 人群建议采纳率 > 60%
渠道扩展（短信，走规则报备）	规则校验层 8 周零漏放
半自动化（高频低险建议免审批）	该类建议历史采纳率 > 95% 连续两月
多门店推广	试点对照数据经 BI 复核

注意半自动化的门槛设计：**某类建议连续两月采纳率 > 95%，说明人和 AI 判断已收敛——此时人工审批是纯开销，撤掉它。**自动化程度跟着采纳率走，而不是跟着路线图走。

5.5.7 演示时刻：让运营经理"考"Agent

MVP 做完不是等验收会，而是制造一场精心设计的"考试"。请一线运营经理当面用真实运营口吻提目标——刻意不迁就系统的表达方式："最近三个月没来的那批人，能不能想办法弄回来？"而不是"请圈选半沉睡会员"。

这一考测的是整条链路的鲁棒性：Agent 要把口语化的"三个月没来"映射到 sleep_tier_definition@v2（含 87% 覆盖率 caveat）、"弄回来"映射到发券建议单、并主动暴露风险提示（客群标签可信度）。如果 Agent 答得磕磕绊绊，暴露的正是链条上最弱的一环——这是 demo 前最后的免费排雷机会。运营经理考完说一句"这个比我带的实习生强"，MVP 的信任阶段就算通过了。演示不是表演产品多完美，是当众验证它经得起不完美的问题。

5.5.8 要点总结

• 建议型形态是风险不对称的最优解：Agent 出建议单（人群×动作×理由×预算×风险提示），人拍板，Action 执行，语义层说话；自动化是按采纳率挣来的，不是按计划发布的。
• 知识库四层 = 证据等级：L1 通识（最低置信）< L2 客户事实 < L3 数据事实（走语义层查询不进 prompt 全量）< L4 口径与约束（一票否决的围栏）。
• 最小闭环四步：自然语言目标 → 分层（本体+语义层，无自由 SQL）→ 建议 → 理由与证据；建议单不带证据等于噪音。
• 双重兜底：AI 判断 + 确定性规则校验（红线/频次/上限/豁免），LLM 输出永远当假设对待；采纳率与效果回流 L2，建议质量随使用单调上升。

参考资料

• Palantir Foundry: Explore action types — "建议 → 审批 → Action 执行"工作流的工业原型：提交条件与人工确认的官方建模方式。
• OWASP Cheat Sheet Series: MCP Security — "高影响动作需人工确认、LLM 输出当不可信输入"的官方建议——双重兜底的权威依据。
• Anthropic: Building effective agents — 官方工程指南：何时用 workflow、何时用 agent，生成式输出与确定性控制流组合的架构模式。