operating-kit 的 deploy-with-verification 智能体如何用测试→构建→部署→线上验证→状态文档五步流水线杜绝假部署【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents导读deploy-with-verification是当前仓库 operating-kit 插件提供的一个生产部署智能体Agent它把一次上线固化为test测试→ build构建→ deploy部署→ verify-live线上验证→ update state doc更新状态文档五个强制步骤并在测试失败时立即熔断、在命令退出码为 0与线上真的在服务新版本之间划出明确界限。读完本文你将掌握这套流水线的模板变量、硬性规则、五步实操细节、汇报格式以及它与session-start、session-end等兄弟智能体如何协同把部署状态变成仓库内可追溯的单一事实来源。智能体定位一次生产上线五个不可跳过的环节deploy-with-verification是 operating-kit 插件的一部分。根据 docs/plugins.md 的目录说明operating-kit 负责Session lifecycle, pre-ship review, deploy with live verification state doc update, prod log health check即会话生命周期、发布前审查、带线上验证的部署 状态文档更新、生产日志健康检查。整个插件共包含 5 个智能体智能体文件职责deploy-with-verification.md完整部署流测试→构建→部署→线上验证→更新状态文档code-review-preshipment.md发布前全面代码审查输出 SHIP / SHIP WITH FIXES / DO NOT SHIP 结论prod-logs-health-check.md部署后或事故时拉取生产日志只以日志为准分析问题session-start.md会话开始时读取状态文档、核对线上状态、简报session-end.md会话结束时固化教训、遗留问题、下一步从智能体文件头部的 frontmatter 可以看到它的运行画像--- name: deploy-with-verification description: Use when deploying to production. Runs tests, builds, deploys, verifies live, and updates the state doc with the confirmed revision. Stops if tests fail; never reports shipped until the live system confirms the new build is serving traffic. model: sonnet tools: Bash, Read, Edit ---model: sonnet选用 Sonnet 模型与 docs/agents.md 中Sonnet 用于复杂推理与架构任务、管理部署流水线的模型分层策略一致tools: Bash, Read, Edit该智能体需要执行测试/构建/部署命令Bash、阅读状态文档Read、对状态文档做定向编辑Edit三样工具正好对应流水线的执行、核对、回写三个阶段。模板变量把通用流程套用到具体项目这个智能体是一份可参数化模板部署到不同项目前必须用项目实际信息替换 6 个占位符占位符含义示例值{{REPO_PATH}}仓库本地路径所有命令的工作目录/data/web/disk1/git_repo/your-app{{TEST_COMMAND}}完整测试命令pytest -x -q/npm test{{BUILD_COMMAND}}完整构建命令npm run build/docker build -t app:v1.2.3 .{{DEPLOY_COMMAND}}完整部署命令kubectl rollout restart deploy/app/make deploy{{HEALTH_OR_VERSION_ENDPOINT}}健康检查或版本探针端点https://app.example.com/health/https://app.example.com/api/version{{STATE_DOC}}项目状态文档单一事实来源路径docs/STATE.md{{STATE_DOC}}的定位在兄弟智能体中有交叉印证session-start要求把它指向projects single source-of-truth state filesession-end同样强调状态文档 记忆索引{{MEMORY_INDEX}}双文件结构。这意味着状态文档是跨会话、跨智能体共享的权威记录deploy 智能体负责其中部署版本/修订号字段的写入。硬性规则什么时候必须停下智能体在进入任何步骤前先声明四条不可妥协的硬性规则测试不绿不部署任何测试失败 → 停止、报告、不得继续部署后必须核对线上系统不能只凭部署命令退出码为 0就判定成功只有线上验证通过才更新状态文档状态文档记录的是被线上确认过的修订号绝不提前宣称deployed/shipped只有第 4 步线上验证和第 5 步更新状态文档都成功后才允许使用这两个词。第 4 条规则实际上把宣布成功定义为一个两阶段提交先由线上系统确认新构建在服务流量再把结论写入状态文档——两步缺一不可。五步部署流水线逐段拆解第 1 步测试Test{{TEST_COMMAND}}要求全部通过All green required。这是唯一的熔断点任何失败即停止上报禁止进入后续步骤。可以把这一步与发布前的审查智能体联动——code-review-preshipment.md 会在每次部署前检查自上次部署提交以来的所有变更覆盖正确性、原子性与竞态、错误处理、数据存储卫生、安全、类型安全、测试、集成副作用、性能、可观测性十个维度并给出SHIP / SHIP WITH FIXES / DO NOT SHIP结论只有审查放行且测试全绿流水线才真正起步。第 2 步构建Build{{BUILD_COMMAND}}生成可部署产物。构建产物应当携带可识别的版本标识以便第 3 步从输出中提取。第 3 步部署Deploy{{DEPLOY_COMMAND}}从部署命令的输出中捕获新的 revision/version 标识符。这个标识符将在第 4 步被用于与线上返回结果比对是部署的是不是同一份代码的关键凭据。第 4 步线上验证Verify live——本智能体的灵魂curl -s {{HEALTH_OR_VERSION_ENDPOINT}}确认响应健康且反映的正是你刚刚部署的内容。文档明确列出了这一步要拦截的三类假成功平台仍服务旧版本部署命令返回成功但平台继续对外提供上一个 revision灰度只路由了部分流量分段上线staged rollout只把一小部分流量引到新构建镜像首次真实请求即崩溃新镜像在首个真实请求上 crash-loop但部署动作本身显示绿色。文档用一句话点破了本质Exited 0 和 live and serving the new code 是两个不同的声明claims必须确认后者如果端点没有显示你的构建部署就没有完成。这正是这个智能体区别于跑完命令就算完事的普通脚本部署的核心设计。第 5 步更新状态文档Update state doc同一轮执行不得推迟到会话结束只有在第 4 步确认线上修订号 刚部署的修订号之后打开{{STATE_DOC}}用第 4 步确认到的值更新deployed version / revision字段对当前状态或版本表中的相关条目只做定向编辑targeted edits only。若第 4 步失败禁止更新状态文档。注意same run, not deferred to session-end这一约束部署状态必须由部署事件本身即时落盘而不是等到会话收尾时由session-end补写。这样即使会话中途崩溃状态文档里也已经留下了部署证据。状态文档的写入纪律谁在什么时候写什么把五个智能体拼起来看状态文档的写入是有明确分工和顺序的deploy-with-verification在部署事件发生时线上验证通过后写入版本/修订号字段session-end明确声明不要重写部署已经更新过的部署状态除非线上验证显示不一致——它只补写教训、问题状态、下一步计划、部署之外发生的漂移且坚持targeted edits only绝不整文件替换见 session-end.mdsession-start在每个工作会话开始时读取状态文档并做线上核对{{LIVE_CHECK}}捕获智能体无法预防的漂移CI-only 发布、手工生产变更、上一会话崩溃未跑 session-end 等发现MISMATCH时先大声标记、协调一致后才开始干活见 session-start.md。一句话总结这套纪律部署状态由部署智能体当场写会话状态由 session-end 补写启动时由 session-start 复核三层各司其职避免状态文档漂移这个生产事故的常见温床。汇报格式每个环节都必须有据可查流水线结束时智能体必须按固定结构汇报不允许含糊Tests: X/X passed测试通过数/总数Build: success/failure构建成功/失败Deploy: success/failure 新 revision/version id部署成功/失败 新修订号Live verification: 实际端点响应内容 是否与所部署构建匹配真实响应文本而非看起来正常State doc: updated / not updated并说明原因这套汇报与 prod-logs-health-check.md 的报告真实数据而非断言精神一脉相承后者同样要求报告时间窗口与拉取日志行数让截断可见、按根因分组错误并附代表性片段、区分去重后的失败数 vs 总出现次数、明确声明无法从日志确认的开放缺口。使用方式与适用前提本智能体属于 operating-kit 插件安装方式为/plugin marketplace add wshobson/agents # 注册整个市场目录 /plugin install operating-kit # 安装 operating-kit 插件安装后该插件下的 5 个智能体含deploy-with-verification随插件一并加载可通过自然语言调用例如deploy the latest build with verification。需要说明的适用前提与限制本仓库是插件市场源deploy-with-verification是一份面向任何项目的可参数化智能体模板其 frontmatter 中的model: sonnet、tools: Bash, Read, Edit和模板变量{{REPO_PATH}}、{{TEST_COMMAND}}等均需在接入具体项目时按实际环境填写文中示例命令仅用于说明占位符语义流水线正确性依赖{{HEALTH_OR_VERSION_ENDPOINT}}确实能反映当前服务版本例如健康端点同时返回 git sha 或镜像 tag若端点只返回200 OK而无法暴露版本标识第 4 步的匹配比对将无从谈起{{STATE_DOC}}应指向项目内被session-start/session-end共同使用的同一份状态文档否则单一事实来源会被割裂。小结deploy-with-verification的可贵之处在于把部署成功从过程定义命令跑完、退出码为 0改写为结果定义线上系统确认新构建在服务流量且状态文档已记录该修订号。对任何被假部署困扰的团队这套测试熔断 线上比对 状态文档即时落盘的三重约束配合 operating-kit 的 pre-ship 审查与 session 首尾核对构成了一条可以端到端追溯的生产上线链路。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考