在推进采购数字化的过程中，很多企业都会遇到一个现实问题：市场上号称“数字化采购 / 采购 SaaS / SRM”的平台很多，但真正专注于采购场景、并且在企业中被广泛采用的，到底有哪些？

有的企业刚开始调研，希望先了解行业主流平台；有的已经立项，却发现不同厂商定位差异很大；也有不少采购负责人，在ERP采购模块和独立采购SaaS之间反复权衡。

如果你正处在采购系统选型或前期评估阶段，这篇文章将从行业视角，梳理当前专注于数字化采购的主流SaaS平台，并提供一套更理性的选型参考思路。

需要先说明的是，所谓“排名靠前”，并不等同于“最适合所有企业”。不同规模、不同行业、不同采购成熟度的企业，关注重点完全不同。本文不会简单给出“谁最好”的结论，而是帮助你建立判断框架，避免选型走弯路。

一、 市场格局与平台共性：什么样的平台算“靠前”？

目前，数字化采购SaaS市场已进入规模化应用阶段，厂商众多，定位各异。这并不是一个“赢家通吃”的市场，采购场景的复杂性决定了没有一家平台能通吃所有客户。

在实践中，被市场认为“排名靠前”或主流的平台，通常具备一些共性特征：

客户基础扎实，行业覆盖广：已服务大量中大型企业客户，案例覆盖制造、零售、工程等多个行业，而非局限于单一领域。

产品成熟度高：不仅功能完整，更在复杂流程配置、多组织权限、合规风控等企业级能力上经过验证。

交付与服务能力稳定：具备成熟的实施方法论和专业团队，能保障系统成功落地与持续应用。

生态集成能力强：能与ERP、财务、OA等企业核心系统稳定对接，打破数据孤岛。

二、 主流平台深度测评：五大典型路径解析

市场上的领先平台，根据其背景、优势和目标客群，可以归纳为几种典型路径。了解这些路径，比单纯记名字更有助于你做出选择。

类型一：深耕流程的“行业专家型” —— 【正远科技】

这类平台通常从深厚的业务流程管理（BPM）或特定行业咨询背景成长而来，其核心优势在于 对采购业务本质的深度理解与极强的流程定制能力。

1、正远科技

正远科技是一家在流程管理领域扎根超过20年的厂商。他们的数字化采购方案以 自研SRM系统 和 ZeroCloud低代码平台 为核心，不是简单的功能堆砌，而是围绕“供应商管理、价格管理、采购执行协同”三大核心业务模块进行深度设计。

核心优势：

流程柔性极强：依托低代码平台，企业可以像搭积木一样，自主配置符合自身合规要求和审批习惯的采购流程，特别适合流程复杂、个性化要求高的大型企业。

行业理解深入：长期服务威高集团、南山集团等大型制造企业，其解决方案能深度匹配制造业对物料、供应商、质量协同的严苛要求。

全链路覆盖：从供应商准入、绩效评估，到询比价招标、订单协同、收货对账，实现了采购业务的全周期数字化管理。

适合谁：流程复杂、追求深度定制化，且希望采购系统能与自身管理体系高度融合的大中型企业，尤其是制造业、工程建筑等对流程管控要求严格的行业。

类型二：生态整合的“巨擘型” —— 【用友与金蝶】

这类平台源自国内ERP巨头，其最大优势在于 与财务、供应链、生产等系统“天生一体”的无缝集成，数据流转顺畅，能实现真正的业财一体化。

2、用友YonBuilder & 金蝶云·苍穹

用友采购云：背靠用友庞大的ERP生态，对于已使用用友系统的企业，集成成本最低。其战略寻源模块强大，特别擅长处理国企、大型集团复杂的招标采购与合规需求。

金蝶采购云：基于云原生的金蝶云·苍穹平台构建，在系统敏捷性和弹性方面有优势。其供应商协同门户体验出色，AI辅助定价等智能化场景应用较快。

共同优势：安全性高、系统稳定、生态整合度无与伦比。能完美支持多组织、多账簿的集团型管控。

适合谁：已经或计划全面使用该品牌ERP系统的大型集团企业、国有企业及上市公司，尤其适合将采购合规与财务控制视为生命线的客户。

类型三：产业互联的“供应链协同型” —— 【企企通】

这类平台的核心定位在于 连接与协同，其目标不是简单地管理内部采购流程，而是构建一个连接采购商与海量供应商的在线协同网络，实现供应链端的降本增效。

3、企企通

企企通是国内专注于供应链协同和SRM领域的领先平台。它的核心价值在于打通企业与其供应商之间的数据流与业务流，将传统的线下、离散的采购协作，转变为线上、实时、自动化的协同网络。

核心优势：

构建供应商协同门户：为企业搭建一个专属的、面向所有供应商的在线门户。供应商可通过该门户自助完成接收订单、确认交期、发货通知、在线对账、开具发票等全链路操作，极大减轻采购方的沟通负担。

强化战略寻源与供应商绩效：提供完善的招标、询比价管理工具，并基于真实的交货、质量、服务数据，实现供应商绩效的客观量化评估，为优化供应商体系提供数据支撑。

适合谁：供应链结构复杂、供应商数量众多、对外协同成本高昂的中大型制造、零售或连锁企业。尤其适合那些希望将数字化从内部管理延伸至整个供应链生态，以提升供应链整体韧性与效率的客户。

类型四：敏捷普惠的“中小企业优选型” —— 【支道】

这类平台精准聚焦中小企业市场，在成本、易用性和上线速度上做到了极致平衡，降低了采购数字化的入门门槛。

4、支道

支道提供以无代码平台为核心的一站式解决方案，其采购管理作为开箱即用的场景模板，让非技术人员也能通过拖拽搭建系统。

核心优势：性价比高、部署快、极其灵活。能快速响应中小企业在发展过程中不断变化的采购管理需求。

适合谁：IT预算和能力有限，但急需实现采购基础流程数字化、规范化，并追求高性价比的中小企业，是迈出采购数字化第一步的稳妥选择。

三、 如何选择：避开误区，找到你的“最适路径”

看到这里你会发现，没有“最好”，只有“最适合”。选型中最常见的误区就是“只看功能列表，不看自身基因”。在行动前，建议先内部厘清这几个问题：

1、我们采购数字化的首要目标是什么？ （是降本合规，还是提升协同效率？）

2、我们当前的采购流程成熟度和IT基础如何？

3、我们更看重系统的“开箱即用”，还是“深度定制”？

4、我们是否有足够的资源（预算、团队）来应对系统实施和后续变革？

选型逻辑参考：

如果你是流程复杂、管控要求高的大型集团，优先考虑“行业专家型”或“生态巨擘型”。

如果你是正在规范化、寻求效率突破的中大型企业，“行业专家型”或“通用平台型”的平衡性可能更佳。

如果你是期望解决同外部供应商之间的沟通滞后、数据孤岛问题，那么打造一个高效的 “供应链协同网络”可以是首要战略。

如果你是追求实用、快速见效的中小企业，“敏捷普惠型”是一个务实的起点。

结语

采购数字化不是一次简单的软件采购，而是一场涉及流程、组织和数据的深层变革。所谓“排名靠前”的平台，都是在特定路径上积累了深厚优势的伙伴。

最理性的做法，是抛开模糊的“排名”焦虑，回归自身业务现状与发展蓝图。在理解不同平台类型基因的基础上，选择那条与自身阶段最匹配、能陪伴你持续成长的数字化路径。希望这份测评与梳理，能为你带来清晰、实用的选型洞察。

一、QAT 调优流程

流程总览：

针对征程 6H/P 的硬件特性，以 int8+int16+fp16 的混合精度量化为主要调优配置，会增加较多的 fp16 设置来优化量化精度

注意：

征程 6H/P 上会用到更多 fp16 高精度和 GEMM 类算子双 int16 等的配置，为了配置方式更加简单灵活，QAT 量化工具提供了一套新的 qconfig 量化配置模板，具体使用方式和注意事项参考：

<u>【地平线 J6 工具链入门教程】QAT 新版 qconfig 量化模板使用教程</u>

调优原则：

如上是一个标准的对称量化公式，产生误差的地方主要有：

1. round 产生的舍入误差。例如：当采用 int8 量化，scale 为 0.0078 时，浮点数值 0.0157 对应的定点值为 round（0.0157 / 0.0078） = round（2.0128） = 2，浮点数值 0.0185 对应的定点值为 round（0.0185 / 0.0078） = round（2.3718） = 2，两者均产生了舍入误差，且由于舍入误差的存在，两者的定点值一致。 对于舍入误差，可以使用更小的 scale，这样可以使得单个定点值对应的浮点值范围变小。由于直接减小 scale 会导致截断误差，所以常用的方法是使用更高的精度类型，比如：将 int8 换成 int16，由于定点值范围变大， scale 将减小。
2. clamp 产生的截断误差。当 qmax * scale 无法覆盖需要量化的数值范围时，可能产生较大截断误差。例如：当采用 int8 量化，scale 为 0.0078 时，qmax * scale = 127 * 0.0078 = 0.9906，大于 0.9906 的值对应的定点值将被截断到 127。 对于截断误差，可以使用更大的 scale。scale 一般是由量化工具使用统计方法得到，scale 偏小的原因是校准数据不够全，校准方法不对，导致 scale 统计的不合理。比如：某一输入的理论范围为 [-1， 1]，但校准或 qat 过程中，没有观测到最大值为 1 或最小值为 -1 的样本或观测到此类样本的次数太少。应该增加此类数据或者根据数值范围，手动设置固定 scale。在截断误差不大的情况下，可以调整校准参数，通过不同的校准方法和超参缓解截断误差。

因此，QAT 量化精度调优以减少上述两种误差为基本原则，下文将针对 QAT 每个阶段做调优介绍：

注意：

征程 6H/P 平台的浮点模型量化友好设计以及 QAT 模型改造等内容和征程 6E/M 一致，仍可参考该文章对应章节：

<u>【地平线 J6 工具链进阶教程】J6 E/M 工具链 QAT 精度调优</u>

1.1 模型检查

完成模型改造和量化配置后，调用 Prepare 接口时会对模型做算子支持和量化配置上的检查，这些检查一定程度上反映了模型量化存在的问题。对于不支持的算子将以报错的形式提醒用户，一般有两种情况：

1. 未正确进行模型的量化改造。Prepare 过程中 QAT 量化工具会对模型进行 trace 来获取完整的计算图，在这个过程中会完成算子替换等的优化，对于这些已替换的算子，输入输出类型如果是 torch.tensor 而非经过 QuantStub 转化后的 qtensor，则会触发不支持算子的报错，表现为 xxx is not implemented for QTensor；
2. 确实存在不支持的算子。工具链已支持业界大量的常用算子，但对于部分非常见算子的不支持情况，需考虑进行算子替换或者作为算子需求向工具链团队导入。

Prepare 运行成功后会在当前目录下自动保存模型检查文件 model_check_result.txt 和 fx_graph.txt，建议参考下列解读顺序：

1. 算子融合检查。算子融合作为 QAT 量化工具的标准优化手段，常见的融合组合为 Conv+ReLU+BN 和 Conv+Add 等，未融合的算子会在 txt 文件中给出，未按预期融合的算子可能是因为共享没有融合成功或者是 QAT 量化工具的融合逻辑变更（针对新版 qconfig 量化模板 enable\_optimize=True 情况，见<u>【地平线 J6 工具链入门教程】QAT 新版 qconfig 量化模板使用教程</u>），需要检查代码，确认未融合的情况是否符合预期：

# 示例：未融合的Conv+Add算子
Fusable modules are listed below:
name       type------  -------------------------
model.view_transformation.input_proj.0.0(shared) 
<class'horizon_plugin_pytorch.nn.qat.conv2d.Conv2d'>
model.view_transformation._generated_add_0        
<class'horizon_plugin_pytorch.nn.qat.functional_modules.FloatFunctional'>

未融合的算子对模型性能会有一定影响，对于精度的影响需视量化敏感度具体分析，一般来说，Conv/Linear+ReLU+BN 可能会因为算子复用导致未融合，此时建议手动修改融合；在 OE 3.5.0 以及之后版本使用新 qconfig 模板下，Conv+Add 默认不会融合，可不修改

2. 共享模块检查。一个 module 只有一组量化参数，多次使用将会共享同一组量化参数，多次数据分布差异较大时，会产生较大误差：

# 示例：该共享模块被调用8次
Each module called times:
name      called times
---------  --------------   
...
model.map_head.sparse_head.decoder.gen_sineembed_for_position.div.reciprocal                          
8

called times > 1 的模块可能有很多个，全部改写成非共享是一劳永逸的。对于修改简单且精度影响大的共享算子如 QuantStub，强烈建议取消共享；对于 DeQuantStub 算子，共享不会对模型精度产生影响，但是会影响 Debug 结果的分析，也建议取消共享，修改方式参考征程 6E/M“模型改造”章节。

例如下面的共享模块，量化表示的最大值为 128 * 0.0446799 ≈ 5.719，在第一次使用中，输出范围明显小于 [-5.719， 5.719]，误差较小， 第二次使用中，输出范围超出 [-5.719， 5.719]，数值被截断，产生了较大误差。两次数值范围的差异也造成了统计出的 scale 不准确，因此该共享模块必须修改

+-+-+-+-+-+-+--+-+-+-+-+|   | mod_name | base_op_type   | analy_op_type  | shape  | quant_dtype |  qscale |base_model_min | analy_model_min | base_model_max |   analy_model_max ||-+-+--+-+-+-+-+-+-+-+-+...| 1227 | model.map_head.sparse_head.decoder.gen_sineembed_for_position.div | horizon_plugin_pytorch.nn.div.Div  | horizon_plugin_pytorch.nn.qat.functional_modules.FloatFunctional.mul  | torch.Size([1, 1600, 128])| qint8  |  0.0446799 | 0.0002146 | 0.0000000 | 4.5935526 |  4.5567998 |...| 1520 | model.map_head.sparse_head.decoder.gen_sineembed_for_position.div | horizon_plugin_pytorch.nn.div.Div  | horizon_plugin_pytorch.nn.qat.functional_modules.FloatFunctional.mul | torch.Size([1, 1600, 128]) | qint8 |  0.0446799 | 0.0000000 | 0.0000000 |  6.2831225 |  5.7190272 |...

上面共享算子的修改方式可以参考：

class Model(nn.Module):def __init__(self, ) -> None:super().__init__()...
        self.steps = 2for step in range(self.steps):setattr(self, f'div{step}', FloatFunctional())def forward(self, data):...for step in range(self.steps):
            data = getattr(self, f'div{step}').div(x)...

对于不带权重的 function 类算子都可以参考上面的拆分方式，但是也存在部分共享算子或模块带有权重参数拆分起来比较复杂，是否需要拆分建议先根据量化敏感度进行分析。带有权重参数算子拆分时需要复制权重，拆分方式可以参考：

class Model(nn.Module):def __init__(self, ) -> None:super().__init__()...
        self.steps = 3
        self.conv0 = nn.Conv2d(...)
        shared_weight = self.conv0.weight
        shared_bias = self.conv0.bias
        for step in range(1, self.steps):setattr(self, f'conv{step}', nn.Conv2d(...))getattr(self, f'conv{step}').weight = shared_weight
            getattr(self, f'conv{step}').bias = shared_bias
  
    def forward(self, data):...for step in range(self.steps):
            data = getattr(self, f'conv{step}')(x)...

上述共享算子修改生效后，在 model_check_result.txt 文件中可见到无该算子共享相关的信息：

# 修改生效后下面信息将不再显示
Modules below are used multi times:
name      called times
------  --------------
xxxxx                2

此外，未调用的模块也会在文件中体现，called times 为 0，当 Calibration/QAT/模型导出出现 miss\_key 时，可以检查模型中是否有模块未被 trace。

3. 量化配置检查。txt 文件中会给出模型量化精度的统计信息：

# 算子输入量化精度统计input dtype statistics:+---+--+--+--+| module type                                                                |   torch.float32 |   qint8 |   qint16 ||---+---+--+--+| <class 'horizon_plugin_pytorch.nn.qat.stubs.QuantStub'>                    |             290 |      15 |        0 || <class 'horizon_plugin_pytorch.nn.qat.linear.Linear'>                      |               5 |     117 |        9 || <class 'horizon_plugin_pytorch.nn.qat.stubs.DeQuantStub'>                  |               0 |       8 |        0 |...# 算子输出量化精度统计
output dtype statistics:+---+--+--+--+| module type                                                                |   torch.float32 |   qint8 |   qint16 ||---+--+--+--+| <class 'horizon_plugin_pytorch.nn.qat.stubs.QuantStub'>                    |               0 |     123 |      182 |...# 使用fp16量化精度的算子，量化精度统计+---+--+--+--+--+| module type                                                                |   torch.float32 |   qint8 |   qint16 |   torch.float16 ||-----+--+--+--+--|| <class 'horizon_plugin_pytorch.nn.qat.stubs.QuantStub'>                    |              34 |       0 |        0 |               0 || <class 'torch.nn.modules.padding.ZeroPad2d'>                               |               0 |      11 |        0 |               0 || <class 'horizon_plugin_pytorch.nn.qat.functional_modules.FloatFunctional'> |              48 |      14 |        9 |              50 |...

重点检查的信息有：

• <class 'horizon_plugin_pytorch.nn.qat.stubs.QuantStub'> 的 input dtype 应为 torch.float32，对于 qint8 或者 qint16 的 input dtype，一般是冗余的 QuantStub 算子可以改掉，不会对精度产生影响但可能会对部署模型性能有影响（算子数量）
• 正常来说模型中的算子不应出现 torch.float32 的输入精度（除下文 c 情况），如上图的 <class 'horizon_plugin_pytorch.nn.qat.linear.Linear'>，需要检查是否漏插 QuantStub 未转定点，未转定点的算子在导出部署模型时会 cpu 计算从而影响模型性能。对于模型中的一些浮点常量 tensor，工具已支持自动插入 QuantStub 转定点，建议获取最新版本
• 对于 GEMM 类算子（Conv/Matmul/Linear）作为模型输出时支持高精度输出（征程 6E/M 支持 int32 输出，征程 6B/H/P 支持浮点输出），体现到这里则是 <class 'horizon_plugin_pytorch.nn.qat.stubs.DeQuantStub'> 的 input dtype 应为 torch.float16 或 torch.float32，对于 qint8 或 qint16 输入的 DeQuantStub 需要检查是否符合高精度输出的条件，符合条件但未高精度输出的需修改。此外对于下面左图的结构，也建议优化为右图结构来保证高精度输出的优化

• qint8 和 qint16 算子的占比，可以协助判断是否配置全 int16 生效；torch.float16 算子的占比，可以协助判断是否配置 fp16 生效

txt 文件同时会给出逐层的量化配置信息：

# 激活逐层qconfig
Each layer out qconfig:+--+--+--+--+--+--+| Module Name| Module Type | Input dtype | out dtype | ch_axis | observer ||--+--+--+--+--+---|# 固定scale| quant | <class 'horizon_plugin_pytorch.nn.qat.stubs.QuantStub'>                    | [torch.float32] | ['qint16']| -1  | FixedScaleObserver(scale=tensor([3.0518e-05], device='cuda:0'),zero_point=tensor([0], device='cuda:0')) |# QAT训练激活scale更新| mod2.1.attn.q | <class 'horizon_plugin_pytorch.nn.qat.conv2d.Conv2d'>  | ['qint16']  | ['qint16'] | -1 | MinMaxObserver(averaging_constant=0.01) |# QAT训练激活scale不更新| mod2.1.FFN.out_conv.1.0| <class 'horizon_plugin_pytorch.nn.qat.conv2d.Conv2d'> | ['qint16']| ['qint16']| -1| MinMaxObserver(averaging_constant=0)  |# 激活fp16 qconfig| bev_fusion.multi_view_cross_attn.32.global_cross_window_attn._generated_add_2[add]| <class 'horizon_plugin_pytorch.nn.qat.functional_modules.FloatFunctional'> | [torch.float16, torch.float32]                     | [torch.float16] | FakeCast(dtype=torch.float16, min_val=-0.0009765625, max_val=0.0009765625)  | |# 权重逐层qconfig
Weight qconfig:+-----+----+-----+------+---+| Module Name | Module Type | weight dtype|ch_axis|observer ||---+-------+----+----+---|| mod1.0 | <class 'horizon_plugin_pytorch.nn.qat.conv2d.Conv2d'> |qint8 | 0 | MinMaxObserver(averaging_constant=0.01) |

重点检查的信息有：

• 每层算子的输入输出 dtype、权重的 dtype，是否符合量化配置；若和量化配置不符合，比如配置了 int16，但是算子显示为 int8，则需要关注下算子回退信息，例如在旧模板下 Conv+Add 融合时 Conv 不支持 int16 输入，会导致前序算子输出回退到 int8。新的 qconfig 量化配置模板下算子回退过程需查看 qconfig\_changelogs.txt，详细参考：https://developer.horizon.auto/blog/13112
• 配置了 fix scale 的算子，是否正确显示 FixedScaleObserver 信息，scale 值是否正确
• 逐层算子的 observer 是否正确：权重默认 MinMaxObserver，QAT 校准时激活默认 MSEObserver，QAT 训练时激活默认 MinMaxObserver
• 若为 QAT 训练阶段且配置了固定校准的激活 scale，查看 averaging\_constant，判断是否生效，生效为 averaging\_constant=0（即不更新 scale），默认为 0.01（更新 scale）

对于 fx_graph.txt，可以从中获取到模型中 op/module 的上下游调用关系，例如当存在算子 called times 为 0 未被调用的情况，可以通过 Graph 定位到上下文算子从而定位未被调用的原因（通常因为在 init 函数中定义了但在 forward 中没有调用，也可能存在逻辑判断或循环次数变化的情况）；此外当出现导出的部署模型（bc 模型）精度异常，也可以通过 Graph 信息来排查是否是导出计算图改变导致的

# 模型Graph图结构信息
Graph:
opcode       name        target            args           kwargs
----         -----       -------           -------        -------
placeholder    input_0    input_0              ()         {}
call_module    quant       quant            (input_0,)     {}
call_module  traj_decoder_src_proj_0_0  traj_decoder_src_proj.0.0                                             (quant,)  {}
call_function  scope_end    <function Tracer.scope_end at 0x7f4477d7dc60>   ('traj_decoder_src_proj.0',) {}
call_function  __get__    <method-wrapper '__get__' of getset_descriptor object at 0x7f460922b800>  (traj_decoder_src_proj_0_0,) {}
call_function  __getitem__       <slot wrapper '__getitem__' of 'torch.Size' objects>     (__get__, 0)   {}
call_function  __getitem___1      <slot wrapper '__getitem__' of 'torch.Size' objects>   (__get__, 1)  {}
call_function  __getitem___2     <slot wrapper '__getitem__' of 'torch.Size' objects>   (__get__, 2)   {}
call_function  __getitem___3      <slot wrapper '__getitem__' of 'torch.Size' objects>   (__get__, 3) {}
call_function  permute     <method 'permute' of 'torch._C.TensorBase' objects>   (traj_decoder_src_proj_0_0, 0, 2, 3, 1)  {}...

重点关注的 Graph 信息：

• opcode 为算子调用类型
• name 为当前算子名称，需注意和 model_check_result.txt 中的 module.submodule 名称区别
• target 为算子输出
• args 为算子输入

1.2 QAT 校准

1.2.1 int8+int16+fp16 混合精度调优

如果模型中吸收了前后处理的相关算子和操作，这部分默认需要 fp16 精度进行量化

对于 int8+int16+fp16 混合精度而言，主要的量化配置如下（配置方式参考<u>【地平线 J6 工具链入门教程】QAT 新版 qconfig 量化模板使用教程</u>）：

• 基础配置： TAE 算子（Conv/Matmul/Linear）双 int8、其他算子 fp16
• 精度优化配置： TAE 算子（Conv/Matmul/Linear）单 int16（部分双 int16）、其他算子 fp16
• 精度上限配置： TAE 算子（Conv/Matmul/Linear）双 int16、其他算子 fp16
• 性能上限配置： 全局 int8，建议仅在测试模型最优性能（精度无保证）或作为高精度耗时优化的对比参考时配置

同样的对于较难量化的模型而言，初始应使用精度上限配置，在这个配置下解决量化流程可能的问题，优化量化风险较大的算子/模块，往往通过 Debug 工具进行定位，但在使用 Debug 工具较难定位到量化瓶颈时，可以使用分步量化的小技巧（参考本文最后章节"调优技巧"），也即对选中算子取消量化后对比精度，如定位到前后处理的算子/模块产生明显掉点，建议从模型中剥离；定位到模型中算子/模块，可以使用设置 fix\_scale 和拆分共享模块等方式，或者从量化友好角度修改浮点模型（参考征程 6E/M 量化调优对应章节：<u>【地平线 J6 工具链进阶教程】J6 E/M 工具链 QAT 精度调优</u>）

精度上限配置下的模型较难满足部署侧的延时要求，因此解决掉上述的量化瓶颈后需要回归到基础配置。在基础配置上通过敏感度的分析结果，增加 TAE 的 int16 算子，也就是精度优化配置。在基础配置和精度优化配置下精度达标的模型，视延时情况可能需要进一步做性能优化，主要方向为：

1. 基础配置下，回退 fp16 性能瓶颈算子到低精度 int8
2. 精度优化配置下，回退双 int16 的 TAE 算子到单 int16，回退 fp16 性能瓶颈算子到低精度 int8

精度优化配置下如果 int16 算子比例已超出部署预期但精度仍有一定差距，则可以考虑回退部分 int16 算子后尝试 QAT 训练；基础配置下精度表现距离浮点差距较小（量化精度/浮点精度 > 90%，经验值），直接尝试 QAT 训练，在 量化精度/浮点精度 >= 95%（经验值）的情况下，建议优先尝试固定校准激活 scale 的 QAT 训练（仅调整权重感知量化误差）

对于不同精度配置下的 QAT 校准，都有一些校准超参可以调整，需要用户结合具体模型去做调参优化，其中主要的参数有校准数据的 batch size、校准的 steps，详细的参数参考：

1. 基础调优手段：<u>调优指南\_基础调优手段</u>
2. 高级调优手段：<u>调优指南\_高级调优手段</u>

由于征程 6H/P 平台使用了较多浮点 FP16 精度，该精度下数值范围超限场景有以下常见的优化方法和优缺点总结：

总结：

int8+int16+fp16 混合精度调优的重点应放在 TAE 双 int16+ 其他算子 fp16 的调优上，这里需要把使用问题，量化不友好模块等等各种千奇百怪的问题都解决，看到模型的精度上限，然后根据模型部署的性能要求进行 TAE int8 和 int16 混合精度的调优，最后对非 TAE 算子进行 int8+fp16 混合精度的调优，最终达成部署精度和部署性能的平衡。

1.2.2 Debug 产出物解读

征程 6H/P 平台 Debug 产出物的解读和征程 6E/M 一致，仍可参考该文章对应章节：<u>【地平线 J6 工具链进阶教程】J6 E/M 工具链 QAT 精度调优</u>

Badcase 调优

对于实车或回灌反馈的可视化 badcase，利用 Debug 工具的调优流程为：

1.3 QAT 训练

大部分模型仅通过 QAT 校准就可以获得较好的量化精度，对于部分较难调优的模型，以及还需要继续优化误差类指标的模型，通常校准设置的高精度比例导致延时超过部署上限，但精度仍无法达标，这种情况可以尝试 QAT 训练来获得满足预期性能-精度平衡的量化模型。

根据前文所述，在 QAT 校准 量化精度/浮点精度 >= 95%（经验值） 的情况下，充分利用校准阶段较好的激活量化参数，优先尝试固定校准激活 scale 的 QAT 训练（仅调整权重感知量化误差），设置方式具体参考征程 6E/M 精度调优的“模型改造”章节：<u>【地平线 J6 工具链进阶教程】J6 E/M 工具链 QAT 精度调优</u>

参考浮点训练，QAT 训练在大部分配置保持和浮点训练一致的基础上，也涉及到部分超参的调整来提升量化训练的精度，例如 QAT 的学习率、weight\_decay、迭代次数等，详细的参数调整策略参考：

1. 基础调优手段：<u>调优指南\_基础调优手段</u>
2. 高级调优手段：<u>调优指南\_高级调优手段</u>

浮点和 QAT 训练中都涉及到对 BN 的状态控制，在浮点训练中可能会采用 FreezeBN fine-tune 的方式来提升模型精度，在多任务训练中也会采用 FreezeBN 的技巧。因此在 QAT 训练中，提供了 FuseBN 和 WithBN 两种训练方式：

1. FuseBN 即在 Prepare 后，QAT 训练前将 BN 的 weight 和 bias 吸收到 Conv 的 weight 和 bias 中，在训练过程中不再单独更新，这一吸收过程是无损的。FuseBN 也是 QAT 默认的训练方式。
2. WithBN 则是在 QAT 训练阶段保持 Conv+BN 不融合，带着 BN 进行训练，BN 的参数单独更新，在训练结束后转成部署模型时再做融合。浮点训练阶段如果采用了 FreezeBN 的训练方式，QAT 训练时需设置 WithBN 来对齐浮点训练方式，设置方式如下：

from horizon_plugin_pytorch.qat_mode import QATMode, set_qat_mode
set_qat_mode(QATMode.WithBN)

通过观察 QAT 训练过程的 Loss 变化来初步判断 QAT 训练的量化效果，一般来说和浮点最后的 Loss 结果越接近越好，Loss 过大可能难以收敛，Loss 过小可能影响泛化性，对于异常的 Loss 建议的优化手段：

1. 异常 INF 和 NAN 的 Loss 值，或者初始 Loss 极大且无收敛迹象，按如下顺序排查：

   1. 去掉 prepare 模型的步骤，用 qat pipeline finetune 浮点模型，排除训练 pipeline 的问题，Loss 如果仍异常，需要检查训练链路的配置如优化器 optimizer 和 lr\_updater 等
   2. 保持当前 QAT 训练配置，只关闭伪量化节点后观察训练的 Loss 现象，理论上和浮点有微小差异

from horizon_plugin_pytorch.quantization import set_fake_quantize, FakeQuantState
...
set_fake_quantize(qat_model, FakeQuantState._FLOAT)
train(qat_model, qat_dataloader)

2. 在排查完链路问题后出现初始 Loss 较大，有收敛迹象但收敛较慢，这种情况可以尝试调整学习率，延长 QAT 迭代次数，因为 QAT 训练本质上是对已收敛浮点模型的 fine-tune，本身存在一定的随机性，用较大的学习率可以快速波动到一个理想精度（依赖一些中间权重的评测）
3. 对于少数模型，QAT 训练以及尝试了多次超参调整后精度仍无法达标，建议回归 QAT 校准阶段增加少量高精度算子（增加 GEMM 类算子 int16，以及其他算子增加 FP16）、回归浮点结构检查是否还存在量化不友好的结构如使用了大量 GeLU 等（参考征程 6E/M 精度调优对应章节<u>【地平线 J6 工具链进阶教程】J6 E/M 工具链 QAT 精度调优</u>）

1.3.1 QAT 训练效率

由于 QAT 训练过程需要感知模型量化所带来的损失，因此模型中会被插入必要的量化相关的节点：数据观测节点 Observer 和伪量化节点 FakeQuant。数据观测节点会不断统计模型中数据的数值范围，伪量化节点会根据量化公式对数据做模拟量化和反量化，两者都会存在开销，此外就是 QAT 工具内部会对部分算子例如 LN 层做拆分算子的实现，因此相同配置下的 QAT 训练效率是会略低于浮点训练效率，具体还和模型参数规模、算子数量等有关。

对于用户可明显感知到的 QAT 训练效率降低，建议的优化手段有：

1. 使用 QAT 工具提供的算子，这些算子优化了训练效率，例如 MultiScaleDeformableAttention（<u>参考手册</u> ）
2. 更新到最新的 horizon-plugin-pytorch 版本，新版本会有持续的 bug fix 和新特性优化，如模型中某些结构或者算子训练耗时增加明显，可以向工具链团队导入

1.4. 模型导出部署

完成 QAT 精度调优后得到的模型仍是 PyTorch 模型，需要使用简单易用的接口来一步步导出编译成部署模型：PyTorch模型 -> export -> convert-> compile

export 得到 qat.bc； convert 得到 quantized.bc； compile 得到 hbm

由于导出生成物中计算差异的存在，对于每个生成物需简单验证其精度，可通过单张可视化或 mini 数据集，过程中如存在精度掉点，请参考<u>【地平线 J6 工具链进阶教程】J6 E/M 工具链 QAT 精度一致性问题分析流程</u>

二.调优技巧

2.1 分部量化

下面这种方式仅适用于 Calib 阶段，QAT 阶段因为模型已经适应了量化误差，关闭伪量化精度无法保证

from horizon_plugin_pytorch.utils.quant_switch import GlobalFakeQuantSwitch 
class Model(nn.Module):     
    def _init_(...):     
    def forward(self, x):         
        x = self.quant(x)         
        x = self.backbone(x)         
        x = self.neck(x)         
        GlobalFakeQuantSwitch.disable() # 使伪量化失效         # --------- float32 ---------         ​
        x = self.head(x)         
        # ---------------------------         ​
        GlobalFakeQuantSwitch.enable() # 重新打开伪量化         return self.dequant(x)

2.2 部分层冻结下的 QAT 训练

模型 QAT 训练时，要求模型为 train（） 状态，此时若部分层冻结，则需要对应修改状态，参考代码如下：

from horizon_plugin_pytorch.quantization import (
    QuantStub,
    prepare,
    set_fake_quantize,
    FakeQuantState,)

qat_model = prepare(model, example_inputs=xxx, qconfig_setter=(xxx))
qat_model.load_state_dict("calib_model_ckpt.pth")

qat_model.train()# 关闭requires_grad可固定权重不更新，但Drop、BN仍然会更新for param in qat_model.backbone.parameters():
    param.requires_grad = False# 配置eval()可固定Drop、BN不更新，但不会固定权重，因此两者需要配合使用
qat_model.backbone.eval()
set_fake_quantize(qat_model.backbone, FakeQuantState.VALIDATION)#配置head的FakeQuant为QAT状态
set_fake_quantize(qat_model.head, FakeQuantState.QAT)

2.3 Calib/QAT 过程 NaN 值定位

出现 NaN 值可通过下面的修改在 calib/qat forward 过程中报错，从而定位到具体的算子：

from horizon_plugin_pytorch.quantization.fake_quantize import FakeQuantize
FakeQuantize.check_nan_scale='forward'#默认为save，在torch.save时检查是否有nan，有nan会报错
qat_model = prepare(model, (input), default_qat_qconfig_setter)

常见的可能出现 NaN 值的结构：

Multi-head Attention 的 attn mask，需要手动做数值的 clamp

以下内容来源于DataforAI社区，作者Data for AI

当 AI 遇见数据：一场面向工程实践的技术交流

大模型并没有直接带来 AI 应用的成熟。真正决定 AI 能否规模化落地的，正在从模型本身，转移到数据、上下文与基础设施。

与此同时，数据基础设施也正经历一轮深刻演进：从传统的数据湖仓，到多模态数据管理；从 SQL 查询引擎，到面向 AI 的数据解析与治理能力。这些变化，正在重新定义我们构建 AI 应用的方式。

1 月 24 日（周六）下午 ，Data for AI 社区 将携手 ALC Beijing (Apache Local Community Beijing) 举办 Data for AI Meetup Beijing，邀请来自产业、开源社区与学术界的一线实践者，围绕 AI 时代的数据基础设施演进 展开深入交流。

本次 Meetup 汇聚了来自 字节跳动火山引擎 / Daft 社区、OceanBase社区、北京大学、Datastrato / Apache Gravitino 社区、Zilliz / Milvus 社区的技术专家，深度剖析 AI 时代数据基础设施的技术演进路径。

📍 本次 Meetup 核心看点

• 多模态数据处理引擎实践：

  Daft 在 AI 数据预处理与训练加载中的工程经验

• AI 原生元数据平台：

  Apache Gravitino 1.1.0 的关键能力与治理实践

• Agent 数据基座设计：

  记忆、检索与数据统一的工程解法

• Data-centric AI 方法论：

  面向大模型的数据准备与质量体系

• 混合检索实践：

  向量 + 全文检索在真实业务中的优化路径

• 开源探索：

  Skill 驱动的上下文工程平台化可能性

• 圆桌讨论：

  下一代面向 AI 应用的数据基础设施如何设计与落地

多模态数据处理的新范式

AI 训练对数据处理提出了全新挑战。火山引擎 AI 数据湖服务架构师 琚克俭 将分享 Daft 在多模态数据处理上的工程实践，聚焦图像、视频、文本等异构数据在统一处理、预处理与训练加载阶段的性能与架构挑战。

这一分享直面当前 AI 工程的核心痛点：传统数据引擎已难以支撑多模态 AI 工作负载，而 Daft 通过全新的架构设计，在数据预处理和训练加载环节实现了显著的性能提升。

元数据治理进入 AI 原生时代

Datastrato VP of Engineering 史少锋 将深度解析 Apache Gravitino 1.1.0 的核心升级，包括 Lance REST 支持、Generic Lakehouse Catalog、Iceberg 安全增强等关键特性。

当 AI 团队需要在多个集群间管理训练数据、推理数据和模型元数据时，传统的元数据工具往往各自为政。Apache Gravitino 1.1.0 通过统一的元数据治理架构，让跨引擎、跨存储的数据协同变得标准化、可管理，大幅降低 AI 工程中的数据协同成本。

上下文工程：Agent 落地的数据基座

OceanBase 技术专家 汤庆 将深度解析当下最热的「上下文工程」话题。他指出，企业级 Agent 面临三大核心挑战：如何让 Agent 拥有可靠的「记忆」（记忆管理）、如何让 Agent「理解」复杂文档（知识检索），以及如何统一处理向量、文本、结构化数据（数据统一）。

这三款 AI 产品的协同设计给出了答案：PowerMem 基于艾宾浩斯遗忘曲线构建智能记忆系统并支持多智能体隔离，PowerRAG 提供多引擎 OCR 与向量 + 全文的混合检索能力，seekdb 则作为 AI 原生数据库统一管理多模态数据并兼容 MySQL 生态。这套方案的核心价值在于：用数据架构的确定性，对抗 Agent 行为的不确定性。

面向大模型时代的 Data-centric AI 基础设施

北京大学助理教授 张文涛 将从学术与工程结合的视角，系统阐述 AI 从「模型为中心」到「数据为中心」的范式转变。当大模型能力趋同，数据质量正在成为决定模型性能的关键变量。

张文涛团队主导开发的 DataFlow 数据准备系统已在大模型预训练、企业知识库构建等场景得到验证。本次分享将深入解析 LLM 数据工程的完整流程：如何获取数据（爬取、解析、合成、标注），如何处理数据（过滤、改写、配比），以及如何评估数据质量。这套开源工具链与方法论，正在为 AI 开发者降低数据工程的门槛。

从向量检索到混合查询：Context Engineering 实践

Zilliz 资深解决方案架构师 刘汉卿 将系统回顾从 Prompt Engineering 到 Context Engineering 的演进路径。随着 RAG 技术从单一向量检索发展到 GraphRAG 与全文检索的混合查询阶段，检索系统已经从「找到相似内容」进化到「理解查询意图并精准召回」。

在这个演进过程中，一个关键趋势是：用向量计算代替多轮LLM推理，通过检索层的优化来提升 AI 应用的性能与稳定性。刘汉卿将结合企业知识库、推荐系统、智能助理等场景，分享混合查询的工作流搭建经验，以及在金融、医疗、法律、教育等行业的实际落地案例。

上下文工程的平台化探索

独立开源开发者 袁怿（Sam Yuan）将从前瞻视角探讨 2026 年上下文工程的技术趋势。如果说 2025 是 Agent 元年，那么随着上下文工程的快速演进，一个关键问题正在浮现：上下文能力是否应该从「各自实现」走向「横向平台化」？

袁怿将上下文工程拆解为三个维度：工具调用（空间维度）、RAG（信息密度维度）与 Memory（时间维度）。他将以最近进入 AAIF 的 Skill 机制为切入点，对比 Skill 与传统 Function Call 的本质差异，并结合他在开源社区贡献的 StructuredContextLanguage 项目，展示以渐进式加载为代表的平台化思路——让 AgentOS 像操作系统管理进程一样，统一管理上下文资源。

圆桌论坛：下一代面向 AI 应用的 Data Infra 的设计和落地

从多模态数据处理到 AI 原生元数据平台，从上下文工程到混合检索系统——本次 Meetup 的所有分享指向同一个命题：在 Agent 时代，数据不再只是「被调用的资源」，而正在成为被理解、被约束、被治理的核心能力。

越来越多团队在实践中遇到相似挑战：Agent 需要访问的数据分散在不同系统中，权限、语义与上下文边界不清；模型可以生成「看似合理」的请求，却难以保证结果的安全性与一致性。这些问题往往无法通过 Prompt 或单点优化解决。

我们特邀到前 Apple 数据与机器学习平台负责人 谭涛（Kwaai AI Lab 顾问）、Datastrato 创始人 CEO 堵俊平、北京大学助理教授 张文涛 三位圆桌嘉宾，围绕三个核心问题展开讨论：

• 意图与执行解耦：如何让 Agent 的数据请求既灵活又可控？
• 访问规则原生化：能否在系统层面保证数据访问的安全性与一致性？
• 上下文边界管理：如何让 Agent Builder 在不理解底层架构的前提下获取「该拿的数据」？

这些讨论并不立马给出最终答案，而是帮助我们勾勒下一代面向 AI 应用的数据基础设施轮廓——一个更开放、更可治理、也更适合 Agent 时代的技术底座。

活动信息

时间：

2026 年 1 月 24 日（周六）13:10 – 18:00

地点：

北京 · 原点学堂（东升大厦 A 座 10 层）（不提供线上直播）

立即报名：

👉 访问链接：https://www.huodongxing.com/event/3843480320400

⚠ 名额有限，需审核通过（请详实填写报名信息，并通过主理人的微信添加请求，确认审核状态）

这是一场面向 AI & Data 工程实践者的技术深度交流。

无论你是正在构建企业级 Agent 系统的架构师，

还是关注 Data-centric AI 的研发工程师，

都能在这里找到有价值的技术洞察和落地经验。

Community Over Code，期待与你在北京相聚。

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

​

前言

在鸿蒙应用的开发历程中，页面跳转一直是大家最先接触的功能之一。很长一段时间里，Router 模块都是我们手中的标配武器，那句 router.pushUrl 相信每一位开发者都烂熟于心。但在构建大型应用，尤其是面对平板、折叠屏这些复杂设备时，老旧的 Router 逐渐显露出了疲态。它是一个页面级别的全局单例，难以处理分屏、弹窗嵌套路由以及模块化的动态加载。这就像是用一把瑞士军刀去砍伐整片森林，虽然能用，但效率极低且手感生涩。

在 HarmonyOS 6 的时代，官方明确推荐我们全面拥抱 Navigation 组件。这不仅仅是一个组件的更替，更是一次架构思维的升级。Navigation 不再是一个简单的 API 调用，它是一个容器，一个能够容纳完整路由栈、标题栏和工具栏的超级容器。它将路由的管理权从系统底层交还到了开发者手中，让我们能够像操作数组一样精准地控制页面的进出栈。

今天，我们就把那个陈旧的 Router 放在一边，深入探讨如何利用 Navigation V2 架构和 NavPathStack 构建一个现代化、健壮的应用导航体系。

一、 从 Router 到 Navigation：架构的范式转移

要理解 Navigation 的强大，我们先得明白它解决了什么痛点。传统的 Router 是基于 Page（页面）的，每一个页面都是一个独立的 Ability 或者窗口层级。当我们想要在一个弹窗里再做一套局部导航，或者在平板的左侧菜单里嵌入一个独立的路由栈时，Router 就束手无策了。

Navigation 组件的出现彻底改变了这一局面。它本质上是一个 UI 组件，这意味着它可以被放置在界面的任何位置。你可以把它放在根节点作为全屏导航，也可以把它放在一个 Dialog 内部，甚至可以嵌套使用。

在 API 20 中，Navigation 采用了 组件级路由 的概念。每一个“页面”不再是 @Entry 修饰的独立文件，而是被 NavDestination 包裹的自定义组件。这种设计让页面变得极其轻量，页面的切换本质上就是组件的挂载与卸载，性能得到了巨大的提升。更重要的是，它配合 NavPathStack 实现了路由栈的可编程化，我们终于可以像操作数据一样去操作界面了。

二、 核心大脑：NavPathStack 路由栈管理

如果说 Navigation 是躯壳，那么 NavPathStack 就是它的灵魂。在 V2 版本中，我们不再直接调用组件的方法来跳转，而是创建一个 NavPathStack 的实例，并将其绑定到 Navigation 组件的 pathStack 属性上。这个栈对象就是我们操控界面的遥控器。

你需要实现一个复杂的登录流程：用户点击购买 -> 跳转登录 -> 跳转注册 -> 注册成功 -> 直接返回购买页（跳过登录页）。在旧的 Router 模式下，你需要计算 delta 索引或者使用 replace 模式小心翼翼地堆叠。而在 NavPathStack 中，就方便多了。你可以随时调用 popToName 直接回到指定的路由锚点，或者操作栈数组，精准地移除中间的某几个页面。

数据的传递也变得优雅。当我们调用 pushPath 时，可以直接传入一个 param 对象。而在目标页面中，我们不需要再写繁琐的 router.getParams()，而是直接在 NavDestination 的 onShown 生命周期或者组件初始化时，从栈中获取参数。这种参数传递是类型安全的，且完全受控。此外，NavPathStack 还提供了强大的拦截器机制（Interception），让我们可以在路由跳转发生前进行鉴权拦截，比如用户未登录时直接重定向到登录页，这一切都在路由层面被优雅地拦截处理了。

三、 页面构造：NavDestination 与路由表设计

在 Navigation 架构下，我们的一级页面（根页面）通常直接写在 Navigation 的闭包里，而二级、三级页面则通过 NavDestination 来定义。这里有一个关键的概念转变：我们需要构建一个 路由映射表。

我们不再是通过文件路径去跳转，而是通过 路由名称（Name）。我们需要在 Navigation 组件中配置 navDestination 属性，它接收一个 @Builder 构建函数。当 NavPathStack 请求跳转到 "DetailPage" 时，这个构建函数就会被触发，我们需要在这个函数里根据传入的 name 返回对应的 NavDestination 包裹的组件。

这种设计模式天然支持模块化开发。我们可以把不同模块的路由表分散在各自的 HAR 包中，最后在主工程中进行聚合。每个 NavDestination 都是一个独立的沙箱，它拥有自己的标题栏、菜单栏和生命周期（onShown, onHidden）。这对于开发者来说非常友好，我们可以在 onWillAppear 中发起网络请求，在 onWillDisappear 中保存草稿，页面的生命周期完全掌握在自己手中。

四、 界面定制：摆脱默认样式的束缚

Navigation 自带了标准的标题栏（TitleBar）和工具栏（ToolBar），这在快速开发原型时非常方便。但在实际的商业项目中，设计师往往会给出天马行空的顶部导航设计，比如透明渐变背景、复杂的搜索框或者异形的返回按钮。

很多初学者会困惑：我是该用系统自带的，还是自己画？我的建议是按需定制。Navigation 和 NavDestination 都提供了 title、menus 和 toolBar 属性。如果设计风格符合系统规范，直接传入资源配置即可，系统会自动适配深色模式和折叠屏布局。但如果设计差异巨大，我们可以通过 .hideTitleBar(true) 彻底隐藏系统标题栏，然后在内容区域（Content）的顶部放置我们自定义的 NavBar 组件。

这里有一个细节需要注意，当我们隐藏了系统标题栏后，原本的滑动返回手势依然有效，但左上角的返回箭头没了。我们需要自己实现一个返回按钮，并调用 this.pageStack.pop() 来手动触发返回。这种灵活性让我们既能享受系统手势的便利，又能完全掌控视觉呈现。

import { promptAction } from '@kit.ArkUI';

// 1. 定义路由参数模型
interface ContactParams {
  id: string;
  name: string;
  phone: string;
}

@Entry
@Component
struct NavigationBestPracticePage {
  // 核心修正：使用 @Provide 而不是 @State
  // 这样后代组件 (DetailPage) 才能通过 @Consume 直接获取该对象
  @Provide('pageStack') pageStack: NavPathStack = new NavPathStack();

  // 模拟的首页数据
  @State contacts: ContactParams[] = [
    { id: '1', name: '张三', phone: '13800138000' },
    { id: '2', name: '李四', phone: '13900139000' },
    { id: '3', name: '王五', phone: '15000150000' }
  ];

  // -------------------------------------------------------
  // 路由工厂：根据路由名称动态构建页面
  // -------------------------------------------------------
  @Builder
  PagesMap(name: string, param: Object) {
    if (name === 'DetailPage') {
      // 跳转到详情页
      DetailPage({
        contactInfo: param as ContactParams
      })
    } else if (name === 'EditPage') {
      // 跳转到编辑页
      EditPage({
        contactInfo: param as ContactParams
      })
    }
  }

  build() {
    // 根容器：Navigation
    Navigation(this.pageStack) {
      // 首页内容区域
      Column() {
        Text('通讯录 (V2)')
          .fontSize(24)
          .fontWeight(FontWeight.Bold)
          .margin({ top: 20, bottom: 20 })
          .width('100%')
          .padding({ left: 16 })

        List() {
          ForEach(this.contacts, (item: ContactParams) => {
            ListItem() {
              Row() {
                // 这里使用系统图标模拟头像，实际请替换为 app.media.xxx
                Image($r('app.media.startIcon'))
                  .width(40)
                  .height(40)
                  .borderRadius(20)
                  .margin({ right: 12 })
                  .backgroundColor('#E0E0E0') // 兜底背景色

                Column() {
                  Text(item.name).fontSize(16).fontWeight(FontWeight.Medium)
                  Text(item.phone).fontSize(14).fontColor('#999')
                }
                .alignItems(HorizontalAlign.Start)
                .layoutWeight(1)

                // 跳转按钮
                Button('查看')
                  .fontSize(12)
                  .height(28)
                  .onClick(() => {
                    // 核心动作：压栈跳转
                    this.pageStack.pushPathByName('DetailPage', item, true);
                  })
              }
              .width('100%')
              .padding(12)
              .backgroundColor(Color.White)
              .borderRadius(12)
              .margin({ bottom: 8 })
            }
          })
        }
        .padding(16)
        .layoutWeight(1)
      }
      .width('100%')
      .height('100%')
      .backgroundColor('#F1F3F5')
    }
    // 绑定路由映射构建器
    .navDestination(this.PagesMap)
    // 首页的标题模式
    .titleMode(NavigationTitleMode.Mini)
    .hideTitleBar(true) // 首页隐藏系统标题栏，使用自定义内容
    .mode(NavigationMode.Stack) // 强制使用堆叠模式
  }
}

// -------------------------------------------------------
// 子页面 1：详情页 (使用 @Consume 获取 Stack)
// -------------------------------------------------------
@Component
struct DetailPage {
  // 接收参数
  contactInfo: ContactParams = { id: '', name: '', phone: '' };

  // 获取当前的路由栈 (对应父组件的 @Provide)
  @Consume('pageStack') pageStack: NavPathStack;

  build() {
    NavDestination() {
      Column({ space: 20 }) {
        Image($r('app.media.startIcon'))
          .width(80)
          .height(80)
          .borderRadius(40)
          .margin({ top: 40 })
          .backgroundColor('#E0E0E0')

        Text(this.contactInfo.name)
          .fontSize(24)
          .fontWeight(FontWeight.Bold)

        Text(this.contactInfo.phone)
          .fontSize(18)
          .fontColor('#666')

        Button('编辑资料')
          .width('80%')
          .margin({ top: 40 })
          .onClick(() => {
            // 继续压栈，跳转到编辑页
            this.pageStack.pushPathByName('EditPage', this.contactInfo);
          })
      }
      .width('100%')
      .height('100%')
    }
    .title('联系人详情') // 设置系统标题
  }
}

// -------------------------------------------------------
// 子页面 2：编辑页 (使用 onReady 获取 Stack)
// -------------------------------------------------------
@Component
struct EditPage {
  @State contactInfo: ContactParams = { id: '', name: '', phone: '' };
  @State newName: string = '';

  // 独立维护 Stack 引用，不依赖 @Consume，解耦性更好
  private stack: NavPathStack | null = null;

  aboutToAppear(): void {
    this.newName = this.contactInfo.name;
  }

  build() {
    NavDestination() {
      Column({ space: 16 }) {
        Text('修改姓名:')
          .fontSize(14)
          .fontColor('#666')
          .width('90%')
          .margin({ top: 20 })

        TextInput({ text: $$this.newName, placeholder: '请输入新名字' })
          .backgroundColor(Color.White)
          .width('90%')
          .height(50)
          .borderRadius(10)

        Button('保存并返回')
          .width('90%')
          .margin({ top: 20 })
          .onClick(() => {
            // 模拟保存操作
            if (this.stack) {
              this.stack.pop(true); // 出栈
              promptAction.showToast({ message: `保存成功: ${this.newName}` });
            }
          })
      }
      .width('100%')
      .height('100%')
      .backgroundColor('#F1F3F5')
    }
    .title('编辑')
    .onReady((context: NavDestinationContext) => {
      // 最佳实践：在 onReady 中获取当前页面的 stack
      // 这种方式不需要父组件必须使用 @Provide，适用性更广
      this.stack = context.pathStack;
    })
  }
}

五、 总结与实战

Navigation 组件配合 NavPathStack，标志着鸿蒙应用开发进入了 单窗口多组件（Single Window, Multi-Component） 的架构时代。它解决了 Router 时代的诸多顽疾，提供了更灵活的嵌套能力、更强大的路由栈控制以及更轻量的页面切换开销。

对于任何一个立志于构建专业级鸿蒙应用的开发者来说，尽早重构代码，迁移到 Navigation 架构，是提升应用质量的关键一步。

实时云渲染的Web端落地，核心挑战之一是“如何高效、低延迟地将云端渲染的视频流传输至浏览器并完成解码渲染”。因为用户需要的是即点即用，最好不安装任何软件，因此，选择浏览器作为终端载体是刚需。浏览器环境的兼容性限制、网络波动差异、低延迟要求，共同决定了协议选型的复杂性。本文将从技术底层拆解浏览器视频流解码各方案特点，通过多维度对比推导最优选型，并结合点量云流实时云渲染系统的实践经验，解析WebRTC在实时云渲染场景下为何被选中，以及点量云流在WebRTC等领域所做的深度优化方向。

一、Web端常见主流视频流解码方案

Web端视频流解码的核心目标是“在浏览器无插件依赖前提下，实现视频流的高效解码与流畅渲染”，笔者结合多年在视频解码领域的经验，梳理出当前主流的一些方案具体如下：

1、基于浏览器MSE实现：FLV-JS/MPEG-TS方案
MSE（Media Source Extensions）是浏览器提供的媒体扩展API，允许JavaScript动态构造媒体源并喂给原生媒体播放器。该类技术中比较知名的是bilibili开源的flv- js：https://github.com/bilibili/flv_js，该播放器同时支持点播和直播的数据流，类似的还有mpegtjs、video- js、hls- js等。

核心特点：兼容性中等，支持所有实现MSE标准的浏览器（Chrome、Firefox、Edge等新一些的主流浏览器均支持）；无需额外引入解码库，依赖浏览器原生硬解，CPU占用较低；延迟表现中等，常规场景下端到端延迟约1-3秒，通过优化切片大小可压缩至500ms左右，但受其传输和Video标签对视频缓存机制限制，难以突破300ms阈值。实测总延迟很难低于700ms。其短板在于依赖HTTP传输，面对网络波动时易出现卡顿。
特别需要注意的是：MSE在iOS下基本是不能被支持的，只能在部分iPad设备下使用，所以如果要考虑支持iPhone等移动设备，该技术有很大局限性。

主流浏览器下的支持情况如下：

2、纯JavaScript解码：JSMpeg方案
JSMpeg是纯JavaScript实现的轻量级视频解码器，核心原理是通过JavaScript直接解析MPEG-TS格式视频流，将解码后的像素数据绘制到Canvas画布上，音频数据则通过Web Audio API播放。该方案无需依赖浏览器原生解码能力，完全通过软件解码实现。JSMpeg可以通过Ajax加载静态视频，并允许通过WebSockets进行低延迟流式传输（约50毫秒）。

核心特点：因为纯基于JavaScript实现，兼容性极强，甚至支持低版本浏览器及部分嵌入式Web环境；方案轻量，无需额外部署转码服务，适合简单场景的轻量化集成。但短板极为突出：纯JS软解效率极低，CPU占用极高，在1080P画质下多数终端会出现明显卡顿，几乎不可能支持60fps视频的流畅播放；仅能支撑480P以下低画质场景；延迟表现较差，常规延迟2-5秒，且随着画质提升延迟显著增加；不支持硬件加速，无法适配实时云渲染的高画质、低延迟需求。

3、WASM解码方案
WASM（WebAssembly）是一种高性能的二进制指令格式，可将C/C++、Rust等高性能语言编写的解码逻辑编译为WASM模块，供JavaScript调用。该方案的核心是通过WASM提升解码计算效率，兼顾兼容性与性能。常见的有：https://github.com/sonyusquin/WasmVideoPlaye和https://github.com/goldwidco/h265player等。

核心特点：解码性能远超纯JS方案，接近原生应用水平，尤其在Rust编写的WASM模块中，复杂计算场景下耗时仅为原生JS的1/16左右；对视频格式兼容性友好是它的一个特长，因为它可灵活定制解码逻辑，适配特殊编码格式。但仍存在明显局限：需额外加载WASM解码模块，增加首屏加载时间；依赖WebSocket等协议传输视频流；虽性能提升显著，但较难利用系统GPU硬解，相比浏览器原生硬解仍有差距，高画质（4K/60fps）场景下CPU占用仍较高。并且由于缺少完善的重传、冗余等传输层机制的支持，所以经常遇到花屏现象发生。目前该方案多作为兼容性兜底方案，而非实时云渲染的主流选择。

其浏览器兼容性如下：

4、实时通信标准：WebRTC方案
WebRTC是浏览器原生支持的实时通信标准，提供音视频采集、编码、传输、解码的全链路API，核心基于UDP协议实现低延迟传输，支持点对点直连与媒体服务器转发两种模式。WebRTC在不同的浏览器在解码特性上略有差异，但大都是优先会GPU硬解，并直接在浏览器中高效显示。其核心优势在于将音视频传输与解码能力深度集成到浏览器内核，无需额外引入第三方库，可实现端到端的低延迟音视频交互。

核心特点：延迟极低，原生支持端到端延迟500ms以内，通过优化可压缩至100ms以下，甚至通过优化可做到10ms级的极低延迟；支持浏览器原生硬解，CPU占用远低于软解方案；内置网络自适应机制，可根据网络带宽动态调整码率与帧率，且可以支持P2P打洞、转发等技术；支持双向数据通道，可同步传输操作指令与视频流，完美匹配实时云渲染的交互需求。短板在于早期兼容性存在差异，尤其在部分低版本移动端浏览器中需适配，但目前主流浏览器已全面支持；此外，原生WebRTC的音视频编解码策略需针对云渲染场景优化，才能充分发挥性能。

主流浏览器对WebRTC的兼容支持情况如下：

5、新兴方案：WebTransport+WebCodecs
WebTransport基于QUIC协议，提供低延迟、可靠的网络传输能力，WebCodecs则是浏览器提供的原生编解码API，可直接操作音视频数据。两者结合的方案核心是通过WebTransport优化传输效率，WebCodecs提升编解码灵活性。

核心特点：传输延迟与WebRTC相当，甚至在部分场景下更优；编解码逻辑可深度定制，适配特殊画质与帧率需求。但目前兼容性极差，仅支持最新版本的Chrome浏览器，Safari、Firefox等浏览器暂不支持，暂时无法满足实时云渲染的全终端适配需求，仅适用于指定浏览器的特殊演示场景，暂不具备大规模商用价值。

二、实时云渲染场景的选型标尺

实时云渲染的核心需求是“低延迟交互（操作指令与画面同步）、高画质流畅渲染、全终端兼容、低资源占用”，结合各方案的技术特性，从6个关键维度构建对比体系，明确选型边界：

三、为何WebRTC是实时云渲染Web端的最优解？

结合上述对比与实时云渲染的核心需求，WebRTC成为最优选型，核心优势至少在三个关键层面：

1、低延迟传输：匹配实时交互的核心诉求
实时云渲染的核心痛点是“操作与画面不同步”——云游戏中100ms以上的延迟会导致操作脱节，云设计中延迟过高会影响创作连贯性，云VR/AR场景更是要求延迟低于20ms以避免眩晕感。WebRTC基于UDP协议传输，无需像TCP那样进行多次数据确认，从传输层大幅降低延迟；同时支持快速重传机制，在30%丢包率下仍可保持流畅传输，远超其他基于TCP的方案（FLV-JS、WASM+WebSocket）。实测数据显示，原生WebRTC的端到端延迟可稳定在100ms以内，笔者在实际案例中，经过场景优化后甚至能达到10-30ms的局域网级延迟，完全覆盖实时云渲染的延迟需求。

2、原生硬解+低资源占用：保障全终端流畅体验
实时云渲染需适配PC、手机、平板、VR头显等多终端，终端性能差异较大，低资源占用是保障全终端流畅的关键。WebRTC依赖浏览器原生硬解，相比JSMpeg纯软解和WASM软解，CPU占用降低60%以上，在低端手机上也能流畅支撑1080P/60fps的画质渲染；同时无需额外加载解码模块，首屏加载时间比WASM方案缩短80%，提升用户体验。

3、双向交互+网络自适应：适配复杂场景需求
实时云渲染不仅需要“视频流下行”，还需要“操作指令上行”（鼠标、键盘、触控、VR手柄指令等）。WebRTC原生支持DataChannel双向数据通道，可将操作指令与视频流同步传输，指令延迟与视频延迟保持一致，实现“操作即反馈”的体验；同时内置网络自适应机制，可实时检测带宽变化，动态调整码率与帧率——当网络带宽下降时，自动降低画质以保障流畅，带宽恢复后立即提升画质，完美适配复杂的公网环境。

4、兼容性与扩展性：支撑大规模商用落地
目前Chrome、Firefox、Edge、Safari等主流浏览器均已全面支持WebRTC标准，兼容性覆盖90%以上的终端设备，无需用户安装任何插件，可直接通过链接访问，大幅降低落地门槛。同时WebRTC支持自定义编解码参数与传输策略，可根据不同场景（云游戏、云设计、云VR）的需求进行深度优化，扩展性远超封闭的商业协议。

四、点量云流实时云渲染对WebRTC的场景化增强方案分析

原生WebRTC虽具备核心优势，但在实时云渲染的特定场景下仍存在优化空间——如复杂3D场景的编解码效率、弱网环境的画质保障、多终端适配差异等。点量云流作为国产主流实时云渲染厂商，基于WebRTC标准，结合实时云渲染场景需求，进行了全链路深度优化。以下将具体分析点量云流在该场景下是如何进一步适配与优化WebRTC的：

1、传输层优化：智能拥塞控制
点量云流一般会基于弱网的情况下，智能选最优传输策略，比如至少区分视频流与操作指令的传输优先级，确保操作指令优先传输。而针对云游戏、云VR等弱网容错需求，还会重点优化FEC（前向纠错）与重传协同机制，同时动态调整FEC冗余率（比如10%-50%自适应），平衡带宽开销与修复效果，在30%丢包率场景下仍能保障画面流畅度。
实测数据显示，经过优化后，公网环境下端到端延迟平均降低40%，北京到济南的跨地域端对端延迟稳定在30-50ms，局域网内延迟可控制在30ms以内。

2、编解码优化：自适应编码+画质增强
针对实时云渲染的3D画质特点，点量云流策略如下：一是实现编码零拷贝，避免GPU和CPU态的切换；二是自定义自适应编码器，替代WebRTC内置的编码器，可动态切换H.264/H.265，并在编码器配置上，针对云游戏等高速运动画面优化运动估计算法，针对云VR的沉浸式场景强化边缘画质处理；三是智能帧策略优化，一方面确保帧可以即点即开，另一方面，避免帧的不均衡，传输导致延迟峰值。
在优化前后，实测显示，在5Mbps的弱网环境下，仍可稳定传输4K/60fps的画质，较原生WebRTC的弱网适配能力有明显提升。

3、多终端适配兼容性优化：全场景兼容+交互同步优化
针对不同终端的浏览器差异，点量云流构建了WebRTC适配矩阵，通过动态降级策略——在支持WebRTC的主流浏览器上启用优化方案，在低版本浏览器上还保留有其它传输和解码方案，确保全终端覆盖，确保在常见浏览器上的兼容性。

五、总结与未来趋势

实时云渲染Web端的协议选型，核心是“匹配场景需求的技术平衡”。一方面要兼顾低延迟、复杂网络环境；另一方面要考虑浏览器兼容性。

在实践中，点量云流实时云渲染还提供了专门的客户端模式。该模式并未采用WebRTC，而是基于其自研的DLCA协议进行实现。这一选择是基于浏览器本身并非专为实时云渲染设计的考虑，通过自研客户端，能够在低延迟、交互性与实时性方面实现更深度的扩展与优化。据测试，DLCA模式在部分场景下相比WebRTC可降低约1帧的延迟，将端到端延迟进一步优化十几毫秒。当然，点量云流实时云渲染不止自研的DLCA协议这一个核心技术，还有许多技术支撑着实时云渲染系统的稳定运行。

未来，随着WebTransport与WebCodecs的兼容性逐步完善，它们有望成为WebRTC的重要补充，在特定高端场景中进一步提升传输与编解码效率。然而，就目前商用落地的实际需求而言，经过针对性场景优化的WebRTC，仍是实时云渲染Web端被广泛采用的主流技术方案。

作为深耕研发管理领域十余年的从业者，笔者常被问及如何筛选适配IPD（集成产品开发）流程的开源项目管理系统——既要实现“战略-研发-交付”全链路闭环，又要平衡成本控制、定制灵活性与团队适配性。开源工具凭借零授权费用、可二次开发的优势，成为中小企业及合规需求型企业的首选。本文精选8款主流开源IPD项目管理系统，含国产标杆禅道及多款全球热门产品，中立解析核心能力，为不同场景选型提供参考。

一、8款开源IPD项目管理系统核心解析

以下产品按“国产优先、功能适配性”排序，均排除商业化过重、非原生开源及敏感属性工具，每款产品聚焦3个核心功能模块，兼顾IPD流程关键节点需求，保持客观中立表述。

（一）禅道（ZenTao）

国产开源研发管理标杆，2009年推出，深耕IPD轻量化落地场景，支持本地、云部署及信创全适配，累计服务100万+团队，是软硬件协同开发及合规场景的优选工具。

• ​需求管理模块​：支持需求全生命周期追踪，含条目化管理、变更控制与评审流程，可生成跟踪矩阵，实现IPD需求阶段闭环。
• ​IPD流程固化模块​：内置华为标准IPD模板，覆盖概念-计划-开发-验证-发布全阶段，原生支持TR技术评审与DCP决策评审数字化流转。
• ​DevOps集成模块​：无缝对接Git、Jenkins等工具，内置自动化测试框架与流水线监控，实现研发与运维流程一体化。

（二）Redmine

全球普及度最高的开源项目管理工具之一，基于Rails框架构建，以高灵活性和丰富插件生态见长，适配敏捷、瀑布及混合IPD流程。

• ​自定义工作流模块​：支持按IPD场景配置审批节点与角色权限，可通过插件扩展阶段门管理能力，适配复杂流程定制需求。
• ​可视化规划模块​：内置甘特图、日历与进度追踪功能，支持多项目并行管理，直观呈现IPD各阶段资源分配与依赖关系。
• ​协作支撑模块​：集成Wiki与论坛功能，支持文档版本控制与团队留言互动，满足IPD跨部门协作的知识沉淀需求。

（三）OpenProject

被誉为“Redmine现代化替代品”，采用Web 2.0技术构建，界面直观，原生支持敏捷方法论，社区版与企业版分层适配不同规模IPD需求。

• ​敏捷协作模块​：内置Scrum看板与Kanban面板，支持冲刺规划与燃尽图生成，适配IPD快速迭代与任务流转需求。
• ​资源管理模块​：企业版支持资源分配、预算跟踪与多项目视图，可实现IPD跨项目资源统筹与冲突预警。
• ​文档协同模块​：支持文档在线编辑与版本追溯，可关联项目阶段与任务，形成IPD全流程文档闭环。

（四）Taiga

专注敏捷开发的开源工具，以简洁UI与原生敏捷支持为核心亮点，适合中小型团队的IPD敏捷化落地，集成Git版本控制系统实现开发协同。

• ​用户故事管理模块​：支持用户故事地图构建与优先级排序，可拆分迭代任务，适配IPD需求拆解与敏捷交付场景。
• ​冲刺跟踪模块​：自动生成燃尽图与迭代报告，实时展示任务完成进度，助力IPD迭代阶段目标管控。
• ​团队协作模块​：支持角色权限细分与任务评论互动，集成通知机制，确保IPD团队成员信息同步高效。

（五）Phabricator

由Facebook前工程师打造，以强大工作流引擎与代码审查能力为特色，适合技术驱动型团队的大规模IPD分布式协作。

• ​代码审查模块​：内置Diffusion代码管理组件，支持精细化代码评审与意见追踪，提升IPD开发阶段代码质量。
• ​工作流定制模块​：可构建任意复杂审批流程，支持多语言界面，适配大规模团队IPD跨区域协作需求。
• ​任务调度模块​：通过Maniphest组件实现任务分配、优先级管理与状态追踪，衔接IPD开发与测试环节。

（六）Odoo

模块化开源ERP系统，项目管理模块可与PLM、CRM等模块无缝集成，适合需全业务链路协同的IPD场景，尤其适配制造业研发管理。

• ​项目化管理模块​：支持按IPD项目维度统筹任务、资源与交付物，适配非标制造业个性化研发需求。
• ​PLM集成模块​：可管理产品图纸、BOM清单与设计变更，实现IPD研发与生产环节数据打通。
• ​自动化流程模块​：支持自定义审批流与触发器，可自动化IPD阶段评审与交付物校验流程。

（七）Tuleap

源自法国的开源研发管理平台，以合规性与规模化协作能力为核心，支持敏捷、瀑布与IPD混合流程，适配企业级需求。

• ​需求追溯模块​：支持需求与任务、测试用例双向追溯，满足IPD流程可追溯性与合规审计需求。
• ​测试管理模块​：内置测试用例管理与执行跟踪功能，可关联缺陷与需求，实现IPD验证阶段质量管控。
• ​多项目统筹模块​：支持项目集管理与战略对齐，可将企业目标拆解为IPD产品线任务，实现全链路管控。

（八）LeanTime

轻量级开源项目管理工具，以工时跟踪与效能分析为特色，适合预算有限、追求简洁性的小型团队IPD落地。

• ​工时管理模块​：支持任务工时记录与统计，生成工时报表，助力IPD成本核算与资源效率分析。
• ​里程碑管理模块​：可设置IPD关键里程碑与交付节点，触发节点通知，确保项目进度不偏离目标。
• ​简易看板模块​：提供可视化任务看板，支持拖拽式任务流转，适配小型团队IPD轻量化协作需求。

二、场景化选型建议

选型核心需匹配企业规模、IPD成熟度、技术能力与合规需求，以下为针对性建议：

1. ​中小型企业（10-50人）+ 信创需求​：优先选择​禅道​，开源版免费、信创全适配，内置IPD模板无需复杂配置，上手成本低。
2. ​技术驱动型团队 + 高度定制需求​：推荐Redmine或​Phabricator​，前者插件生态丰富，后者工作流与代码审查能力突出，适合技术团队自主定制IPD流程。
3. ​中大型企业 + 跨部门协作​：可选OpenProject企业版或​Odoo​，前者资源管理与可视化能力强，后者可实现IPD与ERP全链路集成。
4. ​敏捷化IPD团队 + 简洁需求​：优先Taiga或​LeanTime​，前者适配敏捷迭代，后者轻量高效，适合快速落地基础IPD流程。
5. ​合规型企业 + 规模化协作​：推荐​Tuleap​，需求追溯与合规适配能力突出，可支撑复杂IPD流程的审计与管控。

三、总结

开源IPD项目管理系统的核心价值的在于“灵活适配+成本可控”，8款产品各有侧重：禅道强在国产信创与IPD原生落地，Redmine胜在定制灵活性，OpenProject兼顾现代化体验与企业级需求，Phabricator适配技术团队深度协作。选型时无需追求“功能最全”，需结合自身IPD成熟度、团队技术能力与合规要求，优先选择“易落地、可扩展”的工具，必要时通过二次开发或插件扩展适配全流程需求。未来，开源IPD工具将持续向AI赋能、生态集成方向迭代，进一步降低企业IPD落地门槛。

开发者朋友们大家好：

这里是 「RTE 开发者日报」 ，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@瓒an、@鲍勃

01 有话题的技术

1、无界方舟 AutoArk-AI 发布 GPA 语音大模型：0.3B 轻量化架构实现 ASR/TTS/VC 统一建模

在克隆参考音频样本的音色的同时，从文本合成语音。

无界方舟 AutoArk-AI 正式推出通用音频模型「GPA」。该模型基于统一的自回归 Transformer 架构，在单一的大语言模型框架下，集成了语音识别（ASR）、语音合成（TTS）和语音转换（VC）三大核心任务。

该模型的设计初衷在于改变传统语音系统碎片化的 Pipeline 设计模式。通过 0.3B 的轻量化参数量级，GPA 旨在实现端侧的高效部署以及跨任务的泛化能力。

在技术架构上，GPA 放弃了任务特定的输出头，转而采用统一的离散音频 Token 空间。这一设计将理解、生成与编辑任务收敛至单一自回归模型中，从而减少了跨任务处理过程中的性能损耗。

交互方式上，模型采用指令驱动机制，通过文本指令来引导任务行为。它支持零样本语音克隆，用户无需调整架构或进行针对性微调，即可在 ASR、TTS 和 VC 之间进行动态切换。

针对边缘计算场景，官方提供了优化的 0.3B 参数版本。该版本兼容性广泛，支持 vLLM、llama.cpp、SGLang、MLX-LM 以及端侧硬件框架 RKNN。

在流式推理的延迟指标方面，测试数据显示：在 TTS 任务中，单并发平均 TTFC（首包延迟）为 258.8ms，RTF（实时率）为 0.197；在 ASR 任务中，单并发平均 TTFT（首 Token 延迟）为 157.5ms，能够支持高并发吞吐场景。

在性能对标测试中，针对中文 SEED 数据集的 TTS 零样本测试显示，GPA-0.3B 的 CER（字符错误率）为 0.95%。数据显示，该成绩优于同参数量级的 F5-TTS 模型。

目前，该模型的代码已开源，相关论文与 Demo 即将上线。使用许可方面，模型目前仅供学术研究与个人教育使用。

GitHub:
https://github.com/AutoArk/GPA

( @GitHub)

2、ElevenLabs 洽谈新一轮融资：估值或达 110 亿美元，有望成英国最有价值 AI 初创公司

据英国《金融时报》报道，AI 语音生成公司 ElevenLabs 正洽谈新一轮融资，计划从投资者处募集数亿美元资金。若交易达成，其估值或将在数月内翻倍至 110 亿美元。

这一跃升将使 ElevenLabs 超越估值约 80 亿美元的自动驾驶公司 Wayve，成为英国最有价值的人工智能初创公司；同时，也将使其跻身欧洲顶尖行列，逼近法国 AI 模型公司 Mistral 约 120 亿美元的估值水平。

此次融资谈判距离公司上一次二级股份出售仅过去四个月，当时的估值为 66 亿美元。据悉，目前的会谈仍处于早期阶段，具体情况可能存在变数。

ElevenLabs 于 2022 年由波兰企业家 Mati Staniszewski 和 Piotr Dabkowski 在伦敦创立，目前已获得红杉资本（Sequoia）、Iconiq、Andreessen Horowitz、NEA 及 FT Ventures 等多家知名风投机构的支持。为了便于获取美国资本，公司已在美国注册，并在伦敦和纽约设有双总部。

在业务层面，ElevenLabs 专注于利用 AI 生成逼真的语音，广泛应用于客服、文本转语音及多语言配音等场景。公司业绩增长迅猛，去年年度经常性收入（ARR）已达到 3.3 亿美元，较 9 月份公布的 2 亿美元有显著提升。

宏观来看，尽管全球投资者对 AI 初创企业的兴趣持续高涨，但欧洲公司在募资规模上仍滞后于美国。作为对比，美国巨头 OpenAI 据传估值已达 5000 亿美元，并正商谈最高达 800 亿美元的新一轮融资，投后估值可能突破 8000 亿美元。

( @Benchmark Studio)

3、红杉资本「覆盖赛道」押注 Anthropic，新一轮融资目标约 250 亿美元，预计最快今年 IPO

据《金融时报》报道，红杉资本计划加入对 AI 初创公司 Anthropic 的新一轮重磅融资。此举打破了风险投资界通常避免在同一领域支持竞争对手的传统惯例，因为红杉此前已同时投资了 OpenAI 和埃隆·马斯克的 xAI。

本轮融资由新加坡政府投资公司（GIC）和美国投资机构科图（Coatue）领投。 据报道，两家机构各出资 150 亿美元。Anthropic 计划以 3500 亿美元的估值筹集 250 亿美元或更高资金，这一估值较四个月前的 1700 亿美元已翻了一番以上。此外，微软和英伟达据称已承诺共同出资最高 1500 亿美元。

红杉此次的投资时机颇受外界关注。OpenAI CEO 萨姆·奥尔特曼此前曾明确表示，虽然不禁止投资者投资竞品，但若投资者对竞争对手进行「非被动投资」，其接触 OpenAI 机密信息的权限将被终止。

尽管面临潜在的利益冲突，红杉仍选择进一步深化在 AI 领域的布局。 此前，红杉不仅支持了奥尔特曼创立的 Loopt 和其引荐的 Stripe，也通过投资 xAI、X、SpaceX 及 Neuralink 等公司与马斯克建立了广泛联系。

这一策略转变发生在该机构经历戏剧性的管理层变动之后。近期，红杉全球掌门人罗洛夫·博塔（Roelof Botha）离职，由林君睿（Alfred Lin）和帕特·格拉迪（Pat Grady）接手。这种多点押注的策略，与 2020 年红杉因利益冲突而放弃 Finix（Stripe 竞对）投资的历史立场形成了鲜明对比。

此外，报道还透露，Anthropic 正在积极筹备首次公开募股（IPO），最快可能在今年年内进行。

( @Z Potentials、@TechCrunch)

4、NVIDIA 发布 PersonaPlex：基于 Moshi 架构的 7B 全双工对话模型，支持混合 Prompt 定制

NVIDIA ADLR 团队近日正式发布了 PersonaPlex，这是一个参数量为 7B 的原生全双工语音对话模型。该模型通过摒弃传统的 ASR→LLM→TTS 级联架构，实现了超低延迟的实时语音交互，并着重解决了全双工模型在角色与音色自定义方面的局限性。

在架构设计上，PersonaPlex 基于 Kyutai 的 Moshi 架构及 Helium 语言模型构建，并采用了 24kHz 采样率的 Mimi 神经音频编解码器。该架构支持模型同时处理音频输入流与输出流，从而具备了实时打断、背向渠道（Backchanneling，如「嗯」、「噢」）以及自然的轮替节奏等全双工特性。

为了提升定制化能力，模型引入了混合提示机制。 该机制包含双路输入控制：通过音频嵌入提取参考音频的声学特征，以控制发音风格与韵律；同时利用文本指令来定义角色的设定、背景知识及交互逻辑。

在训练数据方面，团队采用了脱耦与融合策略。模型使用了 1,217 小时的 Fisher English 真实对话语料来学习打断、情绪反馈等交互行为，并结合了约 2,250 小时由 Qwen3-32B 和 Chatterbox TTS 生成的合成数据，以强化指令遵循能力。

评测结果显示，在 FullDuplexBench 及新增的 ServiceDuplexBench 测试中，PersonaPlex 在顺滑轮替和暂停处理等指标上优于 Gemini 2.0 Flash Live 等商业模型。此外，在未见过的极端场景（如太空紧急状况响应）中，模型也展现出了技术推理与情绪同步能力。

目前，该项目的代码采用 MIT 开源协议，模型权重则采用 NVIDIA Open Model License 协议。相关的测试集 ServiceDuplexBench 也将于近期开放。

HuggingFace:

https://huggingface.co/nvidia/personaplex-7b-v1

( @NVIDIA ADLR Blog)

02有亮点的产品

1、飞书发布首款硬件「AI 录音豆」：联手安克创新，争夺更近的上下文入口

据「智能涌现」报道，飞书联合安克创新发布首款智能硬件产品「AI 录音豆」，这也是飞书自 2017 年成立以来的首次硬件尝试。该产品被定义为飞书内部的探索性项目，由飞书团队负责软件部分的研发。

在此次合作中，飞书团队主要负责软件层面的研发。该设备通过极轻量化的设计捕捉物理场景语音，并结合豆包大模型，旨在实现办公上下文的自动化沉淀与结构化处理。

在硬件形态上，AI 录音豆单体重量仅为 10g，含充电仓总重 48g，内部搭载了双 MEMS 麦克风阵列。产品采用了豆状设计，支持背夹或磁吸佩戴。这一设计旨在降低录音过程中的仪式感，以便更好地覆盖通勤、拜访等碎片化使用场景。

在续航与存储配置方面，配合充电舱使用，该设备可提供 32 小时的总续航时间，并支持快充技术，充电 10 分钟即可录音 2 小时。机身内置 8GB 存储空间，可存储约 250 小时音频，并支持蓝牙与 Wi-Fi 双模式传输。

核心功能方面，设备内置了豆包大模型，支持实时多模态纪要。具体能力涵盖发言人识别、待办事项自动提取以及柱状图等图例的可视化生成，用户可在录音过程中实时查看 AI 总结。

此外，该产品实现了与飞书生态的闭环打通。录音内容会自动沉淀至飞书知识库，用户随后可通过 AI 助手，以自然语言交互的方式对历史音频记录进行语义检索、提问及二次创作。

目前，该产品被定位为飞书内部的探索性项目，具体定价及正式发售日期暂未披露。

（@36 氪）

2、银河通用发布重载机器人 Galbot S1：50kg 双臂负载突破瓶颈，零遥操切入核心产线

「银河通用」正式发布工业级具身智能重载机器人「Galbot S1」。该机器人实现了 50kg 的双臂持续作业负载，并搭载全自主、零遥操的「具身搬运模型」。目前，产品已成功进入宁德时代等头部企业的核心产线，承担重型物料搬运及部件装配任务。

在负载能力上，Galbot S1 实现了显著突破。它拥有 50kg 的双臂持续负载能力，不仅对标人力搬运的极限，更突破了具身智能机器人普遍低于 10kg 的负载瓶颈，有效填补了轻型协作机器人与大型固定吊装设备之间的重载作业空白。

技术层面，该机器人采用了全自主的具身搬运模型。基于纯视觉感知方案，Galbot S1 无需依赖二维码或反光板等外部标记，即可支持动态光照、局部遮挡及人机混行等复杂工况，实现了零遥操下的端到端作业。

针对工业环境的适配性，整机具备 IP54 防水防尘等级，作业高度覆盖 0 至 2.3 米区间，能够适配从地面物料到高位货架的全场景搬运需求。

在续航与安全性方面，Galbot S1 支持 8 小时单次续航及自主换电功能，可实现 7×24 小时连续运转。同时，系统配备了毫秒级安全响应机制与 360° 全向避障能力，确保作业安全。

此外，银河通用通过在宁德时代、博世、丰田等真实产线的长期运行，构建了场景数据闭环，持续强化具身智能大脑在严苛节拍下的稳定性。

目前，公司已完成 21 亿元融资，估值突破 200 亿元，正积极推进千台级的工业部署。

（@量子位）

3、全球首个全年龄段覆盖，京东京造第二批 AI 玩具上线

近日，京东京造正式宣布上线第二批自研 AI 玩具。此次发布的新品在此前针对儿童开发的陪伴玩具基础上，进一步推出了面向年轻人及老年群体的 AI 玩具，实现了全球首个全年龄段用户需求的覆盖。

京东 JoyInside 为硬件注入了「长期记忆」与「情境感知」能力，能够理解对话的上下文，也成为首个根据不同年龄段用户的偏好与习惯进行优化的系统平台。

这项能力被深度应用于不同年龄层的需求设计中：系统能识别婴幼儿的哭声并给予安抚，为儿童提供启蒙引导并识别潜在风险，与年轻人进行有深度的主题聊天，也能用方言陪伴老年人，并关注他们的健康与社交需求。

回顾市场表现，首批 AI 玩具上市后，被用户视为「游戏搭子」、「情绪树洞」及「知识导师」，在帮助儿童减少电子屏幕依赖方面发挥了作用。数据显示，接入 JoyInside 的智能硬件平均对话轮次提升超过 120%，多款产品上线即售罄，且保持了极低的退货率。

截至目前，京东 JoyInside 已携手超过 40 家硬件品牌，涵盖 AI 玩具、机器人等品类。

（@IT 之家、@京东黑板报）

03有态度的观点

1、DeepMind CEO：AGI 5-10 年内实现

日前，Google DeepMind CEO Demis Hassabis 接受了 CNBC 的节目采访，与主持人共同讨论了缩放定律的重要性以及发展通用人工智能（AGI）的持续追求。

Demis 表示，自己依然认为 5 到 10 年内 AGI 能得以实现。

其指出，包括 AI 在内的 AGI 将涉及 LLMs 和世界模型的组合，而不是一个组件取代另一个组件。

Demis 认为，AI 可能需要更好的推理、长期规划和 「世界模型」 的概念，以更好地理解物理学并进行模拟，反映人类科学家的工作。其也强调，除了世界模型之外，AGI 可能还需要其他类型的技术和能力。

同时他也表示，为了使 AI 在科学能力方面取得进步，它需要能够提出新的假设和想法，而不仅仅是解决现有的猜测。

( @APPSO)

04社区黑板报

招聘、项目分享、求助……任何你想和社区分享的信息，请联系我们投稿。（加微信 creators2022，备注「社区黑板报」）

1、招聘 AI Agent 开发工程师

22-35K·13 薪深圳 5-10 年 本科

岗位职责：

1. 负责 AIAgent 系统的架构设计与工程实现，包括智能体的任务规划、决策逻辑、工具调用以及记忆管理等核心模块。
2. 深入集成与优化大语言模型（LLM），通过提示工程、微调等技术路径，持续提升 AI 助手的对话质量、逻辑推理能力及任务执行准确性。
3. 为 AI 助手连接并管理各类外部工具与 API（如搜索、数据库、第三方服务），构建其实际解决问题的能力，同时确保执行过程的安全与可控。
4. 建立针对 AI 助手性能的评估、监控与迭代闭环，通过数据分析驱动产品体验的持续优化。5.编写高质量、可维护的代码，并将 AIAgent 系统部署至生产环境，保障其高可用性与低延迟。

任职要求：

1. 计算机科学、软件工程或相关专业本科及以上学历，具备 3 年以上后端或 1 年以上 AI 应用开发经验。
2. 熟悉 PyTorch、TensorFlow 等主流深度学习框架，具备扎实的工程能力和良好的编码习惯。
3. 对大语言模型及 AIAgent 技术栈有深入理解和实际项目经验。
4. 拥有强烈的产品意识和用户同理心，关注技术落地对用户体验的实际影响，具备优秀的数据分析能力和问题解决技能。
5. 有成功的 ToC 互联网产品或 AI 产品（如智能助手、对话机器人）开发及上线经验者优先。

联系人：李先生

联系方式：26905841@qq.com

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示：个人观点，仅供参考

‍当我们审视人工智能的进化脉络时，一场颠覆性的智能变革正深刻重塑行业格局：人工智能正从执行特定指令的工具，蜕变成为能够理解复杂意图、规划执行路径并自主解决问题的自主智能体。

这一转变的关键动力，一方面来自大语言模型所提供的通用推理能力与广泛知识积累，另一方面也离不开高质量数据对模型性能的基础支撑。

曼孚科技作为一家从数据出发，以数据标注和数据管理为核心的 AI 平台型企业，致力于打造全球规模最大的数据处理平台与业界领先的端到端AI平台，通过一站式满足数据、算力、工具、管理、训练及推理等AI全链路需求，为大语言模型驱动的自主智能体发展奠定坚实基础。

这种依托大语言模型构建、由高质量数据赋能的智能体新形态，不仅重塑了人机协作的边界，更在本质上拓展了机器智能的疆域。

一、从 “工具” 到 “伙伴”

传统人工智能系统大多遵循 “输入 - 处理 - 输出” 的运作逻辑，无论是图像识别、机器翻译还是推荐系统，均在封闭的输入空间内执行预定义任务。这些系统缺乏对任务上下文的整体把控，更无法在动态环境中自主调整策略。

大语言模型驱动的智能体则呈现出全然不同的智能形态：它们具备任务理解、自主规划与动态调整的综合能力。

这种能力的基础，源于大语言模型已从 “文本预测器” 到 “世界模型”的进化，而支撑这一进化的核心前提，是海量高质量标注数据的训练与打磨。

通过标准化、精细化的数据标注与管理，模型不仅掌握了语言规则，更内化了关于世界运行规律的丰富知识。当这些知识与环境反馈相结合，智能体便能展现出令人惊讶的环境适应性。

在这一智能形态下，智能体的核心不再是单一算法模型，而是由感知、认知、决策、执行等多个模块构成的协同系统。

大语言模型充当系统的 “认知内核”，负责解读任务意图、分解复杂目标、制定行动策略并评估执行效果；外围模块则承担环境交互、反馈获取、工具调用与记忆存储的功能，形成完整的感知 - 行动闭环。

这种架构让智能体能够应对开放世界的复杂任务。例如，当被要求 “分析公司上个季度的销售数据并准备汇报 PPT” 时，传统 AI 需要多个独立系统协同完成 —— 数据分析工具、文档生成系统、演示软件等，且每个环节都依赖人工衔接。

而 LLM 驱动的智能体可自主规划完整流程：检索数据库获取销售数据，调用分析工具开展统计处理，基于分析结果生成文字总结，最终调用 PPT 生成模块创建演示文稿。整个过程中，智能体根据各步骤执行结果动态调整后续计划，展现出强大的任务管理能力。

而这一切能力的落地，离不开底层高质量数据的支撑。

曼孚科技深耕数据标注与管理领域，构建了一套覆盖项目全生命周期的内部质量管理体系，为大语言模型与自主智能体的训练提供了可靠的数据保障。

从新成员准入的严格筛选—→现有人员的常态化质量监督—→新场景新需求的规则培训与磨合，曼孚科技通过多轮数据质量检查、驳回修改的闭环流程，确保交付给客户的数据完全满足质量要求。

在标注人员培养层面，曼孚科技建立了系统化的培养体系：

1、针对所有标注人员开展全面的入职培训，内容涵盖标注平台使用方法、标注项目常见类型、标注质量要求等核心模块，帮助标注人员建立清晰的工作认知。

2、结合标注人员的水平差异与经验积累，制定分阶段、分层次的培训计划，精准匹配不同标注项目的需求。

3、创新性设立标注员培训师岗位，通过在线培训、面对面指导、视频教程等多元方式开展教学，并在项目启动前增加专项培训，助力标注员深度理解项目需求。

此外，曼孚科技高度重视培训效果评估，通过常态化测试与考核，及时发现标注人员的能力短板，给予针对性指导支持。

为了从机制上保障标注质量，曼孚科技搭建了全流程的标注质量管理机制：

1、通过随机抽取标注结果进行质量检查，确保标注数据的准确性与一致性，对发现的错误或低质量标注及时反馈指导，对严重违反规则的行为落实相应处罚。

2、建立以标注准确率、效率、工作态度为核心维度的绩效考核机制，以正向激励推动标注质量与效率双提升。

3、定期组织标注员培训，持续强化标注规则、工具使用与质量管理机制的认知；同时定期评估标注规则与数据集，及时调整更新不合理内容，保障标注质量的稳定性与可靠性。

在标注过程监督环节，曼孚科技更是构建了多维度的管控体系：

1、设立随机检查机制，抽取部分已标注数据进行核验，检查结果直接作为人员评估与培训的依据。

2、建立快速纠错机制，一旦发现标注错误立即修正，避免错误数据对后续模型训练与应用产生负面影响。

3、搭建实时反馈机制，帮助标注人员及时掌握自身工作质量，持续优化标注行为。

4、加强团队内部沟通协调，及时解决标注人员遇到的问题困难，避免因误解偏差影响标注质量一致性。

5、通过定期评估标注流程、引入自动化标注工具与算法、加入脚本及算法质检流程等方式，不断优化标注流程，减轻标注员工作负担，提升标注效率与准确性。

6、通过改善工作环境、完善奖励措施等途径，全方位提升标注员的工作效率与质量。

二、智能体系统的核心组件

构建真正的 LLM 驱动智能体，需要一系列精心设计的组件协同运作，形成有机的认知 - 行动系统。

认知框架：从语言理解到任务规划

大语言模型作为认知核心，其能力已远超语言生成本身。借助思维链提示、自我反思与程序辅助推理等技术，LLM 能够将复杂问题拆解为逻辑步骤，逐步推演解决方案。

例如，面对 “帮助用户规划一次北京三日游” 这样的开放式任务时，智能体会先开展需求分析（明确预算、兴趣偏好、时间限制），再将任务分解为交通安排、住宿预订、景点选择等子目标，最终生成详细的日程计划。

更先进的智能体系统引入多专家协作框架，将单一 LLM 扩展为多个具备不同专长的 “认知专家”：有的擅长逻辑推理，有的专攻创意生成，还有的专注事实核查。

它们通过内部 “讨论机制” 协同决策，这一架构显著提升了智能体处理复杂多维度任务的能力。

记忆系统：从短时交互到持续学习

与传统对话系统仅维持短暂对话历史不同，现代智能体具备完善的多层记忆架构：

1、短期记忆：留存当前对话与任务的上下文信息。

2、长期记忆：以向量数据库或知识图谱形式，存储智能体长期运行中积累的经验、用户偏好及领域知识。

3、外部记忆：连接数据库、知识库与互联网，提供实时、准确的外部信息支撑。

记忆系统不仅承担信息存储功能，更支持复杂的记忆检索与关联推理。当智能体面对新任务时，可从长期记忆中检索相似案例、借鉴历史经验。

同时，持续将新获取的知识结构化存储，实现能力的持续迭代。这种记忆能力让智能体能够构建个性化用户模型，提供更精准的服务。

工具使用：从单一模型到能力扩展

纯粹的 LLM 存在明显能力边界 —— 无法获取实时信息、难以执行具体操作、精准计算能力薄弱。工具使用能力使智能体突破自身限制，将语言理解转化为实际行动。

智能体的工具集可涵盖：

1、信息工具：搜索引擎、数据库查询、API 调用。

2、操作工具：代码解释器、软件控制接口、机器人指令集。

3、专业工具：数学计算器、设计软件、专业分析平台。

智能体学习 “何时、如何选用何种工具” 的过程，被称为工具学习。

通过少量示例演示或强化学习，智能体能够根据任务需求自动选择适配工具，并以正确格式提供输入参数。

例如，需计算复杂统计指标时，会自动调用 Python 代码解释器而非尝试自主计算；需获取最新股票信息时，会调用金融数据 API 而非依赖训练数据中的陈旧信息。

行动策略：从确定性执行到适应性探索

在动态、不确定的环境中，智能体需根据环境反馈实时调整行动策略。这涉及强化学习与语言模型的多层次融合：

1、探索与利用的平衡：在已知有效策略与尝试创新方法之间找到平衡点，尤其面对未知环境时

2、分层强化学习：高层策略由 LLM 负责，处理抽象目标分解与计划制定；低层策略由专用控制器负责，处理具体动作执行

3、自我反思与修正：任务执行过程中持续评估进展，检测到目标偏离或障碍时，主动调整计划甚至重新规划整体任务

行动策略的优化，让智能体能够应对现实世界中充满变数的任务。

例如，自动化测试智能体发现某个按钮无法点击时，会尝试替代方案（如使用键盘快捷键或寻找其他入口），而非僵化等待按钮变为可用状态。

值得注意的是，大语言模型与自主智能体的产业化落地，往往面临垂类标注项目 “短频快” 的交付节奏挑战，而曼孚科技凭借成熟的风险管控体系，为项目平稳交付提供了坚实保障。

曼孚科技针对这类项目的核心风险控制目标明确：在保证数据质量和合规安全的前提下，通过流程优化与技术赋能，将项目的不确定性降至最低，实现稳定、可预测的交付输出。

实现这一目标的关键，在于曼孚科技创新性地将 “人的经验” 和 “规则的标准” 沉淀到 “系统的流程” 与 “智能的工具” 之中。

通过构建 “人机协同标注” 模式提升效率基线，依靠 “三角专业团队” 和 “闭环质量管理” 双轮驱动控制质量波动，并始终将合规安全作为不可逾越的红线。

这套风险管控体系，不仅解决了垂类标注项目的交付痛点，更为大语言模型驱动的自主智能体在各行业的规模化应用，扫清了数据层面的障碍。

三、大模型的“成长烦恼”

尽管 LLM 驱动的智能体展现出巨大潜力，但要实现稳定可靠的自主智能，仍需攻克一系列重大技术难题。

幻觉与事实一致性问题

作为基于统计规律的语言模型，LLM 本质上是生成 “看似合理” 的文本，而非必然 “真实准确” 的答案。这导致智能体在任务规划或信息提供时，可能产生逻辑自洽但与事实不符的建议。

例如，规划旅行路线时，可能推荐不存在的交通方式或已关闭的景点。

解决这一问题需多维度协同：通过检索增强生成确保决策基于最新准确信息；建立自我验证机制，让智能体行动前核查计划可行性；优化不确定性校准，使智能体能够识别并表达对自身建议的信心程度。

前沿研究正探索符号推理与神经网络的融合，为智能体构建可验证的逻辑基础。而这一过程中，高质量的标注数据与严谨的质量管理体系，正是减少模型幻觉、提升事实一致性的核心前提 —— 这也正是曼孚科技的核心优势所在。

长期任务规划与执行一致性

人类能够围绕长期目标保持行动一致性，即便中途遭遇干扰或需调整计划。当前智能体在维持长期一致性方面仍存在短板，易在复杂任务中 “迷失方向” 或陷入执行循环。

应对这一挑战的前沿方向包括：

1、目标导向的层次记忆：构建从具体行动到抽象目标的多层关联，确保每一步执行都服务于最终目标

2、进展监控与里程碑管理：将大型任务分解为明确的里程碑，持续跟踪进展并适时调整策略

3、注意力机制优化：通过改进的注意力架构，让智能体在长时间跨度内保持对关键信息的聚焦

多模态情境理解与交互

真实世界任务往往涉及多种信息模态 —— 文本、图像、声音、界面状态等。智能体需具备真正的多模态理解能力，才能全面掌控环境状态。

最新的多模态大模型正推动这一领域突破。

例如，能够同时处理图像描述、文本指令与界面元素的智能体，可更精准地理解用户需求与环境限制。

当用户指着屏幕说 “把这个部分做得更突出些” 时，智能体需同时解读语言指令、视觉参照与界面编辑的可能性，这要求实现跨模态表征的深度融合学习。

而多模态数据的高质量标注，正是这类模型训练的关键支撑，曼孚科技的全流程数据管理能力，能够为多模态智能体的研发提供定制化的数据解决方案。

效率与可扩展性瓶颈

基于大型基础模型的智能体，面临显著的计算成本与响应延迟挑战。同时处理复杂规划、工具调用与环境交互，需要大量模型推理资源，在实时应用场景中可能难以适配。

解决效率瓶颈的创新方向包括：

1、模型专业化与分工：训练专用小型模型处理常规任务，仅将复杂问题交由大模型处理

2、预测与缓存机制：预判用户潜在需求并提前准备响应，降低实时计算压力

3、边缘 - 云协同架构：在边缘设备部署轻量级推理模块，复杂分析任务保留在云端执行

而曼孚科技打造的端到端 AI 平台，通过一站式整合数据、算力、工具等资源，能够有效优化模型训练与推理流程，帮助企业降低智能体研发与部署的成本，提升整体效率。

四、从“被动响应”到“主动协作”

LLM 驱动智能体的未来发展，将循着从简单到复杂、从被动响应到主动协作、从单一运作到协同联动的路径持续演进。这一演进过程，将重新定义人类与数字系统的互动模式。

下一代智能体将不再局限于等待明确指令，而是能够解读用户的高层次目标，主动提出实施方案并寻求确认。

它们将具备更强的上下文感知能力，精准把握任务背景、约束条件与优先级，成为真正意义上的智能协作伙伴。

例如，当用户提出 “我们需要提高下季度的客户满意度” 时，智能体不仅会制定调研计划，还会主动建议改进措施并跟踪实施效果。

在通用能力方面，未来的智能体将突破单一应用或领域的限制，发展出通用的界面理解与操作能力。借助统一的环境表征学习与迁移学习方法，智能体可快速适配新软件界面、操作流程与领域知识，实现真正的通用智能。

这种能力将让智能体能够在整个数字生态中灵活 “穿梭”，完成涉及多平台、多工具的复杂工作流。而以全球最大数据处理平台为最终目标的曼孚科技，将不断为这类通用智能体提供覆盖多领域、多场景的高质量数据支撑。

可以说，LLM 驱动的智能体新形态，标志着人工智能正从 “模式识别” 时代迈向 “自主决策与行动” 时代。这一转变不仅是技术层面的突破，更是对智能本质的重新审视。

当机器能够解读复杂指令、制定合理计划并在动态环境中持续推进任务时，一种全新的智能形态已悄然形成。

而以曼孚科技为代表的 AI 平台型企业，正通过高质量的数据标注、全流程的质量管理与创新的风险管控体系，为这一智能形态的发展注入核心动力。

这种智能形态的发展，最终将助力我们构建出真正理解人类需求、尊重人类意图、增强人类能力的智能伙伴，开启人机协作的全新篇章。

一句话就能分析数据？担心自己零基础，跟不上训练营节奏？别急！「瑶池 Data Agent 入门训练营」 第1节先导课来了！
Data Agent 是一款基于大模型的企业数据智能助手，提供免费版、个人版和企业版三种版本，分别满足个人用户的基础使用、进阶需求及企业的多用户协作、安全管控与独立部署等场景，支持通过自然语言对话完成数据查询、分析与处理，无需编写代码，助力各岗位用户高效实现数据驱动决策。这节课我们不讲复杂操作，只做一件事：帮你彻底搞懂 Data Agent 是什么、能帮你做什么。无论你是业务人员、管理者还是技术小白，都能在这里找到属于你的数据驱动起点。

一、参营入口

点此报名参营，用 Data Agent 为你的业务按下加速键！

二、参营时间

2026年1月21日-1月29日 （每个工作日下午17:00-17:30）

三、第一节课程介绍

四、超值奖励

• 结营证书：完成所有任务即可获得阿里云官方训练营电子结营证书；
• 结营奖励：课后作业总分（满分100分）排名前100名者获奖，相同分数按提交时间先后排序，即可领取棒球帽/无线鼠标/公仔/鼠标垫（随机发其一）；
• 优秀学员奖：选取5名完成全部任务和作业的优秀学员，加赠德尔玛加湿器！获奖名单会于结营后的7个工作日内在活动钉群内公布；
• 钉群互动奖：交流群内不定时举办有奖问答及抽奖活动，赢卡套、帽子等精美好礼！
  

五、如何参营

本次训练营所有课程内容将采取钉群线上直播方式，课程结束后每小节课后作业均在钉钉交流群内获取提交，这是你获得证书和奖品双重奖励的唯一通道。

六、参考资料

1. Data Agent 帮助文档：https://help.aliyun.com/zh/dms/data-agent-for-analytics/
2. Data Agent 版本介绍：https://help.aliyun.com/zh/dms/data-agent-version-introduction
3. 阿里云瑶池Data Agent 荣获 InfoQ 2025 年度 “Data & AI最具价值产品奖”https://mp.weixin.qq.com/s/SdNeTFh8pxZ_Yf8hjjCTxg