阿里云电力 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 聚合榜。

Agent 技能解剖（一）：Agent Memory——把「记住」做成数据层

本系列共四篇，逐篇拆解四个当前装机量最高的 Agent 技能，全部基于下载技能包后的源码级阅读，不是对 README 的转述。 解读视角固定为 prompt 工程：它把哪一部分不确定性交给了模型，又把哪一部分交给了代码。

为什么先拆这一个

关于「让 Agent 记住」，业内长期存在两种做法：

1. 塞进上下文——把历史对话、文件、笔记尽可能多地带进 prompt；
2. 外置成存储——把记忆写成结构化数据，需要时检索回来。

第一种做法的问题不是「不够长」，而是成本与轮次线性相关：每一轮都要为全部历史重新付费，且上下文越长，模型对中段的注意力越差。第二种做法把问题从「prompt 长度」转换成了「数据工程」，代价是要自己定义 schema、自己做检索、自己处理过期与冲突。

Agent Memory 是第二种路线上装机量最高的技能之一。它值得拆的地方在于：代码只有 680 行，却把一个记忆系统该有的骨架全都摆出来了——三种记忆类型、覆盖率、冲突覆盖、遗忘机制。骨架清晰，正好适合当教学样本；同时它的几处实现与宣称不一致，也正好适合当反面教材。

技能档案

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

Agent 评测领域最容易造成误解的，不是某个指标怎么算，而是同一个词在不同框架里常常指向不同层级。

有人把一次模型调用叫 Run，有人把整个工作流叫 Run；有人说 Replay，实际只是重新发送 prompt；有人把 Trace 当日志，也有人把它当成一棵有父子关系、可以定位耗时与错误的执行树。术语没有先对齐，评测报告里的“成功率 95%”“支持恢复”“全链路可追踪”就很难验证。

这篇文章不按字母顺序背词典，而是沿着一条完整链路解释这些概念：Agent 怎样运行，怎样留下证据，怎样用数据集和评估器打分，又怎样把失败样本变成回归测试。

先看全局：一次运行如何变成一次评测

Dataset 中的一条 Case
        │ 输入 + 可选 Ground Truth
        ▼
Workflow 启动一个 Run
        │
        ├── Span：模型调用
        ├── Span：Tool Call
        ├── Span：Guardrail 检查
        ├── Checkpoint：保存 State
        └── HITL：暂停并等待人工决定
        │
        ▼
Trace：串起本次执行的完整证据
        │
        ├── Evaluator 打分
        ├── Offline Eval 批量比较
        ├── Online Eval 生产监控
        └── Replay / Regression Eval 复现与防回退

这里可以先记住三句话：

这是 Agent 框架评测实验室系列第五篇，也是阶段开发记录。

起点：先让不同框架完成同一任务

Lab 最早解决的是兼容性：统一 stdin/stdout 的请求与结果契约，让不同 Python/Node 框架可以在各自隔离环境运行。这个阶段最直观的产物是 matrix 和报告，但也很快暴露问题：

• 每个 adapter 对 usage 的理解不同；
• 有的框架隐藏模型重试；
• MCP SDK 与 CLI 协议不同；
• 同名模型可能被 gateway 路由到不同后端；
• prompt、工具包装稍有不同，分数就不可比。

因此第一条经验是：先统一证据格式，再谈统一排行榜。

V2.0—V2.1：运行时从附属代码变成核心边界

普通 runner 只关心子进程退出码。企业 Agent 还需要 job、attempt、lease、事件 revision、预算 reservation、checkpoint 和 immutable artifact。

runtime-v1 采用 SQLite WAL 和 append-only event/reducer：

command -> validate current snapshot -> append events
        -> reduce new snapshot -> transactionally persist both

这个阶段没有急着做远程服务，而是坚持单机、一次命令、可验证状态。事实证明这是正确取舍：并发和网络还没加入时，就已经发现事件序列、预算结算和终态工件之间有大量边界条件。

V2.2：恢复不是“再跑一次”

接下来加入 host crash、SQLite reopen、orphan attempt 回收和 checkpoint resume。LangGraph composed 与 OpenAI Agents native 都通过了“researcher 已完成后恢复，只继续 analyst/reviewer”的测试。

“LangGraph、OpenAI Agents、PydanticAI、Google ADK，到底哪个更强？”

这句话听起来像一个排行榜问题，实际上至少藏着六个不同问题：谁更容易写出第一个 demo，谁在同一模型下更省 token，谁能安全暂停审批，谁能在进程崩溃后恢复，谁的原生抽象更适合复杂工作流，谁的运行证据足以通过企业审计。

如果不先限定业务场景和风险边界，“最强框架”没有可验证的含义。

我在开发 Agent Framework Lab 的过程中，逐步把框架测验从“同一个 prompt 跑一遍”改造成一条证据链：冻结任务、提示词、工具、模型和价格；交错重复执行；注入审批、取消、工具故障、worker 崩溃和进程重启；保存不可变原始结果；最后才按自定义权重生成比较结果。

这个系列整理 Lab 的核心理念、方法、代码、失败经验和阶段记录。它既是项目复盘，也是未来开发其他 Agent 测验项目时可以复用的设计手册。

系列文章

1. 别急着问哪个 Agent 框架最好：先把比较问题定义对
2. 把企业需求写成可执行的 Agent 评测契约
3. 不注入故障，就测不出 Agent 框架的生产能力
4. 从原始运行到排行榜：硬门、权重与统计陷阱
5. Agent Framework Lab 开发实录：从比较 demo 到企业就绪 Alpha

此前发布的《Agent 框架开发与评测踩坑实录》是本系列的代码型伴读，集中记录事件账本、审批绑定、幂等键、价格表和 ground truth 等十二类工程坑。

一张图理解 Lab

场景 / Prompt / 工具 / 模型 / 价格 / 限额
                  │ 冻结并版本化
                  ▼
        Framework Adapter Matrix
       ┌──────────┴──────────┐
       │ 公平公共赛道        │ 原生上限赛道
       │ 同输入、同工具      │ 原生图、handoff、checkpoint
       └──────────┬──────────┘
                  ▼
       正常运行 + 固定故障注入
                  ▼
      Raw Result / Events / Artifacts
                  ▼
       硬性 No-Go → 加权能力画像
                  ▼
        Go / Conditional-Go / No-Go

这套方法最重要的变化，是不再把框架看成一个只负责“调用模型”的 SDK。企业应用真正关心的是一整组能力：任务质量、安全治理、故障恢复、审计、成本、延迟、可运维性、开发体验和迁移成本。