淘宝直播推荐系统早期为追求策略快速上线，形成了多框架、多分支并存的架构，导致工程团队面临数百万行代码的沉重维护负担。为此，团队自研了轻量级执行框架，通过统一物料承载公共能力、声明式编排表达场景差异、受约束的流程语义以及结构化执行诊断，彻底重构了应用生产方式。在此基础上，团队先通过人工迁移建立验收基线，再将经验沉淀为 Skill 引导 AI 参与复杂历史应用的迁移与验证。这一实践不仅实现了性能的平稳过渡，更证明了“AI Friendly”的核心在于为 AI 提供有限、显式且可验证的工程空间，从而将一次性迁移经验转化为可复制的自动化能力。
摘要
淘宝直播推荐应用支持直播多个核心流量场景。早期，为了让算法策略快速进入实验，算法团队直接开发和维护对应场景应用的 Java UDF、图配置及代码分支。这种方式缩短了单次试验路径，但随着维护责任逐步转交到规模更小的工程团队，历史上形成的多框架、多分支和多套诊断方式开始成为持续迭代的主要成本。
复杂度不仅来自代码规模，更来自多个版本的独立演进。同一项公共能力可能存在于不同分支和部署版本中，一次修改需要分别理解上下文、评估影响、发布和验证。即使最初源自同一份实现，各版本在长期演进后也可能形成不同的行为，难以直接合并或替换。
针对这些问题，我们逐步建立统一的应用开发与迁移方式：用可复用组件承载公共能力，用声明式编排表达场景差异（即通过配置描述组件组合、参数连接和执行关系，由框架统一解释和执行），用明确的流程语义降低理解成本，并通过结构化执行记录支持诊断与验证。在这一基础上，我们先通过人工迁移建立旧系统的行为基线和验收标准，再将迁移知识、操作步骤、工具及验收规则组织为可复用的 Skill，让 AI 参与历史应用的分析、转换和修复，并通过确定性校验工具与新旧链路对比检查迁移质量。
本文将介绍这套应用编排框架的设计取舍、三项核心机制，以及从人工迁移到 Skill 复用的演进过程，并讨论它们如何为 AI 参与工程任务提供基础。我们用 AI Friendly 描述这样一组架构属性：任务上下文可以局部理解，组件契约和依赖关系显式可见，能力可以检索与组合，生成结果能够接受工具检查。
一个仍能运行、却难以持续维护的系统
▐ 2.1 早期生产方式为何合理
淘宝直播搜推应用形成于算法策略快速发展的阶段。早期工程资源相对有限，需要支持算法团队持续开展策略实验。为了缩短策略从想法到实验的路径，算法同学直接编写 Java UDF、维护图配置并完成实验上线。
在当时的约束下，这是一种务实选择：策略设计与工程实现之间沟通链路短，独立方案和代码分支能够隔离单次变化，有限的工程资源可以优先保障业务快速试验。
问题出现在业务进入多场景长期维护阶段之后。部分实验分支和场景分支长期保留，逐渐成为独立的开发、部署和维护单元；不同场景又分别使用不同框架。早期用于缩短单次实验路径的局部最优，开始转化为跨场景维护时的整体成本。
随着维护职责从较大范围的分散承担转向规模更精简的工程团队集中承接，如何以有限的人力持续维护多场景应用，成为架构演进需要解决的重要问题。过去分散在不同参与者、代码分支和执行框架中的知识，需要逐步沉淀为可复用的组件、统一的流程和验证方法，以减少重复理解、修改与排障的成本。
不过这并不意味着早期选择错误，而是原有生产方式所依赖的组织规模、团队分工和资产生命周期已经发生变化。
从策略快速试验期到多场景长期维护期的生产方式变化
▐ 2.2 复杂度不在图的数量，而在复制后的独立演进
梳理线上实际运行版本后，我们发现，同一套流程和能力被复制到不同方案与代码分支中，随后因场景需求、参数配置和兼容逻辑的变化而独立演进。因此，同名逻辑图可能已具有不同的行为，代码分支的最新提交也未必对应线上部署版本。
一次公共能力升级或故障修复，需要先确认各运行版本的行为与差异，再评估影响、修改代码，并分别完成发布和回归验证。降低维护成本，需要减少公共能力的重复实现，让必要的场景差异得到明确表达和统一验证。
▐ 2.3 三类问题共同推高长期成本
第一类问题是分支副本化与多框架并存。
长期分支分别维护 Java 实现和图配置，公共能力无法沿一个主干持续演进。新场景习惯复制完整分支，而不是复用公共能力后只表达差异。多框架并存又要求维护人员在不同框架的组件模型、参数规则、执行机制和排障路径之间来回切换。
第二类问题是执行模型缺少稳定语义和统一生命周期。
自由图擅长表达节点之间的连接，却不一定能突出业务阶段、主执行路径和职责边界。串行、并行、条件执行和数据依赖混合在拓扑中，阅读者需要沿连接关系逐个查看节点及其代码，才能还原真实流程。每张图又是独立定义，请求初始化、公共校验、监控上报和资源清理等横切能力只能逐图接入。
线上接口拓扑图样例1
线上接口拓扑图样例2
如上图所示，不同业务的执行拓扑形态各异，缺少统一的阶段划分和组织方式，读者需要逐一追溯节点及其依赖关系，才能还原业务流程与执行顺序。
第三类问题是执行诊断和监控能力不足且分散。
历史应用缺少与实际执行树对应的完整节点记录。线上出现异常时，现有日志通常无法直接回答：请求执行过哪些节点、最早在哪个节点失败、异常原因是什么、耗时是否超限。不同场景还分别设计日志字段、指标和排查入口，同类问题难以复用同一套查询模板和排查经验。
三类问题叠加后，维护成本会随分支、图和场景持续增加，无法随着公共能力和历史经验的积累逐步摊薄。增加人员只能缓解局部排期，新成员仍然需要重复学习不同分支、框架和场景上下文。
因此，真正需要解决的不是某个类写得太长、某张图不够直观，而是原有应用生产方式已经无法被当前团队持续承接。
我们决定重构的不是代码，而是生产方式
▐ 3.1 为什么局部措施不够
面对历史系统，最容易想到的方案包括增加人员、局部重构、替换旧框架、补充监控工具，或者直接让 AI 分析和改写代码。这些措施都有价值，但只能改善局部问题。
AI 尤其不能直接接管一个依赖人脑解释的系统。模型可以阅读大量代码，但如果真实行为同时分散在代码分支、图配置、实验参数、动态开关和外部调用中，它首先面对的不是“如何写新代码”，而是“哪一份事实才代表线上”。如果流程和参数缺少稳定契约，AI 生成得越快，错误也可能扩散得越快。
我们最终把目标重新定义为：建立一套能够支撑多场景长期维护的统一生产方式，让公共能力能够复用，让场景差异能够显式表达，让流程具备稳定语义，让执行结果能够被统一验证。
▐ 3.2 从三类痛点推导运行框架能力
新的运行框架需要同时提供三组能力。
第一，统一应用和物料模型，并声明式表达差异。稳定能力由细粒度节点承载，场景差异主要通过流程组合、节点选择、参数、条件和配置表达，减少为隔离差异而复制完整代码分支的必要性。
第二，顺序优先、显式并行，并提供统一生命周期。流程应该可以自上而下阅读；串行、并行等待和异步旁路需要显式表达；请求前置和请求结束逻辑可以集中维护，不再逐图复制。
第三，统一产生结构化执行信息，并提供标准上报扩展。日志、监控和排查工具应当消费同一份执行事实，而不是要求每个业务节点自行定义诊断字段。
除了能力本身，我们还给底座设置了三项约束：轻量、易上手、扩展优先。框架只保留统一模型和执行语义所必需的机制，成熟的配置管理和中间件能力继续复用，平台差异和业务差异通过适配层与扩展点承载。
▐ 3.3 为什么选择自研
现有图执行框架各有侧重，在领域组件复用、通用图执行和运行诊断等方面提供了不同能力。结合多场景应用的长期维护需求，我们希望进一步统一应用模型、场景差异表达、流程语义、公共生命周期和结构化执行信息，并通过配套平台支持组件发现、可视化编排、版本关联和发布治理。
为此，我们选择建设由执行框架和编排管理平台组成的应用编排与运行体系：框架负责定义组件契约、执行流程和生成诊断信息；平台负责组件管理、流程编排及相关管理操作。两者围绕统一的应用模型协同，连接应用的设计、配置、执行与诊断过程。
如在现有框架上实现这些目标，仍需要建设新的核心抽象和配套平台能力，同时适配底层模型及其演进节奏。考虑到这些建设投入，我们选择自主维护这一层应用模型及配套工具，根据实际需求持续演进。
总体架构设计
这套体系由轻量执行框架与配套编排管理平台组成。它将原本散落在代码与图配置中的业务能力整理为可复用组件，并通过受约束的流程结构组织这些组件。执行框架保持与应用具体宿主平台解耦，负责流程执行、依赖协调和结构化诊断信息生成；编排管理平台负责组件发现、流程编排、版本关联和发布治理。
整体可以分为四层：
- 物料层：用
AtomicNode、ChainNode（组成Chain）等统一接口承载细粒度能力； - 编排层：用
Plan、Stage、ExecutorGroup描述业务流程及串并行关系； - 运行时层：负责条件判断、参数传递、并发调度、超时及异常处理；
- 诊断与适配层：生成
ExecuteRemark执行树，并通过扩展点接入日志、监控和宿主环境。
这种分层刻意把“稳定能力”和“场景差异”拆开：稳定能力进入物料代码，流程结构、节点依赖、条件和物料配置进入编排。公共能力可以在一个主干中持续演进，不同场景仍能通过声明式配置保持必要差异。
Emeya 总体架构与各层职责
▐ 4.1 AI Friendly 不是“AI 更容易写代码”
如果把 AI Friendly 理解为“模型能够快速生成代码”，这个说法并不准确。因为代码生成效果会受到模型版本、提示词和样例数量影响，它只能说明模型能力，不足以证明架构本身适合 AI 长期参与。
我们更关注的是：面对一个真实工程任务，AI 能否只读取与任务相关的局部上下文，能否在有限且稳定的工程语法内做选择，能否通过显式契约理解数据流，生成结果能否被确定性工具检查，运行后能否留下足以定位问题的证据。
按照这个标准，AI Friendly 不是一项独立功能，而是总体设计产生的工程属性：
这里需要区分运行底座和外围控制能力。固定流程层级、统一物料、参数契约和 ExecuteRemark 属于 Emeya 核心模型；DSL、Builder、metadata、解析器和校验器是围绕这套模型建设的 AI 控制层。新体系没有替 AI 保证结果正确，它提供的是一组稳定接口，使外部工具能够理解、生成、检查和重跑。
后续三个核心设计共同支撑了新体系的 AI Friendly 特性：统一物料降低单次任务需要读取的上下文，受约束流程减少需要临场推理的结构选择，结构化执行信息为验证和修复提供证据。
核心设计一：统一物料与声明式差异
5.1 从粗粒度 UDF 转向职责稳定的物料
历史节点中，一个类可能同时完成 RPC 请求构造、远程调用、结果解析和业务处理。粗粒度节点能够快速交付单个需求，却很难被其他场景直接复用；一旦部分逻辑存在差异，最简单的处理方式往往是复制类或复制分支。
新体系将业务流程拆分为职责更清晰的物料。AtomicNode 承载独立业务计算，ChainNode 承载参数构造、服务调用和结果解析等链式能力。节点通过明确的输入、输出和配置契约参与编排，不再依赖阅读完整调用链才能知道数据从哪里来、向哪里去。
细粒度不是越小越好。节点粒度需要同时满足三个条件：职责可以被一句话说明；输入输出可以稳定声明；能力存在独立测试或跨场景复用价值。纯粹为了拆分类而制造大量无意义节点，只会把代码复杂度转移到编排层。
5.2 稳定能力进入代码，场景差异进入编排
我们希望用一套代码和一个主干能够承载多个场景，但这不等于强行消灭差异。真正需要消除的是“用一套代码副本表达局部差异”的方式。
在新体系中，稳定的业务能力由节点代码承载，差异主要通过以下声明表达：
- 选择哪些节点；
- 节点按照什么顺序组合；
- 参数如何连接；
- 什么条件下执行；
- 超时时间多长；
- 并行策略是什么；
- 场景专属配置取什么值。
这样，公共能力升级时可以沿主干一次修改，场景差异仍保留在可阅读、可比较的编排中。新增场景也不再默认复制完整分支，而是先检索已有物料，判断能否直接复用或组合复用，只为真实能力缺口新增代码。
统一框架本身不会自动回收历史分支。主干开发约束、实验结束后的合并回收、长尾分支治理仍然需要由工程制度保证。新体系提供的是让这些治理动作可以发生的技术基础，而不是用框架替代治理责任。
从粗粒度 UDF 分支副本到细粒度物料与声明式编排
核心设计二：约束的流程语义与统一生命周期
▐ 6.1 为什么不继续使用自由图作为主要表达
自由图的优势是表达能力强，天然适合描述复杂依赖和并发关系。但表达自由也意味着阅读方式不稳定：同一类业务流程可能被不同开发者画成完全不同的拓扑，主链路和旁路任务混在一起，阅读者需要不断沿边回溯依赖。
我们做了一个明确取舍：牺牲一部分自由图的表达上限，换取稳定的阅读范式和可评审的并行边界。开发者按业务阶段阅读流程，运行时则根据并行属性和参数依赖调度任务。顺序表达不等于所有任务串行执行，框架仍然保留并发执行能力。
流程配置按照 Plan → Stage → ExecutorGroup → Node 的层级自上而下组织。Plan、Stage 保持顺序执行；需要并发时，由 ExecutorGroup 显式标记执行方式：
Plan示例
▐ 6.2 参数依赖既是运行契约，也是可验证事实
节点通过显式参数契约传递数据。每个节点声明输入、输出及其类型，上游输出与下游输入通过统一的参数标识（Key）建立连接。运行时可以据此协调依赖等待，工具也可以在执行前检查输入是否有生产者、类型与配置是否一致，以及数据依赖是否与执行顺序冲突。
以一个简化示例说明：节点 A 输出resultA，节点 B 将其声明为输入，二者便建立了明确的数据依赖。如果节点 B 引用了不存在的参数，或输入类型与上游输出不匹配，工具就可以在执行前指出问题；运行时则依据依赖关系，在所需输出就绪后继续执行下游节点。
通过这种方式，参数关系从隐藏在 Map、上下文对象和方法调用中的约定，转变为可以枚举和检查的显式契约。开发者能够直接查看数据的来源与去向，AI 可以依据契约理解和生成连接关系，工具则能够对这些关系进行静态校验。
▐ 6.3 把公共前后置流程变成一等能力
历史应用中，请求初始化、公共上下文准备、监控上报和资源清理往往散落在不同图中。每接入一项公共能力，都需要逐图新增和配置节点。
新体系允许定义固定的全局前置 Plan 和全局后置 Plan，业务流程执行时由框架统一拼接。公共能力可以集中维护、统一装配，不再依赖每个场景重复配置。
统一生命周期的价值不只是少写几份配置，它建立了公共治理的控制点：团队可以明确哪些逻辑必须在所有请求前执行，哪些诊断和清理动作必须在请求结束时发生。
业务 Plan 与全局前置、后置 Plan 的统一生命周期
核心设计三：让每次执行留下结构化证据
▐ 7.1 日志不是附属能力，而是执行模型的一部分
如果日志完全由业务节点自行决定，不同场景最终会形成不同的字段、格式和查询方式。即使所有节点都“有日志”，维护人员仍然无法用同一套方法还原请求执行过程。
新体系将诊断信息设计为执行模型的一部分。每次任务执行都会生成与实际任务树对应的 ExecuteRemark。Plan、Stage、ExecutorGroup、AtomicNode、Chain 和 ChainNode 等执行层级都会记录名称、状态、耗时、异常和扩展信息，最终形成一棵与真实执行过程一致的 Remark 树。
这棵树提供了一份统一原料：日志系统可以把它展开为结构化日志，监控系统可以聚合节点成功率和耗时，链路平台可以还原执行拓扑，排查工具也可以定位第一个失败节点。不同场景采用同一套模型后，查询模板和排查知识才具备复用基础。
Chain ExecuteRemark 样例
{
"async": 1,
"cost": 4,
"endTime": 1788262507769756,
"isProcessorBlocking": 1,
"isProcessorParallel": 0,
"name": "示例Chain",
"processorName": "SerialProcessor",
"startTime": 1788262507764919,
"success": 1,
"taskType": "Chain",
"subRemarks": [
{
"async": 0,
"cost": 0,
"endTime": 1788262507764957,
"name": "示例参数构造",
"processorName": "SelfRunTaskProcessor",
"startTime": 1788262507764928,
"success": 1,
"taskType": "ChainNode"
},
{
"async": 0,
"cost": 4,
"endTime": 1788262507769684,
"name": "示例调用器",
"processorName": "SelfRunTaskProcessor",
"startTime": 1788262507765016,
"success": 1,
"taskType": "ChainNode"
},
{
"async": 0,
"cost": 0,
"endTime": 1788262507769722,
"name": "示例结果解析",
"processorName": "SelfRunTaskProcessor",
"startTime": 1788262507769714,
"success": 1,
"taskType": "ChainNode"
}
]
}▐ 7.2 框架负责产生证据，应用负责接入技术体系
新框架不负责日志存储、指标聚合、监控大盘和告警实现，它提供两个标准处理钩子：节点或执行单元完成后，可以处理对应层级的 ExecuteRemark；接口完成后，可以处理整条请求的 ExecuteRemark。
应用通过这些出口统一接入现有日志采集、耗时统计、采样存储和监控上报。钩子的执行异常会被记录并隔离，不改变原业务执行结果，避免诊断链路反向影响主业务。
从人工迁移到 AI 迁移
新体系建立了目标生产方式，但历史应用不会因此自动迁移。真实行为仍然分散在 Java UDF、图配置和实验参数中。
迁移需要先还原旧应用事实，再按照新模型重建节点和流程，最后证明新旧链路行为等价。
我们没有从“写一个迁移 Skill”开始，而是经历了三个阶段：人工迁移建立基线、AI 迁移并打磨 Skill、直接复用 Skill 迁移新场景。
从人工迁移到 Skill 复用的三阶段演进
▐ 8.1 第一阶段：人工迁移建立事实与验收基线
考虑到图结构简单、输出较为稳定、迁移和验证成本可控，我们选择主播关注页作为人工迁移到新体系的首个真实业务场景。我们人工完成旧图、Java UDF、节点职责和数据依赖的还原，识别实验配置、动态条件和公共前后置行为，再将旧逻辑映射为新体系下的物料和编排配置。
人工迁移的目标不是证明人比 AI 更可靠，而是建立三类基线：哪些旧行为必须保留，旧框架概念应当如何映射到新体系，以及什么证据可以证明迁移正确。
主播关注页迁移整体投入约20人日，留下了第一批可复用资产：旧框架到新框架的概念映射、节点拆分与参数迁移规则、典型实现和编排样例、新旧链路对比方法，以及适合交给工具处理的重复任务清单。
没有这一步，后续 AI 迁移面对的只是一组散乱代码和抽象目标，生成结果即使看起来合理，也缺少事实和验收依据。
▐ 8.2 第二阶段：让 AI 迁移，同时把失败沉淀为能力
直播频道页成为第一个完整的 AI 迁移场景。我们将人工迁移形成的框架知识、迁移步骤和样例写入 Skill，让 AI 参与旧应用分析、目标拓扑设计、代码和配置生成、静态对账及差异修复。
此时的 Skill 不是一个预先设计完成的提示词，而是在真实迁移中逐步形成的工程能力。迁移暴露的错误被分成两类处理：
- 需要理解业务含义和历史语义的问题，补充知识、规则和样例；
- 可以确定性判断的问题，优先沉淀为解析器、生成器和校验脚本。
例如，AI 难以稳定还原旧图依赖，就增加图解析、血缘提取和依赖报告；复杂 Plan 手写容易出错，就使用脚本生成；生成结果难以走读，就把 Plan 反解为 Markdown；Java 参数、Spring Bean 和配置容易漂移，就增加跨产物契约对账。
每发现一种可重复错误，都不只是修复当前代码，而是判断怎样让下一次迁移更早发现、自动定位并能够重跑。Skill 因此从操作说明逐渐变成知识、规程、工具和验收标准的组合。
▐ 8.3 第三阶段：直接复用 Skill 迁移新场景
在后续迁移场景中，我们不再边迁移边从头建设 Skill，而是直接执行已经沉淀的标准流程：
- 读取旧应用和目标接口；
- 还原节点、依赖与配置事实；
- 生成迁移任务和依赖阶段；
- 按拓扑迁移节点；
- 生成代码、Bean 和 Plan；
- 执行确定性校验；
- 根据报告修复并重跑；
- 由人工审核业务语义和迁移结果。
复用 Skill 后，单场景整体迁移周期缩短到约 3 天。人工工作主要收敛为驱动 AI 工具执行任务、审核迁移结果、确认新旧差异，以及决定灰度、放量和回滚。
这次变化比“AI 写了多少代码”更重要：迁移经验先从人脑进入文档，再从文档进入工具，最后由 Skill 把知识、任务、工具和验收标准组织成可重复执行的过程。
复杂历史应用如何拆解为可执行迁移任务
▐ 9.1 输入不是一个代码仓，而是一组运行事实
历史应用的真实行为不只存在于 Java 代码中。一次迁移至少需要同时处理：
- 旧框架的图或流程配置；
- Java UDF 和 Spring Bean；
- 输入输出及共享上下文；
- 实验参数、动态配置和条件开关；
- 外部服务调用和异常处理。
如果只让 Agent 阅读仓库并直接改写，它很容易把代码引用关系误当成完整业务依赖，遗漏配置、实验和运行时注入形成的隐式行为。
因此，迁移第一步不是写代码，而是建立结构化事实基线：形成节点清单，记录节点类型、职责、输入输出、配置、外部依赖和异常策略；再从图连接、参数读写和隐式引用中生成依赖图。
▐ 9.2 按依赖关系划分 Stage，而不是平均切任务
依赖图生成后，迁移任务按照拓扑划分 Stage：上游依赖先迁移，无依赖或同层节点可以并行，下游只有在前置产物通过检查后才能开始。
主 Agent 负责维护全局事实、目标拓扑、公共约束和阶段状态；规模化执行任务负责迁移边界清晰的节点；确定性脚本负责图解析、任务生成、Plan 构建、参数闭环和跨产物校验。
这种分工解决三个问题：
- 上下文规模：把长任务拆成边界清晰的节点任务，避免上下文持续膨胀；
- 并行安全：由依赖关系决定哪些任务可以并行，避免下游先于上游迁移；
- 结果可靠：结构、配置和契约判断交给脚本，不依赖模型每次临场推理都得到相同结果。
AI 擅长理解、转换和处理局部差异，脚本擅长稳定解析、生成和校验。迁移过程不是二选一，而是让二者分别承担适合自己的工作。
AI迁移过程
如何证明迁移前后行为等价
迁移完成不能以“代码编译通过”或“接口返回成功”为标准。搜推在线链路依赖持续变化的召回、特征和打分服务，同一个请求在相近时刻执行两次，也可能因为实时数据、实验配置、缓存或服务状态不同而得到不同结果。
因此，分别请求新旧链路并比较最终响应，无法判断差异来自迁移逻辑还是两次请求获得了不同的外部数据。前面阶段的微小差异还会沿召回、打分、重排和结果组装不断放大，只比较最终结果也难以定位最早的偏差。
因此，我们建立了三层验证。
▐ 10.1 第一层：静态结构与契约校验
静态检查用于回答新应用是否结构自洽，包括：节点是否完整、Bean 实现是否一致、输入参数是否都有生产者、输出是否被正确消费、Plan 是否引用有效物料、配置类型和默认值是否一致。
这类问题可以确定性判断，应尽量在部署前由脚本发现。静态检查能够证明结构和契约闭合，但不能证明业务语义天然正确。
▐ 10.2 第二层：固定外部输入，分阶段比较新旧链路
为了隔离实时外部数据变化，我们采用“录制旧链路、回放给新链路”的方式：旧链路真实调用召回和打分服务时记录请求与结果，新链路在对应调用点使用同一份数据。这样，新旧链路的关键外部输入保持一致，剩余差异才更可能来自迁移逻辑。
比较也不是只看最终响应，而是按照召回、特征处理、打分、重排和结果组装逐层进行。发现差异后，先定位第一个出现偏差的阶段，再判断它属于预期配置差异、顺序无关差异、实时字段差异，还是需要修复的逻辑错误。
录制回放验证过程
▐ 10.3 第三层：预发、灰度与生产观察
Mock 可以隔离外部不确定性，但也可能掩盖真实集成问题。因此，静态检查和mock对比通过后，仍需要经过预发真实调用、分批灰度和生产观察。
灰度阶段同时观察技术和业务指标：接口成功率、RT 分布、节点异常和超时、核心业务指标和策略指标。AI 和工具可以整理证据、聚合差异并给出修复候选，但灰度放量和回滚始终由人工授权。
迁移稳定性的目标不是证明 AI 永远不会出错，而是让错误尽可能早地暴露，能够定位到责任阶段，修复后可以重跑，并且每次生产决定都有证据和责任人。
结果
▐ 11.1 已迁移场景的运行表现
新体系已在部分真实场景上线接流，并使用一套代码和一个主干承载所有已迁移场景。当前记录的四个场景中，迁移后的平均 RT、P99 RT 和 P999 RT 均未出现劣化：
表中数值表示“迁移后 RT – 迁移前 RT”，负数代表耗时下降。这组结果可以支持的结论是：在已经统计的场景中，新体系没有引入可见性能劣化，部分场景的长尾 RT 有所改善。
性能改善主要来自迁移过程中重新梳理执行关系，将部分不合理的串行操作调整为并行执行，而不是新框架性能更优。
▐ 11.2 迁移方式已经发生变化
三个迁移阶段的人工投入或周期呈下降趋势：主播关注页人工迁移约 20 人日，直播频道页在 AI 参与并同步建设 Skill 的阶段约 10 人日，后续复用 Skill 缩短到单场景约 3 天。
这组数字来自不同规模和复杂度的场景，不能直接当作严格效率实验。它更适合说明研发重心的变化：人工从逐项理解、设计和编码，逐渐转向业务约束补充、架构取舍、差异判断和生产授权；AI 承担批量分析、结构转换、代码及配置生成和重复修复；确定性工具承担事实解析、生成和校验。
复盘：比“让 AI 写代码”更重要的四个判断
第一，历史系统迁移必须先建立人工事实基线。
如果不知道旧系统哪些行为必须保留、概念如何映射、什么证据代表正确，AI 只能生成“看起来合理”的代码。人工迁移不是需要尽快绕过的低效步骤，而是后续自动化的事实和验收基础。
第二，先降低系统的解释成本，再扩大 AI 的执行范围。
AI 可以读取复杂代码，但稳定交付不能建立在每次都重新理解全部历史上下文上。统一物料、显式参数、受约束流程和结构化执行信息，本质上是在把人脑中的隐式知识变成机器也能使用的工程契约。
第三，确定性问题不要长期留给模型推理。
图依赖、参数闭环、Bean 注册和 Plan 结构都可以由程序稳定判断。真实迁移中，每遇到一种可重复错误，都应该判断能否沉淀为解析器、生成器或校验器。模型负责处理语义和差异，工具负责保证重复动作的稳定性。
第四，生成、验证和生产授权必须保持职责分离。
AI 可以生成代码、归纳日志和提出修复建议，但不能同时定义通过标准并批准自己的结果。业务语义、例外判断、灰度放量和回滚仍然需要明确的人工责任。可信迁移不是追求无人参与，而是让人工判断集中在真正需要负责的环节。
结语
新架构体系的价值不只在于把一种图结构替换成另一种流程结构，也不只在于帮助 AI 更容易生成代码。它真正改变的是历史应用的生产基础：公共能力有统一物料，场景差异有显式编排，执行流程有稳定语义，每次运行有结构化证据。这些结构降低了 AI 理解、生成和验证的成本，真实迁移又把一次性经验逐步沉淀为可复用的 Skill 与工具，它们共同构成了现阶段对 AI Friendly 的支撑。
这次实践给我们的最终判断是：面对复杂历史系统，AI 迁移的起点不是更长的提示词，也不是更激进的自动生成，而是先把系统改造成可理解、可约束、可验证的形态。
工程基础决定了 AI 能够安全走多远，也为未来 AI 理解需求、完成开发提供了支撑，让生成结果更可控、交付质量更稳定。
团队介绍
本文作者凉一，来自淘天集团-直播搜推工程团队。团队聚焦直播搜索、推荐与智能交互场景，负责商品、直播及直播看点的数据与索引建设，召回、粗排、精排等在线工程链路，以及面向消费者的直播 Agent 研发，持续提升系统性能、稳定性与业务迭代效率。同时，团队探索 Agent 在直播业务中的应用，推动算法能力与业务需求高效落地，为用户提供更精准、流畅、智能的直播内容发现与消费体验。
本文来自@大淘宝技术。原文链接：https://mp.weixin.qq.com/s/qsvb9pscxPHf0J1oWwDa_w?nwr_flag=1