Python

两种处理错误/边界条件的编程风格，在 Python 社区尤为常见。 LBYL — Look Before You Leap（先检查再操作） 谚语来源： “Look Before You Leap” 字面意思是"跳跃之前，先看清脚下"。想象要跳过一条沟——不先看清落脚点就跳，可能会摔进坑里。引申为行动之前先确认条件是否安全，对应中文谚语"三思而后行"、“谋定而后动”。 在编程里，“leap”（跳跃）= 执行操作，“look”（看）= if 条件检查。 操作前先检查前提条件是否满足。 # LBYL 风格 if key in my_dict: value = my_dict[key] else: value = default if os.path.exists(filepath): with open(filepath) as f: data = f.read() 特点： 逻辑清晰，防御性强 存在 TOCTOU（Time-Of-Check-Time-Of-Use）竞态条件风险——检查和使用之间状态可能改变 代码中充满 if 判断，容易冗长 EAFP — Easier to Ask Forgiveness than Permission（先操作再处理异常） 短语来源： 这句话来自生活场景的比喻——想做某事时，与其事先去请示许可（可能被拒绝、很麻烦），不如直接去做，事后出了问题再道歉求谅解，因为道歉往往比请示更容易。 英文 字面意思 编程含义 Ask Permission 事先请求许可 用 if 检查条件是否满足 Ask Forgiveness 事后请求原谅 用 except 处理出错的异常 这个说法由 Python 之父 Guido van Rossum 推广，体现了 Python 的哲学：代码应该表达意图，而不是充满防御性检查。 ...

什么是 LangGraph LangGraph 是 LangChain 生态系统中的一个框架，专门用于构建有状态的、多步骤的 AI 应用程序。它通过图（Graph）的方式来定义和管理复杂的 AI 工作流，让开发者能够创建具有循环、条件分支和持久化状态的智能体系统。 LangGraph 的核心理念是将 AI 应用程序建模为状态机，其中节点代表操作步骤，边代表流程控制，状态在节点之间传递和更新。 核心概念 State（状态） State 是在整个工作流中传递和更新的数据结构。通常使用 TypedDict 定义： from typing import TypedDict, Annotated from langgraph.graph import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] user_input: str analysis_result: str Node（节点） Node 是执行具体操作的函数，接收当前状态并返回更新后的状态： def research_node(state: AgentState): # 执行研究任务 result = do_research(state['user_input']) return { "analysis_result": result, "messages": [("assistant", f"研究完成：{result}")] } Edge（边） Edge 定义节点之间的连接关系： Normal Edge（普通边）：直接连接两个节点 Conditional Edge（条件边）：根据状态决定下一个节点 from langgraph.graph import StateGraph, END # 普通边 workflow.add_edge("node_a", "node_b") # 条件边 def should_continue(state): if state['done']: return END return "continue_node" workflow.add_conditional_edges( "decision_node", should_continue ) Graph（图） Graph 是完整的工作流定义，包含所有节点、边和状态管理： from langgraph.graph import StateGraph workflow = StateGraph(AgentState) # 添加节点 workflow.add_node("research", research_node) workflow.add_node("analyze", analyze_node) workflow.add_node("respond", respond_node) # 定义边 workflow.add_edge("research", "analyze") workflow.add_edge("analyze", "respond") # 设置入口点 workflow.set_entry_point("research") # 编译图 app = workflow.compile() 核心特性 1. 状态持久化 LangGraph 支持状态的持久化存储，可以实现： ...

什么是 CrewAI CrewAI 是一个开源的 Python 框架，专门用于构建和管理多智能体（Multi-Agent）系统。它允许开发者创建一个由多个 AI 智能体组成的"团队"（Crew），这些智能体可以协同工作，共同完成复杂的任务。 核心概念 Agent（智能体） Agent 是 CrewAI 中的基本执行单元，代表一个具有特定角色和能力的 AI 助手。每个 Agent 具有： Role（角色）：定义 Agent 的身份和职责 Goal（目标）：Agent 要达成的目标 Backstory（背景故事）：为 Agent 提供上下文和个性 Tools（工具）：Agent 可以使用的工具集合 from crewai import Agent researcher = Agent( role='研究员', goal='收集和分析相关信息', backstory='你是一位经验丰富的研究专家，擅长从各种来源收集准确信息', tools=[search_tool, scrape_tool], verbose=True ) Task（任务） Task 定义了需要完成的具体工作，包括： Description（描述）：任务的详细说明 Agent：负责执行该任务的智能体 Expected Output（期望输出）：任务完成后的预期结果 from crewai import Task research_task = Task( description='研究 AI 领域的最新发展趋势', agent=researcher, expected_output='一份包含最新 AI 趋势的详细报告' ) Crew（团队） Crew 是多个 Agent 和 Task 的组合，负责协调整个工作流程： from crewai import Crew, Process crew = Crew( agents=[researcher, writer, reviewer], tasks=[research_task, write_task, review_task], process=Process.sequential # 顺序执行 ) result = crew.kickoff() 执行流程 CrewAI 支持两种执行流程： ...

Python 3.14 概述 Python 3.14 于 2025 年 10 月 7 日正式发布（当前最新版本：3.14.2，2025年12月5日），带来多项重大改进和新特性。这是 Python 发展历程中的重要里程碑，包括注解系统的重大变革、模板字符串、多解释器支持等令人期待的功能。 核心新特性 PEP 649 & PEP 749: 延迟注解求值 Python 3.14 最重大的变化！ 注解不再立即求值，而是存储在特殊的注解函数中，仅在需要时才求值。 关键改进： 大幅提升运行时性能（注解定义成本最小化） 不再需要使用字符串包裹前向引用 新增 annotationlib 模块用于处理注解 三种注解格式： from annotationlib import get_annotations, Format def func(arg: Undefined): pass # VALUE 格式：求值为运行时值 try: get_annotations(func, format=Format.VALUE) except NameError: print("会抛出 NameError") # FORWARDREF 格式：未定义的名称替换为特殊标记 print(get_annotations(func, format=Format.FORWARDREF)) # {'arg': ForwardRef('Undefined', owner=<function func>)} # STRING 格式：以字符串形式返回 print(get_annotations(func, format=Format.STRING)) # {'arg': 'Undefined'} PEP 734: 标准库中的多解释器支持 突破性功能！ 在同一进程中运行多个独立 Python 解释器的能力现已暴露给 Python 层。 ...

python timed task, 定时任务 while True sleep Timeloop threading.Timer sched schedule APScheduler Celery Apache Airflow while True: + sleep() 主要缺点： 只能设定间隔，不能指定具体的时间，比如每天早上8:00 sleep 是一个阻塞函数，也就是说 sleep 这一段时间，程序什么也不能操作。 Timeloop库 Timeloop是一个库，可用于运行多周期任务。这是一个简单的库，它使用decorator模式在线程中运行标记函数。 threading.Timer threading 模块中的 Timer 是一个非阻塞函数，比 sleep 稍好一点，timer最基本理解就是定时器，我们可以启动多个定时任务，这些定时器任务是异步执行，所以不存在等待顺序执行问题。 内置模块sched sched模块实现了一个通用事件调度器，在调度器类使用一个延迟函数等待特定的时间，执行任务。同时支持多线程应用程序，在每个任务执行后会立刻调用延时函数，以确保其他线程也能执行。 比threading.Timer更好，不需要循环调用。 调度模块schedule schedule是一个第三方轻量级的任务调度模块，可以按照秒，分，小时，日期或者自定义事件执行时间。schedule允许用户使用简单、人性化的语法以预定的时间间隔定期运行Python函数(或其它可调用函数)。 任务框架 APScheduler APScheduler（advanceded python scheduler）基于Quartz的一个Python定时任务框架，实现了Quartz的所有功能，使用起来十分方便。提供了基于日期、固定时间间隔以及crontab类型的任务，并且可以持久化任务。基于这些功能，我们可以很方便的实现一个Python定时任务系统。 它有以下三个特点： 类似于 Liunx Cron 的调度程序(可选的开始/结束时间) 基于时间间隔的执行调度(周期性调度，可选的开始/结束时间) 一次性执行任务(在设定的日期/时间运行一次任务) APScheduler有四种组成部分： 触发器(trigger) 包含调度逻辑，每一个作业有它自己的触发器，用于决定接下来哪一个作业会运行。除了他们自己初始配置意外，触发器完全是无状态的。 作业存储(job store) 存储被调度的作业，默认的作业存储是简单地把作业保存在内存中，其他的作业存储是将作业保存在数据库中。一个作业的数据讲在保存在持久化作业存储时被序列化，并在加载时被反序列化。调度器不能分享同一个作业存储。 执行器(executor) 处理作业的运行，他们通常通过在作业中提交制定的可调用对象到一个线程或者进城池来进行。当作业完成时，执行器将会通知调度器。 调度器(scheduler) 是其他的组成部分。你通常在应用只有一个调度器，应用的开发者通常不会直接处理作业存储、调度器和触发器，相反，调度器提供了处理这些的合适的接口。配置作业存储和执行器可以在调度器中完成，例如添加、修改和移除作业。通过配置executor、jobstore、trigger，使用线程池(ThreadPoolExecutor默认值20)或进程池(ProcessPoolExecutor 默认值5)并且默认最多3个(max_instances)任务实例同时运行，实现对job的增删改查等调度控制 分布式消息系统Celery Celery是一个简单，灵活，可靠的分布式系统，用于处理大量消息，同时为操作提供维护此类系统所需的工具, 也可用于任务调度。Celery 的配置比较麻烦，如果你只是需要一个轻量级的调度工具，Celery 不会是一个好选择。 数据流工具 Apache Airflow Apache Airflow 是Airbnb开源的一款数据流程工具，目前是Apache孵化项目。以非常灵活的方式来支持数据的ETL过程，同时还支持非常多的插件来完成诸如HDFS监控、邮件通知等功能。Airflow支持单机和分布式两种模式，支持Master-Slave模式，支持Mesos等资源调度，有非常好的扩展性。被大量公司采用。 ...