Ygrowly
返回精选项目

Enterprise Agent System · 2026

EnergyOps Agent

从园区累计读数，到可信的账本与受控 Agent 操作。

园区能耗智能运营平台：把数百台水电表的原始累计读数整理为用能、异常与结算三本可信的账，并通过 WPS Comate 提供受权限与人工确认约束的对话式 Agent 入口。

业务问题与个人职责

业务问题：不稳定的累计读数要变成可追溯的统计与结算，Agent 又要在不越权的前提下操作业务能力。我主导 Agent 运行时治理与评测闭环的方案和交付，Mentor 把关业务方向。

系统链路

  1. 累计读数
  2. 质量判定
  3. 区间用量
  4. 多层聚合
  5. 异常诊断
  6. 告警闭环
  7. Agent 调用

工程重点

Data Quality
7 类质量状态判定 + 可信白名单，仅可信区间进入聚合，不做无依据估算。
Runtime Governance
数十个 MCP 工具收敛为 6 类能力包，R0/R1/R2 风险分级 + Before/After Tool Hook 链校验。
Recoverable Ops
幂等窗口、任务状态持久化与启动自动回补，重启与乱序补数不产生聚合缺口。

可验证证据

Eval
回放评测 · 任务完成率约 +12pt
Security
内部越权用例全部拦截
Perf
核心接口 P95 约 -86%（固定查询集）
Ops
人工补数约 -70% · 调度成功率 99%+
Pipeline
raw → interval → hourly → daily

Python · FastAPI · PostgreSQL · MCP · WPS Comate · pytest

设计取舍

  1. 把安全边界交给 Hook 链，而不是写进 Prompt

    为什么
    对模型来说「查询」和「发布」只是两个不同的工具名，它不理解操作的真实代价。用 Prompt 划边界等于把安全交给概率。
    代价
    每个写工具都要显式定义参数 Schema、风险等级、幂等键与审计字段，R2 级还要设计二次确认态——新增一个写工具的成本远高于加一句 Prompt。

  2. 异常候选与业务告警拆成三层，不直接等价

    为什么
    把「数据偏离」直接等同于「发送告警」，结果是大量低价值通知淹没真正需要处理的问题。
    代价
    自适应基线、候选评分、静默窗口变成三套要维护的配置，运营侧多了一层需要理解的模型；冷启动阶段样本不足，只能如实标记「不可判定」。

  3. 只让可信区间进入聚合，质量存疑的读数不做估算

    为什么
    估算出来的数据看起来更完整，但一旦进入结算就无法追溯。宁可在覆盖率上开天窗，也不让来源不明的数字进账。
    代价
    覆盖率指标会低于「什么都算上」的方案，需要向业务解释缺口；补数依赖人工流程，短期无法自动化。

  4. 大结果外置为 Artifact，不进入模型上下文

    为什么
    读数明细动辄数万行，塞进上下文只会挤掉真正需要推理的信息，还会推高成本。
    代价
    模型手里只剩聚合摘要和引用，需要细节时必须二次取用——多一次工具往返，换上下文可控。

系统不负责清单

刻意划出的非目标。写下来的边界才是能守住的边界。

  • 不替代既有采集平台完成物理设备采集与底层协议接入
  • 不直接控制空调、照明、冷站等设施
  • 不负责设备维修的派工、排班与 SLA 计时——工单只覆盖「通知—指南—反馈—关单」的信息闭环
  • 不替代财务系统完成记账、付款、开票或总账管理
  • 不开展正式碳核算、ESG 披露或 ISO 50001 认证
  • 不把异常候选自动等同于正式业务事故
  • 不允许模型直接修改原始读数、决定费用或绕过业务规则
  • 不扩展为门禁、消防、资产与物业的完整智慧园区平台

开放问题

目前还没有答案的部分。欢迎就其中任何一条追问。

  • 自适应基线在季节切换期会同时抬高误报和漏报，目前靠人工确认兜底；按业态分别建模是方向，但样本量还不够
  • 异常候选的评分权重仍来自人工经验，缺少「候选→真实事故」的标注数据来校准
  • 工单只覆盖信息闭环，没有和维修系统的排班、SLA 数据打通，处置效果无法量化回流
  • R2 级写操作目前要求逐次人工确认，批量与高频场景下的确认体验还没有好答案