面向 AI 工程师的 Agent SRE 实战指南用 SLI/SLO、错误预算与故障注入守护自主智能体【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit本文是 Agent Governance Toolkit 中agent-sre子项目位于 agent-governance-python/agent-sre配套的 SRE 概念手册的深度展开。它面向懂 AI 但不懂 SRE的团队回答一个核心问题当监控面板显示 HTTP 200、而你的 Agent 正在一本正经地编造医学剂量或放行一笔欺诈交易时你如何量化不可靠、预算可接受的失败、并在出问题时自动熔断降级。读完本文你将掌握七类 Agent 专属 SLI、四档 SLO 状态、错误预算与燃烧率的自动告警、混沌故障注入、金丝雀模型发布、Agent 级熔断器与信号关联式事件响应的完整落地写法。什么是 SRE为什么 Agent 团队必须重新学一遍Site Reliability EngineeringSRE是 Google 开创的一门学科用软件工程的方法解决运维问题。它不指望系统永远在线而是为可靠性设定可度量的目标、为可接受的失败做预算、并用自动化手段在出问题时及时响应。SRE 的核心理念只有一句话100% 可靠性是错误的目标。任何系统都会失败真正的问题是你的用户能容忍多少失败以及你如何把这份失败预算花在快速迭代上而不透支信任。SRE 交付三样东西一套共享的可靠性语言—— SLI、SLO、错误预算把应该能用这种模糊说法变成可度量的契约自动化的护栏—— 熔断器、金丝雀发布、混沌测试在用户发现问题之前先发现问题事件处理纪律—— 当故障发生时一定会发生用 runbook、告警和事后复盘postmortem快速恢复并防止复发。在 AI Agent 场景下这套方法论的对象从服务器迁移到了智能体agent-sre模块源码位于 agent-governance-python/agent-sre/src/agent_sre正是这一思路的工程化实现。为什么 AI Agent 需要 SRE五种看不见的故障模式传统服务以 APM 能捕获的方式失败——崩溃、超时、500 错误。AI Agent 的失败方式完全不同而且更危险因为它们不可见。Agent 会无声地失败监控显示 HTTP 200, all green而你的 Agent 刚刚幻觉出一个医疗剂量、批准了一笔欺诈交易、或编造了一条引用。错误答案没有堆栈跟踪。没有错误预算多数团队对 Agent 错误的态度是理论上零容忍实践上零度量。没有错误预算就无法在速度与可靠性之间做理性取舍——每个 bug 都变成危机或者更糟每个 bug 都被无视。没有面向 AI 的 SLO传统 SLO 度量可用性与延迟。但一个 200ms 返回幻觉答案的 Agent 并不可靠——它只是快而错。AI Agent 的 SLO 必须度量决策质量而不仅仅是可用性。这正是 agent-sre 的 SLO 引擎 的设计出发点。多 Agent 系统的级联失败当 Agent A 调用 Agent B、B 再调用 C 时C 的失败会反向级联。没有熔断器一个不稳定的工具或一个过载的模型就能拖垮整条 Agent 工作流。这对应 OWASP ASI08 —— Cascading Agent Failures见 docs/compliance/owasp-agentic-top10-mapping.md。没有护栏的成本失控一个卡在重试循环里的 Agent 能在几分钟内烧掉数千美元的 API 调用费。没有成本护栏一个坏提示词或死循环就能在任何人注意到之前耗尽你的月度预算。agent-sre为此提供了 CostGuard 成本守卫。SLI度量 Agent 的行为而不是基础设施传统 SRE 的 SLI 度量请求延迟、错误率、吞吐量。Agent SRE 的 SLI 度量 Agent 的行为——问题不是服务器响应了吗而是Agent 给出好答案了吗。agent-sre定义了七类为 AI Agent 量身打造的 SLISLI度量什么示例Task Success Rate任务成功率Agent 是否正确完成任务95% 的任务成功完成Hallucination Rate幻觉率Agent 多久编造一次信息少于 5% 的响应包含幻觉Cost Per Task单任务成本每个 Agent 任务花费多少平均成本低于 $0.50/任务Latency延迟首 token 时间与总响应时间p99 延迟低于 3 秒Policy Compliance策略合规Agent 是否遵守治理规则100% 符合安全策略Tool Call Success工具调用成功率Agent 的工具调用是否成功超过 98% 的工具调用返回有效结果User Satisfaction用户满意度显式或隐式用户反馈平均评分 4.0/5.0from agent_sre.slo.indicators import TaskSuccessRate, CostPerTask, HallucinationRate # 定义你要度量什么 success TaskSuccessRate(target0.95, window24h) cost CostPerTask(target_usd0.50, window24h) hallucination HallucinationRate(target0.05, window24h) # 每个 Agent 任务结束后记录观测 success.record_task(successTrue) cost.record_cost(cost_usd0.35) hallucination.record_evaluation(hallucinatedFalse)源码透视SLI 的底层契约从 SLI 基类与内置指标实现 可以看到这套 API 的完整设计时间窗口TimeWindow枚举定义了1h/6h/24h/7d/30d五档标准窗口DAY_30 30d对应 2,592,000 秒任何字符串窗口都会在构造时被归一化为TimeWindow测量与合规基类SLI通过record()把每次测量写入MeasurementStore默认InMemoryMeasurementStore也支持SQLiteMeasurementStore以跨重启存活current_value()返回窗口内均值compliance()返回窗口内达标测量的占比内置指标除了文档表格中的三类源码还内置了ToolCallAccuracy、ResponseLatency支持按百分位取值默认 p95/5000ms、PolicyCompliance默认 100% 目标、DelegationChainDepth作用域链深度越低越好反向比较与CalibrationDeltaSLI校准漂移度量预测置信度与实际成功率的差距方向感知的合规HallucinationRate.compliance()与DelegationChainDepth.compliance()都覆写了基类逻辑——前者按value target判定好越低越好后者按value max_depth判定这与 TaskSuccessRate 的越高越好方向相反接入自定义 SLI 时务必注意目标方向注册表SLIRegistry自动注册全部内置指标类型并支持按agent_id注册实例、批量collect_all()采集方便与观测面板对接。单元测试见 agent-governance-python/agent-sre/tests/test_indicators.py 与 test_sli_persistence.py可作为自定义 SLI 的参照实现。SLO把指标组合成可靠性契约传统 SRE 说99.9% 的请求必须在 200ms 内完成。Agent SRE 说99.5% 的 Agent 响应必须准确且 95% 的任务成本低于 $0.50。SLO 把多个 SLI 组合成一个带时间窗口的可靠性目标回答一个问题我的 Agent 足够可靠吗from agent_sre import SLO, ErrorBudget slo SLO( namecustomer-support-agent, descriptionProduction support agent reliability targets, indicators[success, cost, hallucination], error_budgetErrorBudget(total0.05), # 5% error budget ) # 每个任务结束后记录这是一个 good 事件 slo.record_event(goodTrue) # 评估 SLO 健康状态 status slo.evaluate() # HEALTHY | WARNING | CRITICAL | EXHAUSTEDSLO 状态机与告警联动状态含义应采取的动作HEALTHY预算内所有指标达标继续部署WARNING预算消耗快于可持续速度调查放慢部署CRITICAL预算几乎耗尽停止新功能开发先修可靠性EXHAUSTED预算已耗尽冻结部署直到预算恢复源码细节值得注意见 objectives.pySLO.__init__中有一条自动推导规则如果未显式传入ErrorBudget则从所有指标里最严格最小的 target 推导预算总量total 1.0 - min(sli.target)即最严格指标决定可靠性下限SLOStatus枚举实际包含五档HEALTHY / WARNING / CRITICAL / EXHAUSTED / UNKNOWN其中UNKNOWN表示窗口内尚无任何测量数据evaluate()的判定优先级为预算耗尽 → CRITICAL → 燃烧率告警 → 数据不足UNKNOWN→ HEALTHY若在构造时传入AlertManagerevaluate()会在状态恶化时发送WARNING/CRITICAL告警、在恢复时发送RESOLVED告警并携带dedup_key去重——告警按 Agent 与 SLO 维度去重避免状态抖动造成告警风暴。依赖推导、状态判定与告警去重的对应测试仓库中 test_objectives.py 覆盖了预算推导、状态迁移与告警联动test_alert_dedup.py 与 test_alert_persistence.py 进一步验证了去重与持久化行为可作为接入告警链路时的回归保障。错误预算把可靠性变成可花销的资源传统 SRE 说我们每月可容忍 0.1% 的宕机43 分钟。如果已经用了 40 分钟就停止部署有风险的变更。Agent SRE 说我们每月可容忍 5% 的坏响应。如果已经用掉 4.5% 的预算就冻结模型升级与提示词变更直到预算恢复。错误预算把可靠性从好/坏二元判断变成可花销的资源让你做出理性权衡预算还有余额上线那个新提示词模板。预算耗尽了专注可靠性。质量恢复之前不上新功能。budget ErrorBudget( total0.05, # 5% 错误预算95% 可靠性目标 burn_rate_alert2.0, # 燃烧率 2 倍时告警 burn_rate_critical10.0, # 燃烧率 10 倍时呼叫 ) # 查看预算状态 print(fBudget remaining: {budget.remaining_percent:.1f}%) print(fExhausted: {budget.is_exhausted})预算耗尽后的动作动作描述ALERT通知团队FREEZE_DEPLOYMENTS阻止新版本 Agent 上线CIRCUIT_BREAK打开熔断器缩小爆炸半径THROTTLE降低 Agent 流量或能力源码透视错误预算的实现细节从 ErrorBudget 实现 可以确认有界事件缓冲事件存储在collections.deque(maxlen100_000)中防止长运行 SLO 的内存无限增长缓冲满时最旧事件被静默淘汰剩余量计算remaining max(0.0, 1.0 - consumed/total)因此remaining_percent永远不会为负is_exhausted判断consumed totalExhaustionAction枚举正是上文表格四个动作的机器可读形式可通过ErrorBudget.exhaustion_action配置燃烧率告警firing_alerts()会基于当前窗口计算燃烧率并与burn_rate_alert默认 2.0warning和burn_rate_critical默认 10.0critical比对返回正在触发的告警列表。燃烧率Burn Rate预算消耗的速度计传统 SRE 说按当前错误率我们会在 3 天内耗尽月度预算。Agent SRE 说按当前幻觉率我们的错误预算将在 6 小时后归零。燃烧率度量你消耗错误预算的速度。燃烧率 1.0 表示你恰好会在窗口结束时耗尽预算更高则更糟。燃烧率含义到耗尽的时间30 天预算1.0x可持续30 天2.0x令人担忧15 天5.0x糟糕6 天10.0x危急3 天30.0x宕机1 天# 查看最近一小时的燃烧率 rate slo.error_budget.burn_rate(window_seconds3600) print(fBurn rate (1h): {rate:.1f}x) # 查看正在触发的告警 for alert in slo.error_budget.firing_alerts(): print(f⚠️ {alert.name}: burn rate {alert.rate:.1f}x)实现要点burn_rate()的计算公式为实际错误率 / 允许错误率源码见 objectives.py#L106-L130其中允许错误率由total / window_seconds得出默认评估窗口为 1 小时但告警阈值按 24 小时窗口评估alerts()中两个BurnRateAlert均使用86400秒窗口这遵循了 SRE 社区快速燃烧 长窗口观测的通行实践。混沌测试给 Agent 的依赖注入故障传统 SRE 说我们随机杀死服务器证明系统能扛住故障。Agent SRE 说我们向 Agent 的依赖注入故障——慢速 LLM 响应、工具报错、上下文损坏——证明 Agent 能优雅降级。AI Agent 的混沌测试不止于基础设施故障你需要测试这些场景LLM 以 5 秒延迟而不是 500ms响应工具调用返回错误或垃圾数据上下文被截断或损坏Agent 的内存不可用链中的下游 Agent 不可达from agent_sre.chaos.engine import ChaosExperiment, Fault, AbortCondition # 定义实验 experiment ChaosExperiment( namellm-latency-spike, descriptionWhat happens when the LLM takes 5x longer?, duration_seconds300, blast_radius0.5, # 影响 50% 的请求 abort_conditions[ AbortCondition(metricsuccess_rate, threshold0.80, comparatorlte), ], ) # 定义要注入的故障 latency_fault Fault.latency_injection( targetllm-provider, delay_ms5000, rate0.5, ) # 运行实验 experiment.start() experiment.inject_fault(latency_fault, appliedTrue, details5s latency added) # 评估韧性 score experiment.calculate_resilience( baseline_success_rate0.95, experiment_success_rate0.88, ) print(fResilience score: {score.score}/100 ({PASS if score.passed else FAIL}))源码透视故障注入的内置原语混沌引擎源码 提供了四类开箱即用的故障构造器Fault.latency_injection(target, delay_ms5000, rate1.0)—— 注入延迟Fault.error_injection(target, errorinternal_error, rate1.0)—— 注入错误返回Fault.timeout_injection(target, delay_ms30000, rate1.0)—— 注入超时Fault.prompt_injection(target, techniquedirect_override, rate1.0)—— 注入对抗性提示词对应 OWASP 提示注入场景。此外chaos_scheduler.py 提供ChaosScheduler支持按 cron 调度实验、配置黑窗blackout、按严重度渐进加压并记录每次执行的韧性趋势adversarial.py 与 adversarial_policy.py 则将混沌测试扩展到对抗性攻击剧本AttackPlaybook与对抗策略评估。可运行示例见 examples/chaos_test.py配套测试在 tests/test_chaos.py 与 tests/test_chaos_scheduler.py。金丝雀发布先让 5% 的真实流量试新模型传统 SRE 说把 5% 的流量路由到新版本服务器。如果错误率飙升回滚。Agent SRE 说把 5% 的流量路由到新模型/新提示词。如果幻觉率上升或准确率下降自动回滚。金丝雀发布对 AI Agent 至关重要因为模型升级和提示词变更可能带来不可预测的回归——一个在基准测试上表现更好的模型可能在你特定的工作负载上表现更差。from agent_sre.delivery.rollout import CanaryRollout, RollbackCondition, RolloutStep rollout CanaryRollout( nameassistant-v2, steps[ RolloutStep(weight0.05, duration_seconds60, name5% canary), RolloutStep(weight0.25, duration_seconds120, name25% ramp), RolloutStep(weight1.0, duration_seconds0, namefull rollout), ], rollback_conditions[ RollbackCondition(metricerror_rate, threshold0.10, comparatorgte), RollbackCondition(metrichallucination_rate, threshold0.08, comparatorgte), ], ) rollout.start() # 每个阶段评估候选版本 metrics evaluate_new_version() if rollout.check_rollback(metrics): rollout.rollback(reasonHallucination rate exceeded threshold) else: rollout.advance()发布策略的工程支撑delivery 模块 不只提供金丝雀rollout.py定义了DeploymentStrategy部署策略枚举与RolloutState状态机blue_green.py 提供蓝绿发布支持deploy → validate(health_check_fn) → switch → rollback的完整生命周期gitops.py 则提供声明式RolloutSpec校验与default_canary/default_shadow模板生成。这些机制共同覆盖模型/提示词这一新型部署物件的灰度与回滚诉求。示例与测试分别见 examples/canary_rollout.py 与 tests/test_delivery.py、tests/test_blue_green.py。熔断器阻止多 Agent 系统的级联雪崩传统 SRE 说如果下游服务失败 5 次停止调用它 30 秒。Agent SRE 说如果 Agent 失败 5 次停止向它路由任务并使用兜底方案。熔断器阻止多 Agent 系统中的级联失败。当 Agent A 依赖 Agent B、而 B 开始失败时熔断器阻止 A 继续向 B 发送注定失败的请求转而返回兜底响应。三种状态CLOSED (正常) → 失败超过阈值 → OPEN (阻断) ↓ 超时到期 ↓ HALF_OPEN (试探) ↓ ↓ 成功 失败 ↓ ↓ CLOSED OPENfrom agent_sre.cascade.breaker import CircuitBreaker, CircuitBreakerConfig breaker CircuitBreaker( agent_idresearch-agent, configCircuitBreakerConfig( failure_threshold5, # 5 次失败后打开 recovery_timeout_seconds30, # 30 秒后再试 half_open_max_calls1, # 允许 1 次试探调用 ), ) # 用熔断器包裹 Agent 调用 result breaker.call( funcresearch_agent.run, querysummarize this paper, fallbackUnable to process request. Please try again later., ) # 熔断器自动 # - 跟踪成功与失败 # - 连续 5 次失败后打开熔断 # - 打开时抛出 CircuitOpenError或返回兜底 # - 30 秒后放行一次试探调用检查恢复源码透视状态机、同步/异步与级联检测CircuitBreaker 实现 有几个值得注意的工程细节配置兼容CircuitBreakerConfig同时接受规范名recovery_timeout_seconds与旧别名reset_timeout_seconds兼容agent_os.circuit_breaker旧 API两者不一致时抛ValueError状态机CircuitState为CLOSED / OPEN / HALF_OPEN_maybe_transition_to_half_open()在 OPEN 状态下按recovery_timeout_seconds到期自动转 HALF_OPENHALF_OPEN 下成功即回 CLOSED失败立即回 OPEN同步/异步双支持call()对返回 awaitable 的结果会包装为协程并自动在协程成功/失败时调用record_success()/record_failure()因此breaker.call(awaitable_fn)在异步调用方中可直接await兜底语义OPEN 状态且传入fallback时直接返回兜底值否则抛出CircuitOpenError内含agent_id与retry_after便于上层降级提示级联检测同一文件还提供CascadeDetector可注册多个 Agent 的熔断器当处于 OPEN 的 Agent 数达到cascade_threshold默认 3时判定发生级联失败对应 OWASP ASI08。测试见 tests/test_circuit_breaker.py 与 tests/test_cascade.py。事件管理把多个信号关联成一次事故传统 SRE 说PagerDuty 告警 → 值班工程师 → Runbook → 事后复盘。Agent SRE 说检测到 SLO 违约 → 信号关联 → 创建事件 → 自动执行 runbook → 通知团队。Agent SRE 通过关联多个信号来检测事件——一次 SLO 违约 一次成本飙升 一次延迟升高很可能是一次事故而不是三个独立告警。from agent_sre.incidents.detector import IncidentDetector, Signal, SignalType detector IncidentDetector(correlation_window_seconds60) # 从不同来源接入信号 signal Signal( signal_typeSignalType.SLO_BREACH, sourcecustomer-support-agent, messageTask success rate dropped below 95% target, ) incident detector.ingest_signal(signal) if incident: print(f Incident: {incident.title}) print(f Severity: {incident.severity.value}) # P1, P2, P3, P4 incident.acknowledge() # ... 执行修复 ... incident.resolve()Agent SRE 监控的信号类型信号触发条件SLO_BREACH违反 SLO 目标ERROR_BUDGET_EXHAUSTED错误预算完全耗尽COST_ANOMALY花费超过 z-score 阈值LATENCY_SPIKE响应时间超过基线TOOL_FAILURE_SPIKE工具调用失败率飙升POLICY_VIOLATIONAgent 违反治理策略TRUST_REVOCATIONAgent 信任分下降经 AgentMesh源码透视事件检测器的信号关联逻辑从 detector.py 的实现可以看到信号到严重度的自动映射Signal.severity_hint将ERROR_BUDGET_EXHAUSTED / POLICY_VIOLATION / TRUST_REVOCATION映射为 P1SLO_BREACH / COST_ANOMALY / LATENCY_SPIKE映射为 P2其余为 P3事件只对 P1/P2 信号创建P3/P4 信号仅记录不建事件避免噪音去重与关联dedup_window_seconds默认 600s内同源同类型信号不重复建事件correlation_window_seconds默认 300s内来自同一来源的不同类型信号会被合并为Correlated事件取最高严重度、自动应用所有信号类型注册的响应动作通过register_response(signal_type, actions)注册事件创建时自动执行并标记auto-triggered事件生命周期Incident内置DETECTED → ACKNOWLEDGED → INVESTIGATING → MITIGATING → RESOLVED状态机duration_seconds自动统计从检测到解决的时间。测试见 tests/test_incidents.py事件运行手册runbook相关支持可查看 src/agent_sre/incidents 目录下的其他模块与 tests/test_runbooks.py。传统 SRE → Agent SRE 映射表传统 SREAgent SRE为什么不同Uptime服务器在跑吗Response quality答案对吗返回 200 但内容幻觉不算在线Request latencyp50, p99Token latency首 token 时间、总生成时间LLM 推理与 CRUD API 的延迟画像不同Error rate5xx 响应Hallucination rate编造信息编造一条假引用没有 HTTP 状态码Throughput请求/秒Task completion rate任务/小时Agent 任务是多步骤的不是单次请求-响应CPU/MemoryToken usage / Cost per task昂贵资源是 LLM 推理而非算力Deployment rollbackModel/prompt rollback回滚的是提示词变更不是二进制产物Circuit breaker服务→服务Circuit breakerAgent→AgentAgent 失败是语义性的不只是超时Canary deployment5% 服务器Canary deployment5% 流量到新模型全量上线前先用真实流量试新模型Chaos testing杀一台服务器Chaos testing注入 LLM 延迟、工具错误测试 Agent 对依赖故障的韧性Runbook重启服务、扩容Runbook切换模型、禁用工具、限流修复动作发生在模型/提示词层而非基础设施层SLO99.9% 可用性SLO95% 任务成功、5% 幻觉多维质量 成本 安全Error budget每月 43 分钟宕机Error budget每月 5% 坏响应预算花在坏答案上不是宕机上On-call rotationAgent-aware on-call告警携带 Agent 上下文、追踪与决策日志快速上手30 行代码跑通完整 SRE 闭环下面是一个完整示例——定义 SLO、设置成本护栏、检测事件全部在 30 行内完成Monitor an AI agent with SRE best practices. from agent_sre import SLO, ErrorBudget from agent_sre.slo.indicators import TaskSuccessRate, CostPerTask, HallucinationRate from agent_sre.cost.guard import CostGuard from agent_sre.cascade.breaker import CircuitBreaker, CircuitBreakerConfig from agent_sre.incidents.detector import IncidentDetector, Signal, SignalType # ── 1. 定义可靠意味着什么 ──────────────────────────────────── success TaskSuccessRate(target0.95, window24h) cost CostPerTask(target_usd0.50, window24h) hallucination HallucinationRate(target0.05, window24h) slo SLO( namemy-agent, indicators[success, cost, hallucination], error_budgetErrorBudget(total0.05, burn_rate_critical10.0), ) # ── 2. 设置成本护栏 ───────────────────────────────────────────── guard CostGuard( per_task_limit2.00, per_agent_daily_limit50.0, org_monthly_budget1000.0, ) # ── 3. 为下游 Agent 添加熔断器 ────────────────────────────────── breaker CircuitBreaker( agent_idmy-agent, configCircuitBreakerConfig(failure_threshold5, recovery_timeout_seconds30), ) # ── 4. 接入事件检测 ───────────────────────────────────────────── detector IncidentDetector(correlation_window_seconds60) # ── 5. 带着 SRE 护栏运行你的 Agent ────────────────────────────── def run_agent_task(query: str): # 检查成本预算 allowed, reason guard.check_task(my-agent, estimated_cost0.50) if not allowed: return fBlocked: {reason} # 通过熔断器执行 result breaker.call( funcyour_agent.run, queryquery, fallbackService temporarily unavailable., ) # 记录 SLI 观测 is_good evaluate_response(result) success.record_task(successis_good) slo.record_event(goodis_good) guard.record_cost(my-agent, task-1, cost_usd0.35) # 检查 SLO 健康状态 status slo.evaluate() if status.value EXHAUSTED: signal Signal( signal_typeSignalType.ERROR_BUDGET_EXHAUSTED, sourcemy-agent, messageError budget consumed — freeze deployments, ) detector.ingest_signal(signal) return result安装与运行# 在 agent-governance-python/agent-sre 目录下仓库内源码安装 pip install -e .[dev] python examples/quickstart.py仓库内的可运行版本见 examples/quickstart.py它模拟 100 次任务刻意让成功率低于 95% 目标、幻觉率高于 5% 目标演示 SLO 状态评估、预算剩余、燃烧率、成本护栏与事件创建的完整输出。包发布与源码布局说明需要说明的是agent-sre已随 Agent Governance Toolkit 的包整合迁移。当前 agent-sre/pyproject.toml 是一个弃用占位包dep-only deprecation stub发布时只依赖并重定向到agent-governance-toolkit-cliagent_sre顶层包源码由 agent-governance-toolkit-cli 在构建时通过 force-include 从../agent-sre/src/agent_sre合入。因此在仓库内开发测试请使用pip install -e可编辑安装方式直接引用源码树发布安装则统一走agent-governance-toolkit-cli其提供的agent-sre控制台入口指向agent_sre.cli.main:cli并支持docker / hyperlight / policy / mcp / api / otel / langchain / langfuse等丰富的可选依赖组。成本护栏的实战深化CostGuard 的预算层级与异常检测快速上手示例里只展示了CostGuard的基本用法这里补充其完整能力源码见 guard.py三层预算单任务上限per_task_limit默认 $2.0、单 Agent 日限额per_agent_daily_limit默认 $100、组织月预算org_monthly_budget默认 $5000check_task()返回(allowed, reason)元组reason 明确说明被拦截原因原子化检查并扣费文档示例使用的check_task()是咨询性检查不预留预算并发场景可能超限对预算敏感路径应改用check_and_charge()它在同一把锁内完成检查 记账杜绝并发穿透阈值告警与自动限流/熔断默认在日预算消耗 50% / 75% / 90% / 95% 时告警alert_thresholds可自定义auto_throttleTrue时利用率 ≥85% 自动THROTTLE达到kill_switch_threshold默认 0.95自动KILL组织月预算同样触发全局 kill switch一次性熔断所有 AgentZ-score 异常检测anomaly_detectionTrue默认开启时基于最近 1000 条成本记录的历史对 z-score 2.0 的单笔成本触发COST_ANOMALY告警——这正是事件检测信号表中COST_ANOMALY的底层来源输入防护所有数值参数在构造时校验isfinite与非负kill_switch_threshold与各阈值必须落在 [0,1]防止 NaN/Inf/负数破坏预算状态。配套测试见 tests/test_cost.py 与 tests/test_cost_hardened.py。从概念到生产进一步阅读SRE 基础Google SRE Book —— Site Reliability Engineering 的权威指南Google SRE Workbook —— 实践案例与练习The Art of SLOs —— 如何设定有意义的 SLOAgent SRE 文档仓库内getting-started.md —— 安装并定义你的第一个 SLOconcepts.md —— Agent SLI 与基础设施指标的区别slo-reference.md —— 完整 SLO 配置指南与模板integration-guide.md —— 与 LangChain、CrewAI、LangGraph 等框架集成deployment.md —— 生产部署模式security.md —— Agent 可靠性的安全考量示例代码仓库内examples/quickstart.py —— 30 行完整可运行示例examples/canary_rollout.py —— 自动回滚的安全模型升级examples/cost_guard.py —— 预算强制与异常检测examples/chaos_test.py —— 面向 Agent 依赖的故障注入examples/slo_alerting.py —— 多渠道告警路由生态关联agent-governance-python/agent-mesh —— 多 Agent 系统的身份与信任提供TRUST_REVOCATION信号来源agent-governance-python/agent-os —— AI Agent 治理内核docs/compliance/owasp-agentic-top10-mapping.md —— Agent SRE 如何对应 OWASP Agentic Top 10含 ASI08 级联失败说明本文引用的外部 Google SRE 链接均出自原文档Further Reading一节仅作背景阅读指引仓库内的实现与示例请以本文给出的相对路径为准。【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考