现在对技术栈了解得更多，所以是时候进行一次正式的更新了。这个版本将列表扩展到 20 个项目，并且不再只关注编程智能体，而是进一步考察有用的智能体产品背后的基础设施。

我尤其感兴趣的是，当一个智能体离开聊天窗口后会发生什么。研究助手需要浏览为人类构建的网站。客户助手需要记住哪个问题实际上已经被解决，而语音智能体需要在有人打断它时停止说话。这些都是不同的工程问题，而选择一个更昂贵的模型并不能消除它们。

下面这些项目是我会针对这些工作进行调研的项目。其中有几个是彼此的替代方案，所以请不要把这理解为一份包含二十个新依赖的采购清单。开源项目和它的商业服务也是两个不同的决策。浏览器库可能是开源的，而托管浏览器可能需要付费；同样的区别也存在于记忆和语音基础设施中。

构建智能体

1. Pydantic AI

Pydantic AI 是我在构建需要集成到现有应用中的 Python 智能体时会首先考虑的项目。它的类型化依赖和经过验证的输出，为智能体与普通应用代码之间提供了清晰边界。它还支持需要在中断后继续运行的工作流所需的审批门控工具和持久执行集成。

设想一个准备退款的助手。我希望结果包含一个订单标识符和一个符合定义 schema 的金额，然后在实际付款前进入一个单独的审批步骤。一段说明退款可能合理的文字，并不是应用契约。Pydantic AI 让这种结构化设计变得自然，同时把实际退款策略留在我可以测试的代码中。

对于已经熟悉 Python 类型和依赖注入的团队来说，这是一个很好的选择。验证可以捕获格式错误的输出；检查客户是否有资格获得退款仍然是一个单独的责任。这是在智能体获得更多工具之前值得建立的边界。

2. LangGraph

当工作流本身变得复杂时，LangGraph 就有了它的位置。它为有状态智能体提供低层级编排，包括持久化和执行期间的人工介入。它的图结构让开发者能够明确控制工作如何在步骤之间流转。

考虑一个文档审核智能体：它收集证据、请求审批，然后等到明天再获取答案。我希望应用知道它准确到达了哪个阶段。我也希望在恢复之前检查已保存的状态，而不是让一个新的模型会话根据转录内容重建工作流。

Pydantic AI 和 LangGraph 有重叠，我通常会从其中一个开始。我的偏好取决于问题：Python 应用中的类型化智能体行为会让我倾向于 Pydantic AI；复杂的分支流程则让 LangGraph 特别值得考虑。两者都不能消除让外部操作可安全重试的需求。恢复后的工作流绝不能把同一张发票发送两次。

读取 Web

3. Firecrawl

Firecrawl 将网页转换为智能体可以消费的材料，包括 Markdown 和结构化抽取。当任务是理解页面而不是操作其界面时，这很有用。该仓库采用 AGPL-3.0 许可证，其文档区分了开源项目和额外的云能力。

对于一个比较供应商文档的研究智能体，我会先抽取相关页面并保留它们的 URL。让智能体以视觉方式浏览每个段落，会给一个主要是信息问题的任务增加浏览器交互问题。结构化抽取也为下一步提供了可以一致验证的内容。

把抓取到的页面与抽取出的字段一起保存是值得占用存储空间的，尤其是对于价格或产品限制。抽取可能会遗漏会改变答案的限定条件。智能体应该能够回到它的证据，而不是把一个整洁的 JSON 对象当作每个字段都正确的证明。

4. Crawl4AI

当我希望在自己的 Python 环境中对爬取有更多控制时，Crawl4AI 是我会考察的替代方案。它支持异步爬取、基于浏览器的页面加载，以及多种抽取方法。它的 Apache-2.0 代码可以直接放入数据管道中，而不要求应用调用托管爬取服务。

一个周期性的文档摄取任务就是很好的例子。我可能知道允许访问的域名和需要刷新的页面，并且希望控制在索引之前如何清洗它们的内容。Crawl4AI 为这项工作提供了一个可编程的落点。稳定的页面结构可以使用确定性抽取，把基于模型的抽取留给结构确实变化的场景。

运行爬虫仍然意味着要负责失败请求以及被读取网站的变化。对我来说，吸引力在于对管道的控制。自托管仍然必须证明其总体成本是合理的。维护账单不仅以计算资源的形式到来，也会以工程时间的形式到来。

在浏览器中工作

5. Stagehand

Stagehand 是我在浏览器工作流方面的候选项目，当我希望把普通代码和模型引导的动作结合起来时会考虑它。它将熟悉的 Playwright 风格操作与用于在页面上执行操作和抽取信息的自然语言原语结合在一起。该项目还提供了自愈动作，旨在当页面结构发生变化时进行恢复。

假设一个智能体需要从供应商门户下载发票。导航到已知 URL 可以保持确定性。定位隐藏在变化菜单背后的发票，可能会受益于语义指令，随后普通代码可以检查下载的文件。我不希望模型在每次任务运行时都重新发现每个稳定步骤。

Stagehand 是 MIT 许可的 SDK；Browserbase 是相关的托管浏览器选项。我会把托管决策与自动化设计分开。租用浏览器解决的是在某处运行浏览器的问题，而成功取回发票仍然需要我的应用进行显式检查。

6. Browser Use

当通过网站的路线不太可预测时，Browser Use 是我会考虑的更偏任务导向的选项。它的开源智能体库可以使用选定的模型，并连接到本地或云浏览器。这使它适用于智能体必须决定如何导航，而不是遵循基本预定义脚本的工作流。

Browser Use 仓库明确区分了它的库、托管浏览器和完全托管的智能体 API。使用云浏览器时，我仍然可以拥有智能体代码。使用托管智能体 API 时，服务也会运行智能体。即使两者在随意描述时都被称为浏览器自动化，它们也是实质上不同的部署选择。

我会尝试用 Browser Use 在陌生门户中查找信息，然后把结果约束到清晰的契约中。对于一个准备预订的智能体，到达确认页面应该是一个独立阶段，不能与按下最终按钮混在一起。每个用户还需要隔离的浏览器会话。一个方便的共享登录，是多用户产品的糟糕基础。

隔离代码执行

7. E2B

E2B 提供用于运行智能体生成代码的隔离云环境，可通过 Python 或 JavaScript SDK 控制。它的仓库还通过 Terraform 记录了自托管方式，并列出了 AWS 和 Google Cloud 作为受支持的提供商。这比假设任何开源 sandbox 都能在一台闲置笔记本上原样运行，是一个更具体的部署主张。

数据分析助手是一个显而易见的用例。用户上传电子表格，智能体编写代码进行检查，应用取回生成的图表或清洗后的文件。我希望这些代码运行在远离应用服务器凭据的地方，并且运行环境可以在任务结束后被丢弃。

独立环境也适用于并行编码 worker。每个 worker 都可以拥有自己的代码 checkout 和依赖，而不是在同一个工作目录中竞争。这些环境仍然需要资源限制和有意配置的网络访问。隔离降低了执行可能造成的损害；但它不会决定智能体应该被允许联系哪些外部服务。

8. OpenSandbox

当需求是在自己的基础设施上运行智能体环境时，OpenSandbox 值得考察。它在本地 Docker 和 Kubernetes 部署之上暴露统一的 sandbox API，并提供了覆盖代码执行以及浏览器或桌面环境的示例。这个 Apache-2.0 项目还支持按 sandbox 配置出站网络策略。

我喜欢这个选项用于已经运行 Kubernetes，并希望智能体工作负载适配其部署模型的团队。编码任务和浏览器任务可以使用不同的环境镜像，而应用通过同一个 sandbox 接口管理它们。这给平台团队提供了一个标准化生命周期和访问控制的位置。

所选 runtime 仍然决定了隔离强度。一个基本的容器部署不应被随意等同于加固过的 microVM 配置。我会在决定系统可能遇到什么敌意代码之后再选择 runtime，然后独立测试这个边界，而不是只看智能体是否完成了任务。

记住有用上下文

9. Mem0

Mem0 值得在这个列表中占据一个正式位置，因为持久上下文会改变智能体产品能做什么。它提供了一个记忆层，用于跨交互保留和检索相关信息，同时提供开源库和自托管服务器，以及托管平台。核心仓库采用 Apache-2.0 许可证。

客户助手不应需要用户每天早上都解释同一个未解决问题。我会使用记忆层保留相关偏好和之前的决策，然后检索当前对话所需的少量信息。这比盲目地把整个对话历史附加到每次模型调用上更有用。

权威账户数据属于应用的数据库。记忆可以帮助回忆某个客户偏好 email，但一个记住的“订阅已取消”的说法应该通过计费系统核对。这一区分也产生了有用的测试：智能体能否区分已经完成的操作和仅仅讨论过的请求？

Mem0 发布的 benchmark 表明确涉及其托管平台，包括专有优化。我不会把这些分数转移到开源部署上。需要在产品实际依赖的记忆类型上评估本地版本。

10. Graphiti

当事实之间的关系，以及这些事实成立的时间，会影响答案时，Graphiti 就变得有趣了。它构建带有可追溯到源材料 provenance 的时间上下文图。新信息可以更新图，同时保留被取代事实的历史。

设想一个账户助手正在处理一位客户，而该客户公司的采购联系人已经发生变化。扁平的记忆搜索可能会同时检索到前任联系人和现任联系人，因为二者在语义上都相关。我希望助手理解在某次采购发生时谁担任该角色，以及下一条消息应该发送给谁。Graphiti 的时间模型正是为这种不断演化的上下文而设计的。

对于直接的偏好回忆，Mem0 是我的起点；当不断变化的关系主导问题时，Graphiti 会让我感兴趣。Graphiti 不同于 Zep 的托管服务：运行开源引擎意味着你需要自己提供周边存储和应用机制。

*喜欢这篇文章吗？鼓掌、保存或评论都会真的帮到我。感谢阅读。*

工具和权限

11. FastMCP

FastMCP 提供了一个用于构建 MCP servers 和 clients 的 Python framework。MCP 为智能体提供了一种一致的方式来发现工具并调用它们，而 FastMCP 让暴露普通应用函数变得相对直接。它的代码采用 Apache-2.0 许可证。

像检查订单配送状态这样范围较窄的操作，是一个很好的起点。server 可以验证请求，并只返回相关字段。这比一个通用数据库凭据加上一条“请谨慎行事”的指令要容易审查得多。

好的工具设计应该让被允许的操作显而易见。读取订单和更改其目的地应该是分开的操作，并且在执行更改的服务内部进行授权检查。通过 MCP 发布一个函数会让智能体可以访问它；业务规则仍然需要存在于某个可执行约束的位置。

12. ToolHive

ToolHive 处理 MCP 的运维侧。它在隔离容器中运行 servers，并提供一个更广泛的平台用于发现和管理它们。当配置了身份认证来源时，它可以按请求执行身份和访问策略，并支持可观测性和 Kubernetes 部署。

当团队已经超越了少数个人配置工具的阶段时，就有理由考察这一层。共享 registry 可以定义哪些 servers 已获批准，而部署策略决定每个 server 可以访问什么。员工安装一个有用的集成，不应该悄悄为敏感公司数据创建一条新路径。

因此，FastMCP 和 ToolHive 在我的技术栈中服务于不同目的。FastMCP 是我会编写内部工具的地方；ToolHive 是我会在团队范围内管理访问权限的地方。两者都不会移除工具自身检查特定用户是否可以更改特定记录的责任。

13. OpenFGA

OpenFGA 是这里最不像“智能体品牌”的项目，而这正是它吸引人的一部分。它是一个用于建模和检查权限的开源细粒度授权引擎。智能体应用可以在返回文档或允许工具对文档执行操作之前使用这些检查。

Authentication 确定调用者是谁。Authorization 决定该身份可以做什么。对于文档助手，我会在文档内容进入模型上下文之前，代表请求用户检查其对特定文档的访问权限。一个系统级搜索凭据不应该把每个用户的助手都变成管理员。

OpenFGA 并不提供人们归入 agent auth 的所有其他部分。OAuth 连接和 token refresh 仍然需要身份或集成层，而应用必须在正确的节点调用权限检查。当权限关系复杂到无法作为分散的条件语句维护时，它就值得引入额外基础设施。

控制模型支出

14. LiteLLM

LiteLLM 为应用提供了一个通往多个模型提供商的通用 gateway，并带有 routing 和 spending controls。它的 proxy 支持 virtual keys 和 budgets，因此不同的智能体或团队可以获得受控访问，而不需要每个组件都管理底层 provider credentials。一些能力位于单独的 enterprise tier 中。

对我来说，一旦模型选择变成运维决策，它就有了位置。后台抽取任务可能使用更便宜的路线，而困难的推理任务可以访问更昂贵的路线。集中这些选择，可以更容易地检查支出并更改路线，而无需编辑每个智能体集成。

Fallbacks 需要针对应用的实际工具调用进行测试。兼容的请求格式并不保证替代模型具有等价行为。一个 fallback 成功响应但改变了工具参数的含义，就相当于维持了 API 可用，却破坏了工作流。

评估真实行为

15. Langfuse

Langfuse 为智能体执行提供了可检查的 trace。它的开源平台记录模型调用和应用步骤，并将这种可观测性连接到 datasets 和 evaluation workflows。核心采用 MIT 许可证，而其 enterprise 目录使用单独条款。

我希望看到从用户请求到最终动作的路径。当助手选择了错误账户时，最终答案可能告诉我的信息非常有限。trace 可以显示检索到了哪条记录，以及模型在选择工具之前接收了什么。这为调查提供了具体的起点。

在启用大范围 tracing 之前，需要先决定如何做 redaction。一个有用的调试界面也可能变成另一个保存敏感 prompts 和文档的数据库。我希望保留足够的证据来解释失败，并且对存储的每一项内容都有理由。

16. Promptfoo

当我想要一个可以在本地或 CI 中运行的可重复 suite 时，Promptfoo 是我会选择的 evaluation tool。它的声明式配置支持跨模型和 prompt 的比较，而 assertions 和 red-team testing 有助于检查超越“答案听起来是否合理”的行为。该开源项目采用 MIT 许可证。

假设一个支持智能体遵循了检索文档中隐藏的指令。我会保留这个案例，并断言该智能体绝不能调用敏感工具。然后，当 system prompt 变化或有人添加新的模型路线时，这个测试可以运行。一个已知失败会变成发布检查，而不是团队聊天里的一则轶事。

测试 suite 受益于将语义检查和确定性检查结合起来。model judge 可以帮助评估解释质量，但当问题是是否发生了未授权操作时，精确 assertion 更可取。当团队希望这些比较与其他配置和测试放在一起时，Promptfoo 特别有用。

17. DeepEval

DeepEval 是我会研究的 framework，用于以代码驱动的方式评估完整智能体运行及其单个步骤。它提供了 tool correctness 和 task completion 指标，以及 retrieval 和 conversational evaluation。它的 Python 测试工作流很自然地适合已经使用自动化测试的团队。

对于一个预约预订智能体，我会评估的不只是最终句子。运行过程应该使用预期的日历，并生成与批准时间匹配的预订。当底层操作错误时，一条自信地表示一切已安排妥当的消息应该失败。

DeepEval 和 Promptfoo 有重叠，所以我会根据团队工作流进行选择，而不是自动安装两者。任何基于模型的 judge 都需要用人工审查过的示例进行校准。评估分数是另一个系统产生的测量值，也有其自身的失败模式；我想知道这个测量是否能跟踪用户实际遇到的错误。

赋予智能体语音

18. Pipecat

Pipecat 是一个用于实时语音和多模态智能体的开源 Python framework。它协调跨 speech services 和模型调用的对话 pipeline，并提供包括 Telnyx 和 Twilio serializers 在内的 transport integrations。当产品需要说和听，而不是交换文本消息时，它是我会考察的软件层。

语音智能体必须把时序作为交互的一部分来处理。当来电者打断时，我希望智能体停止说话，并将纠正内容纳入考虑。缓慢的服务不应该让来电者怀疑线路是否已经断开。选择一个好听的声音只是把这种体验做好的很小一部分。

真实电话还需要连接到 telephony provider。Pipecat 记录了通过 media streaming 的 Telnyx 集成，而它的仓库也列出了 Twilio 支持。运营商账户和电话连接仍然独立于开源 framework。我会从一个范围较窄的 inbound workflow 开始，例如回答服务问题，并把未解决的电话转接给人工。

19. LiveKit Agents

LiveKit Agents 是我会列入候选的另一个语音项目。它把实时智能体构建为 LiveKit sessions 中的可编程参与者，并集成了 job scheduling 以及用于呼入和呼出电话的 telephony stack。该 framework 还支持 semantic turn detection，用于帮助判断说话者何时结束发言。

当同一个对话需要跨 Web 应用、移动客户端和电话连接运行时，LiveKit 尤其让我感兴趣。智能体作为实时通信系统中的参与者，而应用则处理该 session 周围的产品工作流。

Pipecat 和 LiveKit Agents 在智能体 framework 层是替代方案，尽管 Pipecat 也可以使用 LiveKit 作为 transport。我会用产品预计会接到的真实电话来比较它们。一次被打断的预约变更，比一段完美脚本化的问候更能说明问题。Agents framework 采用 Apache-2.0 许可证，而其 turn-detection models 有单独的 model license。LiveKit Cloud 是一个单独的托管选择。

让智能体付款

20. Stripe Link CLI

Stripe 的 Link CLI 是一个采用 MIT 许可证的工具，适用于需要完成普通在线购买的智能体。它从 Link wallet 获取一次性支付凭据，包括用于标准 checkout forms 的 virtual cards。该 CLI 也可以作为本地 MCP server 运行，因此智能体可以请求付款，而无需存储客户的底层卡号。

对于采购助手，我会把选择产品和授权付款分开。智能体可以找到替代笔记本充电器并准备订单，但我会要求在 checkout 之前批准商家和最终金额。Link 的显式审批流程会通过 Link app 向用户发送请求。然后，我的应用会检查订单确认信息，再将购买视为完成或尝试另一笔付款。

生成的 virtual card 仍然是支付凭据。Link CLI 可以将卡片详情写入受限本地文件，同时保持其正常输出经过 redaction；我会使用这一路径，避免卡号进入模型的对话历史和调试 trace。只有 checkout 组件应该需要这些详情。当商家更改已批准总额时，应用也应该停止，而不是询问模型差异是否看起来合理。

开源客户端仍然依赖 Stripe 的托管 Link 服务，而且目前访问仅限于美国 Link accounts。这一地域限制使它现在不适合作为面向全球受众的默认支付功能。对于符合条件的部署，我会先从 CLI 的 test mode 和显式购买审批开始，然后再考虑任何委托支出。支付集成应该比智能体的浏览能力更窄。

从一个工作流开始

二十个项目作为可用基础设施地图是有用的。把它们作为起始架构则会相当痛苦。我会选择一个有价值的工作流，定义它可以采取的动作，然后添加可靠完成和评估该工作流所需的组件。

对于文档助手，我会先建立具有权限感知的 retrieval 和 evaluation set，再添加浏览器自主性。对于语音产品，我会优先处理一个范围较窄、可以干净转接的对话，然后再教它进行付款。记忆应该用在连续性能够改善产品的地方，并为它可以记住什么、什么必须通过权威数据核对制定明确规则。

第一个版本应该让我能够解释一次失败运行，并在不请求模型许可的情况下阻止危险操作。一旦这一点可行，扩展智能体的责任范围就会成为更合理的工程决策。

*我是 Caspar Bannink，一名独立技术创始人，正在构建 HomeScout——一款 AI 驱动的租赁工作流产品。我在 CasparAI on Medium 和 LinkedIn 上撰写关于 AI models、agents 以及其背后系统的内容。*

来源

Pydantic AI：类型化智能体、审批门控工具和持久执行集成。

LangGraph：有状态编排、持久化和人工介入。

Firecrawl：Web 抽取以及开源能力与云能力的区别。

Crawl4AI：异步爬取、抽取和自托管运行。

Stagehand：浏览器自动化 SDK 和模型引导动作。

Browser Use：开源库、托管浏览器和托管智能体。

E2B：代码 sandboxes、SDKs 和受支持的自托管部署。

OpenSandbox：Docker 和 Kubernetes sandbox 基础设施及网络策略。

Mem0：智能体记忆以及托管平台 benchmarks 的适用范围。

Graphiti：时间上下文图及其与 Zep 的关系。

FastMCP：Python MCP servers 和 clients。

ToolHive：MCP 部署、身份策略和 server 管理。

OpenFGA：细粒度授权建模和权限检查。

LiteLLM：模型 gateway、virtual keys、routing 和 budgets。

Langfuse：Tracing、datasets、evaluations 和许可边界。

Langfuse brand assets：官方项目符号和使用指南。

Promptfoo：声明式 evaluations、assertions 和 red-team testing。

DeepEval：智能体轨迹、任务和工具评估。

Pipecat：实时语音 pipelines 和受支持的 transports。

Pipecat Telnyx integration：Telephony media streaming 和连接要求。

LiveKit Agents：实时智能体、telephony 以及独立的 framework 和 model licenses。

LiveKit brand assets：官方符号和品牌指南。

Stripe Link CLI：一次性卡片凭据、审批流程、凭据处理、test mode 和美国账户可用性。