> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 7个AI工程必备Python库
- URL: https://www.hubwiz.com/blog/top7-python-libraries-for-ai-engineering/
- Published: 2026-02-19T02:51:27.000Z
- Updated: 2026-02-19T02:51:27.000Z
- Description: 本文介绍了7个Python库，它们取代了作者所有AI工程中的样板代码。
- Author: admin
- Tags: LIBRARY, #Import 2026-10-14 14:41

本文介绍了7个Python库，它们取代了作者所有AI工程中的样板代码。每个库都遵循相同的模式：一个需要手动解决的问题，一个用几行代码解决它的库，以及README中没有提到的诚实限制。

## 1、LiteLLM：一个适用于每个LLM提供商的接口

**问题：** 你想测试 GPT-4 vs Claude vs Llama。所以你编写了三个独立的客户端配置、三个响应解析器和三个错误处理器。

LiteLLM 为所有LLM提供商提供统一接口。只需更改模型名称字符串即可在不同提供商之间切换。

作者在上季度进行了成本比较：在 GPT-4、Claude Sonnet 和 Llama 3 70B 上运行相同的工作负载。差异是每月847美元。没有 LiteLLM，测试那需要一个星期的重构。

**替换：** 3个独立的SDK集成和一个成本跟踪电子表格。

**诚实限制：** 当提供商更改其API时，你需要等待LiteLLM更新。对于关键任务的生产环境，一些团队仍然更喜欢直接使用SDK。

## 2、Instructor：实际工作的结构化输出

**问题：** 你要求LLM提供JSON。你得到的是用markdown反引号包裹的JSON。或者带有额外字段的JSON。或者一个看起来像JSON但带有尾随逗号的字符串。

Instructor 通过Pydantic模型确保结构化输出，无需手动解析或处理边界情况。

在 Instructor 之前，作者有一个包含12个边界情况的 `parse_llm_json()` 函数。它仍然在生产数据上每周失败一次。上面的嵌套提取（复杂对象的验证列表）是 Instructor 真正领先的地方。尝试使用 regex 和 json.loads() 做到这一点。

**替换：** 带有手动验证的150行JSON解析函数。

**诚实限制：** 增加延迟。当模型的第一次尝试不通过验证时，Instructor 有时需要重试循环。对于高吞吐量管道，需要测量开销。

## 3、MarkItDown：将任何文档转换为LLM就绪文本

**问题：** 你的RAG管道需要摄取PDF、Word文档、PowerPoint和Excel文件。所以你安装了用于PDF的pdfminer、用于Word的python-docx、用于幻灯片的python-pptx和用于电子表格的pandas。四个库。四个解析管道。四组边界情况。

MarkItDown 是微软构建的（86K GitHub星标），可以将任何文档转换为干净的Markdown。它保留了标题、表格和列表作为Markdown。

当作者为内部知识库构建文档问答系统时，摄取管道占代码库的40%。MarkItDown 会将其减少到几行。

**替换：** 使用4个独立解析库的自定义提取管道。

**诚实限制：** PDF提取仅限文本层。没有OCR的扫描图像不返回任何内容。PDF中的表格提取也不一致，因此需要验证任何财务或大量表格的内容。

## 4、FastMCP：在几分钟内构建MCP服务器

**问题：** 模型上下文协议 (MCP) 正成为给LLM提供访问外部工具和数据的标准。但从头开始构建合规的MCP服务器意味着数百行的传输处理、模式定义和协议样板代码。作者写过关于[MCP的安全模型需要审查](link-mcp-security)的文章，但即使抛开安全问题不谈，实现负担也是真实的。

FastMCP 使用装饰器模式让你在几行代码中构建完整的MCP服务器。原型化一个内部搜索索引的工具服务器大约需要20分钟。作者开始编写的原始MCP版本有200行，仍然没有处理传输。

**替换：** 200多行协议样板代码。

**诚实限制：** FastMCP 仍然很年轻（22K星标且在增长）。如果你的堆栈不支持MCP，这没有帮助。你仍然需要仔细考虑[你暴露的内容](link-mcp-security)。

## 5、PydanticAI：没有框架税的类型安全代理

**问题：** 你想要与LLM进行结构化、类型安全的交互。但完整的代理框架带来了依赖膨胀、不透明的抽象，以及当你需要在框架内部三层深处调试某些东西时的下沉感。

PydanticAI 位于原始API调用和重型框架之间的最佳位置。类型化输入、类型化输出、工具定义、依赖注入。由Pydantic团队构建（其验证库为OpenAI SDK、LangChain以及基本上所有其他软件提供支持）。

作者开始将其用于任何对于单个Instructor调用来说太复杂但不需要完整[LangGraph工作流](link-langgraph-guide)的结构化任务。

**替换：** 无类型提示链和手动响应验证。

**诚实限制：** PydanticAI中的"代理"更像是"结构化LLM交互"而不是"自主多步推理"。对于具有持久状态的复杂多代理工作流，LangGraph或CrewAI仍然占据该领域。

## 6、tiktoken：在发送之前了解你的成本

**问题：** 你通过连接上下文来构建提示词，而你不知道是否即将超出上下文窗口，或者当0.02美元的调用可以工作时发送一个2美元的API调用。

tiktoken 是OpenAI的分词器。在构建包含动态上下文的LLM调用之前，作者添加了令牌检查。

作者在递归上下文构建函数创建了45,000令牌的提示词后开始使用tiktoken。API调用成本1.35美元。对于单个请求。每小时查询200次。

**替换：** 盲目API调用和惊喜发票。

**诚实限制：** tiktoken是OpenAI特定的。对于Anthropic，你需要他们的令牌计数API。LiteLLM的 `token_counter()` 包装了多个分词器，但准确性有所不同。硬编码费率（如上所述）是一个最终会对你说谎的捷径。

## 7、Pydantic Evals：停止对提示词进行"氛围测试"

**问题：** 你更改了系统提示词。它变好了吗？你手动运行三个示例，它们看起来没问题，你发布了它。两天后，用户抱怨你没有测试的回归问题。

Pydantic Evals 是作者发现的最简单的评估框架。定义案例，运行它们，获取通过/失败报告。足够简单，你实际上会使用它（这是整个重点）。

作者几个月来一直抗拒评估框架。"我的提示词工作正常，我手动测试它们。"然后作者更改了一个系统提示词以改进一个边界情况，它默默地破坏了作者没有检查的其他三个情况。

**替换：** "看起来不错"的测试和部署后惊喜。

**诚实限制：** 它是新的，API仍在发展中。对于大规模的生产评估管道，Braintrust或Langfuse提供更深入的集成。但对于"此更改后我的提示词是否仍然有效？"来说，它完全正确。

## 8、结束语

一年前，作者会告诉你最好的栈是你自己构建的栈。完全控制。没有依赖。

作者错了。作者在维护API包装器上花费的时间比构建实际产品还多。这7个库共享一个理念：做一件事，做好它，不要碍事。它们都不需要购买框架。它们都删除你不应该编写的代码。

最好的AI工程堆栈不是最复杂的。它是能够交付的。这就是整个教训。

---

原文链接：[7 Python Libraries That Replaced All My AI Engineering Boilerplate](https://medium.com/data-science-collective/7-python-libraries-that-replaced-all-my-ai-engineering-boilerplate-6d02b66d07d9?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处