Signal #22：代码生成越便宜，理解系统越稀缺
AI Coding 正在快速降低代码的生成和修改成本，但代码变多，并不意味着系统更容易理解。当 Agent 持续添加分支、Fallback 和局部修复，代码库可能在保持可运行的同时，逐渐失去清晰的设计意图。
AI Coding 带来的下一种技术债，可能是“理解债”。未来真正稀缺的能力，不只是生成更多代码，而是让快速演化的系统仍然保持清晰边界、可解释结构，以及人类对关键决策的判断权。
WorkBuddy 团队从产品视角梳理工具、上下文、记忆、Harness 与长任务运行之间的关系，并明确指出当前 Agent 仍缺少业务正确性验证。
文章先把模型还原为无状态函数，再解释产品如何通过工具调用、MCP、Skill、Plugin、Context Engineering 和 Memory 为模型补充能力与状态。Harness Engineering 负责执行环境和运行约束，Loop Engineering 处理跨时间持续执行。团队没有将这些机制包装成完整答案，而是进一步指出功能正确性、业务正确性和代码库 Harnessability 仍是现实缺口，适合作为理解 Agent 产品工程体系的一份系统导览。
AI代码生成率94%：我们用一个 Skill 跑通需求开发全流程
企业微信团队将需求开发拆成八个可校验阶段，通过分层知识库、确定性脚本和运行时验证，让 Agent 按照工程规范完成真实业务需求。
团队针对 AI 开发业务代码时上下文过多、物料分散、定位不准确和跨会话状态丢失等问题，将需求开发组织成八个语义化阶段。流程通过五步定位法缩小代码范围，以三级知识库承接项目结构、模块规则和业务知识；精确数值计算、文件操作和幂等执行交给脚本，模型主要负责需求理解和任务编排。关键节点设置红线检查与运行时验证，并通过 TECH_SPEC.md 保存跨会话状态。文章披露代码生成率达到 94%，但更值得关注的是其背后的工程拆分方式。
从 Vibe Coding 到 AI 原生研发团队：一套能落地的工程实践
腾讯团队通过统一研发平台、内部能力接入、工程规则和协作机制，把零散的个人 AI 编程探索转化为团队级研发方式。
团队建设了 Vibe Flowing 平台，处理内部业务 SDK、数据不互通、权限申请和重复建设等企业场景问题，并跑通了“人定义需求，AI 负责实现”的实际案例。在工程层面，团队通过大仓组织、Skills、测试驱动开发和公共能力沉淀提升 Agent 的可用性；在产品与研发协作中，又引入页面评论等低门槛入口，使需求反馈可以直接进入研发链路。文章说明，AI 原生研发并不是简单换一款 Coding Agent，而是需要同时调整基础设施、规范、协作界面和团队能力建设。
Copilot 需求交付 Skill 如何实现数据需求24h交付
淘天数据团队把业务需求到 SQL 交付组织成四阶段 Skill，用分层、可审计的中间产物替代一次性黑盒生成。
copilot_req2sql 接收业务需求，逐步完成需求理解、资产检索、模型设计和 SQL 生成，并自动创建规范化的交付目录。流程采用渐进式披露，Agent 只在当前阶段读取所需知识，降低无关上下文对生成结果的干扰；同时借鉴 Spec Coding，将结构化需求、口径确认、模型方案和 SQL 等阶段产物保留下来。目前部分临时取数需求已经能够在 24 小时内完成交付，也说明数据开发自动化的难点并不只是 SQL 语法，而是业务口径、数据资产和交付流程的共同组织。
Coding Agent 的计划正在从会话里的临时文本变成可审查、可恢复、可治理的工程产物，Agent 交付的对象也开始从最终结果扩展到执行过程。
Coding Agent 在短任务中可以依靠模型连续推理完成工作，但当任务跨越多个阶段、会话甚至执行环境时，对话上下文很难继续充当可靠的任务状态。一些 Agent 产品开始将计划从聊天记录中独立出来，使其能够被审查、修改、持久化和重新执行。实际的研发自动化也不意味着预先确定所有步骤，而是由相对确定的执行骨架承接任务状态，同时为 Agent 保留必要的动态探索空间。计划成为独立工程资产后，长任务才能获得更清晰的控制、恢复和验证机制。
AI 生成接口自动化：从“随机抽奖”到“确定性交付”的工程实践
货拉拉将接口自动化脚本生成升级为包含交付标准、工具执行、运行验证和质量度量的完整闭环。
该体系经历了从直接生成、流程增强到 Skill 工程化的多轮演进。Skill 在这里被定义为面向交付的测试工程协议，既约束输入输出，也编排接口分析、脚本生成、运行调试和结果检查。整体架构按职责分层，把适合确定性执行的任务交给工具，并围绕效率、质量和覆盖度共同度量效果。这项实践的价值不只是提高脚本编写速度，而是把 AI 生成纳入可复用、可验证的测试生产链路。
快手将业务排障拆成底层降噪、中层 Workflow 快速分析和上层 Agent 深度推理，重点处理业务理解、证据可信度和幻觉控制。
业务级根因分析无法只依赖日志检索，Agent 还需要理解代码、业务资产和系统关系。团队通过接入业务代码和结构化资产补充上下文，对观测数据分层降噪，并建立证据等级和 Benchmark 评测体系。对于能够确定性处理的问题，则尽量转换为传统算法或固定 Workflow。文中“Workflow 快思考、Agent 慢思考”的分层比较务实，避免了让 Agent 无边界接管整个排障过程。
让开关自我消亡：AI 赋能的 Feature Flag 全生命周期治理
快手用大模型识别和生成开关清理方案，再通过 AST 校验、安全护栏和评测体系完成高风险代码治理。
功能开关长期不下线会形成隐性技术债，但传统治理依赖业务团队主动投入，很难持续推进。快手构建了大模型与 AST 校验结合的双引擎：模型负责理解开关语义和代码上下文，静态分析负责验证修改结果，再通过两道安全护栏控制执行风险。文章披露系统已自动下线 1500 个开关、删除六万多行代码，并保持线上零故障。这个案例说明，Agent 进入代码治理场景时，需要与确定性分析工具共同组成可验证的系统。
爱奇艺海外事业部基于 Cursor SDK 构建 Code Chat MCP 和 Debug Agent，让产品、运营和研发问题能够直接关联源码与跨系统信息。
Code Chat MCP 让非研发角色可以基于代码仓库获取更准确的业务结论，Intl Chat Debug Agent 则连接多个系统，对线上问题进行定位和分析。团队为 Agent 设置了业务路径优先等边界，避免模型在代码库中无目标搜索。这项实践体现了一个值得关注的方向：代码仓库不仅是开发资产，也可以成为产品、运营和客服理解系统行为的知识入口。
让 Agent 越用越准、成本越来越低：AgentLoop 的 Agent 经验自进化闭环
AgentLoop 尝试从真实运行 Trace 中提炼结构化经验，并重新注入 Agent 运行时，形成上线后的持续优化闭环。
Agent 每次执行都会留下包含输入、工具调用、输出和结果反馈的轨迹，AgentLoop 将这些轨迹转换为可检索、可复用的结构化经验，并在后续任务中按需召回。其定位介于可观测平台、经验系统和运行时优化机制之间。这个方向有助于降低重复探索成本，但仍需要持续关注错误经验固化、经验冲突、版本治理和验证机制。
Storage Agent Family: Agent 时代，重构云存储的“人机交互”
火山引擎以统一约定组织不同存储产品的 Agent，尝试让存储运维从多个控制台入口转向一致的智能工作空间。
Storage Agent Family 不是一个单独 Agent，而是 TOS Agent、TLS Agent 等不同存储 Agent 共同遵循的产品和工程约定。已经上线的成员能够承接日常运维、异常排查、日志分析和操作建议，并强调一致的操作节奏、安全底线和长期用户理解。它说明云产品的 Agent 化正在从单个聊天入口，进一步走向共享规则、统一安全边界和跨产品工作空间。
火山引擎推出 AI MediaKit，将音视频理解、处理和交付能力封装成 Agent 可组合的生产级工具底座。
单个模型能够生成视频，并不意味着 Agent 能够稳定完成一条成片。AI MediaKit 覆盖音视频理解、剪辑、转码、字幕、画质和交付等多个能力域，试图让 Agent 跨过理解、处理和最终交付三道门槛。其重点是把原本分散的音视频云能力组织成 Agent 友好的统一接口，使内容生产从单点模型调用转向完整工作流。
文章将测试开发重新定位为质量资产和研发自测能力的建设者，而不只是自动化脚本的生产者。
过去测开岗位容易被压缩成写脚本和维护平台，难以真正改变质量生产方式。AI 降低了用例生成、数据准备和工具建设成本，也让“研发拥有自测能力、质量资产与代码同步生产”变得更可行。不过，AI 同样可能放大已有的流程和组织问题。文章的核心判断是，测试开发需要从执行任务转向建设质量机制、验证标准和可复用资产。
团队通过拆解 Harness 工作流中的 Token 去向，使用渐进式披露、上下文裁剪和工具替换减少无效消耗。
团队先利用 AgentLens 分析完整开发链路，发现系统提示词、重复上下文和工具描述是主要消耗来源，随后提出让 Agent 按需读取、减少重复内容和缩短执行路径等原则。具体措施包括渐进式披露、减少完整历史重发、在部分场景以 CLI 替代 MCP，以及优化 Skill 和规则文档。文章预估中型需求可以降低 50% 至 65% 的 Token 成本，最终效果仍需结合真实任务的完成质量和 A/B 数据共同评估。
复杂 Agent 不能依赖不断加长的 Prompt，而需要围绕控制、决策、执行和治理建立职责清晰、数据可追踪的运行闭环。
文章从复杂系统视角重新拆解 Agent，提出在设计之前先明确系统必须长期保持的不变量，再将整体划分为控制、决策、执行和治理四个平面，并定义调度器、规划器、执行器、验证器等角色的职责与所有权。对于容易混淆的“重试”，文章进一步区分模型重试、工具重试和任务级恢复，并提出用数据契约约束不同角色之间的输入输出。其核心判断是，Prompt 更适合作为角色合同，而不是承载整个系统；稳定交付需要明确的状态、边界、验证与故障处理机制。
/better-harness：将工程最佳实践内置于 Qoder，持续提升你的工程效能
Better Harness 将 Coding Agent 所依赖的工程环境作为可持续治理的对象，通过体检、修复、复验和资产沉淀改善后续任务的执行质量。
/better-harness 不直接处理某一个业务需求，而是分析项目当前为 Coding Agent 提供的规则、工具、上下文和验证能力。它会结合 Agent 自定义能力的使用情况、真实任务会话和仓库工程基础，画出当前 Harness，定位影响任务完成的断点，再选择最小的改进载体进行修复和复验。完成后的规则、Skill 或工程能力会继续留在仓库中，成为后续 Agent Loop 可以复用的资产。这种做法把 Harness 从一次性的前置配置，进一步变成了可以持续演进的工程系统。
非功能性需求 (NFR) 是 AI 生成代码缺失的“护栏”吗？
AI 可以快速实现功能需求，但性能、安全、可靠性和可维护性等非功能性要求，决定了生成结果能否真正进入生产系统。
文章指出，当前 AI Coding 容易让团队把可运行的功能原型误认为可上线的生产系统，而性能、安全、可靠性、扩展性和运维要求往往没有被明确提供给模型。问题并不完全来自模型能力，现实研发中团队本身也经常没有提前定义和管理非功能性需求。文章建议将 NFR 纳入规格和验收过程，并借助架构决策记录保存不同要求之间的权衡，避免机械地应用一套统一标准。AI 降低了实现和验证部分 NFR 的成本，但前提仍是团队能够明确系统边界以及真正需要满足的质量属性。
Skill 并非越长、规则越多越可靠，过度膨胀的指令会稀释关键约束、制造隐性冲突，并降低 Agent 的实际遵循能力。
作者在维护数据质量异常检测 Agent 时发现，持续向 Skill 中追加规则并没有改善效果，模型反而更频繁地违反指令。原因包括关键规则被大量内容稀释、不同指令之间存在隐性冲突、否定式表达触发模型训练偏差，以及上下文过长造成早期内容被截断。文章提出对规则进行分层，明确优先级，使用正向且无歧义的指令，外置参考资料，并为自动修复机制增加防膨胀约束。它提醒团队，Skill 同样是一类需要版本管理、冲突检查和持续清理的工程资产。
WebMCP 解决了网页如何向 Agent 暴露原子操作，但复杂业务任务还需要一层能够组织任务知识、工具关系、上下文和人机边界的 WebSkill。
Tool 可以说明一个动作能够做什么，却很难告诉 Agent 在什么业务条件下调用、多个工具如何组合、哪些信息需要提前收集，以及何时必须让用户确认。WebSkill 提案试图在 WebMCP 之上增加浏览器侧的任务能力，将任务说明、工具绑定、上下文作用域和交互边界组织成可发现、可调用的整体。其设想中，模型负责理解意图和选择 Skill，WebSkill 提供完成任务的方法，WebMCP 执行具体动作，Generative UI 承接必要的人机确认。页面因此可能从信息展示界面进一步演进为 Agent 获取局部业务能力的入口。
D20特约｜MasterGo MCP 赋予 AI 掌控画布的能力
MasterGo 通过 MCP 向 Agent 开放画布读写能力，并尝试建立连接设计语义、组件资产和代码实现的统一中间层。
Agent 不再只能读取导出的设计图片，而是能够理解画布结构，生成、修改、查询和操作设计对象。MasterGo 还尝试用统一语义层建立设计元素与代码之间的对应关系，并在 D2C 中引入“基准文件”，使后续页面生成能够继承既有组件和视觉规范。它解决的核心问题不是让 AI 生成一张设计图，而是让设计资产以结构化、可操作的方式进入产设研协作链路。
D20 AI生活分论坛｜Design Skills 重构人机设计协作
蚂蚁将 Ant Design 中的设计知识、规则和高复用资产重新组织成 Agent 可消费的 Design Skill，并发布了构建方法。
传统设计系统主要面向设计师和开发者阅读，Agent 即使能访问文档，也难以理解组件背后的选择条件和设计判断。团队从知识来源、规则解构和 Skill 组织三个层次重新处理设计资产，并强调确定性、生长性和开放性。Ant Design Skill 的意义在于，组件库开始从“人使用的 UI 资产”演进为“人和 Agent 共同消费的研发资产”。
尤雨溪在 Vue&ViteConf 宣布 Vue 3.6 RC 发布，成立新公司支持 Vue 生态发展
Vue 3.6 RC 完成 Vapor Mode 的主要能力，并重构响应式系统，尝试在保留 Vue 开发体验的同时降低运行时成本。
Vapor Mode 通过编译生成更直接的 DOM 操作，减少虚拟 DOM 和组件运行时开销，可按需启用，并支持与现有 Vue 组件互操作。Vue 3.6 还对响应式系统进行了重构，以改善性能和内存占用。与此同时，尤雨溪宣布成立 Vue Source Inc. 支持 Vue 与 Vite 生态发展。对业务团队而言，当前更适合关注兼容边界、迁移成本和真实项目收益，而不是只依据基准测试决定是否切换。
CSS 链接参数允许页面向外部 SVG 等链接资源传递自定义值，为可复用、可主题化的外部图形资产提供了新的标准化路径。
外部 SVG 通过 <img> 等方式引用时，通常无法继承页面中的 CSS 变量和选择器，开发者只能复制多份资源或改为内联。新的草案尝试让页面在链接资源时传递参数，由资源内部消费这些值，从而改变颜色等样式。该能力仍处于首个公开工作草案阶段，但对于图标系统、品牌主题和组件资产复用具有实际价值。
Flutter 全新真 3D 实现，用 flutter_scene 能开发一个「我的世界」
flutter_scene** 基于 Flutter GPU 和 Impeller 构建原生 3D 场景，并能够与 Flutter Widget 共同参与画布合成。**
项目提供场景图、材质、光照、阴影、后处理和模型导入等能力，不依赖 Unity 等外部引擎。SceneView 可以像普通 Flutter 组件一样进入界面布局，甚至允许将 Widget 放入三维场景。它目前仍有物理系统和工具链等限制，但补充了 Flutter 在数据可视化、产品展示、空间交互和轻量三维应用中的能力。
Flutter 开始将 Material 和 Cupertino UI 包从框架主体中解耦，为组件样式独立演进和更快发布提供基础。
当前 material_ui 和 cupertino_ui 已进入预发布测试，Flutter 3.44 以上版本可以尝试切换新的导入路径。样式包独立后，Material Design、Liquid Glass 等视觉体系的更新不再完全受 Flutter SDK 大版本节奏限制。现阶段仍主要用于兼容性验证和迁移准备，距离大规模业务采用还有一定距离。
Android Bench 迈入新时代：Android 开发 LLM 评估方法持续优化
Android Bench 引入 Harbor 框架、开源权重模型以及成本和效率指标，开始从单一完成率转向更完整的移动开发 Agent 评估。
Android Bench 面向真实 Android 开发任务，早期主要关注模型能否完成修改。新版根据社区反馈重新运行基准，引入 Harbor 执行框架，新增多款开源和闭源模型，并把成本、运行效率等因素纳入排行榜。团队还向社区开放任务设计和评测结果提交，使基准能够持续覆盖新的 Android 工程场景。
小红书引擎架构团队OSDI 2026新成果：HELMSMAN重塑大规模向量检索基础设施
小红书面向全闪存服务器设计 HELMSMAN，用聚类索引、定制存储栈和学习式剪枝降低大规模向量检索对 DRAM 的依赖。
图索引在 SSD 上存在大量随机访问，传统磁盘向量检索方案又难以充分利用现代闪存能力。HELMSMAN 采用聚类式索引，通过分层学习式剪枝减少无效访问，并用 GPU 加速分布式索引构建。团队实验显示，其吞吐量相较对比系统提升 2 至 16 倍，最高达到纯内存系统 85% 的吞吐，硬件成本可降低 90% 以上，为工业级向量检索提供了一条全闪存路径。
小红书、北大开源 UltraEP：面向大规模 MoE 训推的「最优」负载均衡方案
UltraEP 根据每层、每个 Microbatch 的真实路由结果动态复制热点专家，将实时负载均衡引入 MoE 训练和推理。
MoE 的专家路由天然存在负载偏斜，静态划分难以适应不同请求、层级和 Microbatch 的变化。UltraEP 在运行时使用精确路由信息决定热点专家副本，并通过预留 Slot、跨层复用以及控制面和数据面优化控制迁移开销。团队披露其平均达到理想性能的 94.3%，相较对比框架提升 1.49 倍，并已进入实际生产。
小红书 dots infra 开源BigMac：突破多模态大模型训练的帕累托前沿
BigMac 通过嵌套流水线调度多模态编码器、LLM 和生成器，在计算效率与激活显存之间取得更好的平衡。
多模态训练系统通常需要在计算气泡和显存占用之间取舍。BigMac 以 LLM Pipeline 为主干，把编码器和生成器任务嵌入依赖安全的位置，并提供全局调度计划、低侵入模型接入和性能诊断工具。其设计重点不是增加一种新的模型并行名称，而是把不同模态模块的依赖关系纳入统一调度，从系统层减少等待时间和显存峰值。
淘天从序列并行、Attention 算子、混合量化和缓存调度四个层面优化图生视频推理，展示生成模型生产化中的系统协同。
团队采用 DeepSpeed Ulysses 进行序列并行并优化通信重叠，引入 SageAttention 和选择性量化，在不同线性层之间组合 W8A8、W8A16 方案，并自研 DPCache 进行缓存调度。文章披露，在不计算多卡扩展收益时取得了 4.87 倍推理加速。各项优化并非彼此独立，显存、算子精度、通信和缓存策略需要共同设计，才能把模型能力转化为可承担的线上成本。
让 AI Agent 看见正在发生的业务，阿里云 EventHouse 正式商业化
EventHouse 将多源实时数据统一成事件模型，为 Agent 提供可治理、可查询的业务状态，而不只依赖离线知识库。
EventHouse 通过 Catalog 统一事件定义和治理，通过 Analysis 联合分析实时与历史数据，再由 Luma 提供自然语言查询入口。传统 RAG 更适合回答已经发生并被沉淀的知识，而生产 Agent 还需要知道订单、设备、交易和告警此刻处于什么状态。事件湖仓因此可能成为 Agent 连接实时业务系统的重要基础设施，但其实际价值仍取决于事件口径、权限边界和后续执行闭环是否完整。
社区之声：一次 Agent 协作“翻车”，让我看懂了 RocketMQ 这次升级
RocketMQ 通过 LiteTopic、异步协作和细粒度流控，尝试适配 Agent 动态会话、长任务和多节点协作产生的新型消息负载。
传统消息队列面向相对固定的生产者和消费者，而多 Agent 系统会动态创建会话、并行执行任务并频繁改变协作拓扑。LiteTopic 可以动态创建轻量子主题，实现更细粒度的故障隔离和状态管理；Suspend 三态消费模型与按 LiteTopic 限流，则用于处理等待、恢复和不同任务之间的资源竞争。文章还介绍了 MCP Server，使 Agent 能够直接操作消息队列。
Higress 推出 Serverless 企业版，对比开源成本降低 90%，认证性能提升 30 倍
Higress Serverless 企业版重点优化大规模消费者认证、配置膨胀和网关运维成本问题。
开源自建 Higress 在消费者数量持续增长时，控制面配置体积和认证开销可能同步放大。企业版将消费者认证从全量配置中解耦，使认证性能和配置规模不再直接受消费者总量影响，并采用 Serverless 方式降低运维投入。文中披露的 30 倍性能提升和 30% 至 90% 成本节省来自特定场景，更适合作为大规模网关容量设计的参考。
把大模型一键接进你的 App，火山引擎 Supabase 上线 AI-Gateway
火山引擎 Supabase 将模型访问、用户鉴权、配额和审计整合到 BaaS 中，降低轻量 AI 应用自建后端网关的成本。
前端应用可以复用 Supabase 登录态调用模型，无需把模型 API Key 暴露在客户端；团队则可以在控制台统一管理配额、调用记录和访问策略。相比自行搭建一层后端转发，它减少了鉴权和额度管理等基础工作。该能力适合个人开发者和中小型应用快速接入，但生产环境仍需要结合业务场景设计限流、成本预算和异常处理。
STAROps 将真实用户监控中的多类弱信号组织成长期巡检任务，关注告警阈值之外的渐进式体验退化。
传统告警擅长发现已经越过阈值的明确异常，大盘适合人工观察整体趋势，而巡检更关注多个信号共同出现时是否意味着体验正在退化。STAROps 以页面、应用等对象为单位，结合性能、错误、崩溃和环境数据生成巡检报告，并尝试解释异常证据。该实践适合作为实时告警之外的稳定性治理补充，把难以单独触发报警的弱信号整理为可跟进的问题。
RAG 核心概念与原理：Chunking、Embedding、相似度、HNSW 与多路召回｜得物技术
得物技术从工程视角系统梳理 RAG 的离线建库和在线检索链路，适合作为团队统一基础概念的参考材料。
文章依次介绍 Chunking、Dense 与 Sparse Embedding、余弦相似度、HNSW 索引，以及 Query Rewrite、元数据过滤、多路召回、RRF 融合和 Rerank 等环节。其重点是说明检索效果并非由单个向量模型决定，切片策略、召回路径、过滤条件和精排模型都会影响最终结果。内容偏基础，但结构完整，适合作为 RAG 工程链路的入门说明。
下一代搜索智能体评测基准！美团开源LoHoSearch，用知识图谱校准AI能力认知
LoHoSearch 利用大规模知识图谱自动构造高难度、可核验的问题，为搜索 Agent 提供比传统人工题库更有区分度的评测。
该基准以覆盖 762 万个维基百科实体的知识图谱生成候选问题，再经过难度控制和人工核验，最终形成 544 道题目，覆盖 11 个领域。团队发现，现有前沿搜索 Agent 在这些问题上的准确率明显下降，并需要更多工具调用。LoHoSearch 的价值不只是增加一套排行榜，而是探索如何规模化生成具有明确答案、复杂依赖和稳定难度的长程搜索任务。
让AI离开温室，走向动态世界：MineExplorer揭示顶级多模态大模型被忽视的能力断层
MineExplorer 将多模态模型放入持续变化的开放环境中，评估感知、规划、导航和长程执行的组合能力。
基准通过隐藏前置条件、动态环境和多步任务，避免模型仅凭静态图像识别或游戏知识完成测试。对 18 款模型的评估显示，模型普遍存在感知强于推理、导航失败率高、多跳任务完成度低的问题；单纯增加执行步数或记忆容量也不能解决这些缺口。该结果提醒团队，Agent 评测需要覆盖状态变化和行动后果，不能只测试单轮理解或局部操作。
微软亚洲研究院分别从共识排序公平性和内核运行时调优切入，展示系统软件中仍可被重新定义的基础机制。
Bercow 协议把“机会平等”引入区块链交易排序，试图在公平性和时效性之间建立可量化约束；Xkernel 则允许在运行期间安全修改传统内核中的固化常量，使系统能够根据工作负载动态调整。后者尤其值得 Agent 基础设施关注：当工作负载越来越动态，仅依赖部署前确定的系统参数可能难以持续保持最优状态。
RE-TRAC 在每轮搜索后生成包含结论、证据、不确定项和后续方向的结构化状态，让 Agent 能够跨探索轨迹积累经验。
传统 ReAct 搜索在一次轨迹结束后，很难把失败原因和已经确认的证据有效传递给下一轮探索。RE-TRAC 将每轮状态显式表示为答案与分析、证据库、来源验证、不确定项和待探索方向，再基于这些状态继续搜索。实验显示，小参数模型在该框架下能够接近或超过部分更大模型，也说明测试时状态组织和搜索策略可以显著影响深度搜索表现。
UniNote 将多模态内容表示和排序能力组织进统一模型，并通过两阶段训练兼顾召回效率与排序质量。
第一阶段使用 SFT 学习统一向量表示，第二阶段使用强化学习直接优化排序目标；同时引入 Matryoshka Representation Learning，使同一模型能够输出不同维度的向量，适配不同延迟和存储预算。实验显示，UniNote 在多数 Item2Item 任务上超过基线。该方向试图减少工业检索中召回模型和排序模型之间的割裂。
RynnBrain 1.1 具身多模态基础模型——让机器人在真实世界里“各司其职”
RynnBrain 1.1 增加接触点预测和三维定位能力，并基于统一基座训练面向不同机器人的操作策略模型。
模型针对场景理解、空间感知和动作相关能力进行优化，并在七项评测中取得领先结果。团队基于该基座进一步训练 RynnBrain-VLA，在轮式人形、灵巧手和双臂机器人上完成不同操作任务。其思路是由通用具身多模态模型提供理解能力，再由下游策略模型适配具体机器人形态和任务。
WAIC 2026｜面壁智能首个具身智能成果 MiniCPM-Robot 系列模型正式发布！
MiniCPM-Robot 同时覆盖机械臂操作和移动机器人跟踪，强调小参数、本地部署和具身记忆能力。
系列包含面向通用机器人操作的 MiniCPM-RobotManip，以及面向移动机器人跟踪和导航的 MiniCPM-RobotTrack。前者基于 MiniCPM-V 训练，强调较小参数规模下的操作性能；后者支持真实设备本地断网部署，并通过自进化数据管线提升跟踪效果。配套的 PhyAI 推理框架用于降低部署和推理成本。
从“会说”走向“会创作”｜Seed Audio 1.0 音频创作模型发布
Seed Audio 1.0 将语音、音效、节奏和时间控制统一建模，目标由单纯语音合成转向完整音频创作。
模型能够在一次生成中编排旁白、人物语音和环境音，支持约 100 毫秒粒度的时间控制，并覆盖 20 多种语言。它还支持零样本音色生成和较长时间的音色稳定性。统一生成减少了传统音频生产中多个模型和后期工具之间的拼接，但其真实生产价值还需要结合长音频一致性、可编辑性和版权治理继续观察。
Qwen-Image-3.0 重点提升复杂布局、小字号文字、多语言和细节渲染能力，面向海报、界面和信息图等生产场景。
模型支持较长文本输入，可以生成九宫格、嵌套界面和包含大量文字的复杂画面，并强调 10px 小字与多语言渲染能力。相比只关注审美表现的图像模型，这类能力更接近真实设计和营销物料生产需求。目前相关平台已开放 API 邀测，具体效果仍需要等待公开版本和更多真实案例验证。
