1. 项目概述Agent-Reach 是什么为什么值得花时间搞懂它Agent-Reach 不是一个抽象概念也不是某个大厂刚发布的闭源黑盒产品——它是一个真实存在于 GitHub 上、采用 MIT License 开源、用 Python 编写的命令行工具CLI核心定位是让开发者能以极简方式调用和编排本地或远程智能体Agent的执行链路。我第一次在 GitHub 搜索 “agent cli” 时偶然点开 shihabal3amri/diplay 仓库注意diplay 是其早期代号现主分支已统一为 Agent-Reach看到 README 里第一行写着pip install agent-reach agent-reach --help当场就试了——三秒装完五秒跑通一个本地 LLM 调用 demo。这种“零配置即用”的体验在当前大量 CLI 工具还在卡在 Python 环境兼容、模型路径硬编码、依赖冲突的阶段显得格外扎实。它的本质是把“智能体调度”这件事从 Jupyter Notebook 或 Flask Web 服务里解放出来回归到 Unix 哲学最擅长的领域组合小工具、管道化输入输出、可脚本化复用。比如你写好一个用 LangChain 封装的客服问答 Agent以前要启动服务、curl 测试、写 shell 脚本调用 API现在只需agent-reach run --agent customer-support --input 订单号12345怎么查物流结果直接打印在终端还能用| jq .response或 output.txt接续处理。这不是炫技而是把 Agent 从“演示玩具”推向“生产级基础设施组件”的关键一步。适合谁看如果你是 Python 开发者日常需要快速验证 Agent 行为、做 A/B 测试不同提示词、批量处理结构化输入比如 CSV 里的 1000 条用户问题、或者想把 Agent 集成进 CI/CD 流水线做自动化测试——Agent-Reach 就是你缺的那块拼图。它不替代 LangChain 或 LlamaIndex而是站在它们之上提供一层干净、稳定、无状态的 CLI 接口层。我团队上个月用它把内部知识库 Agent 的回归测试时间从 47 分钟压缩到 6 分钟靠的就是cat test_cases.jsonl | xargs -n1 -P4 agent-reach run --agent kb-agent这一行并行命令。没有服务器、不占内存、结果可审计——这才是 CLI 工具该有的样子。2. 整体设计思路与架构选型为什么是 CLI而不是 Web 或 SDK2.1 核心设计哲学拒绝“重封装”专注“轻调度”Agent-Reach 的代码仓库结构非常克制src/agent_reach/下只有 4 个核心模块——cli.py命令行入口、runner.py执行引擎、config.py配置加载、agent.pyAgent 抽象基类。没有 Web 框架依赖没有数据库连接甚至没有日志系统只用 Python 内置logging输出到 stderr。这种极简不是偷懒而是刻意为之的设计选择。我拆过它的setup.py依赖列表只有pydantic2.0,3.0、click8.0和rich13.0三个包——click处理命令解析rich渲染带颜色的输出pydantic验证配置。连requests都没引入因为所有网络调用都交给用户自己的 Agent 实现去处理。为什么放弃 Web UI因为 Web 界面天然带来状态管理复杂度会话保持、并发控制、前端构建、跨域调试……而 CLI 的优势在于“无状态”每次agent-reach run都是全新进程参数全靠命令行传入输出全靠 stdout/stderr 流出。这使得它能无缝集成进任何已有工具链——你可以用cron定时触发用make管理任务用git bisect定位 Agent 行为退化甚至用tmux分屏同时监控多个 Agent 的实时输出。我在做多模型对比测试时就开了 3 个 tmux pane分别运行agent-reach run --model gpt-3.5-turbo、--model claude-3-haiku、--model qwen2-7b结果实时滚动对比比打开三个浏览器标签页高效得多。2.2 Agent 抽象层设计不绑定框架但兼容主流Agent-Reach 的agent.py里定义了一个极简接口class BaseAgent(ABC): abstractmethod def invoke(self, input: dict) - dict: pass注意input和output都是dict不是字符串也不是Message对象。这意味着你写一个 LangChain Agent只需包装一层from langchain.agents import AgentExecutor from agent_reach.agent import BaseAgent class LangChainAgent(BaseAgent): def __init__(self, agent_executor: AgentExecutor): self.executor agent_executor def invoke(self, input: dict) - dict: result self.executor.invoke({input: input.get(query, )}) return {response: result[output], metadata: result.get(intermediate_steps, [])}同样LlamaIndex 的QueryEngine、Ollama 的本地模型调用、甚至纯subprocess.run()调用外部二进制程序都能套进这个invoke接口。这种设计避免了“框架绑架”——你不用为了用 Agent-Reach 就重写整个 Agent 逻辑。我实测过一个用llama-cpp-python加载 GGUF 模型的本地推理 Agent只需 12 行代码就能接入agent-reach run --agent local-llama --input {query:解释量子纠缠}就能跑通。相比之下很多所谓“Agent 平台”要求你必须用它的 DSL 写提示词、必须注册到它的控制台、必须走它的 API 网关——反而把简单问题复杂化了。2.3 配置驱动 vs 硬编码为什么 config.yaml 比 --model 参数更可靠Agent-Reach 支持两种参数传递方式命令行短参数如--model qwen2-7b和配置文件驱动--config config.yaml。但我在实际项目中强烈推荐后者原因很实在可复现性。命令行参数容易被 shell 历史记录污染、被误复制粘贴、在 CI 中难以版本化而 YAML 配置文件可以 git commit、code review、diff 对比。一个典型的config.yaml长这样agent: type: langchain module: agents.customer_support class: CustomerSupportAgent init_args: llm_model: qwen2-7b knowledge_base_path: /data/kb/v2 timeout_seconds: 30 input: format: jsonl # 支持 json, jsonl, csv path: test_inputs.jsonl output: format: jsonl path: results.jsonl这里init_args会直接传给 Agent 类的__init__方法input.format决定如何解析输入文件——jsonl每行一个 JSON 对象csv则按列映射到input字典的 key。这种设计让一次命令能处理上千条测试用例而不用写循环脚本。我曾用它跑过 2300 条客服对话测试集命令就是agent-reach run --config prod-config.yaml全程无人值守结果自动存到 S3。如果用--model参数光是拼接 2300 次命令行就容易出错更别说参数转义问题了。3. 核心细节解析与实操要点从安装到定制 Agent 的完整链路3.1 安装与环境适配为什么 pip install 就够了却常踩 wheel 兼容坑Agent-Reach 的 PyPI 包名就是agent-reach安装命令pip install agent-reach看似简单但背后有几点必须注意的细节。首先它不提供 Windows 的预编译 wheel所以 Windows 用户pip install时会触发本地编译——这就要求你必须提前装好 Visual Studio Build Tools2019 版本即可否则会卡在pydantic编译环节报错MSB8065。Linux/macOS 用户则基本无感因为 PyPI 上提供了manylinux和macosx的 wheel。其次Python 版本兼容性有明确边界官方支持 3.8–3.11但我在 3.12 上测试失败原因是click8.x 系列尚未完全适配 3.12 的新语法typing.Literal的行为变更。解决方案不是降级 Python而是升级clickpip install click8.2.0即可。这个细节官网文档没写是我翻 issue 区发现的——第 47 号 issue 提到 “click 8.1.7 crashes on Python 3.12”作者回复说 “fixed in 8.2.0”。所以我的建议是装完agent-reach后立刻执行pip list | grep click确认版本低于 8.2.0 就手动升级。最后关于rich库的终端兼容性。rich默认启用真彩色24-bit color但在某些老旧 SSH 终端比如 CentOS 7 默认的 xterm里会显示乱码。这时加一个环境变量就能解决export RICH_COLOR_SYSTEMstandard。我把它写进了团队的.bashrc一劳永逸。这个技巧不是 Agent-Reach 特有但对 CLI 工具的可用性影响极大——毕竟没人想看到一堆[38;2;...的 ANSI 转义字符。3.2 CLI 命令详解那些藏在 --help 里的实用参数运行agent-reach --help会看到 5 个一级命令run、list、config、version、debug。其中run是主力但其他几个绝非摆设。agent-reach list会扫描AGENT_REACH_AGENTS_PATH环境变量指定目录下的所有 Python 模块列出已注册的 Agent 名称和描述。默认路径是~/.agent-reach/agents你可以用export AGENT_REACH_AGENTS_PATH/path/to/your/agents切换。这个机制让你能像插件一样管理 Agent——把不同业务线的 Agent 放在不同目录用list一眼看清可用能力。agent-reach config是配置管理神器。它支持init生成默认 config.yaml、validate校验 YAML 语法和 schema、show显示当前生效配置。最实用的是config validate --config my-test.yaml它会用pydantic的 BaseModel 验证配置字段类型和必填项比如timeout_seconds必须是 intknowledge_base_path必须存在且可读。我曾经因为knowledge_base_path写错路径导致 Agent 启动时报FileNotFoundError但错误堆栈很深定位困难后来改用config validate一行命令就提示 “Field required at knowledge_base_path”省了半小时 debug。debug命令则是诊断利器。agent-reach debug --agent my-agent --input {query:test}会启动一个交互式调试会话显示 Agent 初始化过程、invoke调用前后的完整input/output字典、以及每个中间步骤的耗时。它甚至会捕获未处理异常并格式化输出比直接python -m pdb方便太多。我在调试一个因llama-cpp-python内存泄漏导致的 segfault 时就是靠debug命令的--verbose模式看到最后一行是llama_cpp.llama_tokenize调用后进程退出从而锁定问题在 tokenization 步骤。3.3 自定义 Agent 开发三步写出可注册的 Agent 类写一个能被 Agent-Reach 识别的 Agent严格遵循三步法第一步创建 Python 模块在AGENT_REACH_AGENTS_PATH目录下新建文件my_agent.py内容如下# my_agent.py from agent_reach.agent import BaseAgent class MyAgent(BaseAgent): def __init__(self, greeting: str Hello): self.greeting greeting def invoke(self, input: dict) - dict: name input.get(name, World) return { response: f{self.greeting}, {name}!, timestamp: __import__(time).time() }第二步添加模块级元数据在my_agent.py文件顶部添加注释块必须紧贴文件开头# AGENT_REACH_METADATA # name: greeting-agent # description: A simple agent that greets users by name # version: 1.0.0 # author: your-name这个注释块是 Agent-Reach 扫描时提取 Agent 信息的唯一依据。name字段就是agent-reach list显示的名字description会出现在--help的说明里。注意注释必须是# AGENT_REACH_METADATA开头且必须是连续的#行不能有空行。第三步注册并测试确保AGENT_REACH_AGENTS_PATH指向包含my_agent.py的目录然后运行agent-reach list # 应看到 greeting-agent agent-reach run --agent greeting-agent --input {name:Alice} # 输出: {response: Hello, Alice!, timestamp: 171xxxxxx}这里有个易错点很多人把name写成MyAgent类名但 Agent-Reach 匹配的是元数据里的name字段不是类名。我第一次就栽在这儿list里看不到 Agent查了半天才发现注释里写的是# name: MyAgent但run时用了--agent my-agent大小写和连字符都不匹配。4. 实操过程与核心环节实现从零搭建一个电商客服 Agent4.1 场景定义与需求拆解我们要解决什么真实问题假设你是一家跨境电商公司的技术负责人客服团队每天收到 5000 条关于“订单延迟”、“退货流程”、“关税计算”的咨询。现有方案是人工回复FAQ 文档响应慢、口径不一致、无法处理长尾问题。我们决定用 Agent-Reach 快速上线一个最小可行 Agent能根据订单号查询物流状态并结合公司政策生成个性化回复。关键约束有三条1必须用公司内网可访问的物流 APIHTTP 接口2政策规则存在 Excel 表格里需动态加载3输出必须包含标准话术模板且能标记置信度。这个需求看似简单但暴露了 Agent 开发的典型陷阱外部依赖不可控、数据源格式混乱、业务规则频繁变更。如果用传统 Web 服务开发光是 API 认证、Excel 解析、缓存策略就要写几百行代码而用 Agent-Reach我们可以把每个痛点拆解成独立模块再用 CLI 组合。4.2 数据准备与依赖安装让 Agent “看得见”业务数据首先准备两个核心数据源物流 API 凭据公司内网 API 的base_url、api_key、timeout存为secrets.yaml不提交 gitlogistics: base_url: https://internal-api.company.com/logistics api_key: sk-live-xxxxxx timeout: 15退货政策 Excelpolicies/return_policy.xlsx表头为country_code,order_age_days,max_refund_percent,required_docs。用pandas读取后转成字典缓存避免每次请求都 IO。依赖安装只需一条命令pip install pandas openpyxl requests pydantic. 注意openpyxl是读 Excel 的必需库requests用于调用物流 API——这些都不在 Agent-Reach 依赖里由 Agent 自己管理符合“职责分离”原则。我特意选了pandas而不是xlrd因为后者已停止维护且不支持 .xlsx 新格式。这个选择背后是经验去年我们一个老项目用xlrd读客户发来的 Excel结果对方用 WPS 新版保存文件打不开紧急升级openpyxl才救场。所以现在所有新项目Excel 处理一律openpyxlpandas组合。4.3 Agent 实现237 行代码搞定全链路以下是ecommerce_agent.py的核心实现已删减日志和异常处理保留主干# AGENT_REACH_METADATA # name: ecommerce-customer-support # description: Handles order status and return policy queries for e-commerce # version: 1.2.0 # author: ops-team import os import json import pandas as pd import requests from typing import Dict, Any from agent_reach.agent import BaseAgent class EcommerceCustomerSupportAgent(BaseAgent): def __init__( self, secrets_path: str ~/.agent-reach/secrets.yaml, policies_path: str ./policies/return_policy.xlsx ): # 加载敏感配置 self.secrets self._load_yaml(secrets_path) self.policies_df pd.read_excel(policies_path) # 预处理政策数据按 country_code 建索引提升查询速度 self.policies_by_country { row[country_code]: row.to_dict() for _, row in self.policies_df.iterrows() } def _load_yaml(self, path: str) - Dict[str, Any]: import yaml with open(os.path.expanduser(path)) as f: return yaml.safe_load(f) def invoke(self, input: dict) - dict: query_type input.get(type) # track_order or return_policy result {confidence: 0.0, response: , metadata: {}} if query_type track_order: result self._handle_track_order(input) elif query_type return_policy: result self._handle_return_policy(input) else: result[response] Unknown query type. Please specify track_order or return_policy. result[confidence] 0.1 return result def _handle_track_order(self, input: dict) - dict: order_id input.get(order_id) if not order_id: return {response: Missing order_id parameter., confidence: 0.2} # 调用物流 API url f{self.secrets[logistics][base_url]}/v1/tracking/{order_id} headers {Authorization: fBearer {self.secrets[logistics][api_key]}} try: resp requests.get( url, headersheaders, timeoutself.secrets[logistics][timeout] ) resp.raise_for_status() data resp.json() # 构建标准化响应 status data.get(status, unknown) eta data.get(estimated_delivery, N/A) carrier data.get(carrier, unknown) if status delivered: response f✅ 订单 {order_id} 已签收由 {carrier} 配送签收日期{data.get(delivered_at, N/A)}。 confidence 0.95 elif status in_transit: response f 订单 {order_id} 运输中预计 {eta} 送达承运商{carrier}。 confidence 0.85 else: response f 订单 {order_id} 状态{status}。详情请查看物流官网。 confidence 0.7 return { response: response, confidence: confidence, metadata: {raw_api_data: data} } except Exception as e: return { response: f物流查询失败{str(e)}。请稍后重试或联系客服。, confidence: 0.3, metadata: {error: str(e)} } def _handle_return_policy(self, input: dict) - dict: country input.get(country_code, US) order_age input.get(order_age_days, 0) policy self.policies_by_country.get(country) if not policy: return { response: f暂不支持 {country} 的退货政策请联系客服确认。, confidence: 0.4 } # 规则匹配按订单年龄判断可退比例 max_refund float(policy[max_refund_percent]) if order_age 30: refund_percent max_refund reason 订单未超30天 elif order_age 60: refund_percent max_refund * 0.7 reason 订单超30天但未超60天 else: refund_percent 0.0 reason 订单超60天不支持退款 docs policy[required_docs].split(;) if policy[required_docs] else [] response ( f {country} 退货政策\n f- {reason} → 可退 {refund_percent:.0f}%\n f- 需提供材料{, .join(docs) if docs else 无}\n f- 申请入口https://support.company.com/returns ) return { response: response, confidence: 0.9 if refund_percent 0 else 0.6, metadata: {matched_policy: policy} }这段代码的关键设计点在于所有外部依赖API、Excel都在__init__时加载并缓存invoke方法纯粹做逻辑编排。这样保证了每次 CLI 调用都是轻量级的不会重复 IO。_handle_track_order和_handle_return_policy两个私有方法职责单一便于单元测试——我用pytest写了 12 个测试用例覆盖各种 API 异常、Excel 缺失列、国家码不匹配等场景全部通过。4.4 配置与部署如何让 Agent 在生产环境稳定运行生产环境配置prod-config.yaml如下agent: type: module module: ecommerce_agent class: EcommerceCustomerSupportAgent init_args: secrets_path: /etc/agent-reach/secrets.yaml policies_path: /opt/agent-reach/policies/return_policy.xlsx input: format: json path: /tmp/queries.json output: format: json path: /tmp/responses.json logging: level: INFO file: /var/log/agent-reach/ecommerce.log部署时我做了三件事确保稳定性权限隔离/etc/agent-reach/secrets.yaml所有者设为agent-reach:agent-reach权限600避免其他用户读取 API Key资源限制用 systemd service 文件设置内存上限MemoryLimit512M防止 Excel 加载过大导致 OOM健康检查写了个简单的health-check.sh每分钟执行agent-reach run --agent ecommerce-customer-support --input {type:health}返回{response:OK}才认为服务正常。这个 Agent 上线后客服响应时间从平均 8 分钟降到 12 秒而且所有对话记录自动存入/tmp/responses.json供后续分析。最让我满意的是当物流 API 因维护不可用时Agent 自动降级为返回预设话术而不是崩溃——这得益于try/except里精心设计的 fallback 逻辑。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 “ModuleNotFoundError: No module named xxx” —— Agent 导入失败的 3 种根因这是新手遇到最多的错误表面是模块找不到实际原因分三层第一层PYTHONPATH 未包含 Agent 目录Agent-Reach 默认只扫描AGENT_REACH_AGENTS_PATH目录但如果你的 Agent 依赖其他包比如langchain而这些包没装在全局 site-packages就会报错。解决方案在AGENT_REACH_AGENTS_PATH目录下创建requirements.txt内容为langchain0.1.0然后运行pip install -r requirements.txt。注意不要用pip install -e .因为 Agent-Reach 不走 setuptools entry point。第二层Agent 模块名与文件名不一致比如文件叫my_agent.py但AGENT_REACH_METADATA里写# name: my-agent而你在 CLI 里用--agent my_agent下划线就会失败。Agent-Reach 匹配的是name字段且会自动把-转成_但不会把_转成-。所以name: my-agent对应--agent my_agentname: my_agent对应--agent my_agent——看起来一样但前者是规范写法。第三层循环导入陷阱我在写一个依赖transformers的 Agent 时发现from transformers import pipeline放在模块顶层会卡住因为transformers初始化时会尝试下载模型。解决方案把pipeline创建移到invoke方法里且加if not hasattr(self, _classifier):缓存检查。这样首次调用才加载后续复用实例。提示用agent-reach debug --agent your-agent --verbose可以看到完整的 import traceback比python -c import your_agent更精准定位问题模块。5.2 输入格式解析失败JSONL 文件里为什么总少一行当用input.format: jsonl处理文件时Agent-Reach 默认用fileinput.input()逐行读取但很多用户导出的 JSONL 文件末尾有多余空行或最后一行没换行符。fileinput会把空行当作有效输入导致json.loads()报错。我的解决办法是在预处理脚本里加一行sed -i /^$/d input.jsonl删除空行再用sed -i $a\ input.jsonl确保末尾有换行。这两行 shell 命令已集成进团队的 CI 流水线成为数据准备的标准步骤。另一个常见问题是中文字符乱码。Windows 生成的 CSV 文件常用 GBK 编码而 Agent-Reach 默认用 UTF-8 读取。解决方案不是改代码而是在config.yaml里加encoding: gbk字段v1.3.0 支持。这个参数会透传给open()函数一劳永逸。5.3 性能瓶颈定位为什么 Agent 运行越来越慢我遇到过一个案例Agent 初期 200ms 响应两周后涨到 3s。用cProfile分析发现90% 时间花在pandas.read_excel()上——因为每次invoke都重新读 Excel。修复方法就是把 Excel 加载提到__init__如前文所示。但还有更隐蔽的坑requests默认不启用连接池每次 HTTP 调用都新建 TCP 连接。解决方案是在 Agent 初始化时创建requests.Session()实例并复用def __init__(self, ...): self.session requests.Session() adapter requests.adapters.HTTPAdapter( pool_connections10, pool_maxsize10, max_retries3 ) self.session.mount(http://, adapter) self.session.mount(https://, adapter)这个Session对象会在invoke中复用把物流 API 调用的平均耗时从 800ms 降到 120ms。连接池参数pool_connections和pool_maxsize设为 10 是经验值对应 10 个并发请求——超过这个数会排队避免压垮后端。5.4 配置热更新失效为什么改了 config.yamlCLI 却不生效Agent-Reach 的配置加载是“一次性”的run命令启动时读取 config之后修改文件不影响当前进程。这本是合理设计但用户常误以为是 bug。正确做法是用--config参数显式指定路径或设置环境变量AGENT_REACH_CONFIG_PATH。更优雅的方式是用systemd的RestartSec10配合ExecReload/bin/kill -s HUP $MAINPID实现配置热重载——不过这需要 Agent 本身支持信号处理Agent-Reach 当前不内置需自行扩展。注意agent-reach config validate命令每次都会重新读取文件所以它是验证配置变更是否正确的最快方式。6. 进阶技巧与生态扩展让 Agent-Reach 成为你工作流的中枢6.1 与 Shell 脚本深度集成把 Agent 当作“智能命令”CLI 的最大价值在于可编程性。我写了一个ask-cs.sh脚本把 Agent-Reach 变成客服团队的日常工具#!/bin/bash # ask-cs.sh - 快速查询订单/退货政策 if [ $# -lt 2 ]; then echo Usage: $0 order_id|country_code track|return exit 1 fi case $2 in track) input{type:track_order,order_id:$1} ;; return) input{type:return_policy,country_code:$1,order_age_days:30} ;; *) echo Unknown action: $2 exit 1 ;; esac agent-reach run --agent ecommerce-customer-support --input $input | \ jq -r .response | \ sed s/\\n/\n/g # 处理 JSON 转义换行团队成员只需./ask-cs.sh US123456789 track就能得到格式化好的物流信息。jq和sed的组合把原始 JSON 输出变成可读文本这才是 CLI 工具该有的体验——不是展示数据结构而是交付信息价值。6.2 构建 Agent 测试流水线用 GitHub Actions 自动化回归我们在 GitHub 仓库里配置了.github/workflows/test-agent.ymlname: Test Ecommerce Agent on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Set up Python uses: actions/setup-pythonv4 with: python-version: 3.10 - name: Install dependencies run: | pip install agent-reach pandas openpyxl requests pydantic - name: Run Agent tests run: | # 测试基础功能 agent-reach run --agent ecommerce-customer-support \ --input {type:track_order,order_id:TEST123} \ --config test-config.yaml # 测试批量处理 head -n 5 test_inputs.jsonl | \ agent-reach run --agent ecommerce-customer-support \ --config test-config.yaml这个流水线每次 PR 都会验证 Agent 是否能正常初始化、能否处理单条/批量输入。test-config.yaml里用 mock API 和精简版 Excel确保测试不依赖外部服务。CI 通过才允许合并把质量问题挡在上线前。6.3 社区生态与未来方向MIT License 下的协作可能性Agent-Reach 的 MIT License 意味着你可以自由修改、分发、商用甚至改名后作为自己产品的组件。GitHub 上已有 17 个 fork其中比较活跃的是agent-reach-aws集成 AWS Bedrock、agent-reach-sql用自然语言生成 SQL 查询。这些衍生项目都没提交 PR 回主仓而是各自维护——这正是 MIT 的魅力不强求贡献但降低协作门槛。我个人最期待的方向是Agent-Reach WASM把 Python Agent 编译成 WebAssembly在浏览器里运行轻量级 Agent。虽然目前pyodide对pandas支持还不完善但已有团队用micropython实现了类似效果。一旦可行agent-reach run --browser就能直接在 Chrome 里调用本地 Agent彻底摆脱服务器依赖。最后分享一个小技巧Agent-Reach 的--help输出支持| less分页但很多人不知道less里按/键可以搜索关键词。比如agent-reach run --help | less后按/timeout就能快速定位超时相关参数。这个 Unix 传统技能在 CLI 工具时代依然闪耀着光芒。