oh-my-pi robomp 的 PR 终态应答机制:`finalized_pr_comment` 的语义、路由与工作区回收设计

发布时间:2026/10/11 16:57:41
oh-my-pi robomp 的 PR 终态应答机制:`finalized_pr_comment` 的语义、路由与工作区回收设计
人工智能AI Agent代码智能体工具调用CLIMCP Clients【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in. Built by Stencil Labs.项目地址https://gitcode.com/GitHub_Trending/oh/oh-my-pi点击查看免费下载finalized_pr_comment.md是 oh-my-pi 仓库中自托管 GitHub 分类机器人 robomp位于 python/robomp/的一组人格提示词persona prompt之一定义了机器人对已终结 PRmerged / closed上后续评论的标准回复。本文以该提示词为主体结合 persona.py、github_events.py、tasks.py 的事件路由与状态机以及 test_github_events.py、test_tasks.py 中的回归测试完整解析这条一句话提示词背后的设计意图、触发链路与可复现的运维语义。提示词原文与语义拆解finalized_pr_comment.md的完整内容仅一行PR closed/merged. Further changes: opening fresh fix recommended. Regression: reopen original issue; Ill triage from scratch.这行文本可以被拆解为三层契约片段语义面向对象PR closed/merged.状态告知该 PR 已合并或关闭机器人不会在此 PR 上继续改动报告者Further changes: opening fresh fix recommended.行为指引若需继续开发新改动请开一个全新的修复 PR维护者/贡献者Regression: reopen original issue; Ill triage from scratch.回归通道若原问题复发重开原 issue机器人会从零重新 triage报告者值得注意的是提示词刻意区分了两种后续路径新功能/新改动走开新 PR同一问题的回归走重开原 issue。后者之所以存在是因为重开事件会触发 github_events.py 中issues.reopened的分支将该事件重新排队为一次 submitter-attributable 的triage_issue任务——这一点在测试中有明确注释印证见下文回归测试一节。提示词在架构中的定位persona 层robomp 把所有面向 omp Agent 的提示词集中存放在 python/robomp/src/prompts/ 目录由 persona.py 统一加载。加载机制在persona.py顶部有清晰的文档说明模板采用极简 mustache 风格占位符{{path.to.value}}正则\{\{\s*([a-zA-Z0-9_.])\s*\}\}并且刻意不引入真实模板引擎防止非法提示词渲染出意外副作用persona.py_load(name)通过importlib.resources从robomp.prompts包内读取模板文本并缓存persona.pyrender(template, scope)完成占位符替换查找失败时返回空串persona.py。与finalized_pr_comment直接对应的加载函数是def finalized_pr_comment() - str: return _load(finalized_pr_comment.md).strip() # persona.py L404-L405该函数被登记进模块的__all__导出列表persona.py供 tasks.py 等上层调用。值得注意的工程细节finalized_pr_comment是无占位符的静态模板因此它走_load而非render——与followup_comment含{{repo.full_name}}、{{inbound.number}}、{{thread}}等大量动态占位符形成对照。这也解释了为什么_load与render是两个独立函数静态确认消息不需要任何会话上下文。触发链路谁在什么时机发出这条评论finalized_pr_comment只在机器人自己开的 PR上触发触发点是 PR 上的评论事件issue_comment.createdGitHub 把对 PR 的对话评论也作为 issue comment 下发此时 payload 中issue.number即 PR 编号。完整链路如下路由判定github_events.py 在issue_comment.created中检测到pull_request in issue并通过_login_matches_bot判断该 PR 是否为机器人作者。若为机器人 PR则路由为handle_pr_conversation任务并附带 directive 信息若为外来贡献者 PR则直接skipincoming PR comments ignored。状态查询handle_pr_conversation在 tasks.py 中通过_resolve_issue_row_for_pr把 PR 编号解析回原始 issue的数据库行。终态判定若issue_row.state in (merged, closed, abandoned)且本次评论不含维护者 directive则进入确认分支——调用persona.finalized_pr_comment()并通过github.post_comment发回 PRtasks.py。代码注释说明此举目的Still acknowledge so the reporter knows the bot saw it.仍要确认让报告者知道机器人看到了评论。异常兜底post_comment抛GitHubError时仅记录log.warning(ack comment failed, ...)不重试、不阻塞保证确认消息是尽力而为的副作用。这条终态上仍应答的设计与 followup_comment.md 中维护者 dismissalintended、not an issue、works as designed永久终结修复工作流的规则形成互补前者是机器人主动的礼貌确认后者是工作流的硬性停止信号。状态机依据merged / closed / abandoned三元组finalized_pr_comment中的 closed/merged 对应 robomp 内部数据库的状态模型。db.py 定义了完整的IssueState联合类型IssueState Literal[ new, reproducing, fixing, reviewing, opened, merged, closed, needs_info, abandoned, ]其中merged、closed、abandoned三种终态在 tasks.py 中被多次作为finalized集合使用triage_issue重开路径existing.state in (merged, closed, abandoned)→ 拆除旧工作区后从默认分支重新 branchtasks.pyissue 评论处理路径同样判定后发送 finalized_issue_comment.mdIssue closed. If bug recurs, reopen; Ill re-triage from scratch.PR 对话路径即本文主题tasks.py。三种终态的来源merged/closed由事件或维护者操作推进abandoned则通过robomp cleanup owner/repo#123命令或set_issue_state(..., abandoned)显式置入见 cli.py、host_tools.py。db.set_issue_state是底层写接口db.py。终态上的两个分支确认应答 vs 维护者重开handle_pr_conversation在终态上的行为是二分的判断标准是是否有维护者 directive即评论是否来自授权维护者并携带显式指令分支 A——无 directive发确认评论。这是finalized_pr_comment的唯一出口。机器人不恢复会话、不触碰代码、不 push、不重开任务只发一条确认并结束。该分支保证了终态 PR 上任何新评论都不会产生意外副作用这一核心安全属性。分支 B——有维护者 directive视为重开。tasks.py 会sandbox.remove_workspace拆除陈旧工作区旧分支可能已被合并或删除db.upsert_issue(..., statereproducing)把原始 issue 重置为活动状态重新走ensure_workspace在原始 issue 上从默认分支重新建 branch之后若产出代码变更Agent 会开一个新的 PR注释明确The agent will open a new PR if code changes ship。分支 B 的存在解释了提示词中 opening fresh fix recommended 的工程依据终态 PR 的分支existing_branch指向已合并/删除的 ref无法直接续改必须拆除重建tasks.py 中对 reopen 场景的注释On a reopen the prior branch is stale (merged/deleted), so branch from default。与 issue 终态提示词的对照robomp 对issue 终态与PR 终态各配一条确认提示词语义严格对应维度finalized_issue_comment.mdfinalized_pr_comment.md原文Issue closed. If bug recurs, reopen; Ill re-triage from scratch.PR closed/merged. Further changes: opening fresh fix recommended. Regression: reopen original issue; Ill triage from scratch.触发位置终态 issue 上的新评论tasks.py机器人终态 PR 上的新评论tasks.py回归通道重开 issue → 重新 triage重开原始issue → 重新 triage新改动通道—issue 语境建议开全新修复 PR两条提示词共享同一承诺reopen → re-triage from scratch。该承诺不只是文案路由层有真实实现issues.reopened事件在 github_events.py 中被排队为triage_issuereason 为issues.reopened并按提交者归属消耗 rate budget随后 tasks.py 的reopen re-triage分支完成工作区拆除与重建。回归测试承诺如何被验证robomp 用测试把上述行为固化为契约重点有两处重开即排队test_github_events.py 的test_route_issue_reopened_queues_triage直接引用提示词注释——finalized_issue_comment.mdpromises re-triage on reopen; the router must queue it as a submitter-attributable triage (not drop it to the skip branch)——并断言should_queue、task triage_issue、reason issues.reopened、submitter 归属正确。终态拆除顺序test_tasks.py 的test_triage_issue_reopen_tears_down_finalized_workspace模拟机器人此前已 finalize 该 issueDB 中存在 closed 行 陈旧工作区的场景断言重 triage 时remove_workspace先于ensure_workspacecalls [remove, ensure]且行状态最终重置为reproducing。这两条测试分别锁定了提示词承诺的两个端点路由层重开会被接收以及任务层重开从干净的 workspace 重新开始。此外 test_server.py 中还有test_handle_pr_conversation_*系列覆盖 PR 对话事件在无映射、缺分支映射、review 工作区等边界下的行为保证终态分支不会误伤活动工作流。运维视角如何在现场观察与验证由于确认消息是尽力而为的副作用现场排障主要依赖日志与状态表终态 PR 上收到评论时日志会打印skip: pr-conversation on finalized issue含state字段可据此确认机器人确实进入了 finalized 分支而非其他路径tasks.py维护者重开时日志打印directive reopen (pr)含from_state与author随后可见 workspace 拆除与重建序列tasks.py用docker compose exec robomp robomp status可查看 issue 表与 release 表确认行的终态状态robomp cleanup owner/repo#123可强制拆除工作区并将状态置为abandonedREADME.md。小结finalized_pr_comment.md虽只有一行却是 robomp 终态不可变、回归有通道 状态机的人机接口它向报告者明确承诺PR 已终态、新改动请开新 PR、回归请重开原 issue 且机器人会从零重 triage而承诺的兑现由 github_events.py 的路由、tasks.py 的工作区拆除/重建、db.py 的九态模型与两处回归测试共同背书。理解这条提示词就理解了 robomp 在PR 合并/关闭之后这一最易产生歧义的阶段如何保持行为一致、可预测且安全。赞分享人工智能AI Agent代码智能体工具调用CLIMCP Clients【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in. Built by Stencil Labs.项目地址https://gitcode.com/GitHub_Trending/oh/oh-my-pi点击查看免费下载相关推荐oh-my-pi / robomp 问答类 Issue 自动关闭机制解析基于 表情反馈的提示词后缀与调度器设计oh my pi / robomp 问答类 Issue 自动关闭机制解析基于 表情反馈的提示词后缀与调度器设计 导读 本文聚焦 oh my pi 仓库中人工智能AI Agent代码智能体工具调用CLIMCP Clientswvp-GB28181-pro GB28181视频平台部署落地指南从零到上线五步走wvp GB28181 pro GB28181视频平台部署落地指南从零到上线五步走 wvp GB28181 pro 是一款开箱即用的 GB28181 视频平台后端音视频前端OpenSearch 3.0.0-alpha1 Release Notes 深度解析Lucene 10、JDK 21 与核心架构演进OpenSearch 3.0.0 alpha1 Release Notes 深度解析Lucene 10、JDK 21 与核心架构演进 导读 本文以 OpenS搜索引擎全文检索可观测性数据分析创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考