入坑 Agent 必看的20 个开源项目

在工作里，如果要让 Agent 协助处理一张售后工单，它可能要先查知识库和订单，再给出处理建议；如果还要改工单状态，就得按权限决定是否由员工确认。看起来是一件“让 Agent 处理工单”的事，拆开后却涉及资料检索、业务数据读取、流程编排和受控写入。每一层解决的问题不同，选工具前得先看清它在这条流程里负责哪一步。

今天，云朵君给大家分享 20 个 Agent 开源项目，按它们对应的工作任务逐个展开。项目名称链接到各自仓库，方便继续核验。

01构建 Agent 与编排流程

Pydantic AI

https://github.com/pydantic/pydantic-ai

Pydantic AI 对应 Python Agent 开发这一层，涉及类型化依赖、结构化输出校验、带审批的工具调用，以及用于可中断任务的 durable execution 集成。它处理的问题，是让模型生成的内容能以相对明确的格式进入普通应用代码，而不是让下游逻辑从一段自然语言里猜订单号、金额或下一步动作。

比如，售后 Agent 可以先生成包含订单编号和退款金额的结构化请求，再由单独的审批步骤决定是否执行。这里的 schema 校验只能确认输出形状是否符合约定；用户是否有资格退款、退款金额是否正确，仍要由业务规则判断。若考虑采用，需核对当前支持的执行引擎、审批接入方式和故障恢复语义，尤其不要把恢复流程误认为外部副作用必然只执行一次。

LangGraph

https://github.com/langchain-ai/langgraph

LangGraph 面向有状态 Agent 的低层编排，重点在图式流程、持久化和运行中的人工介入。

它适合被拿来讨论“任务跨多个步骤、分支或等待点时，应用如何记住目前走到哪一步”，而不只是让模型连续调用几个工具。

以文档审核为例，流程可能先汇集材料，再请求负责人审批，然后等审批结果返回后继续。把状态显式保留下来，有助于恢复时知道哪些步骤已完成、哪些动作还不能重复。不过流程恢复和业务动作幂等是两件事：重新进入节点时，邮件、付款或工单更新是否会重发，仍需在业务层设计和验证。它与 Pydantic AI 在部分场景有交集，选择前可先判断需求主要是 Python 应用内的类型化 Agent，还是多分支、有等待状态的流程编排。

02获取网页内容

Firecrawl

https://github.com/firecrawl/firecrawl

Firecrawl 主要处理“读取网页并整理内容”：它可以将网页转换为 Markdown 或结构化结果，开源项目与额外云端能力需要分开看。

它面向的是从网页取资料，而不是替 Agent 点击页面、登录账户或提交表单。

例如，研究助手要汇总几家供应商的产品规格，可以先抽取相关页面，再把字段交给后续流程比较。网页原文和链接最好一并保留：结构化结果看起来整齐，不代表抽取时没有漏掉价格条件、适用地区或例外说明。评估时需分别核对开源代码能做什么、托管服务增加了什么、页面内容如何保留，以及网站变化或请求失败由谁处理。

Crawl4AI

https://github.com/unclecode/crawl4ai

Crawl4AI 是更偏可控、自行运行的 Python 爬取选项，支持异步抓取、浏览器加载页面和多种内容抽取方式。它对应的工作通常是把一批已知网站或文档持续采集进自己的数据管线，而不是把抓取全交给一个托管接口。

比如团队每周更新内部知识索引时，可以限定允许访问的域名，按页面结构选择确定性解析；只有结构经常变化、规则难以覆盖的页面，再考虑模型辅助抽取。这样做带来控制权，也带来维护责任：网站改版、反爬限制、请求失败和清洗规则都要有人处理。准备自托管时，需核对当前依赖、浏览器运行方式、网络边界和实际维护成本。

03操作浏览器

Stagehand

https://github.com/browserbase/stagehand

Stagehand 将代码控制与模型辅助操作结合起来：固定步骤可以写成常规代码，页面结构变化或目标不固定时，再用自然语言指令定位元素或提取信息。它试图解决的不是“所有网页都交给模型”，而是让确定性步骤和需要判断的页面动作各有合适的控制方式。

例如，从供应商门户下载发票，访问固定地址和保存文件可以按脚本执行；若下载入口藏在经常变化的菜单里，再考虑语义化定位。下载完成后仍要用代码核对文件是否存在、归属是否正确。还要区分 Stagehand SDK 与 Browserbase 托管浏览器：自动化写法与浏览器运行在哪里是两项决策。评估时应检查当前自愈行为的边界、失败后的重试规则，以及托管环境的数据和凭据处理方式。

Browser Use

https://github.com/browser-use/browser-use

Browser Use 更偏任务导向的浏览器 Agent：当网站路径不固定时，Agent 可以根据目标决定如何浏览，并连接本地或云端浏览器。它与以固定脚本为主的自动化方式不同，重点在于让模型处理页面状态和导航选择。

需要区分三种不同的运行形态：自己运行开源库、使用托管浏览器但保留 Agent 代码，或调用托管 Agent API 让服务端运行整个 Agent。它们的数据流、凭据位置和运维责任并不相同。假设 Agent 帮用户预订行程，到达确认页面和按下最终提交按钮应当是不同步骤；后者可能产生外部影响，需按产品规则安排授权。还要检查每个用户的浏览器会话是否隔离，不能因为共用登录状态方便就让一个用户接触另一个用户的数据。

04隔离代码执行

E2B

https://github.com/e2b-dev/E2B

E2B 提供运行 Agent 生成代码的隔离环境，相关资料列出 Python、JavaScript SDK 和通过 Terraform 自托管的路径。

它解决的是“代码应该在哪里执行、怎样与主应用的凭据和运行环境隔开”，而非代码结果是否正确。

例如，用户上传表格后，Agent 可以在独立环境里写代码做清洗或生成图表，再由应用取回产物。隔离环境可以降低任意代码直接接触应用服务器的风险，但仍要决定网络是否开放、运行时长和资源上限、凭据能否进入环境，以及任务结束后怎样清理。其中云端服务和自托管说明以 2026 年 10 月 3 日的资料为限；真正选型前要确认当前部署选项、底层隔离强度和适用的安全边界。

OpenSandbox

https://github.com/opensandbox-group/OpenSandbox OpenSandbox 面向自有基础设施提供沙箱接口，支持本地 Docker 与 Kubernetes 部署，使用方向包括代码、浏览器或桌面环境，也可以按沙箱配置出站网络策略。它的价值在于让不同任务环境通过较统一的接口管理，而不是给所有 Agent 配同一个随意开放的执行容器。

如果平台团队已经维护 Kubernetes，可以设想把编码任务和浏览器任务放进不同镜像，再统一管理生命周期和网络访问。需要注意，统一 API 不会自动提供统一的隔离强度：容器配置和更强隔离运行时不能混为一谈。应根据可能执行的代码、可访问的数据和网络目标来选运行时，并单独验证边界；任务成功率不能代替隔离验证。

05保存与检索上下文

Mem0

https://github.com/mem0ai/mem0

Mem0 是跨轮次保存和检索相关信息的记忆层，相关资料区分了开源库、自托管服务与托管平台。

它主要解决“下次交互时是否需要找回一小部分上下文”，而不是替应用保存所有权威业务数据。

例如，客服助手可以记住用户更愿意通过邮件联系，减少每次重复询问；但“订阅已经取消”这类账户状态仍需回到账单系统核实。记忆里可能同时有用户请求、模型推断和已经完成的动作，应用需要区分这些信息的来源与可信程度。相关基准表针对托管平台，不能直接套用到开源部署。若考虑使用，应在自己的记忆类型和检索任务上评估，并核对数据保存、删除和托管边界。

Graphiti

https://github.com/getzep/graphiti

Graphiti 面向会随时间变化的关系构建上下文图：除保存实体间关系外，还记录事实何时成立及其来源，新信息可以更新当前关系，同时保留被替代信息的历史。它关注的是“同一事实随时间变化后，回答时怎样找对时间点”，与单纯按语义相似度找记忆的任务有所不同。

比如，客户公司的采购联系人发生变更，系统若只找到“采购联系人”相关记录，可能同时取回旧联系人和新联系人。需要追溯历史订单时应看到当时的联系人；准备新的沟通时则应使用当前信息。开源 Graphiti 与 Zep 托管服务需要区分；实际采用还要核对存储、更新、来源追踪和过期事实处理由哪些组件负责。

06接入工具与管理权限

FastMCP

https://github.com/PrefectHQ/fastmcp

FastMCP 是构建 MCP 服务端和客户端的 Python 框架。MCP 提供 Agent 发现和调用工具的接口；FastMCP 则让应用把已有函数包装成相对清晰的工具调用。它适合从一个边界窄、输入输出容易检查的操作开始，而不是一上来就暴露整个数据库。

例如，先提供“查询订单物流状态”，只返回完成任务所需的字段。读取订单和修改收货地址应当是不同操作，修改动作还要在实际执行它的服务端进行身份和权限校验。把函数注册成 MCP 工具，只解决了 Agent 能否发现和调用它；谁可以对哪条记录做什么，仍由业务授权规则决定。核对时要看当前 SDK 能力、身份传递方式和服务端权限在哪里生效。

ToolHive

https://github.com/stacklok/toolhive

ToolHive 负责 MCP 服务的运行与管理，支持隔离运行、发现和管理工具服务器；如果接入身份来源，还可配置按请求执行身份和访问策略，并支持可观测性及 Kubernetes 部署。与负责写一个 MCP 工具的库相比，它讨论的是团队如何管理一组共享服务。

例如，多团队共用工具时，可以集中登记哪些服务器允许部署、每个服务器能访问什么资源，以及请求来自哪个身份。否则个人电脑上临时添加的集成，可能悄悄形成通往敏感数据的新通道。即便有统一管理层，每个工具本身仍需验证具体用户是否能修改对应记录。实施前要确认隔离方式、身份源配置、策略实际覆盖的请求路径和日志中的敏感信息处理。

OpenFGA

https://github.com/openfga/openfga

OpenFGA 是细粒度授权引擎，可对权限关系建模并回答某个用户是否能访问特定资源或执行特定操作。它不只面向 Agent；当应用里的权限关系逐渐复杂，想把“谁能做什么”从散落的条件语句中集中管理时，可以评估这一层。

比如文档助手准备把某份文档交给模型之前，应以发起请求的用户身份检查这份文档是否可读。一个系统级搜索凭据不应让所有用户的助手都获得管理员权限。OpenFGA 解决的是授权判断，不会自动提供用户认证、OAuth 连接或令牌刷新；应用也必须在正确的动作前调用检查。需要核对授权模型怎样表达资源关系，以及服务端哪些入口强制执行检查。

07路由模型与控制支出

LiteLLM

https://github.com/BerriAI/litellm

LiteLLM 是连接多个模型服务的统一网关，提供路由、预算和虚拟密钥等控制方式。它可以让应用集中处理请求发往哪个模型服务、哪些团队或 Agent 使用哪组凭据，而不必把所有供应商密钥散落在业务代码里。部分能力可能与企业版本有关，具体范围需再查。

假设信息抽取任务对模型能力要求较低，而复杂分析任务需要更强模型，团队可以按任务设路由，再观察费用和失败情况。统一接口不代表不同模型行为等价：切换后工具参数、格式和拒绝行为都可能变化。备用路由也要用真实任务验证，特别是会触发外部动作的调用；请求返回成功，不一定表示业务语义保持不变。

08追踪与评测

Langfuse

https://github.com/langfuse/langfuse

Langfuse 用于追踪和评估 Agent 运行，可以记录模型调用和应用步骤，并把可观测数据与数据集、评测流程连接起来。

它适合回答“用户请求到最终动作之间发生了什么”，尤其是最后结果本身不足以解释错误时。

例如，助手选错客户账户，仅看最后一句回复很难判断是检索阶段拿错记录，还是模型看到了正确资料却选择了错误工具。运行追踪能给排查提供线索，但也可能保存提示词、文档和个人信息。上线前要决定记录哪些字段、如何脱敏、保留多久和谁能查看。许可证划分也以 2026 年 10 月 3 日的资料为限，当前开源目录和企业组件边界需再确认。

Promptfoo

https://github.com/promptfoo/promptfoo

Promptfoo 可在本地或 CI 中运行，支持用声明式配置比较模型和提示词、通过断言检查行为，以及开展红队测试。它适合把已发现的失败方式整理成可重复检查，避免只凭一条看起来不错的回答判断系统质量。

比如检索到的文档里藏有越权指令，Agent 不应因此调用敏感工具。团队可以保存这类输入，并对“不调用该工具”写确定性断言；提示词或模型路线变更后再重复跑。语义判断可以交给模型评审辅助，但如果要检查的是是否发生未经授权的写入，明确断言往往更直接。需根据当前版本核对测试格式、执行环境和评审器的局限。

DeepEval

https://github.com/confident-ai/deepeval

DeepEval 是偏代码驱动的评测框架，既能检查完整 Agent 运行，也能检查其中的步骤；适用方向包括工具正确性、任务完成、检索和对话评估。它可能适合希望把 Agent 评测放进 Python 自动化测试流程的团队。

以预约助手为例，不应只检查最后是否说“已经订好”，还要核对它使用了正确日历、预约时间与用户确认一致。否则语言上完成任务，实际操作却可能出错。DeepEval 与 Promptfoo 存在重叠，是否两者都需要应由团队现有测试流程决定。对模型评审指标也应使用人工判定过的样例做校准，因为评测器本身同样会误判。

09实时语音交互

Pipecat

https://github.com/pipecat-ai/pipecat

Pipecat 是实时语音和多模态 Agent 的 Python 框架，负责协调语音服务、模型调用与传输层。它面向的是需要边听边回应的交互，而不是把语音消息简单转成文本后再按普通问答处理。对话的时序、打断和交接都会影响体验。

例如，来电者中途更正订单号时，系统应能停止当前播报并按新信息继续；如果语音服务延迟很久，也应让用户知道系统还在处理，必要时转人工。它可以集成 Telnyx、Twilio 等传输，但电话连接仍依赖单独的运营商或服务。实际评估时要检查端到端延迟、打断处理、断线恢复和人工接管，并把电话账户与开源框架分别核算。

LiveKit Agents

https://github.com/livekit/agents

LiveKit Agents 是实时会话中的可编程参与者，涉及任务调度、电话能力和语义轮次检测等方向。

它所处的位置与单一语音模型不同：除了理解和生成语音，还要和实时通信会话、任务生命周期及产品应用配合。

如果一个产品希望同一套对话流程覆盖网页、移动端和电话，可以评估 Agent 如何加入会话、状态如何同步以及电话呼入呼出由哪一层承担。LiveKit Cloud 是独立的托管选择，框架与模型可能有不同许可条件；这些信息都需要按当前仓库和服务条款重新核验。它与 Pipecat 在部分传输层有交集，因此比较时应选一条代表性通话流程，检查打断、预约变更和转人工，而不是只比一段顺畅的问候。

10支付

Stripe Link CLI

https://github.com/stripe/link-cli

Stripe Link CLI 可让 Agent 发起普通线上购买：它从 Link 钱包获取一次性支付凭据，也可以作为本地 MCP 服务供 Agent 调用。支付与一般工具调用不同，最终动作会产生财务影响，因此流程应把“找商品、准备订单”和“授权扣款”分开。

例如，采购助手可以准备好替换设备的订单，但付款前要让用户确认商户和最终金额。如果页面金额与已批准金额不同，应停止等待再次确认，而不是让模型自行判断差额是否合理。凭据即便是一次性的也仍然敏感，需避免进入模型上下文和普通调试日志；凭据输出处理方式、Link 服务依赖和账户适用范围都需重新检查。2026 年 10 月 3 日资料中提到的地区限制不能直接当作当前结论。

11写在最后

这 20 个项目覆盖的是不同问题域：编排流程、读取网页、操作浏览器、隔离执行、保存上下文、管理工具和授权、控制模型请求、追踪评测、语音交互，以及支付。它们可以帮助建立一张检查清单，但项目名称本身不能证明当前版本适合某个工作流。

具体评估时，回到售后工单流程逐项确认：缺什么能力、失败代价多大、数据访问范围是什么、谁来审批、如何追踪，以及怎样停用或替换。之后再到各项目的官方仓库和文档核对版本、许可证、部署方式、数据流与权限模型。本文整理的项目资料截至 2026 年 10 月 3 日，未做当前验证或横向测试；需要作工程决策时，应先核对官方最新说明，再用自己的代表性任务验证。