后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载导读Greploop 是存放在本仓库.agents/skills/greploop/目录下的一个 AI Agent 技能Skill用于驱动 AI 编程代理对 GitHub PR、GitLab MR 或 Perforce 变更列表CL执行“评审—修复—再评审”的闭环循环直到 Greptile 代码评审工具给出 5/5 置信度且零未解决评论。读完本文你将掌握 Greploop 的完整执行流程平台自动探测、PR/MR/CL 识别与创建、Greptile 评审触发与轮询、评分解析、评论修复、线程解决以及最终结果报告并能基于仓库中的参考文档GitLab API 与 GitHub GraphQL 查询深入落地到实际 CI/Agent 流水线中。Greploop 是什么Greploop 的核心目标非常明确迭代修复一个 PR/MR/CL直到 Greptile 给出满分评审——5/5 置信度、零未解决评论。它是一份结构化的 Agent 指令skill不是可执行二进制程序而是由具备 Bash 执行能力的 AI 代理如 Codex逐条遵循的操作规程。从仓库内的元数据可以看出它的工程化定位见 .agents/skills/greploop/SKILL.md名称与描述name: greploop描述明确为“迭代改进 PRGitHub/MRGitLab/shelved changelistPerforce直到 Greptile 给出 5/5 置信度且零未解决评论”。许可证MIT版权归 Greptile AI见 .agents/skills/greploop/LICENSE。兼容性要求git、ghGitHub CLI或glabGitLab CLI已认证且仓库已安装 GreptilePerforce 场景需要已认证的p4CLI。允许的工具白名单Bash(gh:*) Bash(glab:*) Bash(git:*) Bash(p4:*)即该技能只被允许通过这四类 CLI 完成全部操作。元数据版本version: 1.2作者greptileai。使用前需确认前置条件全部满足平台必需 CLI附加要求GitHubgit、gh已认证仓库已安装 Greptilegreptile-apps[bot]或greptile-apps-staging[bot]参与评审GitLabgit、glab已认证仓库已安装 GreptileGreptile 作为 pipeline job 运行Perforcep4已认证正确的p4 clientworkspaceGreptile 通过 webhook 或 Swarm 集成输入Greploop 唯一可选输入是PR/MR/CL 编号。若未提供则由代理自动探测为当前分支查找对应的 PR/MR或为 Perforce 查找默认的 pending changelist。总体流程六步闭环Greploop 的执行主线由以下步骤组成平台探测GitHub / GitLab / Perforce识别或创建 PR/MR/CL进入主循环最多 5 次迭代避免失控每次迭代依次执行A. 触发 Greptile 评审并轮询完成B. 获取评审结果置信度评分 未解决行内评论C. 检查退出条件D. 修复可操作的评论E. 解决已处理的讨论线程F. 提交、推送或重新 shelve输出结构化报告。第一步平台探测Greploop 先检查 Perforce 环境再回退到 git remote 探测# Check for Perforce environment if p4 info /dev/null 21; then VCSperforce else REMOTE_URL$(git remote get-url origin) if echo $REMOTE_URL | grep -qi gitlab; then VCSgitlab else VCSgithub fi fi两个值得注意的覆盖场景自托管 GitLab 实例如果主机名不包含gitlab字样grep 探测会失败此时通过传入--vcs gitlab覆盖。Perforce显式传入--vcs perforce。第二步识别或创建 PR/MR/CLGitHub优先查看必要时自动创建草稿 PRif PR_JSON$(gh pr view --json number,headRefName -q {number: .number, branch: .headRefName} 2/dev/null); then echo $PR_JSON else PR_JSON fi如果PR_JSON为空当前分支/worktree 没有对应 PR代理会在启动循环前自动发布一个草稿 PR但必须遵守三条纪律先检查git status --short并判断预期变更范围——不要静默暂存无关改动若 worktree 混杂且意图不清晰停下并向用户询问确保工作在评审分支上——若当前分支缺失、受保护、是默认分支或不合适创建/切换到codex/descriptive-name分支仅暂存目标改动、必要时提交、推送分支并创建草稿 PRgit switch -c codex/descriptive-name # only when a review branch is needed git add intended-files-only git commit -m concise change summary # only when there are staged changes git push -u origin HEAD gh pr create --draft --fillGitLab读取 MRglab mr view --output json | jq {iid: .iid, branch: .source_branch}若尚未处于 MR 分支需要先切到对应分支。Perforce列出与描述 pending changelist# List pending changelists for current user/client p4 changes -s pending -u $P4USER -c $P4CLIENT # Describe a specific CL p4 describe -s CL_NUMBER操作前必须确保p4 clientworkspace 正确。三个平台的关键字段差异后续所有 API 调用都依赖这些标识平台标识分支字段提交 SHAGitHubnumberheadRefNameheadRefOidGitLabiid内部编号非idsource_branchshaPerforcechangelist 编号P4CLIENTshelved 文件第三步主循环Max 5 次迭代A. 触发 Greptile 评审GitHub / GitLab先推送最新改动Perforce则重新 shelve 以更新评审文件# GitHub/GitLab git push # Perforce: Re-shelve to update the shelved files for review p4 shelve -f -c CL_NUMBER推送后等待检查启动sleep 5。GitHub 侧防重复触发先检查 Greptile 是否已在运行避免重复发评论GREPTILE_STATE$(gh pr checks PR_NUMBER --json name,state | jq -r .[] | select(.name | test(greptile; i)) | .state) if [ $GREPTILE_STATE ! PENDING ] [ $GREPTILE_STATE ! IN_PROGRESS ]; then gh pr comment PR_NUMBER --body greptile review fi随后轮询 Greptile check run 直至完成HEAD_SHA$(gh pr view PR_NUMBER --json headRefOid -q .headRefOid) while true; do GREPTILE_CHECK$(gh api repos/{owner}/{repo}/commits/$HEAD_SHA/check-runs \ --jq .check_runs[] | select(.name | test(greptile; i)) 2/dev/null) if [ -z $GREPTILE_CHECK ]; then echo Waiting for Greptile check to appear... sleep 5 continue fi STATUS$(echo $GREPTILE_CHECK | jq -r .status // completed) CONCLUSION$(echo $GREPTILE_CHECK | jq -r .conclusion // pending) if [ $STATUS completed ]; then if [ $CONCLUSION success ]; then echo Greptile check passed! else echo Greptile check completed with: $CONCLUSION fi break fi echo Waiting for Greptile... (status: $STATUS) sleep 10 doneGitLab 侧同样先判断是否有 pipeline 在跑PIPELINES$(glab api projects/:fullpath/merge_requests/MR_IID/pipelines) GREPTILE_RUNNING$(echo $PIPELINES | jq [.[] | select(.status running or .status pending)] | length) if [ $GREPTILE_RUNNING 0 ]; then glab mr note MR_IID --message greptile review fi再按提交 SHA 找到对应 pipeline定位 Greptile job 并轮询至终态success/failed/canceled完整脚本见 SKILL.md 第 190–224 行。其中用到的 GitLab API 细节:fullpath自动解析、pipeline/job 字段、分页约定可在 .agents/skills/greploop/references/gitlab-api.md 中查到。Perforce 侧没有原生 check run。如果 Greptile 是通过p4 shelve触发的 webhook 集成就等待其处理并轮询 CL 上 Greptile 的评审评论直至出现评分。B. 获取 Greptile 评审结果Greptile 可能把评分放在两个位置Perforce 是三个必须全部检查取最新的评分平台评分来源 1评分来源 2GitHubPR descriptionbodyPR reviews找greptile-apps[bot]/greptile-apps-staging[bot]的最新条目GitLabMR descriptiondescriptionMR notes按author.username过滤用户名因安装而异首次运行需确认PerforceCL descriptionp4 describe -s中 Greptile 追加的评分块Helix Swarm 评论 API如GET /api/v11/comments?topicreviews/REVIEW_ID按user/body/flags字段过滤# GitHub: PR description gh pr view PR_NUMBER --json body -q .body # GitHub: PR reviews gh api repos/{owner}/{repo}/pulls/PR_NUMBER/reviews # GitLab: MR description glab mr view MR_IID --output json | jq -r .description # GitLab: MR notes glab api projects/:fullpath/merge_requests/MR_IID/notes解析文本时关注两类信息置信度评分类似3/5或5/5也可能写作Confidence: 3/5的模式评论数量摘要中标注的行内评审评论条数。随后拉取所有未解决的行内评论# GitHub gh api repos/{owner}/{repo}/pulls/PR_NUMBER/comments # GitLab glab api projects/:fullpath/merge_requests/MR_IID/discussionsGitLab 侧过滤条件DiffNote类型、来自 Greptile、位于最新提交上、且resolved: false。Swarm 侧则过滤未标记为 resolved/addressed 的 Greptile bot 评论。C. 检查退出条件满足以下任意一条即停止循环置信度评分为5/5且零未解决评论达到最大迭代次数此时如实报告当前状态。D. 修复可操作的评论对每条未解决评论读取对应文件在上下文中理解评论判断它是可操作需要改代码还是信息性可操作则实施修复信息性评论或误报则记录说明但仍然要解决该线程。E. 解决线程GitHub使用 GraphQL 分页拉取未解决线程.agents/skills/greploop/references/graphql-queries.md 中给出了完整查询gh api graphql -f query query($cursor: String) { repository(owner: OWNER, name: REPO) { pullRequest(number: PR_NUMBER) { reviewThreads(first: 100, after: $cursor) { pageInfo { hasNextPage endCursor } nodes { id isResolved comments(first: 1) { nodes { body path author { login } } } } } } } }批量解决已处理的线程利用 GraphQL 的别名语法一次提交多个 mutationgh api graphql -f query mutation { t1: resolveReviewThread(input: {threadId: ID1}) { thread { isResolved } } t2: resolveReviewThread(input: {threadId: ID2}) { thread { isResolved } } }GitLab逐条解决先拉取resolved: false的 discussions再按id逐个 PUTGitLab 不支持批量解决必须循环glab api projects/:fullpath/merge_requests/MR_IID/discussions?per_page100 glab api --method PUT \ projects/:fullpath/merge_requests/MR_IID/discussions/DISCUSSION_ID \ --field resolvedtrueGitLab 相关 API 的完整字段说明notes[0].position.new_path文件路径、per_page分页直到数组长度小于per_page见 .agents/skills/greploop/references/gitlab-api.md。F. 提交、推送 / 重新 shelveGitHub / GitLab提交前同样强调写集write set收敛存在无关改动时禁止git add -A只暂存目标文件范围不清晰就停下询问git add intended-files-only git commit -m address greptile review feedback (greploop iteration N) git pushPerforce把改动重新纳入 CL 并 re-shelvep4 shelve -f -c CL_NUMBER推送 / shelve 后sleep 5等待检查启动然后回到步骤A进入下一轮迭代。第四步报告循环退出后输出结构化总结字段值PlatformGitHub / GitLab / PerforceIterationsNFinal confidenceX/5Comments resolvedNRemaining commentsN如有若因达到最大迭代次数退出需列出剩余未解决评论并给出后续建议。输出格式示例满分达标Greploop complete. Platform: GitHub Iterations: 2 Confidence: 5/5 Resolved: 7 comments Remaining: 0未完全解决达到 5 次迭代上限Greploop stopped after 5 iterations. Platform: GitLab Confidence: 4/5 Resolved: 12 comments Remaining: 2 Remaining issues: - src/auth.ts:45 — Consider rate limiting this endpoint - src/db.ts:112 — Missing index on user_id columnPerforce 场景Greploop complete. Platform: Perforce Changelist: 12345 Iterations: 3 Confidence: 5/5 Resolved: 9 comments Remaining: 0Codex 场景下的执行委托约定SKILL.md 的第 0 步有一条重要的编排约定当 Greploop 由 Codex 调用且子代理可用时主代理必须默认把实际执行委托给子代理并把探测到的 PR/MR/CL 标识、仓库/worktree 路径、当前分支、VCS 平台、用户范围约束以及已知的变更文件意图一并传下去。父代理只负责监控进度、转发简洁状态更新并汇报最终结果。仅当子代理不可用或环境无法委托时才由父代理直接执行。这保证了长循环任务不会阻塞主对话上下文。工程实践要点与安全边界通读整个技能可以发现几条刻意强调的纪律任何把 Greploop 接入自己流水线的团队都值得沿用循环上限 5 次防止评分长期不达标时无限烧 CI 资源超限时如实报告而不是假装成功写集收敛全程禁止无差别git add -A只暂存“目标文件”或“Greptile 修复涉及的文件”工作区混杂时停下询问这是防止误提交无关改动的核心护栏防重复触发发greptile review评论前先检查是否已有 check run / pipeline 在运行避免并发评审造成混乱结果双源校验评分可能同时出现在描述与评论中必须两处都查并以最新者为准信息性评论也需解决线程修复了代码才算完成但信息性/误报评论记录说明后同样要 resolve才能把“未解决评论数”清零。与仓库的关系及进一步阅读Greploop 作为可复用的 Agent 技能完整存放在.agents/skills/greploop/目录下与仓库中的其他开发技能如.agents/skills/elsa-release/、.agents/skills/speckit-*/并列属于仓库为 AI 代理开发的协作基础设施而非 Elsa 运行时本身的业务代码。若要在 CI 中把 Greploop 固化为工作流可以参考其官方脚本骨架编写.github/workflows/greploop.yml类配置。建议继续阅读的仓库文件技能主体.agents/skills/greploop/SKILL.mdGitLab API 参考MR、pipeline、job、notes、discussions 的完整调用与字段.agents/skills/greploop/references/gitlab-api.mdGitHub GraphQL 参考reviewThreads 分页查询与批量 resolve mutation.agents/skills/greploop/references/graphql-queries.md许可证说明.agents/skills/greploop/LICENSE赞分享后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载相关推荐Greploop 实战指南基于 Greptile 自动化 PR/MR/CL 审查迭代闭环直至 5/5 满分通过Greploop 实战指南基于 Greptile 自动化 PR/MR/CL 审查迭代闭环直至 5/5 满分通过 导读 Greploop 是本仓库Onyx/AI 应用大模型RAGAI Agent后端前端企业级多模态智能体系统架构设计与部署实践企业级多模态智能体系统架构设计与部署实践 UI TARS桌面应用作为基于视觉语言模型VLM的多模态AI代理栈将GUI智能体能力与视觉识别技术深度融合为技后端工作流自动化流程编排低代码GitHub GraphQL 查询实战在 Greptile 自动代码审查中获取与批量解决 PR 评审线程GitHub GraphQL 查询实战在 Greptile 自动代码审查中获取与批量解决 PR 评审线程 本文基于 danswer 仓库内置的 GreptilAI 应用大模型RAGAI Agent后端前端上一篇AssemblyScript WASI 实战用 Wasmtime 运行系统时间、stdin 输入、控制台输出与安全随机数下一篇如何在PC上完美运行Switch游戏Yuzu模拟器完整使用教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
