1. 项目概述一个面向开发者的开源AI智能体框架最近在GitHub上闲逛又发现了一个挺有意思的开源项目叫oh-my-openagent。这个项目名就挺有“梗”的熟悉Linux的朋友一看就知道它是在向经典的oh-my-zsh致敬。不过它的核心可不是美化终端而是瞄准了当下最火热的AI智能体Agent领域。简单来说这是一个旨在帮助开发者快速构建、管理和部署AI智能体的开源框架。如果你是一名开发者或者对AI应用开发感兴趣可能已经感受到了这股浪潮。现在单纯调用一个大语言模型的API来完成问答已经不能满足很多复杂场景的需求了。我们需要的是能够自主规划、使用工具、与环境交互、并持续学习的“智能体”。但自己从零开始搭建一个这样的智能体系统涉及任务分解、记忆管理、工具调用、流程编排等多个复杂模块门槛不低。oh-my-openagent的出现就是为了降低这个门槛。它试图提供一个开箱即用的、模块化的基础架构让开发者能像搭积木一样组合出功能各异的AI智能体无论是用于自动化办公、数据分析、智能客服还是更复杂的业务场景。这个项目目前由开发者code-yeongyu维护从代码提交和文档来看还处于比较活跃的早期阶段。但这恰恰是开源项目的魅力所在——你可以看到它的设计思路参与到它的演进过程中甚至根据自己的需求进行定制。接下来我就结合自己的理解和一些初步的探索来深度拆解一下这个项目看看它到底想解决什么问题又是如何设计的以及我们该如何上手使用甚至贡献代码。2. 核心设计理念与架构拆解2.1 为什么我们需要“智能体框架”在深入代码之前我们得先搞清楚为什么一个“框架”是必要的。你可以把大语言模型LLM想象成一个知识渊博但“四肢不勤”的大脑。它很擅长理解和生成语言但让它去查数据库、发邮件、操作软件它就无能为力了。智能体就是给这个大脑装上“四肢”工具和“神经系统”控制逻辑让它能真正行动起来。自己实现一个智能体你至少需要处理以下几个核心问题任务规划与分解用户说“帮我分析一下上个月的销售数据并写一份报告”智能体需要自己拆解成“登录数据库”、“查询销售表”、“计算环比同比”、“生成图表”、“撰写总结段落”等一系列子任务。工具调用与管理每个子任务可能需要不同的工具比如execute_sql、send_email、call_api。如何让LLM理解这些工具的功能、输入输出格式并正确地调用它们记忆与上下文管理智能体在执行多轮对话或长链条任务时需要记住之前做了什么、得到了什么结果。这涉及到短期对话记忆、长期知识存储甚至是从历史中学习经验。流程控制与错误处理如果某个工具调用失败了怎么办如果LLM的回复不符合预期如何纠正整个任务的执行流程是线性的、循环的还是基于状态的可观测性与调试智能体内部是如何决策的为什么它调用了A工具而不是B它的“思考过程”是否透明这对于开发和调试至关重要。oh-my-openagent的设计目标就是将这些通用且复杂的模块抽象出来提供一套标准化的接口和默认实现让开发者可以专注于定义具体的工具和业务逻辑而不是重复造轮子。2.2 项目架构初探虽然项目的具体实现会不断迭代但根据其文档和代码结构我们可以推断出其架构大致遵循了智能体系统的常见范式。通常一个智能体框架会包含以下几个层次工具层Tools这是智能体的“手和脚”。框架会定义一套工具接口开发者可以据此实现各种具体工具如网络搜索、文件读写、代码执行、API调用等。框架的核心职责之一是做好工具的描述让LLM知道这个工具能干嘛和调用封装。智能体核心层Agent Core这是“大脑”的驱动逻辑。它包含规划器Planner负责将用户目标分解为任务序列。可能采用链式思考Chain-of-Thought、思维树Tree of Thoughts等策略。执行器Executor负责按规划调用具体的工具并处理工具返回的结果。记忆体Memory存储对话历史、工具执行结果、学到的知识等。可能分为短期缓存和长期向量数据库存储。编排与生命周期管理层Orchestration管理智能体的多轮对话、并发执行、状态持久化等。这一层决定了智能体是单次任务型还是常驻服务型。可观测层Observability提供日志、追踪Tracing、评估Evaluation等功能让开发者能看清智能体内部的运行状态便于调试和优化。从oh-my-openagent的仓库结构来看它很可能采用了类似的模块化设计。目录中应该会有tools/、agents/、memory/、orchestration/这样的文件夹每个模块相对独立通过清晰的接口进行通信。这种设计的好处是灵活性高你可以替换默认的规划算法接入不同的记忆后端或者轻松地添加自定义工具。注意开源项目早期文档和结构可能变化较快。最准确的方式是直接阅读项目的README.md、docs/目录以及pyproject.toml或setup.py来了解其依赖和模块划分。3. 快速上手构建你的第一个智能体理论讲得再多不如动手试试。我们假设oh-my-openagent已经提供了一些基础工具和一个简单的智能体类来看看如何快速搭建一个能查询天气并给出穿衣建议的智能体。3.1 环境准备与安装首先你需要一个Python环境建议3.8以上。然后通过pip从源码或如果已发布从PyPI安装。# 假设项目已发布到PyPI可能尚未发布此为示例 # pip install oh-my-openagent # 更可能的方式是从GitHub克隆并安装 git clone https://github.com/code-yeongyu/oh-my-openagent.git cd oh-my-openagent pip install -e . # 以可编辑模式安装方便修改代码安装过程会处理项目依赖通常包括某个LLM的SDK如OpenAI, Anthropic, 或本地模型库、一些工具依赖如请求库、数据库驱动等。3.2 定义你的工具智能体需要工具。我们创建一个获取天气的工具。框架通常会提供一个装饰器或基类来定义工具。# my_weather_tool.py import requests from openagent.tools import tool # 假设框架提供了 tool 装饰器 tool def get_weather(city: str) - str: 获取指定城市的当前天气情况。 Args: city: 城市名称例如“北京”、“Shanghai”。 Returns: 一个描述天气的字符串例如“北京晴25摄氏度微风”。 # 这里使用一个模拟的天气API实际项目中请替换为真实的API # 注意处理错误和异常非常重要 try: # 示例URL实际需替换 response requests.get(fhttps://api.weather.example.com/current?city{city}, timeout10) response.raise_for_status() data response.json() return f{city}{data[condition]}{data[temp]}摄氏度{data[wind]} except requests.exceptions.RequestException as e: return f获取{city}的天气信息失败{e} # 再定义一个简单的“穿衣建议”工具它本身不调用API而是基于规则给出建议。 tool def get_clothing_advice(weather_desc: str) - str: 根据天气描述给出简单的穿衣建议。 Args: weather_desc: 天气描述字符串例如“晴25摄氏度微风”。 Returns: 穿衣建议字符串。 if 雨 in weather_desc: return 建议携带雨具穿防水外套。 elif 高温 in weather_desc or 30 in weather_desc: # 简单判断 return 天气炎热建议穿短袖、短裤等清凉衣物注意防晒。 elif 低温 in weather_desc or 0 in weather_desc: return 天气寒冷建议穿羽绒服、毛衣等保暖衣物。 else: return 天气舒适建议穿长袖T恤、薄外套等。关键点解析tool装饰器这是框架提供的“魔法”。它会自动将你的函数包装成一个标准工具可能还会自动生成供LLM理解的描述从函数文档字符串和类型注解中提取。清晰的文档字符串Docstring这极其重要LLM以及你的同事需要通过这个描述来理解工具的用途和输入输出格式。描述要准确、简洁。健壮的错误处理工具在真实世界中会失败网络超时、API限流、数据格式异常。你的工具必须能妥善处理这些情况并返回一个对智能体有意义的错误信息而不是直接崩溃。3.3 组装并运行智能体有了工具接下来就是创建一个智能体并将工具赋予它。# run_agent.py import asyncio from openagent.agents import Agent # 假设框架提供了Agent基类 from openagent.memory import SimpleMemory # 假设有一个简单的内存实现 from my_weather_tools import get_weather, get_clothing_advice async def main(): # 1. 初始化智能体并指定使用的LLM这里以OpenAI为例 agent Agent( llmgpt-4, # 或其它支持的模型标识 llm_api_keyyour-api-key-here, # 在实际应用中请使用环境变量管理密钥 memorySimpleMemory(), # 使用一个简单的内存来记住对话历史 ) # 2. 为智能体注册工具 agent.register_tool(get_weather) agent.register_tool(get_clothing_advice) # 3. 运行智能体 user_query 上海今天天气怎么样我应该穿什么 print(f用户: {user_query}) response await agent.run(user_query) print(f智能体: {response}) # 智能体的内部思考过程可能是这样的框架可能会暴露出来 # 1. 用户问上海天气和穿衣建议。 # 2. 我需要先获取天气我有get_weather工具。 # 3. 调用 get_weather(上海)得到结果“上海多云22摄氏度微风”。 # 4. 然后我需要基于这个天气给出穿衣建议我有get_clothing_advice工具。 # 5. 调用 get_clothing_advice(多云22摄氏度微风)得到结果“天气舒适建议穿长袖T恤、薄外套等。” # 6. 将两步结果整合回复用户。 if __name__ __main__: asyncio.run(main())实操心得API密钥管理永远不要将API密钥硬编码在代码中使用环境变量如os.getenv(OPENAI_API_KEY)或密钥管理服务。异步编程很多AI框架和网络调用都是异步的async/await。主入口需要使用asyncio.run()。如果你不熟悉异步编程需要先补课因为这是现代Python高性能应用的标配。智能体的“思考”过程一个设计良好的框架应该提供某种方式来查看或记录智能体的“推理轨迹”Reasoning Trace即它是如何一步步分析问题、选择工具、解析结果的。这对于调试复杂任务至关重要。在oh-my-openagent中可以查看是否有日志级别设置或专门的trace模块。4. 深入核心如何设计一个可扩展的工具系统工具是智能体的基石。oh-my-openagent框架的价值很大程度上体现在其对工具系统的抽象和管理能力上。我们来深入探讨一下一个健壮的工具系统应该考虑哪些方面。4.1 工具的描述与发现LLM如何知道它有哪些工具可用框架需要将工具“翻译”成LLM能理解的格式。通常这会是一个结构化的列表包含每个工具的名称、描述、参数列表参数名、类型、描述和返回类型。# 框架内部可能生成的工具描述结构示例 tools_description_for_llm [ { name: get_weather, description: 获取指定城市的当前天气情况。, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如“北京”、“Shanghai”。 } }, required: [city] } }, # ... 其他工具 ]这个描述会在每次与LLM交互时作为系统提示词System Prompt的一部分发送给LLM或者通过函数调用Function Calling机制传递。框架的职责是自动从我们之前用tool装饰的函数中提取这些信息。4.2 工具的调用与验证当LLM决定调用某个工具时它会生成一个符合上述参数格式的调用请求通常是一个JSON对象。框架需要路由根据工具名找到对应的Python函数。参数验证与解析检查LLM提供的参数是否齐全、类型是否匹配例如把字符串“123”转换成整数123。这可以借助Pydantic等库来实现强大的数据验证。安全执行在调用工具函数时要考虑安全性。特别是对于execute_code、shell_command这类高危工具必须有沙箱环境或严格的权限控制。oh-my-openagent如果提供这类工具其设计必须非常谨慎。结果处理捕获工具执行的结果或异常并将其格式化为LLM能继续处理的文本。4.3 工具的组合与流程简单的智能体一次只调用一个工具。但复杂的任务需要组合多个工具甚至根据中间结果动态决定下一步。这就引出了“工作流”或“规划”的概念。框架可能提供更高级的抽象比如顺序链Sequential Chain预定义好工具A - 工具B - 工具C的执行顺序。条件分支根据工具A的结果决定下一步调用工具B还是工具C。循环重复调用某个工具直到满足条件例如不断搜索直到找到满意答案。这些能力可能通过一个独立的“规划器”模块来实现也可能通过更强大的“智能体”类来封装。作为开发者我们需要了解框架支持哪些模式以及如何配置它们。注意事项工具粒度的权衡工具应该设计得足够“细”还是足够“粗”太细如“打开文件”、“读取一行”、“关闭文件”会导致LLM需要规划太多步骤容易出错。太粗如“生成月度销售报告”则工具本身内部逻辑过于复杂失去了灵活组合的意义。一个好的原则是一个工具最好只完成一件职责清晰、相对独立的事情。工具描述的准确性工具的描述直接决定了LLM能否正确使用它。描述要避免歧义明确说明输入参数的格式例如日期是“YYYY-MM-DD”还是“MM/DD/YYYY”以及输出结果的示例。5. 记忆管理让智能体拥有“过去”没有记忆的智能体每次对话都是全新的开始这显然不符合我们对“智能”的期待。oh-my-openagent的记忆系统负责存储和检索与当前对话或任务相关的信息。5.1 记忆的类型通常智能体记忆可以分为几个层次对话历史Conversation History最基础的记忆就是简单的“用户说-智能体说”的轮次记录。这对于维持对话连贯性必不可少。短期工作记忆Short-term Working Memory存储当前任务执行过程中的中间结果、工具执行输出等。这些信息可能只在当前任务链中有效。长期记忆Long-term Memory存储从过去所有交互中学到的“知识”或“经验”。例如用户曾经说过“我喜欢喝美式咖啡”这个信息应该被存储下来并在未来相关的对话中被回忆起来。这通常需要向量数据库如Chroma, Pinecone, Weaviate的支持将信息转换为向量Embedding存储并通过语义相似度进行检索。5.2 记忆的存储与检索一个简单的内存实现可能就是一个Python列表存放最近的几条消息。但一个生产级的框架需要更强大的能力摘要Summarization当对话历史很长时全部发送给LLM会消耗大量令牌Token并可能超出上下文长度限制。一种策略是定期将旧的对话历史总结成一段简短的摘要只保留摘要和最近的消息。向量检索Vector Retrieval对于长期记忆当用户提出一个新问题时系统需要从庞大的记忆库中快速找到最相关的几条信息。这就是向量数据库的用武之地。框架需要集成向量化的能力调用Embedding模型API和检索接口。记忆的更新与遗忘不是所有信息都需要永久记忆。框架可能需要提供策略比如基于时间、基于重要性评分来清理或归档旧记忆。在oh-my-openagent中你可能会看到类似ConversationBufferMemory、SummaryMemory、VectorStoreMemory这样的类。使用它们的方式可能如下from openagent.memory import ConversationSummaryMemory, VectorStoreRetrieverMemory from openagent.vectorstores import ChromaVectorStore # 假设集成Chroma # 使用带摘要的对话记忆 summary_memory ConversationSummaryMemory(llmllm, max_token_limit1000) # 使用基于向量数据库的长期记忆 vector_store ChromaVectorStore(persist_dir./chroma_db) long_term_memory VectorStoreRetrieverMemory( retrievervector_store.as_retriever(search_kwargs{k: 3}) # 检索最相关的3条 ) # 将多种记忆组合使用 agent Agent(llmllm, memory[summary_memory, long_term_memory], ...)实操心得上下文长度是宝贵资源LLM的上下文窗口如GPT-4的128K虽然大但也不是无限的。在设计和配置记忆系统时要时刻考虑如何高效利用Token。摘要和选择性检索是关键。记忆的“相关性”不等于“正确性”向量检索根据语义相似度返回信息但最相似的信息不一定是正确或当前任务最需要的。有时需要结合关键词过滤、元数据如时间戳、来源来优化检索策略。记忆可能带来偏见如果长期记忆中存储了错误的信息它可能会被反复检索出来影响智能体的判断。需要考虑记忆的验证和修正机制。6. 实战进阶构建一个自动化数据分析智能体让我们用一个更复杂的例子来串联前面讲到的所有概念构建一个能接受自然语言指令自动进行数据查询、分析和可视化的智能体。6.1 场景与工具定义假设我们有一个销售数据库。我们想让智能体能回答诸如“对比一下北京和上海第三季度各产品的销售额用柱状图展示”这样的问题。我们需要定义以下工具query_database(sql_query: str) - List[Dict]: 执行SQL查询返回结果列表。generate_chart(data: List[Dict], chart_type: str, title: str) - str: 根据数据和图表类型柱状图、折线图等生成图表返回图表文件的保存路径或一个Base64编码的图片数据。analyze_trends(data: List[Dict]) - str: 对数据进行简单的统计分析如计算增长率、排序并返回文本描述。6.2 智能体配置与流程设计这个任务比简单的天气查询复杂得多可能涉及多轮交互和复杂的规划。第一层规划智能体需要理解用户问题将其分解为a) 编写查询北京第三季度销售额的SQLb) 编写查询上海第三季度销售额的SQLc) 合并/对比数据d) 生成柱状图。第二层执行与纠错执行SQL可能因为表名或字段名错误而失败。智能体需要能捕获错误并尝试修正SQL可能需要一个“诊断SQL错误”的子工具或者让LLM根据错误信息重新生成SQL。第三层结果整合将两个查询结果进行合并、对比然后调用generate_chart工具。最后可能还要调用analyze_trends来生成文字结论。在oh-my-openagent中我们可能需要使用一个更高级的“规划型智能体”Planner Agent或者利用框架提供的“工作流”功能来定义这个执行流程。# 伪代码展示一种可能的编排方式 from openagent.agents import PlannerAgent from openagent.tools import SQLDatabaseToolkit # 假设框架提供了数据库工具包 # 初始化数据库连接和工具包 db_tools SQLDatabaseToolkit(database_urisqlite:///sales.db).get_tools() chart_tool generate_chart analysis_tool analyze_trends all_tools db_tools [chart_tool, analysis_tool] # 创建一个规划型智能体 data_agent PlannerAgent( llmllm, toolsall_tools, memoryConversationSummaryMemory(llmllm), planner_llmllm, # 可能用一个更强的LLM专门负责规划 max_iterations10, # 防止无限循环 ) # 运行复杂任务 response await data_agent.run(对比一下北京和上海第三季度各产品的销售额用柱状图展示并给出分析。)6.3 错误处理与鲁棒性在这个场景下错误处理至关重要SQL注入风险绝对不能让LLM直接拼接用户输入生成SQL。应该使用参数化查询或者限制LLM只能操作特定的、安全的查询模式通过工具封装来实现。工具调用失败query_database可能因为SQL语法错误而失败。框架应该能捕获这个异常并将其作为反馈信息重新给到智能体让智能体进行“反思”并尝试修正。结果验证generate_chart工具拿到的数据格式可能不对比如缺少必要的字段。工具内部应该进行数据校验返回明确的错误信息。一个健壮的框架会提供标准的错误处理流程允许智能体在遇到失败时尝试其他路径或向用户请求澄清。7. 部署与监控让智能体走向生产开发调试完成的智能体最终需要部署为服务供其他系统或用户调用。同时在运行过程中对其进行监控和评估也必不可少。7.1 部署模式oh-my-openagent作为一个框架可能提供了不同的部署选项API服务器将智能体封装成一个HTTP API服务例如使用FastAPI。这可能是最常见的模式前端或其它微服务可以通过RESTful接口与智能体交互。消息队列消费者智能体作为后台Worker从消息队列如RabbitMQ, Kafka中消费任务请求处理完成后将结果投递到另一个队列。适合异步、高吞吐量的场景。命令行工具对于一些自动化脚本任务智能体也可以打包成CLI工具。集成到现有应用将智能体作为库直接导入到你的Python Web应用如Django, Flask中。框架可能会提供一个标准的AgentServer类或类似的封装简化启动过程。# 示例使用框架提供的FastAPI集成 from openagent.servers import FastAPIAgentServer from my_agent import my_custom_agent # 导入你定义好的智能体 app FastAPIAgentServer(agentmy_custom_agent).get_app() # 然后使用 uvicorn 运行 # uvicorn main:app --host 0.0.0.0 --port 80007.2 监控、日志与评估智能体在线上运行我们必须要知道它“干得怎么样”。日志记录框架应该记录详细的运行日志包括接收的用户输入、LLM的原始请求和响应注意脱敏、调用的工具及其参数结果、每一步的耗时等。这些日志对于排查问题至关重要。链路追踪Tracing类似于分布式系统中的调用链追踪智能体的每一次运行都应该有一个唯一的Trace ID将LLM调用、工具调用串联起来方便在复杂流程中定位瓶颈或错误点。评估Evaluation如何衡量智能体的表现这可能是最大的挑战。框架或许会提供一些基础评估工具比如端到端评估给定一组标准测试问题QA对看智能体的回答是否匹配预期。工具使用正确率评估智能体在需要调用工具的场景下是否选择了正确的工具并提供了正确的参数。人工反馈集成记录用户对智能体回复的“点赞”或“点踩”作为改进的信号。注意事项成本监控LLM API调用是按Token收费的工具调用可能涉及外部API费用。框架应该能统计每次运行消耗的Token数和成本并设置预算告警。速率限制与重试对接LLM API和外部工具API时必须妥善处理速率限制Rate Limit和临时性故障实现带退避策略的重试机制。安全性部署对外开放的API时必须考虑身份认证、授权、输入验证、防Prompt注入攻击等安全措施。框架可能提供一些基础钩子Hooks或中间件但主要的安全责任在开发者自身。8. 常见问题与排查技巧实录在实际使用和探索oh-my-openagent这类框架时你肯定会遇到各种各样的问题。下面记录一些典型场景和排查思路。8.1 智能体不调用工具总是“自言自语”现象你明明注册了工具但智能体在回答问题时完全无视工具只用LLM本身的知识生成一个可能不准确或笼统的答案。可能原因与排查工具描述不清晰检查你的工具函数文档字符串。是否清晰、无歧义地描述了功能、输入和输出LLM可能因为看不懂描述而不敢调用。LLM配置问题确认你使用的LLM模型是否支持函数调用Function Calling或工具使用如GPT-3.5-turbo-1106及以上版本、GPT-4系列、Claude等。有些旧版或小型模型可能不支持此功能。系统提示词System Prompt冲突框架会生成一个默认的系统提示词来指导LLM使用工具。但如果你自己额外设置了很强的系统提示词比如“你是一个乐于助人的AI助手”可能会覆盖或干扰框架的指令。查看框架文档了解如何正确自定义系统提示词。温度Temperature参数过高LLM的Temperature参数控制输出的随机性。如果设置得太高接近1LLM可能会过于“天马行空”不遵循使用工具的指令。尝试将其调低如0.1或0.2。8.2 工具调用参数错误现象智能体尝试调用工具但传递的参数格式不对导致工具执行失败。可能原因与排查参数类型不匹配LLM生成的是JSON字符串框架需要将其反序列化并验证类型。检查你的工具函数参数的类型注解Type Hints。框架是否支持复杂的嵌套类型最稳妥的方式是使用基本的str,int,float,bool和List、Dict。参数值不合理例如city参数传了一个空字符串或“123”。这需要工具函数内部做校验并返回明确的错误信息让智能体有机会重试。查看原始交互数据开启框架的调试日志查看发送给LLM的完整消息包括工具描述以及LLM返回的包含工具调用的响应。这能最直观地看到问题出在哪里。8.3 智能体陷入循环或效率低下现象智能体在一个简单问题上反复调用工具或者进行无意义的“思考”迟迟给不出答案。可能原因与排查最大迭代次数限制检查智能体配置中的max_iterations或max_steps参数。设置一个合理的上限比如10-20次防止无限循环。规划能力不足对于复杂任务默认的简单规划策略可能不够。考虑切换到更强大的“规划器”智能体或者将复杂任务拆分成多个子任务通过更高级的工作流Workflow来编排。记忆干扰如果记忆系统中存储了过多无关或过时的信息可能会干扰LLM的决策。尝试清空记忆或者优化记忆的检索策略如提高检索的相关性阈值。8.4 性能瓶颈分析现象智能体响应很慢。排查思路分段计时在代码中关键步骤LLM调用、工具执行、记忆检索前后添加计时点找出耗时最长的环节。LLM API延迟LLM API调用通常是最大的延迟来源。考虑使用响应更快的模型如果精度允许或者实现流式响应Streaming来提升用户体验。工具优化检查自定义工具的实现。是否有耗时的同步I/O操作如网络请求、大文件读写考虑将其改为异步async实现或者引入缓存。上下文长度如果发送给LLM的上下文对话历史工具描述非常长不仅会增加Token成本也会增加API的响应时间。积极使用记忆摘要功能只保留最相关的信息。8.5 如何为开源项目贡献如果你在使用oh-my-openagent过程中发现了Bug或者有很好的功能想法可以考虑为其贡献代码。熟悉项目仔细阅读CONTRIBUTING.md如果有、项目代码结构、现有的Issue和Pull Request。从小处着手可以先从修复文档错别字、增加测试用例、或解决一个标记为“good first issue”的Bug开始。代码风格遵循项目已有的代码风格和规范如Black, isort, flake8。充分测试为你新增的功能或修复编写单元测试。清晰描述提交Pull Request时详细说明你修改了什么、为什么修改、以及如何测试。参与到这样一个前沿的开源项目中不仅能解决自己的问题还能与优秀的开发者交流是快速提升技术能力的绝佳途径。