阿里云电力 AI 调研（七）：横向能力——Agent 工程化的五个关键设计与成熟度天花板

本系列共八篇，逐环节拆解阿里云在电力行业「发、输、变、配、用」的 AI 与 Agent 落地现状。 全部结论标注信源等级：A 官方（阿里云/客户官网、官方技术博客）、B 权威媒体 / 行业白皮书 / 信通院、C 厂商 PR 稿或会议演讲、D 二手转载（仅作线索）。 本系列刻意区分「已投产」与「方案宣传」，并对厂商口径保留独立判断。

前六篇按「发、输、变、配、用」逐环节拆完了阿里云在电力行业的落地。六篇读完得到的是一堆互不相干的印象——山东的调度智慧大脑、广东的计量设备 AI 指挥官、冀北的操作票校验、浙江的 AI 评标、国家管网的管输路径智能体。并排放置后能看到一个更值得写的事实：它们共用同一套技术底座（飞天企业版 + 百炼专属版），也共用同一套 Agent 工程方法论——大小模型协同、图模融合、确定性校验、人机责任边界。单看某一项目只是「某省电力的某次试点」，横向看，它们才是真正可复制的那部分资产。

第二层动机是祛魅。电力 AI 材料里，「百余个智能体」「自学习自优化」这类表述密度极高，但它们描述的是规模与路线图，不是自主度与交付状态。本篇把案例逐一映射到自建的三档成熟度分级上，结论先给：电力行业公开可验证的 Agent 天花板是 L2（工具调用闭环），全行业没有 A/B 级信源证明 L3（多智能体自主协同决策）已落地。

一、三层架构与核心产品清单

把阿里云在电力行业的产品按「谁依赖谁」排一遍，得到三层结构：底座层给算力与数据，平台层给模型与工具链，应用层是业务场景的智能体。上层的能力上限由下层决定。

1.1 算力与数据底座层

关键词是「同根同源」与「混部」。飞天企业版是阿里云的专有云形态，官方表述为与公共云同根同源、基于同一套飞天云计算操作系统，为政企客户构建资源与云管完全独立的企业级云平台（A）。三组能力值得记下：

• 一云多算：智算（GPU）+ 超算（高性能 CPU）+ 普算（通用 CPU）融合为异构算力集群，通过算力池化做多租户隔离（A）。
• 一云多芯：支持 Intel、海光、鲲鹏、飞腾、倚天 710 等芯片混部，并支持在线轮转——不铲除、不重建地在线替换服务器（A）。对停机窗口极稀缺的电网机房，这比参数更有价值。
• 规模化能力：官方口径为单集群最大支持 1.5 万张 GPU 卡、资源按 1% 粒度调度、GPU 利用率提升 100%、百万 Output Token 成本下降 89%（C，厂商口径；「提升 100%」是相对基线的倍数表述，不是「达到 100%」）。

电力专用算力有两个标志节点：2021 年 8 月南方电网与阿里云上线的国内电力行业首个云超算平台（南网调度云超算），采用飞天 + 神龙超算集群，每秒 825 万亿次浮点运算，单节点性能较普通云服务器提升 5 倍（A）；国网云，国家电网自 2019 年起构建覆盖全国的超大型云计算平台，核心由阿里云提供技术支撑（B），2020 年共建时用的是飞天企业版「一云多 Region」能力（A），该平台后来成为光明电力大模型的数字底座。

阿里云电力 AI 调研（八）：结语——方法论复盘与可复制性评估

本系列共八篇，逐环节拆解阿里云在电力行业「发、输、变、配、用」的 AI 与 Agent 落地现状。 全部结论标注信源等级：A 官方（阿里云/客户官网、官方技术博客）、B 权威媒体 / 行业白皮书 / 信通院、C 厂商 PR 稿或会议演讲、D 二手转载（仅作线索）。 本系列刻意区分「已投产」与「方案宣传」，并对厂商口径保留独立判断。

一、八篇之后，剩下的是什么

前七篇逐环节走完，最终沉淀下来的其实不是一份"阿里云电力 AI 能力清单"——那样的清单半年后就会过期。真正有复用价值的是两样东西：一套判断厂商材料的方法，和一张评估某项能力自己能不能用的分层表。

本篇就是这两样东西的整理。

二、归因四问

第一篇提出了"归因三问"。跑完二十个案例之后，它需要扩成四问——第四问在整个调研中排除了大量看似可信的数字。

第一问：谁主导的？ 厂商交付、客户自建、还是客户主导 + 厂商作为底座之一？第三种情况在电力行业占比最高。山东广固换流站、重庆永川倒闸操作票、国网江苏变电智巡，都属于这一类：效果好，但不能写成"阿里云方案"。

第二问：谁验证的？ 有独立第三方吗？特别要警惕"同源验证"——山东"调度智慧大脑"故障研判"1 分钟内"这一数字，被人民网与阿里云稿同时引用，但两篇稿件的作者是同一人（B/C）。这不构成交叉验证，只是同一个信源的两次发布。

第三问：AI 的边际贡献能否剥离？ 同一时期是否存在外因？龙源电力的新能源资产运营是个典型：AI 预警准确率 86.5%、设备可用系数 ≥99% 都是真的，但同期风电电价下行 52 元/MWh、利用小时数减少 138 小时——电价与限电是 AI 无法对抗的结构性约束。任何"AI 提升收益"的叙事都必须先扣掉这部分。

第四问：这个数字的口径是什么？ 这是最容易被跳过、也最容易出错的一问。第四篇拆解的"故障自愈率 80%“就是标准案例——它指的是计量设备层面的自愈，不是配网线路自愈率。同类陷阱还有：准确率数字存在六种口径（70%/85%/87%/88.06%/90%/92%/95%）服务于不同场景，不可直接比较；“智能体数量"是数量口径而非自主度口径；“风机"与"机组"是两个概念。

四问的顺序不能颠倒。 先问归属，再问验证，然后剥离外因，最后校验口径。跳过任何一步，都可能把一个真实数字读成一个不存在的结论。

三、「铁三角」模式的真实结构

阿里云在电力行业最成功的一个项目——国网山东电力的"电网调度智慧大脑”——被官方总结为一种可复制的方法论：“需求方定义场景、技术方攻坚算法、生态方打通数据”（C，阿里云稿）。

把这三方拆开看：

这个结构之所以值得单独讨论，是因为它把最脏最累的活（打通十余个异构核心系统）交给了第三方，而不是让模型厂商去做。对于电力这类系统烟囱林立、数据标准不统一的行业，这是唯一现实的路径。

Agent 技能解剖（四）：Proactive Agent——主动性的代价与上下文存活

前三篇都在处理「记忆」：怎么存、怎么约束、怎么改进。 这一篇换一个层面——记忆的载体本身会消失。 上下文压缩一发生，没落盘的一切就没了。而在这个前提下，讨论「主动」才有意义。

这篇的位置

Proactive Agent 是本系列里定位最特殊的一个：它不提供存储，而是提供一整套协作行为规范。它的自我描述是「把 AI Agent 从任务执行者变成主动伙伴」，实际内容可以归到两个问题：

1. 怎么让主动行为不打扰人？（主动性必须有上限，否则就是骚扰）
2. 怎么让 Agent 活过上下文压缩？（这是主动性的前提——一个连昨天做过什么都想不起来的 Agent，无法主动）

第二个问题是硬约束，第一个问题是软约束。技能的绝大部分篇幅给了第二个。

技能档案

数据抓取于 2026-09-28。作者署名是一个 AI Agent 本身（Hal 9001），技能里没有理论引用，全部是「这样试过、那样会坏」的经验条目——这决定了它的读法：当成事故报告合集来读，比当成架构文档读收获大。

上下文存活的三个协议

这是全篇最硬的部分，按触发时机串起来看：

协议一：WAL（Write-Ahead Log）

触发条件是用户的输入，不是模型的自省。 这是整个设计里最关键的一处选择。技能列出了需要扫描的六类信号：

Agent 技能解剖（三）：Self-Improving Agent——从纠错日志到规则晋升

前两篇解决的是一致性问题：怎么把记忆存成数据、怎么用 schema 约束它。 但记忆本身不改变行为。你知道一件事，不等于你会因此改变做法。 这一篇讲的是把「知道」变成「改掉」的机制。

一个被普遍误读的词

「自我改进的 Agent」这个说法容易让人想到权重更新、在线微调、参数层面的学习。而本系列讨论的这类技能，做的完全是另一件事：

它把「学习」实现为一个文档编辑流程。

模型的行为由 prompt 决定，那么「改变行为」的最短路径就不是训练，而是改 prompt。于是「自我改进」被拆解成一条可执行的流水线：把纠正与错误写成结构化日志 → 反复出现的模式被识别出来 → 蒸馏成一句规则 → 写进项目的常驻 prompt 文件。

这个技能就是这个流水线的一份完整、且经过版本迭代的实现。它是当前装机量最高的技能（86,140），不是偶然——它解决的是所有 Agent 用户都有的痛感。

技能档案

数据抓取于 2026-09-28。版本号走到 3.0.24 说明它经历了长期实际使用与修正。

四层记忆阶梯

先看它把知识放在了哪几层。这是理解全技能的钥匙：

四层的分工非常明确，且晋升是单向的：

Agent 技能解剖（二）：Ontology——用 schema 管住模型的不确定性

上一篇讲 Agent Memory，结论是「把记忆做成数据层」。但数据层有一个自带的问题：数据一旦自由生长，就查不动、也信不过。 这一篇讲那个问题的解法：给记忆加一层类型系统与约束校验。

问题的真正形态

用自然语言存储记忆，会遇到三类麻烦，而且它们都不会立刻暴露：

1. 形态漂移。「项目」「Project」「project」是同一个东西；「进行中」「in progress」「active」也是同一个状态。写入时没人觉得有问题，三个月后查询时全都查不全。
2. 关系丢失。「张三负责官网改版」这句话，在纯文本记忆里就是一句话。你没法问「张三还负责什么」，只能全文搜「张三」，然后自己读。
3. 无校验。模型写下「会议结束时间早于开始时间」，存储层照单全收，没有任何环节会拒绝它。

Ontology 这个技能给出的答案是教科书式的：因为语言是不确定的，那就不要再让语言承担一致性保证——把它压缩成「实体 + 类型 + 属性 + 关系」，然后用 schema 去校验。

技能档案

数据抓取于 2026-09-28，口径为 SkillHub 聚合榜。