用 .NET 构建全天候故障分诊智能体

一篇 dev.to 文章展示了如何用 .NET 10 和 Microsoft Foundry 上的 gpt-5.4-mini 构建全天候故障分诊智能体：发现异常、调用获准工具调查、汇总证据并创建事件。作者把重启操作留给人工审批，也讨论了持续运行时的调用成本、配额和 429 错误。

目前能确认什么

示例包含被监控的 Loja.Api 和作为 BackgroundService 运行的 Vigia.Agente。后者按周期收集 health check 与最近 15 分钟的 5xx 错误，先检查异常阈值、重复事件和每日 token 预算，再决定是否调用模型。

全天候运行，不等于全天候调用模型。

应用健康或问题已经上报时，规则直接结束本轮检查；预算耗尽后，程序仍会用规则采集的数据创建事件。AI 负责进一步调查，重启请求则等待人工批准。

运行层面，作者采用串行周期、每轮超时取消和异常捕获，避免单轮失败终止后台服务。429 通常表示请求受到限流；请求数和 token 用量都可能受配额约束，因此限制单次输出长度不能替代整体预算管理。

我的判断

对程序员最有参考价值的是职责分配：确定性规则负责筛选与兜底，模型负责需要上下文的调查。这套结构能把 AI 接入已有监控流程，也让模型不可用时仍有基础事件记录。

但现有节选不足以证明它已经适合生产值守。429 后如何退避重试、预算统计如何覆盖失败调用、服务重启后如何继续去重，以及审批如何校验身份，都还没展示清楚。

单轮异常能被捕获，不代表智能体自身停摆时有人会收到通知。

作者提出了这个问题，但节选尚未给出完整方案。真正落地时，智能体自身的健康监测和告警出口仍需要明确设计。