HN讨论 · 身份未知
事故响应中的 LLM 代理：处理海量遥测数据并保持人工审批
一家处理 PB 级数据的 SaaS 的 SRE 团队在事故响应中试验 claude、openclaw、langchain 等工具，遭遇上下文溢出、幻觉、token 消耗和批准疲劳，并坚持不在生产环境放宽权限；为此他们开源了 Rust 代理 AURA，以限定域 worker 和确定性工具权限支撑调查与修复。
查看原始信号hn:49538195
目标用户
运行大规模 SaaS、需要处理海量遥测数据并快速定位生产事故根因的 SRE/值班工程师
潜在需求
需要一种能处理大规模遥测数据的事故调查代理：工具权限在 agent 上下文之外确定性受控，敏感操作保留人工审批，同时避免上下文溢出和过高 token 消耗。
发生场景
事故响应工作流中，值班 SRE 需要跨日志、指标、Git/SCM 等多个领域协调调查；团队曾用 claude、openclaw、langchain 等工具，但遇到上下文溢出、幻觉、token 消耗大，审批流程令人疲惫，且不能接受在生产环境放宽权限。
来源证据
一家处理 PB 级数据的 SaaS 的 SRE 团队在事故响应流程中试验 claude、openclaw、langchain 等工具，遇到上下文溢出、幻觉和大量 token 消耗，面临批准疲劳，且拒绝在生产环境放宽权限。
We run a SaaS that handles petabytes of data. Our SRE team experimented with using claude, openclaw, langchain, etc. within our incident response workflows. We struggled with overflowing context, lethal trifecta vectors, hallucinations, and burned a lot of frontier tokens mostly on easy work. Approval fatigue was a challenge, and we drew a hard line at relaxing permissions in production. Long story short, we built and open-sourced AURA, a Rust-based harness specifically designed for the type ofhttps://news.ycombinator.com/item?id=49538195
为什么值得留意
该信号来自有实际使用经验的 SRE 团队，记录了现有 LLM 工具在真实事故响应中的具体缺口（上下文、权限、审批），并开源了可复现的解法；作者还主动列出异步输入和入站 webhook 中断等未完成部分，表明需求仍在演进。
已有方案
- claude
- openclaw
- langchain
未满足部分
- 作为服务运行时缺少成熟的异步输入系统
- 缺少入站 webhook 中断机制，自动化事故响应需要外部中间件或轮询 MCP 触发
- 高可用部署选项尚未完成
可能延伸 · 模型推测
- 把告警触发统一为入站 webhook 或 MCP 接口，减少中间件
- 为异步调查增加任务队列与进度订阅，便于集成到值班工作流
- 将人工审批节点扩展为跨平台通知和远程确认
目前未知
- 帖子来自项目作者，描述带有立场，缺少独立用户验证
- 未说明 open-weights 模型根因准确度的具体评测方式和样本规模
- 没有外部采用或贡献数据，无法判断该方案在实际环境中的接受度
继续核实
- AURA 在真实事故响应中相比通用 LLM 编排方案的落地效果如何？
- 人工审批环节在自动化调查中是否仍然是效率瓶颈？
- 缺少入站 webhook 触发是否限制了它在告警自动接入场景的采用？
主题词
incident responsetelemetry data analysiscontext window managementllm agent permission controlhuman-in-the-loop approval