搭数据团队，先别急着招人。先回答两个问题：这家公司现在最需要数据解决什么，手头的数据和口径现状是什么。目标不同，配置就不同，一个做增长诊断的团队和一个做数据中台的团队，需要的人可能完全是两批。
这篇文章按企业规模给一套从零搭建的方法。先讲核心角色和职责边界，再讲不同规模怎么配人，然后给一张角色、任务、交付物、复核人的分工表，最后说清哪些重复执行可以交给企业级 AI Agent 平台上的 Agent 协作，以及怎么用试点验收。如果你的团队已经跑起来，只是想引入 Agent，文末也留了升级路径。
一、先想清楚要解决什么数据问题
数据团队常见起点有三类。
第一类是业务已经跑起来，但取数慢、口径乱。运营问一个留存，财务给一个口径，销售又是另一个口径，每次都要人来拉数。这类团队优先解决数据可用性和口径统一，重点在数据工程和数据分析师。
第二类是业务要往前推进，缺的是预测和实验。比如要判断哪些用户会流失，要不要调整定价策略。这类需求才会真正用到数据科学家的模型能力。
第三类是数据量已经很大，但没有治理，权限、质量和合规都失控。这种情况更接近数据中台建设，要先补治理角色，再谈分析产出。
先分清自己落在哪一类，再决定第一个岗位招谁。很多团队搭不好，是因为一开始就照着大厂的组织架构招人，结果招来的数据科学家半年都在拉数。
二、核心角色与职责边界
不同公司把这类团队叫数据分析团队、数据科学团队或数据团队，叫法不同，负责的角色基本一致。一个成熟的数据团队通常由五个角色构成，Microsoft Learn 的数据分析角色课程把这五个角色讲得比较清楚，企业实际使用时可以合并，但职责边界基本不变。
数据工程师负责把数据从源系统搬到可分析的形态，建管道、清洗、保证数据及时可用。分析工程师负责把业务口径翻译成统一的数据定义，让全公司对净收入、留存这类指标只有一种解释。数据分析师负责出报表、跑专题、验证假设，把数据转成别人做决策要用的信息。数据科学家负责预测模型、实验设计和复杂归因，产出通常再回流到分析师的可视化里。业务分析师负责定义问题、确认关键 KPI，并把洞察转成领导能拍板的行动建议。
团队规模小时，这些角色会被合并。最常见的合并是业务分析师由业务负责人兼任，分析工程师并入数据分析师，数据科学家暂时不设。另外，数据科学家这个称呼在不同公司含义差别很大，有的指研究型岗位，有的只是高级分析师，招聘时要把具体任务写清楚。
关于比例，InfoQ 与 Synq 在 2024 年对 40 个顶级数据团队的分析显示，洞察类角色中位占比 46%，数据工程类 43%，机器学习类 11%。这个数字只能当参考，实际比例要跟着业务重点走，做增长的公司分析师多，做平台的工程师多。
三、不同规模怎么配角色
从零搭建，按规模分三档更实用。
准成长期企业，营收体量小、业务线少，先招一个偏业务的数据分析师。这个人的核心能力是把财务、销售、运营的口径捋顺，能在经营会上把数字讲清楚，会 SQL、会用一套 BI 工具。这个阶段的关键动作，是把最关键的十几个指标定义准、看得住，大数据架构可以等数据量真正上来再补。
成长期企业，业务线扩展到两三条，取数需求开始排队，可以扩到三人。一个数据分析师负责业务问题和报表，一个数据工程师负责管道和数据质量，一个业务对口人负责接需求、定 KPI、推动决策落地。三个人各守一段，避免所有取数都压在同一个人身上。
中型企业，业务线更多，口径开始成为问题，此时补一个分析工程师。他的任务是建语义层、统一指标定义，让同名指标在各部门只有一个口径。InfoQ 与 Synq 的研究还显示，大型公司设立专门数据治理职能的比例约 60%，其他规模约 20%，说明治理角色往往要等团队到一定规模后才单独成岗。
大型或规模型企业，数据团队人数超过几十人后，治理、平台、机器学习各自成组。这时数据治理要单独成岗，机器学习也要有专人维护模型，团队重心从交付报表转向平台能力和长期资产。
配置顺序可以遵循一个原则，先补能推动业务决策的角色，再补基础设施。分析师先于工程师，口径治理先于模型，这是从零搭建时比较稳妥的顺序。
四、角色、任务、交付物、复核人分工表
把角色和任务落到一张表里，是搭建时最实用的动作。下面这张表覆盖了重复取数、模型维护和业务判断三类高频任务。
| 角色 | 典型任务 | 交付物 | 复核人 | 验收标准 |
|---|---|---|---|---|
| 业务分析师 | 定义问题与 KPI，把业务问题转成数据问题 | 问题定义、KPI 清单、行动建议 | 业务负责人 | 建议能被业务采纳并进入决策 |
| 数据分析师 | 重复取数、专题分析、搭看板、验证假设 | 分析报告、看板、假设验证结果 | 业务分析师或业务负责人 | 报告直接回答业务问题，口径可复算 |
| 分析工程师 | 统一指标口径、建语义层、维护数据资产 | 语义模型、指标字典、口径文档 | 数据分析师与数据工程师 | 同名指标全公司只有一种定义 |
| 数据工程师 | 建管道、清洗、保证数据质量与及时性 | 数据表、ETL 脚本、数据质量报告 | 分析工程师或数据负责人 | 数据干净、及时、可追溯 |
| 数据科学家 | 预测建模、实验设计、复杂归因 | 模型、实验方案、效果评估 | 业务分析师与数据负责人 | 模型结果可复算，效果可度量 |
这张表有两个作用。第一，把每个人要交什么、谁负责看结果写清楚，避免产出报告就结束。第二，把复核人从数据团队内部拉出来，业务判断的任务由业务负责人复核，技术质量的任务由数据负责人复核，两条线分开。
五、把重复执行交给 Agent，人负责判断
分工表里有一类任务特别适合交给 Agent，重复取数、固定报表、口径核对、埋点方案与验证、模型例行监控。它们共同的特点是步骤清晰、结果可验证、不依赖临场业务判断。
判断标准可以这样记。如果一个任务过去需要多个角色接力排期，而且每个环节都有明确的对错标准，它就适合先 Agent 化。如果一个任务依赖的是业务判断和上下文，就保留给人。
ThinkingAI 的内部演示里，有一条交付全流程的 Agent 链，先出埋点方案，再落成代码埋点，接着调试验证，然后接进知识库沉淀，搭出可视化看板，最后接运营触达。整条链跑下来约 280 秒。拆开看，这些环节过去分别对应数据分析师、研发、QA、分析师和运营几个角色，一个需求落地快则一两周，慢则一个月。现在人退到关键节点做判断，埋点方案对不对、看板看哪几个指标、这次触达打给谁，执行交给 Agent。
需要说明，这是内部演示样例，反映的是链路可被压缩到什么程度，不代表每个企业马上就能达到同样用时。本文也不以人数减少作承诺，Agent 承接的是执行，人负责定义问题和复核结果，岗位会从执行向判断迁移。
在统一口径上，Agent 的作用更直接。企业知识库用单一事实源把净收入、留存这类指标固定为唯一定义，Agent 基于这个语义层回答自然语言问题，不同业务线问同一个指标，得到的是同一个口径。重复取数由此从人工排期变成即时问答。
六、落地顺序与试点验收
从零搭建，建议按这个顺序走，定目标、选第一个场景、配角色、上工具、跑通一条链路、沉淀口径。
先定一个能在一两个月内看到结果的小场景，比如把某条业务线的留存和付费看板做准，或者把经营会要用的五个指标口径统一。用这个小场景反向决定要配什么角色，比先画组织架构图更可靠。
跑通之后，用三件事验收。第一，指标口径可复算，换一个人按同样定义也能算出同样结果。第二，交付物可追溯，一个结论能回到原始数据和定义。第三，结果可复核，业务负责人能独立判断报告是否正确。三件事都能通过，这个团队才算立住了。
如果你的团队已经存在，只是想从 BI 看板往 AI 数据分析 Agent 升级，配置逻辑会不同，可以单独看《从 BI 看板升级到 AI 数据分析 Agent，团队需要做哪些准备？》。
常见问题
第一个数据人该招数据分析师还是数据工程师？
大多数情况下先招数据分析师。早期最需要的是把口径捋顺、把数字讲清楚的人，数据量还没大到必须先做工程。数据工程师可以等取数需求稳定后再补。
数据团队要多少人？
没有固定数字。准成长期一个人就够，成长期三到五人，业务线多了再按口径、工程、分析补人。InfoQ 与 Synq 对 40 个顶级数据团队的统计里，中型团队通常少于 35 人，但那是成熟科技公司的口径，普通企业不需要按这个标准对标。
数据科学家什么时候才需要？
当业务开始做预测、实验和复杂归因时再招。如果现在的主要任务是取数和报表，数据科学家大概率会被浪费在拉数上。
Agent 会让数据团队大幅缩编吗？
执行类岗位的重复任务会被承接，重复取数、固定报表这类工作可以由数据分析 Agent接手，但定义问题、判断口径、复核结果这些工作仍然需要人。更现实的变化是岗位重心从动手转向判断，团队人数是否减少取决于业务体量，不取决于 Agent 本身。
口径混乱怎么治理？
先找全公司最常用的十个指标，逐个统一定义并落到指标字典里，再让 Agent 和报表都从这套定义取数。口径治理先于模型和看板，成本最低。
数据团队搭得对不对，最终看三件事，问题有没有被定义清楚，口径能不能复算，结果有没有人复核。把这三件事立住，再让 Agent 接走重复执行，团队才有余力去做真正影响业务的判断。想进一步了解 Agent 怎么落到数据分析场景，可以到 ThinkingAI 官网申请演示体验。
