「英中对照」ProptechOS梳理基于其平台的代理式楼宇运营用例及判定标准

Most “smart building” use cases stop at a notification. Agentic use cases don’t — they close the loop. Each one below follows the same anatomy: a trigger the system detects, an action it takes on the building, the systems and data it draws on, the guardrail that bounds it, and the measure that proves it worked. That structure is what separates an agent from a dashboard.大多数“智能建筑”用例止步于通知。智能体型用例则不然——它们会形成闭环。下面每个用例都采用相同的构成：系统检测到的触发条件、它对建筑执行的动作、它所利用的系统和数据、约束它的护栏，以及证明其有效的度量。正是这种结构将智能体与仪表盘区分开来。

What counts as an agentic use case什么才算智能体型用例

A use case is agentic only if the system acts, not just advises. The test is simple: after the trigger fires, does a person still have to do something for anything to change? If yes, it’s analytics. If the system decides and acts within guardrails — and you can see every decision it made — it’s agentic.只有系统采取行动，而不仅是提供建议，用例才是智能体型的。判断标准很简单：触发条件发生后，是否仍需人员采取行动才能产生改变？若是，那就是分析系统。如果系统在护栏内自行决策并行动——而且你可以查看它做出的每项决策——那才是智能体型用例。

Every use case here is written the same way, five lines each, so you can compare them and lift them straight into a spec:此处的每个用例都以相同方式编写，每个均为五行，便于你相互比较并直接写入规格说明：

Trigger — what the agent detects. Action — what it does to the building. Systems and data — what it reads and writes. Guardrail — the bounds it operates inside. Measure — how the outcome is verified.触发条件——智能体检测到什么。动作——它对建筑执行什么。系统与数据——它读取和写入什么。护栏——它运行所遵守的边界。度量——如何验证结果。

The use cases below illustrate what agentic operations can look like on ProptechOS. Which ones apply depends on the systems, data and partner applications connected in each building.下面的用例展示了在 ProptechOS 上智能体运营的可能形态。具体哪些适用，取决于每栋建筑所连接的系统、数据和合作伙伴应用程序。

Energy and cost能源与成本

Continuous HVAC optimization持续 HVAC 优化

For Energy and Sustainability Manager面向能源与可持续发展经理

• Trigger — live load, occupancy, weather forecast, and tariff signals show the current control strategy is over-conditioning a low-occupancy floor during a high-price period.触发条件——实时负荷、人员占用情况、天气预报和电价信号表明，当前控制策略正在高电价时段对低占用率楼层进行过度调节。

• Action — re-sequences plant and shifts setpoints within comfort bounds to cut load through the price peak, pre-cooling earlier when power is cheaper.动作——在舒适度范围内重新编排设备运行序列并调整设定值，以在价格高峰期间削减负荷，并在电价更低时提前预冷。

• Systems and data — BMS plant and zone points, interval meter, occupancy, weather forecast, and dynamic tariff, resolved against the RealEstateCore model of the building.系统与数据——BMS 设备与区域点位、间隔电表、人员占用情况、天气预报和动态电价，并基于建筑的 RealEstateCore 模型进行关联解析。

• Guardrail — stays inside comfort and equipment limits; plant sequencing respects minimum run and rest times.护栏——保持在舒适度和设备限值内；设备序列编排遵守最小运行时间和停机时间。

• Measure — energy and cost per degree-day, peak demand, comfort-complaint rate.度量——每度日的能源和成本、峰值需量、舒适度投诉率。

Cut energy costs and meet ESG goals with Energy toolbox.借助 Energy toolbox 削减能源成本并实现 ESG 目标。

Demand-charge and demand-response management需量电费与需求响应管理

For Energy and Sustainability Manager面向能源与可持续发展经理

• Trigger — forecast load, or an incoming grid demand-response signal, shows the building on track to set a new monthly peak or a DR window opening.触发条件——负荷预测，或传入的电网需求响应信号，表明建筑将创下新的月度峰值需量，或 DR 时段即将开始。

• Action — stages non-critical loads down and pre-conditions ahead of the window to shave the peak without a comfort hit.动作——分阶段下调非关键负荷，并在时段开始前进行预调节，以在不影响舒适度的情况下削峰。

• Systems and data — interval meter, load forecast, DR signal or API, and BMS controllable loads.系统与数据——间隔电表、负荷预测、DR 信号或 API，以及 BMS 可控负荷。

• Guardrail — life-safety and critical systems excluded; occupant-facing zones held within their limits.护栏——生命安全系统和关键系统不在调节范围内；人员使用区域保持在其限值内。

• Measure — monthly peak demand, DR event performance, comfort exceptions during events.度量——月度峰值需量、DR 事件表现、事件期间的舒适度异常。

Comfort and tenant experience舒适度与租户体验

Comfort complaint triage and resolution舒适度投诉分级与解决

For Head of Facilities and Operations面向设施与运营负责人

• Trigger — a tenant logs a “too warm” or “too cold” complaint, or a cluster of complaints concentrates in one zone.触发条件——租户记录“太热”或“太冷”投诉，或投诉集中出现在某个区域。

• Action — correlates the complaint with live zone data, identifies the cause, applies a bounded correction, and logs the diagnosis — raising a work order only if the fix needs hands on site.动作——将投诉与实时区域数据相关联，识别原因，在限定范围内执行修正，并记录诊断；仅当修复需要人员到场时才发起工单。

• Systems and data — tenant app or ticketing system, BMS zone points, equipment status, and the RealEstateCore model.系统与数据 — 租户应用或工单系统、BMS 区域点位、设备状态以及 RealEstateCore 模型。

• Guardrail — auto-correction limited to setpoint and schedule within range; mechanical faults escalate to a person with the diagnosis attached.约束规则 — 自动校正仅限于允许范围内的设定值和时间表；机械故障会升级至人工处理，并附带诊断信息。

• Measure — time-to-resolution, share of complaints resolved without a truck roll, repeat-complaint rate.衡量指标 — 解决耗时、无需人员上门即可解决的投诉占比、重复投诉率。

Out-of-hours drift correction非工作时间偏差校正

For Head of Facilities and Operations面向 设施与运营负责人

• Trigger — an after-hours scan finds zones running as if occupied — air, heating, or lighting on with no occupancy or schedule reason.触发条件 — 非工作时间扫描发现区域以有人占用模式运行：在无人员占用或时间表依据的情况下，空调、供暖或照明处于开启状态。

• Action — returns the zones to unoccupied setback and flags the schedule mismatch for review.操作 — 使区域恢复至无人占用节能回退设定，并标记时间表不匹配问题以供审核。

• Systems and data — occupancy, schedule, BMS zone and lighting points, and the meter.系统与数据 — 人员占用、时间表、BMS 区域和照明点位，以及计量表。

• Guardrail — won’t touch zones with an active booking or manual override; respects tenant-controlled areas.约束规则 — 不会干预存在有效预约或手动超控的区域；尊重租户管控区域。

• Measure — off-hours energy use, number of drift events caught, recurring offenders.衡量指标 — 非工作时间能耗、发现的偏差事件数量、屡次发生偏差的区域。

Maintenance and equipment health维护与设备健康

Fault detection to work order从故障检测到工单

For Head of Facilities and Operations面向 设施与运营负责人

• Trigger — sensor patterns indicate a developing fault, such as a chiller drawing more power for the same output, or a valve hunting.触发条件 — 传感器模式表明存在正在发展的故障，例如冷水机组在相同出力下消耗更多电力，或阀门振荡。

• Action — confirms against related points to rule out a false positive, then raises a prioritized work order with the diagnosis, location, and likely part, routed to the right team.操作 — 通过相关点位核实以排除误报，随后生成优先级工单，附上诊断、位置和可能的故障部件，并分派至合适团队。

• Systems and data — BMS equipment points, the CMMS or work-order system, and the asset register in RealEstateCore.系统与数据 — BMS 设备点位、CMMS 或工单系统，以及 RealEstateCore 中的资产台账。

• Guardrail — auto-dispatch limited to defined fault types and severities; ambiguous cases go to a human queue.约束规则 — 自动派单仅限于既定故障类型和严重程度；不明确的情况进入人工队列。

• Measure — mean time to detect, false-positive rate, share of faults caught before failure.衡量指标 — 平均检测时长、误报率、故障发生前检出的故障占比。

Operational Efficiency covers the rest of this loop — fault detection, CMMS integration, and asset data pulled from one RealEstateCore model instead of per-system silos.运营效率涵盖该循环的其余部分——故障检测、CMMS 集成，以及从单一 RealEstateCore 模型而非各系统数据孤岛调取的资产数据。

Predictive maintenance prioritization预测性维护优先级排序

For Asset and Portfolio Manager面向 资产与组合经理

• Trigger — degradation trends across assets suggest several units approaching intervention thresholds in the same window.触发条件 — 各资产的退化趋势显示，若干设备在同一时间段接近干预阈值。

• Action — ranks interventions by risk, cost, and disruption, auto-scheduling routine items and proposing a sequence for the capital ones.操作 — 按风险、成本和干扰影响对干预措施排序，自动安排常规项目，并为资本性项目提议执行顺序。

• Systems and data — equipment run data, CMMS history, the asset register, and cost data.系统与数据 — 设备运行数据、CMMS 历史记录、资产台账和成本数据。

• Guardrail — capital or tenant-impacting work is proposed, not executed; routine preventive maintenance is auto-scheduled within policy.约束规则 — 资本性或对租户有影响的工作仅作提议，不予执行；常规预防性维护在政策范围内自动排程。

• Measure — planned-to-reactive work ratio, avoided failures, maintenance spend per asset.衡量指标 — 计划性工作与反应性工作比率、避免的故障数、单资产维护支出。

Sustainability and reporting可持续发展与报告

Carbon-aware operation碳感知运行

For Energy and Sustainability Manager面向 能源与可持续发展经理

• Trigger — a grid carbon-intensity forecast shows a high-carbon window coinciding with flexible load in the building.触发条件 — 电网碳强度预测显示，高碳时段与建筑柔性负荷重合。

• Action — shifts flexible loads — pre-cooling, thermal storage, EV charging — toward lower-carbon periods, within comfort and cost bounds.操作 — 在舒适度和成本限值内，将预冷、蓄热、EV 充电等柔性负荷转移至低碳时段。

• Systems and data — grid carbon-intensity feed, tariff, BMS flexible loads, and the meter.系统与数据 — 电网碳强度数据源、电价、BMS 柔性负荷以及计量表。

• Guardrail — comfort and cost limits still bind; carbon optimization won’t breach the budget or the comfort band.约束规则 — 舒适度和成本限制依然具有约束力；碳优化不会突破预算或舒适度区间。

• Measure — operational carbon, cost impact, comfort exceptions.衡量指标——运营碳、成本影响、舒适度异常。

Reporting-ready data, continuously持续提供可直接用于报告的数据

For Energy and Sustainability Manager, Asset and Portfolio Manager面向能源与可持续发展经理、资产与投资组合经理

• Trigger — a reporting period or an ad hoc request needs energy, carbon, and performance data across the portfolio.触发条件——某个报告期或临时请求需要整个投资组合的能源、碳与绩效数据。

• Action — assembles normalized, audit-traceable metrics per building from the live model, instead of a manual data-pull scramble.行动——根据实时模型为每栋建筑汇总归一化、可审计追溯的指标，而非仓促地手动拉取数据。

• Systems and data — meters, BMS, the RealEstateCore model across buildings, and the target reporting framework.系统与数据——计量表、BMS、跨建筑的 RealEstateCore 模型，以及目标报告框架。

• Guardrail — figures are traceable to source; where data quality is low, the report flags it rather than silently filling the gap.安全护栏——数据可追溯至来源；当数据质量较低时，报告会予以标记，而不是悄悄填补缺口。

• Measure — reporting cycle time, data-coverage and quality score, audit exceptions.衡量指标——报告周期时间、数据覆盖率与质量评分、审计异常。

What ties the use cases together是什么将这些用例联系在一起

Read together, three things make these work as a system rather than a pile of point features.综合来看，有三点让这些用例成为一个系统，而不是一堆单点功能。

Guardrails make autonomy safe. Every use case acts inside bounds the operator sets and escalates at the edge of them. Autonomy is scoped on purpose — the agent takes the routine decisions off a person’s plate, not the judgment.安全护栏让自主化安全可靠。每个用例都在运营人员设定的边界内运作，并在触及边界时升级上报。自主化的范围经过刻意设计——智能体接手人的常规决策，而不代替人做判断。

A shared model makes them portable. Each use case resolves messy, vendor-specific data against one semantic model — the RealEstateCore ontology — so the same logic runs across buildings that were never built to talk to each other. That’s what lets a use case built once run estate-wide, and it’s the answer to a technology leader’s first question: how does this work across our mixed stack without a rip-and-replace?共享模型让用例可移植。每个用例都依据同一个语义模型——RealEstateCore 本体——解析杂乱的厂商专有数据，因此相同逻辑可在从未设计为相互通信的建筑之间运行。这使得一次构建的用例可以在整个地产组合中运行，也回答了技术负责人的首要问题：在不推倒重来的情况下，它如何跨我们的混合技术栈运行？

They compound across a portfolio. An agent overseeing a whole portfolio turns each use case from a single win into a continuous baseline. That shift — from tuning buildings one at a time to operating all of them at once — is what an Asset and Portfolio Manager is actually buying.它们会在整个投资组合中形成复合效应。监督整个投资组合的智能体将每个用例从单次成果转变为持续基准。这种转变——从逐栋调优建筑到同时运营所有建筑——正是资产与投资组合经理真正看重的价值。

Underneath all of it is the same division of labour: the BMS stays the system of record; the agent is the system of action on top of it.所有这些背后都是同一分工：BMS 仍是记录系统；智能体则是位于其之上的行动系统。

The post Agentic building operations use cases appeared first on ProptechOS.文章 基于智能体的建筑运营用例 首发于 ProptechOS。