当 “数字中国”战略迈入深水区，数据治理平台不再是单纯满足监管要求的辅助工具，而是成为企业数字化转型的核心引擎，撬动业务增长的关键资产。Gartner近日发布的《2026年数据与分析治理平台魔力象限》报告指出，生成式AI的爆发式应用正以前所未有的力量重塑数据治理市场。传统的、以人工操作为主的治理模式难以为继，市场正迅速转向由AI智能体和主动元数据驱动的智能、自动化治理。到2027年，60%的数据治理团队将优先治理非结构化数据，以交付GenAI应用并提升决策质量。IDC最新预测显示，2026年中国数据治理平台市场规模将冲破860亿元大关，年复合增长率维持在29.7%的高位，行业发展潜力巨大。
行业三大核心趋势，定义治理新方向
当前数据治理行业的演进路径清晰明确，三大趋势成为发展主流：
• 智能升级提速：AI技术全面渗透治理全流程，自然语言处理与机器学习能力实现数据质量自动监控、异常智能修复，让非技术人员也能轻松操作，大幅降低应用门槛；
• 信创适配深化：国产软硬件生态在关键行业加速落地，信创适配从 “可选” 变为 “必选”，本土厂商凭借对国内政策、行业场景的深刻理解，以及快速响应的服务能力，逐渐占据市场主导地位；
• 资产价值凸显：数据治理从 “管理导向” 转向 “资产导向”，治理平台不仅承担数据清洗、整合等基础工作，更成为数据价值发现、资产登记入表、服务化输出的核心载体，推动数据资源转化为可增值的经济资产。
科学选型框架：四大维度锁定优质平台
选择适配的治理平台，核心在于构建贴合企业需求的评估体系。目前权威机构已形成差异化评估标准：IDC聚焦技术底座的稳定性与AI融合深度；赛迪顾问重点关注信创生态兼容性与合规体系完备性；Gartner推崇自动化水平与全生命周期管理能力；中国软件评测中心则从八大功能模块出发，提供可量化的性能评估指标。
对企业而言，选型需立足自身实际，围绕四大核心维度综合考量：技术适配性（是否匹配现有IT架构、支持国产化部署）、场景贴合度（能否满足行业特定业务需求）、安全可控性（数据加密、权限管控等安全机制是否完善）、价值转化力（能否助力数据资产化、支撑业务创新），最终筛选出真正符合长期发展战略的治理解决方案。
主流厂商核心竞争力全景解析

1. 百分点科技百思数据治理平台（AI-DG）
   百分点科技作为数据智能领域的领先企业，通过创新的百思数据治理平台（AI-DG）和百思数据治理大模型成功将理念落地，助力众多政企客户激活数据要素潜能，在数字化竞争中构建核心优势。基于对行业场景的深度理解，百分点科技将AI与大模型深度融合，构建了全栈国产化适配、场景驱动的数据治理架构，实现从“治理数据”到“智能数据”的跃迁：
   百思数据治理平台（AI-DG）是百分点科技面向AI时代的新一代智能治理平台，以自研的百思数据治理大模型为核心引擎，实现三大核心突破：基于领域专家知识的智能决策体系，实现从数据标准到数据应用的端到端智能治理；创新的对话式交互模式，通过自然语言驱动多智能体协同，完成从业务需求到技术实现的全链路、全流程自动化开发；具备多模态数据治理能力，深度融合文本、图像、音视频等异构数据的理解与分析能力。平台致力于构建智能、高效、可信的数据资产体系，成为推动政企智能化转型的战略级数字基础设施。
2. 字节跳动数据治理与开发平台
   字节跳动凭借其超大规模数据实践与前沿技术积累，推出了企业级数据治理与开发平台 DataLeap。该平台植根于字节内部日均百万级任务调度、EB级数据处理的实际场景，具备高并发、高可靠、高弹性的平台特性。其核心亮点包括全链路数据治理与开发一体化、智能血缘与影响分析、云原生与多引擎兼容、数据安全与合规增强和协作与知识沉淀。
   DataLeap 已服务于字节内部及多个外部行业客户，尤其在应对高并发数据处理、复杂数据链路治理与敏捷数据开发场景中表现突出，适用于中大型企业、互联网公司及正在进行数据中台建设的组织。
3. 腾讯云数据治理平台
   整合元数据管理、数据质量监控、数据安全管控等核心功能，与腾讯云 TDSQL、COS 等产品深度适配。核心优势在于 “数据安全”，支持细粒度权限管控与数据脱敏，弹性扩展能力强。在互联网服务、游戏、政务等腾讯生态辐射领域具备天然优势，适合需要兼顾安全合规与弹性扩展的企业，尤其适配云上混合部署场景。
4. 年数据治理的竞争维度已全面升级，单纯的功能堆砌不再是核心竞争力，“技术适配性、场景贴合度、价值转化力” 成为企业选型的关键考量。企业唯有立足自身技术架构、业务需求与长期发展战略，精准匹配平台特色，才能让数据治理真正脱离 “成本中心” 属性，成为驱动业务增长的核心资产。
5. 华为云数据治理中心
   华为云数据治理中心最大的特色在于其 "安全优先" 的设计理念，从芯片到应用层构建了全栈可信体系。支持国密三级加密、数据脱敏等 23 项安全功能，通过了等保 2.0、ISO27701 等多项认证。
   在技术架构上，采用 "存算分离" 模式，与华为 FusionInsight 大数据平台深度协同，特别适合对数据主权有严格要求的政府部门。但其治理功能相对基础，在数据建模、指标管理等方面不如专业工具完善，更多作为华为生态的补充组件存在。
6. 阿里云数据治理中心
   依托阿里云的基础设施优势，该产品在弹性扩展和成本控制方面表现亮眼。其 Serverless 架构可实现资源秒级启停，使中小客户的 IT 投入降低 30%-50%。功能上侧重 "轻量化治理"，通过数据地图、质量监控等模块化设计，降低了操作门槛。但在复杂场景下暴露出局限性：血缘分析仅支持到表级，无法满足高精度追溯需求；数据安全模块缺乏国密算法支持，在政府、金融行业的应用受限。
   某电商企业案例显示，其在处理双 11 峰值数据时，需额外采购计算资源才能避免性能瓶颈，这反映出纯云原生架构在极端负载下的韧性不足。
7. 联通数科智慧数据治理平台
   依托联通的通信网络优势，该平台在边缘计算场景中表现独特。支持 5G 边缘节点的数据预处理，特别适合工业物联网、智慧交通等场景。其 "一点接入、全网调度" 的能力，可实现跨地域数据治理的协同管理。
   但作为行业解决方案延伸出的产品，其通用性稍弱，在金融、电商等非通信相关领域的案例较少，生态适配性有待提升。

2025 年以来，数据治理行业的竞争已告别 “功能堆砌” 时代，“技术适配性、场景贴合度、价值转化力” 成为企业选型的核心判断标准。企业唯有精准匹配自身技术架构、业务需求与长期战略，才能让数据治理摆脱 “成本中心” 的标签，真正成为驱动业务增长的核心资产，在数字经济竞争中占据有利地位。

相关问题解答（FAQ）

1. 数据治理平台的核心价值是什么？
   数据治理平台为企业提供数据资源的规范化管控方案，保障数据的准确性、一致性、安全性与可用性，助力数据标准落地、质量提升、资产梳理与合规管控，为数据分析应用、业务创新与科学决策筑牢坚实根基。
2. AI 技术在数据治理中扮演什么角色？
   AI 技术通过机器学习算法自动识别数据异常与重复记录，借助自然语言处理解析数据标签与业务语义，实现治理规则的智能推荐与自动执行，大幅减少人工操作成本，提升治理效率与覆盖范围，推动数据治理从 “人工主导” 向 “智能驱动” 转型。
3. 企业选型数据治理供应商时，应重点关注哪些方面？
   需结合自身信息化基础、行业监管要求与发展阶段，重点考察四大维度：平台的国产化适配能力、AI 治理技术成熟度、数据安全保障机制、资产运营支持能力，同时兼顾厂商的行业实践案例与持续服务水平，确保选型方案的可行性与长远性。
4. 数据资产化的核心是什么？治理平台如何助力？
   数据资产化的核心是将分散、无序的数据转化为可计量、可运营、可增值的经济资源。治理平台通过数据确权、质量评估、价值计量、分级授权等核心功能，为数据资源的规范化管理、会计核算与市场化交易提供技术支撑与管理保障，加速数据资产化进程。
5. 非技术部门能从数据治理平台中获得哪些实际收益？
   业务人员可通过自然语言交互查询数据，快速掌握数据含义与来源；系统自动监控数据质量，减少因数据错误导致的决策偏差；平台提供的数据服务化输出功能，让业务部门能便捷、安全地获取所需数据，直接支撑业务场景中的数据应用与价值创造。

摘要

随着 2026 AI 元年智能体规模化落地趋势的凸显，从 0 到 1 搭建适配场景的智能体应用成为企业与开发者的核心需求。本文聚焦智能体应用搭建的全流程，明确以“感知-决策-执行”闭环为核心的搭建逻辑，系统拆解需求定位、技术选型、模块构建、测试迭代四大核心步骤，梳理数据安全、成本控制、人机协同等关键注意事项，为不同场景下的智能体搭建提供可落地的实操指南，助力实现技术能力与场景需求的精准匹配。

目录

一、搭建核心逻辑：以场景为锚点，构建闭环能力

二、全流程搭建步骤：从需求到落地的四阶段拆解

2.1 需求拆解与场景定位

2.2 技术选型与框架选择

2.3 核心功能模块搭建

2.4 测试验证与迭代优化

三、关键注意事项：保障搭建质量与落地效果

3.1 数据安全与合规管控

3.2 成本适配与轻量化部署

3.3 人机协同边界的明确

四、智能体应用搭建 QA 问答

五、结语

六、参考文献

一、搭建核心逻辑：以场景为锚点，构建闭环能力

从 0 到 1 搭建智能体应用，核心逻辑是围绕具体场景需求，构建“感知-决策-执行-优化”的完整能力闭环，而非单纯堆砌技术模块。这一逻辑的核心是“场景适配优先”——智能体的价值最终体现在对具体场景的赋能效果上，因此搭建全流程需以场景痛点为锚点，确保每一步构建都服务于问题解决。

从本质来看，智能体应用搭建的核心价值在于打破传统 AI 工具的功能局限：通过整合感知、决策、执行能力，让智能体从“被动响应工具”升级为“主动解决问题的数字助手”，既降低人工干预的频次与成本，又能实现技术能力在同类场景中的规模化复用，为企业智能化转型提供轻量化、可落地的解决方案。

二、全流程搭建步骤：从需求到落地的四阶段拆解

智能体应用搭建需遵循“需求-技术-构建-验证”的线性逻辑，拆解为四大核心阶段，确保每一步衔接顺畅、目标明确，避免因流程缺失导致落地失败。

2.1 需求拆解与场景定位

需求拆解与场景定位是搭建的基础，直接决定后续技术选型与模块设计的方向，核心要完成“目标明确-流程梳理-边界界定”三件事。首先，明确核心应用目标：需精准定位智能体的核心功能，例如客户服务场景的“7×24 小时问答与问题闭环”、工业场景的“设备故障预测与维护提醒”，避免功能泛化导致资源浪费。其次，梳理场景全流程：拆解目标场景中的核心环节与关键节点，例如“用户咨询-需求识别-数据检索-答案生成-反馈收集”，明确智能体的输入（如用户指令、设备数据）、输出（如回答内容、维护指令）及各环节的触发条件。最后，界定能力边界：明确智能体可自主完成的任务与需人工介入的场景，例如复杂问题的转接、高风险决策的审核，避免因能力边界模糊导致用户体验下降。

2.2 技术选型与框架选择

技术选型需遵循“适配性优先、低成本起步”原则，核心围绕“框架-数据-算力”三大核心要素展开。在框架选择上，优先选用支持多工具联动、可扩展性强的开源框架，例如 LangChain、AutoGPT 适合文本类智能体搭建，AgentGPT 适合轻量化场景快速落地，工业智能体可选择适配工业协议的专用框架，降低开发门槛与后续迭代成本。在数据准备上，需搭建“采集-存储-预处理”全链路模块：采集场景相关的结构化（如用户画像、设备参数）与非结构化数据（如文本咨询、设备图像），选择安全合规的存储方案（如企业私有云、加密数据库），通过数据清洗、标注、脱敏等预处理，提升数据质量。在算力配置上，根据场景需求灵活选择部署方式：轻量化场景（如小型客服智能体）可采用云服务器按需付费；复杂场景（如多模态工业智能体）可结合本地算力与边缘计算，平衡性能与成本。

2.3 核心功能模块搭建

核心功能模块搭建需围绕“感知-决策-执行”闭环展开，三大模块相互联动，构成智能体的核心能力。感知模块负责“信息输入与解析”，需支持多类型信息接收，例如文本、语音、图像、传感器数据等，通过 OCR 识别、语音转文字、多模态语义理解等技术，实现信息的精准提取与意图识别，为后续决策提供基础。决策模块是智能体的“核心大脑”，需结合规则引擎与大模型能力：规则引擎用于处理明确的标准化场景（如固定流程的业务办理），大模型用于处理复杂的非标准化场景（如模糊需求解读、多路径选择），通过两者协同实现自主决策，例如根据用户咨询意图匹配对应的服务流程。执行模块负责“动作落地”，需对接场景相关的工具与系统，例如客服智能体对接 CRM 系统实现客户信息调取，工业智能体对接 MES 系统下发维护指令，通过标准化接口确保指令精准执行，同时反馈执行结果。

2.4 测试验证与迭代优化

测试验证与迭代优化是确保智能体落地效果的关键，需分阶段开展“功能-性能-场景”全维度测试。功能测试阶段，模拟真实场景下的各类输入，验证智能体的响应准确性、流程完整性，例如客服智能体测试不同咨询问题的解答准确率，工业智能体测试设备数据异常的识别精度，排查功能漏洞。性能测试阶段，重点验证响应速度、并发处理能力与稳定性，例如测试 100 人同时咨询时的响应延迟，连续运行 72 小时的稳定性，确保满足场景的实际使用需求。场景验证阶段，在真实环境中进行小范围试点，收集用户反馈与实际运行数据，针对性优化决策逻辑、指令匹配度等，例如根据用户反馈调整回答话术，根据设备运行数据优化故障预测模型，实现“测试-反馈-优化”的闭环迭代。

三、关键注意事项：保障搭建质量与落地效果

在智能体搭建全流程中，需重点关注数据安全、成本控制、人机协同三大核心问题，避免因细节疏漏导致搭建失败或落地效果不佳。

3.1 数据安全与合规管控

数据是智能体运行的基础，需全程保障数据安全与合规。一方面，严格遵循数据安全相关法规，例如个人信息保护法、数据安全法，确保数据采集、存储、传输、使用全流程合规，避免敏感信息泄露。另一方面，搭建数据安全防护体系，采用数据加密、访问权限管控、脱敏处理等技术，例如对用户隐私信息进行加密存储，对设备商业数据设置分级访问权限，定期开展数据安全审计，防范数据安全风险。

3.2 成本适配与轻量化部署

成本控制是智能体规模化落地的关键，尤其是中小企业需避免盲目投入。建议采用“轻量化起步、逐步迭代”的部署策略：初期优先搭建核心功能模块，选用低成本的云服务与开源框架，降低初期投入；根据业务发展需求逐步扩展功能，升级算力资源。同时，做好成本评估与优化，例如通过数据压缩减少存储成本，通过算力调度提升资源利用率，避免资源闲置。

3.3 人机协同边界的明确

智能体的核心价值是辅助人工而非替代人工，需明确人机协同的边界。在搭建过程中，需预设人工介入机制：对于超出智能体能力范围的复杂问题（如特殊业务咨询）、高风险决策（如重大设备停机指令），自动转接人工处理；同时，搭建人机协同平台，实现人工对智能体运行状态的监控、决策结果的审核与异常情况的干预，确保智能体的运行安全与效果可控。

四、智能体应用搭建 QA 问答

4.1 基础认知类

Q：什么是智能体应用搭建？核心逻辑是什么？

A：智能体应用搭建是指从 0 到 1 构建具备“感知-决策-执行”闭环能力的智能系统，能自主响应特定场景需求并完成任务。核心逻辑是以场景为锚点，围绕具体需求（如客服、工业控制）搭建“感知-决策-执行-优化”的完整能力闭环，而非单纯整合技术工具，最终实现从“被动响应”到“主动解决问题”的转变。

Q：搭建智能体应用需要哪些核心技术？

A：核心技术围绕“感知-决策-执行”三大模块展开：感知层需支持多类型信息接收（文本、语音、图像等），依赖 OCR、语音识别、多模态语义理解技术；决策层需结合规则引擎与大模型，处理标准化与非标准化场景；执行层需对接具体场景工具（如 CRM、工业系统），通过接口实现指令落地。

Q：搭建智能体的流程是怎样的？从 0 到 1 要分几步？

A：从 0 到 1 搭建智能体共分四步：第一步是需求拆解与场景定位，明确核心功能与流程；第二步是技术选型与框架选择，确定工具与部署方案；第三步是功能模块搭建，构建“感知-决策-执行”闭环；第四步是测试验证与迭代优化，通过测试提升稳定性与适配性。

4.2 技术选型类

Q：新手搭建智能体，优先选择哪些开源框架？

A：新手优先选择轻量化、易上手的开源框架：文本类场景（如客服智能体）选 LangChain，支持多工具联动与流程编排；轻量化自主决策场景选 AutoGPT，降低开发门槛；工业场景（如设备控制）可选用适配工业协议的专用框架（如基于 Python 的工业智能框架）。

Q：搭建智能体时，数据安全需要注意什么？

A：需重点关注三点：一是合规性，遵循《个人信息保护法》等法规，确保数据采集、存储、传输合规；二是防护措施，对敏感数据（如用户隐私）进行加密存储与脱敏处理，设置分级访问权限；三是定期审计，定期开展数据安全检查，避免数据泄露风险。

Q：如何控制智能体搭建的成本？

A：建议采用“轻量化起步、逐步迭代”策略：初期优先搭建核心功能模块，选用云服务器按需付费（如阿里云、腾讯云的轻量服务器），降低初期投入；后期根据业务需求逐步扩展功能，避免盲目升级算力；同时通过数据压缩、算力调度提升资源利用率，减少闲置成本。

4.3 实操落地类

Q：搭建智能体时，如何明确人机协同的边界？

A：需预设“智能体自主处理 + 人工介入”的双重机制：智能体负责标准化、低风险任务（如常规咨询、简单指令执行）；对于复杂问题（如特殊业务办理）、高风险决策（如设备停机），自动转接人工处理；同时搭建监控平台，人工可干预智能体的异常运行，确保安全可控。

Q：智能体搭建完成后，如何进行测试与优化？

A：分三阶段测试：一是功能测试，模拟真实场景输入，验证响应准确性与流程完整性；二是性能测试，测试响应速度、并发处理能力（如 100 人同时咨询）与稳定性；三是场景验证，在真实环境小范围试点，收集用户反馈，针对性优化决策逻辑与指令匹配度。

Q：不同场景（如客服、工业）搭建智能体，核心差异是什么？

A：核心差异在于场景需求与技术适配：客服场景需侧重“多模态交互 + 快速响应”，优先支持语音、文本等多类型输入；工业场景需侧重“设备数据采集 + 精准执行”，需对接工业系统（如 MES、PLC），确保指令与设备操作的精准匹配。

4.4 进阶优化类

Q：如何让智能体具备持续迭代能力？

A：需搭建“测试-反馈-优化”的闭环机制：在智能体中嵌入反馈收集模块，记录用户使用体验与执行结果；定期分析数据，调整决策逻辑与执行策略；同时预留扩展接口，支持后续功能升级与场景拓展，让智能体随业务需求持续优化。

Q：搭建智能体时，如何避免功能泛化？

A：核心是聚焦场景痛点：搭建前明确智能体的核心目标（如“7×24 小时客户咨询”），避免添加无关功能；在功能模块设计时，只保留与核心目标相关的能力，例如客服智能体无需添加复杂的数据分析功能，工业智能体无需支持多语言交互，确保能力与需求精准匹配。

Q：中小企业搭建智能体，有哪些低成本的实操建议？

A：一是选用轻量化工具，优先选择开源框架与云服务，降低开发与部署成本；二是小范围试点，先在单一场景（如客服咨询）落地，验证效果后再逐步扩展；三是借力第三方服务，部分平台提供智能体搭建的轻量化工具（如无需代码的可视化平台），降低技术门槛。

五、结语

从 0 到 1 搭建智能体应用，核心是把握“场景适配”与“闭环能力”两大核心要点，通过科学的流程拆解与严谨的细节管控，实现技术能力与业务需求的精准匹配。在 2026 AI 元年的技术浪潮下，智能体搭建不再是专业技术团队的专属，随着开源框架的普及与轻量化工具的推出，中小企业与个人也能实现低成本搭建。未来，随着技术的持续迭代，智能体搭建将更趋简化，但场景适配性、数据安全性与人机协同效率仍将是核心竞争力。唯有以场景为锚点，兼顾技术可行性与商业价值，才能让智能体真正发挥赋能作用，推动业务的智能化转型。

六、参考文献

[1] 中国信息通信研究院. 2026 人工智能产业发展白皮书[R]. 北京：中国信通院，2026.

[2] 工业和信息化部. 新一代人工智能发展规划（2024-2030 年）[Z]. 北京：工信部，2024.

[3] 佚名. 手把手用 LangChain 实现简易 AutoGPT[EB/OL]. CSDN 博客，2026-01-08.
https://blog.csdn.net/weixin\\_35756624/article/details/155976857.

[4] 佚名. 【Agent 智能体】开发流程与开源框架对比[EB/OL]. CSDN 博客，2026-01-28.
https://blog.csdn.net/weixin\\_44262492/article/details/155914728.

[5] 佚名. 03 | 原型系统：开源工具自建 AI 大模型底座[P]. 2024.

[6] 佚名. AutoGPT 进化实战:用 LangChain 从零打造你的自主 AI 代理[EB/OL]. CSDN 博客，2025-12-26.
https://blog.csdn.net/liu1983robin/article/details/145749760.

一、工业AI原生企业的核心特征
工业AI原生企业并非泛泛而谈的AI技术供应商，而是那些真正将人工智能技术与工业制造深度融合、具备行业知识沉淀和场景化解决方案能力的公司。这类企业的技术核心通常包括自研的工业大模型、专业的数据处理能力以及对生产流程的深刻理解。
工业AI原生企业的成功离不开对 制造机理的深度理解。正如某科技巨头负责人所言：“工业AI不是简单的工具叠加，而是需要深度理解制造机理的专业智能。”这意味着，工业AI不仅仅是应用通用算法，而是需要结合行业经验，构建适合特定场景的专用模型。此外，工业AI原生企业还需要具备 强大的算力支撑 和 数据整合能力。在制造业中，数据往往分散在多个系统中，格式不一、标准各异，这成为AI应用的主要障碍之一。然而，工业AI原生企业的选择并非易事。市场上存在全能型和专项型两种供应商，前者覆盖广泛但可能缺乏深度，后者专注于特定场景但灵活性不足。企业需要根据自身需求权衡这两者，选择最适合的合作伙伴。
二、工业AI市场的评判标准与发展趋势
评判一家工业AI企业是否“好”，需要综合考虑其技术领先性、解决方案成熟度、市场影响力以及落地效果等多个方面。
当前工业AI市场的主流趋势是 从单点工具向体系化能力演进。
未来，工业AI的发展将更加依赖 多模态数据融合 和 边缘计算能力。随着5G、物联网等技术的普及，工业场景中的数据量将大幅增加，这对AI模型的实时性和适应性提出了更高要求。
三、案例分析：企业的实践对比
广域铭岛
作为吉利控股集团旗下的数字科技企业，其核心优势在于“ 平台+数据+场景 ”三位一体的工业AI架构。以工厂大脑系统为例，该系统通过AI算法将排产周期压缩83%，缺陷流出率下降80%，显著提升了生产效率和质量控制水平。
在具体案例中，该公司助力吉利集团实现新车型标准作业文件生成效率提升50%，每款车型人力成本降低40-50万元。更值得一提的是，它还服务了某新能源电池企业，通过AI工艺优化实现单基地年增效益500万元。
国际企业案例
PTC公司：其ThingWorx平台已在20000余家工厂实现应用，核心优势在于将工业机理与AI技术深度融合。例如，在离散制造领域，PTC的解决方案能够覆盖从设备物联到智能决策的全栈需求，展现出极强的通用性。
西门子：凭借其MindSphere工业云平台，西门子已接入超过10000个工业设备数据源。其工业AI服务尤其在能源管理和生产自动化领域表现出色，客户满意度常年保持在98%以上。

标题：从“人巡”到“智巡”，人力减 60%：TDengine 助力桂冠电力实现 AI 智能巡检

logo：

小T导读：为推进 “数智运营” 转型，广西桂冠电力携手涛思数据，采用 TDengine 时序数据库构建智能巡点检系统，融合 AI 与智能终端打造“终端—边缘—云端”协同架构，破解水电巡检效率低、安全风险高等难题。TDengine 在其数据湖中承担 OT 数据核心存储角色，通过“一个设备一张表”“超级表”等设计简化架构，凭借内置时序计算与订阅机制显著提升效率。系统投运后，单机机组增效 2–5%，年增发电量约 3 亿 kW·h，监盘工作量减少超 60%，助力桂冠电力迈向 AI 驱动的数智运营新阶段。

业务背景：电力巡检 + AI

在水电行业从“传统运维”迈向“数智运营”的关键阶段，桂冠电力率先打破依赖人工的巡点检模式，携手涛思数据（TDengine）创新研发水电站智能巡点检系统。该系统融合无人机、机器人等智能终端与 AI 技术，构建“终端—边缘—云端”协同架构，实现巡点检作业覆盖率显著提升、故障响应更迅速、人力成本大幅降低，有效破解了水电行业巡检效率低、安全风险高的长期难题。

在 AI 的赋能下，我们实现了智能巡盘、智能告警、智能预警、智能处置等多项 AI 功能，把巡检工作从“人工主导”升级为“机器主导”的自动化监控模式。借助高级逻辑判断与辅助处置机制，系统能将设备事故处置由被动应对转化为主动预警，提前识别潜在风险并同步提供操作指导与优化方案，既显著提升机组运行的安全性与经济性，又大幅减轻运行人员的监屏劳动强度和心理压力。

同时系统的实施使得发电效率也得到显著提升：单台机组的增效约为 2-5%。主要水电机组应用后，每年可增加发电量约 3 亿 kW.h。系统的智能监盘功能实现了适用于少人、无人监盘的模式，减少了监盘 60% 以上的工作量，大幅减轻了运行人员的工作强度，进一步提高了监盘的准确性和响应速度。

本文将与大家分享 TDengine TSDB 在我们数据湖建设中发挥的关键作用。

业务上的具体应用实践

简化数据湖的存储架构

在数据湖当中，TDengine TSDB 作为数据湖的贴源层，支撑了全部 OT 数据的存储。如下表所示，OT 数据与 IT 数据之间有着明显的区别：

为在 OT 与 IT 数据上实现最佳性能，我们分别采用某关系型数据库与涛思数据 TDengine TSDB 作为 IT 层与 OT 层的存储组件，构建分层存储体系。架构图如下图所示：

在当前架构当中，TDengine TSDB 所具有的特性，使得海量 OT 数据的存储更加便捷：

• “一个设备一张表”的设计，非常直观地映射到 IoT 中各类设备的采集值模型；
• 超级表的设计，使得一次查询多个测点变得非常简单；

• 分布式的架构设计，可以支持横向扩展和纵向扩展，在同一层无需多集群；

  • 虚拟分区策略，可以充分利用每一个节点的资源；
  • 动态调整数据分布，可以避免单点资源瓶颈带来的业务阻塞；
• 特色的时序计算函数，使得大部分业务计算可以直接获取，同一区域内无需分层存储。

业务建模的约束设计

基于“一个设备对应一个子表”的建模原则，我们对设备及其点号的数据进行建模与存储。在建模过程中，需要重点解决以下几个问题：

• 设备维度的设计：确定用于描述设备的关键维度；
• 唯一性的设计：明确用于唯一标识设备的字段，即设备表的 Primary Key；
• 多维选择唯一性的设计：确定可用于唯一检索设备的多个字段组合，即设备表的 Candidate Key。

TDengine 的超级表具备标签列特性，可用于实现设备表的存储。各标签列相互独立，类似于关系型数据库中的字段。由于超级表不具备 Primary Key 和 Unique Index 机制，因此在实际应用中需要通过约定来实现约束：

• db\_name：作为业务分割单元，不同 db\_name 的服务于不同业务，保证同一业务内的 tbname 不重复，避免写入错误数据；
• tbname：作为单个系统的唯一性约束，用于单个业务范围内的真正唯一 id；
• tag::point\_code：作为测点名字记录，用于单个业务领域内的唯一性标记；
• tag::mtype/station\_name 等标签列：作为设备的属性进行描述，联合起来作为候选主键。

以单列模型的测点 pointdata 为例，表结构如下所示：

CREATE STABLE `all_station_st` (
`data_time` TIMESTAMP, 
`point_value` DOUBLE
) TAGS (
`point_code` VARCHAR(20), 
`addr` INT, 
`mtype` VARCHAR(20), 
`station_name` NCHAR(30), 
`description` NCHAR(64), 
`kks` VARCHAR(100), 
`measure_code` VARCHAR(60), 
`original_one` VARCHAR(40), 
`original_two` VARCHAR(64), 
`idx` NCHAR(32), 
`status` TINYINT
)  

由于标签列之间缺少约束功能（如索引、主键），因此需要从业务上做验证和校验，才能保证最终唯一。期望 TDengine TSDB 后续能在这一个维度进行进一步开发，降低业务开发的复杂度。

内置时序计算优化业务效能

在我们的业务系统中，TDengine 以其卓越的性能与强大的时序计算能力，大幅简化了业务开发工作。

对于业务逻辑和部分智能算法而言，常常需要对时间戳进行对齐，并在指定频率下获取测量值，这就要求我们基于原始数据进行计算。传统做法有两种：

• 提前计算：通过定时计算或者流式计算，提前把降采样的结果计算完存放起来；
• 实时计算：通过查询原始数据，实时计算后返回给应用。

提前计算的优势在于能让应用以最快速度获取结果，但缺点是需要维护一整套定时调度机制，涉及任务调度、异常处理和补数等运维工作，复杂度较高。

实时计算能够保证每次计算结果都是最新的计算逻辑，缺点是计算耗时有可能太大，计算内存消耗过大。

而 TDengine 的特色时序计算，就很好地避免了这些问题。即使是在微服务 + 低代码的时代，TDengine 带来的业务简化依然具有重要价值。以获取测点的日平均值进行绘制为例：

提前计算的实现通常需要部署独立的 Java 程序并持续监控其运行状态。编写计算逻辑本身并不复杂，真正的工作量在于多出一套需要维护的应用，同时还要应对算法更新、数据更新带来的重算问题，使整个过程显得十分笨重。

实时计算是指在业务产生数据需求时，直接查询数据库中的原始数据并即时计算结果。在我们的场景中，这类操作往往会演变为 CPU + MEM + Network 的高负载任务——在 queryRawData 过程中，需要占用大量内存来缓存 TSDB 返回的原始数据，消耗 CPU 进行数据解析，同时占用大量网络带宽完成数据传输。

而使用 TDengine 内置的 interval 库函数进行计算，则很轻便的完成了这个计算。interval 库函数是一个时间窗口函数，可分为：滑动时间窗口、翻转时间窗口。在我们的业务当中，大多数情况下会采用等时间窗口的平均值计算方式。例如：

taos > select _wstart, avg(`point_value`) from db.$point_code where _c0 >= ‘2025-01-01’ and _c0 < ‘2025-02-01’ interval(1d);

整个集群内存几乎没波动。做一个简单规模的查询对比：

# 在 1w 测点 10s 采样间隔，统计 7 天内的日平均值

# 使用 TDengine 的计算，只需要 1.14 秒
taos> select _wstart, count(*), avg(`current`), avg(`voltage`), avg(`phase`), tbname from test.meters partition by tbname interval(1d);
Query OK, 70000 row(s) in set (1.140877s)

# 对于提前计算，每日的计算，只是查询 1 天的数据就占用 15.49 秒：
taos> select * from test.meters where _c0 >= '2025-01-01' and _c0 < '2025-01-02' >> /dev/null;
Query OK, 14400000 row(s) in set (15.496163s)

# 对于实时计算，只是查询原始数据，就占用了 106.85 秒
taos> select * from test.meters >> /dev/null;
Query OK, 100800000 row(s) in set (106.852480s)

通过上述的数据可以得到：

从上述数据可以看出，实时计算方案在性能上明显不及 TDengine 内置计算，因此在实际业务中几乎不会被采用。提前计算方案在应用次数超过 16 次后能够带来正向收益（实际业务中查看次数会很容易超过这个数量）。因此，我们在系统中同时采用了提前计算与内置计算的组合方案。其中，内置计算帮助我们有效减少了网络传输、内存占用、CPU 计算以及业务研发等多方面的开销。

订阅替代数据分发

作为企业级数据湖，我们既需要满足桂冠电力内部的数据共享，也要支撑与外部系统之间的数据分发。借助 TDengine 的订阅机制与 taosX 企业级同步组件，这一需求得到了高效而可靠的解决。

对于分发内容的类型，我们主要有 2 大类：

• 针对设备订阅，订阅设备的时序数据

# 选择部分设备进行同步，只订阅时序数据
create topic topic_fzd as select tbname,data_time,point_value from pointdata.all_station_st where status = 1 and idx in ('辐射','辐照度') ;

• 针对业务进行订阅，需要订阅设备的元数据和时序数据

# 选择未知设备进行同步，并且同步元数据变动
create topic topic_longtan with meta as stable pointdata.all_station_st where status = 1 and station_name = 'DJK_LT_90000208'  

同步方式上，我们分为两大类：

• 目的地是 TDengine，应用使用 taosX 进行订阅和写入，保证稳定性。
• 目的地未知，应用由需求方使用官方 driver 编写，订阅对应的 topic，自行安排应用。

通过以上的 topic 方式和应用方式，我们解决了数据湖上的数据分发需求。与过往的其他大数据组件相比，属实是非常轻便了。

大规模的运维经验

在正式投产之后，我们经历过 3.0.3、3.3.4 和 3.3.6 多个大版本。测点规模从百万走向千万，是一个 10 倍增长的运维过程。在这里分享几个 TDengine TSDB 大规模集群运维的经验。

容量规划

基于桂冠的业务场景进行估算，我们最终使用了 64c256g * 3 的虚拟机运行 TDengine TSDB。按照双副本（企业版特性），每个 vgroup 处理 2w 的测点的经验数据，我们预估 64c*3 可以处理：

64 vnode/节点 * 3 节点 / 2 副本 * 20,000 测点/vgroup = 192,000 测点

实际过程中从刚上线的性能宽裕，逐步发展到后来的性能拮据。我们发现 20,000 测点/vgroup 这个经验数值，会随着业务应用的开发出现下滑。其核心原因在于业务开发的增多，会带来显著的 CPU 资源消耗。因此我们把预估方式调整为：

Unit = 20,000 / (insert\_ratio + query\_ratio) 测点/vgroup

其中 insert_ratio 代表写入强度，query_ratio 代表查询强度。可以初步分成几种情况：

• insert\_ratio

  • 0.5：代表数据频率已知，顺序写入，日常没有数据补写。
  • 1.0：代表数据频率已知，大部分时候顺序写入，存在常规的数据补写、部分乱序写入
  • 2.0：代表数据频率未知，大部分时候顺序写入，存在常规的数据补写、乱序写入

• query\_ratio

  • 0.5：代表常规有监控类查询（last/last\_row），短期时间区间查询（7天内）。
  • 1.0：代表常规有监控类查询（last/last\_row），短期时间区间查询（7天内），伴随定期任务查询。
  • 2.0：代表常规有监控类查询（last/last\_row），短期时间区间查询（7天内），伴随定期任务查询，同时提供历史数据查询。

这部分经验分别对应：单个物联网项目、综合物联网平台和集团数据湖平台。

写在最后

在 TDengine TSDB 的多年应用过程中，桂冠电力团队与涛思数据团队共同积累了丰富的大规模运维经验，并将实践成果转化为补丁与功能回馈社区。同时桂冠也见证着 TDengine 从一个时序数据库，逐步走向一个成熟的时序存算平台。在未来的日子里，相信 TDengine 能够成为物联网的一个标准全栈解决方案，为我们的电力业务进一步释放业务价值。

关于广西桂冠

广西桂冠电力股份有限公司是中国大唐集团有限公司的二级企业，主要经营水电、火电、风电及其他清洁能源的开发及运营，电站检修、技术咨询业务，兼营有色金属加工、金融服务等业务。公司拥有广西龙滩、岩滩、平班等共 41 座水电站、1 座火电厂和广西、贵州、山东烟台 9 个风电场，并网范围覆盖国家电网和南方电网的多个区域，资产分布于广西、四川、贵州等数个省市自治区，是一个集多能源、多网源、跨地域为一体的大型综合发电企业。

作者：桂冠电力

在这个被大模型和智能体（Agent）疯狂重塑的年份，我们不得不承认一个残酷的事实：传统的边缘计算叙事，正在失效。

当算力从中心有序下沉，当 AI Agent 开始接管终端决策，边缘计算不再只是网络的延伸，而正在成为智能的前沿阵地。谁还停留在旧叙事中，谁又真正拿到了通往下一个十年的船票，答案正在迅速分化。

基于这样的行业背景，边缘计算社区正式启动「2026 中国边缘计算企业 20 强」榜单评选。这不仅是一份年度名单，更是一场在技术代际更迭下的行业校准。

榜单背景

自 2019 年起，边缘计算社区已连续六年发布「中国边缘计算企业 20 强」榜单，累计吸引 800 余家产业链企业参与评选，覆盖边缘云、边缘一体机、边缘 AI、5G MEC 等核心领域。

过去六年中，该榜单全网累计传播曝光量突破 3500 万次（清博大数据舆情统计），不仅持续为行业树立技术与商业标杆，也逐步成为企业扩大市场影响力、获取生态与产业资源的重要入口。

当边缘计算进入 “边缘 × AI × 智能体” 的新阶段，我们认为：这份榜单，也必须随技术代际一起升级。

从“连接”到“智算”

回望过去两年，边缘计算的演进速度远超预期。

如果说 2024 年行业仍在聚焦边缘盒子、网关与连接能力，那么到了 2025 年底，只谈连接、不谈推理的产品，已经很难再获得市场认可。

大模型正在以前所未有的速度“瘦身”并下沉至边缘侧：从手机、PC，到工业控制器与现场设备，越来越多的终端被要求具备本地推理与自主决策能力。

边缘计算正在从“管道”，演进为 AI 的“触角”。当然，这并不意味着所有传统边缘计算企业都会被淘汰。但可以确定的是：

以“连接能力”为核心竞争力的边缘产品，正在快速失去议价权。

智能体爆发，边缘侧的“寒武纪时刻”

2026 年，或将成为边缘智能体（Edge Agents）走向规模化应用的起点。所谓边缘智能体，并非简单的模型端侧部署，而是指在受限算力、弱网络甚至离线条件下，仍具备自主感知、规划与执行能力的边缘决策单元。

未来的边缘计算竞争，将不再取决于硬件参数，而在于：

• 谁能让大模型在边缘侧稳定运行
• 谁能在毫秒级延迟内完成复杂决策
• 谁能在算力、算法与网络之间实现系统级优化

这不仅是技术升级，更是一轮生态重构。

寻找 2026 年的“边缘脊梁”

正是在这样的行业变局之下，我们启动「2026 中国边缘计算企业 20 强」评选。

我们要寻找的，不是停留在历史成绩上的老牌玩家，也不是只会包装概念的“PPT 公司”，而是那些真正进入 “边缘 × AI”深水区 的企业：

• 成功将 7B、14B 等模型量化并部署到边缘端的技术实践者
• 用边缘智能体解决真实、碎片化场景问题的实干团队
• 在算力、算法与网络协同中实现突破的破局者

他们，才是真正决定边缘计算下一个十年走向的力量。

评选标准与参选要求

参选条件

• 在边缘计算领域具备成熟的技术解决方案与商业化落地案例；
• 拥有核心技术壁垒（如边缘芯片、算法优化、异构计算等）或独特生态资源；

• 2026 年新增重点：展示边缘计算与 AI 大模型的融合实践（如优化 AI 推理效率、隐私计算、联邦学习等），以及算力。
  

  评分机制

• 线上投票（30%）：公众通过官方渠道为心仪企业投票；

• 专家评审（70%）：从以下四大维度综合打分：

  • 技术领先性（35%）
  • 商业落地（30%）
  • 边缘×AI创新（25%）
  • 生态贡献（10%）

上榜权益

• 品牌升维：通过头部合作伙伴渠道全域曝光，覆盖 10 万+ 开发者社区；
• 商机裂变：优先对接甲方订单资源，2024 年某上榜企业通过生态合作斩获 800 万项目订单；
• 权威认证：榜单企业客户咨询量平均提升 120%（历史数据）；
• 生态赋能：优先加入“边缘计算产业图谱”。

特别提醒

独行者快，众行者远：在 AI 巨头定义规则的战场上，边缘计算企业唯有被看见，才有机会被选择。技术不应被埋没，真正的能力值得被记录。边缘计算的下一个十年，不属于参数最多的人，而属于最懂场景、最懂约束、也最懂 AI 如何落地的人。

边缘计算社区
2026年1月21日

当天气预报不再局限于“播报”，而是成为物理世界的数字孪生接口，微服务架构将如何撑起这场感知革命？
“透过天气项目学透 Spring Cloud”不仅是一次技术实践的复盘，更是对未来软件架构形态的一次预演。在传统的认知中，天气项目往往被视为展示 RESTful API、服务注册发现、配置中心等 Spring Cloud 核心组件的经典场景。然而，若我们将目光投向未来 5 到 10 年的技术演进，这个项目将不再仅仅是数据的搬运工，而是演变为集全球感知、边缘计算、AI 赋能于一体的复杂智能系统。
从未来的视角审视 Spring Cloud 在天气项目中的角色，我们将看到微服务治理正在经历一场从“集中式管理”向“云边智协同”的深刻范式转移。
一、 架构形态：从集中式云端迈向“云-边-端”全域协同
未来的气象监测将不再依赖孤立的气象站，而是由数以亿计的物联网传感器、手机气压计、车载雷达以及低轨卫星构成的泛在感知网络。传统的单体 Spring Cloud 架构将无法应对海量的设备接入和极高的并发写入，架构形态将发生根本性进化。

1. 边缘节点的微服务化
   未来的 Spring Cloud 将不仅仅运行在中心云机房，更将大规模下沉至边缘侧。在未来的天气项目中，每个城市甚至每个街区都会部署边缘计算节点。
   边缘自治：利用 Spring Cloud 的扩展机制，微服务将具备“边缘自治”能力。即使在网络与中心云断连的情况下，本地的气象数据采集、预警广播等服务仍能独立运行。这是未来应对极端自然灾害、保障通信“最后一公里”的关键技术。
   动态拓扑感知：服务治理将不再局限于静态的服务列表。未来的服务发现组件需要能够实时感知移动节点（如气象无人机、应急车）的动态位置，基于地理位置和网络延迟动态调整服务调用链路。
2. 混合云架构的常态化
   为了应对突发性天气（如台风、暴雨）带来的局部流量洪峰，未来的天气项目将运行在混合云之上。
   无缝跨云调度：Spring Cloud 的服务治理将与底层基础设施深度解耦，实现跨公有云和私有云的无缝服务调度。当某区域流量激增时，系统能自动在云端扩容计算微服务实例，并将流量智能分发，实现真正的“气象级”弹性伸缩。
   二、 数据处理：从批处理演进为“流批一体”的实时孪生
   未来的天气预报要求达到“分钟级”甚至“秒级”的刷新率，这对微服务间的数据流转提出了极高的要求。传统的请求-响应模式将逐渐让位于事件驱动架构（EDA）。
3. 事件驱动的服务解耦
   在未来的项目中，传感器的每一次数据波动都将触发一个事件。
   实时反应链：Spring Cloud Stream（或其演进形态）将成为连接物理世界与数字世界的神经中枢。一旦监测到气压骤降，事件即刻触发，预警服务、交通调度服务、物流规划服务并发响应，无需等待上层应用轮询。这种“极速解耦”是未来智慧城市运作的基础。
4. 数字孪生的实时构建
   天气项目将成为构建城市“数字孪生”的核心数据源。微服务架构不仅要传输数据，更要维持一个与真实世界同步的虚拟模型。
   状态一致性挑战：在高度并发的微服务环境下，如何保证全球数百万个虚拟气象节点状态的一致性？未来的分布式事务治理将不再局限于 ACID 或 BASE，而是结合 CRDTs（无冲突复制数据类型）等新型数据结构，实现最终一致性与实时性的完美平衡。
   三、 治理智能化：从人工运维到“自愈合”智能体
   随着系统复杂度呈指数级增长，人工配置 Hystrix 断路器、手动调整熔断策略将成为历史。未来的微服务治理将全面拥抱 AIOps（智能运维）。
5. 预测性弹性伸缩
   未来的 Spring Cloud Gateway 将集成 AI 预测引擎。
   流量预判：结合历史天气数据和即将到来的气象变化，系统能够预知某地即将发生的暴雨会导致用户查询量激增。在流量到来之前，微服务实例自动完成扩容和预热，实现“零延迟”响应。
6. 自愈合系统
   异常根因分析：当某个微服务响应变慢时，AI Agent 会自动分析链路追踪数据，判断是数据库锁死、网络抖动还是算法缺陷，并自动注入修复策略（如限流、重启、降级），无需人工干预。系统将具备类似生物体的“免疫修复”能力。
   四、 安全与可信：零信任架构与隐私计算
   气象数据在未来将关联到能源调度、航空保险、农业生产等高价值领域，数据的安全性与隐私性至关重要。
7. 零信任网络
   未来的 Spring Cloud 安全体系将默认“不信任任何内外部网络”。
   细粒度动态授权：每一次服务调用，即使是内部微服务之间的通信，都需要经过基于身份和上下文的动态鉴权。Service Mesh（服务网格）将成为标准配置，承载所有微服务的流量管控与加密传输。
8. 数据的可用不可见
   在某些商业场景下，例如保险公司获取气象数据进行理赔核验，未来的架构将支持隐私计算。保险公司可以在不解密原始气象数据的情况下，运行计算逻辑获得结果。这需要在微服务协议层面引入同态加密等技术的支持，彻底解决数据共享的信任危机。
   五、 终极愿景：Spring Cloud 作为“感知即服务”的骨架
   透过未来的天气项目，我们看到 Spring Cloud 的本质正在发生变化。它不再仅仅是 Java 程序员手中的开发框架，而是正在进化为连接数字世界与物理世界的操作系统。
   在这个未来图景中，Spring Cloud 赋予了软件系统“感知”、“思考”和“反应”的能力。它让气象数据不再停留在屏幕上，而是流动到自动驾驶汽车的决策单元中，流动到智能电网的调度算法中，流动到每一个用户的智能终端上。
   “从入门到进阶”的终点，不仅是掌握了一个框架的使用，而是理解了如何构建一个具有韧性、智能且自适应的未来系统。这或许才是我们学习 Spring Cloud 的终极意义所在——在比特与原子的交汇处，用代码重构世界的运行逻辑。

当 AI 长出身体，从能听会说到能看会动！Agora Convo AI World 拉斯维加斯之夜活动回顾

主笔：周森

审校：小炫

编辑：陈述

AI 不再仅仅是屏幕里的对话框，从能感知情绪的陪护机器人，到具备实时翻译能力的智能眼镜，AI 硬件化成为 CES 2026 呈现的重要趋势。

然而，在 AI 硬件热潮背后，行业也在迫切寻找一个答案：当 AI 试图长出「身体」，它需要怎样的底层架构与交互逻辑？

1 月 9 日晚，Agora（声网兄弟公司）联合 RiseLink（博通集成）在拉斯维加斯 The LOFT at Cabo Wabo Cantina 举办了 Convo AI World 论坛活动。

这场吸引了近 300 位全球科技精英参与的盛会，意在为这股 AI 硬件热潮指引风向。

两家企业不仅联合发布了基于 BK7259 芯片的 R2 全场景 AI 机器人开发套件，更首次系统性地提出了「物理 AI 的蓝图」。

△ 活动现场

具身 AI 的蓝图：从「工具」到「生命形态」

当前，行业正处于从文本模型、语音助手，迈向具备长期记忆、情绪理解与陪伴能力的 AI 伙伴的早期阶段。

Physical AI，本质上是具身智能（Embodied AI） 在消费级市场的落地呈现。AI 硬件不再是冰冷的电子零件，而是一种正在形成的数字生命形态。

由 Agora 与 RiseLink 联合提出的 Physical AI 蓝图，则试图为下一阶段的具身智能发展提供一套以体验为核心的设计方法论。

Tony Wang 在演讲中强调，Physical AI 的关键不在于堆砌硬件参数，而在于对话体验，即在复杂环境中理解语境、识别说话者并感知情绪的能力。

未来，AI 的核心语言将从单向的「指令」彻底转变为双向的「对话」，其商业模式也将从硬件单次销售，转向以订阅制为核心的长期服务。

△ 发言嘉宾：Tony Wang，Agora 联合创始人兼 CRO

张鹏飞博士进一步阐述道，Physical AI 时代的竞争已演变为协同效率的竞争。想要成为或持续保持第一，前提是与各自领域中已经处于领先位置的伙伴深度协作。

RiseLink 将通信、算力与功耗管理深度整合，配合 Agora 的 RTC 实时互动能力，构成了 Physical AI 的基础引擎：以低延迟保障交互的自然性，以高能效支撑长时间的在线陪伴。

△ 发言嘉宾：张鹏飞博士，RiseLink（博通集成） CEO

真实的 AI 堆栈：重构技术底层

当 AI 跨越数字边界、从云端软件形态进入物理硬件，底层的技术架构不应该只是「模型 + 数据 + 算力」，而需要从「原子」到「比特」实现闭环。

在论坛环节，嘉宾们探讨和回答了什么是「真实的 AI 堆栈」并达成共识：AI 是否好用，取决于设备能否通过物理感知快速理解语境并做出即时反应。

△ Panel: The Real AI Stack

圆桌主持人：Rin Yunis 博士，RiseLink 开发者体验负责人 （中）

圆桌嘉宾： （自左向右）

• Max Fillin， WowCube CEO
• Blake Margraff, Healthcare Technology 创始人
• Amir Eitan, Nanit CPO
• Lin Chen 博士, Wyze 首席科学家

在架构选择上，边缘（Edge）与云端（Cloud）的分工不再是二选一，而是基于延迟、隐私和成本的精密平衡 。对实时性和隐私敏感的能力更适合本地运行，而需要持续迭代、受成本约束的功能则更适合放在云端，工程实践应从验证出发，再逐步优化边云分配。

在消费级场景中，成本是最硬的约束条件。无论技术听起来多么具有颠覆性，如果缺乏可持续的单位经济模型（Unit Economics），产品终究无法走出实验室成为长期的生意。

同时，嘉宾们达成了一个感性却深刻的共识：AI 必须具备稳定的记忆和一致的行为 。一个今天热情、明天健忘的 AI 硬件，是无法真正建立起用户信任的。

△ 圆桌嘉宾：Max Fillin, WOWcube CEO（左）

这种信任的建立，在家庭与健康等强私密场景下尤为微妙。品牌的真实投入与清晰的价值传递，远比罗列一堆天衣无缝的安全技术术语更有效。 用户对 Physical AI 的接受度，往往并不取决于你背书了多少项加密协议，而取决于极其直观的交互体感，即：反馈要即时（低延迟）、过程要透明（可解释）、底线要有人守（人类参与）。

△ 圆桌嘉宾：Lin Chen 博士, Wyze 首席科学家

应用与具身落地：AI 硬件的场景爆发

Physical AI 最令人兴奋的特质在于它的多模态能力，以及在各个场景的迅速渗透。

△ WOWcube（左）：将经典的 2x2 魔方形态与 24 个高分辨率屏幕相结合，通过扭转、倾斜和触觉交互，让玩家在立体的物理空间中体验沉浸式的游戏与应用。

△ Wyze（右上）： 新款户外安防摄像头采用贴纸式安装方式固定在窗户上，可从室内进行户外录像

△ Nanit Pro（右下）： 全功能婴儿监控系统，新增用于记录宝宝成长发育的功能

在医疗与健康领域，Physical AI 的价值在于它能实时处理复杂的生理信号，并以人类能理解、能接受的方式进行交互，从而在专业性与亲和力之间找到平衡。

Blake Margraff 指出，AI 在医疗中的落地绝非简单的自动化，而是要实现「自动化的患者监测与干预」。

△ 圆桌嘉宾：Blake Margraff，Healthcare Technology 创始人

Amir Eitan 则从育儿与家庭监测的角度补充道，真正的信任来自于 AI 能在特定场景下提供「可解释的反馈」。

△ 圆桌嘉宾：Amir Eitan，Nanit CPO

在 AI 陪伴的主题论坛中，各位嘉宾围绕 AI 陪伴产品在儿童与家庭场景中的实际落地展开话题。

△ Panel：Where AI Companionship Comes to Life

圆桌主持人：Patrick Ferriter，Agora 产品与市场高级副总裁（左下）

圆桌嘉宾：

• 孙兆治，珞博智能 CEO（左上）
• Angela Qian，灵宇宙 Luka AI 战略负责人 （右上）
• Wayne Zhang， Dify Chief of Staff（右中）
• Margo Wang，Lgenie ＆灵机一动 Agent 市场总监（右下）

稳定性和一致性是影响儿童用户对 AI 硬件接受度的关键因素。无论是故事内容、角色设定还是互动方式，一旦发生变化，都会显著影响使用体验。

低延迟是实时陪伴场景中的基本要求，是建立用户与产品情感连接的底线，响应过慢会直接削弱互动的自然感。

长期留存更具挑战性。吸引用户首次尝试与长期留存两者的差异性需要引起重视，长期留存更具挑战性，需要 AI 在持续使用中形成稳定的互动节奏和情感连接，而不仅是单次回应。

安全与责任方面需要引入多层防护思路，包括年龄匹配内容、实时干预机制、以及对儿童隐私的明确告知与限制。当 AI 承担陪伴角色时，如何在维持互动亲密性的同时设立清晰边界，仍是行业需要持续面对的问题。

△ Fuzozo 芙崽（左上）：面向 Z 世代的 AI 养成系潮玩

△ Luka AI Cube（右上）：灵宇宙小方机，儿童 AI 学伴

△ Lgenie （左下）：小匠宠物陪伴小车 & 四足桌面机器人

△ 海马爸比（右下）： AI 智能婴儿看护器

在产品演示环节，Diana Zhu 博士主持发布了 Choochoo AI 教育机器人。她提到，Choochoo 能够实现流畅的视觉与动作反馈，核心在于集成了 RiseLink 的高集成度 SoC 方案。该芯片在单颗硅片上整合了 Wi-Fi 连接、音视频处理与 AI 加速引擎，使得开发者能够绕过复杂的底层硬件调优，直接在 R2 套件上通过简单的 API 调用，实现原本需要高性能服务器才能支撑的「视觉-语言-动作」协同。

△ 发言嘉宾：Diana Zhu 博士，RiseLink 美国负责人

作为首款由 RiseLink 芯片与 Agora 对话式 AI 引擎深度驱动的教育机器人，Choochoo 不仅能听懂孩子的提问，更能通过视觉传感器「看」到周围的环境与孩子的动作，并做出相应的物理反馈。

△ Choochoo / 延伸阅读：对话式 AI 升级，不仅能看还能动

值得一提的是，作为 R2 全场景 AI 机器人开发套件标杆案例，陆吾智能旗下的桌面机器人「陆卡卡」也同步亮相。现场，陆卡卡展示了如何在紧凑的形态下实现高频、低延迟的 AI 交互。

△ 陆卡卡 / 延伸阅读：桌宠陆卡卡，一只「兵蚁」从二次元走进现实

在两款极具代表性的具身智能产品身上，我们看到，当 AI 拥有了强大的「大脑」（大模型）与灵敏的「身体」后，交互的边界已彻底被打破。两款产品的发布，共同定义了 AI 硬件的新高度，同时也标志着基于 Agora 与 RiseLink 合作的 AI 方案已经完全成熟。

在快闪分享环节，Joey Jiang 分享了打造 AI 原生硬件的最短路径，强调了模块化硬件对快速实现概念落地的意义。他指出，AI 原生硬件的开发不应再遵循「从零打样」的旧逻辑。通过 Seeed Studio 提供的模块化感知节点（如传感器、视觉模块）与 RiseLink 方案的即插即用式结合，硬件原型的验证周期可以从数月缩短至几周。这种「搭积木」式的开发模式，正是初创团队在 Physical AI 浪潮中抢占市场窗口期的最短路径。

△ 发言嘉宾：Joey Jiang，Seeed Studio 销售副总裁

Kim Jin 分享了打造糯宝 AI 机器人的背后故事。在研发背后，团队耗费大量精力对用户意图的深度理解。通过多模态感知，敏锐地捕捉视觉、触觉与语音背后的感性信息，实现拟人化的回复。这种交互不只是指令的执行，而是基于对用户意图的精准洞察，让机器人产生真实的「情感共鸣」。这标志着 Physical AI 真正跨越了工具属性，进化为懂得用户灵魂的情感伴侣。

△ Pophie (机器灵动) 产品负责人 Kim Jin

△ Maxevis（左）：迈威儿童拍学机

△ Pophie 糯宝（右）：桌面级情感陪伴机器人

隐私、授权与信任：环境式 AI 的底线

随着环境式 AI（Ambient AI）走向「始终在线」，隐私与信任已不再是合规问题，而是产品体验本身。用户真正担心的并非模型出错，而是设备在「不被察觉的情况下」收集和使用数据。

△ Panel：When AI Is Everywhere: Redefining Data Privacy, Consent, and Trust

圆桌主持人：Ramana Kapavarapu，Agora 首席信息安全官 (CISO) & IT 运营负责人（中）

圆桌嘉宾：（自左向右）

• Diana Zhu 博士，RiseLink 美国负责人
• Joe Tham，Ellie 海马爸比联合创始人
• Gibran Mourani，MiniMax 全球客户经理
• 卜峥，Kaamel AI 联合创始人兼 CEO

△ 成立于 2021 年底的 MiniMax 刚刚宣布港股上市，成为从成立到 IPO 用时最短的 AI 公司。大家首先向 MiniMax 的 Gibran Mourani 道贺。

围绕隐私实践，嘉宾们形成了一个明确共识：说到做到、做到可见。

透明性： 相比冗长的隐私条款，产品应在交互层面清晰呈现系统是否在监听、收集了什么数据，以及用户如何即时控制这些行为。透明性体现在硬件指示、软件状态和使用流程中，比如用物理指示灯直观地告诉用户系统是否在监听。

边缘保护： 通过边缘计算最小化数据流动，让原始语音和视觉数据停留在本地，是保护隐私的最有效路径。对多数场景而言，无需上传云端、本地处理并仅传递必要信号，既有助于隐私保护，也降低了系统暴露面。

响应机制： 谈及安全事件响应，需要成熟、结构化的应对机制，而非临时决策。快速隔离、明确影响、及时修复与复盘改进，比短期业务考量更重要。过往大型数据泄露案例反复证明，延迟或回避只会放大长期损失。

真正可规模化的信任，来自硬件与软件的一致设计以及可实时验证的控制能力。认证和合规是基础，但只有当系统行为与承诺持续一致，用户对「无处不在的 AI」才会产生长期接受度。

△ 活动现场

AI 具身化不可挡！

纵观整场活动，我们可以从三个层面理解这场关于 Physical AI 的深刻变革：

技术本质： 从「挂载」到「具身」。 AI 不再是硬件外挂的一个功能，而是通过专用芯片和实时通讯协议，深度融合进硬件的神经系统。

交互范式： 从「指令」到「共生」。 当 AI 能够理解语境、感知情绪并拥有长期记忆，它就从一个「好用的工具」进化为一个「理解你的物种」。对话不再是手段，而是其存在的形式。

商业本质： 从「买断」到「订阅」。 物理 AI 的核心价值在于其随时间不断进化的能力。厂商卖出的不再是零件，而是长期的服务与情感陪伴。

在 Agora 和 Riselink 两家公司和来自人工智能、芯片和硬件、AI 算法，以及数字健康、家居安防、AI 陪伴和教育等领域的数十家 AI 软硬件企业代表和顶尖专家的背书下，AI 将跳出单纯的数字世界，开始在物理世界中，真正长出它的身体。■

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

Python的动态类型特质与WebAssembly的静态二进制本质，在系统接口层面形成了天然的张力，而ABI作为两者沟通的底层桥梁，其挑战远非简单的接口适配所能概括。在边缘计算与无服务器场景的实践中，这种张力尤为明显：Python依赖的动态类型推断、垃圾回收机制，与WebAssembly的线性内存模型、静态类型约定在语义层面存在深刻分歧，而ABI作为连接这两种异构体系的关键，必须在类型映射、内存访问、调用约定等核心维度实现无缝衔接，否则便会出现看似兼容实则逻辑断裂的隐性障碍。这种障碍并非表层的功能失效，而是底层语义的错位——当Python的对象模型试图通过ABI穿透到WebAssembly的线性内存时，类型标识的模糊、内存所有权的界定、生命周期的同步，都会成为难以逾越的深层博弈点。比如在物联网设备的边缘计算场景中，Python处理的传感器动态数据流，需要通过ABI传递给Wasm模块进行高效计算，此时Python对象的动态属性可能在转换过程中丢失语义，而Wasm的线性内存无法动态适配对象的伸缩，导致数据结构出现隐性错乱。更隐蔽的是，当Python的垃圾回收机制触发时，可能误回收仍被Wasm模块引用的内存块，而Wasm对内存的手动释放也可能导致Python侧出现悬垂引用，这种跨环境的生命周期不同步，往往在高并发场景下才会暴露为数据一致性问题，每一个细节的疏忽都可能导致整个集成体系的语义崩塌，这种崩塌往往隐藏在正常运行的表象之下，直到特定场景触发才会暴露其底层的不兼容本质。

类型语义的对齐缺失是ABI面临的首要核心挑战，这种缺失并非简单的类型不匹配，而是动态与静态类型体系在ABI层面的语义断层。Python中变量的类型可随时变更，对象的创建与销毁由垃圾回收机制自动管理，而WebAssembly的类型系统则是编译期确定的静态结构，每一个数据的内存布局、大小、对齐方式都在编译阶段固定，这种本质差异使得ABI在进行类型映射时，必须面对语义转换的巨大鸿沟。不同的WebAssembly运行时对同一类型的ABI定义可能存在细微偏差，比如Wasmer与Wasmtime在外部引用类型的枚举命名上存在差异，Wasmer将Python的字符串类型映射为“externref_str”，而Wasmtime则命名为“string_externref”，这种看似微小的分歧，导致Python模块在跨运行时迁移时，接口调用会因类型标识不匹配而出现隐性失效，且这种失效往往难以通过常规测试察觉。更复杂的是，Python的复合类型如字典、列表，其内部结构具有动态伸缩性，字典的键值对可能随时增减，列表的元素类型也可混合存储，而WebAssembly的线性内存要求数据必须以连续块的形式存在，且每个元素的类型与大小必须一致，这就要求ABI构建一套复杂的类型转换逻辑。例如，将Python字典转换为Wasm可识别的结构时，不仅需要将键值对按固定顺序排列为连续内存块，还要额外存储键的哈希值与索引映射，以模拟字典的查找特性，这种转换过程中，类型语义的损耗与失真难以避免——Python字典的无序性在转换后可能变为有序结构，而混合类型的列表则需要额外的类型标记字段，这不仅增加了内存开销，还可能导致某些依赖原生语义的操作出现逻辑偏差，如何在转换中保持类型的完整性与行为一致性，成为ABI设计的核心难点。

内存模型的异构冲突构成了ABI集成的另一重深层障碍，WebAssembly的线性内存与Python的托管内存体系在语义与操作层面存在本质分歧。WebAssembly采用单一连续的线性内存空间，所有数据都存储在这片连续区域中，内存的分配与释放需要严格遵循特定的对齐规则，通常要求数据地址必须是其大小的整数倍，尤其是原子操作对内存对齐的要求更为严苛，任何偏离自然对齐的访问都可能导致CPU指令执行效率骤降，甚至在部分架构下引发隐性的内存访问异常。而Python的内存管理则依赖垃圾回收机制，对象的内存分配由解释器自动处理，内存地址的分配具有随机性，且对象之间可能存在复杂的引用关系，比如循环引用、弱引用等，这种托管式内存模型与WebAssembly的手动内存管理逻辑在ABI层面形成尖锐冲突。当Python对象需要通过ABI传递到WebAssembly环境时，不仅需要将动态分配的对象内存转换为连续的线性内存块，还要处理内存所有权的转移与生命周期的同步——Python的垃圾回收机制无法感知WebAssembly环境中的内存使用状态，可能在Wasm模块仍在访问数据时就回收该内存，而WebAssembly也无法参与Python的内存管理循环，无法主动通知Python侧释放不再需要的对象。在多线程场景下，这种冲突更为突出：Python的全局解释器锁（GIL）限制了内存操作的并发安全性，而Wasm的原子操作需要无锁的内存访问环境，ABI必须设计一套独立的内存协调机制，既要通过引用计数跟踪跨环境的内存使用状态，防止内存泄漏，又要通过内存锁定机制避免野指针访问，还要兼顾跨环境内存访问的性能，避免过度的同步操作导致效率低下，其设计难度远超同构体系下的内存接口。

系统接口的抽象层级差异给ABI带来了难以调和的适配难题，WASI作为WebAssembly的系统接口标准，其设计理念与Python依赖的原生系统接口存在显著的抽象鸿沟。WASI为了追求跨平台可移植性，对传统操作系统的系统调用进行了精简与标准化，仅保留了文件操作、网络通信、内存管理等核心功能，且调用方式采用了基于句柄的抽象设计，与Linux、Windows等原生系统的系统调用在功能覆盖、参数传递方式上存在明显差异。而Python的许多标准库与扩展模块深度依赖于原生系统的完整接口能力，比如Python的os模块提供的进程管理、信号处理功能，在WASI的接口规范中并未完全覆盖，这种差异使得ABI在对接两者时必须面对功能缺失与接口转换的双重挑战。例如，Python的os.fork()函数用于创建子进程，而WASI为了避免跨平台兼容性问题，并未提供对应的进程创建接口，ABI适配层必须通过线程模拟或进程池复用的方式间接实现该功能，这不仅增加了实现复杂度，还可能导致部分依赖进程隔离特性的Python代码出现逻辑偏差。更复杂的是，WASI的版本迭代与实现差异加剧了适配难度，WASI 0.2版本在网络接口中新增了TCP流的非阻塞操作支持，而部分老旧的Wasm运行时仍基于WASI 0.1版本实现，导致Python模块在利用ABI调用网络功能时，出现功能不一致或调用失败的情况。此外，不同运行时对WASI标准的实现也可能存在偏差，比如WasmEdge对文件权限的检查逻辑与Wasmer存在差异，导致Python的文件操作在不同运行时中表现出不同的行为，ABI需要在Python的原生接口期望与WASI的标准化接口之间构建适配层，既要通过功能补全弥补缺失的系统调用，又要通过兼容性适配兼容不同版本与实现的差异，这种适配层的设计不仅需要深入理解两套接口的抽象逻辑，还要具备足够的灵活性以应对生态的快速变化。

工具链的碎片化导致ABI在编译与链接阶段面临一致性难题，Python与WebAssembly的集成依赖多种工具链的协同工作，而不同工具链的编译策略、链接规则存在显著差异，使得ABI的实现难以保持跨工具链的一致性。目前主流的集成工具链包括Emscripten、Pyodide、Wasmer-Python等，每一种工具链都有其独特的编译流程与优化策略：Emscripten侧重于将Python代码编译为Wasm模块，其编译过程会对Python的标准库进行裁剪与适配，可能导致部分依赖原生扩展的模块无法正常工作；Pyodide则是将Python解释器编译为Wasm，通过JavaScript桥接实现与Wasm模块的交互，但其ABI设计过度依赖JavaScript中间层，导致跨环境调用的性能损耗较大；Wasmer-Python直接通过原生绑定实现Python与Wasm运行时的交互，但其对Python版本的兼容性较差，仅支持3.8以上的特定版本。这些工具链的差异在异常处理机制上表现得尤为明显，Python的错误处理模型依赖于异常传播，允许在函数调用栈的任意层级捕获异常并处理，而部分Wasm工具链如Emscripten默认不支持跨模块的异常传播，将Python的异常转换为Wasm的错误码，这就需要ABI在编译阶段进行特殊配置，通过生成额外的异常处理元数据，实现异常信息的跨环境传递，既要满足Python的异常处理需求，又要兼容工具链的限制。另一些工具链在处理稳定ABI时，可能存在链接逻辑的偏差，比如在Windows平台上，即使指定了稳定ABI构建，Emscripten仍会错误地链接到版本特定的Python库文件，导致Python模块失去跨版本兼容性，在Python 3.10与3.11之间切换时出现符号未定义错误。这种工具链层面的差异使得ABI的实现必须针对不同工具链进行适配，而每一种适配都可能引入新的兼容性问题，如何在碎片化的工具链生态中维持ABI的一致性与稳定性，成为集成过程中必须攻克的难题，这不仅需要对工具链的底层逻辑有深入理解，还要设计灵活的适配策略，比如通过条件编译指令适配不同工具链的特性，通过中间层封装屏蔽工具链的差异，以应对各种边缘情况。

ABI的演进与兼容平衡是长期面临的战略挑战，随着Python与WebAssembly生态的快速发展，ABI需要在功能扩展与向后兼容之间找到微妙的平衡。Python的版本迭代速度较快，每一个大版本都会引入新的语言特性与标准库接口，比如Python 3.11新增的异常组特性、3.12优化的类型注解语法，这些新特性往往需要ABI在类型映射、调用约定等层面进行相应调整，才能实现与Wasm模块的无缝集成。而WebAssembly的规范也在持续升级，最新的WebAssembly 2.0标准引入了SIMD扩展指令集、引用类型增强等新特性，这些特性为性能优化提供了更多可能，但也要求ABI进行升级以支持新的指令调用与内存操作模式。然而，ABI的升级必须兼顾已有系统的兼容性，否则会导致基于旧版ABI开发的Wasm模块与Python扩展失效，破坏生态的稳定性。例如，若ABI为支持SIMD指令而修改了数值类型的内存布局，那么基于旧版ABI编译的矩阵运算Wasm模块，在新版本环境中会因类型映射错误而输出错误结果。更复杂的是，不同的Python库与WebAssembly模块可能依赖不同版本的ABI，部分老旧的Python扩展仍依赖于早期的ABI版本，而新开发的Wasm模块则需要使用最新的ABI特性，这种依赖的多样性使得ABI的版本管理变得异常复杂。如何设计一套可演进的ABI架构，既能支持新特性的快速集成，又能通过兼容层保障旧模块的正常运行，成为考验架构设计能力的关键。