1. 项目缘起与核心定位Agent-Reach 这个名字第一次出现在我视野里的时候我正被一堆零散的 AI Agent 工具链折腾得够呛。那段时间我在同时维护三套不同架构的 Agent 项目一套基于 Python 的轻量编排一套跑在 CLI 环境下的任务代理还有一套是帮朋友做的自动化消息处理流程。每套系统都有自己的工具调用规范、上下文管理方式和执行入口切换成本高得离谱。Agent-Reach 吸引我的点很直接它试图用一套统一的 CLI 接口把 AI Agent 的能力触达范围从单一的对话窗口扩展到文件系统、命令行工具、外部 API 以及本地脚本生态。说白了Agent-Reach 是一个面向 AI Agent 的命令行交互层与能力扩展框架。它的核心价值在于让 Agent 不再局限于“你问我答”的聊天模式而是能够像一位坐在终端前的工程师一样主动调用工具、读取文件、执行命令、处理数据并根据执行结果决定下一步动作。这个定位解决了一个非常实际的问题大多数 AI Agent 框架在演示阶段看起来很美好一旦进入真实工作场景就会因为工具调用链路断裂、上下文丢失、执行权限模糊而变得不可用。适合关注这个项目的人大致分三类。第一类是正在搭建 AI Agent 的开发者尤其是那些用 Python 做原型验证、但苦于没有统一 CLI 入口来管理工具调用的朋友。第二类是对 CLI 工具有执念的效率型用户他们希望把 Agent 能力嵌入到现有的终端工作流里而不是额外打开一个网页或客户端。第三类是想学习 AI Agent 主流架构的学生或转行者Agent-Reach 的代码结构和设计思路可以作为很好的参考样本因为它没有过度封装核心逻辑相对透明。我之所以花时间深入研究这个项目是因为它在 GitHub 上的组织方式很务实。没有花哨的官网没有冗长的白皮书README 直接告诉你它能做什么、怎么装、怎么跑。这种风格在当下的 AI Agent 项目里反而少见很多项目一上来就讲愿景结果代码跑不起来。Agent-Reach 给我的第一印象是这是一个真正被用过、被踩过坑、然后被打磨过的工具。2. 架构拆解与设计思路2.1 为什么选择 CLI 作为核心交互层Agent-Reach 把 CLI 作为主要入口这个选择背后有很实际的考量。GUI 和 Web 界面在演示时更直观但一旦涉及到批量任务、远程执行、脚本集成CLI 的优势就碾压式地体现出来了。你可以把 Agent-Reach 的命令写进 shell 脚本可以配合 cron 做定时任务可以通过 SSH 在远程机器上触发 Agent 执行这些都是 Web 界面很难优雅做到的。从技术实现角度看CLI 层负责解析用户输入、管理会话状态、调度工具调用、格式化输出结果。Agent-Reach 在这一层做了几件关键的事第一它定义了统一的命令语法让用户可以用自然语言或结构化参数两种方式触发 Agent第二它维护了一个会话上下文确保多轮交互时 Agent 不会“失忆”第三它提供了工具注册机制开发者可以把自定义的 Python 函数或外部命令注册为 Agent 可调用的工具。注意CLI 交互层的一个常见坑是参数解析歧义。比如用户输入agent-reach run --file data.txt --action summarize如果--action的值恰好和某个文件名冲突解析器可能会出错。Agent-Reach 通过强制参数命名空间和类型校验来规避这个问题但在自定义工具时仍然需要留意参数命名的唯一性。2.2 Python 生态的深度绑定与取舍Agent-Reach 选择 Python 作为主要开发语言这个决策在 AI Agent 领域几乎是默认选项。Python 有最丰富的 LLM 调用库、最成熟的数据处理工具链、最活跃的社区支持。但 Python 也有它的代价启动速度慢、并发模型复杂、打包分发麻烦。Agent-Reach 在处理这些取舍时采取了一种务实的策略。对于启动速度它没有试图用 Rust 重写核心而是通过懒加载和模块拆分来减少冷启动时间。只有真正被调用的工具模块才会被导入基础 CLI 框架保持轻量。对于并发它没有自己造轮子而是直接利用 Python 的asyncio和concurrent.futures把并发控制的复杂性交给标准库。对于分发它优先支持pip install和源码运行两种方式没有强推 Docker 或二进制打包降低了上手门槛。这种取舍带来的好处是开发效率高、社区贡献门槛低。代价是在极端高并发场景下Python 的 GIL 会成为瓶颈。但说实话大多数个人开发者和小团队的使用场景根本碰不到这个瓶颈。如果你真的需要扛住成千上万的并发 Agent 调用那可能需要考虑基于 Rust 或 Go 的 Agent 框架或者用 Python 做编排层、用其他语言做执行层。2.3 工具调用机制的设计哲学Agent-Reach 的工具调用机制是我最欣赏的部分。它没有采用那种“把所有工具都塞进一个巨大 prompt 里让模型自己选”的粗暴做法而是设计了一个分层的工具注册与发现系统。第一层是内置工具比如文件读写、目录遍历、HTTP 请求、Shell 命令执行。这些工具开箱即用覆盖了最常见的操作需求。第二层是扩展工具开发者可以通过装饰器或配置文件注册自定义工具指定工具名称、描述、参数 schema 和调用入口。第三层是动态工具Agent 在执行过程中可以根据上下文临时生成并调用工具比如根据用户需求动态生成一段 Python 代码并执行。这种分层设计的好处是内置工具保证基础能力扩展工具满足个性化需求动态工具提供灵活性。同时每一层都有明确的权限控制和审计日志避免 Agent 在执行过程中做出意料之外的操作。实操心得在注册自定义工具时工具描述的质量直接决定了 Agent 能否正确调用。我试过把一个工具描述写成“处理数据”结果 Agent 完全不知道什么时候该用它。后来改成“读取 CSV 文件并返回前 N 行参数为文件路径和行数”调用准确率立刻上来了。工具描述要像写给新同事看的操作手册而不是写给自己的备忘录。3. 环境搭建与快速上手3.1 Python 环境准备与依赖安装Agent-Reach 对 Python 版本的要求是 3.9 及以上推荐 3.11 或 3.12。我实测下来3.11 在异步性能和类型提示支持上比较均衡3.12 也没问题但某些第三方库的兼容性可能还在追赶。如果你还在用 3.8建议先升级因为很多现代 AI Agent 相关的库已经不再支持 3.8 了。安装 Python 本身不是难事但有几个细节值得注意。Windows 用户建议从 Python 官网下载安装包安装时勾选“Add Python to PATH”否则后续在命令行里调用python会找不到。macOS 用户可以用 Homebrew 安装命令是brew install python3.11。Linux 用户大多数发行版自带 Python但版本可能偏旧建议用 pyenv 或 conda 管理多版本。依赖安装方面Agent-Reach 的核心依赖包括click或typer用于 CLI 解析、pydantic用于数据校验、httpx或requests用于网络请求、rich用于终端输出美化。如果你要用到 LLM 调用还需要安装对应的 SDK比如openai、anthropic或dashscope。这些依赖在项目的requirements.txt或pyproject.toml里都有声明直接pip install -e .即可。# 克隆项目 git clone https://github.com/your-org/agent-reach.git cd agent-reach # 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装依赖 pip install -e . # 验证安装 agent-reach --version如果 GitHub 克隆速度慢可以尝试用镜像站或者直接下载 release 包。国内用户访问 GitHub 偶尔会遇到连接问题这时候可以配置 git 的代理或者使用一些公开的镜像服务。但要注意镜像站的内容同步可能有延迟如果发现版本不对还是建议想办法从源站获取。3.2 配置文件与 API 密钥管理Agent-Reach 的配置文件默认放在~/.agent-reach/config.yaml也可以通过环境变量AGENT_REACH_CONFIG指定其他路径。配置文件的结构很清晰主要分为三块LLM 提供商配置、工具配置、会话配置。LLM 提供商配置需要填写 API 密钥、基础 URL、模型名称等信息。这里有个安全建议不要把 API 密钥直接写在配置文件里然后提交到 Git。正确的做法是用环境变量存储密钥配置文件里只写环境变量的名称。Agent-Reach 支持这种引用方式比如api_key: ${OPENAI_API_KEY}。# config.yaml 示例 llm: provider: openai api_key: ${OPENAI_API_KEY} base_url: https://api.openai.com/v1 model: gpt-4o-mini temperature: 0.7 max_tokens: 4096 tools: enabled: - file_read - file_write - shell_exec - http_request shell_exec: allowed_commands: - ls - cat - grep - python timeout: 30 session: max_history: 50 auto_save: true save_path: ~/.agent-reach/sessions/工具配置里的allowed_commands是一个重要的安全边界。默认情况下Agent-Reach 不会允许 Agent 执行任意 Shell 命令而是通过白名单机制限制可执行的命令范围。这个设计非常必要否则 Agent 可能会在你不注意的时候执行rm -rf之类的危险操作。我建议在生产环境里把白名单收得更紧一些只开放真正需要的命令。3.3 第一次运行与基础交互安装配置完成后直接运行agent-reach会进入交互模式。你可以像跟聊天机器人对话一样输入指令Agent 会根据你的输入决定是直接回答还是调用工具。比如你输入“帮我看看当前目录下有哪些 Python 文件”Agent 会调用文件遍历工具然后返回结果。$ agent-reach Agent-Reach v0.3.1 已启动输入 exit 退出。 帮我看看当前目录下有哪些 Python 文件 [调用工具: file_list, 参数: {pattern: *.py, path: .}] 找到 3 个 Python 文件 - main.py - utils.py - test_agent.py 读取 main.py 的前 20 行 [调用工具: file_read, 参数: {path: main.py, lines: 20}] ...这种交互方式的好处是直观坏处是每次都要手动输入。如果你要做批量任务可以用agent-reach run命令配合参数直接执行单次任务或者用agent-reach script执行预定义的脚本文件。脚本文件支持 YAML 或 JSON 格式可以定义一系列步骤和条件分支。常见问题第一次运行时如果报错“No module named agent_reach”通常是因为没有正确安装或者虚拟环境没激活。检查一下pip list | grep agent是否有输出如果没有重新执行pip install -e .。如果报错“API key not found”检查环境变量是否设置正确可以用echo $OPENAI_API_KEY验证。4. 核心功能深度解析4.1 工具注册与自定义扩展Agent-Reach 的工具注册机制是我认为最有价值的部分之一。它让开发者可以用很小的成本把现有代码接入 Agent 生态。注册一个自定义工具只需要三步定义函数、添加装饰器、指定参数 schema。from agent_reach.tools import tool tool( namequery_database, description查询本地 SQLite 数据库并返回结果, parameters{ sql: {type: string, description: SQL 查询语句}, limit: {type: integer, description: 返回行数限制, default: 10} } ) def query_database(sql: str, limit: int 10): import sqlite3 conn sqlite3.connect(data.db) cursor conn.cursor() cursor.execute(sql) rows cursor.fetchmany(limit) conn.close() return {columns: [d[0] for d in cursor.description], rows: rows}这个工具注册后Agent 就能在需要的时候调用它。关键在于description和parameters的写法。描述要清晰说明工具的功能和适用场景参数要指定类型、描述和默认值。Agent 会根据这些信息判断何时调用以及如何传参。我踩过的一个坑是参数类型不匹配。有一次我定义了一个参数类型为string但实际传入的是数字结果 Agent 调用时一直报错。后来改成integer就正常了。所以参数 schema 一定要和实际函数签名保持一致不要偷懒。另一个经验是工具粒度要适中。太细的工具会导致 Agent 频繁调用增加延迟和 token 消耗太粗的工具则灵活性不足。比如“读取文件”和“写入文件”应该分开但“读取 CSV 并解析”可以合并成一个工具。判断标准是如果两个操作总是成对出现就合并如果可能独立使用就分开。4.2 上下文管理与多轮对话Agent-Reach 的上下文管理采用了一种滑动窗口加摘要的混合策略。默认情况下它保留最近 N 轮对话的完整内容超出部分会被压缩成摘要。这个 N 可以在配置文件里调整默认是 50 轮。摘要由 LLM 生成保留关键信息和决策依据丢弃冗余的寒暄和重复内容。这种策略的好处是平衡了上下文完整性和 token 消耗。但实际使用中我发现摘要的质量很不稳定。有时候 LLM 会把重要的工具调用结果摘要掉导致后续对话中 Agent 忘记了之前查到的数据。解决办法是在配置文件里把max_history调大或者对关键信息手动打标记让摘要器优先保留。session: max_history: 100 summary_threshold: 80 preserve_patterns: - 工具调用结果 - 错误信息 - 用户明确要求记住preserve_patterns是一个正则列表匹配到的内容在摘要时会被优先保留。这个功能很实用但需要根据你的使用场景定制。比如你做数据分析时可以把“查询结果”“统计值”加进去做代码生成时可以把“函数签名”“依赖版本”加进去。实操心得多轮对话中最容易出问题的是工具调用结果的传递。Agent 调用工具拿到结果后如果结果太长可能会被截断或摘要掉。我的做法是在工具函数里做预处理只返回关键字段而不是把原始数据全部丢回去。比如查询数据库时只返回前 10 行和总行数而不是全部数据。这样既节省 token又避免信息丢失。4.3 执行安全与权限控制Agent 能执行 Shell 命令和读写文件这既是它的能力也是它的风险。Agent-Reach 在安全方面做了几层防护。第一层是命令白名单只有配置里允许的命令才能执行。第二层是路径限制文件读写默认只能在工作目录及其子目录内进行不能访问系统敏感路径。第三层是操作审计所有工具调用都会记录到日志文件方便事后追溯。这些防护措施在默认配置下已经能挡住大部分误操作但如果你要开放更多权限就需要格外小心。比如你要让 Agent 执行pip install安装依赖就需要把pip加入白名单。但这样一来Agent 理论上可以安装任意包包括恶意包。所以更好的做法是预先安装好依赖而不是让 Agent 动态安装。tools: shell_exec: allowed_commands: - ls - cat - grep - python - pip denied_patterns: - rm -rf - sudo - chmod 777 working_dir: /home/user/project timeout: 60denied_patterns是黑名单优先级高于白名单。即使某个命令在白名单里如果匹配到黑名单模式也会被拒绝。这个双重保险机制很有必要因为白名单可能配置得太宽泛黑名单可以兜底。5. 实战场景与案例拆解5.1 自动化代码审查与重构建议我用 Agent-Reach 做过一个代码审查的自动化流程。思路很简单让 Agent 遍历项目目录读取所有 Python 文件分析代码质量生成审查报告。这个流程如果手动做一个中型项目至少要花半天时间用 Agent-Reach 跑一遍只要几分钟。具体实现上我注册了一个analyze_code工具内部调用pylint或ruff做静态分析然后把结果返回给 Agent。Agent 根据分析结果生成人类可读的审查意见包括潜在 bug、代码风格问题、性能优化建议等。最后把报告写入 Markdown 文件。tool( nameanalyze_code, description对指定 Python 文件进行静态分析返回问题列表, parameters{ file_path: {type: string, description: Python 文件路径} } ) def analyze_code(file_path: str): import subprocess result subprocess.run( [ruff, check, file_path, --output-format, json], capture_outputTrue, textTrue ) return {file: file_path, issues: result.stdout}这个案例的关键在于工具的输出格式。我选择 JSON 而不是纯文本因为 JSON 结构化程度高Agent 解析起来更准确。如果返回的是ruff的默认文本输出Agent 有时候会误读行号和错误类型。改成 JSON 后准确率明显提升。另一个经验是分批处理。如果项目文件很多一次性让 Agent 处理所有文件会导致上下文爆炸。我的做法是每次处理 5 到 10 个文件生成阶段性报告最后再汇总。这样既控制了单次调用的复杂度又保证了整体流程的完整性。5.2 数据清洗与报表生成流水线第二个案例是数据清洗。我有一批 CSV 文件格式不统一有的用逗号分隔有的用分号有的有表头有的没有。手动清洗费时费力用 Agent-Reach 可以做成自动化流水线。流程是这样的Agent 先遍历目录找到所有 CSV 文件然后逐个读取前几行判断格式根据判断结果调用相应的清洗工具最后合并成一个标准化的数据集并生成统计报表。整个过程 Agent 会根据每一步的结果动态调整下一步动作而不是死板地执行预设脚本。# pipeline.yaml steps: - name: discover_files tool: file_list params: pattern: *.csv path: ./data - name: detect_format tool: csv_detect params: file: ${discover_files.result} - name: clean_data tool: csv_clean params: file: ${discover_files.result} delimiter: ${detect_format.delimiter} has_header: ${detect_format.has_header} - name: generate_report tool: report_gen params: data: ${clean_data.result} output: ./report.md这个 YAML 流水线展示了 Agent-Reach 的脚本能力。${}语法引用前一步的输出Agent 会自动解析依赖关系并按顺序执行。如果某一步失败整个流水线会暂停并报告错误位置方便排查。注意事项数据清洗场景下Agent 的判断可能出错。比如它可能把有表头的文件误判为无表头导致第一行数据被当成列名。我的做法是在关键步骤加人工确认或者让 Agent 输出判断依据人工抽查几个文件验证准确性。完全无人值守的流水线适合格式高度一致的场景格式混乱时还是需要人工介入。5.3 本地知识库问答系统搭建第三个案例是用 Agent-Reach 搭建本地知识库问答。我把项目文档、会议记录、技术笔记放在一个目录里让 Agent 建立索引然后通过 CLI 提问Agent 检索相关文档并生成回答。这个场景的核心是检索工具的实现。我用sentence-transformers做文本向量化用faiss做相似度检索。Agent 收到问题后先调用检索工具找到最相关的文档片段然后基于这些片段生成回答。这样既保证了回答有据可依又避免了把整个知识库塞进 prompt 导致的 token 浪费。tool( namesearch_knowledge, description在本地知识库中检索相关文档片段, parameters{ query: {type: string, description: 检索问题}, top_k: {type: integer, description: 返回片段数量, default: 5} } ) def search_knowledge(query: str, top_k: int 5): from sentence_transformers import SentenceTransformer import faiss import numpy as np model SentenceTransformer(all-MiniLM-L6-v2) query_vec model.encode([query]) index faiss.read_index(knowledge.index) distances, indices index.search(query_vec, top_k) results [] for idx in indices[0]: results.append(load_document_chunk(idx)) return {query: query, results: results}这个案例的难点在于文档切分策略。切得太碎检索到的片段缺乏上下文切得太粗检索精度下降。我试过按固定字数切分、按段落切分、按语义切分最后发现按段落切分加滑动窗口效果最好。每个片段保留前后各一段作为上下文检索时用片段本身做匹配返回时带上上下文。6. 性能调优与并发处理6.1 响应延迟的优化手段Agent-Reach 的响应延迟主要来自三个环节LLM 调用、工具执行、上下文处理。LLM 调用通常是最慢的尤其是用大模型的时候。优化手段有几个一是用更小的模型做意图识别和工具选择只在生成最终回答时用大模型二是开启流式输出让用户先看到部分结果三是缓存常见问题的回答避免重复调用。工具执行的延迟取决于工具本身。文件读写很快网络请求和数据库查询可能很慢。对于慢工具可以设置超时和重试机制避免 Agent 卡死。Agent-Reach 支持在工具注册时指定超时时间超时后会返回错误信息Agent 可以选择重试或换一种方式。上下文处理的延迟主要来自摘要生成。如果对话历史很长每次都要重新生成摘要开销不小。优化方法是增量摘要只对新增的对话做摘要然后和之前的摘要合并。Agent-Reach 在较新版本里支持这个特性需要在配置里开启。performance: streaming: true cache: enabled: true max_size: 1000 ttl: 3600 summary: incremental: true batch_size: 106.2 并发场景下的稳定性保障Agent-Reach 本身是单进程 CLI 工具但你可以通过多种方式实现并发。最简单的是启动多个进程每个进程处理一个任务。这种方式隔离性好但资源消耗大。另一种方式是用asyncio在单进程内并发执行多个 Agent 会话适合 I/O 密集型任务。我实测下来单进程内并发 10 到 20 个 Agent 会话是比较稳定的。再往上就会遇到 Python GIL 的限制性能提升不明显。如果你需要更高的并发建议用多进程加负载均衡或者把 Agent 执行层用其他语言重写。常见问题并发场景下最容易出现的是 API 速率限制。LLM 提供商通常有每分钟请求数限制并发太高会被限流。解决办法是加一个令牌桶或漏桶限流器控制请求速率。Agent-Reach 没有内置限流器但可以在工具层面实现或者用外部代理做限流。6.3 资源占用与成本控制Agent-Reach 本身的资源占用很低主要开销在 LLM 调用和工具执行上。成本控制的关键是减少不必要的 LLM 调用。比如工具选择可以用规则引擎做初筛只在规则无法判断时才调用 LLM。上下文摘要可以用更便宜的模型只在生成最终回答时用贵模型。另一个成本控制手段是缓存。相同的查询和工具调用结果可以缓存起来下次直接返回。Agent-Reach 支持工具级别的缓存配置可以在工具注册时指定缓存策略。对于查询类工具缓存命中率通常很高能显著降低成本。tool( namequery_weather, description查询指定城市的天气, parameters{city: {type: string}}, cache_ttl1800 # 缓存 30 分钟 ) def query_weather(city: str): # 实际查询逻辑 ...7. 常见故障排查与避坑指南7.1 安装与依赖问题速查问题现象可能原因解决方法command not found: agent-reach未安装或未加入 PATH重新执行pip install -e .检查虚拟环境是否激活ModuleNotFoundError: No module named xxx依赖缺失执行pip install -r requirements.txtImportError: cannot import name tool版本不匹配确认安装的是最新版本检查 Python 版本是否满足要求Permission denied文件权限不足检查工作目录权限避免使用系统目录SSL certificate verify failed证书问题更新 certifi 包或检查网络环境7.2 运行时错误与异常处理Agent 执行过程中最常见的错误是工具调用失败。失败原因可能是参数错误、网络超时、权限不足等。Agent-Reach 会把错误信息返回给 AgentAgent 可以选择重试、换工具或向用户报告。但有时候 Agent 会陷入重试循环反复调用同一个失败的工具。为了避免这种情况我在工具实现里加了重试次数限制和退避策略。第一次失败后等待 1 秒重试第二次等待 2 秒第三次直接返回错误。这样既给了临时故障恢复的机会又避免了无限循环。import time from functools import wraps def retry(max_attempts3, backoff1.0): def decorator(func): wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_attempts): try: return func(*args, **kwargs) except Exception as e: if attempt max_attempts - 1: raise time.sleep(backoff * (2 ** attempt)) return wrapper return decorator实操心得Agent 的“幻觉”在工具调用场景下表现为调用不存在的工具或传错误的参数。解决办法是在工具注册时做严格校验参数类型不对直接拒绝工具名不存在返回明确错误。同时在系统提示里明确列出可用工具及其用途减少 Agent 的猜测空间。7.3 上下文丢失与状态管理多轮对话中最让人头疼的是上下文丢失。Agent 突然忘记了之前确认过的信息或者把不同会话的内容混淆。这通常是因为会话隔离没做好或者上下文窗口溢出后摘要质量差。我的做法是给每个会话分配唯一 ID会话数据独立存储。Agent-Reach 默认支持这个机制但需要确保session.auto_save开启并且save_path有写入权限。如果发现上下文丢失先检查会话文件是否正常写入再检查摘要配置是否过于激进。另一个技巧是在关键信息上打标签。比如用户说“记住这个 API 密钥是 xxx”Agent 会把这条信息标记为重要摘要时优先保留。这个功能需要自定义提示词或在工具层面实现Agent-Reach 没有开箱即用的方案但扩展起来不难。8. 扩展方向与个人实践体会Agent-Reach 的扩展性是我持续使用它的主要原因。它的插件机制允许我把各种零散的工具串联起来形成一个完整的自动化工作流。我最近在尝试把它和定时任务结合每天早上自动拉取数据、生成报表、发送通知整个过程不需要人工干预。另一个扩展方向是把它嵌入到现有的开发工具链里。比如在 Git hook 里调用 Agent-Reach 做提交前的代码检查或者在 CI 流程里用它生成变更日志。这些场景下 Agent-Reach 扮演的是“智能胶水”的角色把各个工具粘合在一起让它们协同工作。我在实际使用中最大的体会是Agent 的能力边界取决于你给它注册的工具。工具越丰富、描述越清晰Agent 能做的事情就越多。但工具也不是越多越好太多工具会让 Agent 的选择困难反而降低准确率。我的经验是保持核心工具在 10 到 15 个左右按需动态加载扩展工具。最后分享一个小技巧在调试 Agent 行为时开启详细日志模式把每次 LLM 调用的 prompt 和响应都打印出来。这样能清楚看到 Agent 是怎么思考的、为什么选择某个工具、参数是怎么填的。虽然日志量大但对排查问题非常有用。Agent-Reach 支持通过--verbose参数开启详细日志或者用--log-level debug指定日志级别。
