2026年7月9日每日关注：Codex、26H2与AI Agent企业趋势

🔥 个人主页： 杨利杰YJlio

❄️ 个人专栏： 《Windows 疑难杂症与工单复盘案例库》     《Sysinternals实战教程》

《WINDOWS教程》     《Windows PowerShell 实战》     《人工智能实战合集》

《超简单：用Python让Excel飞起来》

🌟 让复杂的事情更简单，让重复的工作自动化

2026年7月9日每日关注：Codex、26H2与AI Agent企业趋势

2026年7月9日每日关注：Codex、26H2与AI Agent企业趋势

• 2026年7月9日每日关注：Codex、26H2与AI Agent企业趋势
• 一、今天最值得关注的不是某个模型，而是工作方式正在变化
• 二、AI Agent 已经从聊天工具走向工作执行
• 三、Codex 企业化之后，最重要的不再是功能数量
• 四、Windows 11 26H2：企业不应该等正式推送后再开始验证
• 五、本地部署重新变得重要，不能只看模型参数
• 六、桌面运维必须从“感觉卡”走向性能证据
• 七、运维自动化要从一段脚本升级成完整流水线
• 八、知识资产才是模型快速迭代时代最值得保留的东西
• 九、从模型竞争到工作流竞争，个人真正应该升级什么
• 十、总结：今天的七条新闻，最终指向同一个方向

一、今天最值得关注的不是某个模型，而是工作方式正在变化

  最近一段时间，我越来越明显地感受到一个变化：真正值得长期关注的，已经不是“哪个模型又提升了多少分”，而是 AI Agent、Codex、Windows 本地 AI、企业自动化和知识库开始进入同一条技术主线。

  对于桌面运维、系统排障、自动化脚本和企业 IT 管理来说，这个变化非常实际。过去我们面对一个问题，通常是人工判断 → 找工具 → 执行操作 → 验证结果 → 手工记录；现在更值得研究的是，能不能让 Agent 接收任务，让脚本执行标准动作，让性能工具采集证据，最后自动形成报告和知识资产。

  所以今天这份简报，我更想讨论的不是七八条新闻本身，而是它们共同指向的结果：模型正在变成执行者，操作系统正在吸收 AI 能力，企业正在重新重视本地算力，而个人真正应该沉淀的是可复用工作流。

  对我个人来说，这也是为什么我会同时关注 Codex、Windows 11 26H2、PowerShell、PerfMon、WPA 和本地 AI。表面看这些方向很分散，实际上它们正在汇合：让机器承担重复执行，让人负责判断、边界和结果验收。

二、AI Agent 已经从聊天工具走向工作执行

  过去使用 AI，大多数人的动作是打开一个聊天窗口，问一个问题，得到一段回答，然后结束。这个模式本质上还是“问答”。而 Agent 的变化在于：任务不再要求一次回答完，它可以持续运行、调用工具、处理中间结果，并根据执行情况继续迭代。

  OpenAI 在 2026 年 6 月发布的研究中提到，到 2026 年 5 月，样本中的个人用户里有 80.6% 至少提交过一次预计需要人类超过 30 分钟完成的任务，70.2% 至少提交过一次超过 1 小时的任务，25.6% 至少提交过一次超过 8 小时的任务。到 2026 年 6 月，最高使用强度的一部分用户已经通过多个并行 Agent，在一天内累计生成超过 60 小时的代理执行时间。 :contentReference[oaicite:1]{index=1}

  这组数据真正值得注意的，不是“使用量很大”，而是AI 的工作单位发生了变化。从前是一次提示词对应一次回答，现在开始变成一个目标对应一段持续执行过程。

  对于实际工作，我认为最值得优先 Agent 化的，不是那些偶尔才发生一次的复杂任务，而是高频、规则相对清晰、有固定输入输出、可以验证结果的工作。

  例如在桌面运维场景中，可以逐步把以下链路固化下来：收到故障描述后提取关键词，判断需要采集哪些日志，调用 PowerShell 或 Sysinternals 工具执行检查，再根据结果生成排查摘要。对于性能问题，则可以进一步连接 PerfMon、应用启动计时、进程资源数据和报告模板。

  我的建议是：不要急着追求“一个超级 Agent 什么都做”，而是先做几个职责非常清楚的小型长期 Agent，例如 Windows 故障诊断、性能分析、技术内容整理和标准文档检查。

三、Codex 企业化之后，最重要的不再是功能数量

  很多人看 Codex，首先想到的是写代码。但从企业真正落地的角度，我更关心的是另外几个问题：它能不能稳定执行？谁有权限调用？执行了什么？失败后怎么回滚？结果能不能审计？

  OpenAI 公布的数据已经说明，Codex 的使用范围正在明显超出传统开发岗位。公司内部的法务、财务和招聘团队大约在 2026 年 4 月前后也进入以 Codex 为主要 AI 工作工具的阶段；研究岗位的中位使用量相比 2025 年 11 月增长约 56 倍，法务岗位达到约 13 倍。 :contentReference[oaicite:2]{index=2}

  这意味着，企业内部真正的竞争点开始从“谁会写更长的提示词”，转向谁能把 AI 接进真实业务流程，同时保留权限、日志、责任和失败处理机制。

  我认为一个真正能进入企业环境的 AI 自动化流程，至少应该具备四个基础条件：有明确的输入边界、有完整的执行日志、有权限分级，还有失败后的回滚或人工接管路径。

  风险在于：如果只是把一个高权限脚本直接交给 Agent 执行，却没有输入校验、日志、超时、权限隔离和回滚，那么自动化能力越强，故障影响范围反而可能越大。

  所以我现在越来越认同一个工程判断：企业 AI 最重要的不是“聪明”，而是可控、可查、可停、可恢复。

四、Windows 11 26H2：企业不应该等正式推送后再开始验证

  对于普通个人用户，系统升级可能只是点击一次 Windows Update。但在企业环境里，一个版本升级会同时碰到 EDR、终端管理软件、浏览器、Office、打印机、驱动、共享资源、开发环境和自动化脚本。

  微软已经确认，Windows 11 26H2 延续近年版本的共享服务模式。对于已经运行较新版本 Windows 11 的设备，升级可以通过较小的启用包完成，而不是重新进行完整操作系统替换；同时，26H2 已进入 Windows Insider 的 Experimental 渠道进行预览。 :contentReference[oaicite:3]{index=3}

  升级方式更轻，不等于企业验证可以省略。恰恰因为升级成本变低，企业更应该提前建立固定验证清单，让每次系统大版本更新都进入同一套测试流程。

  真正高质量的企业验证，不应该停留在“能打开就算通过”。更合理的标准应该是：功能正常、性能无明显退化、日志无新增高风险异常、脚本可回归、出现问题能够回退。

  另一方面，Windows 本身也正在把 AI 能力继续下沉到系统层。微软的 Windows ML 已经提供统一的本地 AI 推理框架，并基于 ONNX Runtime 在设备端调用 NPU、GPU 和 CPU 执行模型推理；相关 Windows AI APIs 也在支持符合条件的 Windows 设备直接运行本地模型。 :contentReference[oaicite:4]{index=4}

  这对桌面运维意味着，未来排查问题时不能只看传统的 CPU 和内存。越来越多设备还需要考虑 NPU 调度、本地模型、AI 运行时、驱动和安全软件之间的兼容关系。

五、本地部署重新变得重要，不能只看模型参数

  AI 早期最容易形成一种思维：模型越大越好，全部放云端最方便。但企业真实场景里，还存在另外几个不能忽略的问题——数据能不能离开本地、推理延迟是否稳定、长期调用成本是否可接受、网络中断后业务还能不能运行。

  因此，本地模型、边缘推理和混合部署的价值正在重新上升。微软已经明确支持通过 Windows ML 在本地设备使用 CPU、GPU 和 NPU 加速推理；同时，AI 基础设施和数据中心也已经成为整个行业竞争中的核心议题。 :contentReference[oaicite:5]{index=5}

  所以以后比较一台机器是否适合 AI，不应该只问“显卡型号是什么”，而应该同时看显存容量、模型量化支持、推理吞吐、驱动稳定性、框架兼容性、功耗和持续负载表现。

  对于 Windows 用户尤其如此。硬件理论算力高，不代表真实业务一定快。最终还要看 CUDA、DirectML、ONNX Runtime、模型格式、显存占用和具体软件支持情况。

  更实际的选择方式是：先确定自己要运行什么模型、需要多大显存、是否长期满载，再决定硬件，而不是先买显卡，再想能做什么。

六、桌面运维必须从“感觉卡”走向性能证据

  企业桌面环境里最难处理的一类问题，往往不是蓝屏，也不是明确报错，而是用户一句：“电脑就是很卡。”

  如果没有数据，这个问题很容易陷入争论。是 EDR 占用？是内存不够？是磁盘延迟？是浏览器标签过多？是电源策略？还是某个应用启动后持续后台扫描？靠任务管理器看一眼，很难形成可靠结论。

  所以我越来越倾向于把性能问题拆成固定证据链：应用启动耗时、CPU 峰值与均值、可用内存、提交内存、分页、磁盘响应时间、进程私有工作集、磁盘 I/O，再结合具体操作步骤复现。

  只有进入这种数据化方式以后，性能排查才真正具备可比较性。例如同一台设备可以设计四组环境：无安全软件、仅终端接入软件、仅 EDR、两者同时安装，再执行完全相同的办公负载。

  这样得到的结论不再是“感觉某个软件拖慢了电脑”，而可以变成：在哪个步骤出现差距、差多少、对应哪个进程、主要压力来自 CPU、内存还是磁盘。

  性能分析最核心的价值，不是采集更多指标，而是建立“同设备、同任务、同条件、可重复”的对照实验。

七、运维自动化要从一段脚本升级成完整流水线

  很多运维自动化最初都从一个 BAT 或 PowerShell 脚本开始，这没有问题。但当脚本真正进入批量使用以后，就必须开始考虑更完整的工程问题。

  例如一个自动化初始化流程，不应该只是连续执行安装命令，而应该至少包含：环境检查、网络检查、软件部署、用户配置、日志记录、异常重试、结果验证和失败退出。

  同样，一套性能测试工具也不应该只负责启动 PerfMon。更完整的链路应该是固定操作步骤、自动计时、性能采集、文件命名、测试组区分、数据汇总和报告输出。

  我认为自动化成熟度可以简单分成四个阶段：

  第一阶段：能自动执行。

  第二阶段：执行过程有日志。

  第三阶段：失败能够识别、退出或回滚。

  第四阶段：同一套流程可以被人、脚本或 Agent 重复调用。

  真正有长期价值的是第四阶段，因为到了这里，脚本已经不再属于某一次任务，而是变成了可以持续复用的能力模块。

八、知识资产才是模型快速迭代时代最值得保留的东西

  模型会更新，产品入口会变化，今天习惯的提示词甚至可能几个月后就不再重要。但一套经过真实项目验证的故障处理流程、一份完整性能测试方法、一套标准化部署脚本，却可以长期复用。

  对技术人员来说，我认为真正应该沉淀的不是“我问过 AI 什么”，而是以下内容：

  第一，问题输入怎么标准化。第二，需要采集哪些证据。第三，判断规则是什么。第四，什么操作可以自动执行。第五，什么情况必须人工确认。第六，结果如何验证。第七，最后如何沉淀成 SOP、脚本、模板或知识库。

  以我现在关注的方向为例，最值得长期建设的至少包括三类资产：Windows 企业运维知识库、性能测试与故障证据库、CSDN 内容创作与发布工作流。

  其中 Windows 运维知识库不应该只是收藏文章，而应该按“现象 → 环境 → 证据 → 原因 → 解决方案 → 验证结果”沉淀；性能测试也不应该只保存一个 BLG 文件，而应该把测试脚本、负载步骤、原始数据和最终判断关联起来。

  真正长期保值的，不是某一条 Prompt，而是 Prompt 背后的判断规则、数据标准和执行流程。

九、从模型竞争到工作流竞争，个人真正应该升级什么

  如果把今天这些信息连起来，我认为可以得到一个非常明确的判断：未来个人与企业之间的差距，不一定首先来自“谁能使用最新模型”，而更可能来自“谁先建立起自己的知识库、Agent 和工作流体系”。

  模型本身会越来越普及，但高质量业务知识不会自动生成。一个模型不知道你的企业装了什么 EDR，不知道哪类打印机经常出问题，不知道你的部署脚本有哪些历史兼容问题，也不知道什么性能阈值才算真正异常。

  这些都必须通过真实实践逐步沉淀。

#mermaid-svg-N1UmMFaXL9uxYCZm{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-N1UmMFaXL9uxYCZm .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-N1UmMFaXL9uxYCZm .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-N1UmMFaXL9uxYCZm .error-icon{fill:#552222;}#mermaid-svg-N1UmMFaXL9uxYCZm .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-N1UmMFaXL9uxYCZm .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-N1UmMFaXL9uxYCZm .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-N1UmMFaXL9uxYCZm .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-N1UmMFaXL9uxYCZm .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-N1UmMFaXL9uxYCZm .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-N1UmMFaXL9uxYCZm .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-N1UmMFaXL9uxYCZm .marker{fill:#333333;stroke:#333333;}#mermaid-svg-N1UmMFaXL9uxYCZm .marker.cross{stroke:#333333;}#mermaid-svg-N1UmMFaXL9uxYCZm svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-N1UmMFaXL9uxYCZm p{margin:0;}#mermaid-svg-N1UmMFaXL9uxYCZm .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-N1UmMFaXL9uxYCZm .cluster-label text{fill:#333;}#mermaid-svg-N1UmMFaXL9uxYCZm .cluster-label span{color:#333;}#mermaid-svg-N1UmMFaXL9uxYCZm .cluster-label span p{background-color:transparent;}#mermaid-svg-N1UmMFaXL9uxYCZm .label text,#mermaid-svg-N1UmMFaXL9uxYCZm span{fill:#333;color:#333;}#mermaid-svg-N1UmMFaXL9uxYCZm .node rect,#mermaid-svg-N1UmMFaXL9uxYCZm .node circle,#mermaid-svg-N1UmMFaXL9uxYCZm .node ellipse,#mermaid-svg-N1UmMFaXL9uxYCZm .node polygon,#mermaid-svg-N1UmMFaXL9uxYCZm .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-N1UmMFaXL9uxYCZm .rough-node .label text,#mermaid-svg-N1UmMFaXL9uxYCZm .node .label text,#mermaid-svg-N1UmMFaXL9uxYCZm .image-shape .label,#mermaid-svg-N1UmMFaXL9uxYCZm .icon-shape .label{text-anchor:middle;}#mermaid-svg-N1UmMFaXL9uxYCZm .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-N1UmMFaXL9uxYCZm .rough-node .label,#mermaid-svg-N1UmMFaXL9uxYCZm .node .label,#mermaid-svg-N1UmMFaXL9uxYCZm .image-shape .label,#mermaid-svg-N1UmMFaXL9uxYCZm .icon-shape .label{text-align:center;}#mermaid-svg-N1UmMFaXL9uxYCZm .node.clickable{cursor:pointer;}#mermaid-svg-N1UmMFaXL9uxYCZm .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-N1UmMFaXL9uxYCZm .arrowheadPath{fill:#333333;}#mermaid-svg-N1UmMFaXL9uxYCZm .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-N1UmMFaXL9uxYCZm .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-N1UmMFaXL9uxYCZm .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-N1UmMFaXL9uxYCZm .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-N1UmMFaXL9uxYCZm .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-N1UmMFaXL9uxYCZm .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-N1UmMFaXL9uxYCZm .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-N1UmMFaXL9uxYCZm .cluster text{fill:#333;}#mermaid-svg-N1UmMFaXL9uxYCZm .cluster span{color:#333;}#mermaid-svg-N1UmMFaXL9uxYCZm div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-N1UmMFaXL9uxYCZm .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-N1UmMFaXL9uxYCZm rect.text{fill:none;stroke-width:0;}#mermaid-svg-N1UmMFaXL9uxYCZm .icon-shape,#mermaid-svg-N1UmMFaXL9uxYCZm .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-N1UmMFaXL9uxYCZm .icon-shape p,#mermaid-svg-N1UmMFaXL9uxYCZm .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-N1UmMFaXL9uxYCZm .icon-shape .label rect,#mermaid-svg-N1UmMFaXL9uxYCZm .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-N1UmMFaXL9uxYCZm .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-N1UmMFaXL9uxYCZm .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-N1UmMFaXL9uxYCZm :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

关注技术变化

判断是否影响真实工作

隔离环境测试验证

采集兼容性与性能证据

固化脚本和 Agent 能力

沉淀知识库与 SOP

形成可复用工作流

  这条链路里，模型只是其中一个组件。真正形成竞争力的是：你有没有自己的验证环境、有没有真实数据、有没有经过复盘的案例、有没有稳定脚本、有没有权限边界、有没有办法把一次经验变成下一次可以直接调用的能力。

  所以我给自己下半年的技术方向也非常明确：继续做 Windows 故障案例复盘，继续把性能测试标准化，继续把重复运维动作脚本化，同时开始思考哪些流程可以进一步交给 Agent。

  需要避免的是：不断更换模型、不断收藏 Prompt、不断试新工具，却没有任何可以复用的资产留下来。

  真正值得追求的状态是：知识可以检索，流程可以复用，脚本可以执行，Agent 可以调用，结果可以验证，失败可以追踪。

十、总结：今天的七条新闻，最终指向同一个方向

  AI Agent 正在从聊天走向持续执行，Codex 的价值正在从开发工具扩展到更广泛的知识工作，Windows 11 26H2 提醒企业提前建立兼容性验证体系，Windows ML 和本地 AI 能力又让 NPU、GPU、模型运行时进入新的桌面运维边界。

  但对个人来说，我认为最重要的结论反而最简单：

  不要只积累答案，要积累判断规则。

  不要只保存脚本，要建立执行流程。

  不要只追模型，要建立自己的知识资产。

  当知识库、自动化脚本、性能证据、标准流程和 Agent 真正连接起来以后，AI 才不再只是一个聊天窗口，而会逐步成为实际工作系统的一部分。

🔝 返回顶部

点击回到顶部