Agent Zero 发布自动化实战：用 OpenRouter 系统提示词驱动 GitHub Release Notes 生成

Agent Zero 发布自动化实战用 OpenRouter 系统提示词驱动 GitHub Release Notes 生成【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero本文以 Agent Zero 仓库中的 openrouter_release_notes_system_prompt.md 为核心剖析这套提示词即规范的发布说明自动生成方案它如何在 Docker 镜像发布流水线中被 docker_release_plan.py 作为 System Prompt 消费如何约束大模型只依据 Git 提交产出高信噪比的 Release Notes以及如何与 GitHub Actions 工作流、环境变量和测试用例协同工作。读完本文你将掌握一套可复用的LLM 生成发布说明提示词设计原则与完整的 CI/CD 落地路径。一、定位一份被自动化流水线消费的提示词scripts/openrouter_release_notes_system_prompt.md并不是一篇给人阅读的说明文档而是一份面向大模型的系统提示词System Prompt。它的消费者在 scripts/AGENTS.md 中有明确声明openrouter_release_notes_system_prompt.mdis consumed by.github/scripts/docker_release_plan.py.从源码看docker_release_plan.py 通过常量把提示词文件绑定为发布说明生成的输入OPENROUTER_SYSTEM_PROMPT_PATH REPO_ROOT / scripts / openrouter_release_notes_system_prompt.md这份提示词的完整链路是Git 提交 → GitHub Actions 触发 → Python 脚本采集提交 → 读取提示词作为 System Prompt → 调用 OpenRouter Chat Completions API → 将生成的 Markdown 写入 GitHub Release。它把写发布说明这一主观性任务固化成了一套确定性强、可审计、可测试的工程规范。二、提示词逐条解析规则即产品质量原文虽然精炼但每条规则都对应一类真实的生产问题。逐条展开如下1. 角色与输出纪律You write GitHub release notes for Agent Zero. Produce release-ready Markdown only. Do not add preambles, explanations, code fences, or commentary about the prompt.角色锚定开头即声明你为 Agent Zero 写 GitHub Release Notes把模型上下文固定在具体项目语境避免泛化回答。输出纪律只输出可直接发布的 Markdown禁止前言、解释、代码围栏以及对提示词本身的评论。这是为了确保流水线拿到的输出就是最终的 Release Body无需二次清洗。2. 内容来源约束事实边界Base the release notes only on the commit headings and descriptions provided by the user.这是整份提示词最重要的事实边界发布说明只能以用户消息中提供的提交标题与描述为依据。它从源头切断了模型自由发挥的空间与下游 docker_release_plan.py 中build_release_notes_user_message构造的用户消息格式严格对应Commit headings and descriptions: 1. Heading: ... Description: ... 2. Heading: ... Description: (none)3. 优先级规则Prefer the most meaningful user-facing changes, important fixes, notable infrastructure or packaging changes, and any clearly stated breaking changes.要求模型优先呈现四类高价值信息优先级内容类型示例1对用户可见的功能变化新能力、行为变化、UI 变化2重要修复关键 bug 修复、回归修复3值得关注的基础设施/打包变化Docker 镜像、依赖、构建方式变化4明确声明的破坏性变更Breaking changes4. 排除规则信噪比控制Skip low-signal churn, duplicate points, and purely procedural wording unless it materially affects users or operators.要求跳过低信号噪音如格式调整、文档微调、重复要点、纯流程性措辞——除非它们实质影响用户或运维人员。这直接决定了 Release Notes 的阅读质量一份好的发布说明应该是变化清单而非提交流水账。5. 分组与简洁Group related items when that improves readability, but keep the output concise.允许对相关内容分组如把多个相关修复合并呈现但必须保持整体简洁。注意这里的分组是有条件的——只有当能改善可读性时才分组避免为了分组而破坏信息完整性。6. 反幻觉规则Do not invent features, bug fixes, migrations, or breaking notes that are not supported by the commits.明确禁止编造提交中不存在的功能、修复、迁移或破坏性说明。这是对抗 LLM 幻觉的硬约束与第 2 条仅基于用户提供的提交形成双重保险。7. 细节纪律Do not mention commit hashes, pull request numbers, authors, files, or internal implementation trivia unless the commit text makes them essential to understanding the release.不允许出现 commit hash、PR 编号、作者、文件名或内部实现琐事——除非提交文本本身使其成为理解发布内容的关键。这保证了发布说明面向用户与运维而非开发者内部。8. 空结果哨兵If the commit list does not justify any meaningful notes, return exactly:No release notes.当提交列表不构成任何有意义的说明时必须原样返回No release notes.。这个哨兵值在下游被直接作为发布正文使用也让流程对无实质变化的发布保持诚实。值得注意的是docker_release_plan.py 在 API 返回为空时也会兜底输出同样的字符串body extract_openrouter_message_content(message).strip() return body or No release notes.9. 首选格式A short introductory line or heading is allowed but optional. Then use a flat bullet list of the key release points. Add a shortBreaking changessection only when the commit content clearly warrants it.简短引言行或标题允许但可选主体扁平的要点列表flat bullet listBreaking changes小节仅在提交内容明确支持时添加。这一格式约定使不同版本之间的发布说明结构保持一致便于用户横向对比各版本变化。三、源码级调用链提示词如何被真正执行提示词本身只是规则真正让它生效的是 docker_release_plan.py 中的generate_release_body_with_openrouter函数L619-L6681. 输入准备def generate_release_body_with_openrouter(commits: list[CommitEntry]) - str: api_key require_env(OPENROUTER_API_KEY) model require_any_env(OPENROUTER_MODEL_NAME, OPENROUTER_MODEL) system_prompt load_text(OPENROUTER_SYSTEM_PROMPT_PATH) repository require_env(GITHUB_REPOSITORY) user_message build_release_notes_user_message(commits)API Key必须存在OPENROUTER_API_KEY环境变量否则直接失败require_env模型名从OPENROUTER_MODEL_NAME或OPENROUTER_MODEL中任取其一require_any_env这为 CI 与本地调试提供了兼容性System Prompt通过load_text从scripts/openrouter_release_notes_system_prompt.md原样读取用户消息由采集到的提交列表构建。2. API 请求构造payload { model: model, messages: [ {role: system, content: system_prompt}, {role: user, content: user_message}, ], temperature: 0.2, } request Request( OPENROUTER_CHAT_COMPLETIONS_URL, datajson.dumps(payload).encode(utf-8), headers{ Authorization: fBearer {api_key}, Content-Type: application/json, HTTP-Referer: fhttps://github.com/{repository}, X-OpenRouter-Title: Agent Zero Docker Release Notes, }, methodPOST, )关键参数说明参数值作用model环境变量指定决定使用哪个模型完成生成任务messages[0]system 提示词承载本篇文章解析的全部规则messages[1]user 提交清单模型唯一的事实来源temperature0.2刻意压低创造性换取输出的确定性与只依据提交、不得虚构的提示词规则相辅相成HTTP-Referer仓库主页OpenRouter 平台侧展示的引用来源X-OpenRouter-TitleAgent Zero Docker Release Notes请求在 OpenRouter 平台的标识标题3. 响应解析与失败处理message first_choice.get(message) body extract_openrouter_message_content(message).strip() return body or No release notes.extract_openrouter_message_contentL599-L616同时兼容两种响应形态content为纯字符串或content为包含text字段的数组多模态分段响应。HTTP 与网络异常则统一fail输出错误详情。四、CI/CD 集成从提交到 Release 的完整流水线1. 触发条件与全局配置.github/workflows/docker-publish.yml 定义了发布流水线Build And Publish Docker Imageson: push: branches: - testing - ready - main tags: - v* workflow_dispatch: inputs: tag: description: Optional release tag to rebuild, for example v1.21 required: false type: string env: ALLOWED_BRANCHES: testing ready main MAIN_BRANCH: main RELEASE_TAG_REGEX: ^v([0-9])\\.([0-9])$ MIN_RELEASE_MAJOR: 1 MIN_RELEASE_MINOR: 0 DOCKER_IMAGE_REPO: ...push 事件testing/ready/main分支推送或v*标签推送workflow_dispatch手动触发可选输入tag指定要重建的发布标签版本约束发布标签必须匹配v{X}.{Y}且不低于v1.0这一校验逻辑在parse_release_tagL156-L163中执行。2. 三个阶段的脚本调用流水线分三个阶段调用同一脚本的不同子命令main()中通过命令行参数分发见 L823-L837阶段命令产出planL78python3 .github/scripts/docker_release_plan.py plan计算构建矩阵branch、source_tag、mode 等输出has_work与matrixresolve-buildL159... resolve-build对矩阵中每个候选重新校验资格输出待推送的 Docker 标签resolve-releaseL199... resolve-release校验是否为最高发布标签、调用 OpenRouter 生成 Release Body3. 提示词相关的关键环境变量在 resolve-release 步骤L196-L198中流水线注入GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }} OPENROUTER_MODEL_NAME: ${{ vars.OPENROUTER_MODEL_NAME }}其中OPENROUTER_API_KEY作为 Secret 管理OPENROUTER_MODEL_NAME作为仓库 Variable 管理——这体现了密钥与配置分离的 CI 最佳实践模型名可以随时调整而无需改动代码。五、提交数据如何被采集与格式化生成发布说明的前提是拿到上一个已发布版本到当前版本之间的全部提交。collect_release_commitsL562-L577负责这项工作previous_release_tag previous_published_release_tag(config, source_tag) or commits collect_release_commits(previous_release_tag or None, source_tag)上一版本定位previous_published_release_tagL525-L541通过 GitHub Releases API 分页拉取已发布版本跳过 draft 与 prerelease取低于当前版本的最高版本号祖先关系校验使用git merge-base --is-ancestor确保上一版本确实是当前版本的祖先防止提交范围错乱提交格式git log --reverse --format%s%x1f%b%x1e以\x1f标题/描述分隔与\x1e条目分隔输出由parse_commit_entriesL544-L559解析为CommitEntry(heading, description)列表再交给build_release_notes_user_message组装成用户消息——提示词中只依据 commit headings and descriptions这一约束正对应这段采集与格式化逻辑。六、生成失败时的兜底策略LLM 调用天然存在失败风险密钥缺失、限流、网络抖动、响应格式异常。resolve_release_commandL671-L730对发布说明生成做了整体异常兜底body Failed to generate release notes. try: previous_release_tag previous_published_release_tag(config, source_tag) or commits collect_release_commits(previous_release_tag or None, source_tag) body generate_release_body_with_openrouter(commits) except SystemExit: print(fRelease note generation failed ... Falling back to a static release body., filesys.stderr) except Exception as exc: ...关键设计发布本身不因 LLM 失败而阻塞。即使生成失败流水线仍会输出should_releasetrue以静态占位文本Failed to generate release notes.作为 Release Body 发布随后可手动补写。这与发布镜像优先、文案可后补的工程取舍一致。七、测试如何保障这套流程仓库通过 tests/test_docker_release_plan.py 对发布规划逻辑做回归保护工作流契约测试test_docker_publish_workflow_tracks_branch_promotions直接断言docker-publish.yml中存在testing/main分支监听、v*标签监听、workflow_dispatch输入、SOURCE_REF_TYPE与BEFORE_SHA等关键配置——提示词文件的消费方一旦改动测试即失败分支晋升行为测试test_plan_branch_push_builds_when_tag_reaches_allowed_branch在tmp_path中真实初始化 Git 仓库、打标签、合并分支、seed_remote_refs模拟远端引用随后断言plan_branch_push对testing分支产出modepush_promoted_tag、publish_versionFalse、publish_branch_tagTrue对main分支产出publish_versionTrue的候选——验证了版本标签晋升到主分支才发布正式版的规则。同时.github/AGENTS.md 明确要求修改 Docker 发布规划或发布工作流行为后必须运行pytest tests/test_docker_release_plan.py。提示词本身虽无独立单测但其输出格式期望由 docker_release_plan.py 的解析逻辑extract_openrouter_message_content、空结果兜底隐式约束。八、给其他项目的落地建议这套提示词即规范的模式可以低成本复制到任意仓库将提示词作为版本化资产与代码同库管理修改即走 Code Review 流程配合 scripts/AGENTS.md 这类 DOX 文档说明消费方先定规则再写代码提示词中的每一条约束事实来源、优先级、排除项、反幻觉、空结果哨兵、输出格式都应该能在消费代码中找到对应实现规则与实现互为印证压低 temperature生成类任务如需确定性输出temperature0.2是稳健起点配合仅依据输入提交的边界约束失败不阻塞发布LLM 生成只是发布流程的可选增强用静态占位 手动补写兜底保证镜像发布这一核心链路永远可用用测试锁住契约对工作流配置与规划逻辑编写断言式测试防止提示词被无意绕过或消费方被无意改动。通过 openrouter_release_notes_system_prompt.md、docker_release_plan.py、docker-publish.yml 与 test_docker_release_plan.py 四份文件的协同Agent Zero 实现了一套提交驱动、模型生成、规则约束、测试护航的发布说明自动化体系——这份 17 行提示词正是整个体系的规则核心。【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考