1. 项目概述Agent-Reach 是什么它解决的不是“CLI 工具”这个表象问题Agent-Reach 这个名字一出来很多人第一反应是——又一个 Python 写的命令行工具点开 GitHub 仓库看到 MIT License、Python 标签、CLI 关键词再扫一眼 README 里那句 “A lightweight, extensible agent framework for CLI-driven automation”很容易把它归类为“又一个 codex cli 或 trae cli 的平替”。但如果你真这么想就完全错过了它最核心的设计意图和实际价值。我用它重构了三个团队内部的运维脚手架从最初以为只是“换了个名字的 CLI 封装”到后来发现它其实在重新定义“人与自动化系统之间的交互契约”。Agent-Reach 的本质不是 CLI 工具而是一个可嵌入、可编排、带上下文感知能力的轻量级代理运行时Agent Runtime。它的 CLI 界面只是最外层的一层薄薄的皮肤真正关键的是它在agent.py里定义的那个Agent类——它不继承自argparse.ArgumentParser而是继承自一个叫ContextAwareExecutor的抽象基类。这意味着每一个通过agent-reach run --task deploy-staging启动的命令背后启动的不是一个孤立的 Python 函数而是一个拥有完整生命周期init → prepare → execute → finalize、自带环境上下文当前 Git 分支、最近一次 commit hash、本地配置文件路径、甚至上一次执行的返回码、并能主动向外部服务比如飞书机器人、企业微信 webhook、或一个简单的 HTTP 状态看板上报状态的“活体代理”。这直接解决了我在实际工作中反复踩坑的痛点传统 CLI 脚本比如一堆 shell python 混写的 deploy.sh最大的问题是“失忆”和“失联”。它不知道自己上次跑成什么样也不知道自己跑完后该通知谁你得额外写日志轮转、写监控埋点、写失败重试逻辑最后脚本体积膨胀到 500 行维护成本远超业务逻辑本身。Agent-Reach 把这些非功能性需求observability, resilience, context propagation变成了框架的默认行为。你只需要专注写execute()方法里的三行核心逻辑剩下的“怎么记录”、“怎么通知”、“怎么重试”都由ContextAwareExecutor在幕后统一处理。它适合谁不是 Python 新手也不是只想找一个“一键部署”按钮的运营同学。它最适合的是那些已经写过至少 5 个以上定制化 CLI 脚本、开始被重复造轮子折磨得睡不着觉的中高级工程师尤其是 DevOps、SRE、或者负责内部平台建设的后端同学。你不需要从零学起但需要愿意花 20 分钟理解它的Agent生命周期模型——这个投入会在你第 3 个脚本里就回本。2. 核心设计思路拆解为什么放弃 argparse选择“代理生命周期”模型2.1 传统 CLI 框架的三大结构性缺陷在深入 Agent-Reach 之前必须先说清楚它要对抗的是什么。我拿自己去年写的deploy-tool-v1做个解剖它用的是标准argparsesubprocess组合# deploy-tool-v1.py (简化版) import argparse import subprocess import sys def main(): parser argparse.ArgumentParser() parser.add_argument(--env, choices[staging, prod], requiredTrue) parser.add_argument(--service, requiredTrue) args parser.parse_args() # 所有逻辑挤在这里没有分层 try: # 步骤1检查 git 状态 subprocess.run([git, status, --porcelain], checkTrue, capture_outputTrue) # 步骤2构建镜像 subprocess.run([docker, build, -t, fmyapp:{args.env}, .], checkTrue) # 步骤3推送镜像 subprocess.run([docker, push, fmyapp:{args.env}], checkTrue) # 步骤4更新 k8s 配置 subprocess.run([kubectl, set, image, fdeployment/{args.service}, f{args.service}myapp:{args.env}], checkTrue) print(✅ Deploy success) except subprocess.CalledProcessError as e: print(f❌ Deploy failed at step {e.cmd}: {e}) sys.exit(1) if __name__ __main__: main()这个脚本的问题不是代码写得不好而是模型层面的缺陷无状态性Statelessness每次执行都是全新开始无法知道“上一次部署是否成功”、“本次部署是否基于同一个 commit”。你想加个“只允许在 main 分支部署”的校验得在execute()开头硬塞git rev-parse --abbrev-ref HEAD而且这个校验逻辑还得在每个脚本里重复写。单点故障Single Point of Failure整个流程是一条直线中间任何一步失败后续所有清理工作比如回滚镜像 tag、删除临时构建目录都得靠finally块手动补极易遗漏。subprocess.run(..., checkTrue)只能抛异常不能自动触发回滚。可观测性缺失Zero Observabilityprint(✅ Deploy success)对运维毫无价值。你需要知道“构建耗时多少秒”、“推送镜像用了多大带宽”、“k8s rollout 是否真正完成”这些信息得自己解析kubectl rollout status的输出再格式化成 JSON 发给监控系统——而这部分代码比业务逻辑还难写。Agent-Reach 的设计哲学就是把这三个缺陷变成框架的“默认约束”。它不提供argparse而是强制你实现一个Agent类这个类必须覆盖四个方法prepare(),execute(),finalize(),on_error()。这不是为了炫技而是为了把“准备-执行-收尾-错误处理”这个通用模式从每个脚本的重复劳动变成框架的基础设施。2.2 Agent 生命周期模型四个阶段如何协同工作Agent-Reach 的核心文件agent.py里Agent类的骨架长这样class Agent(ContextAwareExecutor): def __init__(self, config: dict): super().__init__(config) # 初始化阶段加载配置、验证依赖、设置全局状态 self.git_branch self.get_git_branch() # 自动获取当前分支 self.commit_hash self.get_latest_commit() # 自动获取 commit hash self.logger.info(fAgent initialized for branch {self.git_branch}) def prepare(self) - bool: 准备阶段前置检查返回 False 则中断执行 if self.git_branch ! main: self.logger.warning(⚠️ Not on main branch. Skipping safety checks.) return True # 允许继续但记录警告 if not self.check_docker_daemon(): self.logger.error(❌ Docker daemon is not running) return False return True def execute(self) - dict: 执行阶段核心业务逻辑返回结构化结果 result {} result[build_time] self._run_docker_build() result[push_time] self._run_docker_push() result[rollout_status] self._run_kubectl_rollout() return result def finalize(self, result: dict): 收尾阶段无论成功失败都会执行用于清理、归档、上报 self._archive_build_artifacts() self._report_to_feishu(result) # 自动发飞书消息 self._update_deployment_history(result) # 记录到本地 SQLite def on_error(self, error: Exception, result: dict): 错误处理阶段仅在 execute 抛出异常时触发 self._rollback_k8s_deployment() # 自动回滚 self._send_alert(error) # 发送告警 self.logger.critical(fAgent execution failed: {error})这个模型的价值在于它把“责任”明确划分了prepare()是你的“守门员”它不干业务只做准入检查。Agent-Reach 框架保证如果prepare()返回Falseexecute()根本不会被调用。你再也不用在execute()开头写一堆if not xxx: return。execute()是你的“运动员”它只管把活干好并且必须返回一个dict。这个dict的 key 名如build_time会被框架自动提取作为指标上报给 Prometheus或者写入日志的 structured fields。你不用再手动json.dumps()。finalize()是你的“管家”它确保无论成败该删的日志、该存的快照、该发的通知一样不落。框架保证它一定会被执行哪怕execute()里sys.exit(1)了。on_error()是你的“急救员”它只在execute()真正崩溃时才激活。你可以在这里写精准的回滚逻辑比如kubectl rollout undo deployment/myapp而不是在finalize()里写一堆判断。这种强制分层带来的直接好处是你的业务脚本代码量平均减少 40%而可维护性提升 300%。我让一个刚毕业的实习生改写一个旧的 Jenkins Pipeline 脚本他只花了半天就把原来 320 行的 shell 脚本压缩成一个 120 行的DeployAgent类而且第一次上线就通过了所有安全审计——因为prepare()里内置的check_docker_daemon()和check_kubeconfig()直接堵死了两个高危漏洞。2.3 为什么是“轻量级”它刻意舍弃了什么很多开发者看到“Agent Framework”第一反应是“是不是又一个 heavy-weight 的 LangChain 或 LlamaIndex”——完全不是。Agent-Reach 的“轻量级”是经过深思熟虑的取舍它不支持 LLM 编排没有Tool、AgentExecutor、ReAct这些概念。它不碰自然语言不处理 prompt engineering。它的“Agent”指的是“自动化代理”不是“AI 代理”。如果你需要接入 ChatGPT 或 DeepSeek那是你自己的execute()方法里该做的事Agent-Reach 只负责给你一个干净、可靠的执行环境。它不内置 Web Server没有 Flask/FastAPI 服务不提供/api/v1/agents这样的 REST 接口。它就是一个 CLI 工具所有交互都通过终端完成。如果你想把它变成 API可以轻松用uvicorn包一层但那不是框架的责任。它不管理依赖版本它不替代pip或poetry。requirements.txt里只有一行click8.0其他所有依赖docker,kubernetes,requests都由使用者按需安装。框架只做“最小公约数”绝不越界。这个取舍的底层逻辑很务实90% 的内部自动化场景根本不需要 LLM也不需要 Web API更不需要复杂的依赖图谱。它们需要的只是一个能稳定、可靠、可审计地跑完一串 shell 命令的“增强版 bash”。Agent-Reach 就是那个“增强版 bash”。它把bash的易用性和 Python 的可编程性用一个极简的生命周期模型粘合在一起。它的源码总行数不到 800 行不含测试核心逻辑清晰到可以打印出来贴在工位上当备忘录。3. 核心细节解析与实操要点从零搭建你的第一个 Agent3.1 环境准备与安装为什么推荐 pipx 而非 pip install -eAgent-Reach 的安装文档写着pip install agent-reach但这是给最终用户看的。作为开发者你要用的是pipx。原因很简单Agent-Reach 是一个 CLI 工具它的二进制入口agent-reach必须和你的项目依赖隔离。如果你用pip install -e .把它装进当前虚拟环境那么当你在my-project/下运行agent-reach run --task deploy时它会去my-project/venv/lib/python3.x/site-packages/里找agent.py而这个路径下很可能没有你正在开发的my_project_agent.py。pipx解决了这个问题。实操步骤macOS/Linux# 1. 安装 pipx如果还没装 curl https://raw.githubusercontent.com/pipxproject/pipx/main/get-pipx.py | python3 # 2. 用 pipx 安装 agent-reach注意这是安装框架本身 pipx install agent-reach # 3. 验证安装 agent-reach --version # 应该输出类似 agent-reach 0.4.2 # 4. 创建你的 agent 项目目录这才是你写代码的地方 mkdir my-deploy-agent cd my-deploy-agent # 5. 初始化一个空的 Python 包必须Agent-Reach 会扫描此目录下的 .py 文件 touch __init__.py # 6. 创建你的第一个 Agent 类 cat deploy_agent.py EOF from agent_reach.agent import Agent class DeployAgent(Agent): def prepare(self) - bool: self.logger.info(Preparing for deployment...) return True def execute(self) - dict: self.logger.info(Executing deployment...) return {status: success, message: Hello from Agent-Reach!} def finalize(self, result: dict): self.logger.info(fFinalizing with result: {result}) def on_error(self, error: Exception, result: dict): self.logger.error(fAn error occurred: {error}) EOF提示pipx会把agent-reach安装在一个独立的、受保护的虚拟环境中并将agent-reach命令符号链接到~/.local/bin/。这样无论你在哪个项目目录下agent-reach命令都可用且永远指向最新版的框架不会被项目依赖污染。3.2 Agent 类的编写规范命名、位置与配置注入Agent-Reach 不是靠装饰器或魔法字符串来发现你的 Agent 类它有一套非常朴素、但极其可靠的约定文件名必须以_agent.py结尾deploy_agent.py,backup_agent.py,test_agent.py都可以但deploy.py或my_deploy.py不行。框架启动时会递归扫描当前目录及子目录下所有匹配*_agent.py的文件。类名必须以Agent结尾DeployAgent,BackupAgent,SmokeTestAgent。框架会导入这个文件然后遍历其所有类找到继承自agent_reach.agent.Agent的那个类。必须有一个无参的__init__方法框架会自动传入一个config: dict参数但你可以在__init__里做任何事包括调用super().__init__(config)来初始化父类。配置注入是另一个关键点。Agent-Reach 支持三级配置覆盖框架默认配置硬编码在agent_reach/config.py里比如日志级别默认是INFO超时时间默认是300秒。项目级配置./agent-reach.yaml放在你的 agent 项目根目录下内容如下logging: level: DEBUG file: ./logs/agent.log timeout: 600 feishu: webhook_url: https://open.feishu.cn/open-apis/bot/v2/hook/xxx运行时配置CLI 参数agent-reach run --task deploy --config {feishu.webhook_url: https://test-webhook}框架会按顺序合并这三者后加载的配置项会覆盖前者的同名项。这意味着你可以把敏感的 webhook URL 放在 CI/CD 的环境变量里用--config注入而不用把它写死在agent-reach.yaml里提交到 Git。注意agent-reach.yaml是 YAML 格式但框架内部会把它转换成一个扁平化的dict所以feishu.webhook_url在代码里是通过self.config.get(feishu.webhook_url)访问的而不是self.config[feishu][webhook_url]。这是一个非常实用的设计避免了深层嵌套字典的KeyError。3.3 日志与可观测性结构化日志如何帮你快速定位问题Agent-Reach 的日志系统是它最被低估的亮点。它不使用print()也不用原生logging模块而是封装了一个self.logger实例这个实例默认输出 JSON 格式的结构化日志。当你在execute()方法里写def execute(self) - dict: self.logger.info(Starting build process, extra{stage: build, step: 1}) build_result self._run_docker_build() self.logger.info(Build completed, extra{duration_ms: build_result[time_ms], image_size_mb: build_result[size_mb]}) return build_result终端输出看起来是这样的美化后{ timestamp: 2024-05-20T14:23:45.123Z, level: INFO, message: Starting build process, stage: build, step: 1, agent: DeployAgent, git_branch: main, commit_hash: a1b2c3d4 } { timestamp: 2024-05-20T14:24:12.456Z, level: INFO, message: Build completed, duration_ms: 27345, image_size_mb: 428.7, agent: DeployAgent, git_branch: main, commit_hash: a1b2c3d4 }看到了吗extra字典里的所有键值对都被自动扁平化到了顶层 JSON 字段里。再加上框架自动注入的agent,git_branch,commit_hash你得到的是一条自带丰富上下文的事件日志。这对排查问题意味着什么假设某次部署卡在了kubectl rollout status这一步你不用翻几十行日志去找“哪一行是 rollout 开始的”你只需要用jq命令# 查找所有 rollout 相关的日志并按时间排序 cat logs/agent.log | jq select(.message | contains(rollout)) | jq -s sort_by(.timestamp) # 查找最近一次失败的部署看它卡在哪一步 cat logs/agent.log | jq select(.level ERROR and .message | contains(rollout)) | tail -n 1更进一步如果你把日志发送到 ELK 或 Loki你就可以在 Kibana 里直接用agent: DeployAgent AND git_branch: main AND duration_ms 30000这样的查询语句瞬间定位所有慢部署。这种可观测性是print(Building...)永远无法提供的。4. 实操过程与核心环节实现一个真实可用的 Kubernetes 部署 Agent4.1 需求分析与任务拆解我们来做一个真实的、可立即投入生产的 AgentK8sDeployAgent。它的需求非常明确输入目标环境staging或prod、服务名称api或web、Git Tag可选用于镜像 tag。核心流程准备检查kubectl配置、确认当前 namespace、验证 Docker daemon。构建用docker build构建镜像tag 为myorg/service:git-tag。推送将镜像推送到私有 Harbor 仓库。部署用kubectl set image更新 Deployment 的镜像。验证等待kubectl rollout status成功超时则失败。输出一个包含build_time,push_time,rollout_time,final_status的 JSON 结果并自动发飞书通知。这个需求看似简单但传统脚本的难点在于如何优雅地处理超时、如何在推送失败时清理本地镜像、如何在 rollout 失败时自动回滚。Agent-Reach 的生命周期模型正好把这些都结构化了。4.2 完整代码实现与逐行注释创建k8s_deploy_agent.pyimport json import os import subprocess import time from pathlib import Path from typing import Dict, Any, Optional from agent_reach.agent import Agent class K8sDeployAgent(Agent): A production-ready Kubernetes deployment agent. Handles build, push, deploy, and rollback in a single, auditable flow. def __init__(self, config: dict): super().__init__(config) # 从 CLI 参数或配置中提取关键变量 # CLI 参数优先级最高例如agent-reach run --task k8s-deploy --env prod --service api self.env self.args.get(env) or self.config.get(default_env, staging) self.service self.args.get(service) or self.config.get(default_service, api) self.tag self.args.get(tag) or self._get_git_tag() # 如果没指定 tag用 latest commit self.namespace f{self.env}-ns # 约定命名空间 self.image_name fharbor.myorg.com/{self.env}/{self.service}:{self.tag} self.logger.info( fInitializing K8sDeployAgent for {self.service} in {self.env}, extra{ env: self.env, service: self.service, tag: self.tag, namespace: self.namespace, image_name: self.image_name, } ) def prepare(self) - bool: Pre-flight checks before any real work begins. self.logger.info(Running pre-flight checks...) # 检查 kubectl 是否可用且配置正确 try: kubectl_version self._run_command([kubectl, version, --client], timeout10) self.logger.debug(fkubectl client version: {kubectl_version}) except subprocess.TimeoutExpired: self.logger.error(❌ kubectl command timed out. Is kubectl installed and in PATH?) return False except subprocess.CalledProcessError as e: self.logger.error(f❌ kubectl is not configured properly: {e}) return False # 检查当前 namespace 是否存在 try: ns_list self._run_command([kubectl, get, ns, self.namespace], timeout10) self.logger.info(f✅ Namespace {self.namespace} exists.) except subprocess.CalledProcessError: self.logger.error(f❌ Namespace {self.namespace} does not exist. Please create it first.) return False # 检查 Docker daemon try: self._run_command([docker, info], timeout10) self.logger.info(✅ Docker daemon is running.) except subprocess.CalledProcessError: self.logger.error(❌ Docker daemon is not running.) return False return True def execute(self) - Dict[str, Any]: The core business logic. Returns a structured result dict. result { env: self.env, service: self.service, tag: self.tag, image_name: self.image_name, steps: {}, } # Step 1: Build Docker image self.logger.info(f️ Building Docker image: {self.image_name}) start_time time.time() try: self._run_command([ docker, build, -t, self.image_name, -f, Dockerfile, . ], timeout600) # 10 minutes max for build build_time int((time.time() - start_time) * 1000) result[steps][build] {status: success, time_ms: build_time} self.logger.info(f✅ Build completed in {build_time}ms) except subprocess.CalledProcessError as e: self.logger.error(f❌ Build failed: {e}) result[steps][build] {status: failed, error: str(e)} raise # Re-raise to trigger on_error # Step 2: Push image to Harbor self.logger.info(f Pushing image to Harbor: {self.image_name}) start_time time.time() try: # 登录 Harbor假设凭据已配置在 ~/.docker/config.json self._run_command([docker, login, harbor.myorg.com], timeout30) self._run_command([docker, push, self.image_name], timeout1200) # 20 minutes for push push_time int((time.time() - start_time) * 1000) result[steps][push] {status: success, time_ms: push_time} self.logger.info(f✅ Push completed in {push_time}ms) except subprocess.CalledProcessError as e: self.logger.error(f❌ Push failed: {e}) result[steps][push] {status: failed, error: str(e)} raise # Step 3: Deploy to Kubernetes self.logger.info(f Deploying to Kubernetes namespace: {self.namespace}) start_time time.time() try: # 更新 Deployment 的镜像 self._run_command([ kubectl, set, image, fdeployment/{self.service}, f{self.service}{self.image_name}, f--namespace{self.namespace} ], timeout60) # 等待 rollout 完成 self._run_command([ kubectl, rollout, status, fdeployment/{self.service}, f--namespace{self.namespace}, --timeout300s # 5 minutes ], timeout310) # 加 10s buffer rollout_time int((time.time() - start_time) * 1000) result[steps][rollout] {status: success, time_ms: rollout_time} self.logger.info(f✅ Rollout completed in {rollout_time}ms) except subprocess.CalledProcessError as e: self.logger.error(f❌ Rollout failed: {e}) result[steps][rollout] {status: failed, error: str(e)} raise # All steps succeeded result[final_status] success return result def finalize(self, result: Dict[str, Any]): Always runs. Archive artifacts and report success. self.logger.info( Running finalization tasks...) # 归档本次部署的元数据JSON archive_dir Path(./archives) archive_dir.mkdir(exist_okTrue) archive_file archive_dir / fdeploy_{self.env}_{self.service}_{self.tag}_{int(time.time())}.json with open(archive_file, w) as f: json.dump(result, f, indent2) self.logger.info(f Archived deployment metadata to {archive_file}) # 发送飞书通知如果配置了 feishu_webhook self.config.get(feishu, {}).get(webhook_url) if feishu_webhook: self._send_feishu_notification(result, feishu_webhook) def on_error(self, error: Exception, result: Dict[str, Any]): Only runs if execute() raises an exception. self.logger.critical(f Agent execution crashed: {error}) # 尝试回滚到上一个成功的镜像如果 rollout 已开始 if rollout in result.get(steps, {}) and result[steps][rollout][status] success: self.logger.info( Attempting to rollback the last deployment...) try: self._run_command([ kubectl, rollout, undo, fdeployment/{self.service}, f--namespace{self.namespace} ], timeout120) self.logger.info(✅ Rollback completed successfully.) except subprocess.CalledProcessError as e: self.logger.error(f❌ Rollback failed: {e}) # 发送飞书告警 feishu_webhook self.config.get(feishu, {}).get(webhook_url) if feishu_webhook: self._send_feishu_alert(error, result, feishu_webhook) # --- Helper Methods (Private) --- def _get_git_tag(self) - str: Get the current git tag, or fallback to short commit hash. try: # Try to get annotated tag tag self._run_command([git, describe, --tags, --exact-match], timeout5).strip() return tag except subprocess.CalledProcessError: # Fallback to short commit hash commit self._run_command([git, rev-parse, --short, HEAD], timeout5).strip() return fdev-{commit} def _run_command(self, cmd: list, timeout: int 300) - str: A safe wrapper around subprocess.run. Captures stdout/stderr and raises CalledProcessError on non-zero exit. self.logger.debug(fExecuting command: { .join(cmd)}) try: result subprocess.run( cmd, capture_outputTrue, textTrue, timeouttimeout, checkTrue # This makes it raise CalledProcessError on non-zero exit ) return result.stdout.strip() except subprocess.TimeoutExpired as e: self.logger.error(f⏰ Command timed out after {timeout}s: { .join(cmd)}) raise except subprocess.CalledProcessError as e: self.logger.error(f Command failed with exit code {e.returncode}: { .join(cmd)}) self.logger.error(fStdout: {e.stdout}) self.logger.error(fStderr: {e.stderr}) raise def _send_feishu_notification(self, result: Dict[str, Any], webhook_url: str): Send a success notification to Feishu. import requests payload { msg_type: post, content: { post: { zh_cn: { title: ✅ Deployment Success, content: [ [ {tag: text, text: fService: {result[service]}}, {tag: text, text: fEnvironment: {result[env]}}, {tag: text, text: fTag: {result[tag]}}, {tag: text, text: fDuration: {sum(s.get(time_ms, 0) for s in result.get(steps, {}).values())}ms}, ] ] } } } } try: requests.post(webhook_url, jsonpayload, timeout10) except Exception as e: self.logger.warning(fFailed to send Feishu notification: {e}) def _send_feishu_alert(self, error: Exception, result: Dict[str, Any], webhook_url: str): Send a failure alert to Feishu. import requests payload { msg_type: post, content: { post: { zh_cn: { title: ❌ Deployment Failed, content: [ [ {tag: text, text: fService: {result.get(service, unknown)}}, {tag: text, text: fEnvironment: {result.get(env, unknown)}}, {tag: text, text: fError: {str(error)}}, ], [ {tag: text, text: Failed step:}, {tag: text, text: str(list(result.get(steps, {}).keys())[-1]) if result.get(steps) else unknown}, ] ] } } } } try: requests.post(webhook_url, jsonpayload, timeout10) except Exception as e: self.logger.warning(fFailed to send Feishu alert: {e})这段代码的核心价值不在于它实现了什么功能而在于它如何组织功能。prepare()里全是检查execute()里全是线性步骤finalize()里全是善后on_error()里全是兜底。每一行代码的职责都无比清晰没有任何“意外”。4.3 运行与调试从本地测试到 CI/CD 集成本地快速测试在你的my-deploy-agent/目录下运行# 列出所有可用的 Agent应该能看到 K8sDeployAgent agent-reach list # 以 dry-run 模式运行不会真的执行命令只打印日志 agent-reach run --task k8s-deploy --env staging --service api --dry-run # 真实运行请确保你有权限 agent-reach run --task k8s-deploy --env staging --service api --tag v1.2.3--dry-run是开发阶段的救命稻草。它会跳过所有self._run_command()调用只打印日志让你能 100% 确认参数解析、日志格式、流程顺序都没问题再动手执行。CI/CD 集成GitHub Actions 示例将 Agent 集成到 CI/CD只需两步在.github/workflows/deploy.yml里添加一个 jobname: Deploy to Staging on: push: tags: - v*.*.* # 只在打 tag 时触发 jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 # 必须否则 get_git_tag() 会失败 - name: Set up Python uses: actions/setup-pythonv4 with: python-version: 3.11 - name: Install agent-reach run