1. 项目缘起与核心定位Agent-Reach 这个标题第一次出现在我视野里的时候我正陷在一堆 AI Agent 的 CLI 工具里做横向对比。那段时间我试过用各种命令行方式去驱动本地模型、去串联工具链、去把一个大模型变成能自己干活的“代理”结果发现一个很尴尬的现实大部分所谓 Agent 框架要么把简单的事情搞复杂要么把复杂的事情做得更复杂。Agent-Reach 这个名字本身就透露了它的野心——让 Agent 能够“触达”到它该触达的东西不管是本地文件、远程接口还是其他 Agent。从关键词来看Agent-Reach 被贴上了 CLI、AI Agent、Python、GitHub 这几个标签。这几个词放在一起基本就勾勒出了一个典型的技术画像这是一个用 Python 写的、通过命令行交互的、托管在 GitHub 上的 AI Agent 工具或框架。它要解决的问题大概率是让开发者能够用最轻量的方式把一个 AI Agent 跑起来并且让它能够“reach”到外部世界。我之所以对这个项目感兴趣是因为在当前的 AI Agent 生态里存在一个明显的断层。一头是像 LangChain、AutoGPT 这样功能齐全但学习曲线陡峭的重型框架另一头是各种零散的脚本和 demo能跑但不成体系。中间地带——也就是“我想快速搭一个能用的 Agent但不想被框架绑架”这个需求——其实一直没被很好地满足。Agent-Reach 如果定位准确它要吃的就是这块市场。这篇文章我会从实际使用的角度出发把 Agent-Reach 的核心设计思路、CLI 交互方式、Python 层面的实现要点、以及在实际部署中可能踩到的坑全部拆开来讲。不管你是刚接触 AI Agent 的新手还是已经用过几套框架想找个更轻量方案的老手应该都能从里面找到对自己有用的东西。我尽量不堆砌概念而是把每个设计选择背后的“为什么”讲清楚让你看完之后不仅能跑起来还能知道怎么改、怎么扩。2. 核心架构与设计思路拆解2.1 为什么是 CLI 而不是 Web UIAgent-Reach 选择 CLI 作为主要交互方式这个决策本身就值得聊一聊。现在很多 AI Agent 项目一上来就搞一个 Web 界面看起来花哨但实际上对于开发者来说Web UI 反而是一个负担。你得启动服务、打开浏览器、点来点去最后发现还不如直接在终端里敲一行命令来得快。CLI 的优势在于它天然适合自动化和脚本化。你可以把 Agent-Reach 的命令写进 shell 脚本里可以把它挂到 cron 任务上可以用管道把它的输出传给下一个工具。这种“可组合性”是 Web UI 很难做到的。而且 CLI 的调试体验更好——你能直接看到标准输出和标准错误能方便地加 verbose 参数看详细日志能用 exit code 来判断执行结果。从技术实现角度看Python 里做 CLI 有几个主流选择argparse、click、typer。argparse 是标准库不用额外装依赖但写起来比较啰嗦click 是 Flask 作者写的装饰器风格很优雅typer 是基于 click 的用类型注解来定义参数对现代 Python 开发者来说最友好。Agent-Reach 如果追求零依赖或者少依赖可能会选 argparse如果追求开发效率和可维护性typer 是更好的选择。我个人的经验是对于 Agent 这类需要频繁加参数、加子命令的项目typer 能省下大量样板代码。提示如果你打算基于 Agent-Reach 做二次开发先确认它用的是哪个 CLI 库。这决定了你加新命令的方式。typer 加一个子命令只需要写一个函数加一个装饰器argparse 则要手动创建 subparser差别很大。2.2 Agent 的“Reach”能力如何实现“Reach”这个词在 Agent-Reach 里应该是核心概念。一个 Agent 要能干活它必须能触达外部资源。这些资源大致可以分为几类本地文件系统、网络接口、其他 Agent 或服务、以及执行环境比如运行一段代码。本地文件系统的触达是最基础的。Agent 需要能读文件、写文件、列目录。在 Python 里这看起来简单但实际做的时候要考虑路径安全——不能让 Agent 随便读到系统敏感文件。常见的做法是设定一个工作目录workspaceAgent 的所有文件操作都被限制在这个目录及其子目录内。实现上可以用 pathlib 做路径解析然后检查解析后的绝对路径是否以 workspace 为前缀。网络接口的触达是另一个重点。Agent 可能需要调用外部 API 来获取信息或执行动作。这里的关键是抽象出一个统一的 HTTP 客户端层把认证、重试、超时、错误处理都封装好。Python 里 requests 是最常用的但如果你想要异步支持httpx 是更好的选择。Agent-Reach 如果定位是轻量级可能直接用 requests 就够了如果考虑到未来要并发调用多个接口httpx 的 async 能力会很有价值。其他 Agent 的触达这个就比较有意思了。在多 Agent 系统里Agent 之间需要通信。最简单的做法是通过共享文件系统或者消息队列。Agent-Reach 如果支持这个可能会定义一个简单的协议比如 Agent A 把任务写到某个目录下的 JSON 文件Agent B 轮询这个目录来获取任务。这种方式虽然原始但非常可靠而且不依赖任何外部服务。执行环境的触达说白了就是让 Agent 能跑代码。这在 Python 里可以用 subprocess 或者 exec。但这里的安全风险很高必须做沙箱隔离。一个常见的做法是限制可执行的命令白名单或者在一个容器里执行。Agent-Reach 如果包含这个能力文档里一定会强调安全注意事项。2.3 Python 技术栈的选型逻辑Agent-Reach 用 Python 写这个选择在 AI Agent 领域几乎是默认的。原因很简单AI 生态的主流库——无论是模型推理的 transformers、还是向量数据库的 chromadb、还是各种 API 的 SDK——都是 Python 优先。用 Python 意味着你能直接调用这些库不用自己造轮子。但 Python 也有它的短板性能。如果你的 Agent 需要处理大量并发请求Python 的 GIL 会成为瓶颈。这时候通常的解法是用 asyncio 做异步 IO把 IO 密集型的操作并发起来。Agent-Reach 如果设计得当应该在网络请求和文件 IO 这些地方用 async而在 CPU 密集型的操作比如文本处理上用多进程或者直接同步执行。依赖管理是另一个要考虑的点。Python 的依赖管理一直是个痛点pip、virtualenv、poetry、pipenv 各有优劣。对于一个要给别人用的工具依赖越少越好。理想情况下Agent-Reach 的核心依赖应该控制在个位数而且都是成熟稳定的库。如果你看到它的 requirements.txt 里列了三四十个包那就要小心了安装过程可能会很痛苦。注意在安装 Agent-Reach 之前强烈建议先创建一个独立的虚拟环境。Python 的全局环境很容易被各种项目的依赖搞乱到时候排查问题会非常头疼。用python -m venv agent-reach-env创建一个干净的环境激活后再安装能避免百分之九十的依赖冲突问题。3. 环境搭建与快速上手实操3.1 Python 环境准备与版本选择Agent-Reach 作为 Python 项目第一步肯定是把 Python 环境准备好。这里有一个很实际的问题用哪个版本Python 3.8 是很多老项目的底线但 3.10 及以上才支持 match-case 语法和更完善的类型注解。如果 Agent-Reach 用到了这些新特性你就必须用较新的版本。我个人的建议是直接用 Python 3.11 或 3.12。这两个版本在性能上有明显提升3.11 比 3.10 快了 10% 到 60%而且对异步的支持更成熟。安装方式上Windows 用户去 python.org 下载安装包记得勾选“Add Python to PATH”macOS 用户可以用 Homebrew 装命令是brew install python3.12Linux 用户看发行版Ubuntu 22.04 自带的是 3.10想要更新的版本可以加 deadsnakes PPA。装完之后验证一下python --version pip --version如果python命令不识别可能是系统里只有python3那就用python3和pip3。这个问题在 Linux 和 macOS 上很常见不是 bug是系统设计如此。虚拟环境创建python -m venv agent-reach-env source agent-reach-env/bin/activate # Linux/macOS agent-reach-env\Scripts\activate # Windows激活之后你的终端提示符前面会出现(agent-reach-env)表示当前在这个环境里。所有后续的 pip 安装都会装到这个环境里不会污染全局。3.2 从 GitHub 获取源码与依赖安装Agent-Reach 托管在 GitHub 上获取源码的标准流程是git clone https://github.com/owner/agent-reach.git cd agent-reach pip install -r requirements.txt但这里有几个现实问题。第一GitHub 的访问速度在某些网络环境下可能不理想克隆大仓库的时候容易断。如果遇到这种情况可以试试加--depth 1参数只克隆最新一次提交能显著减少数据量git clone --depth 1 https://github.com/owner/agent-reach.git第二requirements.txt 里的依赖如果包含需要编译的包比如某些 C 扩展在 Windows 上可能会因为缺少编译器而失败。这时候要么装 Visual Studio Build Tools要么找有没有预编译的 wheel 包。pip 默认会优先找 wheel找不到才尝试从源码编译。第三如果项目用了 pyproject.toml 而不是 requirements.txt安装命令就变成pip install .或者开发模式安装pip install -e .开发模式的好处是你改了源码之后不用重新安装直接生效适合需要调试和修改的场景。提示如果 pip 安装速度慢可以换国内镜像源。命令是pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple。这个镜像源同步频率高包比较全能明显提升安装体验。3.3 首次运行与基础配置装完之后通常 Agent-Reach 会提供一个命令行入口。可能是agent-reach这个命令也可能是python -m agent_reach。先跑一下帮助看看agent-reach --help如果提示 command not found说明入口脚本没装好可以试试python -m agent_reach --help。如果这个也不行那就直接看源码里的入口文件通常是__main__.py或者cli.py用python cli.py --help来跑。首次运行一般需要配置一些东西。最常见的是 API key——Agent 要调用大模型总得有个模型服务。配置方式可能是环境变量也可能是配置文件。环境变量的做法是export AGENT_REACH_API_KEYyour-key-hereWindows 下用set或者$env:。配置文件的话通常放在~/.agent-reach/config.yaml或者项目目录下的.env文件里。具体看文档但原则是API key 这种东西绝对不要硬编码在源码里也不要提交到 Git。配置完之后跑一个最简单的任务验证一下agent-reach run 列出当前目录下的所有文件如果 Agent 能理解你的意图并返回结果说明基本链路通了。如果报错看错误信息。常见的错误包括API key 无效、模型名称写错、网络不通、依赖缺失。逐个排查。4. 核心功能模块深度解析4.1 Agent 循环感知、决策、执行任何 AI Agent 的核心都是一个循环感知当前状态做出决策执行动作然后根据执行结果更新状态继续循环。Agent-Reach 也不例外。理解这个循环是理解整个项目的关键。感知阶段Agent 需要获取当前的环境信息。这包括用户输入的任务描述、当前工作目录的内容、之前执行动作的结果、以及任何被注入的上下文信息。在 Agent-Reach 里这些信息会被组装成一个 prompt发给大模型。决策阶段大模型根据 prompt 返回一个动作。这个动作可能是调用某个工具、生成一段文本、或者宣布任务完成。Agent-Reach 需要解析模型的输出判断它想干什么。这里的一个技术难点是模型的输出是非结构化的自然语言你需要从中提取出结构化的动作指令。常见的做法是让模型输出 JSON 格式或者用特定的标记来包裹动作。执行阶段Agent-Reach 根据解析出的动作调用对应的工具函数。工具函数执行完毕后返回结果。这个结果会被加入到下一轮的感知信息里。这个循环听起来简单但实际实现的时候有很多细节。比如循环什么时候终止如果模型一直不宣布完成怎么办通常的做法是设置一个最大迭代次数比如 10 次或 20 次超过就强制停止。再比如如果工具执行出错怎么办是把错误信息返回给模型让它重新决策还是直接终止一般来说返回错误信息让模型自己调整是更好的做法因为模型可能会换一种方式完成任务。注意Agent 循环的最大迭代次数是一个需要根据实际任务调整的参数。设得太小复杂任务做不完设得太大简单任务可能会被模型过度解读浪费 token。我一般从 10 开始试根据任务复杂度再调。4.2 工具注册与调用机制Agent 要能干活必须有一组工具。Agent-Reach 的工具系统设计决定了它的扩展性。一个良好的工具系统应该满足几个条件注册简单、调用统一、错误可追溯。注册简单意味着加一个新工具不需要改很多地方。理想情况下你只需要写一个函数加一个装饰器工具就注册好了。Python 里可以用装饰器模式来实现tool def read_file(path: str) - str: 读取指定路径的文件内容 with open(path, r) as f: return f.read()这个装饰器做的事情是把函数注册到一个全局的工具注册表里同时提取函数的签名和文档字符串生成工具的描述信息。这个描述信息会被发给大模型让模型知道有哪些工具可用、每个工具接受什么参数。调用统一意味着不管什么工具调用方式都是一样的。Agent-Reach 内部应该有一个统一的execute_tool(name, params)函数根据工具名找到对应的函数传入参数返回结果。这样 Agent 循环里就不用关心具体是哪个工具只管调用就行。错误可追溯意味着工具执行出错的时候能清楚地知道是哪个工具、什么参数、什么错误。这对调试非常重要。实现上可以在 execute_tool 里加 try-except把异常信息连同工具名和参数一起记录下来。工具的设计还有一个原则粒度要适中。太细的工具比如“读取文件第一行”会让模型需要调用很多次才能完成一个任务太粗的工具比如“处理所有文件”又会让模型失去控制权。一般来说一个工具应该对应一个明确的、原子性的操作。4.3 上下文管理与 Token 优化Agent 循环跑起来之后上下文会越来越长。每一轮都要把之前的所有对话和工具调用结果发给模型token 消耗会快速增长。如果不加管理很快就会超出模型的上下文窗口或者产生高昂的费用。Agent-Reach 需要有一套上下文管理策略。常见的做法有几种滑动窗口、摘要压缩、选择性保留。滑动窗口是最简单的只保留最近 N 轮对话更早的直接丢掉。这样做的问题是可能会丢失重要的早期信息。比如用户在任务开始时说的一个关键约束如果被丢掉了模型后面就可能违反这个约束。摘要压缩是让模型自己把早期的对话总结成一段简短的文字然后用这个摘要替代原始对话。这样做能保留关键信息但摘要本身也会消耗 token而且摘要的质量取决于模型的能力。选择性保留是结合前两种重要的消息比如用户的原始任务描述、关键的工具调用结果永久保留不重要的中间过程可以丢掉或压缩。实现上可以给每条消息打一个重要性标签然后根据标签决定保留策略。我个人的经验是对于大多数任务滑动窗口加上对初始任务描述的永久保留就能覆盖百分之八十的场景。如果任务特别复杂、步骤特别多再考虑上摘要压缩。提示在调试 Agent 的时候把每一轮发给模型的完整 prompt 打印出来能帮你快速定位问题。很多时候 Agent 行为异常是因为上下文里混入了不该有的信息或者关键信息被截断了。5. 常见问题与排查技巧实录5.1 安装与依赖相关问题问题一pip install 报错提示找不到某个包这种情况通常是包名写错了或者这个包在 PyPI 上不存在。先确认包名拼写然后去 PyPI 网站上搜一下。如果包确实存在但还是找不到可能是 pip 版本太老升级一下pip install --upgrade pip。问题二安装过程中编译失败典型错误信息里会有gcc、cl.exe、Microsoft Visual C这些关键词。说明某个依赖需要编译 C 扩展但你的系统里没有编译器。Windows 上装 Visual Studio Build ToolsLinux 上装build-essentialmacOS 上装 Xcode Command Line Tools。问题三装完了但命令找不到检查虚拟环境是否激活。如果激活了还是找不到看看包的入口点有没有正确安装。可以用pip show agent-reach查看包的安装位置和入口点信息。5.2 运行时错误与排查思路问题四Agent 一直循环不停止先看最大迭代次数设置了多少。如果设得很大Agent 可能会在某个问题上反复尝试。这时候需要看日志找出它在重复做什么。常见原因是工具返回的结果不符合模型预期导致模型不断重试。解决方法是优化工具的返回信息让它更明确。问题五模型返回的动作无法解析这说明模型的输出格式和 Agent-Reach 期望的格式不匹配。可能是模型没有按照 prompt 里的要求输出 JSON或者输出了 JSON 但字段名不对。排查方法是把模型的原始输出打印出来看。解决方法是优化 prompt给出更明确的格式示例。问题六工具调用超时网络请求或者外部命令执行时间过长。Agent-Reach 应该给每个工具调用设置超时。如果超时频繁发生要么是外部服务不稳定要么是超时时间设得太短。先调大超时时间试试如果还不行就要查外部服务的状态。5.3 性能与成本优化建议建议一缓存重复的工具调用结果如果 Agent 在同一个任务里多次调用同一个工具、传同样的参数结果应该被缓存。这样能减少不必要的网络请求和计算。建议二用小模型做简单决策不是所有决策都需要大模型。如果某个决策很简单比如判断一个字符串是不是 URL可以用规则或者小模型来做省下大模型的 token。建议三批量处理工具调用如果 Agent 需要调用同一个工具的多个不同参数看看能不能合并成一次调用。比如读取多个文件可以一次传一个文件列表而不是分多次调用。建议四监控 token 消耗在 Agent 循环里记录每一轮的 token 使用量跑完一个任务后汇总。这样你能清楚地知道钱花在哪里了哪些环节可以优化。常见问题可能原因排查方法解决方案命令找不到虚拟环境未激活检查终端提示符激活虚拟环境安装编译失败缺少编译器看错误信息关键词安装 Build ToolsAgent 死循环最大迭代次数过大看日志重复模式调小迭代次数优化工具返回动作解析失败模型输出格式不对打印原始输出优化 prompt 格式示例工具调用超时外部服务慢检查网络和服务状态调大超时加缓存6. 扩展开发与二次开发指南6.1 添加自定义工具Agent-Reach 如果设计得好添加自定义工具应该是一件很轻松的事情。基本流程是写一个 Python 函数加上工具装饰器确保函数有清晰的文档字符串和类型注解然后重启 Agent 就能用了。文档字符串很重要因为它是模型理解工具用途的唯一途径。写文档字符串的时候要站在模型的角度想模型看到这个描述能不能准确判断什么时候该用这个工具参数说明要具体不要写“path: 路径”要写“path: 要读取的文件的绝对路径或相对于工作目录的路径”。类型注解也很重要。模型需要知道每个参数是什么类型。是字符串、整数、还是布尔值如果是枚举类型最好在文档字符串里列出所有可选值。一个自定义工具的完整示例from agent_reach.tools import tool tool def search_files(keyword: str, directory: str .) - list: 在指定目录下搜索包含关键词的文件名。 Args: keyword: 要搜索的关键词 directory: 搜索的起始目录默认为当前目录 Returns: 匹配的文件路径列表 import os matches [] for root, dirs, files in os.walk(directory): for file in files: if keyword in file: matches.append(os.path.join(root, file)) return matches这个工具注册之后模型就能在需要搜索文件的时候调用它。6.2 接入不同的模型后端Agent-Reach 默认可能接的是某个特定的模型服务但实际使用中你可能有不同的偏好。有的任务适合用 GPT-4有的任务用本地模型就够了。Agent-Reach 如果抽象出了模型接口层切换后端应该只需要改配置。模型接口层通常需要定义几个方法chat(messages)用于对话embed(text)用于生成向量如果需要 RAG 的话。不同的模型服务实现这个接口Agent-Reach 的核心逻辑只依赖接口不依赖具体实现。接入本地模型的话可以用 LM Studio 或者 Ollama 这类工具来跑。它们通常提供兼容 OpenAI API 的接口所以如果你的 Agent-Reach 支持 OpenAI 格式改一下 base_url 就能接上。比如 LM Studio 默认的接口地址是http://localhost:1234/v1把 API key 随便填一个非空值模型名填你加载的模型名称就能用了。注意本地模型的输出质量和云端大模型可能有差距尤其是在工具调用的格式遵循上。如果发现本地模型经常不按格式输出可以在 prompt 里加更严格的约束或者换一个指令遵循能力更强的本地模型。6.3 多 Agent 协作的扩展思路单个 Agent 的能力有上限复杂任务往往需要多个 Agent 协作。Agent-Reach 如果支持多 Agent扩展思路大致有几种。一种是主从模式一个主 Agent 负责拆解任务把子任务分配给从 Agent从 Agent 执行完把结果返回给主 Agent。这种模式适合任务可以清晰分解的场景。另一种是对等模式多个 Agent 各自负责一个领域通过消息传递来协作。比如一个 Agent 负责文件操作一个 Agent 负责网络请求一个 Agent 负责代码执行。这种模式适合任务需要多种能力的场景。实现多 Agent 协作的关键是通信机制。最简单的还是基于文件系统每个 Agent 有一个收件箱目录其他 Agent 往里面写消息文件Agent 轮询自己的收件箱。这种方式简单可靠但实时性差。如果要实时性可以用消息队列比如 Redis 的 pub/sub但这就引入了外部依赖。Agent-Reach 如果要在保持轻量的前提下支持多 Agent文件系统方案可能是最务实的选择。毕竟对于大多数个人项目和小团队来说引入一个 Redis 实例来跑几个 Agent有点杀鸡用牛刀了。7. 实际使用中的经验与避坑总结7.1 我踩过的几个坑第一个坑是路径问题。Agent 在执行文件操作的时候如果用的是相对路径它的工作目录可能和你预期的不一样。我遇到过 Agent 把文件写到了虚拟环境的目录里而不是项目目录。解决方法是在 Agent 启动的时候明确设置工作目录并且在所有文件操作工具里都用绝对路径。第二个坑是模型对工具返回结果的解读。有一次我写了一个工具返回 JSON 字符串模型把它当成了普通文本没有解析里面的字段。后来我在工具的文档字符串里明确写了“返回 JSON 格式”并且在 Agent 循环里加了一步如果工具返回的是 JSON就把它格式化后再发给模型。这样模型就能正确理解了。第三个坑是 token 超限。有一个任务需要处理大量文件Agent 把每个文件的内容都读进了上下文结果很快就超了模型的窗口限制。后来我改成了让 Agent 先列出文件然后逐个处理每个文件处理完就把内容从上下文里移除。这样虽然多花了几个循环但 token 消耗降下来了。7.2 一些实用的调试技巧把 Agent 的每一步都记录下来。包括发给模型的 prompt、模型返回的原始输出、解析后的动作、工具执行的结果。这些信息在排查问题的时候非常有用。可以写一个简单的日志装饰器挂在关键函数上。用--verbose或者--debug参数来开启详细日志。如果 Agent-Reach 没有这个参数可以自己在代码里加。Python 的 logging 模块配置一下就能输出到文件方便事后分析。对于复杂的任务先用一个简化的版本测试。比如你要 Agent 处理一百个文件先用三个文件测试流程。确认流程通了再上全量。这样能快速定位是流程问题还是数据问题。7.3 关于安全的一些提醒Agent 能执行代码、能读写文件、能发网络请求这些能力如果被滥用后果可能很严重。几个基本的安全原则工作目录要隔离。Agent 的文件操作应该被限制在一个专门的目录里不能让它访问系统文件或者其他项目文件。网络请求要限制。如果 Agent 能随意发请求可能会被诱导去访问恶意地址。可以设置一个域名白名单只允许访问特定的服务。代码执行要沙箱。如果 Agent 能执行任意代码那风险就很大了。至少要做到限制可执行的命令、限制执行时间、限制内存使用。更好的做法是在容器里执行。API key 要保护好。不要把 key 写在代码里不要提交到 Git不要打印到日志里。用环境变量或者专门的密钥管理服务。提示在把 Agent 部署到生产环境之前一定要做一次安全审查。问自己几个问题Agent 能访问哪些资源如果它被恶意输入诱导最坏的情况是什么有没有办法限制损害范围7.4 性能调优的几点体会异步化是提升性能最有效的手段。Agent 的大部分时间花在等模型返回和等工具执行上这些都是 IO 操作。用 asyncio 把这些等待并发起来吞吐量能提升好几倍。缓存能省很多钱。模型调用和工具调用都可以缓存。对于确定性强的操作比如读文件缓存效果特别好。对于模型调用如果同样的 prompt 反复出现也可以缓存结果。批处理能减少开销。如果 Agent 需要做很多类似的操作看看能不能合并。比如需要读取十个文件一次读十个比读十次快得多。监控能帮你找到瓶颈。记录每个环节的耗时跑一段时间后看统计数据。你会发现百分之八十的时间花在百分之二十的环节上优化那百分之二十就够了。Agent-Reach 这个项目从名字到定位都透露出一种务实的气质。它不追求大而全而是专注于让 Agent 能够可靠地触达外部资源。这种专注在当前的 AI Agent 生态里反而显得珍贵。如果你正在找一个轻量、可扩展、不绑架你的 Agent 框架它值得花时间研究一下。我个人的体会是工具的价值不在于功能多少而在于它能不能让你把想法快速变成能跑的东西。Agent-Reach 在这方面至少方向是对的。