小拇指抖音评论/私信决策智能体 Pilot 合作协议

(草案 v1)

甲方:杭州小拇指汽车维修科技股份有限公司

乙方:上海多看人工智能科技有限公司

项目名称:小拇指抖音评论/私信决策智能体结构验证 Pilot

本协议为 Phase 1「结构验证 Pilot」合作协议。Phase 2「团队运行验证」与 Phase 3「生产系统建设」为后续合作路径说明,是否启动、具体范围与费用由双方另行签署补充协议或新协议确认。

一、项目背景

小拇指目前在抖音本地生活、职人视频、门店账号、官方账号、外包客服私信等渠道中产生大量评论与私信线索。这些线索并非普通留言,而是已经被内容激活的潜在客户在做决策前释放出的真实信号。

当前这些线索的处理方式存在以下问题:

  1. 回复依赖个体客服经验,缺乏结构化策略;
  2. 不同门店、不同职人、不同外包团队的回复质量差异大;
  3. 高意向线索因回复不及时或策略不当而流失;
  4. 低意向线索因过度跟进造成骚扰,反而损害品牌;
  5. 缺乏对评论/私信线索的结构化记录与复盘机制,无法持续优化。

因此,双方决定以 Pilot 方式,先验证一套「用户决策结构 → slots → Flow/NBA → AI 策略回复 → Eval/Trace」的决策智能体运行方式,判断其是否具备进一步团队化运行和生产级系统化落地的价值。

↑ 返回阅读导航

二、项目总路径

本项目分为三个阶段:

本协议仅覆盖 Phase 1。Phase 2 与 Phase 3 是否启动、具体范围与费用,由双方基于 Phase 1 结果另行签署补充协议或新协议确认。

↑ 返回阅读导航

三、Phase 1 项目目标

Phase 1 的核心目标不是「上线一个 AI 客服」,而是回答以下关键问题:

  1. 小拇指抖音评论/私信中的用户决策结构,是否可以被 AI 稳定识别?
  2. 基于识别出的结构和 slots,AI 生成的策略回复,是否比普通回复更能推动用户继续对话?
  3. 该结构是否可以被甲方团队理解、使用并持续优化?
  4. 是否具备进入 Phase 2 团队运行验证的价值?
  5. 是否具备进入 Phase 3 生产系统建设的潜力?

Phase 1 以「结构验证」和「初步业务 uplift」为核心,不承诺最终成交归因,不承诺覆盖所有业务场景,不承诺替代甲方现有客服团队。

↑ 返回阅读导航

四、Phase 1 工作范围

Phase 1 工作范围包括但不限于:

  1. 收集并分析不少于 500 条真实评论/私信样本;
  2. 建立第一版用户决策结构库(Decision Structure Library v1);
  3. 建立第一版 slots ontology(关键信息抽取框架 v1);
  4. 建立第一版决策卡库(Decision Card Library v1);
  5. 建立第一版 Flow/NBA 策略库(Flow / Next Best Action Library v1);
  6. 建立第一版禁忌边界与业务规则清单;
  7. 搭建人工 Runtime 工作台(AI 辅助决策 + 人工审核发送);
  8. 选取不少于 20 条真实评论/私信线索,进行人工辅助策略回复验证;
  9. 建立 Eval 表,记录用户是否继续对话、是否进入下一步动作;
  10. 建立轻量 Trace 表,对典型线索形成行为轨迹复盘;
  11. 输出 Phase 1 Pilot 复盘报告;
  12. 输出 Phase 2 扩展验证建议;
  13. 输出 Phase 3 生产级落地路线图。
↑ 返回阅读导航

五、Phase 1 六周工作计划

Week 1:Contract、结构与 slots

目标:完成任务定义与第一版结构/slots 抽取。

主要工作:

  1. 明确本次任务 Contract:
    • 任务:提升抖音评论/私信线索的真实转化效率;
    • 输入:评论截图、私信截图、历史客服回复、业务规则;
    • 输出:结构判断、slots、NBA、策略话术;
    • 成功指标:继续对话、留资、预约、到店意向等;
    • 风险边界:不能虚假承诺、不能错误报价、不能脱离门店真实能力、不能替门店承诺不可控服务。
  2. 基于大量评论/私信截图进行 AI 粗 mining 与人工判断,抽取:
    • 高频决策结构;
    • 关键 slots;
    • 高频边界问题;
    • 典型成功/失败/投诉模式。
  3. 输出第一版:
    • 任务 Contract v1;
    • 决策结构清单 v1;
    • slots ontology v1。

说明:Contract 不是形式文档,而是后续人工 Runtime 和 AI 工作台的治理层。后续所有策略、话术和评估都必须服从该 Contract。

为便于甲方理解,本项目中的几个关键概念说明如下:

因此,Week 1 的工作不是简单「看截图」,而是建立第一版线索心智地图:哪些用户决策结构是稳定存在的,哪些 slots 真正影响下一步策略。

Week 2:策略 Flow 与决策卡库 v1

目标:形成第一版可运行的策略结构。

主要工作:

  1. 基于 Week 1 的结构与 slots,建立第一版决策结构卡库;
  2. 从历史对话中抽取「弱 Eval / 弱 Trace」,即:
    • 用户说了什么;
    • 客服如何回复;
    • 用户是否继续;
    • 是否出现留资、下单、预约、转人工等下一步动作。
  3. 由 AI 初步生成不同结构下的策略 Flow / NBA;
  4. 由甲方 CTO 或指定业务 owner 判断:
    • 哪些策略业务上合理;
    • 哪些策略存在风险;
    • 哪些策略可以进入系统;
    • 哪些话术或承诺必须禁止。
  5. 输出第一版:
    • 决策结构卡库 v1;
    • Flow / NBA 库 v1;
    • 禁忌边界与业务规则清单 v1。

说明:Week 2 不是承诺 AI 已经自动学会最优策略,而是完成第一版「AI 辅助生成 + 业务 owner 确认」的半人工策略蒸馏。

这里的策略并非凭空编写 SOP,而是来自三类输入:

  1. AI 对大量历史评论/私信的结构化总结;
  2. 历史对话中已经存在的「弱行为链 / 伪 Trace」,即用户说了什么、客服怎么回、用户是否继续、是否进入下一步;
  3. 甲方 CTO 或业务 owner 对策略是否符合业务现实的裁决。

换句话说,Week 2 做的是 Decision Mining,而不是普通客服话术整理:从历史对话里抽取局部有效策略,再由甲方业务负责人判断哪些策略可以刻进系统。

Week 1-2 结束时,应形成第一版决策卡库与策略 Flow。Week 3 起,才基于该卡库开展人工辅助运行验证。

Week 3:人工 Runtime 跑库

目标:在真实线索上运行第一版决策卡库。

主要工作:

  1. 由甲乙双方共同确认 20-30 条真实评论/私信线索作为精跑样本;
  2. 对每条线索运行如下流程:
    • 输入原始对话;
    • AI 判断匹配哪类决策结构;
    • AI 补齐已知 slots,并指出缺失 slots;
    • AI 调用对应 Flow / NBA;
    • AI 生成建议话术;
    • 人工审核;
    • 由甲方指定人员在抖音或对应渠道手动回复。
  3. 建立第一版人工 Runtime 工作台。

说明:Phase 1 不建设完整自动化系统。Week 3 的本质是由乙方搭建带 Contract、卡库、slots、Flow 的 AI 工作台,由人工输入真实线索,AI 输出结构判断、NBA 和建议话术,再由人工审核并发送。

该人工 Runtime 可理解为第一版 Decision Runtime,基本结构如下:

Week 4:Eval 与初步效果观察

目标:记录运行结果,观察初步效果。

主要工作:

  1. 对 Week 3 运行的 20-30 条线索,记录:
    • 用户是否继续对话;
    • 用户是否留资;
    • 用户是否预约;
    • 用户是否到店;
    • 用户是否投诉。
  2. 对比同一批线索在 AI 策略回复前后的行为差异;
  3. 识别哪些结构 + slots + Flow 组合效果较好;
  4. 识别哪些策略存在明显问题(如过度承诺、错误报价、语气不当)。

Week 5:Trace 与策略迭代

目标:对典型线索形成完整行为轨迹复盘。

主要工作:

  1. 从 20-30 条线索中,选取 5-10 条形成完整 Trace;
  2. 每条 Trace 包括:
    • 原始评论/私信内容;
    • AI 判断的结构;
    • 补齐的 slots;
    • 选择的 Flow / NBA;
    • 生成的建议话术;
    • 人工审核后的实际发送话术;
    • 用户后续反馈;
    • 是否进入下一步动作。
  3. 初步识别:
    • 哪些策略更容易引发继续对话;
    • 哪些 slots 对推进最关键;
    • 哪些回复方式容易导致流失;
    • 哪些一刀切 SOP 存在浪费;
    • 下一轮应优先优化的策略路径。

Week 5 的交付物包括:

  1. 典型线索 Trace 表;
  2. 策略效果初步复盘;
  3. 下一轮优化建议。

Trace 表字段包括但不限于:线索 ID、来源、原始问题、匹配决策卡、关键 slots、AI 建议动作、实际发送话术、用户反馈、下一步动作、最终状态、复盘判断。

说明:Phase 1 的 Trace 以人工记录和样本复盘为主,不承诺接入抖音、门店、CRM 等系统完成全链路自动归因。

Week 6:Pilot Review 与生产级路线图

目标:判断是否值得进入下一阶段。

主要工作:

  1. 汇总 Phase 1 结果;
  2. 输出 Pilot 复盘报告;
  3. 判断核心问题:
    • 决策结构是否成立;
    • slots 是否能解释用户状态;
    • Flow / NBA 是否能推动用户进入下一步;
    • 人工 Runtime 是否可行;
    • 是否具备进入 Phase 2 团队运行验证的价值;
    • 是否具备进入 Phase 3 生产系统建设的潜力。
  4. 输出:
    • Top slots 观察;
    • Top Flow / NBA 观察;
    • 初步效果数据;
    • Phase 2 扩展验证方案;
    • Phase 3 生产级落地路线图。

说明:Week 6 不承诺增长曲线一定大幅拐点,而是完成「是否值得上生产」的复盘与演示。

本阶段结束后,乙方将提交下一阶段「团队运行验证 / 生产级落地」建议方案。是否进入第二阶段,由双方基于 Pilot 结果另行确认。

Phase 1 最终交付物包括:Pilot 复盘报告、是否进入 Phase 2 的判断建议、Phase 2 扩展验证方案、初步生产级路线图。

↑ 返回阅读导航

六、Phase 1 交付物

Phase 1 完成后,乙方将交付:

  1. 《任务 Contract v1》;
  2. 《小拇指抖音评论/私信决策结构库 v1》;
  3. 《slots ontology / 线索心智地图 v1》;
  4. 《决策结构卡库 v1》;
  5. 《策略 Flow / NBA 库 v1》;
  6. 《禁忌边界与业务规则清单 v1》;
  7. 《小拇指评论/私信回复工作台 Prompt / 人工 Decision Runtime v1》;
  8. 《人工运行样本 Eval 表》;
  9. 《典型线索 Trace 复盘表》;
  10. 《Phase 1 Pilot 复盘报告》;
  11. 《是否进入 Phase 2 的判断建议》;
  12. 《Phase 2 扩展验证方案》;
  13. 《Phase 3 生产级落地路线图》。
↑ 返回阅读导航

七、Phase 1 边界说明

双方确认,Phase 1 不包含以下内容:

  1. 不包含抖音评论/私信全量自动化接入;
  2. 不包含完整生产系统开发;
  3. 不包含自动回复上线;
  4. 不包含对所有评论/私信的全量连续处理;
  5. 不包含对所有后续多轮客服对话的连续代运营;
  6. 不承诺最终成交归因;
  7. 不承诺覆盖所有业务场景与所有边界案例;
  8. 不承诺所有门店、所有职人、所有账号统一上线;
  9. 不替代甲方客服、外包团队或门店人员履行实际服务承诺。

Phase 1 验证的是「结构有效性」和「初步业务 uplift」,不是完成全业务生产系统。

↑ 返回阅读导航

八、甲方配合事项

甲方需配合乙方完成以下事项:

  1. 提供评论/私信截图、历史客服对话、外包客服月报等材料;
  2. 提供当前有效的产品、套餐、价格、工时、服务项目、活动规则;
  3. 提供与「不能承诺」「可能加价」「门店差异」「服务边界」等相关的业务规则;
  4. 指定 CTO 或业务 owner 参与 Week 2 策略确认;
  5. 指定实际执行人员负责在抖音账号中发送 Pilot 回复;
  6. 协助记录用户后续反馈;
  7. 对乙方生成的话术进行必要业务审核;
  8. 提供必要的会议与沟通时间。

如因甲方未及时提供必要数据、业务规则或执行配合,导致 Pilot 时间延误,双方应协商顺延项目周期。

↑ 返回阅读导航

九、费用与付款方式

Phase 1 项目费用为人民币 150,000 元整。

建议付款方式:

  1. 合同签署后 3 个工作日内,甲方向乙方支付 50%,即人民币 75,000 元,作为项目启动款;
  2. Phase 1 结束并提交 Pilot 复盘报告及后续路线图后 3 个工作日内,甲方向乙方支付剩余 50%,即人民币 75,000 元。

付款账号:

上海多看人工智能科技有限公司
招商银行 上海分行 上海张江支行
账号:121988083310001

如双方另行约定,也可采用以下付款方式:

  1. 合同签署后支付 60%;
  2. Week 3 人工 Runtime 启动后支付 20%;
  3. Week 6 复盘交付后支付 20%。
↑ 返回阅读导航

十、后续 Phase 2 与 Phase 3 合作路径

10.1 Phase 2:规模化人工运行验证 / Team Runtime 验证期

Phase 2 不包含在本协议费用中,需另行确认。

Phase 2 的定位不是「再做一轮简单 Pilot」,而是把 Phase 1 中由 Grant + AI 验证过的结构,从 20-30 条样本扩大到 100-300 条真实线索,并让甲方团队在更真实的业务节奏中运行,验证这套体系是否可以从「Grant 人肉跑通」进入「团队可复制执行」。

Phase 1 证明的是:Grant + AI 能否把评论/私信中的用户决策结构化,并生成更好的首轮策略回复。

Phase 2 需要证明的是:小拇指的外包客服、职人、门店或运营团队,是否能在统一结构下稳定执行,并产生可观察的转化改善。

因此,Phase 2 的核心问题不是「多跑几条线索」,而是回答上生产前的三个问题:

  1. 团队是否会用这套结构;
  2. 执行过程是否会变形;
  3. Eval / Trace 是否能在团队运行中稳定记录。

Phase 2 可能包含的工作

  1. 扩大样本:从 Phase 1 的 20-30 条精跑样本,扩大到 100-300 条真实评论/私信线索;
  2. 扩大执行人:由甲方指定外包客服、职人、门店人员或运营人员参与执行;
  3. 培训执行人员理解:决策卡、slots、Flow、NBA、禁忌边界、首轮策略回复原则;
  4. 建立团队版人工 Runtime:让执行人员在统一工作台/表格/流程中运行策略回复;
  5. 乙方进行抽样审核:检查 AI 建议、人工发送、用户反馈、下一步动作是否符合 Flow;
  6. 识别执行偏差:哪些话术被改坏、哪些策略被跳过、哪些边界容易被误用;
  7. 迭代决策卡库:根据 100-300 条线索运行结果,更新结构、slots、Flow、NBA 和禁忌规则;
  8. 建立团队级 Eval 表:比较不同执行人、不同账号、不同场景下的继续对话、留资、预约、到店意向等结果;
  9. 建立团队级 Trace 复盘:识别哪些策略路径在团队运行中仍然有效,哪些只在 Grant 人肉运行时有效;
  10. 输出 Phase 2 团队运行验证报告。

Phase 2 的复杂度

Phase 2 的复杂度高于 Phase 1,原因在于:

  1. 样本量扩大约 5-10 倍,Eval / Trace 记录量显著增加;
  2. 执行主体从 Grant 扩展为甲方团队,出现培训、执行一致性、质量控制问题;
  3. 线索来源更复杂,可能涉及官方私信、职人评论、门店账号、外包客服等多种入口;
  4. 不同执行人对同一 Flow 的理解可能不同,需要抽样审核和纠偏;
  5. 决策卡库不再只是「可用」,而要验证是否可被普通团队成员稳定使用;
  6. 该阶段会暴露上生产前的真实组织问题:谁回复、谁记录、谁审核、谁负责结果。

Phase 2 的交付物

  1. 团队版人工 Runtime 使用说明;
  2. 执行人员培训材料;
  3. 100-300 条线索 Eval 表;
  4. 典型线索 Trace 表;
  5. 决策卡库 v2;
  6. slots ontology v2;
  7. Flow / NBA 库 v2;
  8. 执行偏差与风险清单;
  9. 团队运行验证报告;
  10. 是否进入 Phase 3 生产系统建设的建议。

建议周期:4-6 周。

建议费用:人民币 200,000-300,000 元,具体依据样本量、参与账号数量、参与人员数量、培训深度、抽样审核频次与复盘深度另行确认。

10.2 Phase 3:生产系统建设

Phase 3 不包含在本协议费用中,需另行确认。

Phase 3 的目标不是建设一个普通客服 SaaS,而是建设一套「小拇指抖音线索决策运行平台」。该平台可暂称为 bingo,其本质是 AI 原生的线索决策 Runtime,用来把抖音评论/私信从混乱对话转化为可判断、可执行、可追踪、可优化的任务链。

普通客服 SaaS 主要解决「人如何回复」;bingo 要解决的是「每一条线索进入系统后,AI 如何判断、选择动作、生成回复、记录反馈并持续学习」。因此,生产系统的复杂度不仅来自传统 SaaS 的数据、权限、账号、接口、看板,也来自 AI Agent 系统本身的运行机制,包括:任务 Contract 如何被系统 enforce、slots 如何自动补齐、Flow / NBA 如何被模型调用、模型输出如何受业务规则约束、Eval / Trace 如何自动记录、token 与模型调用成本如何控制、低风险与高风险场景如何分流、人工审核如何嵌入 Runtime。

bingo / 生产级系统需要解决四件事:

  1. 接入评论/私信;
  2. 识别结构 + 补 slots;
  3. 运行 Flow / NBA,生成建议回复;
  4. 记录 Eval / Trace,形成运营看板。

生产系统与 Phase 1/2 的最大区别在于:Phase 1/2 主要依靠 Grant 和甲方团队人工运行 20-300 条线索;Phase 3 要让系统在可获得数据范围内持续处理 1,000、10,000 甚至更多评论/私信。也就是说,生产系统要把人工 Runtime 变成可扩展的 AI Agent Runtime。

Phase 3 的 AI Agent specific 工作

Phase 3 至少需要处理以下 AI Agent 特有问题:

  1. 任务 Contract 系统化:将 Phase 1 中定义的目标、边界、禁忌承诺、成功指标,变成系统运行时的约束条件,而不是停留在文档里;
  2. 决策卡库工程化:将价格怀疑、套餐差异、车型适配、门店距离、是否加价、维修咨询、投诉安抚等决策卡,变成 AI 可检索、可调用、可更新的结构化知识;
  3. slots 自动抽取:从评论/私信中自动抽取车型、年份、排量、套餐、门店、城市、价格差异、风险顾虑、投诉状态等 slots;
  4. Flow / NBA 调度:根据不同结构与 slots 状态,自动决定下一步是补信息、去风险、推荐门店、引导预约、转人工、安抚投诉还是继续追问;
  5. 模型选择与调用策略:根据任务类型选择大模型、小模型、规则引擎或混合模式,避免所有任务都用高成本模型;
  6. Prompt / Card / Policy 管理:管理不同版本的提示词、决策卡、业务规则和禁忌边界,并支持回滚;
  7. 低风险与高风险分流:低风险场景可以半自动或自动回复,高风险场景如投诉、价格争议、门店服务纠纷必须进入人工审核;
  8. Human-in-the-loop 审核:建立人工确认、修改、驳回、升级机制,避免 AI 直接做不可控承诺;
  9. Eval 自动化:自动记录用户是否继续对话、是否留资、是否预约、是否进入门店咨询、是否流失;
  10. Trace 自动化:把每条 lead 的输入、判断、策略、回复、反馈、结果按时间顺序串起来,形成可复盘轨迹;
  11. Token 与成本管理:控制模型调用频次、上下文长度、卡库检索范围、批处理策略和运营成本;
  12. Agent 监控与安全:监控异常输出、错误报价、越权承诺、重复回复、语气失控、平台规则风险;
  13. 持续学习机制:基于 Eval / Trace 定期更新 slots、Flow、话术策略和决策卡库。

这些工作是传统客服 SaaS 团队通常不具备的 AI Agent specific 能力,也是生产系统建设成本与价值所在。

Phase 3 的 Agent Runtime 技术选型

生产系统不应一开始假设必须自研全部 Agent 框架,也不应直接绑定某个单一供应商。更合理的方式是先完成技术选型评估,再根据小拇指的数据接入条件、账号规模、团队能力和安全要求,决定采用「自研 Runtime、开源框架、商业 Agent 平台,或混合方案」。

技术选型至少需要评估以下问题:

  1. Agent 编排方式:采用图式工作流、状态机、多 Agent 协作,还是轻量规则 + LLM 混合;
  2. 状态持久化:每条 lead 的 slots、当前状态、历史动作、用户反馈是否能被保存、暂停、恢复和追踪;
  3. Human-in-the-loop:哪些动作必须暂停等待人工确认,哪些低风险回复可以自动执行;
  4. Tool calling:Agent 如何调用产品库、门店库、套餐库、价格/工时规则、历史对话、Eval/Trace 表;
  5. Guardrails:如何防止错误报价、越权承诺、重复回复、误导用户、违反平台规则;
  6. Handoff:什么时候从 AI 回复转给人工客服、门店、职人、投诉处理或销售负责人;
  7. Tracing:每一次模型判断、工具调用、人工修改、最终回复和用户反馈是否可追溯;
  8. 版本管理:Contract、决策卡、Flow、Prompt、业务规则更新后,如何记录版本与回滚;
  9. 成本管理:如何根据任务难度选择不同模型,控制 token、并发、上下文长度和调用次数;
  10. 部署方式:部署在甲方系统、乙方系统、云服务,还是以 API / 私有化 / 混合方式运行;
  11. 安全与权限:哪些数据可进入模型上下文,哪些必须脱敏,哪些账号动作需要审批;
  12. 监控与告警:系统如何发现异常回复、失败率升高、某类投诉变多、某个 Flow 效果下降。

因此,Phase 3 的生产建设应包含「Agent Runtime 技术方案设计」这一交付项,而不是只做传统 SaaS 的页面、字段和报表。该方案将评估自研、开源框架、商业平台或混合架构的可行性,并给出推荐路线。

可选技术路线示意

  1. 轻量自研 Runtime:适合 Phase 3A。以结构化 Prompt、决策卡库、数据库表、人工审核工作台为主,工程量较低,但自动化程度有限;
  2. 开源 Agent 框架路线:适合 Phase 3B。可基于具备状态管理、持久化、人类审核、工具调用、追踪能力的 Agent 框架搭建;
  3. 商业 Agent 平台路线:适合甲方希望较快上线,但愿意接受平台约束与持续服务费用的情况;
  4. 混合路线:核心决策结构、卡库、slots、Flow 由乙方掌握,底层模型与部分 Agent 编排能力可采用成熟框架或平台。

本协议阶段不预设最终技术路线。Phase 1/2 的目标是先形成可验证的决策结构与运行证据;Phase 3 再基于验证结果选择最合适的 Agent Runtime 技术路线。

国内部署与平台适配

考虑到本项目主要运行在国内业务环境中,Phase 3 的 Agent Runtime 技术选型应优先评估国内可部署、可合规、可持续运维的模型与平台生态,包括但不限于字节系、阿里云、腾讯云、智谱、Kimi、MiniMax 等大模型与智能体平台。

其中,抖音评论/私信属于本项目最关键的数据入口。若未来存在与抖音企业号、抖音开放平台、服务市场工具或字节系 Agent 平台更顺畅的接入方式,应优先评估其可行性。但本项目不预设「字节系方案一定可获得平台级特权」,也不把抖音全量接口开放作为 Phase 3 的唯一前提。

国内平台适配至少需要评估以下问题:

  1. 抖音评论/私信是否可通过官方开放能力、企业号能力、服务市场工具、后台导出、RPA 或人工批量方式进入系统;
  2. 字节系 Agent 平台是否在抖音生态、企业号消息、评论管理、服务商工具方面具备更好的集成路径;
  3. 阿里云百炼、腾讯云智能体开发平台、智谱、Kimi、MiniMax 等平台是否能满足模型调用、工作流编排、工具调用、知识库、追踪、部署、权限、安全与成本控制要求;
  4. 是否需要采用多模型策略:例如高复杂度判断使用强推理模型,低风险分类/抽取使用低成本模型;
  5. 是否需要采用混合架构:国内模型负责线上运行,乙方保留决策卡库、slots、Flow、Eval/Trace 方法论与运行规则;
  6. 是否需要私有化、专有云或甲方云环境部署,以满足数据安全、成本、权限和审计要求;
  7. 是否支持对每条 lead 的状态持久化、工具调用、人工审核、异常监控、版本回滚与 Trace 追踪。

因此,Phase 3 的技术方案不应提前绑定某一家模型或平台,而应在 Phase 1/2 验证业务有效性后,基于数据接入条件、账号规模、平台权限、成本、安全与可维护性,选择最合适的国内 Agent Runtime 技术路线。

Phase 3 的四层架构

Layer 1:数据层 / Data Layer

目标:把散落在抖音里的线索变成可读取、可追踪的 lead。

可能涉及:

  1. 抖音评论;
  2. 抖音私信;
  3. 官方账号;
  4. 门店账号;
  5. 职人账号;
  6. 外包客服回复记录;
  7. 用户后续反馈;
  8. 账号来源、门店、职人、时间戳等信息。

生产一期不一定要求一步到位接入全部数据。可根据数据可得性,从官方私信、外包客服已接触线索、高互动视频评论、职人主动筛选评论等高价值入口开始。生产一期的目标不是「抖音全量接入」,而是让可获得线索先进入决策运行闭环;如果业务效果成立,再逐步扩展数据入口、账号范围和自动化程度。

Layer 2:决策层 / Decision Layer

目标:让系统知道「这条线索现在处于什么用户决策状态,下一步应该做什么」。

可能包含:

  1. Contract;
  2. slots ontology;
  3. 决策结构卡库;
  4. Flow / NBA;
  5. 禁忌边界;
  6. 业务规则;
  7. 策略更新机制。

Layer 3:执行层 / Execution Layer

目标:把 AI 策略真正用于业务回复和线索推进。

可分为三种成熟度:

  1. AI 建议 + 人工确认发送;
  2. 低风险自动回复,高风险人工确认;
  3. 全自动策略回复 + 人工抽检。

生产系统不应从第一天就追求全自动回复,而应先建立可控、可解释、可回滚的半自动执行机制。

Layer 4:学习层 / Eval & Trace Layer

目标:记录每一次策略动作和用户反馈,让系统开始学习自己的经验。

可能记录:

  1. AI 判断了什么结构;
  2. 补齐了哪些 slots;
  3. 推荐了什么 NBA;
  4. 人实际发了什么;
  5. 用户是否回复;
  6. 是否留资;
  7. 是否预约;
  8. 是否到店;
  9. 是否成交;
  10. 是否投诉;
  11. 哪些策略路径有效;
  12. 哪些 slots 是最大阻塞点。

最终形成运营看板,包括:哪类线索最容易转化、哪套话术更有效、哪个门店执行更好、哪些 slots 需要更新、哪些 Flow 需要调整。

生产系统可按数据可得性分为三档

A 档:轻量生产版

适用于抖音评论/私信无法稳定自动接入,但可通过人工、外包、批量导入方式获取高价值线索的情况。

可能包含:

  1. 人工或批量导入评论/私信;
  2. AI 识别结构、补 slots、生成建议回复;
  3. 人工审核与发送;
  4. 简单 Eval / Trace 记录;
  5. 基础运营看板。

建议费用:约人民币 1,000,000 元起,具体另行评估。

B 档:标准生产版

适用于可以通过工具、RPA、后台导出或部分系统接口持续获取评论/私信数据的情况。

可能包含:

  1. 评论/私信半自动接入;
  2. Lead 表、Conversation 表、Action 表、Eval 表、Trace 表建设;
  3. 决策 Runtime 系统;
  4. 人工审核工作台;
  5. 低风险自动回复,高风险人工确认;
  6. 策略效果看板;
  7. 权限与角色管理。

建议费用:约人民币 2,000,000 元起,具体另行评估。

C 档:增强生产版

适用于多账号、多门店、多角色、多业务线并行运行,且甲方希望形成持续经营型 AI 决策系统的情况。

可能包含:

  1. 官方账号、门店账号、职人账号、外包客服账号的多入口管理;
  2. 多账号、多门店、多角色权限体系;
  3. 自动化或半自动化数据接入;
  4. 决策结构卡库持续更新;
  5. slots mining 与 Flow refinement;
  6. Eval / Trace / Dashboard;
  7. 与现有 CRM、门店系统、订单系统或其他内部系统的连接;
  8. 策略迭代与效果归因。

建议费用:人民币 3,000,000 元以上,具体依据系统边界与接入复杂度另行评估。

10.3 长期效果优化与分成

如 Phase 3 建设完成并产生明确业务增量,双方可进一步讨论长期合作模式,包括但不限于:

  1. 月度策略优化服务费;
  2. 按新增线索转化效果收取绩效费用;
  3. 按新增 GMV、到店、订单、复购或其他双方认可指标进行效果分成;
  4. 持续 slots mining、Flow 优化、卡库迭代和运营看板复盘服务。

参考路径:

↑ 返回阅读导航

十一、关于抖音数据接入的说明

本项目的数据入口为抖音评论与私信。双方确认以下事实:

  1. 抖音评论/私信的数据接入,受抖音平台开放能力、企业号权限、服务市场工具可用性等因素影响,存在不确定性;
  2. Phase 1 不承诺必须接入抖音官方 API 或实现全量自动化数据获取;
  3. Phase 1 的数据获取方式以人工截图、后台导出、RPA 或外包客服月报为主;
  4. Phase 3 的数据接入方案,将根据 Phase 1/2 验证结果和当时抖音平台开放能力,另行评估技术可行性与成本;
  5. 若因抖音平台政策变化导致数据接入方式需要调整,双方应协商解决,不构成乙方违约。
↑ 返回阅读导航

十二、知识产权与保密

  1. Phase 1 中产生的决策结构库、slots ontology、决策卡库、Flow/NBA 库、Contract 等知识资产,归乙方所有,但甲方在合作期间享有使用权;
  2. Phase 1 中基于甲方业务数据产生的特定业务规则、禁忌边界、话术模板等,归甲方所有;
  3. 双方对合作过程中获取的对方商业信息、用户数据、业务规则等负有保密义务;
  4. 未经对方书面同意,任何一方不得将合作内容、数据、成果向第三方披露或用于本协议以外的目的。
↑ 返回阅读导航

十三、验收方式

Phase 1 以交付物提交与复盘会议作为验收方式。

验收重点不是承诺最终成交结果,而是确认:

  1. 是否完成任务 Contract、结构库、slots、Flow/NBA、工作台 Prompt;
  2. 是否完成不少于 20 条真实线索的人工辅助运行;
  3. 是否完成 Eval 与 Trace 样本复盘;
  4. 是否给出清晰的 Phase 2 与 Phase 3 路线图;
  5. 是否能基于样本观察判断该体系是否具备继续投入价值。
↑ 返回阅读导航

十四、项目周期

Phase 1 项目周期为 6 周,自甲方支付启动款且乙方确认收到必要基础资料之日起计算。

如因甲方资料、业务规则、执行人员或账号操作配合延迟,项目周期相应顺延。

↑ 返回阅读导航

十五、其他

  1. 本协议未尽事宜,双方可通过补充协议确认;
  2. Phase 2、Phase 3 及长期效果优化合作不包含在本协议费用中;
  3. 双方确认,本项目为探索性 Pilot,存在业务、数据、平台规则、执行配合等不确定性;
  4. 双方同意以阶段性验证、阶段性复盘、阶段性决策的方式推进项目。
↑ 返回阅读导航

附一:从 Pilot 到生产的关键判断

本项目采取分阶段方式推进,是因为生产级 AI Agent 系统建设具有明显的不确定性和工程复杂度。Phase 1 的价值不在于回避这些复杂度,而在于先回答最关键的问题:

当一条真实抖音评论/私信进入决策结构后,AI 生成的策略回复是否能比普通回复更好地推动用户继续往前走?

如果答案是否定的,则不应贸然进入生产系统建设;如果答案是肯定的,则说明后续数据接入、团队运行验证和生产系统投入具备业务依据。

因此,Phase 1 是生产系统建设前的必要验证,不是生产系统的替代品。Phase 2 是组织运行能力验证,Phase 3 才是系统化建设。

↑ 返回阅读导航

附二:生产系统不是普通 SaaS 的原因

普通 SaaS 通常围绕字段、流程、权限、报表展开;本项目的生产系统还需要处理 AI Agent 的任务运行问题:

  1. 每条线索进入系统后,AI 要先判断它属于哪种用户决策结构;
  2. AI 要自动补齐这条线索的关键 slots;
  3. AI 要根据 Contract、业务规则和决策卡库选择下一步 Flow / NBA;
  4. AI 要生成可执行、合规、符合小拇指业务边界的回复;
  5. 系统要记录用户反馈,并把结果沉淀为 Eval / Trace;
  6. 系统要基于真实反馈持续优化 slots、Flow、话术和决策卡。

这意味着,生产系统的核心不是「把 AI 接到客服窗口」,而是建立一个可以持续运行、持续记录、持续学习的线索决策 Agent Runtime。

↑ 返回阅读导航

附:一句话项目定义

本项目不是建设一个普通 AI 客服,而是通过小拇指真实抖音评论/私信,验证一套「用户决策结构 → slots → Flow/NBA → AI 策略回复 → Eval/Trace」的决策智能体运行方式,判断其是否具备进一步团队化运行和生产级系统化落地的价值。

↑ 返回阅读导航