海外SKILL提效实践，以本地原生开发动作为可信事件，集成转化为多系统管理操作，代替原需人工处理的多任务长周期跨系统操作。

核心内容：开发管理SKILL以本地原生开发动作为可信事件，附加本地持久化存储每个开发任务周期的关键信息，在一个开发窗口内将开发事件集成转化为多系统管理操作，自动化串联操作多个关键环节\系统形成全周期闭环。减少开发者人工在 PMS、飞书wiki、Email、GitLab、CI/CD、PaaS 与Release Management之间重复传递同一份上下文信息，将原需人工处理的长周期多任务跨系统操作，改为基于本地开发行为的AI自动化协同操作，提高研发效率。

面向谁

研发、测试与协同伙伴

解决什么

个人开发管理、进度流转、测试协同、发布交付与上线管理

实践载体

Git Hooks + Lark CLI + LLM CLI+ PMS + 飞书 + GitLab + 各交付平台

为什么需要“开发事件驱动”

产研协作中编码之外的成本：研发需要先获取或者自建PMS开发单，切到IDE 建分支启动开发，同时更新PMS进度、飞书整理开发文档、通知测试\产品提测；随后在 GitLab 建 MR、等待 Review、合并分支、创建 Tag，触发自动化 CI/CD 、PaaS 部署结果、上线申请单更新·状态。长周期多任务跨系统操作把一个连续的开发流程拆成了多次繁琐操作。

在本地开发过程中，是否可以实现持久化记忆每个开发任务生命周期的内关键信息，并根据开发行为去自动化操作多个系统，流畅走完开发管理全流程？

1.1 开发行为中的高确定性事件

设计转变：从“开发者人工逐步操作”，转向“研发在本地交互命令”。可通过高确定性事件智能化代理负责跨系统编排，GitLab、飞书、Wiki、CI/CD、PaaS 根据分支、MR 和 Tag 事件继续执行；人只负责范围、Reviewer、合并与发布等关键环节确认。

1.2 三类场景价值

个人开发管理

• 分支\PMS\Wiki 互相关联

• 提交说明自动携带 PMS

• 研发当前事项可查询、可追溯

进度跟踪

• push 形成持续进度证据

• PMS 状态随阶段动作变化

• 代码、工单、文档形成链路

协同自动化

• 提测与自动总结开发文档

• MR/Review/Test 人员自动通知

• Tag 触发交付，上线申请自动收口

开发管理SKILL经过几十轮迭代后， 已从“feature 分支自动建 PMS 单”演进为本地研发协同入口：以开发分支生命周期为主线，本地开发任务周期上下文持久化记忆，把关联PMS开发单、进度同步、提测、文档、通知、合并请求、Review 协同、Tag及触发自动化交付部署、PMS 上线和上线申请完成串成一条可执行链路。它不替代 PMS、GitLab 或交付平台，而是在开发者所在的 IDE/Agent 窗口中统一承接意图、补齐上下文、调用系统，并触发下游流水线接力。

2.1 总体架构

架构上分为六层：本地开发行为是事件源；Hooks 与统一 CLI 是“一窗通办”入口；策略编排层负责映射、状态机、AI、确认与幂等；连接器层打通 PMS、飞书、GitLab、邮件与 Release-mgmt；本地状态层保存工单、文档与推送指纹；外部交付层根据 release 分支或 master/main Tag 触发测试环境、CI/CD 镜像交付/PaaS 部署，上线申请中心则在部署确认后由“上线完成”命令收口。

分层说明

2.2 功能全景：以分支为开发事项载体

跳转微信打开

通过框架迁移、模型调优与性能优化，实现精排模型scaling up下效果、性能同步提升

过去几年，广告预估模型从“稀疏特征 + 轻量 MLP”的阶段，走向更大的 dense 网络、更复杂的特征交互和更长的用户行为序列。在广告预估中，CVR（转化率）模型的精度直接决定广告收入和用户体验。过去两年，我们的模型参数量增长了10倍，稠密计算量从5~8 MFLOPs跃升至60~70 MFLOPs，原有 TensorFlow + CPU 链路已逼近算力和成本极限，模型迭代空间出现瓶颈。

从计算特点看，这类复杂 dense 模型更适合 PyTorch + GPU。其优势体现在：

• 矩阵计算优势：模型参数矩阵越来越大、序列越来越长、网络越来越深，核心计算会更多落到矩阵乘、batch matmul、归一化和向量化规约等高并行算子上。GPU 在矩阵计算、混合精度和大 batch 推理上更有优势；

• 生态成熟：PyTorch 则提供了更贴近算法研发的动态图体验，以及成熟的 CUDA 算子、AMP/BF16、attention module、算子融合和模型导出生态，可以让复杂结构从实验到上线的链路更短。

行业和开源生态也在向同一方向演进。广告算法和基础架构 Jarvis 团队合作进行了本次框架升级。

本次升级的目标不是简单完成框架替换，而是让广告预估模型重新获得可持续迭代空间。我们选定 TorchRec [1] 作为迁移框架，构建 GPU 在线推理链路，让更大的 dense 网络、更复杂的特征交互和更长的用户行为序列赋能广告业务。

建设初期，TorchRec 模型与线上 Tensorflow 模型有接近 1pp 的 AUC 差异。借助 AI 工具和TorchRec 源代码，定位多个因素并进行关键优化：

1. 模型参数初始化：例如，稠密层权重采用与 TensorFlow 一致的 Glorot 均匀初始化；稀疏 Embedding 采用 uniform unit scaling 策略。

2. 调用统一 api 时的默认值差别：例如，多值稀疏特征在 embedding 聚合时，TorchRec 的默认聚合参数 sum，需要修改为 mean 以对齐期望的聚合方式。

3. TorchRec 损失函数与优化器参数设计：鉴于PyTorch 分布式框架的梯度平均池化的同步更新模式，损失函数在 batch 维度调整为需使用 mean 方法聚合。此外，模型还对稀疏参数与稠密参数的优化器做了拆分。使用更加稳定、学习率设置更低的 AdamW 优化器，并且通过基准学习率缩放，补偿 global batch 的扩大导致的优化步长差异。

4. GPU 初始化设置：Tensorflow Estimator 采用了 master 节点初始化参数，worker 节点加载参数的方案；PyTorch 分布式框架每个 worker 节点独立初始化参数，故需要人工设定配置，保证初始化参数的一致性。

至此，TorchRec 模型离线 AUC 效果成功打平线上，消除框架间的效果差异，为后续稠密模型 scaling up 升级奠定基础。

打平效果后，我们开始对模型本身做升级——这就是 scaling up 的核心。推全的转化率预估模型自上而下分为三层：特征输入层、特征交互层与多任务预测层。交互层借鉴 HyFormer [2] 提出的 Query Decoding 与 Query Boosting 思路，将长序列行为与非序列异质特征纳入同一骨干网络；预测层采用 MMoE 的多任务专家结构。

图 1 给出 CVR 模型整体架构，包括数据流与模块划分，便于对照下文各小节阅读。

3.2.1 特征输入层

特征输入上, 分为两类:

• 序列特征: 用户历史交互序列 S=[s1,s2,…,sT]，每个交互行为由 item ID、action type、timestamp、side info 经过 embedding 层后 concat 来表示。

• 非序列特征: 包含用户特征、Item 特征和上下文特征, 并将这些特征各自经过Embedding后再concat。

序列侧由三组用户行为组成：实时点击、点击空间与离线转化序列。组内多列拼接后再经小型网络映射到统一隐空间。为降低查表开销，三组序列共用底层 ID 嵌入表，一次查表即可取出全部子特征，再按组组装为定长序列表示。

此外，由于差异化场景下样本分布的显著差异，故训练时采用 EPNet 进行多场景建模，最终输出一个多域感知的非序列 embedding。

3.2.2 特征token化

不同于 RankMixer[3]，我们对于非序列 token 的 tokenization 方法如下：

这种将 embedding 空间划分为多个头的方式可以保持表示多样性，使模型能够在不引入过度结构复杂性的情况下捕获异构特征语义。这样得到的X=[x1,x2,…,xN]将作为接下来的非序列 token 与序列特征进行交互。

三条行为序列则各自经过 SwiGLU 网络映射至同一隐式空间，使不同来源、不同维度的序列可在同一注意力语义下交互。

3.2.3 特征交互层

图 2 - Query Decoding 模块结构

为了兼顾线上推理的算力约束与复杂的特征交叉需求，参考Hyformer [2]，我们将特征交互层拆解为 Query Decoding 与 Query Boosting两个阶段，数据流清晰可控。

并行输入准备：对齐两类特征的语义空间。交互层首先需要将异构的输入拉齐到同一维度。对于非序列特征（用户、Item、上下文），我们并未采用简单的向量拼接，而是将其 Embedding 在隐空间上切分为 N 个独立 Head。这种多头化的 Tokenization 方式，能以极低的额外参数量保留特征的语义多样性，让不同 Head 在后续交互中自动分化出差异化的信息角色（如部分侧重场景环境，部分侧重长期兴趣）。

与此同时，三条用户行为序列（实时点击、点击空间与离线转化）各自独立经过 SwiGLU 网络映射至上述同一隐空间。这里选用 SwiGLU 而非自注意力，是考虑到广告序列的相邻事件依赖较弱，而 SwiGLU 以线性复杂度完成逐位置变换，在长序列场景下远比自注意力的平方复杂度更适合线上预算。

Query Decoding：以非序列为“问句”，检索序列信息。该模块本质上是为每个非序列 Token 提供“向历史行为提问”的能力，可类比 Transformer 解码器的交叉注意力层：

• Query（查询）的构造：针对每一组序列，我们将 N 个非序列 Token 与该序列的均匀池化向量拼接，送入一层 FFN 生成 1 个全局 Query Token。三条序列的 FFN 参数相互独立，以保留点击、空间、转化三类行为间的天然差异性，最终共生成 S=3 个 Query。

• Key/Value（键值）的供给：直接由上述经 SwiGLU 编码后的序列隐状态担任。

随后，3 个 Query 与序列的 K/V 执行交叉注意力计算。在此过程中，我们特别调整了注意力温度系数，对点积结果进行缩放以防止 Softmax 退化为 One-hot 极值。这保证了注意力权重的“有效秩”维持在高位——通俗来说，就是让每个 Query 都能平滑地从多步历史行为中吸收信息，而非过早锁定在极少数行为上，从而提升训练的稳定性。

Query Boosting：全量 Token 的深度融合与语义校准。交叉注意力之后，我们并未直接输出，而是将上一步得到的 3 个序列解码 Token 与原始 N 个非序列 Token 合并，共计 (N+3) 个 Token 一同送入 Token Mixer 模块。借鉴 TokenMixer-Large [4] 的思路，该模块执行“解构（Split）→ 融合（Mixing）→ 重构（Reverting）”三步：

• Mixing 阶段让所有 Token 两两充分交互，打破非序列与序列的边界，实现全局信息融合；

• Reverting 阶段则将混合后的表示映射回与原 Token 语义对齐的空间，确保后续残差连接时特征不发生语义错位。

灵活的 Scaling Up 潜力。该特征交互层支持像 Transformer Decoder 一样堆叠多层。考虑到线上推理时延与机器成本的 ROI，当前推全版本仅使用 1 层。但离线实验表明，当我们将层数从 1 层加深至 2 层时，离线 AUC 可获得超过千分之一的稳定提升——这为我们后续在算力充裕时继续纵向加深网络、充分释放 GPU 红利留下了明确的迭代空间。

3.2.4 预测层

预测层使用PLE+MLP预估头的结构，分别预估不同场景的pCVR值。其中，PLE由3个为单层全连接层的专家网络组成，预估头则由两层带非线性激活函数的全连接层组成。

在具体推全方案中，我们采用以下核心超参配置：Token 隐层维度 token_dim=128，特征交互层堆叠 1 层，非序列 Token 数量 N=13，序列解码 Token 数量 S=3，单条用户行为序列长度 T=50。该配置下的离线 AUC 相对基线模型提升 0.4 个百分点（pp）。

在此基础上，我们已规划明确的 Scaling Up 路线：后续算力继续扩充后，将沿“更宽的 Token 隐层维度、更深的特征交互模块堆叠、更复杂的序列 Token 建模”三个方向并行推进，持续挖掘模型在 GPU 算力下的性能上限。

TensorFlow 生态提供了成熟的 SavedModel 导出与 Serving 方案，而 PyTorch/TorchRec 模型的导出则面临更多挑战，难点主要来自稀疏/非定长特征中的 offset（偏移量）、序列长度等动态维度信息。训练时，这些信息通常以 Python 原生数据结构（如 list、dict）参与计算图构建，在 Python 环境中运行一切正常，但导出后容易被固化为计算图中的 int/string 常量。一旦线上请求的 batch size、特征组成或序列长度发生变化，这些固化常量便可能与真实输入不一致，轻则导致推理结果错误，重则使导出产物体积膨胀、版本更迭困难。

为解决这一问题，我们将训练链路与推理链路解耦，在推理链路中提前将前向计算逻辑固化为静态计算图。具体做法是：将模型版本间保持固定的信息——如 Embedding 权重、特征到 Embedding 表的映射关系、Pooling 方式等——作为模型配置随图一同保存；而将每次请求均可能变化的 meta 信息（如序列长度、特征偏移量、样本数量等）显式定义为 Tensor 输入，由原生算子在运行时动态计算。如此一来，导出的计算图不再依赖 Python 对象或导出时的固定 shape 样例，从根本上保证了线上推理的鲁棒性与正确性。

在模型的初版 GPU 推理链路中，我们保留了较多原始 PyTorch 执行路径，压测结果显示，单位资源下的吞吐量与时延收益均低于预期。随后，我们对推理过程进行了详细的性能剖析（Profiling），识别出 CPU/GPU 数据搬运、稀疏参数查表、变长序列处理、稠密网络计算以及请求合并等关键环节存在明显瓶颈，并逐一进行了针对性优化。

3.4.1 数据搬运 — 批量拷贝与 GPU Buffer 复用

线上请求进入服务时，大量特征最初驻留在 CPU 内存中。若对每个输入单独执行拷贝，或在 CPU 与 GPU 之间反复进行 reshape、concat 及用户特征展开等操作，数据搬运本身便会成为新的性能瓶颈。我们的优化思路是：在 CPU 侧完成批量的 concat 操作，统一搬运至 GPU 后再进行展开处理，同时尽可能复用已分配的 GPU 显存缓冲区（buffer），从而显著减少冗余拷贝与临时张量的产生。

3.4.2 Sparse 查表 — 合并小算子，减少 Kernel Launch 开销

广告预估模型通常涉及大量 Embedding Lookup、Pooling、序列补齐以及稀疏张量转稠密张量等操作。若这些操作逐个独立执行，将产生大量细碎的小 Kernel 和中间张量，导致 GPU 计算资源难以充分发挥。我们的优化方案是：将多组 Embedding 查表、User/Item 特征对齐、变长序列处理等逻辑合并至更少的 GPU 算子中，从而显著减少 Kernel Launch 次数与中间结果的写回开销，让稀疏侧的计算模式更贴近线上推理的真实数据布局（如按需访问、减少冗余补齐），进一步提升执行效率。

3.4.3 Dense 计算 —  TensorRT 图优化与 BF16 推理

复杂dense网络的主要计算集中在矩阵乘、归一化、激活函数和 attention/sequence block 上，这部分适合交给 TensorRT 做图优化、算子融合和 kernel 选择。在线上可接受的精度范围内，我们引入 BF16 推理，降低显存带宽和计算开销；同时通过动态 profile 覆盖不同的 batchsize 和序列长度，支持模型在各种输入 shape 下高效运行。

3.4.4 Kernel 调度 — CUDA Graph 捕获与重放

TensorRT Engine 虽然已经大幅优化了稠密计算部分的效率，TensorRT Engine 虽然已经大幅优化了稠密计算部分的效率，但推理过程中的输入输出张量绑定、显存分配与释放、执行上下文切换以及 CUDA Kernel 的逐个发起（Launch），仍会带来可观的调度开销和时延抖动。为此，我们按 batch bucket 复用执行上下文和显存 buffer，并用 CUDA Graph 将稳定的 kernel launch 序列捕获下来，在后续请求中直接重放，减少 CPU 侧逐个发起 kernel 的调度成本。最终的目标是让 GPU 的算力尽可能多地用在模型前向计算本身，而非消耗在运行时编排上。

3.4.5 请求合并 — Triton Server 的 User/Item 混合批处理

为了提升 GPU 利用率，我们会将多个线上请求聚合成一个批次（Batch）后再送入 GPU 计算。然而，在线广告请求与标准的深度学习推理请求存在一个关键差异：为节约网络带宽和减少计算图中的冗余操作，每个广告请求通常仅包含 一个 User 的特征 与 多个候选 Item 的特征，即 User 侧与 Item 侧在数量上天然不对齐。标准推理框架原生不支持这种 “User Batch + Item Batch” 的混合语义，无法直接合并请求。

为此，我们在 Triton Server 推理服务层补齐了这部分能力：服务能够区分用户侧特征与物品侧特征，分别按照各自的维度逻辑进行拼接，同时通过请求级别的标识符保留 User 与 Item 的一对多关联关系。在计算图中，我们采用“尽可能延迟（Lazy）”的策略，将 User 特征的复制（Repeat）操作尽量后置，直至与 Item 特征拼接的前一刻才执行。这样做既保证了批量推理的吞吐优势，又最大程度减少了中间张量的显存占用与计算冗余。

3.4.6 调优自动化 — 大模型辅助的性能调优 Workflow

在算子开发过程中，我们采用了基于大模型实现测试/规格驱动开发（TDD/SDD），提高代码的可维护性，大幅提升开发速度。并实现了 Develop/Debug/Test/Profiling/Monitor Agent 协同 workflow，自动定位推理瓶颈并持续优化，实现性能调优自动化工作流，人工调优耗时减少 50%，满足模型推理高吞吐、低延迟要求。

• CVR 模型：收入+3.42%，RPM+2.81%，点击数+1.91%，转化数 +7.22%，深层收入 +2.28%。

• DCVR 模型：收入+1.60%，RPM +1.21%，点击数+1.01%，转化数 +0.25%，深层收入 +2.37%。

4.2 推理效率

• 机器成本减少15%，超时率从0.15% 降至0.03%。

本次框架升级为广告预估模型的长期演进打开了新的算力空间。我们将在模型结构、推理优化和平台化三个方向持续深耕：

• 模型结构：GPU 框架释放出的算力红利，将直接用于扩大稠密（Dense）参数规模，引入更强的序列建模能力（如更长时序依赖、多兴趣表征）、更复杂的注意力结构（如轻量级多头自注意力）以及更深层次的多任务学习体系。未来，CVR、DCVR 等核心模型可以围绕更精细的用户行为理解、更细粒度的转化目标拆解和更充分的特征交叉结构持续演进。

• GPU 推理优化：持续挖掘 GPU 算力潜力，重点推进算子融合（进一步减少 Kernel Launch 次数）、混合精度推理（如 INT8 量化探索）、动态批次处理（Dynamic Batching）、Embedding Cache（高频特征的显存驻留）以及多模型混部与资源弹性调度等方向，在保障时延的前提下持续提升单卡吞吐能力。

• 平台化：将本次迁移过程中积累的模型结构规范、导出工具链、性能调优方法论和 Triton 服务配置模板，沉淀为一套可复用的 TorchRec GPU 训推一体化框架。后续新模型接入时，仅需在框架内配置模型结构即可完成训练、导出与上线，接入工作从“系统工程”简化为“配置化接入”，大幅提高算法的迭代效率。

[1] Ivchenko D, Van Der Staay D, Taylor C, et al. TorchRec: a PyTorch domain library for recommendation systems[C]//Proceedings of the 16th ACM Conference on Recommender Systems. 2022: 482-483.

[2] Huang Y, Jin J, Hong S, et al. HyFormer: revisiting the roles of sequence modeling and feature interaction in CTR prediction[J]. arXiv preprint arXiv:2601.12681, 2026.

[3] Zhu J, Fan Z, Zhu X, et al. RankMixer: scaling up ranking models in industrial recommenders[C]//Proceedings of the 34th ACM International Conference on Information and Knowledge Management. 2025: 6309-6316.

[4] Jiang Y, Zhu J, Han X, et al. TokenMixer-Large: scaling up large ranking models in industrial recommenders[J]. arXiv preprint arXiv:2602.06563, 2026.

海外Agent实践：让问题直达源码，助力团队提效！

爱奇艺AI驱动漏洞闭环治理：让安全发现更智能、修复闭环更高效

纳逗Pro全链路赋能、专项免费算力支持！爱奇艺AI影视创作营第二期来了

AI 时代的质量门禁左移：Agentic Quality Engineering 架构与落地模板

爱奇艺大数据混合云存储

跳转微信打开

海外Agent探索实践，智能化跨系统串联多方数据并结合代码综合分析，让问题直达源码，助力团队协作提效！

跳转微信打开

构建AI安全治理体系，推动漏洞发现与修复智能化闭环。

随着业务系统、API 接口、AI 应用和自动化工具持续增长，安全治理的复杂度也在快速上升。

一方面，资产和接口数量持续增加，仅依赖人工排查很难做到全面覆盖；另一方面，业务逻辑漏洞、越权漏洞、修复绕过等问题，往往需要理解业务场景、接口关系和权限边界，传统扫描器很难稳定发现。

更重要的是，漏洞发现只是第一步。后续的风险确认、通知提醒、业务沟通、修复推动、复测验证、白盒扫描接入、WAF 整改等流程，过去高度依赖人工运营。安全同学需要反复解释风险、催办进度、协助协同、跟进修复状态，整体闭环周期较长，也容易受到人力投入影响。

为解决这些问题，我们围绕“漏洞发现—风险确认—修复推动—运营处置”构建了 AI 驱动的安全闭环治理体系，通过 AI 安全白帽、安全小助手、多智能体协同和工具调用能力，将漏洞治理从过去的“人工驱动为主、规则扫描为辅”，升级为“AI 智能体驱动、人工校验兜底”的新模式。

其中，在自动修复方向，团队基于自研安全编排平台探索了“事件驱动 + Agent 自动修复”的实践：当安全扫描产生缺陷或用户主动发起修复任务后，系统可自动触发修复 Agent，完成缺陷理解、修复方案生成、代码修改、自测验证和合并请求提交，并在关键节点引入人工确认、状态留痕和独立裁决机制，避免 Agent “自修自批”，确保修复过程可控、可审计、可追溯。

简单来说，AI 不再只是辅助分析工具，而是开始参与漏洞发现、风险验证、业务沟通和闭环推动，让安全治理变得更主动、更高效、更可持续。

AI 提效：让漏洞治理更快发现、更快修复、更少人工消耗

项目通过 AI 安全白帽与安全小助手，构建了覆盖漏洞发现、验证、通知、修复推动和运营处置的智能化闭环。

在漏洞发现侧，AI 安全白帽上线以来累计发现百余个有效安全风险，其中包含二十余个高风险问题，覆盖业务逻辑、权限控制、接口安全、数据保护等多个典型场景。通过 AI 自动分析、上下文理解和自动化验证能力，安全团队能够更快发现过去主要依赖人工经验挖掘的高价值漏洞。

在运营闭环侧，安全小助手进一步承接漏洞通知、修复沟通、白盒扫描接入和 WAF 整改等流程。上线后，白盒扫描接入量显著提升，漏洞平均修复周期明显缩短，修复逾期率持续下降。

这说明 AI 的价值不仅体现在“多发现漏洞”，更体现在“让漏洞更快被理解、更快被处理、更快完成闭环”。

体验升级：从“只能看通知”到“可以直接问”

传统安全通知体系主要解决的是“把信息发出去”的问题。业务同学收到通知后，通常只能阅读内容；如果想继续了解漏洞详情、影响范围、资产归属、处理建议或接入流程，仍然需要额外找安全同学沟通。

安全小助手带来的核心变化，是将安全协作从“告知型安全”升级为“服务型安全”。

过去，安全团队更多是向业务同步风险、发送通知、推动整改；现在，业务同学可以通过统一的对话入口，直接完成安全咨询、问题确认、流程推进和反馈闭环。

例如，业务同学可以直接询问：

• 这个漏洞影响哪些资产？

• 我负责的域名是否已经接入安全能力？

• 这个安全通知需要我做什么？

• 漏洞修复完成后应该如何反馈？

• 能否协助拉相关同学一起推进处理？

通过这种方式，安全服务不再只是“发通知、提要求”，而是进一步前置到业务日常工作中，帮助业务更快理解风险、更快找到责任人、更快完成整改闭环。

同时，安全小助手发出的通知会沉淀在聊天记录中。通知不再是一次性消息，而是后续对话、追问和处理的上下文基础，减少了重复解释和反复确认成本。

AI 安全白帽不是传统扫描器的简单升级，而是将 AI 推理能力与接口上下文、业务语义、代码分析和自动化验证工具结合，形成具备自主分析能力的智能漏洞挖掘体系。

在漏洞挖掘过程中，AI 可以结合接口参数、调用链关系、业务语义和权限边界，识别未授权访问、水平越权、ID 遍历、权限提升、敏感数据导出、注入类风险等高价值漏洞。

对于信息不完整的场景，AI 还可以主动补全上下文，分析相关代码和接口关系，理解复杂防御逻辑和潜在绕过路径，并通过自动化验证方式降低误报、提升漏洞确认效率。

相比传统扫描器主要依赖规则匹配，AI 安全白帽更擅长发现依赖业务理解、权限关系和接口调用链分析的复杂漏洞，覆盖了过去主要依赖人工安全专家手工挖掘的高价值场景。

核心能力二：安全小助手，让漏洞运营从“人工催办”变成“智能闭环”

安全小助手基于多智能体协同、工具调用和流程编排能力，承接漏洞提醒、修复沟通、白盒扫描接入、WAF 整改、模板化通知等安全运营流程。

在实际使用中，安全小助手可以根据不同场景自动理解任务、拆解步骤，并调用对应工具完成处理。例如，针对漏洞整改场景，可以自动发送通知、解释风险、协助确认负责人、跟进修复状态，并在必要时触发人工确认。

针对高风险写操作，系统引入Human-in-the-loop机制，也就是“关键动作人工确认”。涉及通知、建群、写入、整改推动等动作时，既能利用 AI 自动化提效，也能确保关键操作可确认、可审计、可追溯，兼顾效率与安全合规。

通过自动提醒、自动协同、流程编排和上下文沉淀，安全小助手显著降低了安全运营中的重复沟通成本，让安全同学从大量事务性催办中释放出来，把更多精力投入到高风险研判和治理优化中。

典型实践一：SQL 注入检测与自动化复核

在 SQL 注入治理场景中，项目引入基于大模型的数据标注能力，并建设扫描结果自动化验证模块，支持漏洞的自动化复核和风险确认。

在某业务场景中，AI 发现一个注入类风险存在修复不彻底问题。原防护策略只处理了部分特殊输入，但仍存在绕过风险。AI 通过进一步分析和验证，识别出残留风险，避免漏洞出现“表面修复、实质仍可利用”的情况。

这类场景说明，AI 不只是发现新漏洞，也可以帮助识别漏洞修复后的绕过风险，提升复测质量和修复可靠性。

典型实践二：高价值业务逻辑漏洞发现

AI 安全白帽在多个核心业务场景中发现了高风险业务逻辑漏洞，暴露出业务系统在权限控制、身份校验和敏感数据保护方面的薄弱点。

例如：

• 任意文件读取风险：攻击者可能通过漏洞读取服务器上的敏感文件，进一步获取配置文件、密钥或账号凭证，扩大攻击面。

• 接口未授权访问风险：部分接口缺少有效身份校验，可能导致用户信息或业务数据被越权访问。

• 越权操作风险：部分业务接口对用户身份和资源归属校验不足，可能导致越权查询、修改或删除数据。

这类漏洞往往不是简单的规则匹配问题，而是依赖对业务身份体系、权限边界、接口语义、调用链路和数据敏感性的综合理解。传统扫描器通常难以稳定识别此类复杂业务逻辑风险，而 AI 安全白帽能够结合上下文进行推理分析，主动发现隐藏在业务流程中的权限绕过、越权访问和敏感数据暴露问题。

典型实践三：让复杂安全流程更轻量

安全小助手背后的关键能力，是多智能体调度架构。

可以简单理解为：安全小助手就像一个“主助手”，负责理解用户问题、拆解任务、规划处理步骤；再根据不同场景，调用对应的“专业子助手”或工具完成具体任务。

过去，如果要支持一个新的安全查询或处理流程，通常需要提前设计固定意图、开发接口能力、配置规则流程，并人工编排数据源和处理逻辑。每增加一个数据源、一个工具或一个新流程，都需要重新开发和配置，扩展成本较高，也难以应对复杂、动态、多步骤的问题。

现在，安全小助手可以基于 AI 的理解与规划能力，自动将用户问题拆解为多个步骤，并结合上下文调用不同能力。

例如，当用户询问某个安全通知时，小助手可以：

• 理解通知内容；

• 关联历史处理记录；

• 查询相关资产和负责人；

• 判断当前处理状态；

• 给出下一步处理建议。

也就是说，安全小助手不只是“回答问题”，而是能够协助完成从理解、查询、判断到推进的完整流程。

这种模式带来了四个直接价值：

第一，减少人工解释成本。很多常见问题可以由小助手直接回答，业务同学不必反复拉安全同学确认。

第二，降低业务理解成本。安全信息不再只是长文档、专业术语或复杂规则，而是转化为更易理解的对话式说明。

第三，提升流程推进效率。服务接入、漏洞协同、修复提醒、资产查询等操作，可以通过小助手统一承接，减少跨系统跳转和人工中转。

第四，增强能力扩展性。通过模板化通知、工具调用和子智能体能力，新场景可以更快接入，不需要每次都从零开发完整流程。

整体来看，多智能体调度架构让安全小助手从“问答工具”升级为“流程协作入口”，把原本复杂、分散、依赖人工推动的安全流程，变得更加轻量、高效和易扩展。

典型实践四：一个窗口处理更多安全事项

安全小助手目前已覆盖多个典型安全协作场景，正在把分散的安全咨询、查询和流程推进，逐步整合到一个对话窗口中。

1.服务接入：从“问流程”到“直接推进”

在服务接入场景中，小助手可以协助业务同学查询接入状态、了解接入要求，并根据当前进度推动后续流程处理，减少反复沟通和人工确认成本。

2.资产查询：从“找人查”到“随时问”

在资产查询场景中，小助手可以帮助业务同学快速了解域名、系统、服务等安全相关信息，减少“找人问、等人查”的时间，让资产信息获取更加便捷。

3.漏洞处理：从“单点通知”到“持续闭环”

在漏洞治理场景中，小助手支持漏洞协同、修复提醒、处理进度跟进等能力，帮助安全团队和业务团队围绕同一个问题持续协作，推动漏洞从发现、通知、修复到反馈形成闭环。

4.多模态输入：让问题提交更自然

在多模态能力方面，小助手也在探索支持图片、文档等多种输入形式，使业务同学可以用更自然的方式提交问题、补充材料和说明上下文。

对业务同学来说，安全小助手带来的核心变化可以概括为一句话：

过去处理安全事项，往往需要“找人、查系统、看文档、等反馈”；现在可以先从一个对话窗口开始，直接提问、持续跟进、推动闭环。

典型实践五：事件驱动的 Agent 自动修复

面对白盒扫描持续产出大量代码安全与质量缺陷、人工修复链路长且易遗漏的问题，团队探索并落地了“事件驱动 + Agent 自动修复”的漏洞治理实践。系统可在流水线安全扫描完成后，或由安全平台主动发起修复任务时，自动接收扫描结果并触发专用修复 Agent。Agent 会基于缺陷上下文自动完成问题理解、修复方案生成、代码修改、自测验证和合并请求提交等流程，将原本依赖人工串联的修复过程转化为自动化闭环。

为避免 Agent “自修自批”，实践中引入了多阶段确认与独立评估机制，在修复方案、修复结果、流程状态和发布门禁等关键节点保留必要的人工确认、过程留痕和质量校验能力，确保自动化修复过程可控、可审计、可追溯。落地实践表明，该模式可显著缩短单个漏洞修复周期，提升修复效率，并已在多个项目和流水线场景中完成批量验证，覆盖百余个高优先级缺陷修复。整体来看，该实践在提升漏洞治理效率的同时，也强化了自动化修复过程中的安全边界和质量保障能力。

当前新版本进一步强化了多段门禁、自动拦截、失败即关闭和独立裁判服务，在提升漏洞修复效率的同时，增强了安全边界和质量保障能力。该实践标志着 AI 能力从“辅助分析安全报告”进一步走向“参与漏洞修复闭环”，也为后续构建“发现 Agent—修复 Agent—评估 Agent”的多 Agent 协同安全治理体系奠定了基础。

创新点

1.AI 提升的不只是发现能力，更是闭环效率

AI 安全能力的价值，不仅在于发现更多漏洞，也在于让漏洞更快完成闭环。

在发现侧，AI 安全白帽通过上下文理解、代码分析、接口语义识别和自动化验证，提升了高价值漏洞的发现效率。

在运营侧，安全小助手通过自动通知、智能问答、流程推进和工具调用，提升了漏洞修复协作效率，减少了大量重复解释、人工催办和跨系统操作。

这意味着，AI 不只是提升“发现问题”的能力，也在提升“解决问题”的效率。

2.从“辅助工具”到“治理智能体”

项目最大的创新在于，将 AI 从“辅助分析工具”升级为“安全治理智能体”。

在发现侧，AI 安全白帽结合接口台账、代码上下文、业务语义和自动化验证工具，实现类安全专家的自主分析与漏洞确认。

在运营侧，安全小助手通过多智能体协同、工具调用和流程编排，将漏洞提醒、业务沟通、复测验证、白盒接入和 WAF 整改串联成可执行、可追踪、可审计的闭环流程。

这使安全治理不再只依赖单点人工经验，而是逐步沉淀为可复制、可扩展、可持续迭代的智能化能力。

总结与展望

整体来看，AI 驱动的漏洞闭环治理不仅提升了漏洞发现能力，也显著降低了人工挖掘、漏洞运营通知和系统整改推进成本，推动安全能力从“单点工具”向“智能闭环平台”演进。

通过 AI 安全白帽、漏洞自动化复核、安全小助手和闭环运营能力的结合，安全工作正在从依赖人工经验的被动响应，转向可规模化、可持续迭代的智能化治理模式。

未来，AI 安全能力将继续向更深层次的业务理解和自动化协同演进。

一方面，AI 安全白帽将从单点漏洞发现，进一步扩展到复杂业务逻辑分析、跨系统攻击链推理、自动化复现和修复建议生成，持续提升高价值漏洞发现效率。

另一方面，安全智能体将进一步增强协作能力，在漏洞识别、风险判断、影响面分析、整改建议和修复验证中形成更完整的闭环。

同时，围绕智能体身份识别、权限控制、凭证代理、访问审计和安全基线等基础能力，后续也将持续完善 AI Agent 在企业环境中的安全运行机制，确保 AI 能够在可控、可审计、可追溯的前提下访问业务系统和执行安全任务。

整体目标是将 AI 能力从“辅助发现问题”升级为“参与安全治理”，逐步形成覆盖风险识别、自动评估、闭环运营和持续治理的 AI 安全体系。

纳逗Pro全链路赋能、专项免费算力支持！爱奇艺AI影视创作营第二期来了

AI 时代的质量门禁左移：Agentic Quality Engineering 架构与落地模板

爱奇艺大数据混合云存储

这张成绩单，数字一个比一个猛！

别让AI瞎猜了：用Harness Engineering 终结无限返工

跳转微信打开

新增实战派导师 头部制作平台加持

当下，AI技术大幅降低了影像创作的入门门槛，“一键成片”让人人都能快速生成视觉画面。量产内容趋于同质化的当下，优质叙事能力、专业镜头语言、高阶审美判断成为AI无法替代的核心创作壁垒，更是拉开创作者差距的关键核心。立足行业痛点与人才需求，爱奇艺重磅升级打造AI影视创作营第二期，以大咖亲授、实战实操、全链赋能的模式，助力广大创作者实现“会用AI工具”到“用AI讲好影视故事”的进阶蜕变。

爱奇艺AI影视创作营聚焦“AI+专业影视创作”核心能力培养，首期课程凭借干货内容、实战教学收获行业及学员广泛好评。6月17日起，创作营第二期正式开启全网招募。在首期成熟教学体系基础上，本次课程、导师全方位迭代升级，大幅提升AI实操教学占比，让内容聚焦一线AI导演实战创作心法。

第二期课程内容覆盖影视叙事与角色塑造、AI影视导演思维、声音设计与听觉叙事、AI制作技术与影视级后期、用户洞察与版权合规五大核心模块，通过5天系统化、沉浸式集训帮助学员搭建AI影视创作知识体系，掌握AI工具与影视专业创作的融合技巧，精准突破AI创作画面同质化、叙事薄弱、质感不足等核心问题。

第二期创作营延续“让故事更精彩、让制作更专业”宗旨，深耕实战化教学理念，集结编剧、影视表演、AI导演、声音设计、影视技术等多领域资深行业大咖，组建全维度导师团队。相较于首期，本次课程新增曾赠、朱雷蒙、李杨三位深耕AIGC影视创作一线的实战派导演。一众导师兼具传统影视创作深厚功底与AI工具融合落地经验，深谙当前AIGC影视创作的技术边界、行业瓶颈与创新方向。教学过程中，导师将拆解影视叙事底层逻辑与专业创作方法论，结合真实AI影视创作案例，为学员搭建从剧本构思、叙事打磨到AI可视化呈现的整体创作思维。

为解决学员“学完不会用、成片质感差”的难题，第二期创作营重点强化实战实操环节，依托爱奇艺自研专业级影视制作平台纳逗Pro，为学员提供从创意构思到成片的闭环创作支撑。

纳逗Pro以公共大模型及自主部署的大模型为底座，沉淀爱奇艺在影视工业化、专业制作领域的深厚经验，同时通过结合爱奇艺IP库、数字资产库和创作者社区，形成可调用的平台能力。目前，纳逗Pro为创作者提供专业画布工作流、大规模团队协同创作等服务，支持影视剧本评估、3D导演台实现多角色构图、长剧集角色一致性等专业级影视创作能力，更有“专业戏增强智能体-武打戏”“人物情感关系图”等独家功能，支持多样创作需求。

本次创作营将持续为学员提供单次超200次镜头生成的专项免费算力支持，全面覆盖镜头生成、画面重绘、细节精修等全流程创作需求。同时，纳逗Pro专属技术导师全程驻场指导，一对一解答工具操作、技术落地难题，保障每位学员都能深度上手、熟练实操。

课程结营后，优秀创作者将获得爱奇艺AIGC创意中心优先入驻资格、平台专属流量扶持、官方项目合作对接、多元化商业变现机会 。爱奇艺将致力于全方位搭建创作者“学习-创作-出圈-变现”长效成长通道。

作为国内AIGC影视生态的核心建设者，爱奇艺持续深耕AI影视赛道，自2025年起陆续落地系列重磅创作活动，搭建完善的AI影视创作孵化体系。此前，“与AI共生”短片大赛、“鲍德熹·爱奇艺AI剧场”创作营等活动已成功举办，其中“鲍德熹·爱奇艺AI剧场”16部入围作品已全部上线播出，收获良好行业口碑。

今年5月20日，爱奇艺携手奥斯卡大奖得主鲍德熹全新升级项目，正式启动“鲍德熹·爱奇艺电影剧场”AIGC商业电影创投计划，面向全球征集60分钟以上AIGC华语商业电影项目，计划孵化推出10部优质长篇商业作品，推动AI影视创作从短篇实验探索，正式迈向长篇商业电影的工业化、市场化新阶段。

依托2026爱奇艺·世界大会战略布局，爱奇艺持续升级创作者扶持体系：全新迭代的爱奇艺号（IQID）已正式上线，实现创作者零门槛入驻、一次性签约、全品类内容通发、高效发布运营；同时推出专项分账补贴政策，2026年底前，AIGC内容与中剧内容可享受20%额外分账补贴。此外，平台从AI工具赋能、专属算力支持、IP授权对接、项目投资合作、专项培训、办公场地供给、市场分发等维度，构建全方位、全周期的创作者扶持生态。目前，爱奇艺AIGC（上海）创意中心已迎来变月文化、熹屿人生等多家优质创作者机构入驻，产业集聚效应持续凸显。

未来，爱奇艺将持续完善AIGC影视创作全链路生态，开放平台资源、升级扶持政策、拓展商业场景，诚邀广大影视创作者、AI创作爱好者携手合作，深耕AI影视创作领域，产出更多高品质原创内容，依托爱奇艺成熟分发运营体系实现价值落地与商业增收。 

报名须知

报名时间：6月17起至7月21日

报名流程：点击原文链接填写报名，提交个人创作相关背景信息，经官方审核通过并完成缴费后，即为报名成功。

阅读原文

跳转微信打开

AI质量门禁左移的架构实践

AI 编码改变的不是单个开发者的写代码速度，而是整个交付系统里的流量分布。过去很多团队的瓶颈在“代码写不完”；现在瓶颈会快速迁移到 Review、测试、验收、复验和线上风险处置。

如果质量门禁仍然放在提交之后，团队会看到一个很典型的现象：代码变更多了，Review 队列更长了；功能分支更多了，测试环境更拥堵了；问题暴露更晚了，修复成本也更高了。质量门禁左移的本质，是把验证能力前置到开发活动内部，让每次 AI 参与生成的变更都能尽早进入可执行的验证闭环。

左移不是多测一点，而是改变验证能力的位置

• 从人工经验到显式契约：把入口、环境、动作、断言和证据要求写成 AI 可执行的结构。

• 从结论驱动到证据驱动：任何通过、失败、阻塞都必须能回看截图、日志、网络请求、结构树或度量数据。

• 从单点工具到系统能力：自动化执行、环境准备、报告治理、复验入口都要进入同一条链路。

AI 参与的是整条质量门禁链路的编排。它通过 Harness 管理上下文，通过 Agent 拆解任务，通过 Subagent 承担专项验证，通过 Skills 调用稳定工具，最后把证据交给门禁规则做可审计判定。

• Harness：质量门禁的运行框架，管理上下文、工具、状态、权限、日志和执行约束。

• Agent：质量任务负责人，负责理解变更、识别风险、规划验证路径和解释证据。

• Subagent：专项验证角色，例如 UI、Network、Telemetry、Visual、Report，各自只处理清晰边界内的问题。

• Skills：可复用工程能力封装，例如进入指定页面、采集截图和结构树、抓取请求、校验字段、生成复验报告。

agentic_quality_gate:
  harness:
    owns:
      - context_window
      - tool_registry
      - execution_state
      - audit_log
      - permission_boundary
  planner_agent:
    responsibilities:
      - understand_change
      - identify_risk
      - select_gate_level
      - dispatch_subagents
      - summarize_evidence
  subagents:
    ui_subagent:
      skills: [navigate_to_page, capture_screenshot, inspect_ui_tree]
    network_subagent:
      skills: [start_capture, filter_requests, assert_fields]
    telemetry_subagent:
      skills: [collect_events, compare_event_schema, count_occurrences]
    report_subagent:
      skills: [assemble_evidence, classify_failure, create_recheck_entry]
  rule:
    ai_orchestrates: true
    gate_decision_remains_rule_based: true

quality_gate_system:

  trigger:

    - ide_generated_change

    - pull_request

    - pre_merge_ci

  ai_harness:

    context:

      - requirement

      - code_diff

      - case_library

      - historical_defects

    guardrails:

      - single_case_transaction

      - evidence_required_before_pass

      - block_when_context_missing

  planner_agent:

    output:

      - risk_assessment

      - gate_level

      - subagent_plan

  subagents:

    - ui_subagent

    - network_subagent

    - telemetry_subagent

    - visual_subagent

    - report_subagent

  contract:

    input: requirement_or_diff

    output: executable_case_dsl

  runtime:

    capabilities:

      - skills.ui_operation

      - skills.api_replay

      - skills.network_capture

      - skills.mock_injection

      - skills.visual_compare

  evidence:

    required:

      - screenshots

      - ui_tree

      - network_trace

      - logs

      - assertion_result

  gate:

    decisions:

      pass: evidence_complete_and_assertions_met

      fail: assertion_failed_with_repro_steps

      block: environment_or_evidence_not_ready

04#
 核心抽象：
 把测试用例写成 AI 可执行契约
AI 不怕用例长，AI 怕用例模糊。面向人的测试说明可以依赖经验补全上下文，但面向 AI 的自测用例必须像接口协议一样明确：输入是什么、环境如何准备、入口如何定位、每一步如何执行、证据如何收集、什么情况下不能继续。
技术人员更容易复用的契约模板
契约并不是为了“把用例写复杂”，而是为了把 AI 原本需要猜的上下文变成明确输入。契约越清楚，AI 的执行越稳定，Review 的证据越可复查。
case:


  id: mobile_entry_bubble_hide_after_click


  goal: verify_entry_bubble_disappears_and_target_tab_selected


  risk_level: high


preconditions:


  account:


    login: required


    permissions: [content_access]


  device:


    platform: mobile


    orientation: portrait


  experiment:


    entry_bubble_enabled: true


  data:


    channel_has_reservation_bubble: true


entry:


  route: app_home_to_channel_page


  anchors:


    - channel_tab_visible


    - reservation_bubble_visible


  ready_when:


    - page_stable_for_ms: 1200


    - loading_indicator_absent: true


steps:


  - action: tap


    target: reservation_bubble


    observe:


      - target_tab_selected


      - bubble_not_visible


assertions:


  functional:


    - reservation_bubble.visible == false


    - selected_tab == target_tab


  telemetry:


    - event_name == entry_bubble_click


    - request_count == 1


  visual:


    - no_overlap_around_tab_area


evidence:


  required:


    - before_screenshot


    - after_screenshot


    - ui_tree_after_action


    - network_trace


    - final_report





05#
 执行状态机：
 让 AI 只能在证据闭环里给结论
很多 AI 测试实践失败，不是因为 AI 不够聪明，而是因为执行过程没有状态机约束。只要允许 AI 在证据不足时继续往下走，就会出现“看起来执行了，但结论不可信”的情况。
一个可靠的执行引擎应该把每条用例当成事务：准备失败就是 BLOCK，导航失败就是 BLOCK，断言失败才是 FAIL，证据缺失不能写 PASS。
06#
 技术广度：不是只测功能，
而是建设一条证据流水线
质量门禁左移要解决的不只是“功能是否能点通”。在真实研发里，很多线上问题来自埋点字段错误、UI 偏差、弱网异常、状态污染、兼容性、性能退化或灰度配置错误。架构上要预留足够的证据类型和断言扩展点。

证据模型要足够宽
功能证据：用户动作前后的截图、页面结构、状态持久化结果。
数据证据：接口请求、字段值、请求次数、链路耗时、错误码。
视觉证据：运行截图、设计源、控件边界、差异定位。
环境证据：账号、设备、版本、网络、实验、Mock、缓存状态。
治理证据：失败归因、阻塞原因、复验记录、趋势指标。

risk_model:

  dimensions:

    business_impact:

      high: payment, login, content_publish, critical_entry

      medium: recommendation, notification, profile

      low: copywriting, non_core_style

    change_complexity:

      high: cross_module_or_state_machine_change

      medium: single_module_logic_change

      low: static_resource_or_copy_change

    evidence_requirement:

      high: screenshot_plus_network_plus_logs_plus_replay

      medium: screenshot_plus_network

      low: smoke_result

gate_level:

  L1: low_risk_fast_gate

  L2: standard_gate_for_user_visible_change

  L3: strong_gate_for_core_path_or_ai_generated_large_diff

08#
 实际案例：
 移动端入口气泡的完整自测闭环
下面用一个抽象后的移动端案例说明如何落地。需求是：频道页存在一个“预约气泡”，用户点击气泡后，应进入目标 Tab，气泡消失，并触发一次正确上报。这个需求看似很小，但覆盖了入口定位、状态切换、UI 展示、埋点上报和证据复验。

这个案例能迁移到哪些场景
入口类需求：浮层、气泡、弹窗、运营位、Tab、快捷入口。
状态类需求：领取、预约、关注、收藏、订阅、购买、开关切换。
上报类需求：点击、曝光、停留、转化、异常路径采集。
视觉类需求：首屏布局、边界遮挡、动态字体、深色模式、多端适配。




09#
 落地路线：
 从工具试点到组织级质量资产
真正能复利的不是“跑通一次 AI 自测”，而是让每次执行都能沉淀资产。用例会变成契约库，证据会变成问题样本，阻塞原因会变成基础设施建设清单，报告会变成质量趋势。

建议优先观察的指标
提测前缺陷拦截数：验证质量是否真的前移。
AI 自测覆盖率：核心链路中可执行契约的覆盖比例。
BLOCK 原因分布：环境、数据、入口、证据、工具能力哪个最拖后腿。
报告有效率：有结论、有证据、有归因、有复验入口的报告比例。
复验耗时：修复后从触发复验到给出可信报告的平均时间。








10#
 写在最后：
AI工程化的核心竞争点会转向验证系统
AI 编码会继续提升代码生产效率，但工程组织之间的差距不会只体现在“谁生成代码更快”。更关键的问题是：当代码生成速度提升之后，团队是否拥有足够强的验证系统来承接这些变更。
质量门禁左移的价值，是把测试从后置的人力活动，升级为开发过程中的系统能力。它要求团队把经验契约化、把执行状态机化、把证据流水线化、把报告治理化。这样，AI 才不只是一个写代码的助手，而是进入了一套能支撑真实交付的工程闭环。

这张成绩单，数字一个比一个猛！

别让AI瞎猜了：用Harness Engineering 终结无限返工

内存峰值降60%+，动图加载快75%：爱奇艺图片库一次从'能用'到'极致'的跨越

零侵入、低成本！轻松为老系统注入 AI 灵魂

治愈 Cursor AI 编程的 “幻觉”？用它就够了！

跳转微信打开

爱奇艺通过自研 QBFS 大数据文件系统构建混合云存储架构，实现多云数据的无感路由、透明迁移与智能缓存，助力大数据降本超 30%

随着业务规模增长，爱奇艺大数据团队自 2023 年开始引入混合云以应对私有云资源的固有局限。相比受限的私有云物理机（机房限制、扩容慢、物理机买断等），公有云不仅能按需弹性伸缩，还能引入新型计算机型、冷存储等更具性价比的资源，并在出海等场景中实现更快速的服务交付。

弹性与成本优势的背后，混合云也带来新的挑战：需对异构资源统一抽象适配，让内部用户无感使用；要避免被单一云厂商绑定，保持架构与数据的可迁移性；还需精细化治理与成本管控，避免资源浪费和管理失控。

爱奇艺大数据在多AZ统一调度架构的基础上，进一步完成了混合云建设，升级为混合多云统一调度，实现了混合云的数据无缝访问和计算调度，大幅降低存储计算成本，提升数据开发与分析效率。

存储层，爱奇艺通过自研的QBFS (iQIYI Bigdata FileSystem) 大数据文件系统提供统一访问入口，屏蔽底层文件系统和集群，实现了云上云下、多家公有云间数据的无感路由、自由流转。

本文将介绍 QBFS 在混合云存储场景中的管理策略，以及实践过程中遇到的问题和解决方案。

QBFS是一个虚拟文件系统，其底层支持多种存储服务，提供跨集群/跨文件系统的统一命名空间、缓存加速、分层存储、透明迁移等功能。整体系统由以下模块构成

• QBFS 客户端 / 路由服务端：大数据应用通过 QBFS 客户端与底层存储服务交互，由服务端的路由和配置来动态决定访问的具体存储集群和客户端参数。元数据和代理访问非常轻量，能充分保持存储服务的功能和性能。

• 数据缓存层：基于 Alluxio 构建的缓存体系，能够透明的将持久层数据接入缓存。

• 持久层存储：包括 HDFS 及私有云 / 公有云对象存储，其集群分布在多个 Region-AZ 中，后文简称为 UFS。

• 数据调度服务：结合 QBFS 路由机制，可以实现冷热分层、透明迁移、备份等数据调度功能。

• 存储元仓：整合多种底层存储服务元数据，支持冷热分析、缓存分析、用量成本审计等数据治理功能。

图 1 QBFS 架构

在私有云多 AZ 阶段，QBFS 已经支持了 HDFS、私有云对象存储、Alluxio。进入混合云后，我们与公有云厂商深入合作，在 QBFS 中扩展接入了多种公有云对象存储。

在 QBFS 的统一命名空间中，可将库、表、分区等虚拟路径映射到公有云对象存储，上层应用只需访问 QBFS 路径，无需关心底层存储细节。QBFS 完成了客户端整合、认证鉴权、数据治理等适配，极大降低了业务使用各公有云存储的复杂度。

图 2 QBFS 统一命名空间

3.1 统一客户端访问

QBFS 客户端作为上层应用的统一访问入口，是适配公有云对象存储的核心组件。QBFS 客户端包中，整合了各底层存储服务的 SDK，上层应用调用 QBFS 客户端的 HCFS 接口时，客户端代理层会完成路由解析、接口兼容、缓存等一系列处理，最终调用 UFS 客户端，完成存储服务访问。

同时，QBFS 客户端会在 Oozie、Kyuubi 等入口以 provided 方式提供，平台侧可对客户端进行统一维护和升级。

图 3 QBFS 客户端

在 QBFS 客户端框架下，我们完成了多种公有云对象存储 SDK 整合，主要解决以下问题

• 客户端瘦身：通过严格控制 QBFS 客户端体量，降低 YARN、容器等环境下的分发与启动压力；统一管控第三方依赖，保持最小化引入，并采用各公有云厂商提供的精简化 SDK，进一步压缩包大小。

• 跨平台兼容：针对集群中多硬件架构（x86_64 / aarch64）和多操作系统环境，对服务 SDK、第三方库及 Native 组件进行统一适配；通过 Shaded 方式隔离依赖冲突，并实现 Native 包的自动匹配与按需加载。

• HCFS 兼容性：业界通过 HCFS 版对象存储、JuiceFS、S3A FS 等方案增强对象存储的 HCFS 支持能力。QBFS 在选型阶段优先选择 HCFS 支持成熟的产品，重点评估一致性、原子 rename 、高效 list 等特性。针对实际应用中仍会出现的不兼容问题，则通过 QBFS 客户端代理层进一步完善接口兼容处理。

• 终端节点服务：统一采用各公有云提供的类终端节点技术（PrivateLink），将对象存储桶域名解析为各公有云 VPC 网段内的 IP，私有云应用经专线直达该 IP 即可访问对象存储，对企业的现网架构零侵入。

3.2 混合云认证鉴权

为了兼容各类公有云对象存储的认证与权限机制，我们构建了混合云认证鉴权体系，让同一身份与权限在云之间无缝衔接，确保数据访问安全可控、策略一致。

在认证方面，QBFS 兼容了公有云对象存储的 AK/SK 认证机制，上层应用统一使用 Kerberos 认证，QBFS 自动完成认证信息的转换，动态从公有云 IAM 获取对应的临时 AK/SK，有以下两种场景

• 非 YARN 任务场景：由客户端进程本地完成 Kerberos 认证，并通过 CredentialProvider 插件及 SPNEGO 协议，安全地从密钥兑换服务获取公有云临时 AK/SK。

• YARN 任务场景：我们参考 S3A Delegation Tokens 框架，将临时 AK/SK 封装为 Token，在任务提交时交给集群分发到各个 Container 中。对于长时任务，会定期更新 Token。

图 4 混合云认证

在权限管理上，业务只需关心 QBFS 命名空间中库、表（视图）、路径的权限，系统会根据元信息，找到 UFS 中的路径，并在各 UFS 的权限引擎中完成授权。

同时，QBFS 路径挂载变更、视图更新时，系统也能完成各类复杂的权限更新处理。

图 5 混合云权限管理

3.3 混合云存储元数据

随着公有云对象存储的逐步引入，数据治理需求从传统 HDFS 扩展至对象存储领域。为了保持元数据格式与分析方法的一致性，我们实现了对象存储元数据的统一解析能力，主要包括以下方面

• 文件目录清单：对象存储的桶清单与 HDFS FSImage 类似，我们对不同对象存储清单进行清洗与语义对齐，结合挂载信息，构建统一的 QBFS 层元数据清单。

• 操作审计日志：整合 HDFS、对象存储、Alluxio 的审计日志，构建统一的 QBFS AuditLog，作为访问行为分析的基础。此外，通过 QBFS 客户端的埋点采集，增强了端到端读写流量、延时等信息。

• 元数据服务：基于各 UFS 元数据与路由表，提供了类似 Observer NameNode 的元数据实时查询能力，支撑目录统计、增长分析、接口加速等功能。

在此基础上，我们进一步开展了数据冷热分层、热点数据缓存、用量成本审计等一系列治理工作。

大数据场景中，数据通常都按时间分区组织，一个表最近 90 天的读请求按照“读时分区年龄”聚合：diffDate(读请求日期，所读分区的数据日期)，可得到表的访问热度特征。

我们发现，大部分数据都是如下图所示的访问模式，数据分区在生产当天访问最热，生产 2-3 天后读请求迅速下降，超过一定时间后访问趋近于 0，这也符合大数据中 T+1 计算场景的普遍规律。

图 6 表的访问热度特征

基于大数据的这种热度特征，QBFS 将数据划分为标准、低频、归档三层。新近且访问频繁的数据保存在标准存储；生命周期推进后访问频率低于阈值的数据转为低频；更久且几乎无访问的数据进入归档。

私有云中，我们用 EC 编码方式存储“低频数据”，用更高密度的硬件存储“归档数据”。随着公有云对象存储的接入，我们也引入了混合云低频存储与混合云归档存储。这两种模式能有效降低成本，并使受限的私有云资源演进为可灵活伸缩的混合云资源。

4.1 混合云低频存储

混合云低频存储的结构如图 7 所示，dt5-dt4 的标准数据分区放置在私有云 HDFS 中，dt3-dt1 的低频数据分区放置在公有云对象存储的标准存储中，上层应用通过 QBFS 路由访问，在 QBFS 命名空间中整合为表的完整数据。

图 7 混合云低频存储

4.1.1 一对多路由

为了使业务能正确的访问各部分数据，在 QBFS 路由层中，我们参考 HDFS RBF 的挂载设计，实现了一对多路由的处理策略，即一个挂载点映射到多个 UFS。该方式能适应数据分区的动态变化，简化路由配置。

我们在 QBFS 客户端模块中实现一对多路由的功能，客户端从服务端获取“路由配置”后，协调各存储服务 SDK 完成多个 UFS 的访问。该功能的核心策略主要包括“写入集群选择”和“多集群调用”。

写入集群选择，是指在一对多路由中选择 UFS 新建文件或目录。RBF 中实现了 HASH, HASH_ALL, LOCAL 等策略，在 QBFS 中我们扩展实现了 FIRST 策略，其规则如下

• 新增挂载点下 =1 级的文件或目录时，默认放置在第一个 UFS 中

• 新增挂载点下 >1 级的文件或目录时，找到最近父目录所在 UFS 进行创建

• 混合云分层存储中，时间分区目录只会存在于一个 UFS 中，新增时间分区目录会创建在私有云 HDFS 中

图 8 写入集群选择策略

多集群调用，是将 QBFS 层的文件访问操作转换为多个 UFS 的方法调用，并整合返回结果。参考 RBF 的架构，我们在 QBFS 客户端中实现了多集群调用策略。

• invokeSingle：仅对其中一个挂载路径进行调用

• invokeSequential：对各挂载路径依次进行调用，直到某一次调用成功返回

• invokeConcurrent：对各挂载路径同时进行调用，最后合并结果

各文件访问操作分别采用相应的多集群调用策略，可以保证正确的文件访问语义。

图 9 多集群调用策略

4.1.2 低频数据转存

在一对多路由的基础上，平台以“时间分区”为调度单元，将数据透明地从标准存储转存到低频存储。

转存流程如图 10 所示：将源分区复制到目标 UFS 临时目录，禁止 QBFS 层该分区写入并校验两端数据一致，将目标分区移动到正式路径、源分区移动到临时目录，再次校验后放开写入，最后清理源端数据。整个过程充分考虑了幂等重试、并发访问、数据一致、流量控制等设计。

在线上，数据调度系统会根据 TTL 规则生成转存任务，完成排序、流控、容错等调度处理，平台每天可以稳定执行约 10 万个分区转存任务。

图 10 分区转存流程

4.1.3 其他问题

在实现“混合云低频存储”的过程中，我们也解决了许多其他问题，列举部分问题供参考

• Hive 重写分区：用户重写 Hive 的低频分区时，可能会出现跨 UFS rename 的情况，我们完善了 Hive commit 中 Hive.needToCopy() 判断， 确保能将 rename 转换为 copy 操作。

• 表全量更新：表全量更新时，可能会对表级挂载点执行删除操作，但 QBFS 不支持对挂载点删除。我们对 Spark任务都配置了 convertInsertingUnpartitionedTable=false，该模式下不会对表级路径执行删除。

• 时间分区非一级：表或 Fileset 的“时间分区”列可能是非一级路径，这种情况我们扩展了一对多路由的策略，引入了“时间分区”层级信息，> 层级仍采用 FIRST 写入策略，<= 层级采用类 HASH_ALL 策略。

4.2 混合云归档存储

基于公有云对象存储中的“归档存储类型”，我们扩展实现了混合云归档存储，进一步降低存储成本。业务需主动设置“归档 TTL”，超过 TTL 的“数据分区”会被转存到公有云归档存储中，并从表中移除。

归档管理策略

归档以数据分区为单位管理，先将分区拷贝到目标桶的临时目录，校验完整后再移动到归档路径，归档路径数据基于桶规则 1 天后归档。需要考虑以下策略

• 云内数据归档：如果“数据分区”已经是公有云对象存储中的数据，则可以跳过 distcp，直接移动到归档路径。

• 最低存储时间：对于不满足公有云最低存储时长的数据，系统会根据成本分析自动降级为“私有云归档”。

• 数据湖表归档：对于 Iceberg 等强依赖元数据文件的数据湖表，当前采用 Spark 导出为 Hive 数据分区归档。

归档恢复流程

公有云对象存储中，已归档的“数据分区”会先解冻为可访问状态，支持两种恢复方式

• 原地恢复：通过 QBFS 路由恢复为原来的路径，并在原表中恢复分区，适合快速适配处理。

• 独立恢复：通过 QBFS 路由恢复为不同的路径，恢复为一个独立的表，适合隔离定制处理。

混合云环境中，数据迁移是常态：从 A 云迁移到 B 云，从单 AZ 桶迁移到多 AZ 桶，机房搬迁、升级到新集群等。QBFS 的目标是让迁移发生在底层，业务仍使用原有路径，应用程序无需修改，同时运行中的程序受影响小。

5.1 表级迁移

表级透明迁移可分为两种类型：时间分区数据的迁移、非时间分区数据的迁移。

时间分区数据，可按“时间分区”为单位，逐步完成整表的迁移。

1. 迁移前置准备：配置一对多路由、复制权限、暂停表的其他任务（分层、备份等）；一对多路由采用 FIRST 写入策略，目标 UFS 在前，源端 UFS 在后，新的时间分区会创建在目标 UFS 上。

2. 时间分区迁移：逐个迁移表的时间分区，每个“时间分区”会生成对应的迁移子任务，流程与“低频转存”类似。

• 生产中分区：最新时间分区下可能还在生产数据，可以将最近的时间分区延后几天迁移

• 混合云低频：路由层面可配置一对 N 路由，能够满足标准、低频两部分数据的迁移需求

3. 表迁移：完成所有的分区迁移后，迁移表级的其他子目录，例如 Iceberg metadata、Paimon manifest 等目录。该阶段会短暂禁止整表写入。

4. 迁移后置处理：1）改为一对一路由，去除源端依赖；2）清理源端权限；3）开启表的其他任务。

图 11 Iceberg 时间分区表的透明迁移

非时间分区数据，通常较小且写入频率低，例如 T+1 全量更新的表、较少更新的维度表等。因此，可以避开数据生产时间，采用传统的停写迁移方式，整体流程大致相同。

5.2 整库迁移

在更大规模的整库迁移中，平台会把库或业务目录拆分为表和子目录，再按时间分区与非时间分区分别处理。库下表都完成迁移后，再做库级路由切换并清理多余表级路由。借助调度平台，管理员可以管理成百上千个表和目录的迁移过程。

大数据混合云场景中，专线带宽往往会成为瓶颈，在爱奇艺当前的混合云资源结构下，主要有以下情况

• 私有云任务大量读取混合云低频 / 归档数据

• 公有云计算节点大量读取私有云数据

为此，我们在 QBFS缓存体系基础上扩展混合云缓存能力，构建跨多云的 Alluxio 公共缓存层，主要有以下扩展

• 混部资源：公有云计算节点的异构机器上部署 Alluxio Worker，构成公有云 AZ 中的缓存资源池。

• 就近访问：基于自研的节点选择策略，QBFS 能识别客户端所在云 AZ 信息，优先选择本地云 Worker 读写缓存。

• 对象存储：Alluxio 通过 QBFS 插件能非常方便的适配对象存储，并兼容 QBFS 复杂的路由处理。

图 12 混合云缓存

6.1 低频与归档数据缓存

对于私有云任务读取云上低频或归档数据的场景，QBFS 会将云上数据缓存到 Alluxio 私有云的 Worker 中。

• 低频定期访问：低频数据的平均访问频率低，但一些低频数据存在月度、季度等周期性访问，我们会对这些数据配置缓存规则，QBFS 会提前加载数据到私有云缓存中。

• 低频变热：如果监控发现低频数据重新变热，可以临时配置缓存，长期需求则通过 TTL 调整逐步迁回私有云。

• 归档恢复：归档数据解冻恢复后，QBFS 会主动加载数据到私有云缓存中。

6.2 任务调度与缓存

对于公有云计算节点读取私有云数据的场景，我们实验发现，如果任务随机调度到云上，云上热数据分布也不稳定，难以针对性缓存；需要任务调度与数据缓存紧密配合，才能有效降低流量。

1. 调度合适的任务组：将任务按用户、队列等维度分组，剔除部分高流量任务，统计每个分组的单位核输入流量；在核数使用量 TopN 的任务组中，优先将单位核流量较低的任务组调度到云端。

2. 缓存任务组的数据：针对调度到云上的任务组，其访问数据相对固定，可以分析该组任务的热点数据，并将相关数据缓存到公有云的 Alluxio Worker 中。其中，任务组生产的数据，可以 write-through 写云上 Worker 时缓存；依赖的第三方数据则通过缓存规则提前加载。

基于 eBPF 监控与客户端采集，我们能精确分析任务的流量情况，某用户的任务组采用调度与缓存方案后，跨专线的高峰时段流量降低 70%。

大数据混合云存储架构已在爱奇艺全面落地，构成多云统一调度框架的基石，帮助大数据降本 30% 以上。基于当前架构，我们可以快速接入新的公有云对象存储，并实施精细的服务治理。同时，通过混合云分层、透明迁移、缓存，我们可以动态调整云上云下存储分配比例，实现多云、多 AZ 的融合与弹性。

未来我们会进一步扩大混合云存储的应用比例，逐步替换私有云内过保的机器，达成更高的降本收益。同时，我们也会优化混合云数据放置与缓存策略，实现存算协同上云，使混合多云统一调度框架具备更强的扩展性。

此外，基于公有云对象存储和相关生态的丰富功能，我们也会扩展 QBFS 在多模态数据、AI 数据链路、数据高可用等方面的应用。

这张成绩单，数字一个比一个猛！

别让AI瞎猜了：用Harness Engineering 终结无限返工

内存峰值降60%+，动图加载快75%：爱奇艺图片库一次从'能用'到'极致'的跨越

零侵入、低成本！轻松为老系统注入 AI 灵魂

治愈 Cursor AI 编程的 “幻觉”？用它就够了！

跳转微信打开

爱奇艺2025年专利成绩单

跳转微信打开

以Harness工程化AI协作，提升研发交付质量。

这两年，越来越多的研发团队已经把AI编程工具带进了日常工作。有人用它补代码，有人让它写测试，有人拿它查文档、搭脚手架、整理方案，也有人开始让agent直接进入仓库，完成一轮搜索、修改、验证和回写。

表面上看，问题似乎已经从“要不要用AI”变成了“用哪个工具”。但真正落到交付时，大家很快会碰到另一层更现实的问题：AI的局部产出可以很快，真正进入研发流程却没那么容易。

很多返工并不是因为模型完全不会写代码，而是因为任务在交给agent之前，依据没有准备完整。页面结构还在变，状态没有补齐，接口边界没有说清，验证口径不统一，结果记录也没有固定落点。这样一来，agent只能靠上下文里零散的信息去猜。第一次也许能猜中，第二次、第三次就开始偏。代码看起来越来越多，协作成本也跟着上来了。

所以这篇文章想讨论的，不是怎样把提示词写得更复杂，也不是单纯推荐某一组工具，而是一个更接近研发现场的问题：

本文问题：怎样把AI放进一个更稳定、更可协作、更可验证、也更容易留下经验的研发流程里。

我把这套做法概括为Harness Engineering。

概念定义：harness在这里指一套让agent能稳定参与研发的工程安排：有任务入口、有执行依据、有工具边界、有验证反馈、有结果记录。

很多时候，团队对agent的期待其实很直接：

• 最好能多做一点

• 少问一点

• 出错少一点

但这三个期待背后对应的并不是单纯的模型能力，而是工程条件：

• 多做一点：上下文和工具是否完整。

• 少问一点：边界、非目标和验收方式是否清楚。

• 出错少一点：验证和回写是否形成稳定链路。

核心结论：agent要可靠参与研发，不能只靠模型回答。项目需要给它准备任务入口、执行依据、工具边界、验证反馈和结果记录。

理论篇：从Prompt到Harness

1.1 局部生成不等于稳定交付

如果只看局部，今天的AI编程工具已经足够能干。它会补函数、会改样式、会写测试，甚至会顺着仓库上下文做一轮看起来像样的实现。但研发真正关心的从来不是“能不能生成一段代码”，而是这段代码能不能进入现有流程、能不能被别人接住、能不能在后续迭代里继续维护。

前端场景里，这个问题通常表现得更早。知道“想做一个什么页面”，不代表页面结构已经稳定，也不代表视觉边界、状态覆盖和实现方式已经对齐。如果只有一段自然语言描述，agent往往会同时猜三件事：

• 页面长什么样

• 有哪些状态

• 代码应该怎么拆

首版做出来并不难。难的是后面继续改的时候，设计稿、状态演示和真实页面慢慢开始分叉。

后端的问题看上去不一样，本质却相似。很多任务一开始只有一句话，比如“做一个同步工具”“补一条处理链路”“把这个流程接起来”。这类描述说清了目标，却没有说清边界：

• 运行模式是什么

• 输入输出是什么

• 失败怎么处理

• 验证怎么做

• 结果应该记在哪里

agent当然也能先写一个版本，但这种“先跑起来再说”的方式，很难直接进入可交付状态。

提示词在这里能解决一部分问题。我们可以把背景写得更长，把要求列得更细，把“不要做什么”补充进去。但prompt通常是一次性的，它很难承担持续验证，也无法自动阻止坏模式扩散。

更常见的情况是，团队开始不断加长prompt：

• 补背景

• 补规则

• 补口径

• 补历史失败经验

短期看这有帮助，长期看会出现两个问题：

所以问题并不只在AI，而在协作链路里缺少统一入口、稳定依据、执行边界和反馈链路。

这就是Harness Engineering要解决的问题。

2.1 第一性原理：从写代码转向跑完整链路

Harness Engineering背后的第一性原理，可以先从研发现场看：

第一性原理：当模型越来越会写代码后，瓶颈不再只是“谁来写”，而是任务有没有说清、边界有没有定住、验证能不能跑、结果有没有人接。

代码生成会越来越便宜，但下面这些事仍然消耗人的注意力：

• 需求澄清

• 优先级判断

• 验收定义

• 架构取舍

• 质量判断

agent-first的研发方式不是让人退出，而是让人把注意力放在更值得判断的地方。

人的注意力应该放在判断上，而不是反复补同一类上下文：

• 目标怎么定：不要反复解释项目背景。

• 边界怎么收：不要每次口头补规则。

• 反馈怎么跑：不要每次手动提醒跑测试。

• 风险怎么判断：不要反复修同类review问题。

• 经验怎么写回项目：不要把结论只留在一次对话里。

agent能不能稳定工作，也不只取决于模型本身。它能看到什么文档，能调用哪些工具，能不能运行测试，能不能读取反馈，能不能知道什么算完成，这些都会影响它能接手到什么程度。

agent能看到什么、能调用什么，决定了它实际能完成什么。

来源：OpenAI Harness Engineering。

对agent来说，可以简单理解成三句话：

• 无法访问的知识，基本等于不存在。

• 无法执行的工具，基本等于没有。

• 无法验证的目标，很难持续修正。

工程信息越容易被agent找到、执行和检查，它能做的事就越接近一个真实工程师能接手的任务。

OpenAI的Harness Engineering实践，最值得借鉴的也在这里。它强调的不是“模型能生成多少代码”，而是当agent开始参与更多软件开发环节时，团队需要把过去靠人记、靠人判断的东西放进系统里。

继续加长prompt只能解决一轮对话的问题。Harness Engineering更关心的是，项目本身能不能提供稳定的入口、边界、验证和反馈。

2.2 最小可用harness的组成

落到项目里，可以先抓三件事：

1.隐性知识要变成可发现的上下文如果一个约束只存在于某个人的经验里，agent基本无法稳定遵守。项目入口、目录说明、架构边界、接口约定、命名规则、验证方式，都应该尽量进入仓库或任务系统。

2.反馈要变成可执行的入口“注意质量”“跑一下测试”这类提醒不够稳定。更好的做法，是把验证命令、runbook、Storybook、contract diff、lint、review gate等变成明确入口。

3.规则要逐步从提醒升级成检查不是所有规则都能一开始机械化，但重复出现的review问题不应该永远靠人提醒。可以先登记在项目约束里，再逐步变成linter、脚本、测试或CI gate。

一套最小可用的harness，至少要组织起五类东西：

一次生成不能构成工程能力，可持续的能力来自一条能跑完的链路：

agent写完代码后进入运行环境，用DevTools等反馈继续修正。

来源：OpenAI Harness Engineering。

也可以把两者的分工再压缩成一张表：

如果把这个原则落到一个普通项目里，起点不是先做一个复杂平台，而是先让仓库具备一套最小可用的harness：有入口地图，有计划协议，有验证入口，有项目约束登记，也有结果回写的位置。

方法篇：把协作链路放进项目

3.1 先固定信息落点

很多团队在使用AI时，会把大量信息放在对话里：

• 项目背景

• 任务范围

• 实现偏好

• 验证方式

• 注意事项

• 上次失败原因

这样做启动很快，但难以复用。下一次换一个agent、换一个同事、换一个任务，这些信息又要重新拼起来。

Harness Engineering的一个核心动作，就是把这些临时上下文移到更稳定的位置。

在一个项目里，可以先把信息落点分清楚。

关键不是把某个系统称为“唯一来源”，而是让每类信息都有清楚的位置。

3.2 从任务入口到评审收口

• 任务状态不要散在聊天里。

• 执行依据不要只停留在口头说明里。

• 验证结果不要只存在本机终端里。

• 评审结论不要只停留在临时对话里。

一项复杂任务在harness里的流转，可以简化成下面这条链：

这样拆开以后，agent不需要凭空理解整个组织流程。它只需要在每个位置完成明确动作：

1.从任务入口拿目标。

2.从计划里拿边界。

3.从仓库里找实现依据。

4.从验证入口读取反馈。

5.把结果写回团队能看到的位置。

基于这个目标，我目前使用的harness模板，把项目里的基础内容分成几类：

这样做的目标，不是让项目目录显得更复杂，而是让agent每次进入项目时，都能沿着同一套路径找到依据、边界、验证和结果记录。

4.1 初始化前先让agent解读模板

https://github.com/SisyphusSQ/harness-template

为了把上面的想法落到普通项目里，模板初始化后的目录可以保持相对克制。它不是要替换原项目的工程结构，而是在原项目旁边补一层协作和验证入口。

如果你拿到的是随文附带的harness模板压缩包，不建议第一步就复制文件。更合适的方式，是把压缩包和目标项目一起交给agent，让它先读模板、再读项目，最后给出初始化方案。

推荐流程：

1. 把harness模板压缩包和目标项目路径一起交给agent。

2. 先要求agent只解读，不修改目标项目。

3. 让agent输出初始化方案：会新增什么、会修改什么、会保留什么、有哪些风险。

4. 根据目标项目的技术栈、任务系统、验证命令和团队约定，选择需要初始化的层级。

5. 确认方案后再执行初始化，并在完成后运行项目验证命令和harness检查。

模板包提供的是一套可复用的项目结构，不是一组必须原样照搬的文件。落到项目里时，agent应该先理解模板，再理解目标项目，最后再把两者对齐。

模板目录把入口、计划、约束、验证和脚本放到项目内，方便后续任务复用。

一个典型初始化结果大致如下：

这个目录不是为了在项目旁边再建一套“文档工程”。这些文件的作用，是让项目本身更容易被agent使用，也更容易被团队协作维护。

AGENTS.md是入口地图，负责导航和边界说明。.agent/PLANS.md和.agent/plans/TEMPLATE.md是复杂任务的计划协议。模板要求计划写真实实现，而不是只写“开发、测试、回写”。

后端任务尤其要写清：

• 真实入口

• 输入从哪里来

• 核心对象是什么

• 哪些模块负责什么

• 失败时如何停止和恢复

• 如何验证和回写

如果团队同时使用Superpowers这类技能化工作流，可以把它看成harness的执行层补充。

harness与Superpowers的分工：

• harness：负责项目入口、计划协议、验证入口、项目约束和结果回写。

• Superpowers：负责写计划、测试驱动、系统化调试、代码评审和完成前验证。

两者不应该变成两套互相竞争的规则，而应该按同一条链路配合。

4.2 初始化后的使用方式

1.先从AGENTS.md、docs/harness/ 和plan里读取项目依据。

2.再按技能化工作流完成实现与验证。

3.最后把结果写回任务系统、PR/MR 或仓库文档。

初始化之后，推荐的使用方式也可以很简单：

1.先读AGENTS.md，找到项目入口和验证命令。

2.复杂任务不要直接开改，先按 .agent/PLANS.md 写计划，冻结本轮范围、非目标和验收方式。

3.在计划里写清真实实现链路，不用harness流程图替代业务实现图。

4.执行时按计划推进，遇到范围变化先更新计划，而不是顺手扩大任务。

5.收口前执行项目验证命令、harness检查和review gate，把结果同步回任务系统、PR/MR或仓库文档。

结果是，agent的工作不再只是一次对话里的产出，而是进入了项目自己的记录、检查和验证体系。

实践篇：前端、后端与工具分层

5.1 前端三层：设计、状态、实现

前端最容易把Harness Engineering的价值看清楚，因为页面交付天然就分层。至少有三层需要分别接住：

• 执行依据层

• 状态暴露层

• 交付实现层

前端协作效率，很多时候就取决于这三层有没有先后站稳。

前端从设计结构，到状态暴露，再到真实页面接入的三段式路径。

如果没有执行依据层，agent和工程师虽然都能开始写，但实现会持续漂移。大家面对的不是同一组约束，而只是同一句需求描述。

Storybook的价值不在于替代设计稿，而在于把运行状态显式摆出来，让评审和回归围绕现成页面行为展开。状态如果只留在设计稿或个人脑海里，后续讨论就会越来越依赖记忆，返工也会越来越随机。

当前两层已经提供稳定依据时，agent的位置才会变得清楚：它不是凭一句描述直接“生成页面”，而是在既定结构和既定状态之上补实现、补细节、补接线。

从harness的视角看，三类信息各有落点：

复杂页面任务在进入实现前，计划文件至少应该回答这些问题：

• 本轮页面范围是什么，是否包含弹窗、抽屉、批量操作、详情页或二级页面？

• 需要覆盖哪些状态，哪些状态只做占位，哪些状态本轮不做？

• 组件层级是否已经从设计结构里固定，还是允许在实现中调整？

• Storybook里要暴露哪些story，评审时看哪些入口？

• 真实页面接入哪些路由、权限、接口和埋点？

• 如果接口还没准备好，mock数据、字段假设和后续替换位置在哪里？

前端场景的关键点：设计不要只冻结“长相”，还要冻结状态。状态不要只存在于设计稿里，还要进入可运行环境。agent不应该凭一句描述生成页面，而应该在结构和状态都明确后补实现。

这也是为什么前端场景里最直接的变化通常不是“生成速度更快”，而是返工更少。结构先冻结，状态先暴露，agent、工程师和评审围绕的是同一组对象，而不是各自理解的预期。

6.1 后端三层：依据、验证、实现

后端表面上没有Pencil和Storybook，但协作链路并没有因此变短，只是把对应的位置换成了另一组工件。让事情稳定下来的，往往是先把执行依据、验证口径和失败边界说清楚。

后端也可以对应拆成三层：

很多任务之所以反复，并不是因为代码太难，而是因为执行语义没有冻结。运行模式、输入输出、异常口径、非目标范围、回滚方式没有提前写清，agent的产出就很容易停在“看起来可以跑”，却还进不了交付。

后端任务中，docs、plan、terminal、logs、repo和review共同组成验证反馈循环。

更稳的做法，是先在任务系统里明确范围和责任，在仓库文档里补齐接口与设计说明，在计划工件里写清。

更稳的做法，是先在任务系统里明确范围和责任，在仓库文档里补齐接口与设计说明，在计划工件里写清Scope、Non-Goals、Validation、Rollback，然后再让agent进入实现与测试。

例如，一个同步工具类任务，如果只写“实现同步功能”，agent只能猜运行入口、配置来源、错误处理、重试方式和验证命令。更好的计划应该回答几个问题：

• 入口命令是什么，谁会触发它？

• 输入来自配置、参数、文件、API 还是消息？

• 核心对象在哪里装配，哪些字段必须校验？

• service、repository、gateway或adapter各自负责什么？

• 失败时是重试、跳过、停止还是回滚？

• 成功与失败分别用什么命令或runbook验证？

• 结果要写回哪里？

后端任务尤其需要把“完成”的判断拆开。因为很多后端能力不是页面上马上能看到的，它可能是一条命令、一个定时任务、一个消费链路、一个API、一个数据同步过程，或者一组配置驱动的行为。

后端场景的关键点：先写清入口、输入、边界和失败策略。验证不要只写单测，要覆盖链路和失败场景。结果要能被后来的人复用。

所以对后端来说，关键不在于把实现动作再往前提，而在于把验证动作更早放进任务设计里。很多链路型任务真正决定能不能进入交付的，并不是“有没有代码”，而是“有没有一组团队共同认可的验证条件”。

7.1 工具可替换，职责位置要稳定

前面两节分别用了前端和后端场景说明同一件事：工具名可以不同，但协作链里的位置其实高度相似。我们真正需要稳定下来的，不是某个固定产品组合，而是研发协作中的职责分层。

工具可以替换，但职责分层、架构边界和跨层约束不能缺位。来源：OpenAI Harness Engineering。

可以把常见工具放回同一条链路里看。

把Pencil、Storybook、Linear、Codex、Cursor、Claude Code放在同一段里讨论，很容易把问题带偏成工具选型。但从工程视角看，这里真正重要的不是产品，而是每一层承担什么职责。

Harness Engineering要做的，就是把这些职责拆开、接稳，并让agent在自己应该工作的层面上发挥作用。工具完全可以替换，但任务编排、依据冻结、状态暴露、执行入口、验证反馈、评审收口这些位置不能长期缺位。

这也是为什么同一套方法可以同时适配Cursor、Codex、Claude Code或其他 agent工具：

• 工具负责执行能力。

• harness负责工程条件。

• 任务入口、计划协议、验证入口和回写位置稳定后，工具替换带来的迁移成本会小很多。

• 如果所有规则都绑在某个工具的私有prompt里，工具一换，团队就要重新整理协作方式。

落地篇：从轻量harness到适用边界

8.1 从最小harness开始

很多团队看到这里，第一反应可能是：这套东西是不是太完整了，落地成本会不会很高。

实际上，如果只是想从“个人会用agent”走到“团队能稳定协作”，起步不一定复杂。先把最容易反复出问题的几个位置固定下来就够了。

轻量harness模板先解决的就是这些基础问题。团队不需要一开始就建设完整平台，可以先把任务入口、计划协议、项目约束、验证入口和结果记录固定下来。只要这些位置稳定，agent协作就会比只靠临时prompt更可控。

后续再逐步补：

• 项目级linter

• contract diff

• E2E（End-to-End，端到端验证：从任务入口、计划协议、执行过程、验证入口到结果记录的完整链路检查，确认协作流程整体可跑通。）

• 外部系统readback

• 维护扫描

• 规则升级

顺序可以慢慢来，但方向应该清楚：把反复依赖人的判断，逐步写回到项目规则和检查入口里。

一个更稳妥的落地顺序可以分成三个阶段：

阶段 1：让agent找得到入口

先补AGENTS.md、验证命令和复杂任务计划模板，让agent进入项目后能快速找到任务入口、项目边界和验证方式。

阶段 2：让任务能被复盘和复用

固定plan、runbook、验证摘要和PR/MR回写格式，让一次任务结束后的结论能被后来的人继续使用。

阶段 3：让重复问题逐步机械化

登记项目约束，把高频review问题升级成lint、script、test或CI，减少同类问题反复依赖人工提醒。

这三个阶段不要求一次完成。更实际的做法，是先选一两个真实项目试运行：

• 前端可以从一个复杂页面或组件库开始。

• 后端可以从一个链路型工具或集成任务开始。

• 每次任务结束后，都补一次计划、验证和回写。

harness会逐步从模板变成项目自己的工作方式。

9.1 判断边界：轻量还是完整

Harness Engineering不是要求所有事情都走一遍完整流程。

适合轻量处理：任务影响面小、验证方式直接明确，不需要完整harness流程。

• 一次性实验、纯脑暴、小范围草稿。

• 非核心逻辑的小修小补。

• 只影响单个小文件，且验证方式直接明确。

适合启用harness：任务会影响交付、协作或后续复用，需要提前固定依据、边界和验证。

• 有明确交付目标的页面或组件开发。

• 有接口、数据结构、测试或验证要求的后端任务。

• 涉及多个模块、多个状态、接口契约、数据迁移、权限边界或外部系统。

• 需要多人协作和评审，或希望把经验写回仓库和任务系统。

仍然需要人判断：让信息进入系统，不意味着人可以退出判断。

• 需求澄清、架构取舍、业务优先级。

• 风险判断、权限边界、安全策略。

• 同类问题是否进入项目约束登记，验证结果是否写入runbook或PR/MR。

• 后续需要交接、复盘或继续迭代时，关键决策应同步回任务系统或仓库文档。

这个边界很重要。Harness Engineering的目标不是把所有研发动作流程化，而是把高风险、高协作成本、高复用价值的部分系统化。越是短平快的事情，越应该保留轻量路径；越是会影响后续交付的事情，越应该提前准备依据、边界和验证。

附：辅助初始化Prompt

下面这段可以直接复制给agent，平时不需要逐字阅读。

你是我的研发协作 agent。我会提供一个 harness 模板压缩包，以及一个目标项目路径。
请按两个阶段工作。
阶段 1：只解读，不修改文件。
1. 解压或读取 harness 模板包，说明模板包中的核心目录和文件职责。
2. 读取目标项目的现有结构，包括 README、AGENTS.md、Makefile、package.json、go.mod、pyproject.toml、docs、scripts、CI 配置等实际存在的入口。
3. 判断目标项目适合初始化哪些 harness 内容：入口地图、控制面文档、计划协议、测试 runbook、项目约束登记、agent prompts/guides、脚本检查入口等。
4. 输出初始化方案，必须包含：
   - 准备新增的文件
   - 准备修改的文件
   - 明确不覆盖或需要保留的文件
   - 需要从目标项目实际情况推导的内容
   - 初始化后的验证命令
   - 可能的副作用和回滚方式
5. 在我确认之前，不要修改目标项目。
阶段 2：确认后再执行初始化。
1. 按确认后的方案初始化 harness 文件。
2. 保留目标项目已有的工程结构、构建方式、测试命令和团队约定，不要把模板内容机械覆盖到项目上。
3. 如果发现模板假设和项目实际情况冲突，先停下来说明冲突，不要自行扩大修改范围。
4. 初始化完成后，运行可用的验证命令，并给出结果摘要。
5. 最后输出一份初始化报告，包括已创建/修改文件、验证结果、尚未机械化的项目约束、后续建议。

最后：prompt解决的是这一轮怎么说清楚，harness解决的是项目里如何持续做对。agent的可靠性不只来自模型能力，也来自任务入口、执行依据、验证反馈和结果记录是否提前准备好。

结语：让AI进入可验证的研发协作

我们讨论AI编程，最容易被放大的往往是模型能力：会不会写、写得快不快、答案漂不漂亮。但回到研发现场，很多问题最后还是落在几件具体的事上：

• 任务依据是否完整

• 边界条件是否清楚

• 验证方式是否提前准备好

• 结果有没有被记录下来

回到研发现场看，Harness Engineering做的其实是几件具体的事：

• 任务别只留在聊天里。

• 边界别只靠人记。

• 验证别只停在本机。

• 结果别只存在这一轮对话里。

它一方面把任务入口、执行依据和验证反馈接稳，另一方面把协作链里的职责分清。做好这些之后，agent才不会只是一个偶尔帮忙的生成工具，而会慢慢变成研发链路中一个更可靠的执行者。

AI可以加快生成，但稳定交付仍然依赖清晰的依据、边界、验证和记录。

当这些工程条件提前准备好，agent带来的就不只是速度，而是更少的返工、更清楚的协作界面，以及能留在项目里的经验。

从Prompt Engineering走向Harness Engineering，重点也就在这里：不只追求这一轮让模型回答得更好，而是让项目本身具备一套能支持agent反复接手、验证和回写的工作方式。

内存峰值降60%+，动图加载快75%：爱奇艺图片库一次从'能用'到'极致'的跨越

零侵入、低成本！轻松为老系统注入 AI 灵魂

治愈 Cursor AI 编程的 “幻觉”？用它就够了！

速看如何跑赢碎片化时代的流量竞速

在爱奇艺做研发，用AI写代码是什么体验？

跳转微信打开

基于华为最新仓颉编程语言，实现鸿蒙生态图片高效加载的完整实践解析

随着HarmonyOS NEXT的正式发布，越来越多的应用开始拥抱鸿蒙原生开发。作为国内领先的视频平台，爱奇艺也在积极布局鸿蒙生态，致力于为用户带来更流畅、更优质的观影体验。

在移动应用场景中，图片加载是影响用户体验的关键环节。海报、焦点图、活动图、角标……这些看似普通的图片资源，却承载着用户的第一印象。如何在鸿蒙平台上实现极致的图片加载体验，成为爱奇艺技术团队面临的重要课题。

本文将分享爱奇艺在鸿蒙原生应用开发中的技术实践——基于仓颉语言自研高性能图片库的全过程，包括技术选型思考、架构设计、性能优化以及实践成果。

2.1 ArkTS的性能瓶颈：

在鸿蒙应用开发中，ArkTS是官方推荐的主要开发语言。然而在实际开发过程中，我们发现ArkTS在处理图片密集型任务时存在一些性能瓶颈：

单线程语言模型的局限：ArkTS基于单线程事件循环模型，当遇到复杂的图片解码、处理任务时，容易造成主线程阻塞，引发UI卡顿。特别是在列表滑动、快速翻页等场景下，用户体验受到影响。

多线程使用成本高：虽然ArkTS支持Worker和TaskPool实现多线程，但开发者需要手动处理内存隔离、线程间通信、参数序列化等问题。Worker数量和TaskPool执行时间受限，需要根据任务类型进行权衡，开发和维护成本较高。

2.2 AVIF格式的迫切需求：

爱奇艺作为视频平台，对带宽和存储成本高度敏感。为了在保证画质的同时降低传输成本，爱奇艺线上图片资源已广泛采用AVIF格式。

AVIF是由开放媒体联盟推出的新一代图片格式，相比传统格式具有显著优势：

• 更高压缩效率：在相同视觉质量下，AVIF 相比 JPEG 通常可减少约 40–50% 的文件体积，相比 WebP 也可进一步降低约 20–30%，显著节省带宽与存储空间。

• 更丰富的图像质量能力：支持 10-bit / 12-bit 色深、4:4:4 色度采样及更好的渐变过渡，减少色带和压缩伪影，在复杂纹理和渐变场景下表现更稳定。

• HDR 与现代特性支持：原生支持 HDR、广色域（如 BT.2020）、透明通道（Alpha）以及动画帧，适合高质量图片与新一代显示设备。

然而，当前鸿蒙系统自带的Image组件尚未支持AVIF格式，这成为爱奇艺鸿蒙原生应用开发的一大痛点。如何在鸿蒙端实现高效稳定的AVIF加载，成为亟待解决的核心诉求。

2.3 图片库密集型任务的特性：

图片库是典型的计算密集型+IO密集型应用，主要包含三类任务：

这些任务对语言的并发能力、内存管理、性能表现都提出了较高要求。

面对上述挑战，爱奇艺技术团队进行了深入的技术调研，最终选择了仓颉（Cangjie）语言作为图片库的核心开发语言。

3.1 仓颉语言简介：

仓颉是华为自研的面向全场景智能的新一代编程语言，专为鸿蒙生态打造。它融合了多种现代编程语言的优点，具备以下核心特性：

静态强类型与内存安全

仓颉采用静态类型系统，在编译期即可发现大部分类型错误，减少运行时异常。同时，仓颉内置内存安全机制，通过所有权和生命周期管理，有效避免内存泄漏、野指针等问题，让开发者更专注于业务逻辑。

高效并发模型

仓颉提供了用户态线程模型，轻量级执行实体拥有独立上下文，却能共享内存空间，兼顾隔离与高效。编译器与运行时系统对并发任务进行了专项优化，结合轻量线程和并发对象库，实现更佳的资源管理与调度效率。

跨语言互操作

仓颉语言提供了强大的跨语言互操作能力，支持与C语言和ArkTS的无缝集成。这意味着：

• 可以充分利用现有的C语言图片解码库（如libavif、libwebp等）

• 可以与ArkTS UI层进行双向通信

• 可以复用现有的鸿蒙UI组件和生命周期机制

平滑迁移

对于已有ArkTS代码的项目，仓颉支持渐进式迁移。开发者可以选择性能关键模块使用仓颉重写，保持其他模块不变，降低迁移风险和成本。

3.2 支持ArkUI组件：

仓颉可以直接支持和创建ArkUI组件，这意味着图片库可以无缝集成到鸿蒙的声明式UI框架中：

这种设计让业务层可以像使用普通组件一样使用仓颉图片库，无需关心底层实现细节。

4.1 整体架构：

爱奇艺仓颉图片库采用分层架构设计，核心组件包括：

4.2 仓颉/ArkTS混合架构：

为了兼顾开发效率和性能，我们采用了仓颉/ArkTS混合架构：

• ArkTS层：负责UI展示、生命周期管理、业务逻辑

• 仓颉层：负责图片加载、解码、缓存、任务调度等核心功能

• C语言层：复用成熟的编解码库（libavif、FFmpeg等）

这种架构的优势在于：

• UI层保持ArkTS开发效率，无需切换语言

• 核心性能模块使用仓颉，发挥语言性能优势

• 复用成熟C库，避免重复造轮子

4.3 图片处理流程：

图片库采用「缓存优先、网络兜底」的三级缓存策略（内存LruCache → 磁盘缓存 → 网络请求），结合静态图与动图的差异化解码方案。加载流程从主线程 loadImage 通过 spawn 触发异步任务，经缓存层快速响应后进入解码处理：静态图直接解码为单帧 PixelMap，动图经 avif 解码和帧管理后输出多帧 PixelMap 序列，最终所有图片统一转换为PixelMap 格式，通过 launch 机制触发 ArkUI Image 组件渲染展示。这种分层设计让 UI 层无需关心图片来源，兼顾开发效率与极致性能。

4.4 动图解码优化：

动图解码是图片库的技术难点之一，我们针对仓颉语言特性进行了专项优化：

帧级锁机制：

• 按帧串行处理，确保帧顺序，防止画面错乱

• 使用仓颉的并发原语实现高效的锁机制

同步机制：

• 保证解码后的帧数据正确及时传递至渲染线程

• 平衡解码速度与渲染帧率，避免内存堆积

任务队列管理：

• 高效调度多个解码任务，避免线程阻塞

• 支持动图优先级管理，优先保证可见区域动图流畅播放

5.1 关键优化点：

互操作回调优化

通过互操作回调实现ArkTS生命周期事件与仓颉端的衔接，如aboutToReuse、aboutToRecycle等。在组件复用和回收时，及时释放仓颉侧资源，避免内存泄漏。

内存复制优化

基于memcpy高效完成C侧解析buffer的内存复制与传递。减少不必要的数据拷贝，降低内存带宽压力。

标准库优化

利用仓颉标准库优化网络请求与文件操作性能：

• 使用仓颉异步I/O接口，提升并发处理能力

• 复用连接池，减少TCP握手开销

• 批量读写磁盘，减少系统调用次数

线程调度优化

减少不必要的线程切换，内存缓存等轻量场景直接在主线程完成处理。仅在真正需要异步执行的任务（如网络请求、图片解码）才使用后台线程。

5.2 内存优化成果：

通过仓颉的内存管理优势，我们在内存占用方面取得了显著优化：

• 内存峰值降低60%+：相比纯ArkTS方案，仓颉图片库的内存峰值大幅降低

• 更稳定的内存曲线：避免GC抖动带来的性能波动

• 更可控的资源释放：利用所有权机制，确保资源及时释放

6.1 性能提升：

我们使用12张不同类型图片进行加载耗时对比测试（单位：毫秒）：

核心结论：

• 整体加载耗时显著降低，特别是网络动图场景优化幅度达75%

• 自定义程度提升，可针对业务场景进行深度优化

• 编码耗时分布更均衡，避免单一任务阻塞

6.2 用户体验提升：

在实际产品场景中，仓颉图片库带来了明显的用户体验提升：

• 首屏加载速度提升：首页海报加载更快，用户进入即可看到内容

• 列表滑动更流畅：长列表滑动时图片加载无卡顿

• 动图播放更顺滑：动图帧率稳定，无掉帧现象

• 内存占用降低：应用运行更稳定，减少OOM风险

仓颉图片库的建设是一个持续演进的过程，我们规划了以下发展方向：

7.1 功能补齐：

借助仓颉语言的高性能与并发特性，持续完善图片库能力：

• 更多格式支持：更多图片格式解码支持

• 更丰富的图片处理：滤镜、水印、智能裁剪等

• 内存优化：更精细的缓存策略，支持图片预加载与智能回收