天猫技术正在建设统一的 AI 端到端交付架构：数字员工提供统一入口与运行时，驻进需求群承接交付；各业务域按需装配并持续沉淀自己的知识、技能与子 Agent。它与产品、前端、后端、测试共享上下文，接需求、写方案、调度 Agent、跟进交付，像一位全程在场的同事。目前已经在天猫技术的所有业务线进行落地推广，月均活跃需求交付100+。
区别于一般 AI 编码工具的两个核心视角——协作：与所有角色共享同一份上下文，让协作重新连起来，而不是被 AI 切碎；资产：把散在人脑与聊天记录里的业务认知，从组织维度沉淀成可复用的资产，越用越厚。
本文为此系列第二篇内容。
第一篇：《天猫数字员工（协作篇）- 研发的暗物质与 AI Native 组织协作》
数字员工以钉钉为协作入口。每条需求对应一个场景群，产品、设计、开发、测试与它共享同一份需求上下文；从 PRD、设计稿和技术方案，到编码、测试、发布与复盘，产物都回到群里。团队不用更换协作工具，@ 它即可发起任务，私聊也能使用同一套能力。下图从一个入口和四个协作切面，快速展示它如何围绕同一份需求上下文参与理解与推进、方案判断、执行交付与状态学习；这些动作按事件触发，可以回退，也会反复发生：
同一个对话入口，共享一份需求上下文；理解推进、方案判断、执行交付、状态学习四个切面按需进入，不是一条固定流水线
上一篇讨论了一个现实：编码越来越快，并不必然缩短需求从提出到上线的周期。交付中的等待、澄清、对齐和知识寻找仍然存在。数字员工因此同时处理两件事：在协作侧让所有角色共享同一份需求上下文，在资产侧把交付过程中形成的业务认知沉淀下来。本文不再重复论证问题，而是展开这套产品形态如何落地、系统如何实现，以及我们怎样度量它的效果。
数字员工协作形态
先回答两个定位问题：为什么造的是”一个”数字员工，以及这”一个”以什么形态嵌进团队协作。
2.1 嵌进团队，而不是配给个人
AI 编码工具已经显著改善个体执行效率，但组织交付仍常卡在键盘之外：需求讨论没有及时收口，方案评审依赖多人同步，联调等待接口与确认，业务规则又在讨论结束后回到少数人的记忆里。上一篇把这些问题称为研发协作的“暗物质”。
产品形态需要回答一个更具体的问题：在多角色共同交付一条需求时，AI 应该处于什么位置？
稳定、可枚举的交付环节适合工作流编排：阶段、输入输出与门禁都明确，便于控制和审计。研发需求同时又有很强的差异性——有的只做评估，有的修改配置，有的需要跨仓编码，难以全部固化成同一条流程。因此我们的选择不是工作流与 Agent 二选一，而是确定性流程与动态规划并用：主 Agent 判断意图和任务形态，按需调用子 Agent、Skill 或工具；进入评审、测试、发布等稳定环节后，再由明确的流程和门禁约束执行。两类方式的适用边界如下：
左：确定性流程适合阶段明确、需要审计的环节；、右：动态规划适合需求类型不固定的入口。系统在不同环节组合使用两种方式
解决了任务怎么执行，还要决定 Agent 与团队如何组织。
一种常见做法是按岗位或任务拆出一组 Agent：数字产品、数字前端、数字后端、数字测试，复杂需求再由编排器调度多个 Coding Agent 并行执行。这种结构可以提高单个任务内部的专业化和并行度。但如果每个角色各自拥有一套 Agent，需求上下文仍会在角色交接时被切断：产品侧澄清得到的信息，不会自然进入技术侧的执行上下文；任务完成得更快，需求收口、跨角色对齐和组织知识沉淀仍需额外解决。两种产品形态的差异如下：
左：每人指挥自己的 Agent 队伍——数字 PM、多 Agent 编队、数字岗位小队，队伍再大，上下文仍锁在各自窗口里、互不知晓；
右：需求群里多一位数字员工——收口、对齐、编码都发生在所有人眼前，上下文沉在群里只有一份
我们的产品选择是让团队在协作现场共享同一个数字员工身份和同一份需求上下文。这里的“一个”不是限制系统只能调用一个 Agent：背后仍可按任务调用需求分析、编码、测试等不同职责的子 Agent；它强调的是面对团队时只有一个稳定入口，需求收口、术语对齐、执行进展和最终产物都回到同一个现场。
在实现上，私聊按员工身份进入个人沙箱，场景群按群身份进入独立的群沙箱。群里的所有成员看到同一个数字员工，讨论和交付共享一份上下文；不同群之间则保持隔离。需求进入后，它可以理解 PRD、定位代码、执行改动、完成验证并部署到预发，最后把验收入口送回群里。我们用自主交付率衡量这一过程：需求能够在既定流程与门禁内连续推进，没有因为流程中断、执行错误或结果不符合预期而需要人工纠正、驳回或重新启动，才算一次自主交付。方案判断、权限授权、评审确认和最终验收属于计划内的人类节点，不视为流程中断。
电商中后台对稳定性、资损和合规都有明确要求，自主交付必须通过与人工研发一致的生产门禁。因此本文后半部分重点讨论流程约束、验证、身份权限与归因，而不是代码生成本身。
▐ 2.2 先是同事，再是工具
落到日常，这个产品形态表现为一位嵌进团队的协作者。这里仅用四个动作快速交代它如何参与协作，完整讨论见上一篇《研发的暗物质》：
- 驻群听全场：它与所有角色共享需求上下文。群里追问业务规则时，回答同时带回出处，不需要重新复述背景。
- 异步卡片参与：人不盯群、不蹲会。需求通知、进度播报、异常预警、验收协作都以卡片送到人面前，要深度交互点”查看详情”进工作台——群是协作现场，详情页是个人工作台。
- 卡点主动触达：部署完成后主动 @ 验收人并附上预发地址和改动说明；审批超时则按规则催办，不再依赖人持续盯进度。
- 跨角色对齐：前端叫 cursor、后端叫 nextToken 的同一个分页游标，这类”传歪”在需求收口时就被对齐、记进词条，不用等到联调才爆雷。
这些能力依赖的不只是模型，也依赖它在协作现场中的位置：常驻群聊、持续持有需求上下文，并能把讨论、任务和交付物关联起来。
这套协作形态如何从“人找它”发展到“它找人”，上一篇已经展开。本文继续回答三个问题：它交付什么、系统怎么实现、业务如何接入。
全链路交付能力
这一章按三个尺度说明数字员工的交付范围：一条需求之内，多个角色如何共享上下文并完成接力；一组场景之内，能力如何按业务域配置；一个业务之上，多条并行需求如何统一管理。
下图包含四条真实需求的五段交付记录：从截图中提取需求、根据评审意见把方案迭代到 v4、同时处理三个仓库、定位“模板无法下载”的根因，以及发布完成后汇总访问地址。它们对应不同角色和不同交付阶段，人主要在确认与验收节点参与：
五段真实交付记录，来自四条不同需求、五类不同的活——内容未改动、人名已脱敏（点开看大图）
▐ 3.1 一条需求之内：跨角色接力
一条需求要动用四种角色：产品、前端、后端、测试。先后与门禁由业务域按实际交付流程定义；这里先看职能：每个角色的活它都接得住，而每个角色和它的输入输出都很直接——
- 产品：丢进来一句话需求、群里的讨论与评审意见；拿回结构化 PRD 和待澄清清单。PRD 被指出”只写接口、没写业务逻辑”，它按业务逻辑分域重写一版——接受批评、按反馈返工。
- 前端：给交互确认与联调信息；拿回页面改动、构建部署与 Diff 预览。
- 后端：给接口口径与方案评审结论；拿回技术方案、服务改动与预发部署。
- 测试：给验收判定与缺陷反馈；拿回测试用例与自测结果——质量门禁（静态检查 → 构建 → 自动测试）加 Harness 浏览器验证贯穿全程，写完自己验；用例带着需求澄清的全部上下文，知道这条需求”为什么这么改”。
编码执行不重造轮子：沙箱里 Claude Code、Codex CLI、通义灵码按需选，数字员工管的是把上下文喂进去、把进度收回来。角色之间的协同，一张图说清：
四个角色共享同一个需求会话，数字员工负责衔接各阶段；
会话关联同一业务域资产空间，统一消费并沉淀业务知识、技术知识、记忆与产物
再看同一条需求的完整过程。手猫「问底价」功能的一次迭代，从需求描述、元信息录入和代码级澄清，到方案评审、测试用例与预发部署，由同一个数字员工在两天内连续处理，人主要在确认和验收节点出现：
同一条真实需求的四段切片：需求启动 → 方案确认 → 测试用例 → 部署验证，取自同一个需求群的两天记录
编码能力可以复用现有工具，数字员工新增的价值主要发生在角色之间：需求对齐、产物衔接、过程验证和进度协调都在同一个现场完成。交付物向前流转时，上下文也随需求保留下来，人可以把注意力集中在方案判断、风险确认和最终验收上。
一条链走得通，靠的是每一环都吃到对的知识——而物流域和供销域吃的根本不是同一套东西。链路是通用的，知识是业务的：能力怎么跟着域走？
▐ 3.2 一组场景之内：开箱即用，按域定制
一个业务域里的场景五花八门，粗看两类：一类不成流程——找人、答疑、读文档、查数据、拉群建单，零散、随时发生；一类是标准流程——技术方案、编码、部署、迭代创建到发布，讲先后、有门禁。数字员工用一套灵活的主子结构把两类都接住：主 Agent 接非流程化的协作面，流程化的交付交给子 Agent。
这套结构提供一条可直接运行的默认路径。主 Agent 预置需求单对接、钉钉文档与多维表读写、数据库操作、数据表理解、迭代创建和发布单创建等通用能力；默认编码子 Agent 则覆盖需求分析、方案设计、编码、测试和发布，各阶段都有明确入口、产物与评审点。新业务域不做定制也能先运行，再根据实际需求逐步扩展。
开箱之上是深度定制，定义权归业务。交付流程以 Skill 装载：分几个阶段、每段产出什么、哪里设置评审门禁，都由业务团队定义。数字员工按配置执行，被指出遗漏步骤后也能回溯原因、补齐产物。在一类接口已经具备、以组装为主的小需求中，手猫团队把九阶段交付流程装载后，曾将需求到方案的时间压缩到十几分钟，确认后继续进入编码与部署。装载入口是业务域后台的一页配置：
调度说明是主 Agent 的派发依据，子 Agent 清单按域生成；关联的 Skills 在派发那一刻投影给执行器（真实页面，已脱敏）
能力按业务域配置：不同业务可以设置 Skills、Hooks、System Prompt，并关联本域知识库，让同一个数字员工在不同业务域获得相应的知识和执行能力：
主 Agent 与每个子 Agent 独立定制，变更自动保存，数字员工运行时在分钟级加载；知识库按域关联（真实配置页，MCP 加装同属此组页签）
自有 Agent 通过标准协议接入，业务能力在调度时按域投影；知识与资产如何生产、治理并持续变厚，是资产篇的正题。单条交付得好、每个域都接得住，需求自然就多起来——几十条并行时，考验的不再是交付本身，而是管理：谁在推进、卡在哪、产物在哪。
▐ 3.3 一个业务之上：看板与主动推进
需求进入场景群后，数字员工同步维护需求看板：自动记录项目成员、里程碑、卡点和产物，并根据群内讨论与交付进展更新状态。群内通过吊顶卡查看当前需求，跨需求则使用 Web 大盘；每条需求对应一张卡，并与研发工单系统保持状态同步。这里同步的是工单状态，任务仍由用户在钉钉对话中发起。群内与跨需求的两种视图如下：
左：群内吊顶看板——成员、里程碑、卡点，随讨论与交付自动更新；
右：Web 需求大盘——四列状态流转，每条需求一张卡（真实系统页面，已脱敏）
看板把等待状态显式记录下来。数字员工将进展同步到群与看板，在需要确认或验收时 @ 对应负责人，超时后按规则催办，并每天生成一份需求摘要，说明当前状态、下一步动作和仍待处理的事项。
日报同时展示趋势变化、卡点负责人和停留时长。群成员可以直接回复“第 2 条展开说说”，继续查看对应需求的细节：
日报以群成员身份发在会话里——有头像、在对话流里、可追问，回一句「第 2 条展开说说」就展开；左右为同一份日报的两段截取，中间标注读法（真实群聊消息，内容未改动、人名已脱敏）
看板、催办和日报解决的是进展可见与待办推进；主动发现问题、主动发起协作等更进一步的能力，将在系列自主篇中展开。系统是否稳定、交付能走到多深，则需要回到运行数据判断。
系统拆解：消息、沙箱、Agent 与身份
理念落到工程上，依托的是一套数字员工系统。这一章沿着一条消息的旅程拆解四个问题：消息如何进入并找到对应沙箱，沙箱如何创建并保存状态，主子 Agent 如何分工，系统访问外部资源时使用谁的身份。核心调用链如下：
钉钉消息 → 消息网关 → 按路由身份转发到专属沙箱 → 主 Agent 判断意图 → 调度子 Agent 或直接回答 → 钉钉 AI Card 实时反馈
从触点到存储的完整结构如下：
钉钉与 Web 两个触点收敛到同一个网关和沙箱；
业务数据统一经数据服务落库，模型调用从网关统一出口
▐ 4.1 钉钉接入与消息路由：从群到沙箱
先看消息怎么进来。接入使用钉钉官方 Stream 模式：网关主动建立长连接，事件沿连接推送下来，不需要暴露公网回调地址。实践中仅检查连接状态不够，我们同时监控“最后一次收到事件的时间”，用于识别连接仍在、事件却不再到达的异常状态。
连接上下来三类事件：私聊、卡片回调、群消息。场景群即开头的需求群：建群后，数字员工发送第一条消息，此后群内消息全量进网关——@ 到的进应答，没 @ 的进旁听。
这里遇到过一个实际问题：如何稳定判断消息是否 @ 了数字员工。平台在不同接收关系下回传的身份标识并不适合只做一份静态配置。网关因此维护机器人标识集合：已确认的标识直接匹配，尚未覆盖时使用文本规则兜底，并在运行中补全集合。
路由规则是：一个路由身份对应一个沙箱。私聊按发送人身份路由；场景群按群会话 ID 派生群身份，做到一群一箱。群沙箱与个人沙箱保持隔离，避免不同会话的回复通道相互影响。多实例同时收到同一事件时，转发前先做原子认领，只有一个实例继续处理。
这条通道从头到尾画出来是这样：
从 Stream 长连接到专属沙箱：多机原子认领去重、@ 判定集合自学习、路由身份两形态
在会话链路上，网关被刻意做“薄”：不调用 LLM，也不做业务判断，只承担三类确定性工作：
- 接得住：消息到达后立即回执，并通过原子认领避免重复处理。
- 留得下：图片和文件在下载凭证有效期内先行转存。
- 送得准：识别路由身份、选择沙箱，再组装成运行时统一格式。
业务调度为什么必须经过数字员工，而不是让网关顺手处理？三个场景可以直接说明：
| 场景 | 如果绕开数字员工 | 经过数字员工 |
| 用户在群里发起需求分析 | 网关按关键词直接启动分析 Agent → 分析完成后缺少统一状态与反馈主体 | 数字员工理解意图 → 启动分析 → 统一管理状态和交互 |
| 分析完用户点“开始编码” | 网关解析卡片回调 → 还得知道分析结果是什么 | 分析结果就在数字员工手里 → 直接传给编码 Agent |
| 编码中用户发了条无关消息 | 网关无法判断该转发还是忽略 | 数字员工推理判断 → 自己回答或转发给 Agent |
如果管道层同时承担业务判断，状态会分散在网关和数字员工两侧，后续交互很难保持一致。因此网关只负责传输与路由，业务决策统一收口到主 Agent。
返回结果时，网关采用“先建卡、再覆盖”：先创建占位卡并取得轨道号，随后持续向同一张卡更新内容。即使遇到冷启动，用户也能先看到任务已经受理，不会出现长时间无反馈或连续刷出多张卡片。
每轮消息在入口生成链路标识，覆盖选箱、投递、回调和发卡；看板既能查看整体情况，也能下钻到单轮消息。这里主要看三个结果：
- 热路径首响：平均约一秒，P90 在三秒以内。
- 冷启动首响：P90 约六秒。
- 首响成功率：超过 99%。
以上为截至 7 月底的内部运行数据，“首响”统一定义为第一张卡片成功推送。
当前系统只保留对话驱动这一种发起方式。用户在钉钉群或私聊中发送“帮我分析这个需求”“帮我优化 utils.ts”等指令，数字员工先结合当前会话与项目列表匹配仓库；无法唯一匹配时，列出候选项目请用户确认，再派发需求分析或编码 Agent。执行过程中，Agent 持续输出流式事件，数字员工一边节流更新 AI Card，一边推送实时事件供详情页订阅。
▐ 4.2 一需求一沙箱：容器、初始化与记忆
消息路由的终点是沙箱：一条需求对应一个场景群，一个场景群对应一个独立沙箱，私聊则使用个人沙箱。不同协作现场彼此隔离，一条需求中的代码、依赖和调试状态不会影响其他需求。
镜像只包含基础运行环境，运行时代码不进入镜像，而是在启动时从发布服务拉取。这样发版不需要重新构建镜像，在线沙箱可以分批升级：守护脚本拉取新版本、切换软链，并在空闲时重启运行时。
创建时，网关注入身份、凭证与业务域配置；多个仓库按需求并行克隆，并根据仓库特征识别技术栈。冷启动从两侧优化：一侧维护已就绪的预热池，首条消息到达时完成一次性认领，绑定完成前不接收业务消息；另一侧把需要保留的状态放到容器外部，避免沙箱重建时丢失。
从创建到就绪、再到群里第一句问候，整条流水线：
创建、注入、拉运行时、备仓、就绪——就绪那一刻，群里冒出它的第一句问候（真实截图，已脱敏）；预热池沙箱经一次性认领上岗，升级走同一条 CDN 通道
运行中，每次转发消息都会刷新沙箱有效期，避免活跃实例被平台回收；转发失败时先查询容器真实状态，再分别执行重建、唤醒或等待启动。
状态设计只做一道取舍：必须记住的留下，可以重建的不留。
| 类型 | 内容 | 处理方式 |
| 必须保留 | 会话、记忆、任务状态 | 存入独立持久卷，容器重建后重新挂载 |
| 可以重建 | 仓库代码、临时执行上下文 | 不进入持久卷，使用时重新生成 |
这样既能保持连续会话，也允许工作容器随时替换。/reset 只重置当前运行状态，不直接删除持久数据，误操作后仍有恢复空间。
这套 Session 设计还支持跨端：Web 工作台不另建会话，而是复用实例关联的 Session——拉取快照回放历史、订阅事件流接续实时进度，发出的消息与钉钉合流到同一个沙箱。聊到一半的需求切换到 Web 后可以继续处理，中间不断档：
两幕是同一个群、同一条讨论线——钉钉聊到一半，Web 工作台打开接着干；
下：两条通道进的是同一个沙箱、同一份会话状态（真实页面，已脱敏）
▐ 4.3 Agent 层开放：调度可控，执行可插拔
消息进入沙箱后，由一主多子的 Agent 结构完成处理。主 Agent 是数字员工本体，也是自研 Agent 框架中的常驻 Thread；子 Agent 负责需求分析、编码和测试，由主 Agent 按需派发。背后的设计判断是：通用性归执行端，可控性归调度端，两层职责分开。
为什么没有直接把通用编码 Agent 作为常驻协作中枢？两者解决的问题不同：编码 Agent 擅长在仓库中完成明确任务，而数字员工中枢还要管理消息路由、结构化交互、多会话状态和跨角色协作。以“直接作为中枢、不增加外部编排层”为比较范围，差异如下：
| 数字员工要做的事 | 自研主 Agent | 通用编码 Agent 直接作为中枢 |
| 发送钉钉 AI Card | 原生工具与状态机直接控制 | 需要额外适配层 |
| 调度编码 Agent | 明确控制启动时机、上下文和回收状态 | 需要在外部补充调度协议 |
| 特定时机发送特定卡片 | 由业务状态驱动结构化交互 | 需要在外部映射运行事件与卡片状态 |
| 管理多会话状态 | 按群、用户和需求显式管理 | 需要额外建立组织会话与编码会话的映射 |
| 确定性消息直转 | 代码路由，不调用 LLM | 需要外部网关提供短路能力 |
主 Agent 的目标是让行为可控：发送消息、更新卡片、派发任务等外部动作都通过显式工具完成。但它也不能退化成规则引擎——“改完了吗”“先别管这个，帮我看看线上报错”这类消息仍需要结合上下文判断。子 Agent 清单按业务域动态生成，并在轮次边界加载新配置，不需要重建 Thread。
子 Agent 层保持可插拔：同一个逻辑 Agent 可以使用自研执行器或 Claude Code 等后端，由业务域选择。工程约束有三条：同一会话中途不切换引擎；不同后端的流式事件统一映射；所有模型请求必须经过统一网关，未配置网关时拒绝启动。
主 Agent 将业务域配置传给子 Agent，这一步称为能力投影，分成三个动作：
- 派发时装载：Skills、MCP 和 Hooks 转换为执行器的原生格式。
- 执行中追问：子 Agent 缺少信息时，通过桥接通道回到群里提问。
- 完成后收口：执行事件回到主 Thread，由主 Agent 统一更新状态并反馈结果。
三种动作及默认、自有子 Agent 的注册关系如下：
派发、追问、结果回传都走注册协议；默认子 Agent 初始化即有、可定制，业务自有的实现 run/resume 即注册——载体可插拔，规范统一
下图展示一次真实的主子 Agent 对话。右栏顶部将用户原话标记为“仅作任务背景”，主 Agent 随后给出的提问才是子 Agent 当轮需要执行的指令：
左：群里被问”为什么没走工作流”，主 Agent 转发提问并转述回答；
右：编码子 Agent 会话原文——它自陈”是我自己的判断”，并承认对较大变更该走正式流程
（真实页面，工号已脱敏）
主子消息分流来自试点中的真实反馈。早期有用户反馈：“部署时轮询进度会占用会话，我新发的消息只能排队。”改造后，消息先经过一道不调用 LLM 的确定性路由：子 Agent 正在等待回复时直接转发；其余消息才进入推理路径，由主 Agent 决定回答、转发还是新建任务。改造后的两条路由如下：
子 Agent 在等待回复时，消息去向是确定的，可以直接转发；只有存在歧义的消息才进入推理路径
例如需求分析 Agent 问“登录页要支持哪几种登录方式”，用户回答“手机号验证码和钉钉扫码”，这条消息的去向已经确定，没有必要再次调用模型判断。在 Agent 系统的成本结构中，识别哪些环节不需要调用 LLM，与提升模型调用效果同样重要。
用户侧只需要理解两层信息：群里的卡片展示阶段、状态和当前执行者；详情页持续显示执行过程。只关心结果时看卡片，需要排查过程时再进入详情页。
任务进入沙箱前先定位仓库和分支，再按复杂度选择执行方式：
| 复杂度 | 执行方式 |
| 简单 | 轻量执行，完成后直接验证 |
| 中等 | 单 Agent 执行并自检 |
| 复杂 | 仍由单个编码 Agent 分阶段执行，增加方案确认、自检和发布门禁；执行过程持续回传状态，异常时由人纠偏或重启流程 |
可控也不等于把行为写成固定剧本。主 Agent 可以在授权能力范围内调整执行方式：例如子 Agent 长时间没有进展时，重新规划任务，改用自己已有的工具继续处理；但后续验证、权限与发布门禁保持不变。推理负责应对变化，工程约束负责守住边界。
这一层也向业务开放：不修改平台代码，即可在业务域后台扩展主 Agent 以及需求分析、编码、测试三个默认子 Agent，配置 System Prompt、Skills、MCP 和 Hooks。已有自研 Agent 的团队，只需实现运行与续跑协议，就能把自己的引擎注册为子 Agent。群里仍由同一个数字员工应答，背后的执行器可以替换；平台保留默认需求分析与交付 Agent，确保新业务域具备可运行的基线。执行器变化也不会改变身份边界，数据权限仍跟随当轮用户。
▐ 4.4 身份与权限：谁干活算谁的，谁消费算谁的
同一个群里，不同人会让数字员工读取文档、提交代码、执行部署或查询受控资源。如果所有动作都使用同一套身份，要么权限不足，要么权限被无意放大。我们按动作拆分身份，原则是：谁消费数据，使用谁的权限；谁产生结果，记录谁的归属。
| 动作 | 实际使用的身份 | 边界 |
| 读写钉钉文档、多维表 | 当轮发送人 | 只能访问这个人原本有权访问的数据 |
| 构建、部署、平台登录 | 数字员工服务身份 | 不借用个人账号，平台动作可独立审计 |
| 提交代码 | 当轮发送人署名 | 产出归属于实际指挥者，个人凭据不落盘 |
| 查询中间件、监控、数据平台 | 群内负责人通过身份委托服务授权的身份 | 资源端仍按负责人的原有权限判断，不额外扩权 |
这里最重要的不是身份有几类，而是模型不能指定任意一个人。身份化调用只接受“当轮发送人”“数字员工服务身份”“已确认的群负责人”等受控角色，角色到真实身份的映射由可信环境注入。即使模型生成“以某某身份查询”，控制层也不会接受。
受控资源再多一步显式授权。群里指定技术负责人后，只有本人登录确认，身份委托服务中的授权才生效；请求同时记录委托用户、执行 Agent 和来源沙箱。授权系统只证明“谁委托了谁”，不会扩大这个人原有的资源权限。凭证加密保存、按需续签，文档、代码和平台身份也不会因为这次委托自动同步或放大。
这条委托链路的完整时序：
群里一句话发起，只有负责人本人登录确认才生效；身份材料经控制面注入沙箱，资源端仍按本人原有权限判
这套委托有一条约束：一个沙箱生命周期内，“用户 + Agent”的身份组合保持不变。更换负责人时不直接修改现有沙箱，而是销毁旧沙箱、冷启动新沙箱，并禁止从旧快照恢复，使上一身份关联的缓存和凭证不进入新环境。整套绑定在系统中实现为一台状态机：
从提案到激活、分离、重授权、吊销的完整流转——绑定的用户、Agent、沙箱三者一致才算就绪；授权可撤、可续、可追溯
消息入口、运行环境、Agent 调度、业务扩展与身份权限共同形成完整链路。它是否稳定、交付过程中人仍在哪些环节介入，需要由运行数据回答。
效能度量与落地数据
系统上线之后，效果不能只靠“感觉变快了”判断。我们先定义度量口径，再用运行数据观察它承接到什么深度，以及人的介入发生在哪里。
5.1 效能度量：刻度与归因方法
数字员工的观测体系分为两类：稳定体验关注服务质量与用户留存，交付效能关注 AI 承接深度、产出效率和投入成本。同一套数据按使用者划分视图：平台侧查看全局，业务域只查看本域。效能侧重点观察两个信号：自主交付率与人工介入次数，矩阵与账本都围绕它们展开：
上：稳定体验（服务质量/用户留存）；下：交付效能（自主性/产出效率/投入成本）。
统计时剔除开发者试用数据，业务域只查看本域，所有视图用于定位改进方向
在当前 AI Coding 推进中，代码采纳率、使用覆盖率等传统指标已经处于较高水平，继续上涨也很难说明 AI 在真实业务需求中究竟承接到了哪一步。它们可以回答“有没有使用”，却不能区分一次提示词生成、一次研发闭环和一条需求的完整交付。单纯按耗时统计也容易失真：开发任务常与其他工作并行，等待和阻塞又可能发生在研发链路之外。
因此我们使用两把尺子。需求分层 C1-C4 描述复杂度，按核心中台影响、产品形态、跨团队范围等七个维度综合判定，并采用就高原则。AI 交付深度 L1-L4 描述承接范围，从提示词驱动、研发闭环、测试闭环到全流程交付。
在 C × L 坐标之外，我们增加一个并列的参考信号：人工介入次数——首轮任务发起之后，人继续补充、澄清、追问或纠偏的轮次。它按协作层（主 Agent 群内的讨论、澄清、评审）与交付层（进入编码子 Agent 会话后的补充与纠偏）分账，用来解释同一复杂度、同一交付深度下，人的参与主要发生在哪里。
这项数据只用于观测和归因，也不追求越低越好。必要的追问、判断和评审本来就是交付的一部分；如果把轮次本身当成目标，延后反馈或合并消息就能让数字变得好看，却不会让交付更顺畅。它与自主交付率也不是同一个口径：计划内的判断和确认可以被记录为参与轮次，但不会把一次交付判为“非自主”；只有异常纠正、驳回或流程重启才会影响自主交付判定。两套口径的交叉视图如下：
上：C1-C4 七维判定表，就高不就低（跨团队面等组织口径已模糊）；下：L1-L4 从提示词驱动到全流程交付；交叉即效能画像主视图，每格「需求数＋平均介入次数」——定位改进方向的参考
5.2 运行大盘：规模、深度与介入位置
截至 7 月底，天猫技术下的业务线已全部接入这套流程：需求池百余条，覆盖二十多个业务域；近 30 天新建需求群与活跃会话均超过一百。从需求沟通、方案设计、评审、开发、测试到发布，每个阶段都有正在流转的需求。这组数据说明的是系统已经进入真实业务运行，而不是用规模直接替代效能结论。
我们还逐条复核了首批十余个试点需求。这个样本不足以证明整体效率提升，但可以帮助定位人的参与发生在哪里：大部分记录集中在协作层，即群里的讨论、澄清和评审；单条需求通常有十到几十轮。这些轮次包含计划内协作，不等同于流程失败。交付层主要记录进入编码子 Agent 后的补充与纠偏，多数需求为几轮到二十轮，已完成编码的需求平均约七轮，较早稳定运行的业务域已经降到一轮左右。该批样本的全链路参与约三十轮，其中纠错返工约占两成。下一步要优化的重点，已经从“是否能生成代码”转向“能否减少协作中的反复确认与信息补充”。两层账本如下：
上：域视角的介入归因看板——交付层与全链路两个刻度，介入轮按协作层/交付层分账；
下：需求明细里每条的介入分层（协/交），需求名与人员已脱敏（真实系统页面）
账本还可以继续下钻到归因。系统为每轮介入标记催进度、解决卡点、拍板确认、提出需求、纠错返工、补充上下文等类型，并识别上下文缺失、理解偏差两类风险信号。在此基础上生成预授权、Prompt 和 Skill 三类改进建议；建议经人工确认后，再沉淀为业务域资产。介入次数因此不只是一个结果指标，也成为下一轮系统优化的输入：
左：单条需求的逐轮介入明细，每轮标协作/交付层；
右：归因打标、风险信号与改进建议——采纳后沉淀为域决策资产（真实页面，需求名与真名已脱敏）
总结与展望：
AI Native 研发组织的新执行单元
如果只把数字员工看成群里的编码机器人，前面的消息路由、长期状态、独立沙箱、身份权限和主子 Agent 都显得过重。它们组合在一起，实际上定义了一种新的组织执行单元：它有稳定身份，有持续上下文，有自己的工作环境和权限边界；能够接收需求、调用工具、产出交付物、维护状态，并在需要判断时把人请回流程。
这也是我们理解的 AI Native：不是在现有研发流程的每个节点各加一个 AI 功能，而是重新划分人、AI 与系统之间的职责。过去由人搬运上下文、推动状态、在多个系统之间完成衔接；未来由数字员工持续持有上下文，承担确定性执行和过程推进，工单、文档与流水线在后台自动流转。人仍然拥有判断、授权和责任，但不再承担每一次信息搬运与状态轮询。
当每条需求都拥有这样一个长期运行的执行单元，研发组织的协作方式会从串行交接转向异步并行：几十条甚至更多需求可以同时推进，人不必逐条追踪 Agent 的工作过程，而是在方案选择、风险确认和例外处理等高价值时刻进入。真正可能带来数量级变化的，不只是某一次编码更快，而是同样的人类注意力可以支撑更多并行交付。
今天这套系统还处在这条路线的前段。更容易端到端跑通的，仍是接口和基础能力已经具备、以组装为主的需求；复杂领域改造仍需要人在需求判断、方案选择和风险确认处介入。下一阶段要解决的不是简单增加更多 Agent，而是继续补齐两块基础：一块是业务心智，让规则、口径和判例从人脑、群聊与历史交付中沉淀成可消费的组织资产；另一块是主动协作，让数字员工在授权和克制的边界内发现问题、发起协作并推动闭环。它们也分别是这个系列后两篇要回答的问题。
数字员工不会自动修复不清晰的 PRD、依赖默契的分工和缺少沉淀的业务知识。相反，这些问题会在交付过程中更早暴露：输入不足时无法继续，责任不清时无法路由，门禁缺失时无法判断是否可以前进。建设数字员工的过程，也是在把研发体系中依赖人兜底的部分逐项显式化。从“人围着系统跑”到“系统围着人跑”的变化如下：
协作载体的迁移——单据自动流转、状态自动回写，协作回到对话现场
过去，需求在工单、文档和流水线之间流转，人负责搬运上下文并追踪状态。数字员工把对话重新变成协作入口：需求在群里澄清，方案在群里评审，系统在后台自动完成建单、执行、状态回写和验收衔接。变化并不是去掉原有系统，而是让系统开始围绕真实的协作现场运行。
AI Native 的终点，也许不是每个人多用几个 AI 工具，而是组织里多了一类可以被授权、被协作、被审计，也能持续学习业务的数字同事。当它真正成为交付网络中的一个节点，研发效率的上限就不再只取决于一个人能写多快，而取决于整个组织能够同时推进多少事情，并把人类最稀缺的判断力留在最值得出现的地方。
团队介绍
本文作者珈文，来自淘天集团-天猫品牌行业前端团队。我们团队负责消费电子、3C数码、运动、家装、汽车、奢品、服务等多个行业的项目。我们定位自身不局限于“传统”的前端团队，在AI、3D、工程化、中后台等领域，我们有着持续的探索和实践。
本文来源@大淘宝技术。原文链接：https://mp.weixin.qq.com/s/kLWwdqZzhm0rqEGQMzn2Iw?nwr_flag=1