导读 本文介绍了基于知识库构建数据 Agent——及其在 CDP 中的运营实践。
1. 引言：从产品到“陪跑”的挑战
2. 下一代产品：从知识库到 Agent
3. 知识库的构建（SKB）
4. 数据 Agent：神策 AI 智能分析师
5. 神策 AI 智能运营师
6. JTracking：一个 AI Native 的海外探索
7. 综合案例：AI Agent 在银行业的实践
8. 未来展望：从“卖能力”到“卖确定性”
分享嘉宾｜曹犟 神策数据 联合创始人 & CTO
内容校对｜郭慧敏
出品社区｜DataFun
01
引言：从产品到“陪跑”的挑战
在过去十余年的发展中，神策数据构建了一套围绕数据驱动的产品全景图。这套体系以客户数据平台（CDP）和数据仓库为基座，负责接入、治理和管理来自 SDK、API、数据湖等多种来源的数据，并提供分群、标签等能力。
在此基座之上，有两个核心应用：
神策分析：作为用户行为分析工具，它提供了行为分析、用户画像、指标管理、智能洞察等功能。
神策智能运营：这是一个典型的营销自动化（MA）产品，强调数据不仅用于分析决策，更要直接驱动和编排对用户的精细化运营，包含流程画布、运营计划、通道管理等模块。
此外，我们还有广告分析（类似于国内的 AppsFlyer 或 Adjust）和 A/B 测试产品。整个产品思路是打通从数据采集、处理、分析到最终行动（Action）的完整链路。
然而，在服务了 2500+ 家客户后，我们发现，即使提供了完整的产品链路，要真正实现“数据驱动”，企业依然面临着巨大的鸿沟：
技术鸿沟：搭建和维护一个复杂的数据分析与用户运营系统，需要专业的技术知识和技能。这对于许多企业而言，意味着高昂的人力物力投入以及持续的技术更新压力。
数据鸿沟：数据的价值依赖于治理，没有治理的数据是“Garbage In, Garbage Out”。随着数据量激增，治理的挑战也越大。同时，不同行业、不同企业的业务场景各异，如何构建有效的数据模型和指标体系，本身就是一道难题。
业务落地鸿沟：数据驱动的核心是业务闭环。企业需要将高阶的业务目标拆解为可执行的运营目标，再制定运营策略，最后通过数据分析对结果进行归因，形成迭代。但在实践中，如何准确拆解目标？如何制定有效策略？如何准确归因？这些问题常常阻碍业务闭环的形成。
管理挑战：上述三个鸿沟共同构成了一个复杂的管理问题。它需要技术、数据和业务专家之间的高效协作，但这背后涉及跨部门的沟通机制、利益协调和信息共享，挑战重重。
神策“陪跑”模式的探索与局限
面对这些鸿沟，我们意识到，仅仅“卖工具”是远远不够的。客户需要的不是一个功能繁杂的软件，而是实实在在的业务结果。
为此，公司尝试了一种“陪跑”服务，派出自己的业务专家，像客户的内部员工一样，深度参与到他们的业务中，帮助他们拆解指标、制定运营计划、使用工具执行并分析结果。
例如，团队曾服务一家知名西式快餐企业。他们的一款主力产品“草莓堡”销量持续下滑，计划在口味升级后，以 8.8 元的低价重新推广。
陪跑团队介入后，首先利用神策分析对历史数据进行挖掘。通过人群画像对比，发现购买“草莓堡”的用户群体呈现出“偏好多人餐”和“笔单价较高”的特征。
基于这一洞察，判断单纯的 8.8 元低价策略可能并不匹配核心用户的偏好。于是，制定了 A/B 测试策略：
策略 A（高门槛）：针对用户偏好，推出“双人餐 5 件套，39 元起”。
策略 B（低价）：按照原计划，主推“1 个汉堡，8.8 元”。
最终的推广复盘数据显示，高门槛的策略A无论在活动期间的营业额增量（近 3 倍于低价组），还是在活动后的客群留存消费上，都显著优于低价策略B。整体策略组（A+B）相比空白对照组，营业额提升了 2.3 倍。
这个案例证明了“陪跑”的价值。但作为一家产品公司，我们也深刻认识到“陪跑”模式的局限性：
商业模式不可持续：人力咨询和陪跑服务的毛利远低于标准化产品，难以规模化。
依赖专家个人能力：陪跑效果高度依赖业务专家的个人经验和行业理解。这些知识沉淀在文档或个人大脑中，一旦专家离职，知识便随之流失。
“陪跑”模式治标不治本。我们需要一种新的方式，将业务专家的智慧沉淀下来，让产品本身就能解决业务落地的问题。人工智能（AI）的浪潮为此提供了可能。
02
下一代产品：从知识库到 Agent
我们开始思考，如何将“陪跑”过程中最有价值的部分——即业务专家的经验和知识——产品化、系统化。
1. 业务目标驱动的知识视图
团队将“陪跑”的完整流程进行了抽象。它始于一个“业务目标”（如提升 GMV），需要被拆解为具体的“运营目标”（如提升客单价或复购率）。基于对用户的理解，我们制定“运营策略”（如高门槛套餐），执行后产生“运营结果”。最后，通过“归因分析”来判断结果的成效，并指导下一步“迭代”。
这个“目标拆解 -> 策略制定 -> 结果归因 -> 知识迭代”的闭环，本身就是一套可以被管理的知识体系。
我们希望构建一个“神策知识库”，用来承载和管理这些知识，包括：
管理实践：如 OKR/KPI 的目标拆解方法。
运营策略库：沉淀不同行业、不同场景下的最佳分群策略、有效用户路径等。
分析与归因：包括常用的归因逻辑、辅助指标和分析看板。
用户偏好：如不同人群对渠道、时间、内容、权益的偏好。
通过人工经验的数据化验证、历史运营数据的挖掘，以及数据经验的人工确认，将这些隐性知识显性化、结构化地存入知识库。
2. 业务目标驱动的产品视图
在新的产品视图下，底层的 CDP 和上层的分析
数据分析、智能运营等产品依然存在。但在它们之间，我们加入了新的核心层次：
知识层：从底层数据和外部经验中抽取知识，构建统一语义层和知识引擎。
AI Driver(s)：基于知识引擎，构建一系列的 AI Agent（智能体），用于驱动数据洞察、指标生成和策略生成，从而赋能上层的分析与运营应用。
03
知识库的构建（SKB）
构建 Agent 的前提是构建一个高质量的知识库。团队从数据建模的视角重新设计了这一架构。
1. 知识库的数据建模架构
数据层：最底层依然是传统的数据仓库或数据湖，按照业务域治理数据，如主数据表（Master data table）和事务数据表（Transactional data table）。
语义层：这是为了让 AI 更容易理解数据而新增的虚拟层。它不存储实体数据，而是定义数据层中不同表、不同字段之间的关联关系和业务含义。例如，AI 需要知道“amount”字段到底是指“订单金额”还是“实付金额”。
指标层：用于定义 AI 无法（或不应）自行推断的核心业务指标。例如，“活跃用户”这一定义在每家企业都可能不同（如“3 个月内登录超过 1 次”+“个人信息维护度大于 70%”）。这一层将复杂的计算逻辑和业务口径固化下来，确保 AI 调用时的准确性。
MCP 层：将指标层和语义层封装起来，提供给 Agent 调用的中间层。
Agent 层：在最顶层，预定义各种场景的数据处理逻辑、跨业务域的数据查询和整合逻辑，供上层应用调用。
2. 场景化的知识逐层渗入
为了实现对知识的精确控制，将其分为三个层面：
知识/数据准备：这是最基础的工程处理。对非结构化数据（如 PDF、PPT 文档）进行场景化切片（Chunking），确保切分的片段在语义上完整；对结构化数据（如表格字段）进行向量化，以便模型理解和检索。
知识构建：这是狭义上的知识库构建。包括建立同义词表、进行歧义消解、定义默认关联信息、配置模糊匹配规则，乃至构建知识图谱，确保 AI 能准确理解查询意图。
工作流配置：这是知识的应用层。需要结合业务域和行业 Know-how，配置多轮对话编排、上下文关键词提取、用户画像补全和话术模板，最终驱动不同的 Agent 执行任务。
3. 神策知识库（SKB）产品
基于上述理念，打造了神策知识库（SKB），它既是后续 Agent 的基础，也是一个可单独交付的企业级严肃知识问答产品，追求 90% 以上的精确度。
其核心功能包括：
知识加工：支持自部署模型（OCR、布局识别等）和第三方解析，对文档进行智能切片。
精确度提升：通过独立的 FAQ 管理、AI 生成相似问法、知识标签、评测中心等工具，持续优化问答准确率。
运营管理：提供多层级文件夹、专业/敏感词库、业务知识维护、细粒度数据权限控制。
系统管理：支持与企业自有的账号权限体系（如 LDAP）和 IM/OA 系统（企微/飞书）无缝对接。
4. 知识的分层体系
在 SKB 内部，将知识梳理为五个层级，自下而上，通用性递减，专用性递增：
神策产品知识：最底层，关于神策智能运营、神策分析等产品如何使用的功能逻辑。
跨行业通用知识：如 AARRR 模型、北极星指标等通用的分析与营销方法论。
行业级通用知识：特定行业的“黑话”和通用逻辑，如银行业的“总行/分行”、“零售业务”等，以及行业通用的数据分析和策略设计方法。
行业场景级知识：特定行业中的特定业务场景，如银行业的“开门红”营销活动、零售行业的“618”大促等场景的增长思路。
企业级专属知识：顶层，每家企业独有的知识。包括专属的元数据定义、历史策略库、内部业务术语、运营要素和组织架构说明等。
04
数据 Agent：神策 AI 智能分析师
在构建了坚实的知识库基础后，我们开发了第一个核心 Agent——AI 智能分析师，它直接面向神策分析产品。
1. 业务人员在数据分析中的真实困境
我们之所以开发 AI 分析师，是因为观察到业务人员在数据分析中面临四大真实困境：
数据认知门槛高：神策的数据模型（Event-User 模型、多实体模型）相比传统数据表已经极大地简化了理解成本。但即便如此，要让非技术背景的业务人员真正理解复杂的表结构、专业的字段含义和数据间的关联，依然是一个巨大的挑战。
产品使用门槛高：任何功能强大的分析工具都不可避免地带来了复杂性。一个功能繁多的产品，意味着高昂的学习成本。新员工或非高频用户很难记住所有操作界面和功能路径。
分析过程耗时费力：一次有效的数据分析，往往是一个“体力活”。分析师需要进行大量的手动点选配置，反复调整数据的展现形式和分析口径，整个过程充满了重复性的劳动。
业务洞察要求高：数据分析的本质是业务分析。它不仅要求懂数据，更要求懂业务。如何从纷繁的数据中识别异常和规律，如何进行严谨的多维度下钻分析，这需要深厚的业务知识和专业的数据素养。
2. 神策AI智能分析师的定位与能力
神策 AI 智能分析师，其产品定位不是要取代业务专家，而是成为他们身边最得力的“数据助手”。其核心任务是帮助业务专家更快速地提取和整理数据，敏锐地发现数据中的蛛丝马迹，并给出有价值的初步建议。
它目前还不是一个 L4 级别的全自动系统，但它具备三大核心能力：
精准理解用户问题：能将模糊的业务问题（如“最近业务不太好，看看怎么回事”）通过多轮对话沟通，转化为清晰的数据分析需求（明确具体的业务指标和时间段）。
深度理解数据并调用工具：基于知识库中的语义层和指标层，理解数据的业务含义，并在正确的时机、正确地调用查询接口（Open API）以获取准确的数据。
初步解读数据并给出建议：在准确获取数据后，能进行初步解读，发现潜在洞察，结合业务知识为用户提供有价值的建议（例如，发现某产品销量下降时，提示可能的原因）。
3. 实践场景与演进
神策 AI 分析师主要应用于两大场景：
指标异动分析：当关键指标（如 DAU、GMV）出现异常波动时，AI 能快速自动完成异动归因分析，通过多维度拆解、可视化对比和智能排查，帮助业务人员快速定位问题根因，大幅提升决策效率。
经营分析报告：对于耗时费力的周报、月报，神策 AI 分析师可以用一句话生成报告初稿。它能自动汇总概览、按渠道/品类/客群等维度进行拆解、生成同比环比图表，并高亮异常与亮点。运营人员只需少量修订即可提交，显著提效。
在实践中，我们最早的验证方案是使用 Cursor + MCP。利用 Cursor 自带的顶尖大模型（如 Claude）的多轮对话能力，结合神策封装的 MCP 接口。这个方案开发成本极低，快速验证了可行性。但局限也很明显：Cursor 是为开发者设计的工具，对于业务人员来说使用门槛依然很高。
因此，最终开发了独立的 Web Agent 交互界面。这个界面设计简洁直观，更符合业务人员的操作习惯，让他们能轻松地提出数据分析需求。
4. 实践心得
在开发 AI 智能分析师的过程中，我们积累了三个核心心得：
心得一：大模型（LLM）能力飞跃是基础 相较于一两年前，今天顶尖的 LLM 在上下文理解、遵循指令方面有了质的飞跃。在生成复杂的 API 查询或 SQL 请求时，过去的大模型可能需要反复修正，而现在，只要在提示词（Prompt）中给出清晰的文字描述和一两个调用示例（One-shot/Few-shot），顶尖大模型几乎可以一次性生成完全正确的请求。这是构建可靠 Agent 的关键前提。
心得二：指标口径 + 数据语义，是提升问答准确率的关键 AI 的回答必须准确，否则就是“答得越快，错得越离谱”。准确率的保障来自于知识库。首先，AI 必须理解数据语义，即数据表里的字段（如 amount, status）的具体业务含义。其次，AI 必须遵循指标口径。每个企业对核心指标（如 GMV）的定义都不同，如果口径不明确，AI 的回答就可能是错误的。神策的“指标平台”和“语义层”正是为了解决这个问题，将这些知识前置，避免 AI 产生“正确的废话”或“危险的错误”。
心得三：用对框架，平衡开发效率与可靠性 在实现复杂的 Agent 时，我们面临一个选择：是采用“可编排的流程”（Workflow Agent）还是“可托管的能力”（SDK Agent）？
Workflow Agent（如使用 LangGraph）：其优势在于灵活，状态机和节点清晰，复杂的多步推理、分支、回滚都可控，便于嵌入语义层、RAG 和工具编排。它适用于复杂业务编排、强流程合规、需要细粒度状态控制的场景。
SDK Agent（如使用 Claude Agent SDK）：其优势在于内置了上下文压缩、工具权限、会话管理等生产特性，开箱即用，开发效率高。它适用于快速落地、强工具与权限治理、更多依赖 LLM 本身能力的场景。
目前，在不同场景下同时使用了两种方式，尚未有定论哪种是绝对的最优解，这取决于具体的业务需求。
05
神策 AI 智能运营师
在神策 AI 智能分析师解决了“看数据”的问题后，我们自然而然地推出了神策 AI 智能运营师，用以解决“做运营”的问题。
神策 AI 智能运营师的核心任务是：根据分析洞察的结果、对人群标签和分群的理解、以及既定的业务目标，基于营销知识库，自动创建一个复杂的运营计划（在神策产品中承载为“流程画布”）。
这解决了传统运营的两个痛点：
创建复杂运营画布本身存在较高的产品使用门槛。
企业在制定策略时，迫切希望了解行业内的最佳实践，而不仅仅是自己摸索。
AI 智能运营师采用了一个多 Agent 协作的架构，包括：
策略设计 Agent：负责初步的策略构思。
策略优化 Agent：对初步策略进行迭代调整。
策略创建 Agent：将策略翻译为可执行的流程画布。
策略预测 Agent：在执行前预估策略效果。
策略洞察/检索 Agent：从知识库中检索相关知识和历史策略。
用户可以通过自然语言提出需求（如“为新客设计一个提升首购的活动”），AI 运营师便能自动生成一个包含用户分群、触发时机、多通道触达（APP Push、短信等）、A/B 测试和后续判断节点的完整流程画布。用户还可以在画布基础上，通过对话进行局部的微调。
06
JTracking：一个 AI Native 的海外探索
上述两个 Agent 都是在神策原有产品架构上进行的“AI+”赋能。与此同时，也在探索一种完全不同的路径：从零开始打造一个 AI Native 的产品。
JTracking 就是团队的尝试。它完全面向海外市场，围绕 Google 生态（特别是 Google Analytics 和 Google Tag Manager）构建。
JTracking 是一个 Web 用户旅程分析及优化的 Agent 套件，包含三个核心 Agent：
Track Agent：解决海外独立站最头痛的“埋点”问题。用户只需输入网址，AI 就能自动分析网站结构，设计一套符合 GA 规范的埋点方案（Tracking Plan），并一键部署到 GTM 中。这能将过去需要数十小时的埋点工作缩短到 30 分钟。
Insight Agent：基于自然语言的用户行为指标分析 Agent。它相当于一个 GA 的轻量化分析插件，用户通过对话即可查询和分析数据。
Vision Journey Agent（开发中）：基于视觉模型的用户行为分析。它类似于“Session Replay”工具，AI 通过观看用户行为录屏（视频），自动分析用户的关键卡点和流失原因，并触发相应的行动。
JTracking 采用纯粹的 SaaS 订阅模式，用户可在线自助付费，无需销售介入。在实践中，我们也获得了不同于国内市场的认知：
心得一：用户信任是前提，GUI 不可或缺 最初设想 AI Native 产品的工作模式应“一气呵成”，尽量减少用户操作。但海外用户的反馈却不一样。首先，Global 用户对“可控性”非常关注，AI 执行的每一步，他们都希望点击确认，以了解风险。其次，团队本想用 Chatbox（对话框）完成所有交互，但用户反馈，对于信息列表的更新（增删改查），他们仍然更希望使用传统的 GUI（图形界面）操作。这表明，AI Native 的理想形态可能是 GUI + Chatbox 的结合，而非纯粹的对话。
心得二：海外重获客，国内重运营 国内市场更重视存量用户的精细化运营，而海外市场（特别是独立站生态），广告效果追踪和营销获客是更关键的需求。这种市场差异决定了产品设计的侧重点必须不同。
07
综合案例：AI Agent 在银行业的实践
最后，我们通过一个正在某银行实践的零售数据团队案例，来串联展示神策 AI 分析师和神策 AI 运营师如何协同工作，完成一个完整的月度运营管理流程。
步骤一：智能月报生成（分析 Agent） 月初，AI 分析师自动抓取核心指标，生成月度经营报告，并对数据表现给出初步的解读和建议。
步骤二：异动指标归因（分析 Agent） 运营人员发现报告中“存款销售额”指标下滑。AI分析师立即介入，针对该异动指标进行深度的多维度归因分析，定位到具体是哪些客群、哪些渠道或哪些产品导致了下滑。
步骤三：策略洞察与建议（分析 Agent + 知识库） AI 结合行内的归因数据，并调用知识库中关于“宏观市场背景”、“竞品动态”等外部通用知识，输出初步的策略建议（例如：“鉴于当前宏观环境，建议针对高净值用户强化大额存单的挽留”）。
步骤四：策略方案设计（运营 Agent + 知识库） 运营人员采纳该建议。AI运营师启动，调用知识库中的行业场景级知识（如“银行业高净值用户挽留通用策略模板”），将文字建议自动转化为一个可执行的、包含具体客群和触达节奏的流程画布方案。
步骤五：策略动态调优（运营 Agent + 知识库） 通用的策略方案还需适配本行业务。AI运营师会进一步调用企业专属知识（如“本行定义的高净值客群”、“本行在售的存款/理财产品列表”），对流程画布进行动态调优，使策略更具适配性。
步骤六：效果仿真预测与执行（运营 Agent） 在策略上线前，AI 还可以进行智能预估。例如，AI Agent 可以扮演一个“高净值用户”，模拟他对即将推送的运营计划可能产生的反应，从而预测策略的成功率。预测通过后，策略正式上线执行。执行后的效果数据会再次回流，由分析 Agent 进行归因，形成完整的运营闭环。
08
未来展望：从“卖能力”到“卖确定性”
总结而言，我们认为大模型为正处困局中的中国 To B 软件行业带来了新的变量。
传统的 To B 困局在于：
卖工具，不卖结果：客户买了“健身卡”（软件），但没有“瘦”（产生业务价值）。
ROI 难以量化：投入上百万购买工具，最终带来了多少收益，往往说不清楚。
风险全由客户承担：软件交付完成后，用得好不好，风险全在客户一方。
甲乙方利益对立：交付验收成为双方博弈的关键节点。
而大模型和 Agent 带来的变革，在于它让“按结果付费”成为了可能：
决策智能化：AI 不仅提供工具，更能辅助甚至自动执行决策。
效果可归因：通过更精细的模型和数据链路，策略的效果变得清晰可归因。
持续优化闭环：如果能交付 L4 级别的 Agent（从分析、决策到执行全闭环），AI 就能在快速的反馈中不断迭代，提升能力。
最终，我们希望迎来一个“企业服务即按灯”的时代。To B 厂商卖的不再是“卖能力”（软件功能），而是“卖确定性”（业务结果）。
在这种新模式下：
客户可以降低决策门槛，无需在功能列表上“比价”。
供应商可以转移和共担风险，实现“出效果再付费”。
双方关系从“甲乙方对立”转变为“从对立到共生”的长期伙伴。
客户真正买到了确定性，而供应商也获得了可持续的商业回报。
