ARTICLE · 1012317
AI 开发者科技晨报

图:2026 年国家网络安全宣传周网络安全技术高峰论坛现场|来源:新华社
日期:2026 年 09 月 15 日新闻范围:2026 年 09 月 14 日 00:00 ~ 2026 年 09 月 15 日 07:20,北京时间聚焦:AI、开发者生态、科技产业与程序员真正需要关注的变化

昨天没有一场“新模型发布会”占据全部注意力,但几条变化反而更值得开发者看:国内同时更新了 AI 安全治理框架和生成式 AI 备案数据,异构国产算力开始给出跨域混训、混推的实测结果;海外则把模型路由、本地 Agent 和数据留存问题推到了产品层。今天真正值得关注的,是 AI 如何从“模型能力”进入“平台治理与工程约束”。
今天最值得看的 3 件事
1. 《人工智能安全治理框架 3.0》正式发布。新版继续沿用“风险分类、技术应对、综合治理”的逻辑,并针对新的 AI 风险调整分类和治理措施。对 Agent 开发者来说,安全问题已经不能只停留在输入输出审核,而要进入权限、工具、运行时和审计链路。
2. GitHub Copilot Auto 新增 Efficiency、Balance、Intelligence 三档。Copilot 开始允许开发者显式决定“成本、质量、延迟”之间的取舍,再由系统按任务自动挑模型。模型路由正在从隐藏机制变成开发者可配置的工程能力。
3. Perplexity Portable Computer 登陆 Windows RTX。本地 Agent 可以在 PC 上处理敏感文件、调用浏览器和连接器;遇到复杂任务时再询问用户是否升级到云端。Local + Cloud 的混合 Agent 架构开始进入普通桌面工作流。
国内
1. 《人工智能安全治理框架 3.0》发布:AI 安全开始进一步进入系统层

图:2026 国家网络安全宣传周现场的“智能体安全测评与防御”展示|来源:新华社
发生了什么
9 月 14 日,在 2026 年国家网络安全宣传周开幕式上,全国网络安全标准化技术委员会正式发布《人工智能安全治理框架 3.0》。
新版由全国网安标委组织中国网络空间研究院、国家网信办数据与技术保障中心等单位编制,继续沿用“风险分类、技术应对、综合治理”的核心逻辑,同时更新风险分类,并调整技术应对与综合治理措施。
为什么值得关注
AI 系统正在从“生成文本”变成可以调用浏览器、Shell、数据库、企业 API 和真实设备的 Agent。
这时,安全边界已经不只是“模型回答什么”,还包括:
Agent 能调用什么工具; 可以读取哪些数据; 哪些操作必须人工确认; 发生越权或异常时能否终止; 整条执行链能否追溯。
治理框架持续迭代,本身就是一个信号:AI 安全正在从原则问题进入更细的工程问题。
开发者视角
事实:官方披露的是风险分类和治理措施的更新,并没有要求所有开发者立即采用某一种固定技术架构。
开发者判断:对生产级 Agent,建议至少把权限、工具调用、敏感数据、模型版本和执行结果纳入审计日志。
一个可靠的 Agent Runtime,应该把“允许、询问、拒绝”设计成系统能力,而不是只写进 Prompt。
对于 Java / Python 后端,今后 AI 安全很可能越来越像传统 IAM、API Gateway 和审计系统,而不是一个单独的内容审核接口。
接下来值得观察
《框架 3.0》后续是否进一步转化为 Agent、模型服务和高风险 AI 应用的具体标准或测评要求。
来源
国家网信办:《人工智能安全治理框架3.0》发布 新华社:2026 年国家网络安全宣传周开幕
2. 国家网信办更新生成式 AI 备案:两个月新增 124 款服务,端侧模型开始单独出现

图:2026 国家网络安全宣传周技术展区|来源:新华社
发生了什么
国家网信办 9 月 14 日发布 2026 年 7 月至 8 月生成式人工智能服务备案信息。
两个月内:
新增 124 款生成式人工智能服务完成国家备案; 其中包括 7 款手机端侧生成式 AI 服务; 通过 API 或其他方式直接调用已备案模型的应用或功能,新增 133 款完成地方登记; 截至 8 月 31 日,累计 1112 款生成式 AI 服务完成备案; 累计 731 款生成式 AI 应用或功能完成登记。
官方同时要求,已经上线的生成式 AI 应用或功能,应在显著位置或产品详情页面公示所使用的已备案或登记服务情况,并注明模型名称、备案号或上线编号。
为什么值得关注
这一条对国内 AI 应用开发者非常实际。
现在越来越多应用通过 Model Router 动态切换模型,但合规披露要求意味着:
实际使用哪个模型,不再只是后端配置问题。
如果生产环境从模型 A 切到模型 B,产品端的模型名称、备案信息和上线编号也可能需要同步变化。
另外,官方这次明确把 7 款“手机端侧生成式 AI 服务”单独列出,说明端侧模型已经不再只是纯硬件能力,而开始进入正式的治理和备案视野。
开发者视角
建议 AI 产品把以下信息从“写死在前端文案”改为可配置元数据:
Provider; Model ID; 对外模型名称; 备案号 / 上线编号; 是否端侧; 数据处理区域; 当前启用状态; 生效时间。
如果系统存在多模型路由,这些字段最好和模型注册表、发布流程联动。
数据库设计和配置中心开始直接参与 AI 合规。
接下来值得观察
端侧模型备案数量是否持续增加,以及模型动态路由、模型升级和灰度切换对应的披露规则会不会进一步细化。
来源
国家网信办:2026 年 7 月至 8 月生成式人工智能服务已备案信息
3. 湖南大学 + 上海 AI 实验室:跨域异构算力混训等效算力达到单集群 95% 以上
发生了什么
9 月 14 日,湖南大学公布其与国家超级计算长沙中心、上海人工智能实验室等团队的跨域异构算力成果。
方案以上海 AI 实验室DeepLink多元算力跨域训推方案为核心,结合湖南大学“曦算”调度平台,实现跨地域、跨厂商、跨架构的模型训练和推理部署。
项目方披露:
大模型跨域混训的等效算力可达到单集群 95% 以上; 在多款国产芯片上的异构混推吞吐提升 30% 以上; 已用于湖南省算力调度平台、马栏山 V 谷及国家超算互联网等场景。
为什么值得关注
国产算力真正难的从来不只是“有没有 GPU”。
当不同厂商、不同架构、不同地域的卡同时存在以后,真正难的是:
怎么把它们变成一个可用的资源池。
跨域训练要处理通信、模型切片和网络瓶颈;异构推理要解决算子兼容、流量路由、资源调度和不同芯片性能差异。
这已经是一个典型的分布式系统问题。
开发者视角
事实:95% 和 30% 以上是项目方公开的数据,目前不应直接视作适用于所有模型和硬件组合的通用结论。
开发者判断:这条路线比单纯比较国产卡 FLOPS 更有实际价值。
以后评估国产推理平台,建议同时记录:
模型兼容度; 跨卡通信开销; TTFT; TPOT; P95 / P99; tokens/s; 故障迁移; 单任务成本。
推理平台的核心能力,正在从“能启动模型”变成“能调度一组异构资源”。
接下来值得观察
DeepLink 与“曦算”后续会开放多少标准接口,以及 vLLM、SGLang 等主流推理栈能否更顺畅地接入国产异构算力。
来源
湖南大学:异构算力调度技术获 2026“算力中国·年度重大突破成果”奖
4. 支付宝披露 AI 支付累计突破 3 亿笔,Agent 开始真正“替用户花钱”

图:2026 Inclusion·外滩大会现场|来源:央广网 / 解放日报
发生了什么
9 月 14 日发布的外滩大会复盘文章进一步披露了支付宝 AI 支付的实际规模。
支付宝目前已经形成 TokenPay、AI 付、AI 收等能力。公开数据称:
支付宝 AI 支付累计交易笔数已突破 3 亿,覆盖超过 95% 的通用智能体场景。
会上还多次讨论智能体商业信任协议 ACT,以及 KYA(Know Your Agent,了解你的智能体)的概念。
蚂蚁数科 Agentar 2.0 则预置了近200 个岗位级数字专家模板和数百个技能工具包。

图:外滩大会智能体商业应用体验区,现场展示智能体从服务到支付的业务闭环|来源:央广网
为什么值得关注
只要 Agent 能调用支付,系统设计就发生了质变。
过去 Agent 失败,大多数时候只是“回答错”。
支付 Agent 失败可能变成:
真的花错钱。
因此支付型 Agent 的核心能力不会只是 Tool Calling,而必须包含:
身份、授权、额度、风控、可撤销、人工确认、审计和争议处理。
开发者视角
这类系统可以参考传统支付架构,而不是把模型输出直接转成交易指令。
推荐的思路是:
模型负责理解意图 → Policy Engine 校验权限与额度 → 支付工具执行 → 审计系统记录 → 高风险操作二次确认。
也就是说:
LLM 可以做决策建议,但资金边界必须是确定性的。
从工程上看,Agent Commerce 最终很可能和 OAuth Scope、支付风控、IAM、工作流审批深度融合。
接下来值得观察
ACT、KYA 等智能体商业规范能否形成跨平台协议,以及 Agent 支付的授权撤销、责任认定和审计标准如何落地。
来源
央广网:从上海出发,AI 新经济正起步
海外
5. GitHub Copilot Auto 新增三档策略:模型路由开始允许开发者控制“成本—质量”取舍
发生了什么
GitHub 9 月 14 日更新 Copilot Auto model selection。
Auto 现在提供三个策略档位:
Efficiency:优先低成本,适合简单、快速任务; Balance:同时权衡成本、质量和延迟; Intelligence:更偏向质量,面向复杂任务。
三个档位使用同一个可用模型池,但 Copilot 会针对每个 Prompt 重新判断该使用哪个模型。
该能力正在 VS Code、Copilot CLI 和 GitHub Copilot App 中陆续推出。
费用仍按照实际被 Auto 选中的模型计算;GitHub 表示,付费用户通过 Auto 计费时继续获得 10% 折扣。
为什么值得关注
这是一个比“新增某个模型”更长期的变化。
AI Coding 正在进入Model Routing阶段。
对用户来说,任务是:
“帮我补一段注释。”
或者:
“帮我修一个跨 20 个模块的并发 Bug。”
平台不再要求用户每次都知道 GPT、Claude、MAI 或其他模型哪个更适合,而是把任务复杂度、可用性、延迟和成本一起纳入路由。
开发者视角
这套逻辑同样值得企业 AI 平台借鉴。
业务代码最好不要直接写:
某业务 = 某一个固定模型。
更合理的是定义:
任务类型 + 质量要求 + 延迟预算 + 成本预算 + 数据策略。
然后让 Model Router 决定实际 Provider 和 Model ID。
最终应该比较的是:
Cost per Successful Task,单位成功任务成本。
而不是只比较每百万 Token 单价。
接下来值得观察
GitHub 是否会进一步开放企业级策略,例如给不同 Repository、团队或 Agent 设置不同 Auto 路由规则。
来源
GitHub 官方:Configure cost and quality in Copilot auto model selection GitHub 中文文档:Copilot Auto model selection
6. 微软发布 37 页 Humanist AI 行为准则:模型必须服从人类控制

图:Microsoft AI 发布 Humanist AI Code of Conduct 草案|图片国内镜像:新浪新闻;原始内容来源:Microsoft AI
发生了什么
Microsoft AI 9 月 14 日发布 Humanist AI Code of Conduct 第一版草案,并开启6 周公众咨询。
微软明确说明:
这份文件目前还没有用于训练模型; 计划在今年年底根据反馈发布修订版; 后续将用于指导 2027 年及之后的 MAI 模型开发; 核心原则是“人比 AI 更重要”,AI 必须保持在人类有意义的控制之下; AI 不被视为具有意识,也不应被设计为模仿意识; Safety Constraints 的优先级高于普通用户或 Operator 的要求,不能被任意覆盖。
为什么值得关注
这份文件最值得开发者看的,不是哲学争论,而是它把 AI 行为约束明确分成了:
目标、硬性安全约束、操作规则和默认行为。
这与生产 Agent 的工程架构非常接近。
开发者视角
Prompt 不能承担所有安全责任。
例如:
“不要删除数据库。”
这只是一句话。
生产系统真正应该做的是:
Agent 默认没有危险数据库权限; DELETE / DROP 类操作进入独立策略检查; 高风险动作要求 Human Approval; 所有 Tool Call 留下可审计记录; Runtime 能直接终止任务。
Probabilistic Model + Deterministic Guardrail会成为越来越重要的架构原则。
需要强调:
这份微软文件目前是公开征求意见的草案,不是法律,也还没有成为 MAI 模型当前的训练规则。
接下来值得观察
微软年底修订版会如何变化,以及这些“行为准则”最终如何落到模型训练、运行时控制和产品权限上。
来源
Microsoft AI:Humanist AI Code of Conduct Microsoft AI:Public consultation 新浪新闻:微软发布 AI 行为准则
7. Perplexity Portable Computer 登陆 Windows RTX:本地 Agent 与云端 Agent 开始融合

图:Perplexity Portable Computer 在 NVIDIA RTX 平台运行|图片国内源:腾讯新闻;技术信息来源:NVIDIA / Perplexity
发生了什么
9 月 14 日,Perplexity Portable Computer 开始支持 Windows RTX PC。
它是 Perplexity Computer 的本地版本,可以在设备上:
分析本地文件; 执行多步骤任务; 使用内置浏览器; 使用 SPACE 沙箱; 连接 Outlook、OneDrive、Word、Google Drive、Gmail、Slack 和 GitHub。
NVIDIA 官方介绍中还提到,应用可以使用经过 Perplexity Computer 后训练、针对 RTX 优化的Qwen 3.8 27B等本地模型。
遇到需要更强推理的任务时,Agent 可以建议调用云端模型,但在把信息传出设备之前会先征求用户授权。
当前 Windows 版本要求兼容的 GeForce RTX 或 RTX PRO,并需要24GB 或更多显存。
为什么值得关注
这个产品把 Agent 架构里长期存在的矛盾做得很直观:
敏感数据希望留在本地,但复杂推理又希望使用云端大模型。
于是系统变成:
Local Agent 处理数据与普通任务 → 判断能力不足 → 请求用户授权 → Cloud Model 处理高难度任务。
开发者视角
这类架构特别适合:
企业代码; 本地文档; 财务文件; 医疗资料; 内网知识库; 桌面自动化。
如果自己设计类似系统,关键不是简单做一个 local / cloud 开关,而是建立数据分类和出域策略。
例如:
文件可以完全不出设备; 摘要允许出设备; PII 必须脱敏; Credential 永远禁止上传; 云端升级必须显式授权。
这实际上是一个Policy-aware Model Router。
接下来值得观察
本地模型在长时间 Coding、浏览器自动化和多工具任务中的成功率,以及 24GB 显存门槛能否进一步下降。
来源
NVIDIA:Perplexity Portable Computer Is Now Available on Windows, Powered by NVIDIA RTX IT之家:Perplexity Portable Computer 向 Windows RTX PC 开放
8. Palantir、NVIDIA 被曝收紧部分模型使用:企业开始把“数据留存”变成模型准入条件

图:国家网络安全宣传周现场的超节点服务器展示,用于说明企业 AI 基础设施的数据与安全边界|来源:新华社
发生了什么
Reuters 9 月 14 日援引 The Information 报道称,Palantir、NVIDIA、Booz Allen Hamilton 等企业正在因为数据安全和知识产权问题,重新限制部分高级 AI 模型的使用。
报道声称:
Palantir 正要求 Anthropic 提供不可撤销的 Zero Data Retention 承诺; NVIDIA 将 Anthropic 模型限制在相对不敏感的任务中; Booz Allen 禁止员工在专有网络安全工作中使用 Anthropic 商业模型。
这里必须明确:
这些细节来自 The Information 的报道,并未得到涉及企业的完整公开确认,因此应视作媒体报道,而不是各方共同确认的官方事实。
为什么值得关注
即使具体公司的谈判内容后续发生变化,这类争议暴露的问题是真实存在的:
当企业使用多个外部模型时,真正的问题已经不只是“哪个模型最聪明”,而是:
请求是否会被留存; 留存多久; 是否用于训练; 数据在哪个区域; 是否会经过第二个 Provider; 谁拥有日志; 是否允许删除; 是否满足企业合同要求。
开发者视角
企业 AI Gateway 应该逐渐把这些信息变成机器可执行的策略,而不是写在采购合同里以后就不管。
建议模型注册表至少维护:
Provider; Model; Data Retention; Training Opt-out; Region; PII Allowed; Secret Allowed; Allowed Business Domains。
当请求包含源码、客户数据、密钥或内部文档时,Router 应该先检查数据策略,再选择模型。
这也是为什么未来 Model Router 很可能同时也是Policy Engine。
接下来值得观察
头部模型供应商是否会把 Zero Data Retention、Customer-managed Storage 和数据区域控制变成更标准化的 API / 企业能力。
来源
Reuters:Palantir, Nvidia curb AI model use over data fears
今日开发者观察

图:2026 国家网络安全宣传周网络安全技术展区|来源:新华社
今天这些新闻放在一起,我认为最明显的变化是:Model Router 正在变成 AI 系统的控制平面。
GitHub Copilot 已经开始公开让用户选择 Efficiency、Balance 和 Intelligence;Perplexity 则在本地模型与云端模型之间根据任务能力和数据边界做路由;国内生成式 AI 备案要求,又让“实际调用哪个模型”与产品合规信息直接绑定;企业对数据留存的担忧,则进一步要求 Router 知道一个模型的数据政策。
所以未来的 Model Router 不会只是:
请求 → 选择最便宜的模型。
它更可能同时考虑:
质量、成本、延迟、地区、数据敏感级别、备案状态、留存策略、上下文长度和工具能力。
另一条趋势来自安全。
中国的《人工智能安全治理框架 3.0》和微软 Humanist AI Code 虽然一个是治理框架、一个是企业行为准则,但在工程上都指向同一个方向:
模型能力越强,系统级约束越重要。
模型可以负责理解、规划和生成,但真正不可违反的规则,应该落在 Runtime、Policy Engine、IAM、Sandbox 和 Audit 上。
这对传统后端开发者其实是一个明显信号。
过去熟悉的权限、配置中心、审计日志、任务调度、数据分级、幂等、超时和故障恢复,并没有被大模型淘汰。Agent 进入生产以后,它们反而正在成为 AI 系统可靠性的核心。
对开发者有什么实际影响
可以马上关注
1. 给自己的模型调用层增加 Model Registry
不要只保存模型名称。
至少补上 Provider、成本、能力、数据留存策略、区域、备案信息和当前状态。
如果以后需要切模型,这一层会直接减少业务代码改动。
2. 测一下 GitHub Copilot 三档 Auto 策略
不要只测试简单补全。
建议拿三种真实任务比较:
简单文档 / 小修改; 普通 Bug 修复; 跨模块复杂任务。
记录总耗时、最终成功率、人工修改量和费用。
3. 检查 Agent 的高风险 Tool
如果 Agent 可以调用:
数据库、Shell、文件系统、浏览器、支付 API 或内部管理接口,
今天就值得检查权限是不是由 Runtime 强制,而不是只依赖 Prompt。
4. 检查国内 AI 应用的模型披露信息
如果产品已经上线,确认模型名称、备案号 / 上线编号是否与实际生产路由一致。
尤其是使用多模型 Gateway 的产品。
5. 本地 Agent 可以开始做真实隐私场景测试
如果有 24GB 及以上 RTX,可以关注 Portable Computer 这类 Local + Cloud 路线。
真正值得测的是:
敏感文件是否真的可以不离开设备,以及云端升级的边界是否足够清晰。
暂时不用管
不要把异构算力的“95% / 30%”直接变成采购结论
这是项目方在特定平台和场景下公布的结果。
没有统一硬件配置、模型、输入输出长度和并发条件时,不能直接横向比较。
微软 Humanist AI Code 暂时不是合规法规
它目前仍是公开征求意见的草案,而且微软明确表示当前没有用它训练模型。
它值得研究架构思想,但不需要因为这份文件立即修改所有系统。
不要因为 Perplexity 上了本地 Agent,就把所有 AI 迁回本地
本地运行可以提高数据控制,但会牺牲模型能力、显存资源、运维成本和部分工具生态。
更值得研究的是Local + Cloud Hybrid,而不是二选一。
企业数据留存争议暂时不要只看公司站队
Palantir、NVIDIA 等细节目前主要来自媒体报道。
真正应该今天检查的是你自己系统里的数据流向。
长期趋势
几个月:Model Router 从成本路由升级成策略路由
未来模型选择会同时考虑:
质量 + 延迟 + 成本 + 合规 + 数据安全 + 能力。
AI Gateway 会越来越像 API Gateway 和 IAM 的结合体。
一年:Local + Cloud Agent 会快速增加
PC、手机、车机和企业工作站都会具备越来越强的本地模型。
敏感数据留在设备,复杂推理按需进入云端,会成为非常自然的架构。
一到两年:AI 合规元数据进入软件工程流程
模型 ID、备案号、版本、数据区域、Retention Policy 等字段,会越来越像今天的软件版本和依赖许可证。
它们需要进入:
数据库、配置中心、CI/CD、发布审批和审计系统。
更长期:国产算力竞争会从“单卡”进入“调度系统”
当多厂商 GPU / NPU 长期共存,真正决定资源利用率的会是:
编译器、通信、Scheduler、Runtime 和 Model Serving。
这也是为什么异构算力调度比单纯公布一块新芯片更值得开发者长期关注。
写在最后
今天没有一个必须让所有开发者立刻迁移的新模型,但反而出现了几条更接近生产环境的变化。
模型路由开始考虑成本和质量,本地 Agent 开始处理数据边界,国内备案开始进入端侧模型,安全治理则越来越强调系统性约束。
这些事情共同指向一个很现实的结论:
AI 开发正在从“怎么把模型调通”,进入“怎么把模型管好”。
未来真正成熟的 AI 系统,不只要知道哪个模型更聪明,还必须知道它能访问什么、数据去了哪里、花多少钱、出了问题怎样终止,以及整个过程能不能被追溯。
对于开发者来说,这些能力可能没有 Benchmark 那么显眼,但它们更接近真正可以长期运行的软件。

图:国家网络安全宣传周现场的网络安全机器人展示|来源:新华社
模型继续变强,真正拉开差距的会是控制模型的工程系统。