简单需求端到端只有 66.7%：阿里云用两道门禁放行数字分身

编码变快，交付不一定变快。需求进生产之前，还有翻译、质量检查和功能测试；这些环节仍靠人，整条链路的上限就停在人最多的那一段。阿里云的云通信核心产品工程团队在 2026 年 10 月 28 日的社区博客里写了他们的做法：数字分身不是独立员工，而是挂在具体人权限上的延伸；能不能开工，先过两道门。Harness 在这里指包住模型的运行外壳，包括规则、知识和可执行的工程资产。

编码快了，交付还是卡在人

团队 2024 年用上代码补全、对话式编程和生成式 IDE，2025 年把规范和领域知识收成章程和 Skill，2026 年改成 Agent 运转，目标是端到端交付。AI Native 指从需求提交起就按智能体可执行的方式组织研发，而不是只在写代码那一步调用模型。

编码只是中间一步。前面要把需求译成模型能执行的输入，后面要做质量检查和功能测试。人还守着这两头，吞吐就上不去。所以他们要的是需求交出去之后，后续工程由 Agent 跑完。这带来三个问题：多个 Agent 怎么协作，边界和权限怎么划，新模式怎么放进现有系统还不把生产弄坏。

流水线补上下文，分身沿用人的权限

早期多 Agent 协作缺的是上下文。工程 Agent 写技术方案时关心架构和中间件，下游测试 Agent 要的是系统边界和怎么定位问题。上游觉得自己写得很全，下游却拿不到该拿的信息。原因是交接仍靠经验和口头约定。他们改成工厂流水线：先规定每段的输入、输出和交接物，协作路径写死，而不是临时商量。

权限上有两条路。一条把 AI 当成独立的数字员工，要另写一套规章。一条把它当成某人在数字世界里的延伸，也就是数字分身。团队选了后者。分身沿用对应的人已有的权限，能做什么、不能做什么跟着这个人走。用这个人的身份提交代码或生成产物，出了问题能追溯到人。责任留在主人身上，主人才会持续改自己的分身。

两道门：Harness 成熟度，以及需求风险

安全上先保稳定。人和 AI 做的需求都不能把生产弄出问题。开工前有两道门。

第一道是 Harness 工程门。应用还没备好规则和知识，分身不能开工。分身能力等级 L 按这套 Harness 的成熟度定。

第二道是需求风险门。需求有风险等级 R。运营工具、数据看板算简单、风险低；跨应用协同、改核心处理路径算复杂、风险高。

分身只接 R 不高于 L 的需求。超出能力就交给对应工程负责人手工做。上线初期知识库还不厚，只能接简单需求。Harness 和知识库跟着活变厚，L 升高，能接的需求才变复杂。

四条业务线，简单需求端到端 66.7%

这套系统已经铺到云通信核心产品的四条线：国内短信、智能语音、智能调度、国际短信。以当时的模型能力，一个分身可以并行三四条需求。分身自己判定为能力范围内的需求里，大约三分之二真正走完端到端。简单需求的端到端交付率是 66.7%，交付物达到预期。原文没有给出总样本量，也没有把「大约三分之二」拆成分子分母。66.7% 只覆盖被判定为能力内的简单需求，不是全部需求，也不是公开榜分数。

九段流水线，不合格就退回

多 Agent 协作被收成一条流水线，工程工作分成九段：PRD 生产、门禁、就绪、设计、编码、自检、测试与质量检查、发布与验收、Loop 反馈。PRD 是产品需求文档。Loop 指做完之后再检测、归因、改正、验证的回头环。

三段原则。契约链：每段的输入、输出和产物格式事先写好，本段产物就是给下一段的契约。最低标准：上一段不合格必须退回，不能把问题送到下游。Skill 可替换：每段有一份明确的能力清单，可以换、可以补，用来适应不同业务。前两条管质量不滑坡，第三条管能不能换场景。

质量检查不共用一个工作区。子 Agent 挤在一起时，会互相把结论带偏，也会产生上下文幻觉。所以产品、工程、安全、测试各有工作区。产品分身核对业务需求是否做全，工程分身查代码缺陷，安全分身查合规，测试分身在测试环境里自动写用例并执行。汇总报告交给技术负责人 Agent，按声明式检查点给通过或失败。有问题就在同一段重跑和修复，不把失败带到下一段。

上线靠交付后的审计，审计本身是生产阶段，不是额外抽查。审计看三件事：流程走对没有，交付物是否达到预期，整条流程上的 AI 执行指标是否正常，文中点名缓存命中率和 Token 消耗。好的做法写进知识库，下次同类需求直接用。要改的建议送给分身主人，由人决定改不改工程资产。

Loop 的顺序固定：检测，归因，改正，验证。每交付一条，就审计一次、改一轮资产、更新知识库。能力从 L1 往 L2、L3 走，能接的需求范围跟着变大。原文没有定义 L1、L2、L3 的分数线。

一条真实需求怎么走完

业务方在钉钉把需求单发给工程负责人的分身。分身先判断接不接。能接的话，多个角色的 Agent 先对齐需求，把结论退回给提出人。提出人确认后才生成需求文档，并检查 Harness 资产，不过不往下走。

随后是技术设计和内部评审，评审不过自动退回。通过后交给技术负责人批准，再进入 AI 编码和部署到测试环境。各角色检查产物，有问题自动修。检查完才做自动化功能测试。用例全部通过，才提交平台做质量检查。工程阶段都结束后做交付后审计：知识入库，改进建议交给主人决定。

任务验收门通过之后，九段可以无人值守往下走。每一步留下谁做的、依据是什么、结果是什么，方便事后回看。这是一条脱敏后的真实需求路径，不是一组对照实验。

不能比人工更贵，也不能只靠模型

后面三件事。继续从简单需求扩到复杂需求。成本不能高于现有人工模式，靠模型分层路由、上下文治理，以及把批量执行放到夜间低峰。组织上试过一名工程师加若干分身，负责一块领域，吞吐不再只按人头算。这套分身模型仍兼容以人为主的组织。

团队认为两个极端都不可取。一是怕幻觉伤生产，完全不用 AI。二是跳过知识和 Harness，指望更强的模型单独保证质量。领域知识往往不标准，有的只在口头上，有的还反直觉：两个缺陷可能互相抵消，只修一个反而把系统修坏。模型一次看不全。所以先把流程和标准写给 AI，把活动范围先收小，再由人在这个框架里带它迭代。他们的结论是，长期拉开差距的不是模型有多强，而是整条工程交付系统里攒下的资产有多深。

原文没有给出 66.7% 的样本量、失败案例清单，也没有上线前后的缺陷率对照。两道门、九段退回和交付后审计是方法约束；66.7% 只说明能力内简单需求的端到端交付，不能外推成全部需求的质量。

阿里云，Caichen，Digital Employees or Digital Twins? Improving End-to-End Software Delivery in Practice，2026-10-28，https://www.alibabacloud.com/blog/digital-employees-or-digital-twins-improving-end-to-end-software-delivery-in-practice_603694