数字员工为何是AI Native组织的新流水线，天猫技术的协同层思考

本文探讨了AI Native组织中“数字员工”作为新流水线的核心价值。作者指出，当前多数方案聚焦于让AI自主完成任务的“执行层”，而真正稀缺的是解决人与人、人与AI之间目标对齐和上下文串联的“协同层”。真正的数字员工并非执行具体任务的Agent或面向个人的数字分身，而是以业务单元为边界、随时在线的“PM”角色。它通过IM群、协作板及会议等入口主动感知信息，拉齐上下文并派发任务，沉淀属于组织的资产而非个人效率。短期红利虽在执行层，但长期胜负手在于协同层，构建这条将各角色串联起来的新流水线才是关键。

上篇留下的那个问题

电动机替代蒸汽机的故事，作为AI转型的例子已经被讲了无数遍：工厂把蒸汽机换成电动机，效率三十年没起色，直到有人围绕电机把整条流水线重组了一遍，效率才真正起飞。那么问题来了：在AI Native的组织里，那条新的“流水线”到底是什么？

在上一篇《重构协同：关于AI Native团队的思考》里，我给出过一个判断：AI Native最大的变化，也许就是把“串联者”从人换成了Agent；而对公司来说，两个核心命题之一，就是要把“人、Agent、知识底座三者协同”的工具建好。我讲了“为什么”，但没讲“那个协同工具具体长什么样”。

这篇文章我想试着用我新的理解做个回答，我不敢说已经找到了答案，但我目前的判断是：“数字员工”，很可能就是那个协同工具，就是那条新的“流水线”。

这里说“流水线”，并不是它字面上那套“固定工位、固定次序”的产线形象——恰恰相反，流水线关键不在那一个个工位，而在于把工位串起来、让任务能一道道流下去的那套“串联机制”。所以当我说数字员工是那条新的流水线时，指的正是串联这个内核，而串联的本质，则是对齐目标和上下文。

我知道，一提“数字员工”，会觉得这个概念有点说烂了，脑子里也会浮现出公司的一堆内部产品——AgentForce（企业智能的数字员工）、CoTeam、QoderWake等等。但这里有一个基本问题一直没有讲清楚：一个数字员工到底该解决什么问题，它应该成为一个什么样的角色？这篇文章讲的，就是我个人对这个问题的一个更具象的理解。

观点总结：数字员工不是又一个被说烂的概念，而是那条新流水线的候选形态；真正的问题在于，我们始终没把它该扮演的角色想清楚。

协同层与执行层，我们更缺的那一半

要把角色想清楚，得先做一个区分——这也是这篇文章最想讲清楚的一点。

把串联者从人换成Agent，这件事的本质就是协同。所以，“数字员工”的核心目标，本就应该是解决协同的问题。我把这一层面叫做协同层；与它相对的，是执行层。两层解的是完全不同的两件事：

协同层：解决“人与人、人与AI之间，如何对齐目标与上下文”——本质是要把隐式的、线上线下的上下文搬上来，并“确定目标”，最后串联任务，而“目标”是执行层Harness的前提条件。
执行层：解决“AI如何自主地把一件事干完”，它的重要目标是通过Harness不断降低人工介入率。

这个区分很重要。回头看现有很多“数字员工”方案，会发现它们大多聚焦在执行层：比如强调AgentTeam，让你去定义开发、测试、产品，或者TeamLeader这样一个个角色的数字员工，然后人还是和这些角色打交道。这些角色，看起来更像是“流水线上执行工位”，有的方案甚至认真地讨论起对数字员工的“绩效考核”。但在我看来，给一个个执行角色贴上传统职能标签，并非关键；我们真正缺的，是把这些角色串起来的“流水线”本身。

这并不是说，执行层这一半不重要，而是它已是相对成熟——只是当下平台和方案选型极多，处于一种野蛮生长的状态。对企业内部而言，执行层更重要的命题，是收敛与统一：让沉淀下来的Harness工作流、技能、知识库能在组织范围内复用、产生复利。而协同层，则是我们目前还没补上的那一半，也是本文想重点谈的。

观点总结：执行层方案已相对成熟、正待收敛；真正稀缺、也最该补的，是把角色串起来的那条协同层的流水线。

什么才算“数字员工”

顺着协同层和执行层的区分，我想较真一下“数字员工”这个叫法本身。

人真正需要打交道的，是那个“协同者”身份的数字员工。至于它背后如何调度不同的Agent去干活，绝大多数人并不需要关心（只需要少数人关心）。所以：

背后那些干活的执行角色，我们可以叫它们Agent，但不必叫“数字员工”。因为它们不必成为数字员工——不必各自拥有记忆，只需按需动态创建，任务执行完就可以销毁。
只有那个协同者角色，才适合称“数字员工”。因为它要真的像一个员工那样干活。这就像真实的组织里，PM是那个稳定的对接人和责任人，而某个具体任务最终外包给了谁、用了什么工具，协作方其实并不需要知道。

至于它具体做什么，不妨照着一个尽职的PM去想象：拉群、把对的人拉进来、追问澄清，盯着目标往前推、到点催办、把风险和卡点主动亮出来，再把诉求、决策和经验一路记录、沉淀下来。而最核心的一件，是拉齐上下文、并派活——拉齐成员之间、以及成员与执行Agent之间的上下文，最终把一份足够清晰的任务派下去。

这里顺带还要区分一下——数字分身，我倾向于把它们看成两个东西。数字分身（或者个人助理），它面向的是个人，是个人的“分身”，代替的是个人的一部分工作，本质上仍然活在现有的那条流水线里；而数字员工，面向的是一个业务单元，是toB的，它沉淀下来的都是公司的资产，不属于任何个人。这个区分之所以重要，是因为它直接决定了“沉淀”归谁：分身沉淀的是个人的效率，人走了东西也跟着走；数字员工沉淀的是组织的资产，越用越厚，不随任何个人的流动而流失。

观点总结：只有“协同者”那个角色才叫数字员工——背后即用即弃的执行Agent不算，面向个人的数字分身也不算；前者让个人更快，数字员工要做的是让组织重构。

它是谁：一个业务单元维度、随时在线的“PM”，以及它怎么“感知”

如果要给这个协同者一个更具象的定位，我的答案是：它很像一个业务单元维度、随时在线的“PM角色”。它必须懂当前这块业务，并且会基于目标、围绕主题，主动去推进事项，而不是你问一句它答一句的机器人。

这里有个关键：它不只是接受一个任务然后去执行，而是需要尽可能多地渗透到员工真实的工作活动中（群里的讨论、会议的沟通、线下的即时交流……），为任务获取充分的上下文。所以，从技术实现上，它的关注点落在“感知”侧，而不是执行侧。工具是被动的，你不用它，它就待在那儿；而一个PM是主动的，它会追着目标、追着人、追着卡点往前走。这也正是协同层区别于执行层的地方：执行层追求的是“把交代的活干好”，协同层追求的是“没人交代，也知道该往哪儿推”。

而一个PM要干好活，第一道坎就是如何“感知”——信息进不来，后面的对齐、推进、派活都无从谈起。所以真正要解决的问题是：怎么把那些原本散在人的协作过程里的上下文、那些藏在线下的隐性知识，自然而然地搬到一个共享的上下文空间里来。

这个“共享的上下文空间”需要入口，可以分成线上和线下两类。

线上目前有两种常见形态：

IM群（钉钉群）：当下最合适的入口——传统上人协作的入口主要就是群，数字员工驻在群里，讨论和文档它都能“听”到、“收”到（类似Claude基于Slack那类思路）。
围绕工作项的协作板：各平台自己做的web形态，围绕一个工作项，通过评论、at来对齐，比如Aone的CoCo（可参考开源的Multica）。

而线下——会议，或即时的小范围沟通——则是应对复杂场景最常见、也最绕不开的方式：几乎没有哪个复杂需求，能只靠群聊就完成目标对齐。可也正因为它发生在线下，反而最难搬进共享空间，而且很多会议是急需提效的：现在只能靠钉钉AI听记事后补一份纪要，而听记缺上下文，记出来的常不尽如人意。更理想的形态，是数字人能像在场员工一样参与会议，随时可以cue它，或它主动发问，和它全双工实时沟通（有点像AI访谈那种虚拟的AI主持人）。我认为这会是未来一个重要方向——也许钉钉AI听记应当提供这种能力，且可定制、可注入上下文。

这三种入口，是一条从“即时、同步”到“延迟、异步”的变化线：会议和当面沟通协同强度最高、最即时，IM群居中，协作板最异步、最能留痕慢推。协同强度越高，越适合啃那些复杂、需要高频对齐的场景；越异步，越适合轻量、可以慢慢推进的事。一个理想的数字员工，应该能覆盖这条线的每一段。

关于入口层面，有个问题需要说明：群这种交互方式，对协同层很自然，但对执行层并不理想。拿Coding来说，很多人习惯实时看到CodeAgent的工作进展、代码变更——这种细粒度、强反馈的过程，塞进群聊里是别扭的。这也提醒我们，协同层和执行层的入口，不必、也不该是同一个东西，但它们背后应当要共享一个上下文空间。

观点总结：数字员工的真正诉求，不是一个全能机器人，而是一个懂业务、会主动推进的“PM”；而做好PM的前提是感知——把隐性上下文搬进一个共享空间，IM群是当下最好的入口，web是补充，而会议则是非常重要、却仍待补齐的一环。

承载它的平台能“拎包入住”，也能自定义

有了角色定位和感知入口，接下来的问题是：用什么平台把它承载起来？

我认为，一个管理协同数字员工的平台，至少要满足这么几点：

轻量：基于一个业务单元，就能快速创建出一个。
能拎包入住：新建出来之后，它得自带足够的“串联角色”内置能力——开箱即用，而不是从零搭。
能自定义：在拎包入住的基础上，又能做足够的差异化定制。
能与执行层无缝衔接：协同层派活给执行层的Agent时，上下文要尽可能少损耗——数字员工费劲感知、拉齐来的上下文，不能在交接给执行Agent时摩擦掉。
跑在云端：它是一个随时在线、面向业务单元的角色，本就该跑在云端，而不是像很多个人AI工具那样，依附在某个人的电脑上、人一关机就没了。

一句话，对一个业务单元来说，介入要足够简单、能复用成熟能力、允许差异化，还要和执行层顺滑打通。作为对照，目前我看到的一些数字员工平台，虽然在自定义能力上足够灵活，但申请和使用都有一定门槛，且不同数字员工之间还缺少可复用的模板——不太容易拎包入住，也不好在一定的组织范围内沉淀复用。

观点总结：好平台的标准是“介入简单 + 复用成熟能力 + 允许差异化 + 与执行层无缝衔接 + 云端常在”。

怎么组织业务单元 → 协同层 → 执行层

那么，一个数字员工该怎么组织？是做成一个大而全、全知全能的Agent实例吗？——很可能并不合适。它要真正懂一块业务、把上下文维持在能驾驭的范围内，就必须被框定在一个相对聚焦的边界里，也就是一个业务单元；上下文一旦铺得太宽，它既抓不住重点，也沉淀不出真正可复用的东西。所以我认为的数字员工架构，是分层的、且以业务单元为界：

业务单元 →〔协同层〕数字员工 →〔执行层〕子Agent + 工作流（研发工作流、答疑工作流、工单处理工作流、经营工作流……）

这个结构里有两个关键：协同层是相对通用的，但到今天为止，我还没见到一个做得比较完善的；而执行层的关键，是把那些已经成熟的工作流沉淀下来、并被复用，可当下这些工作流是非常分散的。

这里顺带说明：无论业务AI Native还是研发AI Native，对协同层的诉求其实是一致的，差异只在执行层——研发、数据、运营、Skill各有各的工作流，本质是SOP的不同。所以两层沉淀的东西也不是一回事：协同层沉的是这块业务的上下文、知识和对齐后的目标，执行层沉的是把活干完的SOP。

再具体到数字员工日常是怎么干活的：它在一个业务单元内，围绕一个一个主题去工作。一个主题，对应到多个协作入口（多个群、私聊、会议等，或者叫频道），同时每个主题又对应到多个不同的需求，每个需求再对应到多个工作流。

举例来说：

业务单元：比如“天猫国补”业务单元。它有自己固定的一批成员、一套业务知识、一组常用技能——数字员工就绑定在这一个单元上，它只管这块（至于业务单元的边界该怎么划，上篇提过，是另一个重要而困难的话题，这里不展开）。
主题：比如“国补交易表达”这样一件要持续推进的事。数字员工的工作，就是围绕一个个主题展开的。
协作入口（频道）：为这个主题拉起的一个或多个钉钉群、若干私聊，后续可能还有相关会议。人和数字员工，就在这些入口里协作。
工作项：一个主题之下，一个个具体的需求，比如“国补交易下单要支持支付优惠前置表达一期”、“二期”、“购物车国补表达bug修复”等等。
工作流：每个需求按它的类型，走一条对应的、已经沉淀好的流程（Agent驱动的动态工作流）——研发需求走研发交付工作流，工单来了走工单处理工作流，取数场景走取数工作流。

而协同层做的，是数字员工在群里/会议里澄清需求、对齐口径、拉齐上下文、按工作项产出需求（目标）、派活、跟进；执行层做的，是背后的子Agent把派下来的活按工作流自主干完（比如出技术方案、编写代码、修改、自测、部署、验证、提CR）。

最后还有一个绕不开的命题：身份和权限。数字员工要替人调用工具、动系统——改代码、跑部署、提CR……它到底该拥有一套独立的身份与权限，还是继承委托人的权限来执行？在群协同这种场景下，又该如何切分？这背后关系到安全、审计和责任边界，是另一个大的话题，这里不展开。

观点总结：数字员工不该是全知全能的，而应按业务单元划分、在聚焦的边界内工作，以主题为单位组织，沉淀的是组织资产，而不是某个人的效率。

也许现在我们感受并不强烈

必须承认一点：数字员工在协同上的作用，今天对绝大多数人来说，不一定能接受并感受到它的价值。

这很正常。在现有的组织和业务形态下，它的价值在短期内本来就不容易体现出来——因为那个“厂房”还远没有改造好。这背后不只是一次技术升级，还牵扯到业务和组织的适配、习惯的改变。比如对研发来说，可能大部分情况下都是拿到已有的PRD，独自就能去做交付（已被分工和分配），那么你所需要的，往往只是执行层的工具，让数字员工通过协同层再绕一遍，反而会让你觉得别扭。

还有一层更微妙的错觉：一个员工可能会把自己的“数字分身”打造得很好，个人效率蹭蹭往上涨——这没有问题，但也要小心不要因此被困住，因为那是一种实实在在的“爽感”，要记住，个人效率高 ≠ 组织效率高，应把个人的经验沉淀到团队去。分身优化的是你自己那一段，而组织的瓶颈，往往在人和人、段和段之间的协同上，那恰恰是分身够不到、而数字员工要去补的地方。

而当下大家最容易有体感的，是执行层的变化——这一层从实践层面看，正渐渐趋于成熟。只是眼下工具五花八门、选择繁多，未来面临的真问题，还是如何收敛（以便沉淀、复用）。换句话说，短期的红利在执行层，长期的胜负手在协同层。

观点总结：短期的效率红利在执行层，长期的胜负手在协同层；个人的“爽感”不等于组织的效率，感受不到，不等于不重要。

结尾：回到那条新流水线

说回开头那个问题：AI Native组织里那条新的流水线到底是什么？我目前的答案是——围绕“Agent来串联”这个新前提，重新组织起来的协同方式；而数字员工，是我现在能看到的、那条流水线最具象的形态。

这方面，天猫技术也在尝试自己的数字员工实践NC（恩熙同学），在协同场景下的权限问题上也有自己特色的实践，本文不展开，感兴趣可以去看“天猫数字员工”系列文章。

当然，实践离目标还很远，我也不敢说这就是终局的答案。但方向是清楚的：与其忙着造更多会干活的AI角色，不如去补上那条把它们串起来的协同层流水线——把目标定义和上下文对齐前置到源头，这件事只会越来越重要。

本文作者书牧，来自淘天集团-天猫技术团队。天猫技术是阿里巴巴旗下专注于电商场景的综合技术团队，既支撑天猫电商业务的持续增长，也在探索如何用 AI、大数据与交互技术重塑行业交易、品牌营销与消费者体验，致力于成为全球领先的品质购物平台背后的技术引擎。团队长期开放AI研发工程师、AI评测工程师、AI算法工程师的岗位，欢迎将简历投递至 jade.liuyy@taobao.com。

本文由 @大淘宝技术授权发布。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议