AI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆【免费下载链接】OperitThe most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent项目地址https://gitcode.com/gh_mirrors/op/Operit点击查看免费下载导读本文以 Operit 仓库的 PR 技术预审重构方案 为主体完整讲解如何将 Pull Request 的自动化门禁从「多检查多红灯、职责混乱」重构为「单一聚合技术状态 基于 merge candidate 净差异的精确归责 按作用域分层的 Android 构建」。读者将掌握三类核心技术能力一是如何用candidate^1..candidate净差异消除过时 fork 的路径误判二是如何让翻译、WebChat、JVM、native、ToolPkg 与文档改动各自获得确定的作用域并精准归责三是如何通过「候选契约 → 快速检查 → 专项 job → 聚合状态」的流水线设计让一次改动只出现一个技术红灯同时保住 secret 安全与构建可信度。背景旧 PR 门禁的四个核心缺陷重构前的pull_request工作流同时使用三个不同的提交对象——目标分支 tip、贡献者 head 和 GitHub merge ref——却没有为它们定义各自的职责。由此产生一系列连锁问题路径误判当贡献者分支落后于上游时基于base tip..head tip的差异会把上游在 fork 之后新增的内容如文档、翻译算进贡献者的改动里导致「过时 fork 把上游新增内容算入贡献者差异」。未验证最终候选树实际构建只检出 head而不是 GitHub 为合并生成的候选树。head 本身不包含最终合并树中可能出现的修复与正确的构建入口因此最终合并结果从未被真正验证过。错误归责旧问题历史债务被错误地记到当前 PR 头上例如修改罗马尼亚语翻译时英文或葡萄牙语的历史占位符错误也会被提升为本次错误。门禁碎片化技术检查、PR 模板策略、文档提示和完整 Android 构建被拆成多个阻断状态。一次改动可能同时得到多个重复红灯更糟的是任意检查skipped后聚合器仍可能把它视为成功。重构目标因此非常明确所有技术检查只运行在 GitHub 生成的 merge candidate 上用「candidate 第一父提交到 candidate」的净差异做分类与归责每个 PR 只保留一个聚合技术检查状态同时让 PR 标题、正文、Issue 和 checklist 不再参与自动阻断。步骤一候选树与作用域契约旧实现的差异污染旧 PR workflow 检出贡献者 head并比较事件中的 base tip 与 head tip。由于贡献者分支落后时上游后续提交会污染差异范围head 也不包含最终合并树中的修复和构建入口语义从一开始就是不稳定的。新实现只认 GitHub 生成的 merge candidate新实现中pull_request事件只检出github.sha即 GitHub 自动生成的 merge candidate。检查入口必须验证该提交恰好有两个父提交第一父提交等于事件 base第二父提交等于事件 head。核心差异契约用三行伪代码即可概括base candidate^1 diff base..candidate workspace candidate也就是说差异始终取「candidate 的第一父提交 → candidate」工作区始终检出 candidate 本身。由此过时 fork 不再把上游新增内容算入贡献者改动最终合并树中实际会生效的内容才是被检查与构建的内容。在源码层面该契约由 ci/script/pr_check.py 的candidate_context()函数强制执行git rev-parse sha^{commit}归一化 base、head、candidate 三个 SHAgit rev-list --parents -n 1 candidate取出候选提交的父列表父数量不等于 2 直接抛错candidate ... must have exactly two parents第一父不等于事件 base 抛first parent错误第二父不等于事件 head 抛second parent错误。配套的单元测试在 ci/test/test_pr_check.py 中完整覆盖了这一契约测试用临时 Git 仓库构造「feature 分支落后于 main」的场景——main 在 fork 之后新增了docs/upstream.md随后--no-ff合并生成 candidate断言changed_paths()只返回app/src/main/res/values-ro/strings.xml而不会包含上游文档同时验证了第一父/第二父错配以及「非合并提交」均会被拒绝。路径分类NUL 分隔、rename 双面分类、规则唯一收口路径分类只使用上述净差异具体实现git diff --name-only --no-renames --diff-filterACMRDT -z base candidate--no-renamesrename 被拆成「删除旧路径 新增新路径」两条记录两个方向分别进入各自的作用域分类保证 rename 或 delete 不会漏掉原路径对应的检查例如旧路径是 Kotlin 代码即便被重命名为文档路径原路径的 JVM 检查仍然触发-z NUL 分隔文件名中的空格、引号等特殊字符不会破坏解析分类规则只保存在 ci/script/pr_check.py 一处作为单一事实来源SSOT供 workflow 与测试共同引用。classify_paths()会输出一个ScopePlan包含localization、android_resources、android_jvm、android_instrumentation、android_full、web、toolpkg、docs、yaml、ci十个布尔作用域。其中值得注意的分类边界翻译资源app/src/main/res/values-*/strings.xml与locales_config.xml命中android_resources仅资源 lane默认语言values/strings.xml因为内容会参与 JVM 编译归入android_jvmANDROID_FULL_PATTERNS命中如 cmake/operit_git_source.cmake、.github/workflows/pr-check.yml、app/src/main/cpp/**、gradle/**以及avator/dragonbones、avator/fbx、avator/mmd、llm/llama、llm/mnn、quickjs、showerclient、terminal等 native 模块根目录都会升级为android_full作用域之间存在优先级与互斥android_fullandroid_jvmandroid_resources确保改动一旦涉及构建输入就提升到完整构建 lane。作用域计划最终被写入 GitHub Output 与 step summaryappend_step_summary()在 PR 页面以表格形式展示每个作用域是否需要检查并列出前 100 条候选路径超出部分折叠并提示省略数量。步骤二差异归责与检查器旧实现的归责乱象旧本地化检查从「新增 XML 行」提取 key再把所有语言中的同名历史错误全部提升为本次错误——这正是「改一个语言、全语言红灯」的根源。仓库卫生和 Markdown 检查在缺少 base 参数时会退化为全仓扫描导致 PR 与本地调用的语义不一致。新实现显式 base/candidate 双快照比较所有 PR 检查现在显式接收--base与--candidate两个 Git object。以本地化检查 ci/script/check_localizations.py 为例其归责模型是双快照分别对 base 和 candidate 调用git ls-tree -r -zgit show commit:path读取app/src/main/res下所有资源文件解析成结构化的ResourceEntryname、tag、text、attributes、items语义化比较比较维度包括资源类型string/plurals/string-array/integer-array、占位符结构%s、%1$d等 printf 格式与{name}花括号占位符、plurals 的 quantity 分支、array 的长度与逐项内容。多行 string、plurals、array 与删除资源均能正确识别归责过滤select_blocking_issues()只保留两类阻断项——candidate 快照中新增的诊断或 PR 实际触碰的资源实体(path, key)在 base 与 candidate 间发生变化仍然存在的诊断。缺失翻译、与源文本相同的文本和历史问题一律只汇总为提示notes不阻断配置双向一致性locales_config.xml的根元素、locale子项、android:defaultLocale、重复项与 locale tag 合法性均做结构校验并保证「翻译目录必须注册」与「配置项必须存在对应 strings.xml」双向一致按路径隔离 locale同一 locale 的组合 qualifier 资源如values-bzhHant按文件路径独立比较互不覆盖输出约束诊断写入 Actions annotation 与 step summary并限制重复输出数量避免海量历史问题刷屏。仓库卫生检查 ci/script/check_repo_hygiene.py 同样收敛到候选净差异git diff --check检查空白错误whitespace、逐行扫描合并冲突标记 / / merge-conflict、对变更的.json/.xml文件做语法解析json/xml、检查工作区 HEAD 是否等于 candidateworkspace-commit、工作区是否被污染workspace-dirty以及新增符号链接symlink需显式人工审查。快速检查的设计目标是一次展示全部可修问题不因首个错误提前终止。步骤三工作流与构建分层旧实现的成本浪费旧实现里一个翻译文件就会触发完整 Android 构建PR 构建还继承 secret、初始化已经删除的 submodule、调用迁移前的 ToolPkg 路径并在失败时上传构建产物——每一个都是安全或资源问题。新实现Candidate checks聚合 按作用域分层的专项 job新的 .github/workflows/pr-check.yml 触发条件为pull_requestdevelopment分支类型含opened/synchronize/reopen/edited/ready_for_review工作流权限仅为contents: read并设置concurrency按 PR 号取消进行中的旧运行。整体分三层第一层fast快速检查所有 PR 必跑检出github.shafetch-depth: 0不初始化 submodule不持久化凭据pr_check.py plan输出候选契约与作用域计划门禁单元测试unittest discover -s ci/test、仓库卫生、Markdown 链接检查无条件运行本地化检查仅在localization true时运行YAML 检查仅在yaml true时运行所有快速检查均continue-on-error: true最后统一由「Require successful fast checks」步骤汇总判定required 为 true 且 outcome 非 success 即失败同时向 step summary 输出| Stage | Required | Outcome |决策表。快速检查失败后后续耗时阶段直接跳过android_build/android_tests以needs.fast.result success为前提。YAML 与 Actions 检查值得一提变更的.yml/.yaml先用 Ruby 的Psych.parse_file做AST 语法解析合法标量不会被转成 Ruby 对象避免对象反序列化误报再对.github/workflows/*.yml运行 actionlint且 actionlint 二进制通过官方 SHA-256 校验8aca8db96f1b94770f1b0d72b6dddcb1ebb8123cb3712530b08cc387b349a3d8后使用。专项检查仍在 fast job 内按需执行WebChatweb trueweb-chat下npm ci、typecheck、npm run build:webchatToolPkgtoolpkg truenpm run build:examples:github重建 GitHub TypeScript 示例并用git diff --exit-code -- examples/github.js强制其与提交版本一致examples/toolpkg_wasm_demo按独立 lockfile 执行pack:toolpkgAssemblyScript TypeScript 归档构建随后用test -s断言 manifest 声明的入口main.js、modules/core.wasm与归档dist/toolpkg_wasm_demo.toolpkg必须存在且非空最后调用 tools/example_packages/sync_example_packages.py 以--mode test校验、再执行真实同步Android 资源android_resources true安装build-tools;35.0.0后用aapt2 compile --dir app/src/main/res做资源语法编译输出 zip 并断言非空——翻译改动只走到这一层绝不启动完整 assemble。第二/三层android_build与android_tests按作用域独立 jobandroid_build仅在android_full true时运行初始化 terminal submodule只初始化当前存在且实际需要的公共 submodule、安装 JDK 21 / Node 22 / Android SDKplatforms;android-34、platforms;android-36、build-tools;35.0.0、ndk;25.1.8937393、cmake;3.22.1、恢复 CMake 源码缓存与manual-deps缓存、执行 ci/script/download_android_dependencies.sh 与 ci/script/prepare_android_dependencies.py 准备依赖、用 Rust 1.88.0 交叉编译 tools/native_ripgrep 生成liboperit_ripgrep.so并断言非空、重建 WebChat 资产与同步 ToolPkg 包最后./gradlew assembleDebug --stacktrace --no-daemon。android_tests在android_jvm true || android_full true时运行按不同 profilejvm/full恢复依赖缓存并准备依赖运行:app:testDebugUnitTest若android_instrumentation true改动涉及app/src/androidTest/**额外追加:app:compileDebugAndroidTestKotlin与:app:compileDebugAndroidTestJavaWithJavac的编译验证。聚合状态candidate每个 PR 只保留一个技术红灯candidatejob 依赖fast、android_build、android_tests三者if: always()再次通过check_stage汇总只有 required 为 true 且 outcome 非 success 的阶段才算失败。最终 PR 页面上只出现一个名为Candidate checks的聚合状态而每个专项 job 仍单独展示各自的具体失败原因——既避免了「一次改动多个重复红灯」又保留了诊断的可追溯性。可信构建与 PR 构建彻底分离PR workflow 零 secretpermissions: contents: read不读取任何 secret也不上传 APK/AAB可信的 main 推送构建与手工 Android 构建由独立 workflow .github/workflows/android-build.yml 承担支持workflow_dispatchassembleDebug、:app:assembleNightly、:app:assembleClone、:app:bundleRelease四种任务选择与 main 分支的路径过滤推送按事件隔离并发concurrency: android-build-${{ github.event_name }}-${{ github.ref }}构建前强制校验 OAuth 输入只有该 workflow 允许上传 APK/AAB 与 reports 产物app/build/outputs/apk/**、app/build/outputs/bundle/**/*.aab保留 14 天构建输入完整性ToolPkg 运行时文件、GitHub 示例生成结果、可信构建输入ci/script/download_android_dependencies.sh等均显式校验Gradle Wrapper 下载内容必须匹配 Gradle 8.13 官方 SHA-256gradle/wrapper/gradle-wrapper.properties 中distributionSha256Sum20f1b1176237254a6fc204d8434196fa11a4cfb387567519c61556e8710aed78。作用域边界与完成情况本次重构的作用域严格限定在.github/workflows/pr-check.yml 与 .github/workflows/android-build.yml 两个工作流gradle/wrapper/gradle-wrapper.propertiesci/script/ 与 ci/test/含 ci/test/test_pr_check.py、ci/test/test_localizations.py、ci/test/test_repo_hygiene.py、ci/test/test_toolpkg_sync.py、ci/test/test_markdown_links.pyexamples/toolpkg_wasm_demo/package-lock.jsonWASM ToolPkg 独立锁文件PR 模板、CI 文档与贡献指南。Issue 自动整理、发布签名、业务代码与仓库 ruleset不在此次修改范围内。按完成清单核对重构后的关键事实如下旧PR Requiredworkflow、模板策略 job 与聚合器已删除新 workflow 保留Candidate checks聚合状态并按作用域展示专项 job快速检查与 Android 分层均使用 candidate 第一父差异PR 不读取 secret 也不上传 APK/AAB已补充门禁、归责、Markdown 与 ZIP 安全测试Gradle 8.13 distribution 使用官方 SHA-256 校验WASM ToolPkg 使用独立锁文件执行真实编译与打包官方 Actions 固定到 Node.js 24 运行时版本actions/checkout93cb6efe...、actions/setup-pythonece7cb06...等均以 SHA 固定首次线上完整 lane 已通过 assemble 与 JVM 单测并补齐 Android lint 检出的四个 WASM 模块数翻译。效果验证一次改动只看到一个技术状态以类似 PR #770 的纯翻译改动为例候选摘要只报告该 PR 在当前main上实际引入的问题——不再报告其他语言的历史债务、上游文档变化或 PR 模板格式错误。fastjob 中android_resources true只执行 aapt2 资源编译android_build与android_tests均因作用域为 false 而不启动candidate聚合 job 汇总后给出唯一的Candidate checks红灯若有并精确指向专项 job 的具体失败原因。整个流程同时满足纯翻译改动不启动完整 assemble、fork PR 日志与产物中不存在仓库 secret、Android 构建只初始化当前存在且实际需要的公共 submodule、YAML 使用 AST 语法解析与 actionlint 双重校验、Gradle Wrapper 下载内容必须匹配官方 SHA-256。这套「候选契约 → 净差异归责 → 作用域分层 → 聚合状态」的 PR 门禁架构可以作为多模块、多语言、多原生依赖的 Android 仓库 CI 重构的通用范本只要保证检查与构建永远作用在 GitHub 真实生成的 merge candidate 上并把「历史债务」与「本次改动」严格区分开单状态门禁与高信噪比诊断就能同时成立。赞分享AI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆【免费下载链接】OperitThe most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent项目地址https://gitcode.com/gh_mirrors/op/Operit点击查看免费下载相关推荐Operit PR 检查重构基于 merge candidate 的差异归责与语义化检查器设计Operit PR 检查重构基于 merge candidate 的差异归责与语义化检查器设计 导读 本文聚焦 Operit 仓库 Pull RequestAI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆GUI 自动化Operit PR 技术预审重构基于 Merge Candidate 的候选树与作用域契约解析Operit PR 技术预审重构基于 Merge Candidate 的候选树与作用域契约解析 导读 本文讲解 Operit 仓库 Pull RequestAI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆GUI 自动化Operit PR 技术预审重构基于作用域分层的工作流与构建通道设计Operit PR 技术预审重构基于作用域分层的工作流与构建通道设计 导读 本文讲解 OperitAndroid 平台 AI Agent 项目Pull RAI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆GUI 自动化上一篇终极兼容方案D3D8to9让经典老游戏在现代Windows上重生下一篇Koin Android ViewModel 完整指南生命周期感知注入、声明式 DSL 与作用域实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考