OneUptime AI Agent 深度实战用「Fix with AI」把未处理异常一键变成可评审的 Pull Request【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文是一份面向 OneUptime 用户的 AI 代码修复AI Code Fix / AI Fix Task实战指南。它讲解 OneUptime 如何将一条未解决的异常exception自动转成一份可评审的 Pull Request——从 Runner 认领任务、克隆仓库、代码智能体修复到合并前的构建/测试验证与预算控制。读完本文你将掌握完整修复链路的工作原理、三类前置条件的配置方法LLM Provider、GitHub App、Runner以及失败处理、自动修复策略和数据隐私边界并能结合仓库源码理解每一步的底层实现。从一次异常到一份 PRAI Fix Task 的完整工作流OneUptime 的核心思路很直接把一条未解决的异常交给 AI产出一份由人类评审的 Pull Request。在任意未解决异常的异常详情页上点击Fix with AI即可触发一次修复任务Fix Task。官方文档 ai-agent.md 给出了完整流程你在未解决异常上点击Fix with AI。系统创建一条修复任务由具备Runs AI Code Fixes能力的空闲 Runner 认领。Runner 拉取异常详情——异常类型exception type、错误信息error message与堆栈追踪stack trace。Runner 将关联仓库克隆进一个临时工作区ephemeral workspace并创建分支分支名以oneuptime-fix-exception-开头后接 run id 的前几个字符。一个由你项目 LLM Provider 驱动的代码智能体code agent分析代码库并写出修复。LLM 调用由 OneUptime 服务器代理执行——Runner 容器内永远不会持有你的 Provider API Key每一次调用都会被计量并记录在 AI 日志中。如果仓库配置了验证命令Runner 会在提交前先构建和测试修复把任何失败反馈给代码智能体进行修补详见下文「合并前的验证」。Runner 提交、推送分支、打开 Pull Request然后删除工作区。从源码看异常修复任务对应 Runner/TaskHandlers/FixExceptionTaskHandler.ts 中的FixExceptionTaskHandler类其关键常量与文档描述一一对应branchPrefix: string oneuptime-fix-exception-——即文档所述的分支命名规则提示词prompt由异常类型、错误信息和完整堆栈追踪拼接而成并明确要求「仅做最小且聚焦的修改、保留既有代码风格、不删除或削弱任何输入校验/认证/授权/限流检查」等硬性规则同时建议把异常消息中动态插值的内容参数化避免同一根因被拆散成多个异常分组。异常页面会实时展示任务状态在AI Tasks下的任务详情页保留完整运行日志——包括 Runner 读取或写入的每个文件、执行的每条命令——并链接到该任务打开的所有 Pull Request。单次运行的预算上限每次修复运行由服务端强制施加循环预算单次运行最多 40 次 LLM 调用、最多 100,000 输出 token。命中预算的运行会以「已完成工作摘要」收尾而不是无限循环下去。修复运行同时计入项目「每日自主 AI token 预算」若已设置。源码侧Runner/CodeAgents/InHouseCodeAgent.ts 中MAX_COMPLETION_CALLS: number 40正是文档所述「40 次 LLM 调用」上限的实现Common/Server/Services/AIService.ts 则承担每日自主预算的计量与执行executeWithLogging会逐次检查余额与预算自治特性在预算耗尽时按「失败关闭」处理。合并前的验证Setup / Build / Test 三段式闸门在Code Repositories的设置页每个代码仓库最多可以配置三条验证命令——Setup Command、Build Command和Test Command例如npm ci、npm run build、npm test。只要配置了任意一条每次修复运行都会在 PR 打开前验证改动代码智能体完成修改后三条命令**按顺序setup → build → test**在 Runner 上、克隆的工作区内、仓库根目录下执行。每条命令最多 15 分钟并且以CItrue运行避免等待交互式提示第一个失败即停止整个验证过程。一旦失败失败命令的输出尾部会被回传给同一个代码智能体作为一次修复任务repair task——指令是修复它自己的改动而不是削弱或跳过测试——然后重新执行验证命令。最多进行2次修复尝试修复轮次共享本次运行的 LLM 预算修复产生的编辑与原始修复落在同一个 commit里。验证结果——Passed、Failed或Skipped未配置任何命令——会写入 Pull Request 正文的Verification小节并记录在该任务的 PR 记录上。即使修复仍然未通过验证也不会被丢弃PR 照常打开正文带有明确标注的Verification failed小节包含失败的命令与输出尾部——工作成果被保留由人类评审者决定去留。仓库未配置命令时则如实报告为Skipped而不是暗示构建是绿的。这些验证命令是运维人员编写并保存在仓库配置中的在你自己部署的 Runner 上执行——信任模型与 runbook 的 Bash 步骤一致。AI 永远不会编写或修改这些命令。从源码看这一整套闸门实现在 Runner/Utils/BuildVerification.tsVERIFICATION_COMMAND_TIMEOUT_MS 15 * 60 * 1000——每条命令 15 分钟墙钟上限MAX_REPAIR_ATTEMPTS 2——最多 2 次修复尝试HEARTBEAT_INTERVAL_MS 2 * 60 * 1000——长命令执行期间每 2 分钟上报一次心跳以保持在服务端 12 分钟 stale-run 清扫窗口内见 App/FeatureSet/Workers/Jobs/AIChat/TimeoutStuckRuns.ts 中的RUN_HEARTBEAT_TIMEOUT_MINUTES 12避免构建/测试期间运行被误判为超时失败OUTPUT_TAIL_CHARS 8000——保留失败命令输出尾部编译器错误与测试失败信息所在回灌给修复提示词文件头注释还强调验证循环永不阻塞 PR仍然失败就带标注打开 PR——与文档描述完全一致。前置条件一LLM Provider一条修复任务能跑起来之前需要三件事就位。异常页面会在创建任务前一次性检查全部三项并展示就绪清单readiness checklist让你清楚地看到还缺什么。OneUptime Cloud零配置如果你的项目没有自己的 LLM Provider智能体任务默认使用共享的全局 Provider用量按计量 AI token 计费——与所有其他 AI 功能一致。若想使用自己的密钥在Project Settings AI LLM Providers下配置即可项目自有 Provider 永远优先于全局 Provider。自托管通过环境变量零配置自托管实例上最快捷的方式是在 OneUptime 服务器上一次性设置GLOBAL_LLM_PROVIDER_*环境变量Docker Compose 写入config.env或通过 Helm values。启动时 OneUptime 会自动注册全局 Provider所有项目的所有 AI 功能包括智能体任务都会使用它。以本地 Ollama 为例GLOBAL_LLM_PROVIDER_TYPEOllama GLOBAL_LLM_PROVIDER_BASE_URLhttp://your-ollama-host:11434 GLOBAL_LLM_PROVIDER_MODEL_NAMEllama3 # No GLOBAL_LLM_PROVIDER_API_KEY needed — Ollama is keyless.完整的变量清单与支持范围见 llm-provider.mdGLOBAL_LLM_PROVIDER_TYPE支持OpenAI、AzureOpenAI、Anthropic、Groq、Mistral、Ollama、OpenAICompatibleAPI_KEY对 OpenAI/Azure OpenAI/Anthropic/Groq/Mistral 为必填对 Ollama 与免密钥的 OpenAI 兼容服务器不需要BASE_URL对 Azure OpenAI、Ollama、OpenAI 兼容服务器为必填MODEL_NAME对 OpenAI 兼容服务器必填其余推荐填写NAME为可选显示名。变量采用声明式同步修改变量并在下次重启后生效取消GLOBAL_LLM_PROVIDER_TYPE即移除该 Provider手动创建在 Admin Dashboard 的全局 Provider 不会被触碰。需要特别提醒的是OneUptime 的 AI 功能是agentic自主智能体的重度依赖工具调用tool calling。请使用llama3.1或更新版本或其他支持工具调用的模型小模型或不支持工具调用的模型如llama2、最初的llama3会产生很差的结果——它们无法查询你的监控器、事件或遥测数据调查结果会是空的或幻觉出来的。就绪检查的源码实现从源码看LLM Provider 就绪检查位于 Common/Server/Utils/AI/CodeFix/CodeFixReadiness.ts 的getLlmProviderCheck()它解析出该路径下最终使用的 ProvidergetLlmProviderForMeteredAgentPath随后做三重判断——Provider 是否存在、在 Cloud 计量模式下项目 AI 余额是否非空、每日自主 token 预算是否耗尽。因此「用共享 Provider」与「项目自有 Provider」在检查中的提示也不同前者会显示计量计费说明后者提示「在你的 API Key 上运行、不消耗 AI 余额」。前置条件二通过 GitHub App 连接 GitHub在Code Repositories下使用Connect with GitHub App连接 GitHub——安装 App 会自动导入其所有仓库并保持同步。GitHub App 是 Runner 唯一能推送代码的通道GitLab 在路线图上。你不需要手动把仓库映射到服务OneUptime 在修复时自动解析正确的仓库——用异常的堆栈追踪文件路径去匹配已连接的仓库回退到仓库名匹配当项目恰好只有一个仓库时直接使用该仓库。异常页面上的就绪清单会显示解析到了哪个仓库。源码对应 CodeFixReadiness.ts 的getRepositoryConnectedCheck()项目级检查只断言「至少存在一个通过 GitHub App 连接的仓库」这一较弱条件刻意不对「某条异常是否匹配得上」作断言注释同时说明只有 GitHub 受支持智能体的克隆/推送路径会拒绝其他所有托管平台见 AIAgentDataAPI 的repositoryHostedAt守卫。前置条件三启用 AI Code Fix 的 RunnerOneUptime Cloud共享 Runner 集群自动可用无需任何部署。自托管Runner 容器默认运行——Docker Compose 安装包含runner服务Helm chart 默认部署它runner.enabled默认true。它会自动注册到你的实例无需复制任何凭据开箱即可处理 AI 代码修复。未配置 LLM Provider 时 Runner 以低成本空闲运行任务会提前失败并给出引导提示直到配置好 Provider。如需在别处运行额外的 Runner例如放在离你的仓库更近的机器上在Settings Runners下创建一个 Runner点击该行上的Show setup instructions获取预填好的安装命令。Key 只显示一次——请安全保存。命令形如docker run --name oneuptime-runner --restart unless-stopped \ -e ONEUPTIME_RUNNER_IDrunner-id \ -e ONEUPTIME_RUNNER_KEYrunner-key \ -e ONEUPTIME_URLyour-oneuptime-url \ -d oneuptime/runner:release在该 Runner 上启用Runs AI Code Fixes——该能力默认关闭Runner 会在下一次心跳约 1 分钟时采用该变更无需重启。任何容器运行方式Docker Compose、Kubernetes 等都可行只要设置好以下环境变量且容器能通过 HTTPS 访问你的 OneUptime 实例变量说明ONEUPTIME_RUNNER_ID仪表盘中的 Runner idONEUPTIME_RUNNER_KEY创建 Runner 时显示的 Runner KeyONEUPTIME_URL你的 OneUptime 实例 URLCloud 上为https://oneuptime.comRunner 会在Settings Runners页面约一两分钟内显示为已连接。如果没有检查容器日志docker logs oneuptime-runner中的凭据或网络错误。注意在 OneUptime 12 之前AI 代码修复运行在独立的AI Agent组件上oneuptime/ai-agent镜像 AI_AGENT_*变量。该组件已合并进 Runner——如果你仍运行旧组件请参考仓库中的 v11 → v12 升级指引安装升级相关文档 目录进行替换。源码侧Runner 模型在 Common/Models/DatabaseModels/Runner.ts 中定义了canRunCodeFixTasks字段即「Runs AI Code Fixes」能力的存储与展示CodeFixReadiness.ts 的getAgentCheck()通过CodeFixAgentAvailability.getOnlineAgentForProject()检查是否有存活智能体——若没有任何在线 Runner它会点名已注册但失联的 Runner引导运维检查对应容器而不是让你再装一个。关于 Runner 的架构说明可进一步阅读 Runner/README.md。当修复失败时文档与源码共同定义了三种失败路径运行出错修复无法应用、仓库不可达、LLM 调用失败异常页面会显示任务错误及原因你可以从这里重试修复完整运行日志在任务详情页。Runner 中途崩溃当一次运行的心跳失联超过约十分钟该运行会被标记为错误。它永远不会被自动重新入队——因为 Runner 可能已经推送了部分修复分支——但你可以从异常页面重试。源码对应 CodeFixRunQueue.ts 的markStaleRunAsError()它用 CAScompare-and-set守卫Running状态绝不覆盖已完成的状态转移并明确注释「不会自动重排队」的原因。没有 Runner 在线排队中的任务如果等待超过 30 分钟、期间没有任何具备Runs AI Code Fixes能力的 Runner 连接会被自动标记失败并给出检查 Runner 的引导——它不会永远显示「进行中」。如果 Runner 在线但繁忙排队任务只是按序等待。源码对应同文件中的ORPHANED_QUEUED_TIMEOUT_MINUTES 30常量与failOrphanedQueuedRuns()清扫逻辑超过阈值且项目无存活智能体的排队运行会被失败化避免异常页被「排队中」状态永久卡住而阻塞重试。来自 AI 调查的自动代码修复当一次 AI 调查在事件incident或告警alert上发布根因分析且其保守分类conservative classification判定应做仓库代码变更时调查面板会提供Open Fix PR from this analysis入口——这是一条以上述发布的分析为完整上下文的修复任务。当补救措施属于运维操作、纯基础设施、外部因素、预期拒绝、用户错误或结论不明时该入口会隐藏。希望符合条件的修复无需点击即可发生的项目可以在Incidents AI Investigation或Alerts AI Investigation下开启Enable Automatic Code Fixes——该选项默认关闭、且独立配置。开启后以「有信心的、有证据的、可代码修复的」根因分析收尾的调查会自动排队与按钮完全相同的修复任务。这里的门控是一个受约束的、服务端验证的分类绝不是对分析文本做正则匹配只有正面的代码修复判定才会打开 PR证据缺失、非代码补救和分类失败都倾向于「什么都不做」。其余行为与手动按钮完全一致PR 就绪后开放评审内容基于已发布的分析生成需要 GitHub App 连接的仓库与启用Runs AI Code Fixes的 Runner计入该类信号的Daily AI Fix Task Limit每 UTC 日默认 25 条与每个仓库的 open-PR 上限每次触发都会先检查同一事件/告警是否已有排队或运行中的修复任务——因此自动触发与人工点击通常会合并为一条任务而非产生两个 PR该检查是写前读、非锁极端同时触发的两个请求仍可能双双通过运行是系统署名的无用户归属且没有任何东西会自动合并。隐私与数据边界仓库克隆存放在 Runner 容器内的临时工作区中运行结束无论成功失败即删除。Runner 容器永不持有你的 LLM Provider API Key——LLM 调用由 OneUptime 服务器代表 Runner 执行。OneUptime不保留你的仓库、不用你的代码训练模型任务运行日志保留每个步骤输出的短预览几百个字符以便审计 Runner 做了什么这些预览可能包含代码片段。使用自托管 Runner 自有 LLM Provider包括本地 Ollama时你的代码永远不会离开你的基础设施。路线图计划中但暂不可用官方文档明确列出以下规划能力当前版本尚不可用GitLab 支持——仓库连接目前仅支持 GitHub App更丰富的遥测上下文——把异常周边的关联 traces、logs、metrics 一并喂入修复流程而不仅是堆栈追踪。小结OneUptime 的 AI 代码修复把「异常 → 根因 → 修复 PR」的闭环固化成了一个可审计、可限流、可验证的自动化管线FixExceptionTaskHandler负责把异常细节编织成智能体提示词并生成 PRBuildVerification在合并前执行设置/构建/测试三段验证并驱动最多两次修复回灌CodeFixReadiness统一了 LLM Provider、GitHub 仓库与 Runner 三类前置检查CodeFixRunQueue兜底处理心跳失联与无人认领的失败场景。无论你是 Cloud 用户一键使用共享 Runner还是自托管部署接入本地 Ollama 与自建 Runner都能让「AI 提修复、人类做评审」真正落地同时守住预算、权限与数据隐私的底线。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考