把楼宇诊断从 20 分钟压缩到 20 秒:基于 Amazon Bedrock AgentCore 的智能体架构

2026-09-22 14 预计阅读时间: 1 分钟
来源: aws.amazon.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:12 分钟

Trane Technologies 在大约四周内构建了一套基于 Amazon Bedrock AgentCore 的智能体解决方案,把原本需要在多个界面间切换、耗时约 20 分钟的楼宇诊断流程,缩短为约 20 秒的自然语言交互。这里的“60 倍”不只是模型生成速度提升,更重要的是把查数据、关联设备、判断异常和组织结论压缩进了一条受控工作流。

60 倍提速,真正减少的是操作链路

传统楼宇诊断往往不是一个复杂算法问题,而是一串分散操作:

  1. 在资产系统中找到楼宇和设备。
  2. 打开监控页面查看温度、压力、能耗或告警。
  3. 切换到历史趋势页面确认异常持续时间。
  4. 对照设备类型、运行规则和维护记录。
  5. 手工总结可能原因与建议动作。

20 分钟变成 20 秒,相当于将 1,200 秒压缩到 20 秒:

1200 / 20 = 60

自然语言只是入口。真正创造价值的是智能体能够识别用户意图、调用正确的数据工具、合并结果,并输出带证据的诊断结论。如果只是把楼宇数据全部塞进一个大提示词,系统很快会遇到上下文过长、数据过期、权限失控和结论不可追踪等问题。

不要把诊断系统做成一个“超级提示词”

来源摘要没有列出每个 AWS 资源和接口的具体配置,因此下面是适合此类场景的参考架构,而不是对 Trane 实现的逐项复刻。

一个稳健的楼宇诊断智能体可以拆成四层:

自然语言界面
    ↓
AgentCore 中的智能体运行与会话控制
    ↓
受约束的诊断工具:资产、遥测、告警、工单、知识库
    ↓
楼宇管理系统、时序数据库、数据湖和维护系统

各层应承担清晰职责:

  • 交互层负责接收问题和展示答案,不直接访问生产数据。
  • 智能体层负责规划步骤、选择工具、维护会话上下文和组织回答。
  • 工具层把底层系统封装成稳定、可授权、可审计的业务动作,例如 get_zone_temperatureslist_active_alarms
  • 数据层继续作为事实来源,模型不应凭记忆生成当前设备状态。

工具最好返回结构化证据,而不是一大段未经整理的日志。例如,每条异常都应携带设备标识、指标名称、时间范围、实际值和阈值。这样既能降低模型误解数据的概率,也方便工程师复核。

可运行示例:先构建受控的诊断工具层

下面的示例不依赖真实楼宇系统,也不声称使用了 Trane 的内部接口。它模拟一个可以被 AgentCore 智能体调用的诊断 API。生产环境中,只需把内存数据替换为楼宇管理系统、时序数据库或数据湖查询。

创建 requirements.txt

fastapi==0.115.0
uvicorn[standard]==0.30.6
pydantic==2.9.2

创建 app.py

from time import perf_counter
from typing import Literal

from fastapi import FastAPI, Header, HTTPException
from pydantic import BaseModel, Field

app = FastAPI(title="Building Diagnostic Tools")

# 示例数据;生产环境中应替换为实时遥测或时序数据库查询。
BUILDINGS = {
    "BLDG-001": {
        "zones": {
            "north": {"temperature_c": 25.8, "setpoint_c": 22.0},
            "south": {"temperature_c": 22.4, "setpoint_c": 22.0},
        },
        "ahu": {
            "supply_air_c": 17.5,
            "static_pressure_pa": 145,
            "expected_pressure_pa": 200,
        },
        "active_alarms": ["AHU-1 low static pressure"],
    }
}


class DiagnosticRequest(BaseModel):
    building_id: str = Field(examples=["BLDG-001"])
    question: str = Field(
        examples=["Why is the north zone warmer than its setpoint?"]
    )


class Evidence(BaseModel):
    source: str
    metric: str
    actual: float | str
    expected: float | str


class DiagnosticResponse(BaseModel):
    status: Literal["normal", "attention_required"]
    summary: str
    recommended_actions: list[str]
    evidence: list[Evidence]
    elapsed_ms: float


@app.post("/tools/diagnose", response_model=DiagnosticResponse)
def diagnose(
    request: DiagnosticRequest,
    x_role: str = Header(default="viewer"),
):
    started = perf_counter()

    if x_role not in {"operator", "engineer"}:
        raise HTTPException(status_code=403, detail="Insufficient role")

    building = BUILDINGS.get(request.building_id)
    if building is None:
        raise HTTPException(status_code=404, detail="Building not found")

    north = building["zones"]["north"]
    ahu = building["ahu"]
    temperature_delta = north["temperature_c"] - north["setpoint_c"]
    pressure_low = ahu["static_pressure_pa"] < ahu["expected_pressure_pa"]

    evidence = [
        Evidence(
            source="zone_sensor:north",
            metric="temperature_c",
            actual=north["temperature_c"],
            expected=north["setpoint_c"],
        ),
        Evidence(
            source="ahu:AHU-1",
            metric="static_pressure_pa",
            actual=ahu["static_pressure_pa"],
            expected=ahu["expected_pressure_pa"],
        ),
    ]

    if temperature_delta > 2 and pressure_low:
        status = "attention_required"
        summary = (
            "The north zone is 3.8°C above setpoint while AHU-1 static "
            "pressure is below its expected value. Insufficient airflow is "
            "a plausible cause, but it must be verified on site."
        )
        actions = [
            "Inspect AHU-1 filters and fan operation.",
            "Check north-zone dampers for blockage or control faults.",
            "Review the last 24 hours of pressure and temperature trends.",
        ]
    else:
        status = "normal"
        summary = "No correlated temperature and airflow anomaly was found."
        actions = ["Continue monitoring current telemetry."]

    elapsed_ms = round((perf_counter() - started) * 1000, 2)
    return DiagnosticResponse(
        status=status,
        summary=summary,
        recommended_actions=actions,
        evidence=evidence,
        elapsed_ms=elapsed_ms,
    )

启动服务:

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
uvicorn app:app --host 0.0.0.0 --port 8000

在另一个终端调用诊断工具:

curl -s http://localhost:8000/tools/diagnose \
  -H 'Content-Type: application/json' \
  -H 'X-Role: engineer' \
  -d '{
    "building_id": "BLDG-001",
    "question": "Why is the north zone warmer than its setpoint?"
  }' | python -m json.tool

这个 API 故意把“事实”和“推断”分开:传感器值属于证据,“风量不足可能是原因”属于需要进一步验证的诊断判断。接入智能体时,可以要求模型只能根据 evidence 字段陈述事实,并把不确定结论标记为假设。

可采用如下系统提示词约束回答:

You are a building diagnostic assistant.
Use only data returned by approved tools.
Separate measured facts from diagnostic hypotheses.
Cite the source and metric for every anomaly.
Never claim that equipment has failed unless a tool explicitly confirms it.
For write operations, request human approval before calling the tool.

决定生产效果的几个边界

1. 工具要小而明确

与其提供一个能够执行任意 SQL 的工具,不如提供语义清晰的业务工具:

  • get_building_summary
  • get_zone_temperature_trend
  • list_active_alarms
  • get_equipment_maintenance_history
  • create_inspection_request

小工具更容易授权、测试和审计,也能减少提示词注入导致越权访问的风险。

2. 读操作与写操作分开

查看温度与创建工单的风险完全不同。读工具可以自动调用;创建工单、修改设定值或控制设备等写操作,应要求明确的人员确认,并记录调用者、参数和结果。

3. 为 20 秒目标建立延迟预算

端到端时间不能只看模型延迟。可以把 20 秒预算拆成:

环节 示例预算
意图识别与规划 3 秒
并行查询遥测、告警和资产数据 8 秒
关联分析与答案生成 6 秒
网络、鉴权和界面渲染 3 秒

互不依赖的工具应并行调用;历史趋势等较慢查询可以预聚合或缓存。与此同时,缓存必须携带数据时间戳,避免智能体把旧数据描述成当前状态。

4. 评估完整任务,而不是只评估文案

关键指标应包括:

  • 是否选择了正确工具。
  • 是否查询了正确楼宇、区域和时间范围。
  • 结论能否追溯到证据。
  • 是否明确表达不确定性。
  • 是否触发了不允许的写操作。
  • 从提问到可执行结论的总耗时。

文案流畅并不等于诊断正确。生产评估集应包含正常状态、传感器故障、数据缺失、多个告警同时发生以及用户无权限等情况。

落地时的检查清单

Trane 的案例说明,智能体项目可以在较短周期内交付明显的流程收益,但前提是问题边界足够清晰。实施时可以按以下顺序推进:

  • 选择一个已有标准操作流程、但需要频繁切换系统的诊断任务。
  • 记录当前人工流程的真实基线,包括耗时、点击次数和错误率。
  • 将数据访问封装成少量只读工具,先不要开放设备控制。
  • 强制工具返回时间戳、来源、单位和阈值。
  • 用真实历史案例评估工具选择、事实准确率和端到端延迟。
  • 对高风险动作增加人员审批、最小权限和完整审计日志。
  • 上线后同时监控模型调用、工具调用、失败重试和用户修正情况。

最值得复制的不是“给楼宇系统加一个聊天框”,而是把分散的诊断步骤整理成一条可调用、可观察、可授权的工作流。AgentCore 为智能体运行提供基础,而可靠的数据工具和明确的安全边界,才决定 20 秒得到的是可信洞察,还是一段听起来合理的文字。


相关推荐