很多企业决定自建 Agent 时，第一反应是招几个算法工程师，把模型接进去。真正让项目卡住的，往往不是模型，而是人。业务说不清要什么，数据给不出统一口径，研发把 Agent 搭起来却没人验收，最后停在演示阶段。自建 Agent 需要的不是几个技术大牛，而是一支业务、数据、研发三方配合的最小团队，加上一套清晰的分工机制。 ThinkingAI 在和 1500 多家企业沟通 AI 落地时，遇到的也多是同一类分工难题。下面把角色清单、职责边界和团队规模一次讲清。
一、自建Agent需要哪些角色
1、最小可用团队由三类角色组成
自建 Agent 的团队可以拆成三块能力，缺一块都跑不远。
- 业务侧。业务负责人一名，负责定场景、定目标、定验收标准。业务专家一到两名，负责把一线经验讲成规则。
- 数据侧。数据工程师，负责数据接入、治理和权限。数据分析师，负责指标口径和业务语义。
- 研发侧。AI 工程或算法工程师，负责模型、工具调用和工作流。平台或后端工程师，负责系统集成、部署和观测。前端与测试工程师，负责交互和验收。
- 统筹角色。AI 产品经理或项目负责人，串联三方，对进度和结果负责。
团队规模不必一开始就配齐。真正的门槛是三块能力都有人负责，而不是每块都设一个岗位。
2、角色说的是能力，不是编制
小团队常见一人多职，数据分析师兼产品，后端工程师兼平台运维。只要每类决策有人拍板、每类交付物有人负责，这个团队就成立。编制可以精简，能力不能缺位，这是自建 Agent 团队配置的第一原则。
二、业务团队负责什么
1、定场景、定目标、定验收
业务团队的第一件事是收敛场景，不要一上来就做全能助手，先挑一个高频、规则相对清楚、出错可以回退的场景。业务负责人要回答三个问题，这个 Agent 服务谁，解决什么任务，做到什么程度算成功。没有可量化的验收标准，后面所有投入都无法判断值不值。 把首次响应时间、一次解决率、人工转接率写成指标，比反复讨论需求有用得多。
2、把隐性经验变成规则
业务专家的价值，是把老员工脑子里的判断讲出来。什么情况要升级人工，哪些话术不能承诺，异常订单怎么处理，这些内容要么写成规则，要么整理成知识文档。业务专家投入的时间，往往直接决定 Agent 上线后的准确率上限。
三、数据团队负责什么
1、接入、治理和权限
Agent 的回答质量，取决于它拿到什么数据。数据工程师负责把业务系统、数据库、文档和报表接进来，做清洗、去重和权限隔离。有两件事不能省。一是哪些数据敏感、谁能看、能不能进模型，必须有明确边界。二是数据怎么更新，是实时同步还是定时刷新。
2、统一指标口径和语义层
同一个指标在不同部门有两个算法，Agent 就会给出两个答案，这是企业落地最常见的问题。数据分析师要负责统一指标口径，并把业务术语、计算逻辑和取数范围整理成 Agent 能直接调用的结构。语义层建设得越早，后期返工越少。 具体做法可以参考 Agent 语义层建设指南，里面把口径治理讲得比较清楚。
四、研发团队负责什么
1、模型、工具和工作流
AI 工程师负责选模型、接工具、写提示词和搭工作流。重点不是追最强模型，而是让 Agent 在给定成本下稳定完成任务。多模型路由、失败重试、结果校验这些工程手段，比单纯堆参数更影响体验。
2、集成、部署和观测
平台或后端工程师负责把 Agent 接进现有系统，处理好鉴权、并发和日志。上线不等于结束，没有运行观测，就无法判断一次失败是模型问题、工具问题还是数据问题。 对数据合规要求高的企业，还要提前规划 私有化部署 方案。ThinkingAI 的 Agentic Engine 支持私有化部署和多 Agent 协作，这类成熟平台可以省掉一部分自建底座的工作。
3、FDE 打通业务现场和研发
自建 Agent 最容易断的一环，是业务现场和研发之间的翻译。FDE 即前沿部署工程师，承担的正是这个连接角色。业界普遍认为，这个概念最早由数据公司 Palantir 在 2010 年前后引入，用来服务那些说不清需求、数据又高度敏感的客户。FDE 不是等需求的后台研发，也不是讲完方法就走的顾问，而是走进业务现场，判断哪些环节值得交给 Agent、哪些判断必须留给人，再把一线问题带回产品。据行业报道，AWS 的 FDE 团队以五到六人一组、每个客户约 45 天的节奏推进落地。近一年这个岗位需求增长很快，据霞光智库《FDE行业研究报告》，美国 FDE 在招岗位从 2025 年 4 月的 643 个增至 2026 年 4 月的 5330 个，人才缺口超过六成。国内也在跟进，工业和信息化部开展的人工智能应用服务商培育专项行动，明确鼓励服务商搭建 FDE 团队。ThinkingAI 把长期交付中积累的经验沉淀为可复用的 Skill 和知识库，思路也是让一线经验不随人流失。对中小企业来说，不必单独设岗，可以由项目负责人或产品经理承担类似职责。
五、业务、数据、研发团队如何分工与协作
1、先划清职责边界
一句话概括分工，业务对做什么和值不值得做负责，数据对数据准不准负责，研发对系统稳不稳负责，三方共同对一次可验收的上线负责。边界清楚之后，很多扯皮会自动消失，因为讨论的变成了责任归属，而不是谁更忙。
2、用固定流程替代随时拉群
把协作固定成一条流程更有效。需求评审由业务牵头，确定场景和指标。口径对齐由业务和数据一起完成，把指标和术语定下来。研发实现由研发牵头，产出可测试的版本。试点验证三方共担，看指标是否达标。复盘迭代回到业务牵头，决定继续、调整还是停掉。每个节点都要有明确负责人和交付物，避免会开完没人跟进。
3、用责任矩阵避免三不管
责任矩阵把任务和责任人对齐。同一个任务只能有一个最终负责方，其他人是配合或参与。 场景定义和数据口径之所以容易漏，往往就是因为没人被指定为最终负责方。把这张表落下来，跨部门协调就有了依据。
六、团队规模怎么定
1、试点期，五到八人足够
试点期的目标是验证一个场景能不能跑通。通常业务一人、数据分析师一人、数据工程师一人、AI 工程一人、平台或后端一人，再加项目负责人，五到八人即可。这个阶段不必追求平台化，先用最小团队把闭环走通。
2、推广期，按场景复制
一个场景验证成功后，团队开始横向复制。每新增一个场景，增加对应的业务专家和一名数据或研发支持。这个阶段要开始沉淀可复用的工具、提示词和知识，否则每做一个 Agent 都要重来一遍。ThinkingAI 内部做过一次交付链路实验，把埋点方案、代码埋点、调试验证、知识沉淀、看板和运营触达串成一条链，整条链跑下来大约 280 秒，过去这些环节需要多个角色接力一两周。能被复用，才说明前面的职责和口径真正理清了。
3、平台化期，补上平台和治理角色
当企业里有多个 Agent 同时运行，团队重心会从做单个 Agent 转向做底座。这时需要增加平台工程、权限治理和运行观测的专职角色，把 Agent 的创建、发布、监控和下架纳入统一管理，避免每条业务线各建一套。分阶段怎么推进，可以参考 企业 Agent 落地路线图，同时提前把 Agent 安全与治理 纳入规划。
七、关于团队分工的常见问题
1、自建Agent最少需要几个人
三到四人可以起步，先把一个场景跑通。但要真正上线一个可验收的场景，五到八人更现实，因为业务、数据、研发三块能力都需要有人稳定投入。
2、没有算法团队能自建Agent吗
可以。模型和工具调用可以借助成熟的企业级平台，不必自己从零训练。但数据治理和业务专家这两块不能省，前者决定答案准不准，后者决定 Agent 懂不懂业务。
3、业务团队要投入多少时间
试点期业务负责人每周要固定投入时间参与评审和验收，业务专家则在前期集中一到两周梳理规则和知识。投入不足，场景定义和验收标准都会失真，项目很容易变成研发的自娱自乐。
4、自建还是采购更合适
判断标准不在预算多少，而在场景差异化和数据敏感度。场景高度差异化、数据敏感、打算长期投入的企业，适合自建或联合共建。场景通用、人力和预算有限的企业，可以先采购再逐步自建。 两种模式的取舍，可以参考 企业 AI Agent 建设模式对比。
5、数据团队不配合怎么办
把数据需求提到立项阶段，而不是研发开工后再要。同时明确数据责任人，让口径和权限的确认成为项目节点，而不是临时求助。责任落到人和时间点，配合度通常会明显改善。
