阅读

美国科技公司苹果（Apple）在最新发布的2026财年第四季度财报中披露，其库存水平显著上升，从第三季度的110.9亿美元增至第四季度的145.4亿美元，环比增长31.1%。与2025年同期的57.2亿美元相比，库存同比增长高达154.3%。这一数据反映了公司在面对关键组件供应紧张时的备货策略。

苹果首席执行官John Ternus在财报电话会议上表示，目前看到的内存定价情况是“前所未有的”。他提到，尽管公司通过携带库存和部分非内存组件的成本降低抵消了部分影响，但预计12月季度的内存成本将进一步上升。受此影响，苹果将下一季度的毛利率指引从本季度的47.9%下调至45%至46%之间。

Ternus还透露，为了改善供应状况，苹果的制造采购义务从6月到9月增加了330亿美元。首席运营官Sabih Khan也参与了关于内存问题的讨论，并重申了采购义务的增加，同时未排除未来对设备提价的可能性。此外，iPad销售疲软也被归因于供应限制，其营收为62亿美元，低于分析师预期的67亿美元，同比下降10%。

美国AI公司Anthropic已更新其编程工具Claude Code的系统提示词，明确禁止该工具用于复刻特定的现有电子游戏。这一变化由Anthropic工程师Addy Osmani于2026年11月2日在X平台上确认，旨在遏制日益增多的AI生成游戏侵权问题。

Osmani表示，针对Opus 5.5模型，团队在提示词中增加了两句关键指令：“请构建原创游戏、类型游戏以及基于用户自身设计和资产的游戏。不要构建对特定现有游戏的复刻，即使它被命名为或称为‘原创’。”此前，Tom's Hardware等媒体及用户在社交媒体上分享了疑似新提示词的截图，引发了社区关注。

尽管直接克隆被禁止，Anthropic强调用户仍可使用Claude Code进行原创游戏开发、特定类型的游戏创作或使用自有素材的项目。Osmani指出，此举是为了遵守公司的使用政策，防止利用AI侵犯知识产权。他表示公司将持续迭代这些指南，以在创意自由和法律合规之间取得平衡，并邀请用户反馈误判情况。

截至2026年11月2日收盘，以科技股为主的纳斯达克100指数（Nasdaq 100）较其10月份的高点累计下跌10%，正式进入技术性回调区间。标准普尔500指数同期下跌约4%。

费城半导体指数（SOX）当日下跌3.4%，延续了周五7.2%的跌幅。该芯片股指数在周一未能收复200日移动平均线，这是自2025年6月以来首次跌破该水平。

Roundhill Financial首席执行官Dave Mazza表示：“油价下跌本应利好科技股，但即便原油价格暴跌，股市仍无法维持开盘涨幅，这显示出上周市场崩盘后投资者信心依然不足。”

Vercel宣布其AI Gateway现已支持美团（Meituan）的LongCat 2.5模型。该模型结合了原生视觉理解能力与编码及多步工具调用功能，旨在帮助代理在复杂代码库和完整项目构建中工作。

据Vercel介绍，LongCat 2.5在视觉编程、创意设计和3D任务方面有所改进，并支持更长的代理工作流，能够执行从规划到执行的工程任务。该模型支持文本和图像输入，拥有100万token的上下文窗口，适用于处理代码、文档和扩展的任务历史。

开发者可通过设置模型名称为meituan/longcat-2.5来使用此模型。它兼容Claude Code、Codex、Cursor等编码代理，需安装最新Vercel CLI并运行npx vercel ai-gateway setup进行配置。

Vercel AI Gateway提供统一的API用于调用模型、跟踪用量和成本，并配置重试、故障转移和性能优化。Gateway反映提供商定价，不收取平台费用或推理加价，包括对自带密钥（BYOK）请求。

为新 GPU 硬件配置 Kubernetes 是一项容易出错的工作。驱动、内核、容器运行时、网络、算子和调度器必须协同工作，且设置要针对硬件和负载调优。微小的不匹配就能阻止工作负载运行或限制性能。英伟达云架构师 Mark Chmarny 和软件工程师 Yuan Chen 在 2026 年 11 月 2 日的技术博客中，记录了他们如何在 Vera Rubin NVL72 早期硬件上完成这一适配，并将其经验固化为 NVIDIA AI Cluster Runtime（AICR）的版本化配方。

从 GB200 NVL72 升级到 Vera Rubin NVL72，用户可见的变化并非微调。GPU 驱动需要全新分支：验证使用的 R615.23 是主机预装的开源内核模块驱动，而官方平台支持目标是 R620。网络侧，ConnectX-7 网卡和 BlueField-3 DPU 被 ConnectX-9 SuperNIC 和 BlueField-4 DPU 取代，DOCA 3.3.0 是首个支持 ConnectX-9 的正式版本。设备拓扑也不同：Vera Rubin NVL72 计算托盘暴露八组 ConnectX-9 PCI 设备共 32 个功能，而 GB200 只有四个 ConnectX-7 适配器。多节点 NVLink 工作负载仍依赖 IMEX，但 DRA 管理的 IMEX 与主机静态 nvidia-imex 服务互斥，必须禁用后者。

这些变化散落在从底层绑定到编排层的各个位置。AICR 的应对方式是将所有发现编码进配方：主机管理模式驱动（GPU Operator 设 driver.enabled: false，容器工具链仍由算子管理）、启用 ComputeDomains 的 DRA 驱动、Kubernetes 版本下限 1.34.1（1.34 提供 GA 的 resource.k8s.io/v1 DRA API，.1 补丁因为 RKE2 的 CDI/NRI 工具链路径需要 containerd 2.1）、Ubuntu 26.04 搭配 Vera 优化的 arm64 64k 页内核，以及 NFD 拓扑更新器默认 60Mi 内存限制需上调——否则在多 TB 的 NVL72 工作节点上会触发 OOM 杀死。配方还引入了 DraNet 用于将 ConnectX-9 设备分配给 Pod，以及通过 NodeWright 施加的独占 RDMA 网络命名空间模式，使每个 Pod 只看到自己的主机通道适配器。

验证流程在实时 Vera Rubin NVL72 参考集群上分四步执行。第一步生成配方，离线解析 14 个组件和 5 层覆盖。第二步渲染部署包，产出 61 个文件包括有序 Helm chart 和部署脚本。第三步对集群做快照并运行验证：部署阶段四项检查全部通过；一致性阶段八项通过，覆盖 GPU Operator 健康、DRA/ComputeDomain 支持、KAI 成组调度、Pod 自动伸缩和安全加速器访问等。第四步是跨节点 ComputeDomain 测试，验证 IMEX 通道注入和 NVLink 织物连通。性能阶段运行跨节点 NCCL all-reduce，通过 IMEX ComputeDomain 在 NVLink 织物上完成 16 GiB 消息的 all-reduce，总线带宽 744.71 GB/s，达到配方设定的下限。整个序列（配方、部署包、快照、部署和一致性验证）在约五分钟内完成，性能阶段额外加上 NCCL 作业本身的运行时间。

但边界必须看清。配方是 Preview 状态，不携带生产支持和生命周期资格。验证在英伟达参考硬件上由厂商自报完成，无独立复现。推理服务性能明确推迟：vLLM 在 v0.27.0 合入了 Rubin（sm_107a）支持代码，但 SM107 内核路径在构建时门控于 CUDA ≥ 13.4，而 vLLM 截至 v0.28.0 的发布镜像仍基于 CUDA 13.0.3 构建，因此最新镜像携带调度代码却没有编译后的内核。ai-dynamo 最新发布 v1.4.2 锁定 vllm-openai v0.26.0，更早于该代码。一个可用的推理性能下限需要已发布的、基于 CUDA 13.4 构建并经实机验证的运行时镜像。

验证过程本身也反向推动了上游修复。在早期硅片上运行时，AICR 发现 go-nvlib 中一个未映射的 Rubin 架构值导致 DRA 驱动的 kubelet 插件崩溃循环。由于架构支持先落入 go-nvml，再流入 go-nvlib，然后进入 GPU Operator、Kubernetes Device Plugin、MIG Manager 和 DRA 插件，修复沿栈一致传播，从首次崩溃报告到在 Vera Rubin 硬件上的验证构建约三天，最终随 DRA 驱动 v0.5.0 正式发布。验证还发现主机管理的 IMEX 守护进程与 DRA 管理的 ComputeDomains 目前不能共享节点，这一反馈塑造了 DRA 驱动 v0.5.0 中加入的主机管理 IMEX 选项。

对平台团队而言，这篇记录的实际价值不在于 744.71 GB/s 这个数字本身——它是厂商在参考硬件上的自测结果——而在于它展示了新硬件适配的完整决策清单如何被固化为可复现、可验证的配方，使第二个集群能在次日重复同样的结果，而不必重新踩一遍 NFD 内存限制或 IMEX 互斥的坑。

思科DevNet的PubHub内部发布工具在2026年进行了一次时间紧迫的改版。团队没有按传统流程先做设计再做实现，而是直接让AI编码代理根据用户故事和后端API生成了端到端的界面。结果是可以用的：用户能走完主要流程，接口也连上了后端。但设计师Alejandro Marrufo和UX负责人Casey Tong在博客中写道，「能用」并不等于「做完了」——界面没有遵循思科的视觉语言，一些AI生成的组件不够直觉化，多处流程需要清理。

这引出了一个实际问题：如何利用AI加速设计修改并将其融入最终产品的流程？他们首先尝试的方案是把已有的HTML页面转回Figma，让设计师在熟悉的工具里继续精化，再通过Figma MCP连接让编码代理把变更同步回代码。想法很吸引人——设计工作留在Figma，AI负责搬运到实现层。

实践中暴露了三个问题。第一，细节在往返中丢失：Figma与代码之间的来回转换遗漏了交互、完整的页面和按钮流程以及动画——恰恰是这些部分让体验显得「做完了」。第二，更新比预期慢：通过Figma修改HTML原型比项目时间表允许的速度更慢，有些页面甚至需要先在Figma里重建并重新连入流程，才能开始任何精化。第三，真相源变得模糊：Figma文件和HTML原型并行演化，设计师和团队其他人很难判断哪个版本是当前状态。

Figma并非一无是处。它在维护素材库和处理精细的UI元素方面仍然是更好的工具。但在时间紧迫的条件下，它不是精化一个已经在代码中运行的界面最快的地方。

于是他们尝试了另一条路：让AI编码工具直接检查现有原型并修改其HTML。设计工作留在已经存在的界面里，没有重建步骤。HTML原型成了唯一的真相源。设计师可以分阶段做修改、逐轮审查、在过程中给AI反馈。设计工作不再需要先在设计工具里重建界面，而是直接针对一个运行中的实现进行，包括Figma难以承载的交互和流程。

一个实际约束很快浮现：token限制。项目进行到中途，设计师用完了token额度，从Cursor切换到Claude，再切换到Codex，等限额重置后继续。工作能扛过这些切换，是因为HTML制品——而非某一个工具——持有设计的状态。他们建议采用类似方法的团队提前规划这一点。

用这种方式，设计师每天都能编辑并交付可用的HTML页面，产出新迭代。在旧的Figma优先流程下，单个页面需要数天。速度在整个团队中产生了复利效应：更快的设计产出意味着更快的工程测试，也意味着下一轮设计迭代能更快获得反馈。

最终形成的工作流是迭代的：产品团队定义用户故事和后端API；AI编码代理据此构建端到端界面；设计师审查可用的HTML页面和流程，用AI编码工具精化原型；设计师将更新后的HTML制品连同设计系统、不同角色的端到端流程和描述变更的changelog一起交给开发者；开发者把这些交给编码代理，由代理在工作项目中应用设计变更；团队测试审查结果，通常是在线实时进行，然后重复这个过程。

HTML原型不再只是mockup，而成了交接文档本身。工程师可以用它准确复现设计，而且这个做法出乎意料地受欢迎。让这成为可能的几个要素：嵌入式设计系统（颜色、字体、组件和间距与页面放在一起，工程师可以引用规则而不必从截图中推断）；角色切换器（通过原型中的控件切换不同用户角色，工程师能清楚看到每条流程及其变体）；changelog（每轮迭代记录变更内容，工程师可以增量应用更新而不必对比整个页面）。

在同步设计和代码方面，他们最初用问题列表逐条提示编码代理修复，既慢又手动。后来要求设计师在每个新版本中附带changelog，工程师把changelog和更新后的HTML一起交给代理，代理就能自动在整个项目中应用变更。交接从一次性提示变成了基本自动的更新步骤。

他们总结的最大变化不是用AI写了更多代码，而是把设计和工程的反馈环拉近了，直到两个角色之间的界限开始模糊。审查变得更频繁，设计师有时在会议中实时编辑；工程师更早开始测试，甚至自己做一些小的设计迭代。整个团队可以把更多时间花在体验和愿景上，更少花在实现后勤上。

对于想尝试这种方法的团队，他们列出了几条实践建议：从可用构建开始，让AI代理从用户故事和API规范生成端到端界面，然后针对它做设计而非从空白画布开始；保持一个真相源，让HTML原型成为规范设计，Figma用在它最擅长的地方（素材库、精细细节），不维护每个屏幕的并行副本；把交接内置到原型中，包含设计系统、每轮迭代的changelog和查看所有角色或流程变体的方式；明确说明代理无法推断的内容，记录次要交互和边缘情况，否则编码代理会自己编造；为token限制做计划，预期在项目中途切换AI工具，因为HTML制品持有设计状态，工作可以延续；缩短审查周期，更频繁地审查，愿意在工程师在场时实时做编辑；让设计师的判断保持核心位置——AI能快速产出功能性的第一版，但它不知道你的设计语言，也不知道哪些交互感觉对。

对他们来说，这个实验产生了一个实用模式：让AI创建第一个可用版本，让设计师精化一个同时充当交接文档的功能原型，让编码代理把这些精化带入项目。这给了他们一条更快的路径——从一个能用的界面到一个感觉像自己产品的界面。

据德国科技媒体heise online报道，英伟达（NVIDIA）第二快的高端游戏显卡RTX 5080价格在最近两周内上涨超过30%，目前很难低于2000欧元买到。这一涨价部分源于此前关于旗舰产品RTX 5090可能停产的传闻，尽管英伟达副总裁Jeff Fisher随后否认了停产说法，但市场紧张情绪已推高了次级产品的需求。与此同时，RTX 5090的价格也已攀升至8000欧元左右。

更关键的是，原本计划作为RTX 5090潜在替代或补充的24GB显存版RTX 5080似乎将推迟发布。据台湾硬件资讯网站Benchlife消息，显卡制造商尚未收到英伟达关于该新版本的完整设计文档，这原本计划在10月完成。此外，在中国制造基地，现有的GB203 GPU芯片库存已售罄，仅能维持一到两个月的供应，这使得原定于2027年1月CES展会期间发布的新款RTX 5080面临巨大不确定性。

造成这种短缺的根本原因是持续的人工智能热潮。英伟达将相同的GPU芯片用于其工作站显卡（如RTX Pro系列），这些产品拥有更大的内存容量，更适合本地运行AI模型，且利润率更高。例如，GB202芯片同时用于RTX 5090和RTX Pro 6000等卡。由于GDDR7内存同样紧缺，英伟达倾向于优先供应高利润的专业工作站市场，从而挤压了消费级游戏显卡的产能和定价空间。

大模型可以自信地告诉你代码里有漏洞，但你无法知道哪些说法被检查过、下周还能不能得到同样的答案、六个月后审计员追问时这条发现为什么存在。Cisco首席工程师Julio Gomez认为，这就是LLM安全工具从演示走向安全项目的全部距离。

他实现了Cisco发布的Foundry安全治理规范——一份设计文档而非产品——然后把它指向真实代码：Langflow 1.7.3的完整v1 API（289个函数级单元、25个模块）、MLflow 2.9.0（830个单元）、以及OWASP的PyGoat训练应用（180个单元）。他给自己定了一条硬规则：不设稻草人基线。对照组使用同一个模型、同一段代码、一个公平、有纪律、同样要求结构化发现和精确行号引用的资深应用安全提示。

结果是这样的：Foundry在Langflow上为人类呈现了32条发现，基线呈现15条；两者引用准确率都是100%；但基线把15条中的14条标为'已确认'，没有任何机制强制执行这个判断，而Foundry的28条确认和4条待审是由机械检查划出的。Gomez对此的总结是：模型从来不是瓶颈，信任才是。

Foundry的核心设计决策有两个。第一，检测是包容的，决策是严格的。Detector被要求偏好召回率——任何说得过去的都提出来；所有纪律都放在下游。这让同一个模型可以同时做到彻底和可信，而不是逼你在两者之间选一个。第二，证据门不是第二意见。它从不问模型'你确定吗'。它把每一条引用拿回去和磁盘上的字节核对：文件必须存在于目标中，行号必须在范围内，引用的文本必须真的出现在那里。只有引用存活的发现才被标为'已确认'，其余降级为'待审'或直接拒绝。模型无法靠争辩绕过不存在的行号。

这个分离为什么重要，Gomez用重复运行来说明。他独立跑了两次完整流水线，存储中122条记录折叠为67个不同指纹，56条在两次运行中复现并落在已有身份上——大约90%重叠，尽管模型输出本身不确定。这意味着下一次CI运行可以计算差异（新增、复现、消失），而不是让团队重新阅读一堵措辞不同的文字墙。第二次运行之后，团队通常就不跑了；有了稳定身份，他们才会继续跑。

在更大范围的MLflow上，治理同样成立：830个单元、41次批量调用、480万token在声明的600万上限内完成，发现落在MLflow历史CVE所在的同一区域（artifact存储层的路径遍历）。但只有13条被标为已确认，110条是待审线索——门在大范围陌生代码上变得更保守，这恰恰是分层在做它的工作。

Gomez明确声明他不是在宣称Foundry更聪明或更便宜。同一个模型，Foundry之所以发现更多，是因为它穷举扫描而不是让一次agent回合做策展。token成本约为单次调用的十倍，换来的是覆盖、机械门和去重。'已确认'意味着经过验证且值得审查者花时间，不意味着已被利用——证明可利用性需要活体测试台，那是规范中他未实现的独立角色。

他的结论是：当发现需要接入流程——一个不能被重复淹没的问题跟踪器、需要知道检查了什么的审查者、随代码变更重复运行的流水线——治理层的价值才显现。对于一名工程师看一小段熟悉代码的一次性检查，一个普通agent更便宜也更实用，直接用就好。

这篇是Security Loop系列的第二部分，发表于2026年11月2日。所有运行记录、溯源日志、规则缺口和评分比较公开在github.com/juliogomez/foundry。

荷兰最大的电信运营商KPN与AI音频公司ElevenLabs合作，正式推出名为Mobiel AI的语音助手服务。该服务作为KPN EEN MKB移动订阅的附加组件，集成在KPN现有的移动应用中，旨在帮助荷兰的小企业主和自由职业者更高效地管理业务通话。

Mobiel AI的核心功能包括未接来电的语音信箱转录、每通电话的自动摘要与文字记录（含后续行动项），以及智能呼叫菜单以将来电路由至同事或部门。KPN指出，53%的创业者表示随时接听电话会分散工作注意力，而69%的企业家认为客户满意度是首要挑战，该工具试图在“随时可达”与“专注生产”之间取得平衡。

在技术实现上，双方针对荷兰语中复杂的复合词和地区口音进行了专门优化。通过收集更多荷兰语数据并微调底层转录模型，验证准确率从约50%提升至90%。所有语音数据均在荷兰境内的KPN数据中心处理，确保数据主权，且客户数据不用于训练AI模型或与第三方共享。

在 Kubernetes 上运行分布式 AI 训练或推理任务时，一个真实的工作负载很少是单个 Pod。它是一棵小型资源树：若干 Pod 组，每组有角色、副本数、Pod 模板和依赖工作负载类型的状态。JobSet、LeaderWorkerSet、PyTorchJob、RayCluster 等框架各自用不同方式编码这些信息。构建调度器、控制器、仪表盘或成本工具的团队因此面临一个组合爆炸问题：每接入一个新框架的 CRD，就需要编写一套适配器来回答同样的三个问题——工作负载的结构是什么？状态如何解读为运行阶段？如何在不破坏工作负载的前提下修改 Pod 规格？

NVIDIA Run:ai 团队在构建平台时遇到了这个瓶颈。Alon Lavian（NVIDIA Run:ai 产品经理，负责 Workload Map 的定位与推广）、Yuval Grauer（NVIDIA 工程负责人兼 Workload Map 维护者）和 Ron Lev（NVIDIA 高级软件工程师兼 Workload Map 技术负责人）在 2026 年 11 月的 NVIDIA 技术博客中描述了现状：每新增一个客户带来的框架，就需要另一个适配器；适配器开发因此成为按框架排期的路线图项目，而非一次性成本。这就是为什么新工作负载类型的支持常常要等待一个版本发布。

Workload Map（原名 Karta，CRD 的 kind 仍保留 Karta）提出的方案是将工作负载结构知识从编译型代码迁移为声明式数据。它由一个 Kubernetes CRD 和一个 Go 解释库组成。每份定义用 YAML 描述该工作负载类型的 Pod 模板路径、副本数计算方式和状态字段位置。文章以 JobSet 为例展示了关键部分：根组件通过 jq 表达式将 JobSet 特有的 replicatedJobsStatus 字段翻译为统一的 Running、Completed、Failed 阶段；子组件定义用路径表达式定位每个 replicated Job 的 Pod 模板，并用 replicas 乘以 parallelism 计算实际 Pod 数。

这套定义提供的不只是状态翻译。statusMappings 将各框架截然不同的原生状态映射到统一的 Running、Completed、Failed 词汇——JobSet 不直接报告 Running 条件，定义便用 jq 表达式检查是否有任何 Job 处于 ready 且 active 且无 failed；当 RayJob 或 LeaderWorkerSet 被描述时，它们各自不同的状态字段被映射到相同的共享类别。同时，定义中的路径表达式让消费者提取 Pod 模板、副本数、元数据并理解工作负载层级，还能跨所有实例更新 Pod 规格、标签和注释。消费者工具因此不需要为每种框架编写专用解析逻辑，而是通过同一份结构描述完成检查、调度和管理。

文章展示了同一份 JobSet 定义被三个消费者使用的场景。Workload Map CLI 加载定义后解析集群中的实时对象，输出包含 leader 和 worker 角色、12 个 GPU 总请求的工作负载树。KAI Scheduler 用定义中的 gangScheduling 指令进行 Pod 分组和 gang 准入；对于没有原生插件的工作负载类型，Workload Map 作为 pod grouper 的回退方案提供结构信息，已有原生插件仍保持优先。NVIDIA Run:ai 通过一次 API 调用注册目录定义，将 JobSet 作为单一工作负载管理。此外，多集群调度工具 Elotl Nova 也使用 Workload Map 在集群选择时解读工作负载结构和资源需求。

项目附带一份预构建目录，覆盖 JobSet、PyTorchJob、RayCluster、RayJob、RayService、KServe、Knative、MPIJob、NVIDIA NIM、LeaderWorkerSet、Milvus、Grove PodCliqueSet 和 NVIDIA Dynamo。新工作负载类型通过编写 YAML 定义添加，无需修改消费者代码。Workload Map 以 Apache 2.0 许可开源，已在 NVIDIA Run:ai 生产环境中使用。

需要指出的是，这个方案将成本从编写适配器代码转移到了编写和审查定义数据。jq 表达式对框架 API 版本敏感——如果 JobSet 的 replicatedJobsStatus 结构在后续版本中改变，定义需要同步更新。文章没有报告跨框架的适配器开发时间节省数据，也没有独立第三方对目录定义准确性的验证。对于已经为特定框架编写了原生插件的调度器，Workload Map 仅作为回退方案，不替代已有逻辑。

加拿大供应链规划软件公司 Kinaxis 首席执行官 Razat Gaurav 在西班牙巴塞罗那举行的 Kinexions 2026 大会上宣布，公司将把其核心规划平台“由内而外”翻转，建立一个专门的语义层，使 AI 代理能够协调从感知信号到采取行动的整个供应链流程。这一战略转变旨在解决 Gaurav 所称的供应链中的主要问题：延迟——即从获取信号到做出决策，以及从做出决策到采取行动之间的时间差。

Gaurav 指出，传统的供应链挑战往往被归咎于变化本身，但真正的痛点在于响应速度。他估计，仅库存一项就导致全球供应链中约有 17 万亿美元的商品处于闲置状态。为了缩短这一差距，Kinaxis 计划将其 Maestro 规划系统中编码了数十年的复杂数学模型和约束条件抽象出来，形成一个可扩展的语义本体层。这个层不仅包含 Kinaxis 自己的数据，还将整合仓库管理系统（WMS）、订单管理、ERP 和财务系统等外部记录系统。

这种架构被称为“运营编排”（operational orchestration）。Gaurav 承认，供应链数据分散且没有单一的记录系统，这是现实情况，不会一夜之间改变。然而，新的语义架构结合代理式 AI，使得跨组织边界的协调成为可能。AI 代理可以利用这个语义层理解不同系统中产品、流程和关系的等价性，从而在无需进行繁重定制集成的情况下，将上游的规划决策转化为下游的具体操作指令。

Kinaxis 首席产品官 Andrew Bell 此前解释过，随着供应链变得更加适应性强，这些底层模型的价值日益凸显。现在，公司试图将这些模型置于一个更广泛的平台中心，包括数据织物、代理执行框架和模块化架构。尽管规划仍然是基础，但 Gaurav 强调，将决策连接到行动是获取下一波业务成果的关键。这一举措反映了企业软件行业正在从单纯的预测和规划工具，向能够直接驱动物理世界操作的智能代理平台演进。

美国数据分析软件公司Palantir Technologies Inc.（纳斯达克代码：PLTR）于2026年11月2日发布第三季度财报，显示其业务结构发生历史性转变。本季度，Palantir美国商业收入达到9.84亿美元，同比增长148%，环比增长29%；而美国政府收入为9.53亿美元。这是该公司历史上首次出现美国商业收入规模超过美国政府收入的情况。

整体财务表现同样强劲。第三季度总营收为23.13亿美元，同比增长96%，环比增长20%，单季营收首次突破20亿美元大关。调整后运营利润率为62%，GAAP每股收益为0.44美元。首席执行官Alex Karp在声明中强调，“主权AI”运动正在迫使政府和商业机构快速分化，Palantir的产品组合（包括Foundry、Ontology和AIP）正通过这种需求实现自我改进循环。

基于第三季度的超预期表现，Palantir大幅上调了2026财年指引。公司将全年营收预期从之前的水平提升至85.3亿至85.34亿美元之间，对应约91%的同比增长率。同时，美国商业收入指引被上调至超过35.59亿美元，意味着至少143%的增长速度。这一指引显著高于市场共识，反映了管理层对AI驱动的商业化落地速度的信心。