InfoQ 推荐

神州数码发布企业AI流程系统与智算产品，尝试打通应用和算力两端

李冬梅 — Mon, 20 Jul 2026 11:59:20 GMT

7月18日，在WAIC 2026 AI魔盒区，神州数码展示了面向企业AI应用和智能算力基础设施的多项产品，包括“神州问学：AI原生的流程操作系统”、AI Infra OS，以及KunTai R722 K2通用服务器、KunTai A989 T3超节点服务器和KunTai PoD2000 A3液冷超节点整机柜。

从产品布局看，神州数码试图同时解决企业AI落地中的两类问题：一是如何将模型输出嵌入真实业务流程，二是如何提升算力资源利用率，衡量AI基础设施的实际产出。

神州数码AIBG AI产研中心总经理侯浩表示，不少企业已经部署大模型和AI工具，但仍面临知识分散、流程割裂、输出难以溯源，以及专家经验难以沉淀等问题。企业需要的不只是模型入口，还需要连接知识、流程、人员和任务的系统。

据介绍，“神州问学”采用四层架构：底层MaaS平台统一接入开源及商业模型；知识治理层负责多类型数据解析和知识图谱构建；流程智能层通过工作流编排业务；上层则面向医药、制造等行业提供场景应用。

该系统可以将AI生成内容与企业原始数据、业务资料和行业规范关联，便于查询来源和复核结果。同时，其采用接入现有办公及业务系统的方式，无需整体替换企业原有IT架构。

在医药场景中，系统可接入Office、飞书等工具，记录文档版本和修改痕迹；在制造业产线良率分析中，则可汇集设备、质量和工艺资料，辅助工程师定位异常原因，并沉淀处理经验。

在基础设施侧，神州数码通明湖研究院AI解决方案专家杨柳春表示，企业对算力的衡量标准，正在从单张芯片性能转向集群利用率、Token产出、运行成本和长期稳定性。

神州数码AI Infra OS包括HICA异构智算加速平台和HISO异构智算调度平台，并与服务器、超节点和交换机配合，覆盖算力规划、推理优化、资源调度和运行管理。

其中，HICA覆盖容量规划、环境诊断、自适应推理和弹性服务。神州数码披露的测试数据显示，在特定环境下，该平台可使每分钟Token数提升50%，Token端到端成本降低20%。

HISO则通过资源池化、拓扑感知调度和内核级隔离，减少资源碎片。按照现场公布的数据，其可使集群有效容量提升30%，GPU利用率提升约一倍。

硬件方面，KunTai R722 K2青春版主要面向成本敏感型通用计算场景，支持32条DDR4内存插槽。

KunTai A989 T3和PoD2000 A3液冷整机柜则面向大模型训练和高密度推理，支持单集群384节点，FP16算力为240PFLOPS。

网络侧，木犀智能SP6交换机整机无阻塞交换容量超过100Tbps，配备64个1.6T端口，主要面向万卡级AI集群，降低大规模训练中的通信瓶颈。

企业级AI正在从单点模型调用转向系统工程。应用侧需要解决知识治理、流程编排和结果溯源，基础设施侧则需要处理异构算力调度、推理优化和集群通信。神州数码此次展示的产品，体现了其同时从业务流程和算力底座切入企业AI市场的思路。

国产GPU分水岭时刻：当别家还在卷参数，摩尔线程早已训练出了世界模型

褚杏娟 — Mon, 20 Jul 2026 11:51:30 GMT

“2026 年初，OpenClaw 刚火时，日活 Token 数大概是 140 万亿。未来算力越多越好，因为 Scaling Law 依然成立。”摩尔线程创始人、董事长兼 CEO 张建中在 2026 世界人工智能大会上分享道。

现实是当前算力依然不够。比如 Kimi K3 的发布引发了大量关注，但同时也带来了算力挑战。就在昨天，月之暗面发布公告称，暂停 C 端新用户订阅，将已有算力全部投入于服务已订阅用户。

算力紧缺，Token 消耗量千倍暴涨，但不同 Token 之间其实存在明显的质量差异。

比如，与消费级 Token 不同，企业生产环境中的高品质 Token 需要支持万亿参数级模型、百万 Token 上下文、极低的首字延迟、较高的生成速度以及 99.99% 的服务稳定性。企业真正愿意付费购买的是那些能够稳定进入生产环境的 Token。

因此，当企业真正开始按照每天生产多少 Token、每百万 Token 成本以及每项业务消耗多少 Token 来衡量 AI 投入时，传统以 GPU 数量、峰值算力为核心的评价体系已经不够用了。

中国工程院院士、清华大学教授郑纬民就提出，算力基础设施的关键，在于将每一份算力转化为高质量 Token。国家信息中心大数据发展部副主任魏颖也表示，算力基础设施是 Token 生产的物理底座，作为算力核心的 GPU 直接决定生产效率与成本。

这些都促使 AI 基础设施从“算力中心”向“生产系统”转型：企业购买的不再只是若干张计算卡，而是一套能够持续生产模型、Token 和智能体，并最终转化为业务价值的工业化体系。

以全功能 GPU 为核心的摩尔线程，率先将 AI 基础设施划分为三座“工厂”：模型训练工厂、词元生产工厂和智能体生产工厂。

三者分别对应模型研发、规模化推理以及数字智能体和物理智能体部署，看似服务于不同环节，背后却指向同一套逻辑：算力的价值不再由硬件参数单独决定，而是取决于芯片、软件、网络、模型和行业应用等能否形成完整生产闭环。

摩尔线程创始人、董事长兼首席执行官张建中

从“有多少卡”转向“生产多少智能”

第一座工厂：国产 GPU 开始完成超大模型训练

模型训练工厂对基础设施要求最高，也是国产 GPU 最难进入的环节。

随着集群规模扩大，任何单点故障、通信延迟、算子兼容问题或精度偏差，都可能导致训练中断，甚至使数周计算投入失效。对于成本动辄达到数亿元的大模型项目而言，训练平台是否稳定、是否能够线性扩展，以及训练结果能否收敛，远比单颗芯片的理论峰值性能更重要。

在摩尔线程看来，模型训练工厂首先必须具备“全功能”能力。因为基础设施建设周期通常长于模型迭代周期，企业无法预先判断下一代模型究竟是大语言模型、多模态模型、视频生成模型、世界模型，还是科学计算和具身智能模型。如果平台只能支持少数模型结构，企业很可能在模型路线改变后重新建设算力系统。

因此，摩尔线程推出以夸娥（KUAE）智算集群和 MUSA 软件栈覆盖更广泛的模型训练任务。其底层训练软件首先兼容 PyTorch，并通过 Torch-MUSA 承接现有算子生态；针对近年来在大模型训练中广泛使用的 Triton 和 TileLang，公司分别提供 Triton-MUSA 及相应适配能力。在更上层，平台支持 Megatron-LM、DeepSpeed 和 FSDP 等主流分布式训练框架，也可以适配客户自研框架。

软件兼容只是模型训练工厂的第一层。真正开始大规模训练前，企业还需要估算集群规模、训练周期、资源利用率及整体成本。摩尔线程为此开发了 MT-HTA 仿真系统，并提供 SimuMax 和 SimuInfer 工具，用于在正式训练或推理前模拟任务执行情况。其目标是让客户提前判断需要多少芯片、训练大约需要多长时间，以及不同并行策略可能带来的性能变化，降低高成本任务的试错风险。

在预训练之后，强化学习正在成为提升模型推理、代码和复杂任务能力的重要环节。摩尔线程在 MUSA 平台上适配了 VeRL 和 Slime，并分别推出开源的 MT-VeRL 和 MT-Slime 模型训练套件，其中 MT-VeRL 支持训推一体方案，MT-Slime 支持训推分离异构推理方案。

围绕混合专家模型（MoE），摩尔线程还对专家并行通信、算子融合和 FP8 训练进行了专项优化。公司披露，其平台能够结合 DeepEP 等通信技术，在 MTT S5000 上原生支持 Per-Block FP8 计算，以提高 MoE 模型的训练效率。

除了芯片本身，超大模型训练的另一个瓶颈是网络。

随着集群从千卡扩展到万卡乃至更大规模，通信效率会直接决定集群是否能够维持线性扩展。摩尔线程推出的 MTT C256 超节点采用一层 Scale-up 网络，在标准单宽机柜中实现 128 卡全互联，并可通过并柜扩展至 256 卡高速互联，卡间通信延迟压缩至亚微秒级。其设计目标是减少传统多层网络中的带宽损耗和通信延迟，同时提高单位机柜的算力密度。

根据摩尔线程公布的数据，夸娥智算集群在扩大训练规模时，线性扩展效率最高可达 95%；训练精度与国际主流计算卡基本一致，损失曲线保持高度接近；集群支持断点续训，有效训练时长占比超过 90%。

在超大模型实战中，摩尔线程与某国家级实验室合作，在国产万卡集群上从零训练了一个 MoE-236B 基础模型，并在后续引入强化学习，模型质量已经达到业界领先水平。

另外，摩尔线程也在证明，国产 GPU 已经在完成从预训练到强化学习的全流程闭环。

北京大学 EvoPhys 团队在摩尔线程”灯塔计划”支持下推出的 5D 世界模型 EvoPhys-World，其原生训练全程都在摩尔线程 MTT S5000 全功能 GPU 上完成，并由 MUSA 软件栈提供全栈支撑。该模型在斯坦福大学 WorldScore 公开评测榜单中，拿下了“世界生成”赛道第一名。这也证明摩尔线程智算集群的高效训练能力，已不仅覆盖大语言模型，在具身智能与世界模型上同样取得突破。

除 EvoPhys 外，摩尔线程还使用 MTT S5000 千卡级集群训练 Wan 类视频生成模型，并与北京智源研究院完成 RoboBrain 2.5 具身大脑模型训练；极佳视界也基于 MTT S5000，开展具身世界模型和世界动作模型训练。

第二座工厂：推理竞争转向 Token 成本

如果说训练工厂决定模型能力的上限，那么词元生产工厂决定了 AI 能否实现规模化商业应用。

进入智能体时代后，推理成本的重要性正在迅速超过训练成本。模型能力越强、调用链越长，企业需要承担的 Token 成本就越高。对于大规模应用而言，即使单次调用成本只下降几个百分点，累积到每天数十亿、数百亿甚至万亿 Token 后，也会形成巨大的成本差异。

因此，词元生产工厂的核心目标不是简单提供算力，而是将不同模型快速部署，并在延迟、吞吐量和成本之间取得平衡。

摩尔线程的推理软件栈原生适配 SGLang 和 vLLM，同时支持 PyTorch、MT-Transformer 和 TensorX 等推理方式。针对传统视觉和行业模型，平台还兼容 ONNX、TensorFlow 和 PaddlePaddle，以同时覆盖 AI 1.0 时期的视觉识别负载与当前的大模型、多模态推理负载。

在大模型领域，其平台已经深度支持 DeepSeek、MiniMax、GLM、Kimi 和 Qwen 等国内主流模型，并实现了 “发布即适配”。这种适配速度对国产芯片尤为重要。当前模型结构和推理框架变化很快，如果一款芯片需要数月才能支持新模型，即使硬件性能足够，也可能错过商业部署窗口。

为了降低推理成本，摩尔线程对 KV Cache、常用算子、融合算子和超大算子进行优化，并提升整体吞吐量。公司称，MTT S5000 在部分大模型推理场景中能够达到与国际主流 GPU 接近的性能水平；随着 Batch Size 增加，吞吐量还可以保持较明显的增长。

不过，摩尔线程在词元生产工厂中提出的更重要方案，并不是用国产 GPU 完全替代企业现有设备，而是通过异构推理重新利用存量算力。

许多企业此前已经采购了不同品牌、不同代际和不同规格的 GPU。随着模型负载变化，部分设备可能不再适合独立承担完整推理任务，但仍然具备计算或带宽优势。与其整体替换，摩尔线程希望通过 PD 分离方式，把不同阶段交给更合适的芯片。

大模型推理通常可以分为 Prefill 和 Decode 两个阶段。Prefill 主要处理用户输入和上下文，计算密集度较高；Decode 则逐 Token 生成结果，对显存带宽和低延迟要求更高。摩尔线程提出，将 Prefill 计算池部署在 MTT S5000 上，将 Decode 生成池部署在企业已有的国际主流 GPU 上，通过异构调度形成统一推理流水线。实际测试显示，通过 PD 异构分离，可实现“3 台 MTT S5000 + 2 台国际主流 GPU = 9 台国际主流 GPU”的等效性能，为企业用户探索出一条极具成本优势的国产化大模型混合部署路径。

这有很大的现实意义。

趋境科技创始人、首席执行官艾智远表示，公司目前已经具备日均万亿级高品质 Token 供应能力，并通过将摩尔线程 GPU 与国际主流 GPU 结合，在 PD 分离异构推理中实现成本与性能互补。MiniMax 副总裁薛子钊也提到，多芯片适配将成为提高训练和推理效率的重要方式。

除语言模型推理外，摩尔线程还将图形计算能力纳入词元生产工厂。与主要面向矩阵计算的 AI 加速器不同，全功能 GPU 同时具备 AI 计算、图形渲染和视频处理能力，这使其可以承担 3D 高斯泼溅（3DGS）、4DGS 和数字孪生等新型负载。

摩尔线程自研了轻量化 3D 重建技术 3D LiteGS，以及 3D 语义理解技术 UniSem。公司还支持 VGGT 等开源模型，与极佳视界合作的结果显示，在部分 3D 场景生成和渲染任务中，MTT S5000 的性能与画质已经接近国际主流 GPU。

这也意味着，未来的词元生产工厂可能不只生产文本 Token，还会生产图像、视频、三维空间和数字世界。随着世界模型和空间智能发展，图形渲染能力可能重新成为 AI 计算平台的重要差异化因素。

第三座工厂：从生产模型走向生产智能体

如果说模型训练工厂生产的是模型，词元生产工厂生产的是推理结果，那智能体工厂要解决的问题，是如何把模型变成能够稳定完成任务的数字员工或物理机器人。

摩尔线程将智能体分为两类：一类生活在软件和互联网环境中，负责写代码、搜索信息、操作应用和完成内容生产；另一类进入现实世界，控制机器人和自动化设备。

针对数字智能体，摩尔线程自研了全域智能体“小麦”。公司披露，“小麦”目前掌握 60 余项技能，可以控制 38 款应用，并能够结合多种前端模型和知识库执行跨应用任务。与普通聊天机器人不同，这类智能体的重点并不只是回答问题，而是能否理解用户意图、保持长期记忆、选择正确工具，并完成从任务接收到结果交付的完整闭环。

在物理智能体领域，核心挑战则从语言理解转向安全、控制和真实世界泛化。机器人在进入工厂、家庭和公共空间前，不可能依靠大量真实试错完成训练。如何在数字环境中模拟重力、碰撞、材质、光照和传感器数据，再将训练结果迁移到真实设备，成为具身智能产业化的关键。

为此，摩尔线程推出全栈具身智能仿真平台 MT Lambda。该平台集成 MuJoCo、Newton 等开源物理仿真引擎，并提供 MuJoCo-MUSA 和 Newton-MUSA 加速版本，同时加入自研物理引擎 AlphaCore。图形侧则结合 3DGS、AI 生成式渲染（AI Generative Rendering，AGR）和光线追踪技术，构建高度拟真的数字孪生环境。

摩尔线程强调，MTT S5000 不仅能够训练和推理，还具备硬件光线追踪及图形渲染能力。在 MT Lambda 中，开发者可以先让机器人在虚拟环境中学习动作，再将策略迁移到真实机器人，实现从仿真到现实（Sim-to-Real）。公司现场展示的机器狗案例中，虚拟环境中的跳跃动作与真实机器狗执行结果保持较高一致性。

具身智能训练还需要规模化。单个机器人在单一环境中进行训练，数据生成速度和场景丰富度都十分有限。MT Lambda 因此支持从单颗 GPU 扩展到数百卡乃至上千卡集群，使大量机器人实例可以同时在不同虚拟环境中训练。

这一思路与当前世界模型和机器人基础模型的发展方向一致：未来的机器人能力，不只是由某个控制算法决定，而是由仿真环境、数据生成、强化学习、视觉模型和硬件平台共同生产。所谓智能体工厂，本质上就是将这些环节组织成一条可以反复运行、持续改进的流水线。

值得注意的是，支撑”三大工厂“体系的另一条主线是 MUSA 生态。

全球 AI 软件和算子长期围绕 CUDA 建立，即使国产芯片在部分性能上接近国际产品，如果开发者需要大规模重写代码，其迁移成本仍然可能阻碍商业部署。

摩尔线程围绕 MUSA 提供 Musify 和 AutoMusify 等自动迁移工具，并进一步推出 MusaCoder 代码大模型和 MUSACODE 编程智能体，希望使用 AI 降低生态迁移成本。MusaCoder 主要用于生成代码和 MUSA Kernel 算子，MUSACODE 则可以自动分析代码、执行迁移并处理部分适配工作。

也可以看出，AI 本身开始成为国产计算生态的迁移工具：芯片厂商可以使用自有算力训练熟悉自身架构的代码模型，再由智能体协助完成算子转换、性能调优和错误修复。

另外，摩尔线程还推出了 AI 算力本 MTT AIBOOK、家庭 AI 中枢 MTT AICUBE，并以 MUSA 软件生态将底层 GPU、智算集群、模型框架、智能体平台和终端连接起来，最终形成边缘与智能终端的完整硬件矩阵，以软硬协同推动全场景智算落地。

不同行业提出的真实反馈

三大 AI 工厂能否成立，最终不能只依赖芯片厂商自身的产品描述，还需要模型公司、云平台、Token 服务商、世界模型企业和集群运营方在真实业务中验证。摩尔线程的这一战略主张就是基于不同产业伙伴，从企业应用、物理智能、模型研发和集群运维等环节的实践经验抽象而来。

京东集团技术委员会主席、京东云总裁曹鹏表示，京东云需要的并不是孤立算力，而是一套能够贯穿算力、模型和智能体应用的全栈系统。为此，京东云正在围绕摩尔线程 MTT S5000 开展训练、推理引擎和具身智能适配，并通过异构调度统一管理不同算力资源。

曹鹏进一步透露，在京东的模型工厂中，结合摩尔线程 MTT S5000，在模型的训练、适配、调优上取得了非常好的进展。最新发布的一系列 JoyAI 大模型，相当一部分训练的算力依托于摩尔线程提供的国产化算力。他表示，京东下一步的具身工厂建设中，摩尔线程的渲染等计算优势也将帮助京东在数据生成与具身仿真上取得突破。

在模型训练方面，极佳视界与 EvoPhys.ai 的实践进一步证明，物理 AI 正在带来与语言模型不同的新型算力需求。MiniMax 也从前沿模型研发角度提出，算力需求还将被模型自我改进进一步放大。在 M3 的后训练过程中，MiniMax 尝试让 AI 自主构建强化学习环境、生成数据、运行评测、分析结果并修改训练代码，连续完成近百轮自动迭代。薛子钊判断，“今年是国产芯片很重要的拐点，越来越多真实的线上场景开始承担推理和训练任务”。这意味着，未来模型训练可能不再是人类预先设定好流程后一次性运行，而是由模型自主提出实验、修改代码并持续迭代。训练任务将从阶段性项目转变为长期运行的自动研发系统，对算力调度、实验反馈和集群稳定性提出更高要求。

在 Token 生产方面，趋境科技的实践则将“词元生产工厂”从概念转化为明确的商业指标。其关注重点不是拥有多少张卡，而是每天能否稳定供应万亿级高品质 Token，并满足企业对延迟、吞吐、上下文和稳定性的要求。

艾智远认为，国产 GPU 进入生产环境的现实路径，不一定是立即完全替代海外芯片，而是先通过 PD 分离和异构部署承担 Prefill 等适合的负载。这种模式可以在降低 Token 成本的同时，利用企业已有存量设备。艾智远还给出实测结论：经过完整上线测试，“4 台摩尔线程 MTT S5000 的 Prefill 性能超越一台 B300 整体性能”，摩尔线程 MTT S5000"基本能够跟国际主流 GPU 实现投资回报率打平"。

无问芯穹的实践则补充了“三大工厂”中经常被忽略的一环：算力只有稳定运行，才能成为真正产能。

无问芯穹技术副总裁吴保东表示，在大规模 GPU 集群中，硬件、网络、存储和训练任务会产生大量复杂故障，若依赖人工，处理一次故障平均约需 1 小时。通过与摩尔线程合作构建的运维智能体系统，其团队将复杂运维问题的处理时延从约 1 小时缩短到 20 分钟以内，困难问题的正确率也从不足 45% 提升至 90%，接近人类专家水平。

可以看出，各行业对底层 AI 基础设施的需求重点并不相同，如何更好满足这些需求是现实且急需解决的问题。

结束语

Token 经济的到来，正在从根本上改变底层算力的组织方式。

未来企业不会只问自己拥有多少张 GPU，而会问这些 GPU 每天能够产生多少高品质 Token、完成多少模型训练、支撑多少智能体任务、维持多高在线率，以及最终能够创造多少业务价值。摩尔线程从模型训练工厂、词元生产工厂到智能体生产工厂这三个维度，来回答当下 token 经济时代提出的新问题。

实际上，这也是国产 GPU 下一阶段需要真正面对的考验：不仅要证明芯片能够运行模型，更要证明芯片、软件、网络和应用组成的整套系统，能够持续、稳定、低成本地生产智能。

开源如何促进平台构建过程中的协作

作者：Ben Linders — Mon, 20 Jul 2026 09:00:00 GMT

在 KubeCon & CloudNativeCon 欧洲大会"上，Marcy Paramonova 和 Stéphane Cusin 发表了题为“在银行中构建云原生文化"”的演讲。他们指出，平台是一种协作系统：平台团队依赖于应用团队，两者需要共同的标准。工程师对平台的信任源于其可预测的行为，而非其功能。

Cusin 提到，开源为我们提供了亟需的东西：一套在团队、供应商和各类工具之间通用的共享标准与统一语言。在银行环境中，开源并非一个显而易见的选择。人们对技术支持和责任归属等问题存在诸多疑虑。

Cusin 认为，银行业环境首先需要信任：

信任并非一蹴而就的决定。它是通过日复一日地运营平台以及保持一致性而建立起来的。作为平台工程师，我们了解到，开发者信任一个平台并非因为它的功能，而是因为它的行为可预测。

Paramonova 表示，平台是一种协作系统。开发人员和产品团队依赖于平台团队。平台团队依赖于应用团队，双方需要共同前进；为此，他们需要共同的标准。

Paramonova 指出，开源用户不仅使用这项技术，还会为其做出贡献，围绕它建立社区，并就技术问题交流想法。我们对这种交流的一种诠释就是我们的“天才吧”活动：

我们希望跳出以往仅提供技术支持的常规模式，为用户带来一些新颖的内容。我们曾经开设过开放式支持环节，用户可以随时前来，我们会与他们一起解决问题。随着时间的推移，越来越多的人对此产生了兴趣。实际上，已经有许多基础设施团队加入了我们。

Paramonova 表示，工程师可以通过提升软技能获益，这有助于大家更好地协作。她提到，他们采取了一种社区驱动的方式，即人们围绕技术创建并维护各类俱乐部或社区。

Paramonova 指出，责任感的增强改变了工程师之间的互动方式。公司不仅信任他们能够完成任务，也信任他们能够做出实际决策并产生切实的影响。

Paramonova 提到，作为一名工程师，关键在于解决问题并对此充满热情。而成为一名工程师，也意味着要分享你对解决问题的热情。

Cusin 表示，开源不仅仅是一种软件选择，更是一种承诺。如果只是更换工具，却不改变人们的思维方式、协作方式和开发方式，最终会陷入僵局。

Cusin 提到，开源从来都不是管理层下达的指令，也从来不是必须恪守的教条，也不存在“没有人告诉我们必须使用开源”。Cusin 总结说，它更像一个指南针，帮我们在这个领域找准了前进的方向。

在演讲结束后，InfoQ 采访了 Marcy Paramonova" 和 Stéphane Cusin" 。

InfoQ：你们采取了哪些措施来赢得平台用户的信任？

Stéphane Cusin：我们在标准化、自动化和运营卓越性方面投入了大量的资源。无论团队将应用部署到开发、测试还是生产环境，都应该拥有相同的体验和预期。我们还明确了平台的职责范围。各团队都清楚地知道哪些服务由平台团队负责运维、可以期待什么样的服务水平，以及自身的运维职责从何处开始。另一个重要的方面是减轻认知负荷。我们没有将 Kubernetes 的每一项功能都暴露出来，而是尝试提供合理的默认设置和具有明确指导性的工作流，使开发人员应该能够专注于自己的应用程序，而不是去理解底层基础设施的复杂性。Marcy Paramonova：在推出新组件或新功能时，我们不会等到它们臻于完美才与用户分享。我们会让用户了解我们的工作内容及背后的原因。事实证明，这种透明度比一个精雕细琢的产品更有价值。用户不再是被动的消费者，而是成了早期测试者和合作伙伴。随着时间的推移，依托这种关系所构建出来的成果，是任何发布公告都无法比拟的。

InfoQ：你们的工程文化随着时间的推移发生了怎样的变化？

Paramonova：开源社区有着独特的文化。他们会记录决策过程，积极回馈社区，并明确责任归属，让人们清楚谁负责维护某个组件、谁负责决策，以及遇到问题时该向谁寻求帮助。我们试图将这些实践内化。当你采用 Kubernetes 时，你不仅仅是在采用一个容器编排工具，你是在加入一个拥有明确规范、预期和协作方式的社区。这促使我们走向了更大的透明度、更广泛的共同责任感，以及更强的工匠精神。这种文化的转变并非源于某人宣布了一项文化倡议，而是因为工具要求采取特定的工作方式。随着时间的推移，这种工作方式逐渐成为了我们自己的。

原文链接：https://www.infoq.com/news/2026/07/open-source-platform/"

无问芯穹夏立雪：数字世界与物理世界的所有AI生产力运行，都需要 Agentic Infra

无问芯穹 — Mon, 20 Jul 2026 08:41:21 GMT

“计算需求在指数级攀升，今天，仅依靠产能的线性增长去堆叠算力，已经远远无法弥合供需之间持续扩大的缺口。”

7月20日，2026年世界人工智能大会上，无问芯穹联合创始人兼 CEO夏立雪提出，从Pre-training（预训练）到Post-training（后训练）、从Test-time（推理时扩展）到Agentic scaling（智能体扩展），在四条Scaling Law的作用下，模型训练和推理的超级市场正在互相孕育。

当下的人工智能基础设施（AI Infra）“必须以极致的效率服务更大规模。”

基于规模与效率两大锚点，夏立雪从无问芯穹的AI生产力公式（AI生产力=智能资源规模× Token转化效率× AI生产力转化效率）出发，首次公布无问芯穹Agentic Infra的“前店后厂一中心”战略布局，涵盖三大核心技术能力与产品服务体系：

“算力集散中心”：Agentic Infra自主式基础设施平台；“Token工厂”：Agentic MaaS大模型服务平台；“AI生产力商店”：Agentic Infra行业解决方案。

这套Agentic Infra产品与服务体系立足基础设施，向下汇聚能源和芯片，向上支撑模型和应用，不仅极致提升底层资源向AI生产力转化的规模和效率，更有着Agentic AI时代最显著的AI原生能力——用基础设施智能体蜂群赋能资源规模扩展、提效Token生产，并支持Agentic AI的持续进化。

Agentic Infra自主式基础设施平台，服务下一代Agentic AI在线进化

无问芯穹Agentic Infra自主式基础设施平台的核心目标，是实现智能资源规模最大化。它就像一座“算力集散中心”，把散落的、异构的算力资源统一汇聚、弹性调度、按需分发，为模型与应用层筑牢充足、稳定、可扩展的算力底座。

夏立雪认为：“算力的异质化、碎片化问题是全球性的，如何把不同的、跨区域的算力资源，高效聚合协同起来，是扩大智能资源规模的关键。”

无问芯穹自成立以来一直致力于通过“多元异构、软硬协同”技术破解异质算力聚合的难题，打造了面向异构集群的大模型跨域训练系统，并集成于Agentic Infra自主式基础设施平台软件中，通过计算通信重叠的流水编排、自适应的通信流调度和异构算力调度机制，三位一体全栈协同优化，能够系统性地破解算力聚合的行业难题。

该系统已经受过三大类跨域算力聚合训练实践的生产级考验：

第一是超远距离聚合。无问芯穹已联合中国电信，完成了国内首例超4000公里距离的大模型跨域混训，在新疆哈密与广东深圳两地集群间，实现联合训练性能提升165%，验证了超远距离跨域集群协同训练的可行性。

第二是多数据中心聚合。打通4个不同代际、不同型号的GPU集群，联合训练近百亿参数大模型，四集群协同性能提升41%，有效盘活了不同批次的存量异构算力。

第三是混合云算力聚合。实现本地私有集群与公有云算力的安全互通混训，整体性能提升68%，帮助众多企业客户解决本地算力不足、云上资源却闲置的错配痛点。

目前这套跨域训练系统已在全国部署触达超37,000P算力、覆盖16种主流芯片，盘活了广域分散的异质算力，使之成为Agentic AI时代的最坚实底座。

当下，强化学习成为下一代AI进步的重要手段。但相较传统预训练，强化学习“多角色协同”的特性使其对硬件的种类需求更加复杂，规模量级也更加庞大，基于异构和超大算力规模的双重刚需，跨集群强化学习因此成为智能规模化及持续进化的新锚点，这也是无问芯穹Agentic Infra自主式基础设施平台重点布局与攻克的核心场景。该场景存在两大重要问题：一是跨集群之后，不同角色之间的等待时间将被拉长；二是当规模扩大到万卡级后，从显卡到服务器、网络、存储，故障将以小时级的频率存在，而重新拉起任务耗时长达数十分钟，任务难以持续稳定运行。

因此，针对跨域强化学习场景，无问芯穹把全栈协同的技术思路贯穿到底——从网络、平台到框架做一体式深度优化，打通分散的异构集群，实现全局资源一盘棋调度。

在此之上，无问芯穹进一步将优化渗透进全链路的每一个环节，尤其是在跨域通信和容错这两个层面：通过优化计算通信重叠技术，让跨域通信效率直接提升3-4倍，实现通信开销100%全掩盖，训练不再因跨域通信产生额外耗时损耗；同时搭建了故障无感的训练机制，成功实现了跨域强化学习训练连续一周0中断稳定运行。让大规模跨域强化学习不仅可以“跑得通”，还能“跑得快、跑得稳”。

“这只是一个起点。”夏立雪表示，伴随着大规模跨集群强化学习训练技术的持续成熟突破，无问芯穹还将持续深耕并行策略、通信融合、智能算子、极致容错等核心技术，“未来，我们能够将跨域计算资源的支撑规模，持续拓展至十万卡级以上，支撑下一代Agentic AI的在线进化。”

Agentic MaaS大模型服务平台，无问芯穹Token工厂以“效”搏大

Token经济时代，无问芯穹早在2023年初就提前布局的Agentic MaaS大模型服务平台，目前正在迎来高速且持续的增长曲线。该平台就像一座“Token工厂”，核心目标是用极致效率服务Token的规模化、高质量生产。

发布会现场，夏立雪用千卡至万卡规模下完整推理服务技术栈揭示了一座Token工厂内部的可优化空间，“从网关、路由，到底层推理实例，Token工厂层层可优化、处处有增量。”

随后，夏立雪披露了无问芯穹首创的新一代推理系统优化成果——跨集群异构PD分离架构（Prefill-RelayDecode-MainDecode, PDD）。

智能体推理需求的特征有“三极”：上下文极长、交互轮次极多、缓存命中率极高，对吞吐、时延、缓存复用的要求，远高于传统对话场景。同时，从实测数据中能直观看到，不同芯片在Prefill、Decode阶段的性能差异极大。而眼下，这些散落在不同地区的存量集群几乎都是同构的，且几乎每个集群都“偏科”。

因此，该架构首先用高性价比的广域网以太网把分布在各地的、已经建好的同构数据中心连起来，让算力强的集群做Prefill任务，让显存带宽高的集群做Decode任务。这一架构设计相当于让“偏科”的硬件只刷自己最擅长的题，可以极大提升大模型推理系统效率，是每座Token工厂都必备的“超级管线”。

然而，基于以太网的KV Cache跨集群传输，存在带宽和延迟瓶颈，这根“超级管线”既要能扛住智能体业务的巨大“流量”，也要能跟得上用户对“流速”的极致要求。

基于Agentic MaaS线上业务长期的大规模实践积淀，无问芯穹推理团队首先把为了Decode实例重复前缀存储去重而设计的Decode Radix Cache技术，创新性地迁移至跨集群异构PD分离架构之中，实现跨集群KV Cache传输数据量降低一个数量级，让“流量过载”的难题迎刃而解。

其次，更大的挑战在于“流速”——智能体的响应速度，是最直观的产品体验底线。

PDD将传统的PD分离链路“P-D”创新解构为“P-RLD-MD”的三级分离式推理架构，就像是为这条“超级管线”加装了一个“精密增压阀”。对于高传输延迟的请求，RelayDecode先行输出Token给用户，从而让用户侧完全感受不到这一实际上长达数十秒的传输延迟；当传输完成后，输Token给用户的任务被无缝切换给MainDecode来处理，避免了RelayDecode被长期占用。通过这一设计，仅需极少量机器承担RelayDecode，就能掩盖以太网KV Cache传输延迟。

实测显示，该架构在实现了首Token延迟（TTFT）降低51.5%的同时，单Token成本可降低37.5%。这不仅意味着用户端速度体验的显著提升，更意味着，每一个集群都能被充分利用起来，最大化释放全域异构算力的产业应用价值。

过去一年里，无问芯穹的Token工厂已通过一系列原始技术创新，推动了推理成本的10倍下降。夏立雪判断，随着跨集群异构PD分离架构的规模化落地，推理成本依然有10倍的下降空间。

“目前无问芯穹的Agentic MaaS大模型服务平台的增长飞轮已经全面转起来了！”夏立雪表示。

技术迭代驱动成本下降，业务规模加速技术创新。通过与Kimi、智谱、Minimax、阶跃星辰等头部大模型企业的密切合作，无问芯穹在真实业务场景中持续打磨、积累了大量优化经验。截至7月，平台单日Token调用量较去年12月，已实现了40倍的爆发增长，而海量业务经验又能反哺技术快速迭代，催动平台性能与可靠性的同步跃升，形成“业务带技术，技术提效率，效率促增长”的正向循环。

夏立雪总结：“6月的GTC上，黄仁勋展示了英伟达的‘算力即收入’曲线。无问芯穹的Token工厂，则希望用这个‘优化即利润’的增长飞轮，向推理时代交出Token效率的答卷。”

无问芯穹已携手上海移动联合打造了“沪芯沪产服务沪客”的“天问”模型服务门户，也与AI原生新世代社区“观猹”联合打造了“中国版OpenRouter” TokenDance（词元跳动）平台。未来，无问芯穹将持续携手优秀的行业伙伴，以这套高效的“Token工厂”赋能更多产业领域、服务更广泛客用户。

Agentic Infra行业解决方案，以AI原生赋能百业提效

依托“算力集散中心”与“Token工厂”，无问芯穹可以将计算资源高效转换成高质量Token。然而相同的业务效果，基于不同的推理路径、模型规模和芯片，Token的成本天差地别，深度影响其在真实生产环境中的商业化潜力。

为此，无问芯穹正通过Agentic Infra行业解决方案，携手多行业伙伴把Token高效转化为产业真正认可的高质量AI生产力，它就像一个“AI生产力商店”，持续赋能千行百业降本提效。

现场，夏立雪带来了覆盖文娱游戏、医疗健康、法律终端、能源电力等多个垂直行业的Agentic Infra行业解决方案。

在文娱游戏场景，无问芯穹携手VAST的Tripo 3D大模型联合打造了AGENTIC 3D GAME GEN解决方案，把分散的创意输入转化为可执行、可比较、可细化的3D模型输出，高效释放游戏内容生产力。

在医疗健康场景，无问芯穹服务上海瑞金医院算力及模型管理，助力医疗大模型及智能应用在运营管理、临床诊疗辅助、医学教育培训等场景的探索落地。

在法律终端场景，无问芯穹打造律师事务所专属AI合伙人——”律盾芯人“，与“段和段律师事务所、君合律师事务所、竞天公诚律师事务所、通商律师事务所”等行业私有化AI终端合作伙伴，以及“法义经纬、图灵法思”等生态合作伙伴一起，共同推动法律行业的智能化安全升级。

在能源电力场景，无问芯穹也正与南网能源一起深度探索基于智能体技术的智算中心能耗智能预测与协同调度解决方案。

基础设施自己本身也是个行业，无问芯穹已经在这个行业深耕多年，既积累了丰富的实践经验与技术，也拥有足够多的应用场景与需求。因此在支撑千行百业智能升级的另一面，无问芯穹也持续将智能体的能力应用到AI Infra 本身，打造了一套基础设施智能体蜂群。

遵循“用智能体赋能基础设施，提升计算规模和智能效率”的核心目标，无问芯穹基础设施智能体蜂群目前已包含三个子集，对应在 AI 生产力转化、智能资源规模、Token 生产效率的三方面：面向用户的平台管家智能体系统、面向集群的运维智能体系统、以及面向芯片的算子生成智能体系统。

夏立雪提到：“我们不仅用 Agent 赋能资源规模扩展、提效 Token 生产，更致力于以 Agent 能力驱动整套 AI Infra 形成自主迭代、自我优化的闭环，让基础设施越用越强。”

平台管家智能体系统是整个基础设施智能体蜂群协同场景下的全局统筹者与用户入口，它有效降低了用户驾驭复杂系统的学习成本，通过自然语言交互，就能让智能体主动帮助用户操作平台、统筹AI基座，轻松高效完成复杂的资源运营、管理和答疑排障等工作，能够独立解决80%日常问题，剩下20%深度问题再转交对应垂类Agent。

智算集群运维智能体系统是一个能够端到端地解决实际生产场景中的运维难题的 7×24小时全天候值守的“运维专家团”，系统以运维主智能体为核心大脑，与故障排查智能体、环境部署智能体、故障处理智能体等协作运行，不仅可以完整执行一个集群的告警自动闭环处置任务，还能够“防患于未然”地规划周期性巡检任务，提前识别潜在隐患。让智算集群的运维从“人找问题”转变为“问题找人”，和“问题自己解决”。

经过大规模生产环境验证，这套系统的价值正在逐渐凸显：可实现运维人效提升5倍以上，关键故障处理效率提升6倍，不仅为大规模GPU训练与推理业务提供了更加稳定、高效的基础设施保障，也让运维人力能够被真正解放出来，聚焦更有价值的技术创新。

算子，是释放AI硬件性能的最后一公里，同时也是拉开基础设施效率差距的关键变量。目前，大模型已经能够快速产出算子，但“能跑通”不等于“能用好” ——要在生产环境中实现性能超越成熟推理引擎、达到工业级落地标准，难度依然极大。

无问芯穹高性能算子生成智能体系统KernelMind，以算子生成主控智能体为调度中枢，联动多类专用智能体，通过“需求分析—智能调度—内核生成—沙箱验证—评审沉淀”五步闭环工作流，可在真实编译试错与知识沉淀中持续自迭代，稳定交付可直接落地的高质量工业级算子。

在GLM5.2模型的实测中，对比行业基线该系统在NVIDIA旗舰卡中实现了端到端7.3%的性能提升，在AMD旗舰卡中更是带来了39%的整体性能跃升，GEMM、Attention、Router等各类核心算子性能均实现全面超越。

早在2025年，无问芯穹就已经在业内率先提出了Agentic Infra的范式变革。如今，Agentic Infra支撑智能体规模化运行与持续进化的产业价值正在被不断验证。从概念到落地，无问芯穹始终坚持以硬核技术推动Agentic Infra走向真实业务场景。夏立雪提到：“我们的愿景始终清晰而坚定：通过Agentic Infra，实现'用智能进化智能，用生产力加速生产力'。”

One More Thing：迈向物理世界

演讲最后，夏立雪将视野从云端的数字世界延伸至真实的物理世界。他提出：“在物理世界中，具身智能的Scaling Law同样需要高效率、大规模的基础设施支持。”

现场，无问芯穹公布了在具身智能领域的全新探索——首个面向大规模具身任务的云边端一体化管理与调度平台。该平台首次把云端GPU集群、边缘算力节点和机器人真机设备统一接入到一个平台中，支持训练、数据采集、评测和真机执行等多种具身任务统一编排运行，有效解决了具身训练中资源分散、跨集群协同困难、任务角色复杂、真机状态不可见、启动链路长的问题。

同时，针对具身智能的训练与推理部署两大核心环节，夏立雪宣布了无问芯穹两项重磅技术升级：面向具身智能的大规模真机强化学习训练框架RLinf V0.3 ，以及面向机器人与端侧AI场景的全栈的推理优化体系Mizar-Robo。

RLinf在V0.1版本中实现了在仿真环境下渲训推一体化的强化学习；在V0.2版本中实现了像管理GPU一样管理真机设备；而V0.3版本的升级则新增支撑具身智能大规模真机、跨域端云协同的强化学习训练，支持具身智能的持续进化。

从实验室到产业，无问芯穹也与智元、清华大学携手深度探索了真机强化学习训练的技术与实践，攻克阻碍真机强化学习训练大规模落地的核心痛点与难点。通过首创的HotSwarm与端云协同训练模式，RLinf V0.3可以支持真机设备1000+次在线上下线，训练0中断，并成功实现近百台真机规模专线需求降至2Gbps以下，大幅拉低具身智能规模化训练的成本门槛。

Mizar-Robo则依托流水线调度、算子内核、量化压缩、计算图四层协同优化，全方位释放端侧硬件潜力，大幅提升具身模型的部署效率，让具身智能即便在低功耗硬件上，也能实现连贯流畅、低延迟、长续航的高精动作交互。

在无问芯穹与自变量机器人WALL-OSS系列模型的联合优化部署中，在保持WALL-OSS原有任务成功率的前提下，实现了7.14倍的推理性能提升，经Thor平台实测，端侧推理时延从500ms压缩至70ms，降幅达86%。不仅保障了实时交互的流畅度与稳定性，也有效延长作业续航，为机器人产品从实验室走向规模化商用落地，提供了有力的基础设施支撑。

“让智能无所不能，是AGI，而让智能无处不在，是AGI Infra。”夏立雪在发布会的尾声中说道。“AI无疑是目前世界上发展变化最快的行业，但我们的初心从未改变，就是做AGI时代最需要的AI Infra。”

从“算力集散中心”做大资源总盘，到“ Token工厂”深挖效率红利，再到“AI生产力商店”循环造血向产业输出价值，乃至向物理世界AI的探索与实践，无问芯穹始终锚定“规模与效率”两大支点稳步向前。

“前店后厂一中心”的Agentic Infra体系，既是无问芯穹积淀多年的战略蓝图系统性落地，也代表着无问芯穹锚定AGI时代的长期方向：为未来数字与物理世界的所有AI生产力的运行构筑基础设施。

亚马逊云科技概要介绍了某客户如何将 Lambda 函数扩展至 100 万个

作者：Matt Foster — Mon, 20 Jul 2026 07:17:00 GMT

亚马逊云科技概要介绍"了工业可穿戴设备制造商 ProGlove 如何扩展其 SaaS 平台，以运行分布在数千个专属客户账户中的超过 100 万个 AWS Lambda 函数。

在亚马逊云科技架构博客的一篇文章中，该团队将其成功归功于“每个租户一个账户”的模式、借助 CloudFormation StackSets 实现的广泛自动化，以及激进的“缩减至零”策略（可以将闲置成本

控制在每个账户每个月 1 美元以下）。

ProGlove 选择将每位客户隔离在各自的 AWS 账户中，以额外的运维开销为代价换取更强的安全边界、独立的服务配额，以及清晰的按客户分摊成本的机制。

亚马逊云科技指出，当平台账户数量超过 50 个后，这一决策导致了运维摩擦。

每个客户账户内包含若干微服务，通常是 5 到 15 个 Lambda 函数，由 Step Functions 状态机进行协调。该状态机负责采集扫描器读数，将其持久化到 Amazon DynamoDB 中，并将业务事件发布到共享的 Amazon EventBridge 总线，供 ProGlove 的分析平台消费。

手动配置不仅拖慢了发布速度，还暴露了服务配额上限的问题。因此，工程师们将 AWS Organizations、Step Functions 和 CloudFormation StackSets 整合为一个工作流，通过单个管道创建和更新每个账户。该团队表示，与亚马逊云科技服务工程师的合作提升了 StackSet 的吞吐量，使得该机制能够将变更同步到数千个账户中，其中合计托管着超过一百万个 Lambda 函数。

图片来源：亚马逊云科技

亚马逊云科技报告称，配额并非唯一的扩展挑战。早期 cron 风格的调度会在所有账户中于同一时间触发同一函数，这会引发工程师们所描述的“自酿” DDoS 攻击。

他们用抖动执行窗口和事件驱动的触发器取代了僵化的定时器，从而平滑了各区域的负载，而且不需要依赖预留并发数或预配置容量。

可观测性成本也呈现出类似的走势。每个 Lambda 函数都会生成日志和指标；乘以数千个账户后，由此产生的体量几乎占据了账单的绝大部分。ProGlove 将高优先级的故障整合到了一个中央死信队列中，并删除了未使用的 Amazon SQS 队列。根据博文所述，这些变更将每个账户的闲置支出降到了 1 美元以下。

其他地方也出现了类似的运维问题。Capital One 指出"，标准化部署、可观测性和治理实践对于在大型组织中一致地运行 Lambda 工作负载至关重要，并且认为，技术规模的扩展还需要运维标准化的支持。

亚马逊云科技的这篇博文还指出，自动化本身也做了一些权衡取舍。StackSet 的部署速度仍然慢于单账户的 CloudFormation 部署，而日志集中化则在一定程度上降低了部分租户级粒度。鉴于在隔离性、成本透明度和运维一致性方面带来的改进，团队认为这些取舍是可以接受的。

ProGlove 的经验揭示了一种模式：首先采用强制执行硬边界的租户模型，尽早自动化所有基础设施操作，并将可观测性方面的投入视为首要的扩展约束。DoorDash 的无服务器迁移案例"也体现了类似的主题，约束严格的自动化确保了每日超过一千万次的 API 调用没有超出并发限制。尽管具体策略各不相同，但其共同点在于：远在容量紧张的问题出现之前，成本和配额的可见性就已经促成了架构选择。

原文链接：https://www.infoq.com/news/2026/07/aws-lambda-1m/"

专访孙元浩：乘坐星环号，把数据库“移民火星”的人

王玮 — Mon, 20 Jul 2026 07:07:06 GMT

“把数据库迁到 GPU，就像移民到火星。”

在 WAIC 2026 的现场，星环科技创始人、CEO 孙元浩口中的这场“火星移民”，正随着其面向 AI Agents 的 GPU 原生认知数据库预览版的发布，成为可落地的现实。AI 时代，星环科技要重写整个数据库。

然而，当被问及底层技术究竟如何实现“重写”时，孙元浩却笑着卖了个关子：“这个我们就不告诉别人了。”

这段发生在 WAIC 2026 星环科技展区上的现场采访，之所以让人印象深刻，部分原因在于这位技术掌门人对自家产品战略的绝对笃信，部分原因在于同样身为一名科幻迷的他，有趣的思考方式——关于速度，关于火星，关于 AI Infra 领域的一种理想主义。

“快”的含义变了

星环科技创业初期，曾提出要打造世界上最快的大数据处理引擎。

“星环”这一公司名字，来自科幻小说《三体》中的“星环号”，人类第一艘实现光速飞行的飞船，也寄托着公司对极致速度的追求。

当时，数据库对性能的需求主要来自数据规模的增长。企业数据从几个 GB 增长到数百 TB、数 PB，甚至更大的规模，单台服务器无法完成处理，只能依靠分布式计算，将数据和任务拆分到更多机器上执行。

在那个阶段，“快”意味着能够在可以接受的时间内处理更大的数据量。

AI Agents 出现后，数据库对速度的要求发生了变化。单次处理的数据量未必很大，但调用次数变得极其密集。

过去，人类用户查询一张报表，等待几秒钟可能并不会严重影响体验。但在 Agent 的执行链路中，一次查询延迟会传递到下一步推理，下一步推理又可能触发新的查询。任何一个环节的等待，都会在循环中不断累积。

因此，AI 时代数据库追求的“快”，不再只是在大数据量上完成批量处理，也包括在大量小规模、连续、并发的数据调用中维持足够低的延迟。

“以前的 AI 是一次一问一答，是 One Shot。现在变成了一个 Loop。”孙元浩认为，Agent 会不停地推理、行动、调用数据库、观察结果，发现不对以后再修改、再重来。这样的使用方式，对数据库带来的影响非常巨大。

在孙元浩看来，今天数据库正在经历的变化，根源并不只是数据规模再次增长，而是数据的使用者发生了改变。过去数据库的用户是人，未来的数据库就是给 AI 用的。

这也是星环科技在 WAIC 2026 期间发布 GPU 原生认知数据库预览版背后的核心判断：当数据基础设施开始直接面向 AI Agent，数据库需要从计算架构到能力体系重新设计。

Agent 想要什么

仿照凯文·凯利的科技观和他的经典著作《科技想要什么》，我们不妨也思考一下 Agent 想要什么。

把 Agent 对数据库的需求拆开看，其实是三层递进的结构：

第一层是速度。数百个 Agent 高频并发，传统数据库的并行计算能力很快触顶。单颗 CPU 通常有 100 到 200 个通用计算核心，约 400GB/s 级内存带宽。这个配置在过去二十年里足够应付绝大多数数据库工作负载，毕竟人类发起的查询，频率和并发量都有上限。

如前文所述，当数百个 Agent 同时发起数据扫描、复杂聚合和向量检索，CPU 的并行资源会被迅速占满。核心不够用，排队就开始了；带宽不够用，数据传输就堵住了。结果就是，Agent 等数据的时间，比推理的时间还长。

速度只是 AI Agent 对数据库提出的第一层要求。

当 AI 从一次问答走向持续执行，数据库还需要解决另外两个问题：上下文和记忆。

第二层是上下文。企业数据天然分散，关系型数据在数据库里，文档知识在文档系统里，语义信息在向量库里，关联关系在图数据库里。Agent 要做出准确判断，需要这些信息被统一组织、协同检索。靠系统拼接能做到，但代价是架构复杂度飙升。

第三层是记忆。 Agent 不是用完即弃的。它需要记住用户偏好、任务进度、历史结论，在跨会话场景中延续理解。这要求数据库具备长期记忆能力，而不只是存储和查询。

速度、上下文、记忆，三层需求叠加在一起，传统以 CPU 为中心的数据库架已经很难招架。AI Agent 的大脑在 GPU 上高速运行，但它需要的数据、知识和业务上下文，仍要等待 CPU 侧的数据库完成查询、分析和整理。模型越来越快，数据供给却没有同步加速，GPU 算力因此不断陷入等待。

孙元浩用了一个形象的比喻：AI 是大脑，数据库是它的四肢。大脑思考得越来越快，但行动和取数据的速度太慢，整个系统还是快不起来。

认知何以涌现

面对 Agent 这个新物种的需要，数据库需要从数据管理系统进化为认知基础设施。星环科技 GPU 原生认知数据库的四个能力维度，试图完成这场进化。

• GPU 原生加速：同一块算力底座，干完所有事

SQL 极速分析、向量检索、图分析、语义检索、机器学习，这些操作过去分散在不同系统里，现在跑在同一块 GPU 算力底座上。这意味着 Agent 不需要在多个系统之间跳转，所有数据操作都在同一个计算体系内完成。

• 一体化融合：消灭"系统拼接"的复杂性

当前企业 AI 数据基础设施的一个普遍痛点：系统太多。

关系型数据用一套数据库，向量检索用另一套，图分析又换一套，全文搜索还得再部署一个。每套系统都有自己的运维体系、数据格式和接入方式。把这些系统拼在一起喂给 Agent，单单是数据搬迁和对齐就能耗掉大量精力。

星环科技的方案是统一承载：关系型、向量、图、全文、文档，多模型能力全部纳入同一底座。数据分析、知识检索、上下文供给和记忆管理，不再需要多套系统拼接。

开发者不用再当"系统胶水工"，可以把精力放在 Agent 本身的业务逻辑上。

• 记忆能力：让 Agent"越用越懂业务"

AI Agent 的一个核心痛点是"健忘"。每次对话、每个任务都从零开始，之前的交互经验、用户偏好、任务进度全部丢失。这导致 Agent 的回答永远停留在"初次见面"的水平，没法越用越聪明。

星环科技的做法是基于自研分布式文件系统，内建长期记忆、会话记忆与上下文管理。支持多类型记忆持续沉淀，通过 GPU 加速实现低延迟检索与精准召回。记忆准确率达到 90%以上；在 BEAM 500K 和 LongMemEval-S 基准测试中，均超过主流开源记忆系统。

• 自然语言数据分析：让业务人员直接用数据

支持自然语言交互，兼容 SQL、Python 和 RESTful API。系统可自动识别用户意图，实现多模型数据的联合查询与分析。

这一能力的价值在于降低了使用门槛。业务人员不需要学 SQL，开发者也不需要手动拼装多系统的查询逻辑，直接用自然语言就能调用底层数据能力。对于 Agent 应用开发来说，这意味着数据、知识和记忆可以更便捷地接入 Agent 的工作流。

数据库要成为 GPU 的原住民

过去多年，行业内已经出现过多种 GPU 加速数据库方案。这类方案通常保留原有 CPU 数据库架构，只把部分计算任务交给 GPU。任务在 CPU 上开始执行，运行到特定环节后将数据搬运到 GPU，计算完成后再传回 CPU。

在高频调用中，CPU 内存与 GPU 显存之间的数据传输，本身就会带来额外延迟。更重要的是，只加速某一个环节，无法消除整个处理链路中的其他瓶颈。

孙元浩将 CPU 与 GPU 的性能差异比作步行和乘坐飞机。

“如果一段路步行，一段路坐飞机，最后一段再步行，肯定比不上从起点直接坐飞机到终点。”

在他看来，GPU 加速数据库和 GPU 原生数据库的核心区别就在这里。

GPU 加速是在原有 CPU 架构中加入 GPU，GPU 原生则要求数据库的核心数据处理链路从起点到终点都围绕 GPU 运行。从任务执行、数据结构到并发控制、资源调度和内存管理，都要重新适配 GPU 的硬件特性。“它是 GPU 的原住民，根本不住在 CPU 上，所以我们把它叫作 GPU 原生。”

难度不啻于“移民火星”

相比 CPU，GPU 拥有万级并行计算单元和数 TB/s 级高带宽显存，当然更适合同时处理大量 Agent 发起的高并行数据负载。基于 GPU 原生架构，数据库计算与 Agent 推理可以在同一 GPU 计算体系内共享显存数据，分析和检索结果直接进入后续推理，避免 CPU 与 GPU 之间的往返搬运。

但问题在于，数据库并不会因为接入一张 GPU，就自动获得数量级的性能提升。

GPU 本身最初面向图形渲染设计，后来逐渐成为 AI 训练和推理的核心硬件，却没有一套天然为数据库准备的成熟软件栈。

这意味着整个数据库需要从头重写，原来为少量 CPU 核心设计的并发控制、任务分配、调度机制，全部要推倒重来。

这种推倒重来，是 GPU 原生数据库与传统数据库外挂 GPU 加速模块之间最本质的差异，也是本文开篇，孙元浩提出的移民火星之喻的由来。

换来的性能与性价比

GPU 原生数据库最直观的价值体现在性能上。

据星环科技公布的测试结果，在 TPC-DS SF1000 和 TPC-H SF1000 基准测试中，分别完成全部 99 个和 22 个查询，测试通过率达到 100%。相较 CPU 数据库 1TB TPC-DS 基准测试性能提升 70 倍，相较 CPU 数据库 1TB TPC-H 基准测试性能提升 28 倍。

值得注意的是，这并不是一套只负责加速查询的 GPU 计算引擎，而是一套具备完整数据增、删、改、查能力的数据库系统。换言之，它既能够承接业务数据的持续写入和更新，也能够直接在不断变化的数据上完成大规模扫描、复杂关联与聚合分析，从而避免将数据额外搬入独立的 GPU 分析系统。

对于数据分析类 Agent，这些恰好是最频繁出现的操作。

不过，GPU 的采购成本通常高于 CPU。企业是否愿意为 GPU 数据库买单，不能只看性能，还要计算完成同等任务需要投入多少资源、花费多少时间。

“如果 GPU 只比 CPU 快 1.5 倍，它就没有经济性。”孙元浩说，“但如果能快几十倍，经济性就会出现，因为 GPU 的价格并不是 CPU 的几十倍。”

星环科技披露，在 TPC-DS 1TB 特定负载测试中，和 Databricks 相比，GPU 原生数据库表现出的性能超 66 倍，性价比超 14 倍。

当然，基准测试中的数量级性能，并不自动等同于所有生产场景都能获得同等提升。企业还需要综合评估数据类型、查询模式、迁移成本、稳定性、兼容性和运维能力。

真正具有说服力的验证，仍然来自具体业务现场。

面对信贷经营和风险分析场景的 4.8 亿条明细数据，星环科技使用 GPU 原生认知数据库完成多维分析和持续追问，在特定场景下实现了 449 倍性能提升。信贷业务分析需要贯通客户、授信、用信、还款及风险变化等全链路信息，并支持持续追问与多维钻取。传统架构下，这种跨链路、多维度的实时分析几乎不可能实现。

当复杂分析从数小时缩短到分钟甚至更短，业务人员可以围绕结果继续追问：哪些区域的风险正在上升？哪些客户群体出现了异常？风险变化与授信策略、还款行为之间有什么联系？

数据库性能提升后，分析变成了连续发生的交互过程。企业也有机会更早发现风险变化，在问题扩大之前采取行动。

一个新的十年的开端

GPU 原生认知数据库并不是一次孤立的软件升级，它背后还对应着整个计算机基础设施的变化。

过去二十多年，企业数据中心提升计算能力的主要方式是 Scale Out，也就是增加服务器数量，通过高速网络将更多 CPU 节点连接起来。分布式数据库和大数据平台正是在这一阶段快速发展。

当单核 CPU 性能遇到瓶颈后，行业通过多核、分布式和横向扩展继续提高整体处理能力。

AI 时代，基础设施开始重新重视 Scale Up。

大模型训练和推理需要多张 GPU 高速互联。模型参数、上下文和 KV Cache 不断增长，对显存容量、内存带宽、存储和网络提出了更高要求。单纯增加彼此松散连接的 CPU 服务器，很难满足 AI 对低延迟和高带宽的需求。

企业需要先将多张 GPU 通过高速互联组成更强的单体计算系统，再在此基础上继续进行横向扩展。

这并不意味着分布式架构会消失。面对更大的数据和模型，Scale Out 仍然必要，只是单个计算节点本身需要具备更强的性能和更高的带宽。

孙元浩将这条软件的技术演进路线总结为两条持续存在的驱动力：一条来自上层用户需求，一条就来自于底层硬件变化。

随着大模型参数越来越大，KV Cache 不断膨胀，内存墙（Memory Wall）成为全产业的瓶颈，围绕 GPU，HBM、DRAM、高速存储、网络通信和散热系统都在重新设计。

软件层同样需要改变，操作系统、数据库和数据处理框架都要适配新的硬件中心。

重要的是，在他看来，这不只是数据库的事，而是整个计算机架构变革的开端。而在未来的 10 年当中，企业的 AI Infra 会彻底发生变化。

但无论计算架构如何演进，数据库作为数据组织、管理与可信供给的核心系统，其基础地位不会改变。正如黄仁勋所强调的，数据库仍将是 AI 的 “Ground Truth”——为模型提供可验证、可追溯、可持续更新的事实基础。

一句话上线 AI Agent 应用：火山 Supabase + IGA Pages 全栈部署实践

火山引擎视频云 — Mon, 20 Jul 2026 06:47:38 GMT

AI 全栈应用上线难在哪？

很多开发者在做全栈应用，尤其是 AI 应用时，真正耗时的地方往往不在业务代码本身。一个功能原型可能很快就能写出来：前端页面、登录注册、文件上传、数据库表、几段后端函数，再接一个大模型接口。但当它要从本地项目变成“别人能打开链接直接使用”的应用时，事情就会变复杂。

你需要准备数据库，执行建表脚本，配置行级权限，开通对象存储，部署后端函数，设置环境变量，再把前端打包上传。每一步都不算难，但串起来之后，部署流程很容易变成一次重复、繁琐、容易出错的基础设施工作。

火山引擎 Supabase X 火山引擎 IGA Pages，实现一站式前端部署和运行，正是为了解决这段“最后一公里”而设计的。

它把前端托管和 Supabase 后端部署整合到同一条链路里。开发者只需要在本地准备好前端代码、数据库迁移文件和 Edge Functions，然后执行一条命令，就可以完成前端站点发布、后端工作区创建、数据库初始化、函数部署和环境变量注入，并获得一个可访问的线上预览地址。

本篇文章会用官方示例应用 Demo 「资料盒子」完整跑一遍 IGA Pages 的部署流程。

火山 IGA Pages：将五类部署收敛为一条命令

火山引擎 IGA Pages 是什么：火山引擎一站式 AI 应用部署与全球加速平台。它提供零配置的部署流程、全球边缘网络和 Serverless 函数能力。它负责极速地“上线”。

💡 当前 IGA Pages 核心功能限时免费，个人开发者和小团队均可零成本上手。https://console.volcengine.com/dcdn/pages

传统全栈应用上线通常包含几类工作：

1. 前端构建与托管

例如安装依赖、执行 build、上传静态资源、生成访问链接。

2. 后端资源准备

包括数据库实例、认证服务、对象存储、实时推送、函数运行环境等。

3. 数据库初始化

执行 migration，创建表结构、索引、权限策略、触发器等。

4. 服务配置

配置前端需要使用的 API 地址、匿名访问密钥、函数地址等环境变量。

5. 前后端联调

检查登录、上传、数据库读写、函数调用和权限隔离是否正常。

过去这些动作往往需要开发者在多个控制台和工具之间手动串联。现在，借助 byted-supabase-cli 的 pages fast create 命令，以及 Trae 中的 byted-supabase Skill，开发者可以把前端托管、Supabase 后端创建、数据库迁移、Edge Functions 部署和环境变量注入放到同一条部署链路中完成。执行部署后，这条链路会自动完成：

构建并托管前端静态站点；创建新的火山引擎 Supabase 工作区；等待后端服务就绪；执行数据库迁移脚本；创建或初始化 Storage Bucket；配置 Realtime 相关发布；部署 Edge Functions；将前端项目与后端工作区绑定；注入浏览器端所需的环境变量；输出最终可访问的预览链接。

开发者不需要在多个控制台之间来回切换，也不需要手动复制项目 URL、匿名密钥或函数地址。

环境准备

开始之前，需要准备以下环境。

1. 火山引擎账号

确保已经拥有可使用火山引擎的账号，并完成必要的登录授权。IGA Pages 部署过程中会创建 Supabase 后端工作区，因此账号需要具备相应资源的创建权限。

2. 安装 CLI

# 安装 byted-supabase-cli。 npx @byted-supabase/cli@latest install # 检查版本 byted-supabase-cli --version

这条命令会同时：

全局安装 byted-supabase-cli安装配套的 byted-supabase agent skill。检查安装是否成功

3. 登录账号

使用 CLI 登录火山引擎账号：

# 按你的实际地域调整，常用 cn-beijing byted-supabase-cli login --region cn-beijing

登录过程会根据当前环境打开授权页面或输出登录提示。按提示完成登录即可。

快速部署实践

方式一：通过 Trae + Skill 自然语言部署

如果已经安装好 byted-supabase-cli，就可以直接在 Trae 中用自然语言发起部署。

原因在于，byted-supabase-cli 不只提供命令行能力，也内置了配套的 Agent Skill。安装 CLI 后，Trae 这类支持 Skill 的 AI 编程工具可以识别并加载这套能力。此后，开发者不需要记住完整命令和参数，只要用自然语言描述目标，Agent 就可以根据 Skill 调用 CLI，完成项目检查、命令生成、部署执行和结果汇总。

这也是 IGA Pages 更适合 Vibe Coding 场景的地方：部署不再依赖人工手动拼接命令，而是可以接在 AI 编程流程后继续完成。

例如，你可以直接告诉 Trae：

“请使用 byted-supabase skill，部署 byted-supabase-cli 中用于演示的 Demo 项目。”

收到指令后，Trae Agent 会基于 Skill 自动完成后续步骤。

👍 示例应用：资料盒子

本次实践使用火山引擎 Supabase 官方 Demo「资料盒子」。

它是一个轻量的 AI 资料管理应用，包含以下功能：

文件上传、预览、下载和删除；支持文本和图片资料管理；文件上传后自动进入处理队列；调用大模型生成标签和摘要；基于资料标签进行问答；

虽然它是一个 Demo，但全栈能力比较完整，也就是说，这不是只发布一个静态页面，而是一次性部署一个包含真实后端能力的全栈应用。

可以直接点击预览链接进行查看也可以通过 Trae 打开预览链接查看各项功能是否正常。

方式二：手动部署

获取代码

# 拿资料盒子Demo地址 byted-supabase-cli pages fast create -h # 输出资料盒子Demo地址 # This command uploads a Pages deployment archive, creates a Pages project, creates a Supabase workspace with the same project name, waits for the workspace/default branch to become ready, optionally applies SQL migrations, optionally deploys Edge Functions, binds the Pages project to Supabase, and creates the final Pages deployment. # Demo app: # https://lf3-static.bytednsdoc.com/obj/eden-cn/whkph/ljhwZthlaukjlkulzlp/nextjs-supabase-filebox.zip # 下载资料盒子zip curl -fsSL https://lf3-static.bytednsdoc.com/obj/eden-cn/whkph/ljhwZthlaukjlkulzlp/nextjs-supabase-filebox.zip -o filebox.zip # 解压 unzip -o filebox.zip

下载并解压官方「资料盒子」Demo 后，目录结构大致如下：

nextjs-supabase-filebox/ ├── frontend/ ├── backend/ └── migrations/

部署命令

进入 Demo 所在目录后，执行以下命令：

byted-supabase-cli pages fast create my-filebox \ --file-path nextjs-supabase-filebox/frontend \ --functions-init nextjs-supabase-filebox/backend \ --migrations-init nextjs-supabase-filebox/migrations \ --framework-prefix NEXT_PUBLIC_

这条命令中的几个参数含义如下：

从这段输出可以看到，IGA Pages 并不是简单上传前端文件，而是依次完成了：

上传前端资源；创建 Pages 项目；创建 Supabase 工作区；等待工作区进入 Running 状态；解析默认数据库分支；执行数据库迁移脚本；部署 Edge Function；将 Pages 项目绑定到 Supabase 工作区；创建并完成 Pages 部署。

当终端输出 Fast create completed 时，说明前端站点、Supabase 后端、数据库迁移和 Edge Function 部署都已经完成。部署过程中，终端会打印出一些关键信息，例如：

PagesProjectID: xxx # Pages（前端）:前端 Pages 项目的唯一 ID WorkspaceID: xxx # Pages（前端）:本次前端部署的 ID（每 deploy 一次产生一个） BranchID: xxx # Pages（前端）:上传的前端打包产物（那个 zip）的资源 ID，一次 upload 产生一个 ProjectDeployResourceID: xxx # Supabase（后端）: 工作区ID DeployID: xxx # Supabase（后端）: 分支 ID

预览访问

byted-supabase-cli pages binding --workspace-id --region cn-beijing -o yaml

这些信息可以用于后续排查、查看项目或重新部署。

部署完成后，复制终端输出的预览链接 preview_domain 在浏览器中打开即可访问应用。

结果验证：确认全栈链路已跑通

为了确认部署不只是页面打开成功，还需要验证前端、数据库、存储、函数和 AI 调用是否全部正常。

1. 登录应用

打开预览链接后，进入登录页。Demo 提供了默认测试账号入口，可以直接点击使用默认测试账户按钮创建并登录。

登录成功后，可以看到“我的资料”列表页面。

2. 导入文件

进入设置页，点击一键导入预置资料。Demo 会自动导入一批 Markdown 和图片文件，用于后续测试。

导入完成后，返回我的资料列表，可以看到文件已经写入 Storage，并在数据库中生成对应的元数据记录。

3. 等待 AI 自动打标签

文件导入后，会进入后台处理流程。Edge Functions 会负责触发文件处理逻辑，并通过 AI-Gateway 调用大模型，为资料生成标签和摘要。

这个过程完成后，资料列表中会出现自动生成的标签。

4. 体验问答

进入“资料问答”页面，输入一个与导入资料相关的问题。系统会根据标签和资料内容进行检索，生成回答，并标注引用来源。

如果回答能够正常生成，并且来源文件可以被高亮展示，说明以下链路已经跑通：

前端可以访问后端；用户认证正常；数据库读写正常；RLS 权限策略生效；Storage 文件访问正常；Edge Functions 调用正常；AI-Gateway 调用正常；资料检索和引用展示正常。

原理解析：为什么能够一条命令上线

IGA Pages 能把部署收敛成一条命令，核心原因是它把前端资源与 Supabase 后端资源放在同一条部署链路中处理。

在普通部署模式下，前端和后端通常是分开的：

前端托管平台只负责页面构建和静态资源发布；数据库平台只负责数据库和权限；函数平台只负责后端函数运行；存储服务只负责文件；环境变量需要人工配置；各服务之间的地址、密钥和权限关系需要人工串联。

IGA Pages 则在部署时明确知道：

当前前端项目对应哪个 Supabase 后端；应该执行哪些数据库 migration；应该部署哪些 Edge Functions；哪些环境变量需要注入到前端；前端应该连接到哪个后端实例。

因此，它可以自动完成“创建后端资源 → 初始化数据库 → 部署函数 → 绑定前端 → 注入环境变量 → 发布站点”的完整流程。

对开发者来说，最直接的变化是：上线一个 AI 全栈应用，不再需要在多个平台之间反复切换。

适用场景：哪些应用适合 IGA Pages

IGA Pages 尤其适合以下几类场景。

💡 AI 应用原型验证

例如资料问答、智能表单、知识库助手、图文管理、Agent 控制台等应用。

🎨 Vibe Coding 产物上线

在自然语言辅助编程场景中，AI 可以很快生成业务代码，但部署经常成为中断点。

📍 Demo、客户演示和内部评审

很多 Demo 的价值在于“能不能马上打开体验”。

实践总结：从本地代码到线上应用

IGA Pages 不是单纯的静态页面托管，而是面向 AI 全栈应用的一体化部署能力。

在这次「资料盒子」实践中，一条 pages fast create 命令完成了前端发布、Supabase 后端创建、数据库迁移、Storage 初始化、Edge Functions 部署、环境变量注入和预览链接生成。

对于开发者来说，它减少的是重复配置和平台切换；对于 AI 编程和 Agent 开发场景来说，它补上的是从“代码生成”到“应用上线”之间的关键一步。

当一个应用可以用一条命令从本地代码变成线上链接，原型验证、产品演示和早期上线都会变得更轻。

目前，IGA Pages 与火山引擎 Supabase 联动能力已上线。开发者可以前往火山引擎官网查看产品入口和技术文档，体验从本地项目到线上全栈应用的一键部署流程。

业务研发中的 Loop Engineering：基于事前-事中-事后架构的实践｜AICon深圳

AICon 全球人工智能开发与应用大会 — Mon, 20 Jul 2026 06:44:26 GMT

Agent 时代，哪些方向正在成为行业关键变量？50 + 实战案例揭晓答案！

模型参数规模不断突破，推理成本持续下降，开源生态日益繁荣。当模型能力逐渐成为行业共识，一个新的问题开始浮现：当人人都能获得强大的模型能力之后，真正的竞争力还剩下什么？答案正在从模型能力本身，转向围绕模型构建可规模化的智能系统；从单点能力提升，转向系统工程与组织级落地能力。

在这一背景下，2026 年 AICon 人工智能开发与应用大会 · 深圳站"正式启动。本次大会将于 8 月 21 日—22 日举办，聚焦 AI 基础设施、大模型系统、智能体工程、数据智能、多模态技术与行业落地等关键方向，邀请来自腾讯、阿里、华为、百度、蚂蚁集团等 50 + 头部科技企业技术负责人、科研机构一线专家，系统性分享前沿洞察与实战干货，共同探讨 AI 技术从能力到系统、从实验到生产的真实路径。

腾讯高级后台开发工程师、项目组 Agent 落地负责人任磊达已确认出席 “Harness Engineering：模型之外的智能体工程"” 专题，并发表题为《业务研发中的 Loop Engineering：基于事前-事中-事后架构的实践"》的主题分享。AI 时代，研发提效的关键不再只是让 Agent 更快写代码，而是让团队能持续证明代码“做对了”、质量“兜得住”。本次分享以“事前-事中-事后”Harness Engineering 为主线，结合游戏后端质量验证实践，探讨如何把 Agent 执行、测试策略、集成测试、Review 沉淀与 Skill 评估组织成质量飞轮。分享将从“查杀分离”这一核心理念出发，说明为什么测试需要独立于实现路径，为什么 Agent 自写自测存在认知同源风险；随后展开 TDD、tester skill、lobbytest / ugctest、skill evaluator 四类实践，分别对应事前结构化、事中自动化验证和事后沉淀回灌。最终目标是让人聚焦业务边界、风险判断和质量标准，让 Agent 承担执行、验证与重复性修复，使同类问题越来越少，质量资产持续复利。

任磊达，腾讯高级后台开发工程师、项目组 Agent 落地负责人，推动百人规模项目组开发团队从 Token Maxing 向 Token Apocalypse 转型，将 Harness 的目标明确聚焦于 ROI。基于事前、事中、事后的架构构建 Harness Loop，降低认知成本，实现单人月耗百亿 Token 的开发模式，并完成团队推广。基于 18 年线上项目运营经验，持续探索 100% Coding Vibe 场景下的质量投入模式与 ROI。在实践中，可于 20 天内完成原本约 100 人天的需求，并通过后续 2–3 个月的质量工程化手段恢复系统的可控性。他在本次会议的详细演讲内容如下：

演讲提纲：引言：Agent 时代的质量焦虑最大的问题不再是“能不能写代码”，而是“怎么证明写对了”研发质量的目标：让问题更早暴露、更少重复、更容易回灌引出核心框架：事前结构化、事中自动化、事后沉淀2. 两层 Harness：执行托底与项目组织Agent-CLI 侧 Harness：托住长程执行，控制失控风险项目侧 Harness：拆清需求、测试、Review 和沉淀入口最终目标：白天做判断，夜里跑执行，第二天复盘回灌3. 质量验证的核心理念：查杀分离类比机器学习：训练集与验证集必须分离类比业务安全：发现问题的“查”和线上处置的“杀”需要独立映射到研发质量：Development 与 Test 要形成独立验证路径Test vs Review：测试通过真实执行路径验证，Review 更多依赖代码文本和经验判断4. 事前：把需求、验收和测试策略结构化/workflow:clarify：把模糊需求变成边界、风险和验收条件TDD 在 Agent 时代的新定位：测试即规格，先定义“怎么算做对”Agent 自写自测的风险：认知同源，容易“用训练集验证训练集”解决方向：上下文隔离、跨模型验证、属性测试、不变量测试tester skill repo：从“怎么测”升级到“该测什么”Push vs Pull：从过度测试转向风险驱动的恰到好处测试5. 事中：Agent 执行，自动化测试与 Hooks 盯防按 plan.yaml 分 stage 执行：实现、验证、失败重试、提交Hooks / linter / auto review：把确定性问题前移到执行过程中lobbytest / ugctest：游戏后端集成测试的实践样本从 CLI 工具到插件化，再到服务化架构真实服务、模拟客户端、TraceID、日志分析共同支撑事中验证事中困惑：用例维护成本、并发测试资源、复杂场景定位成本6. 事后：Review、Issue 与 Skill Evaluator 沉淀闭环Review 放到 MR：沉淀代码上下文、判断依据和处理结果Test 放到 Issue：沉淀验收标准、失败案例和回归入口高频问题回灌为 Hook、Linter、Skill、WorkflowSkill Evaluator：验证对象从代码升级到流程本身两类评估：Skill 是否被正确触发，Skill 是否完成预期任务7. 开发自测的三阶段价值定位阶段一：手工测试最佳实践沉淀为可执行用例阶段二：风险评估驱动低风险变更直发阶段三：测试团队主导质量系统化，开发团队提供技术支撑风险模型：风险等级 = 失效影响 × 失效可能性低风险 + 集成测试通过，可以进入更轻量发布路径8. 效率飞轮：从质量验证到工程资产复利事前：clarify、TDD、tester skill 定义清楚输入事中：Agent、Hooks、lobbytest / ugctest 自动执行验证事后：MR、Issue、Skill Evaluator 沉淀判断并回灌观测指标：MR 评论数、重复评论占比、Harness 回灌率、自动放行率、事前澄清耗时9. 结语：让人的判断越来越值钱人负责业务边界、风险判断和质量标准Agent 负责执行、验证、修复和重复性反馈处理Harness 的价值不是让 Agent 一次写得更快，而是让团队越跑越稳、同类问题越来越少、质量资产越来越厚。这样的技术在实践过程中有哪些痛点？token消耗较大，会有一定认知成本和管理成本的压力。听众收益了解 token maxxing 的上限边界，掌握通过认知管控提升该上限的方法。明晰 vibe coding 的质量保障路径，该路径并非局限于常规的 tdd、单元测试、接口测试，而是要实现功能覆盖度与维护 ROI 的平衡。如果组织选择不缩减HC，以及保证相对稳定的组织架构的形态下，如何借力 AI 实现效能 ROI 的收益。

除此之外，本次大会还策划了AI Infra、推理工程与异构计算"、超级个体与蜂群智能的共生进化"、迈向机器人 AGI 的关键技术与产业实践"、Agent 安全：从风险到可控"、端侧智能与 AI 原生终端"、AI Agent 高价值商业场景实战"等11个专题论坛，届时将有来自不同行业、不同领域、不同企业的50+资深专家在现场带来前沿技术洞察和一线实践经验。

大会限时早鸟票享 9 折专属优惠，现在报名立减 580，更多详情可扫码或联系票务经理 13269078023 进行咨询。

企业级 Harness Engineering 实践：运营、数据、Coding 与办公智能体工程化落地｜AICon深圳

AICon 全球人工智能开发与应用大会 — Mon, 20 Jul 2026 06:36:23 GMT

Agent 时代，哪些方向正在成为行业关键变量？50 + 实战案例揭晓答案！

去哪儿基础架构负责人、技术总监李佳奇已确认出席 “Harness Engineering：模型之外的智能体工程"” 专题，并发表题为《企业级 Harness Engineering 实践：运营、数据、Coding 与办公智能体工程化落地"》的主题分享。本次分享将结合企业级运营自动化 Agent、数据分析 Agent、Coding Agent 与办公智能体平台建设实践，介绍如何围绕不同场景构建 Harness：通过数据基建、知识库建设提供可信上下文；通过开发基建、CI/CD、工作流编排和沙箱机制约束执行过程；通过大模型网关实现多模型适配和成本治理；通过 Langfuse 可观测、质检和评测体系建立“执行—验证—反馈—优化”闭环；并通过数据安全、网络安全、权限控制与审计机制保障智能体在企业环境中可控运行。

李佳奇，去哪儿旅行基础架构负责人、技术总监、技术中心 TC 委员、AI 研发 SIG &业务架构 SIG 负责人。10 余年 OTA 一线研发经验，在高并发高可用系统建设、DDD 项目落地、业务域系统价值度量、线上系统防腐治理等领域有代表性作品。2025年起全面负责AI在公司落地，在 AI 基础设施、AI研发、AI 运营、AI 数据等方向均有重量级落地成功案例。他在本次会议的详细演讲内容如下：

演讲提纲：企业级 Agent 落地背景：四类核心场景为什么都需要 Harness团队建设运营自动化、数据分析、Coding 与办公智能体的背景四类场景的共性：都从“生成内容”走向“连接数据、工具、流程和真实业务系统”共同挑战：上下文管理、工具调用、权限管理、持续迭代、测评质检2. 四类场景的harness实践运营自动化：企业级工作流平台建设和评测质检数据分析：业务商分能力沉淀和通用分析Agent建设和成本治理coding：端到端研发自动化平台建设和基建改造企业办公智能体：企业级龙虾平台建设和安全治理3. 当前落地成果万PD级年化提效成果和典型运营自动化案例展示复杂业务商分常态化分析和成本治理技术需求和业务需求场景下研发端到端规模化落地案例企业级龙虾平台建设和使用案例4. 实践总结和未来展望实践总结：四类场景沉淀出的企业级 Harness 方法未来展望：从场景 Agent 到企业智能体运行体系这样的技术在实践过程中有哪些痛点？模型能力与真实业务任务之间存在断层上下文、知识和数据很难真正可用Agent 调用真实系统后，执行风险显著上升缺少端到端可观测，问题难以定位和运营听众收益获得四类企业核心场景的 Harness 建设方法：了解运营自动化、数据分析、Coding 与办公智能体在上下文、工具调用、工作流、验证和权限治理上的差异化设计。掌握 Agent 从 Demo 走向生产的关键工程能力：学习如何通过数据与知识基建、CI/CD、模型网关、Langfuse 可观测、评测质检和安全治理，让 Agent 持续稳定交付真实业务结果。借鉴多场景规模化落地的实践经验：获得关于成本治理、效果评估、模型升级回退、工具调用失控、数据权限与安全防护等真实问题的处理思路。

除此之外，本次大会还策划了AI Infra、推理工程与异构计算"、超级个体与蜂群智能的共生进化"、迈向机器人 AGI 的关键技术与产业实践"、Agent 安全：从风险到可控"、端侧智能与 AI 原生终端"、AI Agent 高价值商业场景实战"等13个专题论坛，届时将有来自不同行业、不同领域、不同企业的50+资深专家在现场带来前沿技术洞察和一线实践经验。

大会限时早鸟票享 9 折专属优惠，现在报名立减 580，更多详情可扫码或联系票务经理 13269078023 进行咨询。

GMI Cloud联合InfoQ、10+企业重磅发布《中国AI产业核心要素出海发展白皮书》，汇聚 AI 产业共识，盘点出海方法论

赵钰莹 — Mon, 20 Jul 2026 06:30:40 GMT

目前，国内AI市场竞争趋于饱和，出海成为产业突破增长天花板、抓取海外高ARPU市场红利的核心引擎。但算力供给失衡、高端硬件成本高企、全球各地差异化合规壁垒、多语言Token效率损耗、跨文化本地化适配困难等多重瓶颈，持续制约中国AI企业全球化落地效率。

基于这样的洞察，InfoQ极客传媒与GMI Cloud为核心出品方，火山引擎、小米MiMo、快手、出门问问、商汤科技、像素绽放PixelBloom、Moka等数十家产业链头部企业为联合出品方的《中国AI产业核心要素出海发展白皮书》（下称“白皮书”）于2026年7月18日正式发布。大家关注GMI Cloud公众号回复【白皮书】（或访问https://www.infoq.cn/minibook/GSbtyU9968lerf5gwPpU）进行下载查看。

该“白皮书”打破单一企业、单一环节碎片化视角，串联上游基础设施及基础模型、中游MaaS算力平台、下游垂直应用四大参与主体，结合全产业链联合调研与一线落地实践，首次以算力、Token、出海三大核心要素为统一分析框架，全景剖析全球AI产业工业化浪潮下中国AI企业全球化转型现状、核心痛点与协同发展路径，完整梳理全球AI产业底层运行逻辑，凝聚全行业协同出海共识，为全球大模型厂商、MaaS平台、AI应用企业提供一套可落地、全链路的出海战略行动指南。

告别参数狂热，全面迈入“推理经济与Agent时代”

当前全球AI产业迈入规模化工业化量产新阶段，Gartner数据显示2026年全球AI总支出将达2.59万亿美元，生成式AI市场支出同比增速高达59%；全球AI加速器市场规模突破2000亿美元，英伟达Blackwell系列GPU成为全球智算基础设施主流标配。与此同时，行业竞争逻辑完成根本性切换：产业从参数竞赛的训练时代，全面进入以高频并发、长链路智能体任务为核心的推理经济时代，Token成为衡量AI产出、核算商业成本的通用“数字石油”。

随着智能体（Agentic AI）、多模态实时交互在业务场景中的全面铺开，推理期的算力消耗正在急剧飙升。白皮书中的引用数据提到，中国日均Token调用量已经一举突破140万亿大关，在短短两年时间内实现了超过1000倍的跨越式增长。据推算，企业在运行模型（推理）上的累计资金消耗，已经占据了企业AI总预算的85%以及全球AI总算力开支的约三分之二。

在这个“推理称王”的新时代，底层的物理算力与上层的Token商业化形成了极其严密的深度绑定与双向制约：算力卡的显存带宽直接决定了超长上下文（KV Cache）的处理天花板，而Token的指数级爆发又反向逼迫全球数据中心全速向推理吞吐效能做出架构妥协。

穿越出海深水区，直面“算力溢价”与“Token通胀”的现实鸿沟

面对国内竞争日益激烈的市场环境，出海已顺理成章地成为中国 AI 产业开辟全局增量空间的 “新赛道”。然而，白皮书发出前瞻性预警 —— 走向全球的征途绝非简单的 “产品输出”，出海企业正面临着极其严峻的现实鸿沟。

首先是强地缘波动性带来的算力溢价壁垒。在全球智算硬件被顶尖供应链牢牢锁定的背景下，算力已演变为一种高资本排他性的商业竞争主权，极大地压缩了全产业链的利润空间。其次是 “Token 通胀” 的痛点，当前全球 MaaS 市场已演变为由非对称定价主导的精细化通证经济体，且非英语语种在底层编码时普遍面临效率低下带来的 “通货膨胀” 与语义丢失。此外，欧美等全球主要市场对数据主权、隐私保护（如欧盟 GDPR）及数据 “零留存” 的合规要求极高，合规建设已然演变为出海企业真正的核心竞争力。

面对高昂的算力成本与复杂的跨国合规壁垒，单打独斗的孤勇者时代已经终结。白皮书呼吁，全行业必须走向多方协同的“生态输出”，将重资产的物理算力转化为流动的弹性资源。

作为产业链中游的基础设施提供方，全球领先AI原生云服务商、全球七大Reference Platform NVIDIA Cloud Partner之一的 GMI Cloud 依托强大的硅谷AI技术基因与全球化数据中心布局，除了提供基于GB300、B300、B200、H200等高端芯片的AI Native Cloud 外，还推出了 Cluster Engine (Compute Engine)与 Inference Engine 两大核心平台，为AI Agent时代提供从底层算力到上层推理的全栈支撑。

GMI Cloud Cluster Engine （Compute Engine)针对不同用户需求提供双形态服务——裸金属算力服务支持一键快速创建、全球可访问网络与SDN能力，提供完善可观测性支持；容器算力服务则提供更细粒度配置，由其统一编排调度、无需用户自行运维，实例可实现秒级极速启动，从容应对Agent业务高峰的突发负载。两大形态协同，让企业在享受稳定可靠算力体验的同时，以更优化的总体拥有成本完成AI转型全面升级。

GMI Cloud Inference Engine 作为全球AI模型统一接入的"高性能推理引擎平台"，底层搭载H200/H100/GB系列芯片，集成Gemini、OpenAI、DeepSeek、Qwen、Kimi等全球近百个最前沿大模型。为AI开发者与企业提供速度更快、质量更高的模型服务。就白皮书收录的标杆案例显示，实时生成式视频头部企业 Higgsfield 将其重度视频流负载全面运行于 GMI Cloud 平台后，成功降低了 65%的 p95 推理延迟和 45%的计算成本，在峰值流量下保持了 99.9%的请求成功率；前沿大模型开发商 Mirelo AI 则借助其灵活的算力配置，降低了 40%的模型训练成本并提速 20%的迭代时间；此外，该平台还广泛受到 HeyGen、Utopai、Eigen AI 等知名 AI 团队的信任，展现了强大的全球化产业赋能效果。

GMI Cloud中国区总裁蒋剑彪表示：“全球AI产业已经进入算力、Token、应用三位一体的竞争阶段，单一企业很难独自承担全球算力布局、合规体系搭建的高额投入。GMI Cloud将持续发挥产业枢纽价值，依托全球分布式智算底座，为AI应用企业提供合规、低成本、高弹性的全球化算力基础设施，共建全球AI产业新生态。”

多方协同，打破全球AI产业孤岛效应的全局增量闭环

白皮书提出，由基础模型厂商、MaaS平台、算力基础设施提供方和AI应用企业共同构成的多主体协同创新生态，正展现出明确的生产力分工与不可替代的协同增量价值。在这一生态中——基础模型厂商提供技术支撑、MaaS平台搭建服务桥梁、算力基础设施提供方夯实物理底座、AI应用企业聚焦场景落地，但其核心价值绝非简单的资源拼接，整体来看，AI产业多方协同生态能够有效分摊全产业链研发、算力运维、合规适配的刚性成本，减少产业各环节的技术摩擦与资源内耗。

展望未来，多主体协同的产业模式，将重构传统的产业发展形态，实现了技术、算力、场景、合规四大核心要素的闭环联动。上游基础模型的算法能力与MaaS平台的算力调度能力相互融合，实现底层技术资源的高效盘活；MaaS平台的弹性算力资源、标准化服务体系，与应用端的真实业务场景深度适配，保障技术落地的实用性与适配性；而应用端积累的全球市场数据、场景痛点、合规经验，又可反向驱动上游模型迭代、服务体系优化，形成持续正向的产业迭代循环。

在全球产业格局波动、区域市场规则差异化的背景下，这种体系化协同模式可有效提升AI产业全球化适配能力与抗风险能力，夯实产业长期高质量、可持续发展的核心优势，构建适配全球化竞争的产业生态体系。

AI 红利分层，“底座夯实”的团队获益最高——《DevData 2026 研发效能基准报告》正式发布！

赵钰莹 — Mon, 20 Jul 2026 06:27:17 GMT

近日，由思码逸出品的《DevData 2026 研发效能基准报告》正式发布。这是 DevData 系列报告的第三年，覆盖了超过 200+ 家企业、数万名开发者的真实研发数据，延续了主客观结合的方法论——客观指标来自企业真实代码仓库的持续采集，主观判断来自一线技术管理者的真知灼见。

三年听起来不算长，但对于一份行业基准报告来说，刚好够从「拍一张快照」进入「看一条曲线」。DevData 不再只告诉你“行业现在的水平是什么”，还能回答一个更有价值的问题：行业在往哪里走，走得有多快，怎样能走得更好。

三年前，思码逸开启了研发效能行业数据的建设，彼时大家的关注点都在数据治理和更合理的指标。今天，AI 又给我们叠加了更多挑战：当绝大多数代码由 AI 编写，“人”的效能该怎么算？《DevData 2026 研发效能基准报告》尝试从交付速率、交付质量、交付能力三个认知域作答。

今年的数据，揭示了几条让人无法忽视的规律：

全行业研发效能实现了整体跃升。三年间，代码生产率中位值从 2983 提升至 4019 代码当量 / 人月，需求交付周期中位值从 15 天压缩到了 7 天。更重要的是，这种增长不是头部企业的独角戏——小型团队产能增幅甚至超过了大型团队，AI 正在弥补中小团队的规模短板。研发效能普惠式增长的时代，已经到来。

AI 的红利是分层的，工程底座决定了能吃到多少 AI 红利。这是本年度最关键的发现之一：以持续交付为代表的基础能力，直接决定了 AI 效能收益的上限。基础薄弱的团队引入 AI 后，产能反而持续下行；基础扎实的团队，经历短期阵痛后呈 V 型反弹，最终超越初始水平。AI 不会雪中送炭，它只会锦上添花。先夯实包括 CI/CD 在内的工程底座，再逐步推进大模型智能化升级——这是数据给出的最优路径。

质量领域正在上演“分化”。中位值企业的千当量缺陷密度在下降，质量管控跟上了产能增速；但尾部企业的问题密度均值三年翻了一倍多。AI 放大了效率，也在拉大质量差距。过去我们谈“又快又好”，今天的数据告诉我们：只有少数团队真的做到了。

AI 落地进入深水区，渗透率高但深度不足。超过 96% 的企业已经在某种程度上采用 AI 生成代码，但半数以上仍将大模型定位为“辅助工具”。真正的竞争已经从“用不用”转向“用多深”。而投入深度，又回到了同一个前提：你的工程和知识基础设施准备好了没有？

行业共识加速形成。 AI 代码质量自动化校验、数据驱动效能治理、私有化行业大模型——这三件事被近半数企业视为未来 1-3 年的核心方向。行业不再迷恋 AI 本身，而是开始认真思考：AI 来了之后，我们真正该做什么。

三年来，思码逸坚持每年用一份报告记录行业走过的路，记录管理者做过的选择，记录那些“数据印证直觉”或“数据推翻直觉”的时刻。2026 年，行业已经为“要不要做 AI”画上了句号，转而开启了一个更成熟的追问：在 AI 已无处不在的时代，如何做出真正有效的投入决策？

我们希望这份报告不止被翻阅，更能被使用。对标数据不是终点，找到属于你所在企业的投入路径才是。无论是先建设工程底座再引入 AI，还是借助 AI 快速弥补小团队的产能缺口——每种路径，今年的数据都给出了信号。

《DevData 2026 研发效能基准报告》现已正式发布，下载链接：https://fs80.cn/nn5bdw

九章云极DataCanvas亮相WAIC 2026，以AI规模化生产体系赋能智能新底座

作者：九章云极 — Mon, 20 Jul 2026 06:01:03 GMT

过去两年，大模型竞赛上演了一场空前的“算力淘金热”。行至2026年的产业分水岭，行业的关注焦点已从“谁参数最多”转向为——“谁的智能成本最低？”“谁能让算力随手可得？”

7月17日，2026世界人工智能大会在上海开幕。据新华社报道，国家主席习近平出席2026世界人工智能大会暨人工智能全球治理高级别会议并发表主旨讲话，为人工智能创新、产业落地与全球治理指明发展方向。总书记在讲话中指出，要推动人工智能与实体经济深度融合，加快形成新质生产力。这一方向性指引，为AI产业从“技术验证”迈向“规模交付”划定了清晰的航向。当AI不再仅是实验室里的参数竞赛，而是成为驱动千行百业降本增效的基础动力，产业亟需一套可复制、可度量、可普惠的基础设施体系。

站在宏观指引与产业化量产的交汇点上，作为AI基础设施及智算云提供商，九章云极在H1馆B138展台，展示了一套完整的“AI规模化生产体系”，回应了这次大会的核心命题。

从“参数竞赛”到“成本竞争”：供给侧的结构性变革

参数规模与榜单排名，曾是衡量大模型竞争力的唯一标尺。然而，算力成本高企、多芯片计价割裂、GPU利用率困于30%红线、研发缺乏标准化体系——这四大结构性矛盾，正是AI从“技术竞赛”迈向“规模交付”的核心卡点。产业竞争的维度正在发生变化：竞争的关键不再是服务器保有量，而是可度量、可持续迭代的AI规模化交付能力。

九章云极亮相的“AI工厂”，正是对这一痛点的直接回应。其本质，将AI生产从依赖个别专家的研发模式，推向可复制的标准化流水线——通过“训练工厂”与“Token工厂”双引擎闭环，前者以强化学习为底座解决“造模型难”，后者将大模型封装为消费级、专业级、前沿级三类标准化Token服务，回应了“用模型贵”的核心痛点。

在这一蓝图中，DCU统一算力计量体系是实现算力普惠的技术底座。作为算力计量的统一单位，1 DCU代表312 TFLOPS×1小时有效计算，可将异构芯片的实际算力输出折算为统一度量单位，为解决硬件计价规则长期割裂的行业困局提供了可行方案。以DCU衡量算力投入、以Token衡量智能产出，九章云极构建了清晰可量化的算力价值闭环，这不仅是技术创新，更是面向基础设施层级的“标准输出”。

从“规模扩张”到“精细治理”：算力效能的二次跃升

如果说AI工厂解决的是“生产什么、如何定价”，本次同步展出的九章智算云3.0则回应了“如何让算力产生最大效能”的深层命题。

算力规模是基础，算力治理才是决定效能的关键。全新升级的九章智算云以智能队列调度、资源配额管理、开发工具套件三位一体，率先构建从“算力计量”到“算力治理”的全流程闭环，队列调度疏通拥堵，好比高峰路口智能交管，让算力车流有序通行；配额管理设好边界，如同为每支团队划定专属车道，杜绝超限占用；开发工具套件则架起直达通道，让开发者无需绕行即可调用云端算力。三者协同，让算力从“能买到”变为“用得好”。

全球布局层面，九章云极已覆盖十余个智算中心，服务海量行业头部企业，并沿“一带一路”推进算力出海，服务算力基础设施国际化需求。

实体经济验证：最高成本直降82.1%

衡量基础设施企业的价值，在于能否在实体经济中跑出可量化的经济账。目前，九章云极在具身智能、大模型训推、自动驾驶多个赛道均已规模化落地：为头部模型厂商构建大规模推理集群，稳定承载百亿参数超长上下文推理；支撑具身智能从数字孪生到实体协同的全流程算力需求；服务自动驾驶海量路测数据处理与车路协同调度。

客户侧数据更具说服力：依托九章弹性算力体系，某头部模型厂商项目中，综合成本最高节省82.1%，1至999卡GPU弹性调度有效匹配业务潮汐需求。这组数据印证了一个判断：AI基础设施的竞争，正从“谁拥有更多的卡”转向“谁能让每张卡产生更大的经济价值”。

当AI从实验室的前沿技术进化为驱动实体经济的基础力量，产业竞争的标尺早已超越单一模型的参数优越感。九章云极在WAIC 2026的亮相，以DCU统一计量构建了算力的价值尺度，以AI工厂重构了智能的生产函数——这套可复用、可扩展的基础设施参考架构，标志着AI从技术验证走向规模交付的范式迁移已然全面开启。

谷歌发布A2UI v0.9：可移植、框架无关的生成式UI

作者：Daniel Curtis — Mon, 20 Jul 2026 05:02:00 GMT

谷歌发布了A2UI v0.9"，这是一种与框架无关的标准，允许AI智能体声明用户界面意图并在Web、移动与桌面上原生渲染，而无需分发任意可执行的代码。该发布在谷歌开发者博客"上公布，其核心思想是：智能体应使用应用已有设计系统的表达方式，而不是自行发明新的组件。

最显著的变化是理念上的转变。根据CopilotKit"的说法，v0.9不是小幅更新：核心哲学、JSON结构与schema均发生了改变，协议也变为双向的。此前的可选组件集“Standard”已重命名为“Basic”，以表明前端开发者应将智能体接入已有组件。客户端方面，有一个共享的web-core库现在为浏览器渲染器提供基础，该版本同时包含官方的React渲染器，以及版本更新的Flutter、Lit与Angular渲染器，并为社区渲染器设立了专门位置。

智能体端也有了自己的工具包。新的A2UI Agent SDK为更低的延迟引入了缓存层，向Python智能体添加SDK只需一条安装命令：

pip install a2ui-agent-sdk

该SDK负责处理版本协商、运行时切换schema的动态目录，并具备增量解析与修复不完整LLM输出的健壮流式处理，使组件能随着内容到达而逐步渲染。新特性包括客户端定义的验证函数、用于协作编辑的客户端到服务器数据同步、改进的错误处理以及更简化的模块化schema。传输层也被精简，A2UI现在可在MCP、WebSockets、REST、AG-UI与新推出的A2A 1.0上运行。

迁移指南也已经发布。v0.8到v0.9的演进指南"记录了模型提示词方面向“提示词优先”的直接嵌入式模式的演进、模块化文件的重构以及属性重命名的速查表。团队需要注意，当前稳定系列的生产发布为v0.9.1，并且网站上已提供v1.0候选规范"及相应的v0.9.1到v1.0的演进指南"。

CopilotKit的Atai Barkai将v0.9称为“一次重大改进，内置AG-UI支持”"，并认为其已具备大规模采用的条件，但也有怀疑的声音。Hacker News"上的一位评论者质疑为何要信任LLM输出的UI，并担心安全漏洞、UI冒充攻击与可用性问题。

为什么会有人想要这个东西？为什么要相信LLM能输出UI呢？你是在自找安全漏洞、UI模拟攻击、糟糕的可用性等等。

有一篇Reddit帖子"认为目录模型的限制性太强，警告“每个界面都会变得雷同”。架构师Brian Love提出了一个折衷的方案（即固定目录和动态覆盖"），从而在验证失败时提供确定性的回退策略。

A2UI并不是该领域孤立存在的项目。它与AG-UI、MCP Apps、Vercel的json-renderer"及甲骨文的Agent Spec等项目是同一个领域的竞争者，面向Web的项目（比如，syntux）认为基于聊天机器人生成式UI所产出的“可弃用（disposable）"”界面，难以满足真实Web应用对一致性与缓存性的要求。目前谷歌将A2UI定位为位于这些方案之下的可移植契约。

A2UI是由谷歌制定的开放、与框架无关的规范，用于在Web、移动与桌面声明生成式的用户界面。完整的v0.9规范"、演进指南以及官方React、Flutter、Lit与Angular渲染器均发布在a2ui.org"站点上，A2UI Agent SDK的Python版本可通过PyPI"获取。

查看英文原文： Google Releases A2UI v0.9: Portable, Framework-Agnostic Generative UI"

企业 AI：方法论易得，交付力难求

籍云,凌敏 — Mon, 20 Jul 2026 03:32:56 GMT

前言：22 亿数字劳动力 VS E2E

2026 年，全球 AI 总支出预计达到 2.6 万亿美元，同比增长 47%。紧邻的追问是：AI 投入这么多，最终能转化出多少真实生产力？

IDC 的预测，顺势量化出一个“数字劳动力”图景：到 2030 年，全球活跃 AI Agent 数量，将从 2025 年的约 2860 万，快速增长至 22.16 亿。这意味着五年后，企业的数字劳动力数量将是今天的近 80 倍。

但规模不等于结果。22 亿个 Agent 上线，和真正产出业务价值，是两回事。中间的落差，是当前企业 AI 的集中难题—— 让 AI 真正上生产，交付的不能只是某个环节的能力提升，是一条完整业务链路的最终结果。行业把这件事叫「E2E 交付」。

E2E交付讲了几年，今年终于有人开始砸重金。7月，微软宣布投入25亿美元，组建6000人的Microsoft Frontier Company，专门帮企业把AI从PoC推进到生产。此前，亚马逊云科技已投入10亿美元设立AI落地部门，配置数千名驻场交付工程师。OpenAI、Anthropic也在上半年接连成立AI落地合资公司。FDE（前线部署工程师）模式迅速升温，几乎成为今年AI行业最热的关键词——巨头们正以前所未有的力度，往企业里派人。

集体爆发的FDE，我们尚且不论最终是否能够成功，但它本身就是E2E交付需求最好的证明：企业确实到了「光有工具不够，需要有人帮忙端到端交付」的阶段。

派人驻场是解法，把交付能力封装进产品是解法，项目交付是解法，企业自建也是解法。但无论哪条路，企业最终要的是可量化的业务结果。

在选择解法之前，先看清问题的全貌：这道从PoC到生产之间的鸿沟，究竟难在哪？

Production Gap：从PoC到生产，是工具到交付的差别

年初Gartner对企业AI价值发展划分了三个阶段，提供了一个参考坐标：第一阶段，AI作为工具，提升个人及部门效率；第二阶段，AI以智能体的形态执行任务，推动跨部门规模化应用；第三阶段，AI深度融入企业核心业务，影响商业决策。绝大多数企业，正卡在第一阶段到第二阶段的过渡处——工具已经好用了，但离交付业务结果还有一道鸿沟。

业界通常把这道从 PoC 到真正上生产之间的鸿沟称为「Production Gap」。几乎所有做过AI PoC的企业都体验过它的深度：技术团队交付的“可用原型”和业务部门能拿来扛KPI的“生产系统”之间，隔着一道墙。

这中间，AI要从「工具」跨到「交付」。

工具只需要“好用”—— 一个AI助手，写邮件、做摘要、辅助分析，好用就行，用不用得好是自己的事。但结果交付要求的是“可靠”—— 一个AI数字员工，它得能承担一个真实的业务岗位，产出可量化的业务结果，出了问题有人负责。

从“好用”到“可靠”，是标准的切换。一个AI工具回答错了一次，用户皱皱眉跳过就好。一个AI数字员工在生产环境里出了错，可能意味着客户流失、合规风险、甚至业务停摆。

Production Gap不是纯技术问题——它是技术、工程和组织问题的叠加。从PoC到Production，不是同一个问题的延续，是问题性质的切换——从「工具好用」跨到「交付可靠」。

多数企业并没有为这种切换做好准备。但阿里云智能集团CIO蒋林泉，很早就认清其本质，并从这道鸿沟里蹚了过来—— 他带领团队在三年内落地了 28 类 AI 数字员工，在阿里云内部真正上岗，覆盖了网站、服务、电销、CRM、内容、人事等几乎所有核心业务场景，还顺势「等效拓展」2000多个HC的产能。

一年前，阿里云CIO落地了28类 AI 数字员工

跨越鸿沟、结果交付，要付出真金白银和踩坑的代价。

蒋林泉从28类数字员工打磨中，思量出一套「避坑」的方法，沉淀成企业AI落地「RIDE」可复用路径。自2025年在AICon对外分享，不仅受到国内外权威分析机构的高度认可，也逐渐变成不少企业CXO在AI落地时的重要参考框架。

AI落地，他总结为四个关键点，依此推进：Reorganize（重组组织与生产关系，贯通全员AI认知）、Identify（识别真正适合用AI解决的业务场景）、Define（确保效果可度量，定义产品与运营指标）、Execute（推进数据建设与工程落地）。

这其中，有一个值得注意的细节：早在2025年6月，蒋林泉定义的“数字员工上岗标准”就已不是技术指标。他强调的标准是：能承担对应人类岗位的真实任务，能产出真实业务结果，且效率和效果要超过人工。达不到的，不算落地，不能上岗。

这种“以人的标准考核AI”的思路，和多数企业“以技术指标评估AI”的惯性截然不同。后者容易陷入一种陷阱：技术指标漂亮，但业务部门不认账。直接用业务结果说话，才能绕过这个陷阱。

他当时提出的一句原则，后来成为广为流传的经典： AI要和人比，不要和神比—— 也破解了很多企业管理者的恍然之处。

RIDE ：阿里云CIO从大模型「规模化落地实践」过程中沉淀、总结出的一套方法

虽然推出了有效的方法论，但蒋林泉很清醒，早就给出明智的判断：不遵循这些步骤，项目很可能失败；遵循也不保证成功，但能大幅提高概率。

接下来发生的事，合乎判断又出乎他的意料。

Talk is Cheap, show me the Product

方法论不够用，问题才真正开始。

在2025年6月到2026年6月的一年中，蒋林泉带着RIDE方法论，密集走访了十大行业的数十家头部企业，与近100位CIO、CTO、CEO展开深度探讨。反馈出奇一致：方法很好，听完很兴奋，但落到自己业务里，端到端的有效落地绝大部分还是没能突破。

行业不同，困境相似。

这一年交流下来，道理方法都懂了，为什么依然做不到？他把企业问题回归到两个核心矛盾。

矛盾一：自研做不起。

要自建AI数字员工体系，需要的远不只是预算——大规模高素质团队、数年实战积累、把AI嵌入业务流程的组织经验，多数企业并不具备。

一家企业的经历很典型：团队花大半年搭建了一个客服AI助手，投入十几人持续迭代，效果确实比通用方案好，但按这个投入产出比再做几个场景，团队规模至少得翻三到五倍。ROI完全“打不正”。不是企业不想做，是做不起。

矛盾二：通用方案不够用。

市场上不缺通用AI方案和Agent框架，Demo也确实效果惊艳。但一旦放到企业真实业务里——面对高度非标的业务逻辑、对交付结果“不能出错”的生产要求——通用方案的能力边界暴露得很快。企业需要的，是一整套经过高复杂度场景反复打磨的交付方案。这里，包含业务逻辑的深度理解、异常情况的穷举覆盖、长时间运行的稳定性保障——没有捷径，只能靠在真实业务场景里一轮一轮地磨。

自研做不起，通用不够用。绝大部分企业卡在了两者之间的夹缝里。

于是，蒋林泉这一年想得越来越清楚。

方法论能帮企业不犯错，不能帮做成。从“知道怎么避坑”到“真正在业务里跑通E2E交付”，走完这条路，企业所需要的团队规模、技术积累和工程经验，多数企业并不具备。

所以，蒋林泉的判断很直接："Talk is cheap, show me the product"——方法论是必要的起点，但能交付结果的产品才是珍贵的答案。

就此，半年多前，阿里云CIO团队作出了一个决定：把内部AI数字员工积累的能力「彻底产品化」。

背后是三个想清楚的判断 ——

第一，方法论对绝大部分企业不够，要把验证过的能力封装成产品。

RIDE 方法终究是路径，产品输出是结果，只有产品才能让企业直接拿走“经过实战验证的E2E交付能力”。

第二，阿里云内部千锤百炼出来的能力，对大量企业可以直接复用。

28类数字员工覆盖的场景几乎每个行业都有，三年持续迭代意味着绝大部分边界情况都被碰到过、处理过。其他企业会遇上类似的坑，但很少有条件用这样的规模和周期去蹚一遍。封装成产品，本质上是让高门槛的E2E交付经验变得可获取。

第三，一次性正面回应企业的真实诉求，为「结果交付」做输出。

大量交流中，CIO们反复提出的诉求指向同一件事：能拿来即用、直接交付业务结果的产品。这种需求密度和一致性本身，也许就是信号——市场已准备好为“结果交付”买单。

这个决定催生的产品，被命名为「睿系列」——在 7 月 3 日的阿里云飞天发布时刻上，正式对外发布。

珍贵的是，睿系列不是从 PPT 里长出来的——是从真实企业场景里，一轮一轮E2E落地硬蹚出来的。

要理解它和市面上其他AI产品的本质区别，先看背后的产品逻辑。

睿系列：不一样的是，AI 交付结果

从判断到行动，睿系列的产品逻辑，直指前文的两大症结。

第一，对于自研做不起——睿系列以产品化「自服务交付」，企业按需订阅即可上线，无需自建团队，从选场景到部署以分钟计。第二，对于通用方案不够用——睿系列的每款产品，都从真实业务中反复打磨而来，不是通用模型套壳，是把异常处理、边界覆盖、长期运行稳定性这些决定生产可靠性的经验，全部内化在产品里。

当然，回应症结只是及格线。真正定义睿系列的，是它和市面上绝大多数AI产品之间一个根本性的区别：它卖的不是能力，是结果。

过去几年，企业采购AI的方式不外乎三种——买模型自己搭、买SaaS工具、买项目做定制。形态不同，但有一个共同点：企业买到的是能力或工具，从能力到业务结果之间的转化风险，由企业自己承担。工具好不好用是一回事，能不能真正产出可量化的业务结果，只能看企业自己的执行力和场景适配。

睿系列采用的RaaS（Result as a Service）模式，把这个逻辑反过来。模型也好、工具也好，对企业来讲都只是手段——睿系列交到企业手上的，是「可量化的业务结果」。跑不通是产品方的问题，不是企业的问题。风险从买方转移到卖方。

这个承诺要成立，背后需要有三个支撑。

一是效果。每款产品的效果基准不是「比通用方案好一点」，是追平甚至超越人类专家——这是AI数字员工能真正上岗的及格线。达不到人的水平，谈结果交付便是空话。同时，企业TCO要压缩到人工的十分之一到五分之一。

二是可持续性。上线不是终点——产品持续从真实业务中学习，越用越好，越用越像企业自己团队里最能打的那个人。以前传统AI项目制交付，最大的痼疾，是做完一个项目，能力留不下来，换个场景又要从头再来；睿系列的能力长在产品里，不因项目结束而流失。

三是可自运转。企业自主完成训练、上线、迭代，不依赖外部团队驻场。如果AI的跑通能力跟着人走，人撤了能力即散了；睿系列把这个依赖关系切断——产品交到企业手上，就是企业自己的能力。

28类场景由内而生，克服了复杂度，经历了规模化，长时间实战检验沉淀——正是这些积累，让蒋林泉为睿系列RaaS产品家族设定了目标：以产品化自服务的方式，高效率交付效果超越人类专家的任务结果。

当然，交付逻辑能否成立，要回答一个现实问题：当 AI 已经真正进入岗位，是不是真的能像人类专家一样，交付业务结果，甚至达到SOTA效果？

此次蒋林泉首批选择「外呼和翻译」——两个场景看似普通，实则对E2E交付能力要求极高：业务复杂度高、质量容错率低，投入不到位就跑不通。

睿系列破局电销：当 AI 学会了犹豫时共情、松动时推进

一通电销对话里，决定能否向前推进，往往因为一些微妙的瞬间——电话方沉默两秒，或语调疑惑，或语速骤快，背后应该有的判断，过去只有最好的金牌销售能做好。

电销行业有一个公认的困局：20%的金牌销售贡献80%的业绩，但这种能力几乎没法复制。与此同时，单人月持有成本9000元，日产能上限在300通，合规零容错，季度离职率超过30%。人的能力天花板和人力模型的成本底线，同时卡住了这门生意。

市面上的智能外呼产品并不少，但两个问题始终没解决：

做不到像人——客户一接起来就听出是机器人，智商情商都不在，谈不上转化；计费有陷阱——不满一分钟按一分钟算，而外呼的天然特点，是大部分通话十几秒甚至一两秒就被挂断，企业在为大量无效通话买单。

睿呼宝做的，不是一个念稿的机器人，是一个能读懂客户的微妙变化、且储备专家经验的 AI 电销员工。

阿里云没有让睿呼宝在温室里自证，直接把它推上擂台——和人工外呼团队做正面A/B测试。产品续费提醒，睿呼宝的续费率高出0.6个百分点；试用到期的付费转化率，比人工高出0.4个百分点；线索清洗的洗出率，高出0.5个百分点。三个关键场景，全部追平甚至超越人工。

这里，比数字更值得关注的，是产品的评价标准变了。大量的智能外呼通常看拨了多少通、接通了多少次，至于客户有没有留下和转化，往往是销售团队的事。睿呼宝被拉进了人工电销原本的考核体系，只看结果。

这也是为什么，光像人还不够。

睿呼宝拥有99%的拟人度，以至于大量客户都并未意识到对面不是真人。但这里的「像人」，不是语音合成层面的像，是通话行为层面的像。电销的胜负手在于判断力——什么时候该推进，该等待，该收住。睿呼宝的「高智商」来自背后超过1亿通真实通话的训练，能精准识别意图、匹配话术、捕捉转化时机；同时，能实时感知50多种情绪变化，让它具备在客户犹豫时给出共情，在松动时果断推进的「高情商」。

在电销领域能够对标金牌销售，睿呼宝必须掌握的产品思路是：拟人决定客户愿意听下去，智商决定能不能转化，情商决定能不能赢得信任。三者缺一不可。

如果外呼数字员工能力这么强，使用和管理会不会是难点？

这就涉及另一点，产品的部署方式变了。企业想做一个能进入电销流程的 AI，往往要经历较长的开发、调试和磨合周期。睿呼宝将从零训练AI电销员工的时间，压缩到了 20 分钟，以交付自服务的形态。

而且，对数字员工来说，上线不是终点。电话接得多了，问题才会慢慢暴露。于是，睿呼宝会回看通话过程，识别问题出在知识错漏、表达偏差，还是SOP缺失，随之，它会去同场景里验证，辅助企业分钟级修复进化能力。

换句话说，睿呼宝能主动发现问题、解决问题、验证问题，它是持续进化的专业人士，是越用越接近团队里转化率最高的金牌销售。

当效果正面和人类比肩，甚至超越，而成本只有五分之一，只为有效通话计费，企业决策就变成简单的算术题。

睿系列攻克翻译：当 AI 执着于拉高被忽视的 0.1分

在翻译行业经典的5分制度量里，一份产品文档翻译质量是4.1分还是4.5分，差别有多大？

对于不在此领域的人，0.4分的差距微不足道。但对每天阅读这些文档的海外用户来说，即使是0.1分的差异，也是天壤之别 —— 是一种“能看懂，但总觉得哪里别扭”的不适感。

蒋林泉用了一个类比：每0.1分有点像声音的分贝——每增加一点，差异对Native读者都是显著可知的。对出海企业而言，这个差异直接影响海外客户信息获取的准确度和有效性，影响品牌信任和内容转化。

理解这个差距，是理解睿译宝价值的前提。

中国企业出海势头不减，但多语言内容的生产能力远远跟不上业务扩张。以阿里云自身为例：单一语种产品技术文档超过10万篇，GTM营销材料达3万份以上，国际峰会同传一年数百场。在很长一段时间里，这三件事全部被卡住——质量差、速度慢、成本扛不住。而且这三个问题是乘法关系：规模越大，每一个问题，都放大得越厉害。

本质上，企业翻译服务，处理对象不只是文字——翻译是嵌在业务场景里的客户服务、国际协作、产品发布。产品文档要与版本更新同步，营销材料要保留原有版式与品牌表达，技术术语要在不同渠道保持一致，会议口译要经得起临场变化。除了执着对待0.1分的「高质量」交付，更需要「高效率」交付。

到这里，不难理解，为什么翻译场景看似简单，却是极难做到有效的 E2E 交付。

在阿里云内部业务压力下，睿译宝用了两年迭代，在困境里反复打磨沉淀出来，克服了实际的大规模和高复杂度。此次敢于把它放在首批成员，正因它在三类核心翻译场景，全部做到了「SOTA」：

网站翻译——质量从4.18提升到4.68（提升了0.5分），发布速度从T+18天压缩到秒级实时。过去海外版要等近三周才能与中文同步更新，现在几乎是同步的。视频翻译、GTM文档——质量从4.1提升到4.5（提升了0.4分），交付从按周缩短到10分钟。同声传译——准确率从80%拉到95%，开口延时3到5秒，比肩甚至优于专业人类同传。

这些数字能够说明，睿译宝已经能够把原本依赖人工协作和多轮交接的翻译链路，变成一套可复用、可验证、可持续运行的数智化能力。

过去，做一次完整的国际化内容交付，要同时协调翻译公司、设计团队、视频制作方、同传服务商。现在，睿译宝将这条链整合为一个产品：网站·GTM·同传多重场景，统一产品套件，企业TCO仅为人工的1/10到1/5。同时，提供完备的16个语言对（互译英、日、韩、印尼、葡、法、德等主流商务语言），覆盖全场景格式（图片、音频、视频、PPT、PDF、Word、Excel、Markdown等）。

从翻译质量，到效率提升，再到成本降低，睿译宝在解决企业全球化过程中一个绕不开的问题：当业务走向全球，翻译能否不再依赖传统模式，是由 AI「一键交付」结果 —— 让翻译不再成为中国企业出海的负担。

写在最后：当 AI 从工具变员工，格局已不同

不论技术和商业多纷繁，事物的发展，原本是平凡里见世界。

当市场追着更耀眼的AI神话，阿里云CIO选择埋头在不那么明艳的场景，重投入——电销和翻译。但他自信的是，产品背后，是三年踩过的坑和28类AI数字员工的完整经验池。他也明确给出信号，要把产品背后价值万金的经验，封装成 AI 数字员工全产品矩阵。

这甚至是某种意义上的普惠。因为睿系列的产品化，确有不一样的意义：先在内部真实业务场景中历经高复杂度、反复试错和结果验证，再把已经跑通的能力沉淀向外。

蒋林泉对「睿系列」的定位很清晰：把那些过去只有大公司才能建设好、用得起的 AI 落地能力，通过产品化、自服务的方式，向所有企业开放。让每一家企业，无论规模大小，都能用得起、用得好。

回到企业AI这条路的起点——方法论是必要的，能交付结果是珍贵的。睿呼宝和睿译宝只是开始。AI数字员工能走进多少企业场景、改变多少行业的成本效率结构，睿系列会逐个揭晓。

就此，若把关注点拉高：当 AI 数字员工这个品类成立、开始批量上岗，AI 在企业里的角色正在发生质变——过去，它更多被当作演示、助手、工具、项目；现在，它要明确对业务结果负责。

一旦这个转变成立，三件事可能会随之改变：成本结构会被重写——当数字员工的成本降到人工的五分之一乃至十分之一，企业面对的不只是”省钱“，是那些过去做不起、做不好的生意，现在值得重新算一遍账；采购决策标准会切换——企业不只是要评估“工具好不好用”，更要直接验证“结果达不达标”；交付模式也在分化——今年巨头砸重金派人驻场，证明了需求真实存在；但靠人交付有局限，也有天花板，靠产品交付结果才有规模化的可能。

这些变化指向同一个判断：AI在加速跨越价值鸿沟。能生成，不等于能交付；能解决局部，不等于能交付全盘结果；能跑通一次，不等于能长期稳定运行。

企业AI的分水岭在逼近，想要结果，是时候做决策了。

Grab构建安全的智能体AI工作负载平台

作者：Patrick Farry — Mon, 20 Jul 2026 03:09:00 GMT

为安全地运行自治的人工智能工作负载，Grab的网络安全和平台工程团队构建了Palana"。Palana提供了一个安全、隔离的运行时环境，为本质上非确定性的模型驱动应用实现了确定性的防护边界。

在尝试为OpenClaw等智能体框架搭建原型环境后，Grab认识到需要一种系统化、基础设施层面的方案来控制高度自治的智能体所带来的安全风险，于是开发了 Palana。

传统应用的行为通常是可预测的，而模型驱动的智能体会随意调用工具、调用API、读写源码以独立解决问题。这种自由带来了严重的安全挑战，使智能体易受提示词注入、逻辑劫持、依赖项威胁、过度追求目标与幻觉等威胁。例如，参见“AI Agents Gone Rogue”"的介绍。

引入Palana后，Grab在不为每个工作负载构建手工专属环境的情况下，解决了智能体身份标识、网络访问与运维审计等关键的基础设施问题。

该平台以隔离区（isolation）为主要的信任单元，采用零信任模型，确保某一智能体框架的安全威胁不会影响相邻的工作负载或底层计算集群。Palana为每个智能体分配独立的Kubernetes命名空间，配置严格的基于角色访问控制 (Role-Based Access Control，RBAC)、自定义网络策略与隔离的服务账户，同时为智能体提供持久化的本地存储，以在容器重启时保存状态与内存，支持长时间执行的异步工作流。

对于自治智能体，常规条件下通过环境变量或挂载文件传递凭据的方法所带来的风险是无法让人接受的，因为被威胁的运行时可能将高价值的API密钥泄露给非受信的脚本。为了消除该风险，Palana将密钥管理解耦为“智能体可读的凭据”与“仅代理可用的密钥”。高度敏感的凭据（比如，版本控制的个人访问令牌与模型网关的API密钥）被保存在HashiCorp Vault中。

智能体容器只会配置抽象的占位令牌。当智能体发起外部API调用时，中间的安全代理会拦截请求、验证目标并动态替换占位符为真实的密钥。因此，原始密钥从不会写入智能体容器的环境、执行内存或日志文件。

由于智能体必须与外部工具和模型端点进行通信以具备生产力，出口通道被设计为集中式的安全控制点。Palana会自动将所有出站的HTTP/HTTPS流量通过Envoy代理和运行Open Policy Agent规则的外部授权服务进行路由。代理以中间人证书终止方式实时流量解密，允许头部评估计算（header evaluation）、端点验证与令牌替换，同时生成详细的结构化审计跟踪。

此外，鉴于我们无法信任被威胁的智能体会自行终止，因此所有运行控制完全集中在执行运行时之外。网络级的“断网开关”可从控制平面直接禁用网络策略，独立的外部回收器（reaper trigger）在空闲时会触发关机，而无需修改核心的智能体代码。

通过将安全机制整合到Kubernetes原生框架中，平台架构师可以使用标准的基础设施即代码方式来扩展与调试智能体运行时。每个智能体被建模为由自定义Kubernetes operator调和的自定义资源，该operator动态配置命名空间、存储、网络策略与入口路径。

该设计将运维体验拆分为面向开发者的简化UI与命令行工具，以及面向系统工程师的健壮标准Kubernetes层。平台团队可以利用这些原生定义对数百个并发智能体工作负载在生产集群中的生命周期进行编程化审计、更新与管理。

查看英文原文：Grab Builds Secure Agentic AI Workload Platform"

Agent 会执行，但谁来帮它记住过去？

凌敏 — Mon, 20 Jul 2026 02:51:02 GMT

过去一年，AI Agent 正快速进入真实工作场景。它们可以帮助开发者生成代码、执行任务、分析问题，但在实际使用中，一个新的瓶颈逐渐显现：Agent 很聪明，却总是“记不住”。

每次新的对话，都需要重新加载上下文；个人积累的经验无法沉淀，团队共享的项目背景、历史决策和任务过程也难以继承。当 Agent 从个人助手走向团队协作，“记忆”正在成为决定其能否真正融入研发流程的关键能力。

日前，腾讯云数据库团队开源了一套面向 AI Agent 的分层记忆引擎：TencentDB Agent Memory。它能给长期记忆建立层级，给短期记忆引入符号压缩，让 Agent 拥有超强记忆。

7 月 28 日 19:00，腾讯云 DBTalk 第六期特别策划《「TencentDB Agent Memory」技术解密：从个人记忆到团队资产，Agent 记忆的进化与开源之路》主题直播，特邀三位腾讯云数据库产品专家，围绕团队记忆的产品设计理念、AI Native 团队资产基础设施架构，以及团队记忆的开源社区共建三大方向展开深度分享，帮助开发者与企业用户系统理解 Agent 记忆的技术路线与落地实践。

精彩议题抢先看：

议题一：从个人记忆到团队资产：TencentDB Agent Memory 团队记忆版本解析

本议题将介绍 TencentDB Agent Memory 即将开源的团队记忆版本，重点分享为什么 Agent 需要从个人记忆走向团队记忆，以及团队记忆如何帮助 Agent 继承项目上下文、团队经验和任务资产，让开发者更快地把这套能力接入真实研发场景。

议题二：别再让团队失忆：从研发上下文到 AI Native 团队资产基础设施

本议题从研发架构视角，分享如何将研发协作中的上下文、经验、决策与任务过程，沉淀为可继承、可复用、可治理的团队资产，并通过 Agent 工作流释放其价值。

议题三：让团队记忆在共建中完善：TencentDB Agent Memory 的开源之路

本议题从开源社区建设的角度出发，通过团队记忆管理面板的实际演示，展示记忆资产如何被查看、治理与复用；随后分享 TencentDB Agent Memory 开源社区的建设思路与产品 Roadmap，并向所有开发者发出共建邀请——无论你是想接入使用、贡献代码，还是共创场景，都能在这个社区找到自己的位置，一起把“团队记忆”从一个产品，做成一套开放的记忆基础设施。

想了解 Agent 记忆技术路线，探索 AI Native 团队协作新模式，围观这场直播就对了！扫描下方二维码，或点击链接：https://qdrl.qq.com/HdtXrCYQ"，提前锁定直播席位~

扫码添加企微小助手，一键加入开发者专属企微群，即可免费获取讲师 PPT，助力学习高效进阶！

为敏感的云系统设计连续授权

作者：Venkata Nedunoori — Mon, 20 Jul 2026 01:22:51 GMT

核心要点

大多数云系统仅在登录时做一次授权决策，这导致在会话期间对高风险数据操作缺乏持续的校验。将每个敏感操作作为独立的决策点，让系统能够检测批量访问、异常查询量与上下文切换等滥用模式。授权决策可以生成可审计的证据且避免暴露底层的敏感数据，从而解决隐私监管环境中的核心难题。连续授权系统通过行为基线、选择性评估与缓存策略在实时风险评估与性能之间取得了平衡。将授权从静态权限转向运行时决策，有助于降低分布式云系统的大规模数据暴露的风险。

某个客户服务代表在9:00通过认证访问了一个医疗平台，其角色允许查看患者的记录。到10:00，该账号已将5000条患者记录导出为CSV；在10:15，该文件发往了其个人邮箱。安全信息与事件管理（Security Information and Event Management，SIEM）告警在数小时后才触发，事后调查记录显示“用户具有相应的权限”。大多数组织仅在审计或安全事件回溯时才发现这一授权模型的盲点。

此类情形在处理个人身份信息（personally identifiable information，PII）与受保护健康信息（protected health information，PHI）的行业中反复出现，因为现行授权模型只会在登录时做一次决策，之后的所有操作都只是对那次登录权限的执行。

为什么登录时的授权会失效

基于角色的访问控制（role-based access control，RBAC）决定用户是否可以调用某个API或查询某个表，但并不会评估他们当前是否应该从该位置、针对该数据、以该数据量执行这个操作。"能做"与"应该做"之间的差距在涉及敏感数据的泄露调查中屡见不鲜。

我们考虑一个常见的合规性需求，该需求规定客服团队只能访问其正在支持的账户。典型实现是在目录服务（例如，Active Directory，AD）中给出对客户数据库的只读角色。在理论上，访问被局限在已授权的人员，但实际上，支持账号仍然可以执行像下面这样的查询，并检索超出其实际操作需要的数据集：

SELECT * FROM customers WHEREsegment = 'high_value';

在某生产环境中，这种模式仅在团队审查导出活动后才能被发现，人们会意识到少量支持账号在故障排查流程中常规性地检索数千条客户记录，而这些流程此前并未正式审查过。

认证与授权之间的差距并非语义问题。认证确认身份标识，授权决定在当前风险上下文下某个特定操作是否仍然合适。许多处理受监管数据的系统缺失的正是这种基于风险与上下文的实时评估。

基于云的系统将数据的可访问性扩展到了传统网络边界之外。过去数据库部署在受VPN保护的内部网络中，环境控制创造了自然的约束，员工在公司网络与受管设备上工作。而在现代云环境中，访问模式更为分散：承包商、第三方支持团队与远程工作者经常会从外部网络使用与内部用户相同的身份基础设施来访问敏感系统。授权控制必须补偿对网络边界依赖的减弱。

持续授权的架构

图：基于风险的持续授权架构（图片来源：作者原创）

在连续授权架构中，每个涉及敏感数据的操作都会成为一个授权检查点。系统不再仅问“此角色是否拥有SELECT权限”，而是基于行为基线、当前位置、时间与数据敏感性评估用户是否能够对指定数据集执行特定的查询。

并不是所有的请求都需要同等级别的审查。架构需要在常规操作与高风险访问模式之间进行区分，以在响应性与控制之间取得平衡。

例如，临床人员在标准工作时间内从已知受管设备访问其分配的患者记录可使用缓存决策。偏离预期模式的请求则触发更深层的评估。这样可以将关注点集中在风险与数据敏感性都比较高的场景上。

实时评估要结合多类信号，包括行为偏离、网络特征、设备一致性、查询活动、导出行为以及被访问数据的敏感性。

策略引擎将这些信号合成风险分层（比如，低、中、高），并映射到审批、事件提升验证（step-up）、升级或拒绝等动作。

为了保持响应性，评分机制应该尽可能保持轻量级。大多数系统依赖历史行为基线，并将更深入的分析留给高风险的场景。

策略决策点设计

策略决策点（Policy Decision Point，PDP）位于应用逻辑与数据访问之间，类似于OAuth资源服务器或API网关，不同之处在于决策的丰富性与延迟方面的约束。

面向用户的系统无法在每个请求上承受重量级的计算。相反，应由风险信号聚合层（Risk Signal Aggregation Layer）在后台持续更新行为画像。

行为分析在将当前活动与长期运维模式（比如，查询量、访问时段、结果集大小、导出行为与常见查询类型）比较时才有价值。请求到达时，系统评估当前操作是否符合基线或是否偏离了预期。

在生产环境中，超出正常行为波动的偏离会触发额外的审查。较小的偏离可能导致日志增强或提升验证，而较大的异常则可能触发事件升级或临时阻断。

角色感知同样非常关键。分析人员、调查人员与支持工程师的访问模式天然比业务用户更广泛。高效的系统应该根据角色规范评估行为，而不是对所有用户使用统一的阈值。

环境信号以极低的计算成本提供了额外的上下文。IP段分类、浏览器一致性与受管设备验证通常是简单的查询，但在授权决策中它们提供了有意义的指示。

例如，在预期的工作时间内从公司网络访问通常风险较低，而来自非监管设备且位于异常地理位置的特权导出则请求风险较高。设备指纹也有助于识别凭证滥用：如果用户先在一台设备上认证，随后数分钟内的请求却来自另一台设备或不同位置，系统即可将会话标记为需要额外评估。

数据敏感性引入了另一个关键的维度。它的挑战不只是判断某张表是否包含PHI，而是判断请求是否以异常规模或频次访问高度敏感的记录。我们无需追求完美的分类，目标是在大规模泄露发生前识别高风险的访问模式。

审计能力也是架构挑战之一。像HIPAA"与GDPR"这样的法规要求保留详细访问记录，但这些日志本身如果就包含了敏感信息，也会成为受监管的数据集。

例如，直接记录：

“User 4582 accessed Patient 1234's cardiology record”

就会在审计系统中创建另一个需要保护与治理的受监管数据仓库。

更实用的做法是记录上下文化的授权证据，例如：

“User hash A13F initiated a high-sensitivity read operation from managed device B54452 during standard operating hours. Risk level: low. Decision: approved.”

这样既保留了审计与调查所需证据，又将日志系统中的敏感暴露降到最低。

典型的授权审计记录包含核心决策上下文：哈希化的用户标识、时间戳与会话信息、操作类型、数据类别、计算出的风险等级、贡献性风险信号、决策结果以及所有的事件升级或审批链条。

这种结构允许组织在不复制敏感数据到审计系统的前提下重构访问行为。

通过缓存优化性能

连续授权会带来额外的处理开销，尤其在大规模数据访问的系统中。要保持响应性，需要选择性评估与积极的缓存策略。

系统不应对每个请求施加相同的审查，而是要重用低风险的决策，并将实时评估保留给异常或高敏感度的操作。

缓存通常会分层出现。策略规则进行短期缓存，用户风险基线在后台异步刷新，重复的低风险操作复用临时的授权决策，而可疑访问模式则继续进入更深的实时评估。

这些方法引入了可控的最终一致性。实践中组织需要接受这一权衡，因为主要目标是防止持续性或大规模的异常访问，而不是对每个单次查询做出反应。

隐私保留分析进一步通过保留汇总的行为信号而非详细的访问历史来减少存储开销。

系统通常会保留像查询量趋势、结果集分布、常见查询模式和不同数据类别的访问频率这样的汇总类行为指标，而不是长期保存高度细粒度的访问历史。

详细日志用于短期调查，长期基线依赖于汇总度量。

策略部署：三阶段滚动发布

连续授权策略在首次部署时很少会完全正确。只有在真实生产流量下，合法工作流、运维捷径与边缘情况才会显现。

成功的实现通过逐步引入策略而非立即强制执行以减少破坏。

第一阶段为影子模式。评估并记录授权决策但不影响用户的操作，这允许团队在生产流量下观察策略行为并识别误报。

在多个环境中，影子部署能够暴露长期存在但从未正式批准的规范化操作流程。

第二阶段引入有限的强制实施。策略可能要求提供理由、触发警告或允许对已批准的操作场景进行临时覆盖。该阶段用于验证策略逻辑与合法工作流的一致性。

只有在阈值稳定后，组织才进入全面的强制实施阶段，在该阶段，高风险操作会被阻断、升级或通过审批工作流来进行处理。

分阶段发布在减少运维中断的同时，为团队争取了优化行为基线、异常处理与审批路径的时间。

生产模式

最早且最有效的连续授权控制通常聚焦于批量导出、跨租户活动与机器对机器的访问。

批量导出场景尤为重要，因为它们将运维需求与升高的风险结合在一起。许多组织会随着导出量或敏感性增加逐步提升审查的力度。

这些控制经常会暴露出在技术上符合RBAC策略但违反运维预期的行为。

跨租户访问是另一项常见的挑战。支持工程师有时候需要跨客户或租户的临时访问，组织通常通过以下方式来进行处理：

审批工作流时限型权限增强审计日志账户所有者通知跨租户异常检测

机器对机器访问会采用不同的模型，因为API服务账号不会表现出典型的人类行为。系统需要评估期望的工作负载特征，例如：

期望的查询量允许的数据范围允许的执行窗口与服务身份绑定的速率限制

例如，夜间批处理在预期的报告窗口内处理10000条记录可能是正常行为；如果同样的工作负载在异常时间执行或访问显著更大的数据集，则应引起调查。

运维方面的考量

连续授权系统需要持续调优，以在安全效果与运维可用性之间取得平衡。

不同用户类别天然会产生不同的访问模式。分析人员、调查人员与运维支持团队通常需要比常规业务用户更广泛的数据访问。有效实现应根据角色期望调整阈值，而非一刀切地应用统一的限制。

用户体验也很重要。当用户收到清晰的说明、预期的审批路径与透明的修复指引时，升级工作流的执行会简单得多。

对覆盖操作的治理同样需要严格执行。多数组织要求书面的业务理由、范围化的审批、到期时间与定期审查以管理临时的例外情况。

运维监控也至关重要。团队常用回滚机制或功能开关在新策略导致不可预期的延迟或运维中断时快速将其禁用掉。

当前环境的驱动因素

各行业与地区对数据保护的监管期望正在持续扩大。处理受监管信息的组织在访问治理、可审计性与泄露响应方面面临着愈发严格的问责。

与此同时，云原生系统、分布式团队与AI辅助工作流降低了对传统网络边界的依赖。敏感数据在系统、用户、API与自动化层之间的流动比以往更快。

随着这些边界的弱化，授权系统需要在实时评估敏感操作是否仍然合适方面承担更多的责任，而不是仅仅信任会话登录时构建的权限。

衡量效果

评估连续授权系统需要在安全成果与运维影响之间取得平衡。

从安全角度来看，团队通常关注减少不受控的批量访问、提前识别异常行为、改进审计可追溯性与加快调查时长。

对比静态授权模型，实施类似控制的组织通常会报告获得了对高风险访问模式更好的可见性。

运维指标同样重要。如果授权系统引入了过高的延迟或频繁误报，那么它将会迅速被移除掉。

结构化的授权证据也能简化调查。团队无需通过大规模日志关联来重构事件，而是可以直接审阅有上下文的授权决策。

尽管具有这些优点，连续授权并不是每个工作负载的必需方案。

何时不必采用连续授权

连续授权会带来架构与运维方面的复杂性。对于低敏感度系统、内部分析工作负载或不处理受监管数据的环境，较为简单的访问控制模型仍然适用。

并不是所有的场景都必须部署连续授权。更深层次的评估模型最适用于那些因运维、监管或多租户暴露而证明有必要承担额外复杂性的环境。

实施起点

最有效的实现要从增量改进开始，而不是试图全面重构现有的授权系统。

实用的起点是可观测性。在引入动态授权决策前，组织需要对当前的访问行为具备可见性：查询量、访问时序、结果大小与使用频次有助于建立用于上下文评估的行为基线。

数据分类同样重要。对所有数据集一视同仁会带来不必要的摩擦。大多数组织要先从受监管或高敏感度的数据类别入手，然后再逐步扩展。

在获得可见性后，可通过影子评估以非阻断的方式引入策略。团队在生产流量下观察策略行为、调优阈值并识别边缘情况，然后再逐步开启强制实施。

随后，组织通常先聚焦于连续授权能立即创造价值的运维场景，尤其是批量导出、跨租户访问、特权操作与机器对机器活动。

审计能力也应尽早纳入。结构化的授权决策日志为运维审查、合规验证与未来策略完善提供了证据，同时避免了在审计系统中创建不必要的敏感数据仓库。

这些步骤使组织能够在不破坏现有应用架构与运维稳定性的前提下逐步引入连续授权。

结论

授权不只是登录时的静态决策。在处理敏感数据的分布式云环境中，授权越来越成为对访问是否仍然合适的连续评估，要基于当前上下文、行为与风险作出判断。

从静态权限转向上下文感知的运行时决策，与更广泛的Zero Trust架构原则"紧密契合，并可利用现有的身份系统、API网关、策略引擎与可观测性工具逐步实现。

在实践中，最难的部分往往不是策略评估本身，而是如何在不破坏日常运维工作的前提下引入更强的控制。

随着时间的推移，组织将持续引入机器学习与AIOps技术来改进异常检测与自适应策略调优。但核心挑战仍然是架构性方面的：将授权决策尽量靠近敏感操作发生的瞬间，而不是仅仅依赖登录时建立的信任。

查看英文原文：Designing Continuous Authorization for Sensitive Cloud Systems"

寻找 AI 原生时代创业者：极客部落 OPC 入驻招募启动！

Serena — Sun, 19 Jul 2026 04:34:19 GMT

小贴士：OPC 是什么？全称 One Person Company（一人公司），是AI时代最先锋的创业形态之一：一个人或一个极小团队，借助AI完成产品研发、运营、交付与增长。如今，OPC已被写入多地“十五五”规划，北京也正从创业空间、企业登记、算力与政策服务等方面加快布局。新一批站在技术浪潮前沿的“超级个体”，已经开始把一个人的想法，真正落地为可经营公司。

一、新居落地，汇资聚才

7月16日，“AI赋新质·智启新增长——星禾AI智体创新谷启动暨望京新质产业加速器周年沙龙”在望京SOHO T2座20层举行。

活动现场，极客部落·AI 应用生态园作为首批核心 AI 产业平台，正式入驻星禾 AI 智体创新谷。继极客部落首期空间投入运营后，极客部落在望京区域的第二个 AI 创业服务空间正式落地，进一步完善面向 AI 创业者、独立开发者、 AI Builder 及 OPC 团队的创新创业服务体系。

依托全新空间载体，极客部落 OPC 入驻招募同步进行，并将于 2026年7月30日举办第二场 OPC 入驻评审活动，持续发掘和支持具备产品能力、技术潜力与商业价值的 AI 创业项目。

1、构建 AI 创业服务新载体

极客部落二期空间位于北京市朝阳区望京 SOHO T2 座 20 层，地处望京核心区域，周边汇聚科技企业、创新平台、投资机构及产业服务资源，具备良好的创新创业氛围与产业协同基础。

空间将围绕 AI 创业团队实际发展需求，提供办公交流、项目展示、活动路演、资源对接及创业服务等多元化支持，打造集创业办公、项目孵化、产业链接、社区交流于一体的 AI 创业服务载体。

极客部落希望通过空间载体与社区运营相结合，为创业团队提供稳定的线下发展阵地，帮助项目从产品构想和 Demo 验证，逐步走向用户增长、商业落地与持续经营。

2、聚焦 OPC 创业群体

本次招募重点面向 AI 创业者、独立开发者、AI Builder、OPC 创业团队及 AI 原生小团队。

招募项目应围绕人工智能技术形成明确产品或服务，具备相对清晰的目标用户、应用场景与发展方向。已拥有 MVP、Demo、上线产品或阶段性实践成果的团队，将作为本期重点关注对象。

极客部落将重点关注以下类型项目：

以人工智能为核心生产力或核心产品能力的创新项目；聚焦真实用户需求和实际应用场景的 AI 产品；具备技术创新、产品化及商业化发展潜力的创业团队；团队规模精简、执行能力较强、具备持续迭代能力的 OPC 项目；愿意参与创业社区共建，并与其他项目开展交流协作的创业者及团队。

通过公开招募、项目路演、专业评审及后续沟通，极客部落将持续筛选具有发展潜力的 AI 创业项目，形成覆盖项目发现、入驻孵化、资源匹配与成长陪伴的创业服务机制。

二、链接资源，协同赋能

1、政策资源协同赋能

依托望京街道、星禾 AI 智体创新谷及区域产业服务资源，极客部落将围绕创业团队在办公空间、政策支持、算力资源、融资对接、企业服务及市场传播等方面的现实需求，持续完善创业服务支持体系。

符合条件的创业团队，可关注朝阳科创人才 15 条、凤凰人才、ITEC 创新创业大赛等相关政策，以及办公场地支持、创业融资、人才服务、算力及模型资源、应用场景开放等扶持方向。

朝阳科创人才 15 条内容简介：

1、支持对象人工智能、数字安全、数字医疗等“科技+”重点领域，一般为 35 周岁以下，首次在朝阳创业，创业时间 3 年以内的优秀青年人才。2、住房支持优秀青年创始人提供 3 个月免费住房，后续给予 20% 房租补助；对于人才企业在营收、融资、专利、研发等方面成长较快的，给予最高 50% 补贴，每月最高 2000 元，最长补助 3 年。创业优秀博士全球 TOP200 的 STEM 专业博士，可申请免租金人才公寓，最长支持 3 年。博士后出站后在朝阳区创新创业，签订 3 年及以上劳动合同，可获 20 万元安家补贴，或最长 3 年免租金人才公寓。3、办公支持初创“企业”免费注册地，最长两年的共享会议空间、 5 个共享工位。成长“企业”首年 50%、次年 30%、第三年 20% 的空间支持，最高 500 平方米。4、融资支持首贷贴息首次贷款可申请全额贴息补贴。融资补贴单笔融资利息 30% 贴息补贴，连续 3 年，每年最高 10 万元。天使轮奖励天使轮融资金额 10% 作为奖励，最高 50 万元。5、研发创新支持按照用实验室或大型科研仪器设备、委托实验等项目合同的 50% 给予资金支持，最高 50 万元。6、算力支持支持使用算力券、模型券、语料券等开展研发创新活动。按照项目合同的 50% 给予资金支持，每年最高 50 万元。7、应用场景支持免费提供一批应用场景。支持应用场景落地：单个项目最高奖励 30 万元。支持场景对接服务：每年成功对接 5 个及以上的，一次性补贴 10 万元。8、企业白名单建立“青年科技人才初创企业白名单”，开通专项通道、增加合规指导、优化行政审批流程。9、区级配套奖励首都级立项项目落地朝阳，给予同等额度配套奖励，最高 200 万元。海外人才引进项目经推荐认定的中央、北京市海外人才，享受市级同等额度配套奖励。10、安居服务外籍博士协助办理 5 年有效期的往返签证，含配偶及未成年子女。国内人才工作居住证申领、医疗保障、子女入学需求协调。11、创业空间改造打造支持青年科技人才创业的“驻朝空间”，给予最高 100 万元补贴，连续支持 5 年。提供政务、财务、投融资等一站式服务。12、实习支持建立海外人才实习基地，提供优质实习岗位。13、用人主体引才民营企业每引进 1 名全球 TOP200 的 STEM 专业博士，稳定工作 1 年后，给予 10 万元奖励。14、技术成果转化奖励技术转移人才促进技术或项目取得重大突破并落地朝阳区，给予单个项目最高奖励 20 万元，按实际服务佣金的 50% 计算。15、时尚引才统筹区内资源，为青年科技人才提供时尚商圈 VIP 服务、文化地标体验、休闲娱乐等人才礼遇。极客部落将结合项目实际情况，为创业团队提供政策信息解读、申报方向匹配及相关资源对接支持，协助创业者更加高效地了解和使用区域创新创业资源。相关政策均需符合相应申报条件，具体支持内容、申报标准及最终结果，以政府相关部门最新政策及审核结果为准。

2、链接产业服务资源

除办公空间及政策服务外，极客部落还将围绕 AI 创业项目不同发展阶段，持续链接技术平台、产业资源、投资机构及专业服务机构。

入驻项目有机会获得以下支持：

云服务、算力、模型及技术生态资源对接；投资机构、创业导师及产业合作资源链接；企业真实需求、产业应用场景及项目合作机会；产品展示、内容传播、活动路演及媒体曝光支持；极客部落及合作社区的创业交流与项目共创机会。

极客部落将从创业者真实问题出发，根据项目所处阶段及具体需求，开展有针对性的资源匹配与创业服务，帮助团队提升产品成熟度、市场连接能力及持续经营能力。

三、砥砺扬帆，新章再启

1、开启本期 OPC 入驻通道

极客部落 OPC 入驻评审活动将于 2026年7月30日在望京 SOHO T2 座 20 层举行。

通过项目介绍、产品展示、评委提问及综合评审等环节，对报名项目的产品能力、技术特点、应用价值、商业模式及团队发展潜力进行综合判断。

通过评审的项目，将进入后续入驻沟通及资源匹配流程；暂未进入本期入驻名单的优质项目，也有机会进入极客部落项目资源库，持续参与后续活动、项目展示及资源对接。

活动信息

活动名称：极客部落 OPC 入驻评审

活动时间：2026年7月30日

活动地点：北京市朝阳区望京 SOHO T2 座 20 层

招募对象：AI 创业者、独立开发者、AI Builder、OPC 创业团队及 AI 原生小团队

项目阶段：已有明确产品方向，原则上具备 MVP、Demo、上线产品或可展示的阶段性成果

尾声：共建望京创新发展新生态

随着极客部落·AI 应用生态园正式入驻星禾 AI 智体创新谷，极客部落将进一步发挥创业社区、产业平台与创新载体的协同作用，持续引进优质 AI 创业项目，连接政策、空间、技术、资本、市场及专业服务资源。

下一步，极客部落将以本期 OPC 招募为起点，常态化开展项目评审、创业交流、政策解读、资源对接及产品展示活动，陪伴更多 AI 创业团队从 Demo 走向产品、从产品走向市场、从创业项目走向可持续经营。

极客部落本期 OPC 入驻招募现已正式启动。

欢迎正在推进 AI 产品和创业项目的个人及团队报名参加，共同加入望京 AI 创新创业生态。

咨询联系人及联系方式

边端AI不只缺算力：安谋科技重做CPU、NPU、VPU与AI操作系统

李冬梅 — Sun, 19 Jul 2026 03:09:02 GMT

7月18日，WAIC 2026期间，安谋科技在上海世博展览馆举行AI前瞻发布会。

与展馆中大量围绕超节点、万卡集群和云端大模型的讨论不同，这场发布会把重点放在了另一端：当AI进入嵌入式设备、摄像头、机器人、工业网关和边缘计算节点，有限功耗、有限内存和复杂负载将如何改变芯片与系统设计。

发布会涉及四条技术线：面向嵌入式设备的“星辰”CPU与Arm Helium指令集，面向边端推理的“周易”X3-Pro NPU架构，面向机器视觉的“玲珑”VPU，以及安谋科技牵头发起的开源AIOS联盟。

把这些内容放在一起看，安谋科技这次在 WAIC 上试图回答的是一个更具体的工程问题：在功耗、温度、内存带宽和软件生态都受到约束的情况下，如何让计算、视频和系统软件形成一套可以部署的本地AI基础设施。

端侧AI的矛盾，不只是模型太大

过去几年，端侧AI通常被理解为把云端模型缩小后放进终端。但这种理解忽略了两类计算环境之间的差异。

云端服务器通常可以通过增加GPU数量、显存容量和网络带宽扩展计算资源，而嵌入式设备首先受到电池、散热、芯片面积和成本限制。摄像头、门锁、可穿戴设备和工业控制器也很难为了运行一个模型，持续占用全部CPU资源。

与此同时，端侧任务又对实时性提出了更严格的要求。云端应用可以等待模型完成数秒推理，但语音唤醒、人脸检测、机器人避障和工业控制往往需要立即响应。大量视频、音频和传感器数据如果全部上传云端，也会带来网络依赖、带宽成本和数据管理问题。

这意味着，端侧AI面对的不是单纯的算力不足，而是性能、功耗、响应时间、带宽和可靠性之间的多重约束。

安谋科技CPU产品总监朱晓鸣在现场将端侧计算划分为三类需求：始终在线的低功耗感知、由CPU承担的逻辑控制，以及相对复杂的AI计算。在这种架构中，CPU仍然负责系统控制、实时任务和通用逻辑，向量计算单元和NPU则分别承接适合并行处理和矩阵计算的负载。其目标是让嵌入式设备在有限的功耗和算力下尽可能多的释放AI计算潜力。

CPU的变化：给传统嵌入式计算增加向量能力

在端侧AI系统中，CPU并不会因为NPU出现而消失。

模型运行前后的数据预处理、算子调度、设备控制、实时操作系统任务以及大量非矩阵计算，仍然需要CPU完成。对于规模较小的音频检测、传感器分析和简单视觉任务，直接在CPU上运行还可以减少不同处理器之间的数据搬运和调度开销。

安谋科技此次重点介绍了Arm Helium技术。Helium是面向Arm Cortex-M系列处理器的向量扩展，采用128位固定长度向量设计，并增加了一系列面向数字信号处理和机器学习的指令。其作用不是替代NPU，而是提高CPU处理并行数据的效率。

按照现场公布的测试结果，在蓝牙音频编解码场景中，以Cortex-M4为基准，采用相应架构的Cortex-M52、M55和M85分别获得约30%、50%和65%的性能提升；在部分机器学习测试中，M55和M85相较较早一代处理器平均提升约3倍，个别项目超过8倍。上述数字来自安谋科技现场演示，具体表现仍会受到模型、编译器、存储系统和芯片实现方式影响。

安谋科技自研的“星辰”CPU从第二代产品STAR-MC2开始支持Helium。此次现场展示的“星辰300”是一套原型验证平台，将STAR CPU与Arm Ethos NPU集成在FPGA平台中，用于运行人脸检测等端侧模型。

演示中，摄像头画面先由笔记本采集，再传输至验证平台，由CPU与Ethos-U55完成推理并在屏幕上显示检测结果。

这个平台目前更接近芯片设计与软件适配阶段的验证工具，其意义在于验证CPU、NPU、内存和软件工具链能否协同工作，而不是一款直接面向消费者的终端产品。

从工程角度看，CPU指令扩展适合解决规模较小、控制逻辑较多或者需要低延迟启动的任务；当模型进入实时视觉、较复杂的语音处理和语言模型场景后，专用NPU仍然是主要的计算补充。Arm Ethos系列目前覆盖约64 GOPS至4 TOPS的算力范围，主要面向对面积和功耗敏感的端侧设备。

真正决定这套组合能否落地的，也不只是CPU和NPU的理论性能。数据能否在不同计算单元之间高效流动、编译器能否把算子合理拆分、模型中不受支持的算子如何回退，以及内存容量是否足够，都会直接影响最终效率。

NPU不再只看峰值算力

如果说CPU部分解决的是轻量化AI如何进入传统嵌入式设备，那么“周易”X3-Pro讨论的则是更复杂的边端推理。

安谋科技将边端AI场景分为个人终端、视觉与空间智能、工业与能源边缘、边缘节点与本地AI盒子四类。这些场景对芯片的要求并不相同：手机和可穿戴设备关注续航与隐私；摄像头、机器人和汽车强调低延迟、多模态感知与可靠性；工业设备更重视任务确定性和长生命周期；边缘服务器则需要多路并发和长时间运行。

因此，一套固定规格的NPU很难同时在所有场景中获得较高效率。

安谋科技正在研发的“周易”X3-Pro没有简单沿用单一芯片覆盖所有市场的思路，而是提出统一软件架构、统一指令集和硬件接口，再根据不同负载配置差异化硬件。规划中的产品包括面向低功耗场景的Lite系列、中等算力产品以及面向复杂推理任务的子系统方案。

这套架构的核心逻辑可以概括为：上层软件尽量统一，底层硬件允许分化。

统一软件层可以减少模型适配、算子开发和部署工具的重复投入；硬件层则可以根据场景调整计算单元、Cluster数量、内存层次、数据精度和专用加速模块。安谋科技还提出在统一架构中兼容存算一体以及非冯·诺依曼计算方案，但目前披露的主要还是架构方向，尚没有公开具体产品的算力、功耗、制程和量产时间。

从技术路线看，X3-Pro反映出边端NPU设计评价标准正在发生变化。

过去厂商习惯用TOPS表示峰值算力，但对于Agent类负载，单一指标越来越难反映真实表现。持续感知、多轮交互、上下文记忆和工具调用会产生频繁的数据访问与任务切换。部分阶段是矩阵计算密集型，部分阶段则可能受内存带宽、CPU调度或者数据预处理限制。

因此，边端NPU需要同时考虑算力利用率、内存容量、算子覆盖、编程灵活性和任务并发。X3-Pro提出支持更多数据精度、混合精度计算、可配置内存层次和更灵活的Cluster组合，本质上是在提高架构对不同负载的适配能力。

不过，统一架构与场景化硬件之间本身也存在张力。硬件越专用，单位功耗下的效率通常越高，但软件迁移和模型兼容可能越困难；硬件越通用，模型适配更加灵活，却可能增加面积和功耗。X3-Pro最终能否解决这一矛盾，还需要等待具体芯片及软件工具链公布后验证。

当视频不再只给人看

发布会的第三条技术线来自“玲珑”VPU。

传统视频编码主要围绕人眼视觉质量进行优化。例如，在码率有限的情况下，编码器会尽量保留人眼更容易察觉的纹理和轮廓，并允许在不明显影响观看体验的区域损失部分信息。

但在机器人、自动驾驶、视频监控和工业视觉中，视频的主要使用者正在变成模型。人眼无法察觉的压缩损失，可能破坏目标边缘、运动轨迹或者细小特征，进而影响目标检测、动作识别和模型训练结果。

这使视频压缩的优化目标从“画面看起来是否清晰”，扩展到“压缩后是否仍然有利于机器完成任务”。

安谋科技今年初发布的“峨眉”VPU和计划于2027年初推出的“武当”VPU，均引入内容感知编码。其基本方式是在编码前对视频进行浅层图像处理和语义分析，再将分析结果提供给编码器，用于调整码率分配和编码决策。

按照安谋科技现场披露的信息，“武当”计划支持8K 30fps编码，芯片面积相较前代方案缩减约40%，同时增加YUV 4:2:2编码和原始数据压缩能力。在部分不规则运动场景中，公司称其编码质量相较上一代还有约5%至10%的提升。由于产品尚未正式发布，这些指标仍属于设计目标或内部测试结果。

更值得关注的是其正在研发的任务感知编码方案。

这一方案将视频前处理网络、虚拟编码器和下游AI任务放在一起联合训练，使编码器不再只优化传统画质指标，而是同时考虑目标追踪、动作识别等任务的准确率。部署时，训练得到的前置网络可以与VPU结合，根据具体任务决定哪些信息需要保留、哪些信息可以进一步压缩。

安谋科技称，目前在目标追踪和动作识别测试中，该方案获得了超过10%的编码质量提升。这里的“质量”并不完全等同于人眼观看质量，而是包含码率和下游任务精度之间的平衡。

这一方向的技术价值在于，它把视频编解码器从数据传输工具变成AI计算链路的一部分。但其落地也存在新的问题：针对某个模型联合优化的编码策略，能否适用于其他模型；模型升级后是否需要重新训练；不同摄像头、VPU和AI框架之间如何保持兼容；压缩后的视频是否还能满足存档、回放和人工查看要求。

因此，机器视觉编码不会简单取代传统视频编码，更可能作为特定AI场景中的新增模式存在。

AIOS要解决的，是异构硬件之上的系统问题

拥有CPU、NPU和VPU，并不意味着一台设备已经能够运行完整的AI智能体。

持续感知型AI设备通常需要同时处理摄像头、麦克风、传感器、语言模型、语音识别、语音合成、记忆系统和运动控制。不同任务可能分别运行在CPU、GPU、NPU和其他加速单元上，还可能在本地与云端之间迁移。

传统操作系统能够管理进程、存储、设备和网络，但对于模型路由、上下文记忆、AI任务编排、工具调用权限和多模态数据流，并没有统一的原生抽象。

在这一背景下，安谋科技牵头发起开源AIOS联盟，希望联合芯片厂商、设备厂商、模型企业和研究机构，共同探索面向新型AI设备的软件基础设施。现场提出的AIOS架构主要包括模型引擎、Agent任务编排、记忆引擎以及DataFlow数据流引擎。

其中，模型引擎负责模型推理、端云路由以及语音、视觉等多个模型之间的协同；Agent任务编排负责把一个较复杂的目标拆分为工具调用和可执行任务；记忆引擎管理长短期上下文；数据流引擎则负责在视频、音频、文本以及不同计算单元之间传递数据。

安谋科技特别提到Zero Copy等数据处理方式。对于持续采集视频和音频的设备来说，减少数据在CPU内存、加速器内存和应用程序之间的重复复制，可能比单纯提高某个算子的峰值性能更重要。一次额外的数据搬运不仅会增加延迟，也会消耗内存带宽和电量。

在AIOS联盟的规划中，相关软件、模型、技术文档和原型产品将逐步开放。安谋科技还计划开放端侧模型Benchmark套件，用于测试模型在本地设备上执行Agent任务和长时间任务的能力。极术社区已经推出JishuShell，并计划继续开放知识库等组件。

不过，AIOS目前仍然是一个定义尚未完全统一的概念。它究竟是Linux之上的中间件、模型运行时、Agent框架，还是覆盖硬件、模型与交互的完整操作系统，不同厂商的理解并不相同。

联盟后续真正需要解决的，也不只是开放代码。硬件抽象接口如何统一、模型如何跨设备迁移、记忆数据采用什么格式、Agent权限如何控制、实时任务与生成式任务如何共存，以及不同成员如何参与技术决策，都会影响其能否形成可持续的生态。

边端AI开始进入系统工程阶段

从CPU、NPU、VPU到AIOS，安谋科技此次发布会释放出的共同信号是，边端AI已经不再是单颗加速芯片的问题。

CPU负责控制、实时任务和通用计算；NPU处理主要的模型负载；VPU决定视频数据如何被压缩和提供给模型；操作系统则需要负责模型调度、任务编排、记忆、安全以及端云协同。任何一层出现瓶颈，都可能使其他部分的理论性能无法发挥。

这也解释了为什么边端AI不能简单复制云端路线。云端可以通过规模化集群分摊基础设施成本，而终端设备必须在固定功耗、固定内存和固定成本内完成相对确定的任务。对边端系统而言，能否稳定运行、是否支持主流模型、数据搬运是否高效，往往比实验室中的峰值算力更接近真实产品需求。

目前，安谋科技展示的部分内容仍处于原型或研发阶段。“星辰300”是验证平台，“周易”X3-Pro尚未公布完整产品规格，“武当”VPU计划于明年初发布，AIOS联盟也处于早期建设阶段。

因此，这场发布会更像是对技术路线的集中说明，而不是一组已经完成商业验证的产品结论。接下来值得观察的，是这些架构能否转化为量产芯片、稳定的软件工具链和实际设备，以及CPU、NPU、VPU与AIOS之间能否真正形成统一的开发与部署体系。

边端AI的竞争，也将从“模型能不能在设备上跑起来”，进一步转向“整套系统能否在有限资源下长期、稳定并且可控地运行”。

WAIC 2026现场，阡视科技发布超节点系统，专为Token工厂而生

李冬梅 — Sun, 19 Jul 2026 02:59:42 GMT

7月17日，以“智能伙伴共创未来”为主题的2026世界人工智能大会暨人工智能全球治理高级别会议（以下简称“WAIC 2026”）在上海正式拉开帷幕。

新一代AI基础设施服务商阡视科技，携最新专为Token工厂而生的超节点真机重磅亮相，沉浸式呈现下一代国产超节点技术的底层智算逻辑与系统级性能拓展路径。

当前，人工智能技术正从推理时计算演进至递归自我改进阶段，长程连续迭代与闭环规划任务成为下一阶段的核心范式。在此范式下，KV Cache的频繁读写使存力成为新的系统瓶颈。传统超节点架构主要侧重于GPU的互联平面，重点解决芯片间横向通信的瓶颈，对于Token工厂场景来说，无法满足超长上下文的运算效率问题。

阡视科技自主研发的专为Token工厂而生的wylon超节点系统，具备横向算力互联能力的同时也实现了全域无阻塞的卡间全互联通信。它定义了一个新的纵向存力贯通平面，系统打通了异构存力资源的层级架构，构建起百TB级GPU 近存、系统内存以及PB级大带宽闪存空间；同时结合HitenOS大模型操作系统的高效软硬件深度协同设计，在国产GPU平台上实现了“同一速度下更高吞吐，同一吞吐下更快响应”的帕累托改进，可达10倍以上性能的提升。

通过对Token工厂场景的深入分析以及软硬件联合设计研发，wylon超节点系统实现了KV分层管理、算力亲和调度、硬件拓扑感知等底层能力，确保模型负载直达硬件底层，避免中间层性能损耗，为大模型运行提供一体化的高效算力空间，满足Agent时代对大算力、大带宽、大存储的需求，并持续降低Token成本。

阡视科技此次亮相 WAIC 的 wylon Q72/288，单机柜集成 72 颗国产 GPU，4 机柜横向互联域扩展至 288 卡规模，GPU 高带宽显存可达 18 TB，互联总带宽可达 72 TB/s，支持 FP8/4 浮点运算精度，专为 KV Cache 设计的统一DRAM 缓存可达上百TB，为大模型推理提供一体化的高效算存空间，实现高效稳定的 Token 生产。基于 wylon 超节点架构的 wylon 新云 Token 工厂，现已在华东集群节点上线并邀请测试中。

wylon超节点系统深度联合寒武纪、壁仞、沐曦、曦望、海光、摩尔线程等国内GPU芯片企业，构建起从芯片到系统、从算力到生态全栈贯通的国产AI基础设施，不断拓展国产超节点系统性能的帕累托前沿。

三款AI推理芯片+超节点异构集群，云天励飞公布未来算力蓝图

李冬梅 — Sun, 19 Jul 2026 02:52:02 GMT

7月18日，云天励飞在2026 WAIC公布未来两年多AI推理芯片路线图。公司计划推出DeepVerse100P、DeepVerse100D、DeepVerse100L三款芯片，分别针对AI推理中Prefill、Decode和Decode FFN环节的负载特征进行专用优化。

三款芯片将面向万卡异构集群进行协同设计与部署，通过对不同推理阶段进行解耦，为不同负载配置更加适配的芯片和算力资源，进一步提升系统整体效率，持续降低Token生成成本。

推理负载持续分化，算力优化走向精细化

从负载特征来看，当前大模型推理应用正在形成不同类型：以对话、知识问答为代表的通用AI助手，以复杂推理、编程为代表的深度推理应用，以及以Agentic Coding、多Agent协同为代表的实时智能体系统。

随着AI应用不断深入，单次任务的上下文长度、推理链路复杂度以及实时交互要求持续提高，对推理系统的吞吐、延迟和成本提出了更高要求。对于大规模推理部署而言，峰值算力已难以单独反映系统效率，计算、访存、互联和系统调度等因素，共同影响Token生成效率和成本。

大模型推理不同阶段的计算特征也存在明显差异。Prefill需要集中处理输入上下文，对计算能力要求较高；Decode采用逐Token生成方式，对内存带宽和数据访问效率更加敏感。随着MoE等模型架构发展，Decode阶段内部的Attention与FFN在计算、访存等方面也呈现出不同的资源需求。

针对推理负载的变化，云天励飞计划在未来推出DeepVerse100P、DeepVerse100D和DeepVerse100L三款云端大算力推理芯片。

DeepVerse100P面向百万级上下文Prefill场景打造。在传统混部架构中，长上下文Prefil与Decode共享算力与带宽资源，会造成资源抢占，对Decode生成吞吐造成影响。

DeepVerse100D面向Decode环节打造专用推理引擎，拥有数倍于主流芯片的内存带宽，支持1024卡Scale-up及光互联系统架构。通过按需建立光路直连，并根据任务动态重构光路，减少传统多跳电交换和静态组网中的排队、拥塞及中间转发开销，降低多节点通信阻塞和尾延迟，提高逐Token输出的稳定性。

DeepVerse100L面向Decode阶段计算密集型的FFN环节，采用3D Memory架构，相比主流HBM，大幅提升内存带宽，并通过低延迟芯片互联和激活数据快速传输，提高计算与通信的并行效率。

三款芯片协同面向万卡异构集群

随着AI推理进入规模化部署阶段，芯片优化也正由单颗性能提升，进一步走向多芯协同和集群级效率优化。

在万卡规模的推理集群中，系统效率并非单卡性能的简单叠加。不同推理负载对计算、内存和通信资源的需求存在明显差异，当Prefill与Decode、Attention与FFN共享同一套通用算力资源时，容易产生资源竞争。与此同时，随着集群规模扩大，通信阻塞、资源等待和尾延迟等问题也会进一步影响整体推理效率。

因此，提升Token生成效率，除了优化单颗芯片性能，还需要围绕芯片在集群中的协同，对推理过程中的计算、访存、互联和资源配置进行系统级设计。

基于DeepVerse100P、DeepVerse100D和DeepVerse100L，云天励飞计划推动三款芯片在万卡异构集群中的分离式部署与协同运行。按照Prefill、Decode和Decode FFN的不同负载特征，分别配置相应芯片和资源池，并通过高速互联形成协同运行的异构算力系统。

这一芯片协同方案围绕Token生成全过程进行系统优化。通过对不同推理阶段进行分离，降低不同负载之间的资源干扰，并根据实际需求配置计算、访存和通信资源，从而提升集群资源利用率和整体推理效率。

从面向特定推理负载进行芯片优化，到不同芯片之间的协同，再到万卡级集群应用，云天励飞正在将AI推理芯片的优化范围由单颗性能延伸至集群级效率。

面向“百亿Token一分钱”的长期目标，云天励飞希望以三款芯片为核心，形成一套服务于大规模Token生成的“推理工厂”，通过芯片、互联、软件和系统的协同优化，提高算力产出效率，持续降低单位Token成本。

IFWA软件栈：降低国产算力应用门槛

硬件异构程度和集群规模不断提升，也对软件栈提出了更高要求。模型能否快速完成适配、算子性能能否得到充分释放、不同硬件资源能否高效协同，直接影响DeepVerse芯片在大规模集群中的实际运行效率。

围绕DeepVerse芯片及其集群应用，云天励飞持续建设IFWA软件栈，覆盖AI模型开发、编程及系统等不同层级，为模型适配、算子优化、编译部署和软硬件协同提供软件支撑。

在兼容性方面，IFWA围绕Transformer主流架构，持续完善PyTorch ATen算子的适配和性能优化，并加强对vLLM、SGLang等主流推理框架的支持。通过兼容主流软件接口、复用成熟开源组件，降低模型向DeepVerse平台迁移和部署的成本。

在模型适配和开发效率方面，IFWA构建了覆盖模型量化、压缩、编译和部署的一站式自动化工具链，并引入AI Agent参与推理芯片适配和性能优化。

此前，云天励飞已开源Houmao多Agent异构编程框架，由不同Agent协同完成模型开发、算子开发、性能优化和测试验证等任务，将部分依赖人工经验的芯片软件开发流程转化为自动执行、自动验证和持续优化，缩短新模型和新算子的适配周期。

与此同时，云天励飞还将成熟的Triton算子能力融入FlagOS，通过代码贡献、联合验证和社区复用，推动相关能力在国产AI软件生态中进一步共享，减少不同硬件平台在算子适配上的重复投入。

在云天励飞的规划中，IFWA并非一套封闭的软件体系，而是通过对主流模型、框架和开发工具的兼容，降低开发者的迁移和使用成本，缩短模型在DeepVerse平台上的部署周期，让国产算力更加便捷地进入实际应用。

“1001计划”，推动Token成本协同优化

降低Token生成成本是一项系统工程。

从芯片架构、IP与EDA，到封装测试、系统互联、软件栈和算力平台，再到模型及应用，产业链不同环节的效率都会影响最终的Token生成成本。实现极致性价比的Token，需要产业链上下游共同参与。

今年5月，云天励飞联合30余家等单位，共同签署“1001计划”倡议。“1001计划”将围绕Token生成效率和成本，推动产业链上下游加强协同。通过更加紧密的产业合作，使模型和应用需求更早反馈至芯片及系统设计环节，推动成熟软件能力加快复用，同时加速芯片在集群和实际场景中的验证和应用。

随着AI走向规模化应用，算力竞争正在进一步转向对系统效率和单位Token成本的持续优化。芯片、软件、系统和应用之间的协同程度，也将越来越直接地影响AI算力的实际价值。

以“百亿Token一分钱”为长期目标，云天励飞将持续推进芯片、系统、软件和产业生态协同创新，与更多生态伙伴共同提高Token性价比，推动国产AI算力从“能用”迈向“好用、易用、用得起”，为人工智能规模化应用提供更加高效、普惠的算力基础。

从大模型到 AI 执行系统：构建企业级可控 Agent 体系｜AICon深圳

AICon 全球人工智能开发与应用大会 — Sun, 19 Jul 2026 02:00:00 GMT

Agent 时代，哪些方向正在成为行业关键变量？50 + 实战案例揭晓答案！

NoDesk AICTO王仿已确认出席 “Harness Engineering：模型之外的智能体工程"” 专题，并发表题为《从大模型到 AI 执行系统：构建企业级可控 Agent 体系"》的主题分享。随着大模型能力的快速提升，越来越多企业开始尝试将 AI 引入业务流程。然而在实际落地过程中，大部分企业面临着同样的问题：模型能力很强，但业务价值难以稳定释放。数据显示，超过 80% 的企业 AI 项目停留在 PoC 或局部试点阶段，难以进入生产环境。其核心原因并非模型能力不足，而是缺少一套能够连接业务目标、企业知识、业务系统和执行流程的 Agent 执行体系。

本次分享将结合实践经验，探讨如何将“不可控的大模型”转化为“可控的Agent执行系统”。对此，王仿及其团队提出了一套基于 Business Translation（业务翻译）、Knowledge Engine（知识引擎）、Skill Framework（技能体系）和 Agent Runtime（执行引擎）的企业级 Agent Infra 架构，将业务目标逐层拆解为可执行任务，通过 MCP 协议连接企业 ERP、CRM、MES、OA 等系统，并引入 Human-in-the-Loop、人机协同审批、可观测 Trace、长期记忆和 SOP 约束机制，实现 Agent 的可控执行与持续优化。

分享中还将介绍在行业项目实践中，该架构帮助企业将原本需要数小时的数据分析与决策流程缩短至分钟级，运营分析效率提升 70% 以上，Agent 任务成功率提升超过 30%，显著提升了企业 AI 项目的生产化落地能力。

王仿，NoDesk AICTO，专注于企业级 AI 落地，具备“基模训练—工程实战—商业闭环”全链路能力。曾就职于智谱，从 0 到 1 搭建华东区大模型与解决方案团队，服务电商、医疗、制造等多个行业；此前在搜狗、阿里负责高并发 AI 系统建设。现创业 DeskClaw，专注于企业级 Agent Infra 与执行系统建设，帮助企业将 AI Agent 从 Demo 推向生产环境并持续创造业务价值。他在本次会议的详细演讲内容如下：

演讲提纲：问题背景：为什么企业Agent难以规模化落地行业现状：大模型能力快速提升；Agent成为企业AI落地热点；大量项目停留在PoC阶段。核心矛盾：模型能力增强 ≠ 业务价值提升；Demo效果 ≠ 生产系统能力。四大关键问题：① 知识孤岛：企业知识无法统一利用；② 系统孤岛：ERP / CRM / MES / OA无法打通；③ Agent不可控：幻觉 / 越权 / 执行错误；④ ROI不可衡量：无法证明业务价值。2. 核心观点：从模型能力到执行系统核心判断：企业需要的不是模型，而是AI Execution System（执行系统）能力演进路径：Chat → Copilot → Workflow → Agent → Execution System关键变化：从“生成内容”走向“执行任务”从“模型中心”走向“系统中心”3. 企业级Agent Infra架构设计总体架构：Business Translation；Knowledge Engine；Skill Framework；Agent Runtime；Enterprise Systems（ERP/CRM/MES/OA）Business Translation（业务翻译层）：将业务目标转化为Agent可执行任务Job → Task → Action拆解机制解决“业务语言不可执行”的问题Knowledge Engine（知识引擎）企业知识来源：文档 / 数据库 / 系统 / 外部数据核心能力：Chunk / Embedding / Hybrid Search / Rerank关键问题：知识治理而非单纯RAGSkill Framework（技能体系）：Tool → Skill → Workflow抽象；解决工具碎片化问题；支撑复用、权限与治理Agent Runtime（执行引擎）：Planning / Reasoning / Memory / Execution；多Agent协同机制；长任务执行与状态管理；失败恢复与重试机制4. Agent可控性设计：从“能用”到“可控”Human-in-the-Loop：关键节点人工介入；风险控制与确认机制SOP约束机制：将企业流程固化为执行规则；限制Agent自由发挥空间Trace可观测体系：思考过程可视化；Tool调用链路追踪；执行过程审计Agent治理体系：权限控制；审计机制；回滚与风控5. 企业级Agent实践案例进出口报关Agent业务效果：从3小时 → 10分钟，效率提升70%+Agent实现路径：业务翻译(业务专家负责)->skill开发&Agent调度（技术专家负责）->Agent执行（运营专家负责）广告投放Agent业务效果：从半天 → 30分钟人和Agent协作路径：Agent执行、人来拍板，行业/客户的需求变化如何快速调整运维6. 总结与展望核心结论：大模型决定能力上限；执行系统决定业务价值行业趋势：从模型竞争 → 系统竞争；从工具使用 → 执行体系构建最终观点：企业真正需要的不是一个会聊天的大模型，而是一套能够持续创造业务价值的AI执行系统这样的技术在实践过程中有哪些痛点？Agent任务成功率难以保证企业任务往往涉及多步骤推理、多系统协同和长链路执行。随着任务长度增加，模型容易出现目标漂移、上下文遗忘和执行失败等问题，导致任务完成率快速下降。企业知识利用率低很多企业已经建设了知识库，但实际效果并不理想。问题往往不在于 RAG 本身，而在于知识治理体系缺失，包括知识清洗、切片、标签体系和知识质量评估机制不足。Agent执行不可控企业无法接受“差不多正确”的结果。如何通过 SOP 约束、人机审批、权限体系、执行审计以及全链路 Trace，让 Agent 从“会思考”走向“可执行、可治理”，是落地过程中的关键挑战。企业系统集成复杂Agent 要真正创造价值，必须连接 ERP、CRM、MES、OA 等核心系统。权限管理、接口稳定性、异常恢复、长链路事务处理等问题远比模型推理本身更加复杂。听众收益对于架构师和技术负责人：理解企业级Agent落地的整体架构设计掌握Agent Runtime与Agent Governance 的关键设计思路2. 对于Agent工程师：学习Business Translation、Knowledge Engine、Skill Framework等核心架构设计掌握多Agent协同与长任务执行的实现方法理解Agent 可观测性与可控性建设路径3. 对于企业数字化负责人和CTO：了解企业Agent项目为什么难以规模化落地学习如何构建企业级 AI 执行系统掌握衡量 Agent ROI 和业务价值的方法论

大会限时早鸟票享 9 折专属优惠，现在报名立减 580，更多详情可扫码或联系票务经理 13269078023 进行咨询。

腾讯云发布ADP 4.0海外版：集成Google Workspace、Jira，定位AgentOps全生命周期管理

青和 — Sun, 19 Jul 2026 00:01:41 GMT

“企业级智能体不是比谁搭得更快，而是比谁能更稳定、安全、可持续地跑在业务现场，形成持续创造价值的运营体系。”7月18日，在2026世界人工智能大会上，腾讯云副总裁吴运声详细解读“以知识驱动，打造企业原生智能体”的落地路径，并正式发布腾讯云智能体开发平台ADP4.0海外版。

吴运声表示，企业级智能体不是比谁搭得更快，而是比谁能更稳定、安全地跑在业务现场，形成一个持续创造价值的运营体系。其中，能力和知识缺一不可。腾讯云为此搭建起两大底座，一是能力底座“腾讯云智能体开发平台ADP”，二是知识底座“腾讯乐享Agentic知识库”。

最新升级的ADP 4.0定位为AgentOps平台，为企业提供云端智能体的构建、分发和治理一站式服务。企业用自然语言描述需求，智能体就能在云端沙箱自主规划、编写、运行代码，并调用已治理的Skills、连接器、知识库和工作流，完成任务构建。同时，ADP 4.0实现Agent与Workflow双向互调，兼顾开放意图与严谨流程，在保证流程严谨的同时，降低Token消耗，且Workflow全链路可追踪，满足合规审计。

此外，ADP还通过OpenAPI，开放空间、应用、Skill、插件、知识库、文档与会话等模块能力，方便客户和伙伴将企业级智能体能力，嵌入原有业务流程。

依托国内市场的长期落地打磨，ADP产品成熟度持续提升，本次大会正式推出ADP 4.0海外版，同步升级了智能工作台、Claw模式、Skill广场三大核心模块，并围绕触达、交互、生态、连接四大能力全面升级。

在全域触达方面，Claw应用支持LINE、Telegram等主流海外渠道，实现一站发布即可跨区域触达全球用户；在交互体验方面，智能工作台支持自定义时区与多区域调度，模型输出可跟随用户输入语言自动响应；在开放生态方面，模型广场接入多家国际主流大模型，平台Skill完成国际化适配，文档与多模态解析能力同步升级，更符合海外用户使用习惯；在深度连接方面，平台深度接入Google Workspace、Confluence、Jira等主流SaaS应用，深度嵌入海外企业办公与协同场景。

据悉，腾讯云ADP此前已在不少海外企业落地，并取得不错成果。某大型医疗集团，利用ADP构建了覆盖智能导诊、门诊预约、医院咨询、急诊风险识别等全流程的AI医疗助手，预计可独立处理80%以上的常规咨询和预约，整体预约效率提升50%以上，患者平均等待时间缩短30%。某海外一家头部运营商，原有两套客服系统，基于 ADP 重构统一平台后，整体运维成本预计降低 30%–40%，新业务上线周期从数周缩短至数天，应用开发效率预计提升70% 以上。

“ADP解决的是智能体怎么建、怎么跑、怎么管，那么知识库则解决的是智能体懂什么、信什么、用什么的问题。”吴运声表示，腾讯云最近升级了腾讯乐享知识库，成为一个集连接、治理、执行、进化于一体的AI原生知识库，可覆盖入职、客服、销售等多元业务场景，用户通过自然语言即可触发多步推理，完成复杂业务需求。为保障知识的准确性与权威性，乐享还搭建了动态治理体系，可统一接入多渠道企业知识，自动完成去重、冲突检测等治理工作，确保智能体调用的始终是最新、最权威的内容。

智能体成败的关键在于场景。会上，腾讯云邀请生态伙伴共建“十大行业百大场景生态计划”，从客服、经营分析、交易自动化等高频场景切入，依托腾讯云智能体底座和伙伴的行业Know-how，把智能体带进千行百业，推动生产力高效落地。

腾讯发布三大具身基座模型，打通“感知—行动”闭环，工业实测成功率超95%

四月 — Sat, 18 Jul 2026 23:55:01 GMT

7月18日，腾讯Robotics X实验室、福田实验室联合腾讯混元发布具身智能系列新模型和智能体新成果，首次系统性地打通“感知—身体—行动”的闭环，推动具身智能从“离身智能”迈向“具身原生智能”、从实验室迈向真实生产力应用。

本次发布的具身基座模型包括Hy-Embodied-VLM-1.0、Hy-Embodied-RxBrain-1.0 和 Hy-Embodied-VLA-0.5，这三个模型都基于混元大模型打造，其中VLM 模型像“右脑”，负责理解图像、空间和场景；RxBrain模型像具身“大脑”，统一认知、规划和对未来状态的想象；VLA模型连接“小脑”和身体，把高层目标转化成连续的、可纠错的动作。

同时发布具身智能体Apexio和智能体框架TairosAgent，它们通过智能体的调度能力，可以把前面的“左右脑”、“大脑”、“小脑”和身体整合成完整的系统，让机器人形成一个持续感知、持续决策、持续行动的整体。

在2026 WAIC 腾讯AI 应用创新论坛上，腾讯首席科学家、腾讯Robotics X实验室、福田实验室主任张正友指出，今天最聪明的人工智能本质上仍是“缸中之脑”——它善于逻辑推理、文本生成和知识问答，却缺乏与物理世界直接互动的闭环：未必真正理解物体的位置、空间关系与可操作性，也难以在持续变化的环境中边行动、边接收反馈、边及时调整。

“语言并不等于全部认知，它只是智能向外表达的一个通道。”张正友表示，真正的智能需要让语言、视觉、空间认知、身体控制和环境反馈连通起来，在“感知—身体—行动”的闭环里接受验证。此次发布的五项新成果，正体现了腾讯沿着“从离身走向具身、从分裂的模块走向整体的闭环”探索具身原生智能的基本思路。

三大具身基座模型：看懂世界、会推理且会想象、会行动

虽然大模型已经拥有了强大的语言和图像理解与生成能力，但是让人工智能更好的理解物理世界一直是一个难题。过去一段时间，腾讯Robotics X 实验室一直在探索具身智能基座模型，并将成果开源，与行业共同成长。

本次发布并开源的模型有三个，首先是新一代具身VLM（视觉语言）基座模型Hy-Embodied-VLM-1.0，它重点解决了三个层层递进的问题：“看物知用”（理解深度、方位、功能部件与可操作点）、“看景知变”（判断下一步动作及其带来的变化）、“看远知返”（长时程任务中记忆历史、跟踪进度、失败后可分析原因并重新规划）。在覆盖 37 个任务的评测中，三类能力均显著优于同等规模模型；更关键的是，它仅以 A3B 规模、约十分之一的计算量，就接近了上一代 A32B 旗舰模型的效果，更轻量、更适合机器人端直接部署。

其次是具身原生的世界认知模型Hy-Embodied-RxBrain-1.0，它把“会推理”与“会想象”统一起来：面对一个任务，一边用语言给出步骤与约束，一边生成每一步完成后应达到的目标图像，让下游动作模型不仅“听到做什么”，更能“看到做成什么样”。在这个方向上，腾讯还联合行业伙伴建立了RxBrain-Bench 评测基准，RxBrain 显著领先其他代表性系统，在短时未来状态预测上也达到专用具身世界模型的水平。

最后是视觉-语言-动作（VLA）模型Hy-Embodied-VLA-0.5，其核心竞争力不是训练一个更大的模型，而是构建“数据—模型—训练—部署”协同发力的完整学习栈，通过亚毫米级高精度UMI 采集系统积累超一万小时人类示教数据。在第三方 RoboDojo 评测（泛化、记忆、精细操作、长程执行、开放语义理解五类能力）中Hy-Embodied-VLA-0.5 拿下仿真综合排名第一，并在最考验连续执行能力的长程任务与记忆任务两个维度同样排名第一。

值得注意的是，上述模型已经开始进入真实工业场景，并在导购导览、养老服务等多个任务中完成落地验证。借助软硬一体的快速适配能力，同一套模型可支撑多形态机器人规模化应用。同时也联动了腾讯内部腾讯云HAI、多网聚合加速、TRRO，以及腾讯音乐（TME）海量曲库与IoT生态连接能力，以沉浸式听觉体验助力多元场景落地。

例如，HyVLA-0.5已经进入了一家日化品工厂，开展生产实测，面对高混合、小批量、SKU 频繁迭代的产线，其作业成功率高于 95%、节拍快于 6 秒/件，新增 SKU 留给数据采集与模型后训练的时间不到 3 天。

两大具身智能体：时刻在线、即时反应

在智能体领域的持续探索，目的在于解决机器人与现实世界交互过程中的不自然、不流畅、不可靠的问题，让其可以真正走入现实应用。

在广受关注的具身智能体方向上，腾讯发布了持续在线具身智能体Apexio，它由三层以不同频率同时在线的能力构成：最上层认知系统按需唤醒、可做深度思考；中间层感知行动系统以约 15Hz 持续接收多模态信息并快速调整；最下层执行系统以更高频率运行，像条件反射一样瞬间处理碰撞与失衡。系统同时由“目标驱动”，例如完成任务与“生存驱动”，主要包括维护安全、控制能耗、管理运行状态两条主线牵引，即便没有外部指令，也持续感知、持续自保、为下一次行动做好准备。

其次是具身原生智能体框架TairosAgent。与从通用框架改造而来的方案不同，TairosAgent 从设计第一天起就为机器人本体而生，其感知反应、认知决策、探索沉淀三层系统全部围绕具身任务做原生设计，并持续维护环境记忆、本体记忆与任务记忆三类记忆。通过统一的硬件适配层与标准化 Skill 接口，它可接入不同模型、技能与形态的机器人，在导航、讲解、被打断后恢复等典型场景中，响应时间从通用框架的几十秒缩短至2—3 秒。

Tairos 开放平台全新升级：模型开源，智能体开放

基于Hy-Embodied 系列模型与具身原生智能体，腾讯对2025 年发布的Tairos 具身智能开放平台（钛螺丝）进行全面升级，升级后的Tairos 将保持开源和开放，继续提供模型、智能体与开发工具等一系列能力与服务，降低从模型到本体再到应用全链条开发门槛。

过去一年，腾讯Robotics X 实验室已与宇树、智元、越疆、松延动力、乐聚、华沿等机器人企业以及博世、蓝思、景德镇、敦煌等场景合作伙伴，探索具身智能在不同机器人、不同产业场景中的落地。正如“Tairos”之名中的“钛”字所寓意的，腾讯希望做具身智能行业的一颗“钛螺丝”——也许不是最显眼的部分，却能可靠地连接模型、本体、工具与应用，支撑整个生态共同运转。

探索物理人机交互：让机器人安全地“接触人”

在“让具身智能听懂人”之外，腾讯也在探索“让机器人安全地接触人”。在照护、康复、生活服务等领域，机器人必须与人发生物理接触，既要绝对安全，又要动作自然、力道精准。

在此前研发的“小五”机器人基础上，腾讯研发了新一代示范性机器人“小六”：它能与人安全相处、动作拟人，并基于键绳传动，具备独有的“畅气通络按摩手法”，通过自研融合力觉、触觉、视觉的数据采集系统获得高质量手法数据，并经强化学习训练，实现手法轨迹与按摩力道的精准复现。

基于此，未来腾讯也将继续聚焦力觉、触觉、视觉与具身大模型的融合，让机器人真正走到现实生活中。

火速上架！空降即登顶Arena，Kimi K3当日登陆「模型广场」

木子 — Sat, 18 Jul 2026 09:14:05 GMT

昨天凌晨，Kimi K3正式和大伙儿见面。

2.8T参数，百万上下文信息......而且这玩意还开源，是全球第一个开源的3T级别大模型。（几个月前，国内第一个把模型推到1T级别的Kimi K2，也是月之暗面家的）

此前，有不少人在谈 Scaling Law 要失效了、大模型规模要见顶了。但K3再次证明：

至少在当下，规模依然是能力，参数依然能转化为智能。

除了参数强得可怕，K3在编程、长任务执行、自动化、网页检索和表格操作等 Agent 核心场景中，也表现出了非常稳定的第一梯队能力。

在下图中的14项测试里，K3获得 5 项单独第一、1 项并列第二，并且在 12 项测试中进入前二。只有 DeepSWE 和 GDPval-AA v2 两项排在第三，整体表现非常均衡。

所以，也难怪它一空降，即引起AI圈狂欢：目前已登顶Arena的前端代码能力竞技榜，大幅领先Fable 5。

上架模型广场，1000万+tokens免费送！

昨天下午，模力工场·「模型广场」"上架了满血原版Kimi K3。

和官方价格一致：

实话实说啊，这个价格，确实比Kimi-K2.7-Code-Highspeed翻了快一倍；不过还是比Anthropic家的Fable 5便宜很多，差不多是Fable 5 价格的30%。

But !!!

现在来模型广场，完成新用户实名注册，即可获赠至少价值约1000万tokens的礼包"。

此外，我们还同步开展了邀请有礼活动"。

每成功邀请 1 位新用户，并通过专属链接注册并完成实名认证，你和好友都能获得 ¥10 模型使用金，直接到账，并可以用于我们上架的所有模型。

邀请人数不设上限：邀请人数越多，奖励叠得越高。

目前已经有用户了一口气邀请了几十位好友注册，他今年在这里恐怕是token不愁用了。

而且，这份邀请奖励与“新用户实名认证送约 1000 万 Tokens”的福利相互独立，可以叠加领取。

K3，一个全能的助手

Kimi K3 最强的地方，不是某一项能力特别夸张，而是它几乎什么都能干，而且大多数事情都干得不错。

值得一提的是，它可以把复杂任务持续做下去。

在SWE Marathon基准测试（更看重模型能否处理持续时间较长、步骤较多的软件工程任务）中，Kimi K3 得分42.0，位列第一。

这对于真实开发非常重要。因为实际工作往往不是写一个函数，而是读项目、定位问题、修改多个文件、运行测试，再根据错误继续迭代

过去，国产模型更多是追赶海外旗舰；但现在，Kimi K3 不只是比第二名高了2 分，更重要的是，它明显拉开了与 Fable 5、GPT-5.5等的差距。

对于Coding，K3既能按照明确需求精准修改，也能自己读项目、查问题、拆任务、调试、提 PR；遇到复杂工程，还能同时拉起多个 Agent 并行推进，不只是“给你一段代码”，而是真的有机会把整件事做完。

在Agent场景里，K3更是尤其能打。

查资料、跑浏览器、整理信息、处理表格、串自动化流程，都是它的强项。

你可以把一堆网页、一份长文档、几张表格，甚至一串互不相关的工作任务一起交给它，它会自己找信息、做判断、列待办，再一步步推进。配合 100 万上下文，它也更适合读大型代码库、长文档和复杂项目，不容易干到一半就“忘了前面说过什么”。

Kimi K3 还有一个很讨喜的能力：前端和多模态表现很强。

给它一张参考图、一段视频，或者一个交互动效，它不只是能照着写出来，往往还能做得像模像样，审美、空间理解和完成度都在线。这意味着它很适合拿来做网页、交互动效、数据看板、视觉原型和前端 Demo。

参考链接：

https://x.com/Kimi_Moonshot/status/2077830229968683203https://www.reddit.com/r/singularity/comments/1uybldp/kimi_k3_tops_frontend_code_arena/#lightbox

中国 AI 产业核心要素出海发展白皮书

InfoQ 中文站 — Sat, 18 Jul 2026 04:02:12 GMT

当前全球 AI 产业全面迈入工业化规模化落地新阶段，算力、Token、出海三大核心要素深度绑定、共生赋能，共同重塑全球智能产业竞争格局。全球 AI 支出规模突破 2.59 万亿美元，行业竞争从单纯大模型参数竞赛转向推理经济主导，海量 Token 调用催生指数级算力需求，算力硬件成为决定产业上限的刚性物理壁垒。

国内 AI 市场竞争趋于饱和，出海从单一产品输出升级为算力、模型、应用一体化生态输出，成为中国 AI 企业突破增长瓶颈、收割全球高 ARPU 市场红利的核心路径。但产业出海仍面临全球算力供给失衡、硬件成本高企、各国数据合规政策差异化、跨文化适配、海外巨头生态垄断等多重系统性挑战，单打独斗模式难以为继。

本白皮书由 InfoQ 极客传媒联合火山引擎、小米 MiMo、商汤、GMI Cloud、EZmodel 等全产业链企业共同编撰，汇集基础模型厂商、MaaS 平台、AI 应用企业、产业媒体多方视角，以算力底座、Token 商业计量、全球化出海三大主线为核心，梳理全球算力格局、Token 技术落地、AI 出海完整现状，拆解产业链各主体协同分工模式，剖析算力与 Token 双向制约的底层技术经济学逻辑，汇总海内外真实落地实践案例，研判未来 1-3 年产业全球化演进趋势。报告兼顾客观产业数据、一线工程实践与前瞻性趋势预判，旨在打通行业信息壁垒，为国内 AI 企业合规、高效、高质量全球化布局提供体系化战略指引与落地参考。

为什么 AI Agent 拿到数据却不会推理？可观测对象图语义层的设计与开源实践｜AICon深圳

AICon 全球人工智能开发与应用大会 — Sat, 18 Jul 2026 02:00:00 GMT

Agent 时代，哪些方向正在成为行业关键变量？50 + 实战案例揭晓答案！

阿里云技术专家张鑫已确认出席 “Harness Engineering：模型之外的智能体工程"” 专题，并发表题为《为什么 AI Agent 拿到数据却不会推理？可观测对象图语义层的设计与开源实践"》的主题分享。把 AI Agent 接入企业系统时，主流做法是堆 RAG 或把数据塞进上下文。但可观测数据天然是分散的指标、日志、拓扑、变更——Agent 拿到的是碎片，回答不了“谁影响了谁”“为什么慢”“这次故障谁的锅”。本质问题不是数据不够，而是数据没有“意义”。对此，本次分享提出一条不同路线：先建一层可观测对象图语义层，把实体、关系、拓扑、指标、日志统一成 Agent 能查询、能多跳推理的上下文，并讲清它与 OpenTelemetry / Prometheus / CMDB 是补充而非替代。技术上覆盖三块：统一的 SPL 查询面（一套契约同时服务人、CLI、Web、REST 与 AI Agent）；通过 MCP 把对象图安全暴露给 Agent；以及专为 Agent 设计的 plan/data 查询契约与紧凑响应信封。在本次演讲中，张鑫将对此展开详细介绍。

张鑫，阿里巴巴云原生应用平台可观测技术专家，Apache SkyWalking PMC 成员，专注可观测 10 年。现负责开源项目 UnifiedModel，主导面向 AI Agent 的可观测对象图语义层设计与开源。他在本次会议的详细演讲内容如下：

演讲提纲：为什么“更多数据 / 更大模型”解决不了 Agent 的可观测问题（含踩坑）三种常见失败模式：直接把日志/指标塞进上下文、纯向量 RAG、给 Agent 开一堆领域专用 API踩坑实录：碎片化导致 Agent 看不到关系、token 爆炸、关系靠 LLM 脑补产生幻觉根因结论：缺的不是数据量，是“对象图 + 关系语义”这一层2. 对象图语义层怎么建核心对象：EntitySet（对象类型）、关系/拓扑、数据集（指标/日志/事件）、存储与字段映射一套 SPL 查询面（.umodel / .entity / .topo / entity-call）同时服务人和 AI——为什么坚持“单一读取面”而不是领域专用 API与 OTel / Prometheus / CMDB 的映射姿势：补充而非替代3. 把对象图接给 AI AgentMCP 工具/资源面设计：默认只读、写操作默认关闭的安全边界plan vs data 范式：开源侧只产出“查询计划”，把执行留给下游 executor，为什么这么设计踩坑：给人用的响应信封对 Agent 不友好（双层 JSON 嵌套、噪声字段占 ~85% token），如何重做出 ?format=agent 紧凑信封——上下文体积压缩约数倍4. 真实场景：Agent 走一遍故障定位（开源 demo）定位 degraded 服务 → 拉自身指标/日志 → 加载 Runbook → 查上游变更 → 排除“红鲱鱼”无关发布 → 跨域发现促销流量放大 → 关联出根因并给建议关键设计：Runbook 引导的结构化诊断 vs Agent 自由发挥；为什么故意埋一个“看似元凶”的干扰项5. 落地 tradeoff 与开源共建建模成本、语义层维护、与现有可观测栈的边界开源路线：GraphStore Provider / Domain Profile / 一致性验证的共建入口这样的技术在实践过程中有哪些痛点？前期建模有成本，不是开箱即得：要把“藏在人脑里的系统知识”（谁调用谁、变更影响哪些服务）显式建模出来，初期投入不小。语义层会 rot：对象图必须跟系统演进同步维护，否则会和现实漂移，反而误导 Agent——这是长期维护负担。价值强依赖关系数据质量：关系缺失或错误会让多跳推理走偏；对象图放大了“关系正确性”的重要性。不是银弹：它解决“上下文结构与可推理性”，不解决底层采集质量；与现有可观测栈是补充关系，不能替代。plan/data 分离的代价：灵活性换来的是——纯开源侧拿到的是查询计划而非数据，真正取数需要下游 executor 承接。要维护“两套表达”：给人看的响应和给 Agent 看的紧凑信封需要分别设计，多一份契约维护成本。听众收益一套可复用方法论：如何把分散的指标/日志/拓扑/变更组织成 AI 能推理的对象图语义层，而不是无脑堆 RAG 或换更大的模型——附判断“该不该建、怎么建”的决策依据。面向 Agent 的 API / 契约设计经验：plan vs data 范式、把上下文 token 成本压缩约数倍的响应信封设计，可直接迁移到自己的 Agent 平台。一个开源可复现的 AI 故障定位范式 + 诚实的 tradeoff 清单，帮助技术决策者少踩坑、看清边界。

大会限时早鸟票享 9 折专属优惠，现在报名立减 580，更多详情可扫码或联系票务经理 13269078023 进行咨询。

AI 智能体算力消耗过快，传统账单风控跟不上速度

作者： Steef-Jan Wiggers — Sat, 18 Jul 2026 01:00:00 GMT

一家仅有三名员工的公司，平日的 AWS 月度账单仅 10 至 15 美元，但在攻击者从一个 EC2 实例中窃取静态访问密钥后，疯狂调用亚马逊 Bedrock 平台上的 Claude 大模型，单日产生高达 14000 美元的扣费。

亚马逊云科技顾问 Tobias Schmidt 在 LinkedIn 上描述了这起事件"：该团队曾使用现有访问密钥试验 Bedrock 聊天机器人，两项默认配置放大了此次损失。这些密钥拥有 Bedrock 完全访问权限，而 AWS 在 2025 年移除了模型访问开关，默认启用了所有模型。此外，该应用原本设定调用 Haiku 模型，预估账单成本不足 100 美元。

此类事件并非首例，云成本相关论坛上已出现多起高度相似的案例。一个 AI 智能体程序或其凭证泄露在被察觉之前就产生数千美元的高额费用，因为云平台账单告警相比实际消费存在约一天的延迟。两起事件均由亲历从业者完整记录，暴露出自动化程序的消费增长速度与人工操作的慢速护栏之间的结构性错配。

最详细的案例是 5 月份的 DN42 事件，由网络工程师 Lan Tian 记录"，并在 Hacker News" 上引发广泛讨论。一名运维人员授予自主智能体完整的 AWS 访问权限，并设定了一个扫描 DN42 的截止时间——这是一个业余 BGP 网络，大多数节点运行在小的 VPS 实例上。该智能体认为这项工作需要五台 m8g.12xlarge 实例（每台 48 个 vCPU 和 22.5 Gbps 带宽）以及负载均衡器和 Lambda 函数，目标是实现 “20 吉比特每秒扫描速率，同时具备冗余备份与故障转移能力”。然后智能体反复应用 CloudFormation 模板，不断复制整个资源栈。运维人员在一天后才发现异常，当时他们的信用卡已被扣 6531.30 美元。事后经协商，AWS 将账单减免至 1894 美元。据圈内从业者估算，这项扫描工作实际上仅需一台月租 5 美元的虚拟服务器。

两起事件存在一个共性：用户都是通过信用卡扣款记录才察觉异常，而非来自 AWS 的告警。Cost Explorer 中的计费数据滞后长达 24 小时。AWS Budgets 基于这份滞后数据进行校验，因此预算拦截措施只会在费用已经产生后才触发。云架构师、前 AWS 员工 Magnus Eriksson 在 Schmidt 帖子的评论区"直白地写道：

遗憾的是，AWS 预算控制效率不高，因为计费延迟 24 小时。真正的客户至上应该让 AWS 将计费延迟至少变为”准实时“的。

Regula 的解决方案架构师 Igor Zhdanko 解释了为什么 GenAI 凭证已成为一个独特的攻击目标类别：

我不断看到更多类似这起 Bedrock 的安全事故。传统云资源被盗后，攻击者还得寻找能变现的基础设施。但生成式 AI 接口一旦泄露凭证，几乎瞬间就能产生数千美元的调用费用。IAM 角色、最小权限、模型限制、预算和终止开关应该从项目上线之初就应当作为标准配置。

这种区别重塑了安全威胁模型。如果被盗密钥仅能用于加密货币挖矿，攻击者需要配置实例、逃避检测，并在数天内将计算转化为货币。而具有 Bedrock 访问权限的密钥被盗，会直接以 API 速度转化为可转售的模型调用，攻击者无需运行任何基础设施，盗窃与变现之间不存在时间差。

Schmidt 的后续分析"认为，在自动化程序部署前就启用现有管控策略，而非等到事后补救，本可以避免这一系列问题：

通过服务控制策略（SCP）限制成员账号创建高成本实例。如果自动化智能体仅能创建小型实例，就能从源头控制损失规模。为云追踪日志（CloudTrail）配置大型实例启动操作告警，几分钟内即可捕获异常，不必等到信用卡扣款才发现问题。而当其他防护手段全部失效时，AWS 预算工具与成本异常检测功能可作为兜底安全防线。

他对当前现状的总结如下：

我们现在都在将云凭证交给智能体。应当先设护栏，再给自主性。

即使是这种多层防护方案也存在一个时间缺口，另一位从业者在评论中给出了量化说明：预算控制策略按照 AWS 固定的预算刷新周期执行校验，因此密钥盗窃爆发可以在 SCP 生效前运行数小时，以 Bedrock 上的 Claude 费率计算，这数小时产生的费用刚好就是那笔 14000 美元的账单。针对 Bedrock 而非账户总额的服务级异常检测可以缩短这个窗口。核心矛盾在于时序颠倒：CloudTrail 在几分钟内记录 RunInstances 或 InvokeModel 调用，而其成本在一天后才出现在计费数据中。对配置事件发出警报的团队在行动时就能发现失控的智能体；对支出发出警报的团队要等到账单生成后才能发现。对于会循环批量创建资源的智能体，两种方式的差距就是一整笔高额账单。

身份验证模式与警报同样重要。那笔 14000 美元的高额账单事件，根源是 EC2 实例中存放的静态访问密钥——IAM 角色在十多年前就能替代这种过时的密钥方案。DN42 事件的问题则在于，单组凭证拥有无限制的资源创建权限，且未设置任何费用使用范围约束。有限定权限范围的凭证、短期令牌以及拒绝向智能体操作账户提供昂贵实例的 SCP，就能把原本会造成上万损失的安全事故直接拦截在 API 调用阶段。

对于现金需要给智能体分配云凭证的团队，都应当基于上述两类典型故障模式搭建基础防护架构。使用专用成员账户运行每个智能体工作负载，这样 SCP 就可以拒绝创建大型实例和未使用的模型，而不会影响其他任何东西。在发出第一个凭证之前，为 RunInstances、InvokeModel 和 CreateStack 配置 CloudTrail 事件警报，因为这种警报能在操作发生瞬间触发，而所有基于预算的管控措施都要等到账单生成后才生效。仅使用 IAM 角色或短期临时令牌鉴权，并将 Bedrock 访问范围限定为应用调用的特定模型，而不是接受完全访问默认设置。这些都不需要使用新工具，在两起事件中，这些存在多年的控制措施都可以让扣费在 API 调用阶段就直接被拦截。

根据 Lan Tian 的聊天记录，DN42 运维人员自己总结的教训是”下次需要一个更好的智能体。“DN42 社区在 IRC 上的反应是禁止该智能体并设置新的规则：仅允许真人手动操作接入网络。但在这两种治标不治本的应对之外才是真正该落地的方案：云厂商需要消除资源消耗与费用可视性之间的时间差，平台运维团队对待智能代理凭证时，要像对待生产环境部署密钥一样，从爆炸影响范围的维度评估风险。

查看英文原文：https://www.infoq.com/news/2026/07/ai-agents-billing-guardrails/"

豆包视频通话背后，火山引擎重构 Agent 时代多模态传输底座

火山引擎视频云 — Sat, 18 Jul 2026 00:54:38 GMT

对通用 Agent 来说，多模态交互正在成为一项能大幅提升用户体验的关键基础技术。

过去，用户和 AI 的交互更多是输入文字、上传图片，然后等待回答。现在，家长希望可以直接把镜头对准孩子正在做的题目，让 AI 一步步讲解；在穿搭建议、视障人群视频导航等场景里，用户也希望 AI 不再是一问一答，而是在整个任务过程中持续倾听、对话。

这种变化提高的不只是功能丰富度，还有用户与 AI 建立连接的频率和深度。

火山引擎智能视频技术负责人裴志伟在分享中提到，视频通话等多模态场景“极大地拓宽了技术方案的普适性，带来了更多的想象力”，同时也帮助豆包获得了更多流量，“几乎是在没有做太多投放的情况下，业务规模翻了10倍，从千万级DAU变成了亿级DAU”。

这种多模态体验不是模型能力单独决定的。用户打开摄像头和麦克风后，真正影响体验的还有传输质量——连接是否足够快，弱网下是否稳定，音画是否同步，用户打断能否被及时响应，以及模型能否在正确时间拿到正确的信息。

也因此，国内的豆包和海外的 ChatGPT，都在构建让 AI 与人自然沟通的更成熟技术底座。

OpenAI 在7月8日推出了新的 GPT-Live，将连续对话与更深入的搜索、推理和智能体任务解耦，打造了一个相对独立的、低延迟、可打断、可持续的多模态信息交互层。更早举办的2026火山引擎 FORCE 原动力大会上，火山引擎也介绍了背后支撑豆包进行实时多模态交互的多模态传输系统（MMT）。

最终，火山引擎和 OpenAI 要解决的，都不是单纯的音视频性能问题，而是如何为 Agent 时代搭建一套支撑大规模、多场景、低延迟、可打断、可同步的多模态传输系统。

音视频传输技术不够用了

火山引擎和 OpenAI 在介绍自己的多模态交互技术时，都提到了传统音视频传输技术与 Agent 时代的多模态交互需求存在落差。

具体来看，豆包不是一开始就选择攻关复杂的视频通话问题，而是从相对简单的语音交互开始进行探索。

WebSocket 是最先被选择的技术方案。它简单、标准、支持全双工和长连接，也有不错的穿透性。对于当时聚焦语音交互体验的豆包来说，先用这个技术把用户和模型连接起来，验证方向的有效性，比直接搭建一套复杂音视频系统更重要。

但 WebSocket 很快就不够用了。WebSocket 的弱网体验差，会出现视频丢包、延迟不可控等问题，直接影响了模型的反应和回答效果。裴志伟介绍，在日常应用中，延迟抖动超过1秒，模型接收到的信息就会变形，造成回答失真或直接不回答。

为了解决弱网优化问题，豆包引入了 QUIC 方案。相比 WebSocket ，QUIC 在弱网恢复、多路复用和连接迁移上更适合移动端场景。QUIC 的引入，让豆包在耳机、车载、机器人、智能眼镜等更多路、更复杂的场景中，也能实现稳定高效的传输。

当豆包开始把视频通话作为重点能力建设时，QUIC 也不能满足需求了。这时候就要上 WebRTC。WebRTC 能做到超低时延，端到端延迟能比 QUIC 优化10%；同时还具备完整的视频链路能力，内置音视频编解码、回声消除，也有浏览器原生支持。这些能力共同构成了一个直观体验：豆包反应更快，能被自然打断，声音和画面更接近真人交流。

但是，WebRTC 也不是面向AI交互的多模态传输的最优解决方案。火山引擎判断这类多模态传输系统可能是目前最复杂或规模最大的 RTC 系统，可能有此前 RTC 需求的100倍到500倍的服务体量。这种亿级用户、长时间在线和高频调用的AI场景会不断放大成本和稳定性压力。

此外，在人与人通话中，音视频内容是按时间连续产生的，系统要做的是尽量稳定地把一端传到另一端。但 AI 交互中，模型可能在短时间内集中生成大量内容，用户也可能随时打断、追问、切换画面。多模态传输链路要做到实时中的异步，提前缓存，减少加载时间。

更核心的差别在于，传输链路的目标变了。人与Agent交互追求的是模型能在正确时间拿到最有价值的信息。用户问屏幕上一行小字时，继续传一段低码率视频未必是最优解，更合理的方式可能是要触发高清图、抽帧或局部增强，让模型先看清问题本身。

WebSocket、QUIC、WebRTC虽然在不同阶段解决了豆包的现实问题，但难以单独支撑未来规模更大、场景更复杂的实时多模态交互需求。

重构实时多模态传输链路

豆包需要一套面向AI交互的多模态传输链路。这个链路建联要更快，最好从秒级压到数百毫秒；端到端延迟要对齐RTC，不能因为系统改造牺牲用户体验；弱网体验要更稳定，适应移动、出境、地铁、电梯等复杂场景；同时还要支撑亿级并发，并把长期成本控制在可接受范围内。

为此，火山引擎选择利用 C/S 架构来搭建这套系统来支持复杂的网络传输策略、传控策略、播控策略；面向多模态传输的多模态会话系统；以及交互能力的进一步拓展。

具体实践上，火山引擎在客户端没有完全推倒过去的音视频能力，而是把成熟的采集、编码、回声消除等能力保留下来，同时把最底层的网络库换成 QUIC库，增加弱网恢复、多路复用和连接迁移能力。这样一来，用户侧的声音和画面可以更快、更稳地被传送出去。

传输层则基于MoQ协议实现了更好的会话控制。面向AI交互的多模态传输还要判断不同模态之间的关系。哪一路音频要优先，哪一帧视频更值得送给模型，哪些内容需要可靠传输，哪些内容可以为了低延迟做取舍，这些都不再是单纯的网络问题，而是会话控制问题。MoQ信令上会有分层的逻辑单元支持更精细的会话控制。

在服务侧，网关开始承担更关键的角色。用户传来一句话，网关可以选择是否直接送往模型；用户打开摄像头，网关需要判断是否需要抽帧、是否需要高清图、是否要结合模型反馈改变处理策略。在这个环节中，火山引擎引入了 MediaKit 同源的处理算法，让其服务于实时的传输场景。

目前，这套系统已经开始在豆包中落地。近期更新过豆包的用户，已有相当一部分开始使用新的多模态传输链路。这意味着，这套面向AI交互的多模态传输链路已经进入真实的 C 端高并发场景，而不是只在内部测试中验证。

火山引擎会继续将这套在豆包内部跑通的新系统，输出给更多客户：需要一站式服务的客户，可以直接获得多模态交互Agent；希望保留 Agent 定制空间的客户，可以获得 Agent 前后处理能力；自身有较强音视频处理能力和高度定制化Agent需求的客户，可以直接采购多模态传输和基础处理能力。

火山引擎不是简单把豆包的视频通话能力外溢出去，而是把一套被真实高并发场景验证过的多模态传输能力，拆成实时传输网络、传输SDK、传输网关、处理网关等不同模块。对内部，它能支撑豆包的多模态体验；对外部，它让不同开发深度的AI应用，都能按需接入实时多模态能力。

多模态传输成为 Agent 时代新底座

这也意味着，豆包的视频通话只是一个前台入口。火山引擎在豆包超大规模 C 端流量和自身产品化能力之间，快速沉淀了一套自己的多模态传输系统，然后通过豆包真正验证了这套系统能否在真实流量、复杂网络和高频交互中跑通。

火山引擎这套多模态传输系统的意义不仅限于体验的提升。长远来看，多模态传输很可能会从通信管道，变成 Agent 时代的人机交互技术底座。

过去两年，大模型竞争更多围绕参数、推理、上下文、多模态理解能力展开。行业评价AI 能力的重要坐标往往是谁能回答更准确，谁能推理更复杂，谁能理解更长上下文。但当 AI 从聊天框走向更多真实场景，保证体验下限就会变得同样重要。

没有稳定、低延迟、低成本的多模态传输能力，再强的模型也很难进入高频、长时、移动化、硬件化的真实场景。用户不会关心底层协议是什么，但能感知到模型是否真的“跟上了自己”。如果一个 AI 能理解世界，却总是慢半拍进入现场，它很难成为高频入口；如果一次连续会话成本过高，它也很难成为随时可用的基础能力。

模型决定智能上限，传输决定体验下限。这是对 AI 产品化的硬约束。正因如此，火山引擎、OpenAI等公司都在构建新的多模态传输技术底座。

OpenAI 最新推出的 GPT-Live 可以将任务交给另一个模型，同时自己继续维持对话。这种架构变化的本质，是把“自然交互”和“深度智能”拆成两个协作层：前者负责低延迟、持续、可打断；后者负责复杂任务和更强推理。

豆包的视频通话之所以深受用户喜爱不是因为简单“增加了摄像头”，而是因为多模态传输让AI从工具变成了更接近“在场者”的角色。

随着 Agent 竞争继续从模型能力延伸到工程能力，行业会需要一套完善的 AI 原生基础设施。从这个角度看，火山引擎在多模态传输上的投入，不只是为豆包补齐一条技术链路，而是在为 Agent时代进行底层基建。

当 AI开始实时进入真实世界，谁能长期、稳定、低成本地支撑这种交互，谁就更接近下一代 AI应用的基础设施位置。

不止于 4K，火山引擎画质增强让视频从清晰走向细腻

火山引擎视频云 — Sat, 18 Jul 2026 00:43:19 GMT

当色彩有了"深度"，视觉才有了"灵魂"

你有没有注意过，黄昏天空中那抹从金到紫的渐变，在大多数视频里总是断成一圈一圈的色带？那不是拍摄的问题，而是色深（Color Depth）的极限。

色深决定了每个颜色通道能表达多少级亮度。位数越高，色彩过渡越细腻，色带越少。

从 8-bit 的 256 级到 16-bit 的 65,536 级，色彩表达能力提升了 256 倍。这意味着天空的渐变可以丝滑如丝绸，水下的光影可以层次分明到每一缕光线。

火山引擎智能视频云画质增强：8–16 bit 全色深覆盖

火山引擎智能视频云的 vCube 画质增强功能，是一项 AI 驱动的深度视频画质优化方案。它通过智能分析视频内容，识别压缩伪影、色彩失真等问题，自适应地应用最优处理策略，覆盖通用内容、UGC 短视频、AIGC 内容、短剧、经典老片修复五大核心场景。

在色深能力上，火山引擎现已支持 8–16 bit 全范围色深输出，全面覆盖从标准网络视频到数据资产级精度的画质需求。

12-bit：电影母带级画质

精度：每通道 4,096 级亮度，是 10-bit 的 4 倍精度场景：为电影母带、商业广告、院线发行设计后期：提供极大的后期调色空间，支持动态亮度调整体验：带来真正的影院级观看体验

16-bit：数据资产级精度

精度：每通道 65,536 级亮度，是 10-bit 的 64 倍精度场景：面向视觉特效（VFX）和 3D 渲染源母带合成：作为数据资产级格式，支持极其精确的光学合成色带：色彩过渡极为细腻，大幅减少色带现象

效果对比：

为 Seedance 2.0 4K 直出提供全色深增强

色深配置已在火山引擎画质增强的 Pro 增强层级中提供，由大模型驱动的修复技术提供动力，旨在实现电影级图像质量。在线配置支持 8-bit 至 12-bit 输出，16-bit 输出可通过联系技术支持获取。

Seedance 2.0 视频生成模型已支持 4K 分辨率直出，直接产出满足高端流媒体和 4K 蓝光级别的画质 —— 消除天空色带、支持 HDR。在此基础上，火山引擎画质增强能力进一步将色深延伸至 12-bit 和 16-bit，共同构成从内容创作到画质增强的完整闭环。

专业提示： 12-bit 和 16-bit 数据无法被常规播放器或 Windows SDR 桌面渲染管线正确解码。请在 DaVinci Resolve 或 Premiere 等专业工具中查看效果，并使用支持色彩管理的专业监视器。12-bit 输出推荐使用 MOV 容器 + H.265 yuv444p12le 编码，以获得最佳性价比。

面向高质量内容时代

回头看看开头的那个问题 —— 黄昏天空的色带。它看似是一个技术细节，实际上折射出的是整个视频行业正在经历的变化。

AIGC 和自动化生产让高分辨率内容规模化增长的同时，品牌、影视、媒体和平台方对高质量、高稳定性、高复用价值的内容资产也提出了更高要求 —— 画质不再是 "锦上添花"，而是内容资产本身的一部分。

在这样的趋势下，火山引擎智能视频云的价值不只是“上传、转码、播放”，而是成为贯穿内容全生命周期的画质基础设施，让每一个画面，从诞生到分发，都能保持它应有的精度与质感。

8–16 bit 色深增强能力是这套基础设施的核心。每通道最高 65,536 级亮度，让色彩过渡更细腻、色带更少、调色空间更大，高光和暗部的细节都能保留得更好。不管是电影母带、VFX 合成还是 HDR 交付，从处理到交付的每一步，画质都不会打折。

了解更多产品详情：https://docs.volcengine.com/docs/4/1578688?lang=zh#color-depth