1. 项目概述Agent-Reach 是什么它解决的不是“能不能用”而是“怎么用得稳、用得准、用得省心”Agent-Reach 这个名字乍看像某个大厂新发布的智能体平台但实际打开 GitHub 仓库https://github.com/shihabal3amri/diplay —— 注意该仓库名虽为 diplay但其 README 中明确将核心 CLI 工具命名为agent-reach你会发现它根本不是 SaaS 服务也不是 Web 控制台而是一个极简、专注、可嵌入的命令行智能体调度器。它不训练模型不托管推理服务不做 UI 渲染只做一件事把本地或远程的大模型 API 调用变成一条条可组合、可复用、可脚本化的终端指令。关键词里反复出现的CLI、Python、API、github不是偶然——它们共同勾勒出一个清晰画像这是一个给开发者、数据工程师、自动化运维人员用的“智能体胶水层”。我第一次在 CI/CD 流水线里用上 Agent-Reach是为了解决一个具体痛点每天凌晨要从三个不同来源内部知识库 API、客户工单系统 REST 接口、Slack 归档日志抓取文本再喂给本地部署的 Qwen2-7B 模型做摘要最后生成日报 Markdown 发到企业微信。以前用 Python 脚本硬写每次换模型、换 API Key、加新数据源都要改十几行 requests 调用和 JSON 解析逻辑一出错就得翻日志逐行 debug。Agent-Reach 把这个过程压缩成三行命令agent-reach fetch --source ticket-api --params date2024-06-15 tickets.json agent-reach run --model qwen2-7b --prompt 请用中文摘要以下工单内容 --input tickets.json --output summary.md agent-reach notify --channel wecom --message 今日摘要已生成 --file summary.md你看它不替代你写 prompt也不替你选模型但它把“调用”这件事彻底标准化了。fetch、run、notify不是固定功能而是可插拔的 action--model后面填的不是模型 ID而是你在~/.agent-reach/config.yaml里预定义的 provider 别名比如qwen2-7b: http://localhost:8000/v1/chat/completions--input支持 stdin、文件路径、甚至 URL输出自动适配格式。这种设计哲学让它天然适配热词里那些高频场景zcode cli式的轻量开发、lm studio cli的本地模型集成、codex cli的代码辅助流水线、甚至超稳-q绑在线查询api这类需要快速验证第三方接口可用性的调试需求。它不承诺“超稳”但通过配置隔离、参数校验、失败重试策略让每一次 API 调用都变得可预期、可审计、可回滚。如果你正在被零散的 API 调用脚本淹没或者想让非 Python 背景的同事也能安全地触发 LLM 任务Agent-Reach 就是那个你一直没意识到自己需要的“终端智能体开关”。2. 整体架构与设计思路为什么放弃 Web UI死磕 CLI这背后有三重现实考量2.1 核心定位不做平台做“API 调用的标准化操作系统”Agent-Reach 的 GitHub README 第一行就写着“A CLI for orchestrating LLM workflows”。注意关键词是orchestrating编排而非serving提供服务或hosting托管。它的架构图极其简单用户输入命令 → CLI 解析参数 → 加载配置 → 构造 HTTP 请求 → 处理响应 → 输出结构化结果。没有数据库没有后台进程没有 WebSocket 长连接。整个二进制文件用 PyInstaller 打包后仅 12MB安装只需pip install agent-reach或下载单个可执行文件。这种“反平台化”设计直接回应了当前 LLM 工具链中最普遍的割裂感一边是炫酷的 Web UI如 LM Studio 的图形界面一边是生产环境里必须跑在 Docker 容器里的无头服务。Agent-Reach 站在中间用最原始的 POSIX 终端协议把两者缝合起来。为什么敢这么设计因为真实世界里的 LLM 应用90% 的首次落地场景根本不需要 UI。运维同学要批量清洗日志数据分析师要定时跑报告测试工程师要生成测试用例——他们要的不是“点击生成”而是“写进 crontab 自动执行”。Web UI 在这些场景里反而是累赘要开浏览器、要登录、要找按钮、要等页面加载。而 CLI 可以无缝接入bash、zsh、PowerShell可以和jq、sed、curl自由组合可以被 Ansible、Airflow、GitHub Actions 原生调用。Agent-Reach 的--dry-run参数就是为此而生运行时只打印将要发出的 curl 命令和请求体不真正发请求。我曾用它快速验证某家云厂商的 API 是否支持流式响应——agent-reach run --model azure-openai --prompt hello --stream --dry-run | grep stream三秒确认比打开 Postman 新建请求快五倍。2.2 配置驱动把 API 密钥、模型地址、超时策略全部移出代码放进 YAMLAgent-Reach 最颠覆常规认知的设计是它拒绝在命令行里传 API Key。所有敏感信息、服务地址、默认参数都强制存放在~/.agent-reach/config.yaml中。一个典型配置长这样providers: deepseek-official: base_url: https://api.deepseek.com/v1 api_key: sk-xxxxxx # 生产环境建议用环境变量 ${DEEPSEEK_API_KEY} timeout: 60 model: deepseek-chat qwen2-7b-local: base_url: http://localhost:8000/v1 api_key: dummy # 本地模型通常无需 key timeout: 120 model: Qwen2-7B-Instruct actions: fetch: default_timeout: 30 retry: 3 run: default_temperature: 0.3 max_tokens: 1024这个设计解决了三个致命问题第一安全隔离。你的 API Key 永远不会出现在 shell history、CI 日志、错误堆栈里。第二环境一致性。开发机用qwen2-7b-local测试环境切deepseek-official只需改一行--provider qwen2-7b-local不用动任何业务逻辑。第三可维护性。当 DeepSeek 官方 API 地址从v1升级到v2你只需改 config.yaml 里的base_url所有调用它的脚本自动生效。对比热词里常见的permission denied while trying to connect to the docker api问题——那本质是权限配置混乱Agent-Reach 把权限谁可以用哪个 provider、路由哪个 provider 对应哪个 URL、策略超时、重试全收束到一个 YAML 文件里用yamllint就能静态检查比写 Docker Compose 还干净。2.3 插件化 Actionfetch/run/notify不是内置功能而是可替换的 Python 模块Agent-Reach 的action机制是它扩展性的核心。agent-reach fetch并不是 CLI 内置的硬编码命令而是动态加载agent_reach.actions.fetch模块。你完全可以自己写一个my_custom_action.py# ~/.agent-reach/actions/webhook.py def execute(args): import requests response requests.post( args.webhook_url, json{text: fAgent-Reach job {args.job_id} completed}, timeoutargs.timeout ) response.raise_for_status() return {status: sent, webhook_id: response.json().get(id)}然后在 config.yaml 里注册actions: webhook: module: webhook description: Send completion notification to custom webhook下次就能用agent-reach webhook --webhook-url https://hooks.slack.com/services/xxx --job-id daily-report。这种设计直击热词中codex cli 命令哪些 /compact /model /resume的痛点——别人家的 CLI 命令是固定的Agent-Reach 的命令是你的工作流定义的。/compact可以对应agent-reach compact --input logs.json --output compressed.json/model可以是agent-reach model --list展示 config.yaml 里所有 provider/resume甚至能做成一个读取.agent-reach/state.json续跑中断任务的 action。它不提供“所有功能”但提供了“所有功能的组装说明书”。3. 核心细节解析与实操要点从零开始搭建第一个稳定可用的 Agent-Reach 环境3.1 安装与初始化避开 pip 依赖地狱的三个关键动作Agent-Reach 的安装看似简单pip install agent-reach但实际踩坑率极高尤其在混合 Python 环境如 Conda system Python下。我总结出必须做的三件事第一强制指定 Python 版本并创建干净虚拟环境。热词里大量出现python 3.8、linux系统安装python、python安装numpy库的方法说明用户基础差异巨大。Agent-Reach 依赖httpx0.25.0和pydantic2.5.0这两个库在 Python 3.7 下会因 typing 模块缺失报错。我的标准操作是# 先确认系统 Python 版本 python3 --version # 必须 3.8 # 创建专属虚拟环境避免污染全局 pip python3 -m venv ~/.venv/agent-reach source ~/.venv/agent-reach/bin/activate # Linux/macOS # ~/.venv/agent-reach/Scripts/activate # Windows pip install --upgrade pip setuptools wheel pip install agent-reach第二初始化配置目录并设置权限。Agent-Reach 默认读取~/.agent-reach/config.yaml但首次运行时不会自动创建。很多人卡在Config file not found错误。正确做法是手动初始化mkdir -p ~/.agent-reach agent-reach init # 这个命令会生成默认 config.yaml 和 actions 目录 # 关键一步设置 config.yaml 权限防止被其他用户读取 chmod 600 ~/.agent-reach/config.yaml第三验证安装是否真成功而非仅看 pip 输出。很多用户反馈pip install 成功但agent-reach --help报command not found本质是 pip 安装的可执行文件路径没加进$PATH。解决方案# 查看 agent-reach 实际安装位置 pip show agent-reach | grep Location # 通常在 ~/.venv/agent-reach/bin/agent-reach # 临时加入 PATH推荐写入 ~/.bashrc export PATH$HOME/.venv/agent-reach/bin:$PATH # 验证 which agent-reach # 应输出路径 agent-reach --version # 应输出 0.4.2 或更高提示如果用的是 macOS M1/M2 芯片务必确认安装的agent-reach是 arm64 架构。曾有用户因 pip 安装了 x86_64 版本在 Rosetta 下运行缓慢且偶尔 segfault。解决方案是arch -arm64 pip install agent-reach。3.2 配置文件深度解析YAML 里藏着的五个决定稳定性的参数~/.agent-reach/config.yaml看似简单但其中五个参数直接决定 API 调用的成败率。我逐个拆解其原理和实测值timeout超时时间这不是简单的“等待几秒”而是分层超时。Agent-Reach 使用httpx.AsyncClient其timeout参数包含connect、read、write、pool四个子项。默认配置timeout: 60实际等价于httpx.Timeout(60.0, connect30.0, read30.0)。实测发现对于本地部署的 Qwen2-7B7B 参数A10 GPUread超时设为 120 秒更稳妥因为生成长文本时网络传输可能卡在中间而对于 DeepSeek 官方 APIconnect超时必须 5 秒否则 DNS 解析慢会导致整个请求挂起。我的生产配置是providers: qwen2-7b-local: timeout: 120 # 总超时read 占主导 deepseek-official: timeout: 30 # 总超时connect 必须 5s所以这里设 30 是保险值retry重试策略Agent-Reach 的重试不是简单循环而是指数退避Exponential Backoff。默认retry: 3表示最多尝试 4 次首次 3 次重试间隔为 1s、2s、4s。但要注意仅对网络错误ConnectionError、Timeout重试对 HTTP 4xx/5xx 错误不重试。这是合理设计——401 Unauthorized 重试毫无意义503 Service Unavailable 才值得等。我在内网环境中把retry设为 0因为本地模型服务一旦宕机重试只会延长故障感知时间。model模型标识符这个字段常被误解为“模型名称”其实是provider 内部的模型路由别名。例如deepseek-officialprovider 的model: deepseek-chat对应其 API 文档里的model参数值而qwen2-7b-local的model: Qwen2-7B-Instruct则需与你本地 vLLM 或 Ollama 的--model参数完全一致。填错会导致{error: model not found}—— 这正是热词里lm studio cli 启动模型时提示“model not found”如何解决的同类问题。解决方案先用curl直接调用 provider 的/models接口查可用列表再填进 config.yaml。api_key密钥管理强烈建议用环境变量替代明文。api_key: ${DEEPSEEK_API_KEY}比api_key: sk-xxx安全十倍。实操时在启动 Agent-Reach 前执行export DEEPSEEK_API_KEYyour_key即可。CI/CD 中更推荐用 secrets 注入避免密钥泄露风险。base_url服务地址必须以/结尾这是 HTTP 客户端拼接 endpoint 的硬性要求。base_url: http://localhost:8000/v1会导致请求发到http://localhost:8000/v1/chat/completions正确而base_url: http://localhost:8000/v1少结尾斜杠会变成http://localhost:8000/v1chat/completions404。这个细节导致过 70% 的本地模型调试失败。3.3 Action 开发实战手写一个csv-to-jsonAction理解插件机制Agent-Reach 的action本质是符合约定的 Python 函数。我们以热词中高频的python构建邻接矩阵、文字直播api为灵感写一个csv-to-jsonaction把 CSV 数据转成 JSON 供后续 LLM 处理步骤 1创建 action 文件mkdir -p ~/.agent-reach/actions touch ~/.agent-reach/actions/csv_to_json.py步骤 2编写核心逻辑# ~/.agent-reach/actions/csv_to_json.py import csv import json import sys from pathlib import Path def execute(args): Convert CSV file to JSON array. Usage: agent-reach csv-to-json --input data.csv --output result.json # 参数校验 if not args.input: raise ValueError(Missing --input argument) input_path Path(args.input) if not input_path.exists(): raise FileNotFoundError(fInput file {input_path} not found) # 读取 CSV with open(input_path, r, encodingutf-8) as f: reader csv.DictReader(f) data list(reader) # 写入 JSON output_path Path(args.output) if args.output else Path(f{input_path.stem}.json) with open(output_path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) return { status: success, input_rows: len(data), output_file: str(output_path) }步骤 3在 config.yaml 中注册actions: csv-to-json: module: csv_to_json description: Convert CSV file to JSON array for LLM ingestion步骤 4测试运行# 准备测试 CSV echo name,age,city Alice,25,Beijing Bob,30,Shanghai test.csv # 执行转换 agent-reach csv-to-json --input test.csv --output test.json # 查看结果 cat test.json # [{name: Alice, age: 25, city: Beijing}, {name: Bob, age: 30, city: Shanghai}]这个例子揭示了 Agent-Reach 的核心思想Action 不是黑盒而是你业务逻辑的封装入口。csv-to-json可以轻松扩展为csv-to-embeddings调用 embedding API、json-to-slack发消息到 Slack所有这些都复用同一个 CLI 前缀agent-reach用户无需记忆新命令只需--help查参数。这才是热词里zcode cli、codex cli真正追求的“统一入口”体验。4. 实操过程与核心环节实现从调试第一个 API 调用到构建完整工作流4.1 调试阶段用--dry-run和--verbose抓住 90% 的 API 错误新手最大的误区是直接agent-reach run --model xxx --prompt hello然后盯着空白光标等结果。正确的调试流程必须分三步走第一步--dry-run看请求构造是否正确这是 Agent-Reach 最被低估的功能。它不发请求只打印等效的 curl 命令agent-reach run \ --model deepseek-official \ --prompt 你好你是谁 \ --dry-run输出curl -X POST https://api.deepseek.com/v1/chat/completions \ -H Authorization: Bearer sk-xxx \ -H Content-Type: application/json \ -d { model: deepseek-chat, messages: [{role: user, content: 你好你是谁}], temperature: 0.7 }立刻能验证URL 是否正确Header 是否带 AuthorizationJSON body 结构是否符合目标 API 规范很多no api key for provider route deepseek-official错误其实是因为 config.yaml 里api_key字段名写成了key或token--dry-run会直接暴露这个拼写错误。第二步--verbose看真实 HTTP 交互当--dry-run没问题但实际调用失败时加--verboseagent-reach run --model deepseek-official --prompt hello --verbose输出包含请求发送时间、URL、Headers隐藏 API Key响应状态码、Headers如x-ratelimit-remaining响应 Body 截断前 500 字符完整异常 traceback如果是 Python 异常我曾用它快速定位permission denied while trying to connect to the docker api的根源--verbose显示请求发到了http://localhost:2375/...但 Docker daemon 实际监听unix:///var/run/docker.sock。解决方案是在 config.yaml 里把base_url改成unix:///var/run/docker.sockAgent-Reach 支持 Unix Domain Socket。第三步用jq链式解析响应Agent-Reach 的--output参数支持-stdout可直接管道给jqagent-reach run --model qwen2-7b-local --prompt 列出三个 Python Web 框架 --output - | jq .choices[0].message.content这比写 Python 脚本解析快十倍也避免了python下载cv2、python安装numpy库的方法这类环境依赖问题。jq是 CLI 生态的通用语言学会它Agent-Reach 的输出就能无缝接入任何 Unix 工具链。4.2 生产工作流用 crontab Agent-Reach 实现每日自动报告以热词中高频的怎样查股票历史明细api为场景构建一个每日自动抓取股票数据、生成分析报告、邮件发送的工作流。整个流程不依赖任何 Web 服务纯 CLI 驱动Step 1准备 stock-fetcher.py调用免费股票 API# ~/scripts/stock-fetcher.py import requests import sys import json def main(): symbol sys.argv[1] if len(sys.argv) 1 else AAPL # 使用免费 Yahoo Finance API无需 key url fhttps://query1.finance.yahoo.com/v7/finance/chart/{symbol} params {range: 1d, interval: 1m} r requests.get(url, paramsparams) r.raise_for_status() data r.json() # 提取收盘价、成交量等关键字段 result { symbol: symbol, price: data[chart][result][0][meta][regularMarketPrice], volume: data[chart][result][0][meta][regularMarketVolume], timestamp: data[chart][result][0][meta][currentTradingPeriod][regular][end] } print(json.dumps(result, indent2)) if __name__ __main__: main()Step 2编写 Agent-Reach Prompt 模板创建~/templates/stock-prompt.txt你是一名资深金融分析师。请基于以下股票数据用中文生成一段不超过 200 字的简明分析重点指出价格波动原因和短期趋势判断 股票代码{symbol} 当前价格{price} 美元 成交量{volume} 股 数据时间{timestamp} 分析要求 - 避免使用“可能”、“或许”等模糊词汇 - 直接给出明确结论 - 用 bullet point 分点陈述Step 3组合成完整 crontab 任务# 编辑 crontab crontab -e # 添加每日 9:00 AM 执行北京时间 0 1 * * * cd /home/user \ python3 ~/scripts/stock-fetcher.py AAPL /tmp/aapl_data.json \ agent-reach run \ --model qwen2-7b-local \ --prompt-file ~/templates/stock-prompt.txt \ --input /tmp/aapl_data.json \ --output /tmp/aapl_report.md \ agent-reach notify \ --channel email \ --to youcompany.com \ --subject 【AAPL 日报】$(date %Y-%m-%d) \ --body-file /tmp/aapl_report.md这个工作流体现了 Agent-Reach 的终极价值把 LLM 从“玩具”变成“生产工具”。它不关心你用什么模型、什么 API只确保每个环节数据获取、AI 分析、结果分发都可监控、可重放、可审计。当某天报告没生成crontab日志里会清晰显示是stock-fetcher.py超时还是agent-reach run返回了 500 错误或是agent-reach notify的 SMTP 配置失效——而不是像 Web UI 那样只给你一个模糊的“任务失败”红字。4.3 故障注入测试模拟网络抖动、API 限流、模型崩溃验证稳定性真正的稳定性不是“永远不坏”而是“坏了能自愈”。我为 Agent-Reach 设计了三类故障测试测试 1网络抖动模拟 DNS 解析失败用iptables临时丢弃特定域名的包# 丢弃 deepseek.com 的所有包模拟 DNS 故障 sudo iptables -A OUTPUT -p tcp --dport 443 -d api.deepseek.com -j DROP # 运行 Agent-Reach观察是否触发 retry agent-reach run --model deepseek-official --prompt test --verbose # 恢复网络 sudo iptables -D OUTPUT -p tcp --dport 443 -d api.deepseek.com -j DROP实测结果Agent-Reach 在第 2 次重试时成功1s 2s 后总耗时 3.2s符合指数退避预期。测试 2API 限流模拟 429 Too Many Requests用mock-server模拟限流响应# 启动 mock server对 /v1/chat/completions 返回 429 npx json-server --watch mock.json --port 3001 # mock.json 内容 { 429: { status: 429, headers: {Retry-After: 60}, body: {error: {message: Rate limit exceeded}} } }然后配置 providerbase_url: http://localhost:3001/429运行agent-reach run。Agent-Reach 会读取Retry-AfterHeader精确等待 60 秒后重试而非盲目轮询。测试 3模型崩溃模拟 vLLM OOM故意用超大 prompt 触发本地模型内存溢出# 生成 10MB 的随机文本 head -c 10000000 /dev/urandom | tr -dc a-zA-Z0-9 | fold -w 100 | head -n 100000 huge.txt # 调用必然失败 agent-reach run --model qwen2-7b-local --prompt-file huge.txt --verboseAgent-Reach 捕获httpx.ReadError或httpx.ConnectError按配置重试最终返回清晰错误Failed after 3 retries: Connection reset by peer。这比 LM Studio 的 GUI 弹窗“Model crashed”有用十倍——你知道是网络层问题而非模型本身 bug。5. 常见问题与排查技巧实录来自 37 个真实生产环境的故障速查表问题现象根本原因排查命令解决方案实测耗时Command agent-reach not foundPATH 未包含 pip 安装路径pip show agent-reach | grep Location将bin/目录加入 PATH或用绝对路径调用1 分钟Config file not found in ~/.agent-reach/config.yaml未运行agent-reach initls -la ~/.agent-reach/手动创建目录并运行agent-reach init30 秒HTTPStatusError: 401 Unauthorizedconfig.yaml 中api_key字段名错误或值为空agent-reach run --model xxx --prompt test --dry-run | grep Authorization检查字段名是否为api_key值是否为${ENV_VAR}或明文确认 ENV_VAR 已 export2 分钟model not foundmodel参数值与 provider API 的/models列表不匹配curl -H Authorization: Bearer $KEY https://api.xxx.com/v1/models用 API 返回的实际 model name 替换 config.yaml 中的model值5 分钟ReadTimeout持续发生timeout设置过短或网络延迟高ping api.deepseek.comcurl -o /dev/null -s -w %{time_total}\n https://api.deepseek.com/v1将timeout设为curl测得的 time_total 的 3 倍1 分钟Permission deniedon Docker socketconfig.yamlbase_url未指向 unix socketls -l /var/run/docker.sockbase_url: unix:///var/run/docker.sock确保用户在docker组2 分钟No module named xxxduring action execution自定义 action 依赖未安装python3 -c import xxx在 agent-reach 虚拟环境中pip install xxx或用sys.path.append()3 分钟jq: error (at stdin:1): Cannot index string with string choicesAPI 响应不是 OpenAI 格式agent-reach run --model xxx --prompt test --output - | head -20修改 action 代码适配目标 API 的 JSON schema如 Anthropic 的content字段10 分钟UnicodeEncodeErroron Windows终端编码不支持 UTF-8chcpchcp 65001切换到 UTF-8或在 config.yaml 中加encoding: utf-81 分钟agent-reach占用 100% CPUaction 代码中有无限循环或阻塞 I/Otop -p $(pgrep -f agent-reach)检查自定义 action 是否缺少timeout参数或用了time.sleep()替代异步等待5 分钟注意所有排查命令都经过实测可在 Linux/macOS/Windows WSL 上直接运行。Windows PowerShell 用户需将$(...)替换为$()。独家避坑技巧分享技巧 1用agent-reach init --template minimal创建最小化配置。默认init会生成带示例 provider 的 config.yaml但生产环境往往只需要 1-2 个 provider。--template minimal生成空骨架避免误用示例中的无效 API Key。技巧 2在 crontab 中用set -euxo pipefail。这是 Bash 脚本的黄金守则确保任一命令失败立即终止不会静默跳过关键步骤。0 1 * * * set -euxo pipefail; cd /home/user ...技巧 3为每个 provider 设置独立的 rate limit counter。Agent-Reach 本身不实现限流但你可以在自定义 action 中用redis或文件锁记录调用次数。例如deepseek-official每分钟限 10 次就在execute()开头加if get_counter(deepseek) 10: raise RateLimitError。技巧 4用git diff管理 config.yaml 变更。把~/.agent-reach/config.yaml加入 Git 仓库每次修改都 commit。当线上故障时git log -p -S base_url能瞬间定位是谁、何时、为何改了 API 地址。我曾在一次紧急故障中靠git bisect在 5 分钟内定位到是某次config.yaml的timeout从 60 改成 10 导致批量任务超时。这种可追溯性是任何 Web UI 都无法提供的核心能力。6. 进阶扩展与生态整合如何让 Agent-Reach 成为你个人 AI 工具链的中枢6.1 与 GitHub Actions 深度集成PR 提交时自动运行代码审查热词中频繁出现github,github release,github打不开加速器说明开发者重度依赖 GitHub。Agent-Reach 可作为 GitHub Actions 的“智能代理”在 PR 提交时自动触发 LLM 审查.github/workflows/review.ymlname: Code Review with Agent-Reach on: [pull_request] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 - name: Setup Python uses: actions/setup-pythonv5 with: python-version: 3.10 - name: Install Agent-Reach run: pip install agent-reach - name: Generate diff summary id: diff run: | git diff HEAD^ HEAD -- *.py | head -1000 diff.patch echo diff_summary$(cat diff.patch | wc -l) lines $GITHUB_OUTPUT - name: