★ FEATURED ARTICLE 1. 凌晨三点的告警和一套能自己查故障的 AgentAI SRE Agent 自动故障排查架构说白了就是让大模型带着一套受控工具去干值班工程师最烦的那部分活告警进来之后自动拉指标、翻日志、查部署记录、比对历史复盘把根因和修复方案整理好最后交给人审批。它适合运维团队、平台工程团队以及任何被告警风暴和无效噪声折磨过的 SRE。可控、安全、可落地这三个词不是口号而是这套架构能不能进生产的分水岭——模型再聪明只要工具权限没有边界、变更没有人工终审就不该让它碰生产环境。我试过在模拟微服务环境里跑通整条链路从告警触发到生成修复 PR 大概两分钟但真正花时间的不是推理而是把配置骨架、Key 通道、验证清单这些工程细节钉死。这篇就把这套骨架拆开一份可复制的config.toml、一份settings.json、TaoToken 统一 Key/API 通道的接入配置以及三步验证动作——连通性自检、故障注入回放、告警闭环确认。你照着填参数就能跑起来重点在每一步的边界和排错。2. 前置用 TaoToken 统一 Key 和 API 通道AI SRE Agent 的推理层要调大模型工具层要调可观测性接口如果每个组件各自管一套 Key轮换和审计会变成灾难。我的做法是把模型调用统一走 TaoToken 的 API 通道一个 Key 覆盖对话、编码、Agent 场景控制台里能看用量和调用记录排查“到底是模型超时还是工具超时”时省很多事。接入前先确认两件事一是你的 Agent 进程能访问https://taotoken.net/api二是 Key 存在环境变量里而不是硬编码进配置文件。控制台创建 Key 的入口在 API Keys模型能力对照和参数说明看 接入文档。如果你后面要跑长期编码或 Agent 循环Coding Plan 更适合高频调用只是验证模型输出质量用 模型对话 先试几轮。注意Key 只放环境变量配置文件里用${TAOTOKEN_API_KEY}占位。任何把 Key 写进 Git 仓库的做法后面审计都过不了。3. 可复制配置config.toml 与 settings.json 骨架3.1 config.toml推理层与工具层分离这份config.toml的核心思路是推理层和工具层各管各的模型只负责分析工具只负责采集和受限写入。[llm]段走 TaoToken 通道[tools]段定义只读诊断和受限写入两类工具的边界。# config.toml - AI SRE Agent 主配置骨架 [agent] name sre-agent mode semi-autonomous # 半自治AI 排查人工终审 max_reasoning_steps 12 # 单次故障推理步数上限防死循环 timeout_seconds 180 # 单次调查总超时 [llm] provider taotoken base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY # 从环境变量读取不落盘 model claude-sonnet # 按接入文档选可用模型 temperature 0.1 # 排障场景要稳定别放飞 max_tokens 4096 [llm.retry] max_attempts 3 backoff_seconds 2 [tools.readonly] enabled true # 只读诊断工具只采集、查询、分析无任何修改 metrics [prometheus_query, prometheus_range] logs [container_logs, k8s_events] deploy [deploy_history, config_diff] knowledge [runbook_search, incident_history] [tools.write_restricted] enabled true # 受限写入作用域写死越权直接拒绝 config_edit_scope config/ # 仅允许改 config 目录 branch_prefix fix/ # 只能建修复分支 allow_pr_create true allow_pr_merge false # 禁止自动合并 allow_deploy false # 禁止自动上线 [tools.shell] # 黑白名单双重管控 allowlist [ docker-compose ps, docker-compose logs, docker-compose restart ] denylist [ rm, curl, chmod, kubectl delete, terraform apply ] [guardrail] # 前置校验钩子独立于模型推理运行 pre_write_hook ./hooks/validate_change.sh require_human_approval true forbidden_actions [ db_migration, data_purge, infra_destroy, secret_rotate, iam_change, network_rule_change ]几个参数值得单独说。max_reasoning_steps是防死循环的保险丝模型有时候会在“再查一个指标”里绕圈12 步基本够覆盖配置错误、连接池耗尽这类高频故障。temperature 0.1是因为排障要的是稳定复现不是创意。allow_pr_merge和allow_deploy必须为false这是人工终审的底线改这两个值等于把安全护栏拆了。3.2 settings.json知识层与告警闭环settings.json管的是 RAG 知识层和告警闭环。实时状态层靠只读工具采集组织知识层靠 RAG 检索两者互补——遥测数据告诉你“发生了什么”运行手册告诉你“这意味着什么”。{ knowledge: { source: git, repo: gitinternal:sre/runbooks.git, format: markdown, chunk_size: 512, vector_store: local, sync: { mode: ci, on_update: reindex } }, alerting: { source: pagerduty, route_by: service_metadata, dedup_window_seconds: 300, noise_filter: { enabled: true, min_severity: warning } }, closure: { require_metric_recovery: true, postmortem_auto_generate: true, notify_channel: slack, approval_buttons: [approve, reject, modify] }, audit: { log_tool_calls: true, log_llm_prompts: false, retention_days: 90 } }dedup_window_seconds是压告警风暴的关键同一服务五分钟内的衍生告警会被合并成一条调查任务。require_metric_recovery保证闭环确认不是靠“感觉好了”而是指标真的回归正常。log_llm_prompts我默认关掉因为提示词里可能带日志片段落盘有泄露风险需要时再临时开。4. 三步验证连通性、故障注入、告警闭环配置填完不代表能跑必须按顺序验证。跳过连通性直接注入故障你分不清是模型没通还是工具没通。4.1 连通性自检先确认 TaoToken 通道和工具通道都能通。写一个最小自检脚本别一上来就跑完整 Agent。# 1. 检查环境变量 test -n $TAOTOKEN_API_KEY echo key ok || echo key missing # 2. 检查 API 通道连通性 curl -s -o /dev/null -w %{http_code}\n \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ https://taotoken.net/api/models # 3. 检查只读工具 python -m sre_agent.tools.check --tool prometheus_query python -m sre_agent.tools.check --tool container_logs # 4. 检查前置校验钩子可执行 test -x ./hooks/validate_change.sh echo hook ok返回200说明 Key 和通道没问题工具检查会打印每个只读工具的连通状态。如果curl返回401去 API Keys 确认 Key 没过期返回超时则先查网络出口别急着改配置。4.2 故障注入回放连通性过了注入一个真实高频故障把数据库连接池配置从DB_POOL_SIZE20改成DB_POOL_SIZE1x模拟配置失误引发的连锁故障。这个故障的特点是表象复杂——连接池耗尽导致请求堆积、多服务延迟飙升、衍生告警一堆人工排查至少十几分钟。# 注入故障 kubectl set env deployment/order-service DB_POOL_SIZE1x # 触发 Agent 调查模拟告警 python -m sre_agent.trigger \ --alert order-service latency high \ --severity critical \ --dry-run false # 观察推理链路 tail -f logs/agent-reasoning.log预期结果是 Agent 依次调取 Prometheus 指标、容器日志、部署记录锁定DB_POOL_SIZE配置错误生成修复分支和 PR然后停在待审批状态。如果它直接尝试合并或部署说明allow_pr_merge/allow_deploy没生效立刻停下来查配置。4.3 告警闭环确认最后一步验证闭环修复方案审批后指标是否回归正常复盘报告是否自动生成。# 审批修复 PR 后确认指标恢复 python -m sre_agent.verify --service order-service \ --metric db_pool_utilization --expect below 0.8 # 确认复盘报告生成 ls reports/postmortem/ | grep order-serviceverify会检查连接池利用率是否回落到阈值以下require_metric_recovery true时这一步不通过就不算闭环。复盘报告里应该包含时间线、根因、受影响服务、监控漏洞和优化建议——比如这次会指出“缺少连接池利用率专项告警”。5. 本篇常见错排查报错一401 Unauthorized或invalid api key。九成是环境变量没加载或者 Key 里带了空格。先echo $TAOTOKEN_API_KEY | wc -c看长度对不对再确认配置文件里用的是${TAOTOKEN_API_KEY}而不是写死的字符串。报错二Agent 推理到一半卡住日志停在某个工具调用。大概率是工具超时没设或者max_reasoning_steps太小导致提前截断。把timeout_seconds调到 180 以上同时检查对应工具的健康状态。如果卡在 RAG 检索看向量库是否完成了索引同步。报错三前置校验钩子没拦住越权写入。检查pre_write_hook路径是否可执行以及钩子脚本的退出码——非零才会拦截。很多人钩子写了但没chmod x等于没装。报错四告警风暴没被去重Agent 被同一故障触发多次。调大dedup_window_seconds并确认route_by用的服务元数据字段和告警源一致。字段对不上去重逻辑就失效。报错五复盘报告里根因写错把正常波动判成故障。这是 RAG 检索到了弱关联文档导致的。给文档加有效校验日期优先调最新版本同时让 Agent 在报告里标注参考了哪份文档方便人工核验。6. 把 Key 通道和验证清单钉死再谈自治这套架构能不能落地不取决于模型多强而取决于三件事有没有钉死Key 通道统一走 TaoToken、工具权限有明确边界、每一步验证都有可复现的命令。连通性自检、故障注入回放、告警闭环确认这三步跑通你才算有了一个可控的骨架后面再往上加多告警过滤、K8s 崩溃循环排查这些场景才有意义。长期跑 Agent 循环的话Coding Plan 比按次调用更稳接入细节和参数对照随时查 接入文档Key 管理和用量看 控制台。先把config.toml里的allow_pr_merge和allow_deploy确认成false再去注入你的第一个故障。
阅读完成 · 觉得有帮助？
