摘要

Pydantic 的 AI 杠杆来自它掌握了 Python 的类型化数据边界，而不是因为它最初就是为 LLM 设计的。 Colvin 提到，Pydantic 仅 12 月就有近 3 亿次下载；他还表示，一家未具名的基础模型公司从 Pydantic v1 迁移到 v2 后，将首 token 延迟缩短了 20%。“AI 算是找上了我们”，但这种意外形成的定位，如今让 Pydantic 在模型 SDK 和结构化输出工具中获得了不同寻常的分发能力。
Pydantic AI 押注于生产工程能力，认为这将区分经得起时间考验的 agent 框架与机会主义封装层。 Colvin 批评整个生态在类型检查、覆盖率、lint 和文档纪律上都很薄弱，同时承认 LangChain 等早期项目当时是在创造一个新类别。Pydantic AI 接受更复杂的泛型设计，以换取生产安全：每个文档示例和打印结果都在测试中运行，因为这些实践本应是“无需思考的基本功”。
类型安全的图谱让 Colvin 改变了对编排的看法：原本蔓延的控制流被转化为可检查的 Python。 节点返回下一个有类型约束的节点，Pydantic 因此可以推断合法边，并在无需字符串式图定义的情况下生成 Mermaid 图。如今，标准 agent 实现本身就是一张图，但持久化状态存储和分布式执行仍在规划中，尚未完成。
Agent 框架正在弥补模型能力的不足，因此随着模型变强，其长期价值可能下降。 Alessio 提出“苦涩的教训”：开发者可以手工搭建反思和路由图，但更大、训练更充分的模型最终可能直接吸收这套工作流。Colvin 表示认同，并将今天受约束的 agent 比作训练不足的呼叫中心员工——他们需要脚本；“它们越聪明，我们就越不需要告诉它们该做什么。”
Logfire 的核心判断是，AI 可观测性不能继续与应用可观测性割裂。 Colvin 认为，包含模型 prompt 的 trace 所携带的敏感信息将比传统遥测“高出一个数量级”，因此部分客户会重视自托管。Logfire 因而定位于通用可观测性，同时提供一等 AI 支持；OpenTelemetry 的语义约定则可能统一不同框架中的模型调用数据。
Logfire 底层的基础设施押注在技术上有差异化，但商业代价高昂。 团队先后从 ClickHouse 转向 Timescale，最终选择 DataFusion，优先考虑 Rust 的可扩展性、对用户友好的 SQL 和开源架构，而不是更快上市。Colvin 承认这一选择“肯定拖慢了我们”，但它避免把利润让给托管数据库供应商，也让 Pydantic 可以自行实现缺失的计算内核。
管理层在保护 runway 的同时，利用开源和浏览器 demo 提升转化。 Pydantic 和 Pydantic AI 仍采用 MIT 许可证，而 Logfire 明确是闭源、营利性产品；尽管团队实际上同时在运营“3 到 4 家初创公司”，Colvin 仍希望在招聘前先获得更多收入。浏览器版 pydantic.run 旨在让潜在客户直接运行经过测试的示例，消除环境配置摩擦；团队计划加入模型代理，并可能与 Logfire 集成。

精读

1. Pydantic 几乎是偶然成为 AI 基础设施的

Colvin 说，把 Pydantic 称为验证库只是近似说法：它利用 Python 类型提示定义 schema、验证输入，并默认执行合理的类型转换。要求一个整数但收到 "123" 时，结果会变成 123；严格模式则会关闭这一行为。
Colvin 于 2017 年开始做这件事时，用类型提示实现上述功能“确实不被一些人认可”。Pydantic 的普及，以及建立在其之上的 FastAPI 的成功，帮助这种模式在 Python 生态中成为惯例。
JSON Schema 并不是结构化输出委员会经过系统决策后选定的。Sebastian Ramírez 在 Pydantic v1 之前加入，大约利用 50 个周末提交或通知，为 FastAPI 和 OpenAPI 增加 JSON Schema 支持；这后来让一份 Pydantic 定义可以同时作为验证、序列化、工具和 LLM 结构化输出的事实来源。
基于 Rust 的 v2 重写带来的回报，不只体现在 benchmark 上：据称，一家未具名的大型基础模型公司从 Pydantic v1 升级到 v2 后，将内部最重要的延迟指标——首 token 延迟——降低了 20%。

2. Pydantic v3 应在不再经历创伤性重写的情况下叠加性能

Colvin 说，“某个时候肯定会有 v3”，但它造成的代码破坏应远小于 v2；后者将大规模 Rust 重写，与修复从 v0 时代遗留下来的问题结合在了一起。
一个拟议中的变化，是在真正需要 Python 对象之前，持续用 Rust 原生表示保存已验证数据。这样一来，验证紧接着序列化时就可以完全跳过一次 Python 转换，理论上还能带来“再快 3 到 5 倍”的提升。
进一步的工作包括更容易地为 NumPy 数组等类型提供自定义处理、让 SIMD JSON 解析覆盖 amd64 之外的架构，以及可能采用 CBOR 之类的二进制格式来存储和重新加载 Pydantic 数据。
Colvin 于 2022 年初全职开始 Rust 重写，持续了 1 年半。他说，这类工作很少有初创公司会批准：3名工程师全职投入 1 年，为一个免费库编写约 30,000 行 Rust。但这也让公司继续处于 Python AI 技术栈的核心位置。

3. 生产纪律是 Pydantic AI 的切入口

在此前 1 年半的大部分时间里，Pydantic 都在打造通用 Logfire 可观测性，而不是追逐 AI。需求将它拉了回来：Colvin 估计，全球新建的 Python 项目中可能约 80%涉及生成式 AI——“显然在加州是 100%”——这意味着仍有大量工具需求没有解决。
他对 agent 框架的批评尖锐但有所保留。LangChain 早期在探索这个类别时，跳过成熟工程实践是可以理解的；但一些受尊敬的名字最近推出的版本更像是“机会主义”，工程质量“远低于 Python 生态其他部分”。
Pydantic AI 将类型检查、覆盖率、lint 和可执行文档置于优先位置。对于理解 Rust 风格类型系统的开发者来说，它的泛型可能更容易接受；但 Colvin 认为，在大型生产应用中，静态检查的收益足以抵消复杂性，因为这本来就是“无需思考的基本功”。
它的基础 agent 包含系统 prompt、工具、可选的结构化结果、依赖项、模型和设置。Colvin 称这些对象更接近“agentlet”：开发者通常会把多个 agentlet 组合起来，才形成用户所理解的完整 agent。
配套的 pytest-examples 工具会从 docstring 和 Markdown 中提取 Python 代码，运行并 lint，近期还将加入类型检查。这正是团队保持数百个可运行、自包含示例持续更新的方式。

4. 有类型的返回值让图谱可检查，而不是依赖字符串

Colvin 最初认为，普通 Python 控制流足以表达任何 agent 工作流。反复遇到的案例动摇了这一立场：他维护过由此产生的“意大利面代码”，也看到了结构化表示能够自我解释的价值。
Pydantic 的图节点通常是 dataclass，其运行方法返回下一个允许的节点。检查这些返回类型和联合类型，就能揭示合法边，避免使用未经检查的字符串命名连接、再靠运行时验证兜底的图 API。
回报同时体现在安全性和可读性上：仅凭类型提示，就能生成一张 Mermaid 图，准确展示可能发生的路径。Colvin 说，“把这一点做对之后”，他对图谱“异常兴奋”。
Pydantic AI 的常规 agent 实现已经合并到图引擎上，公共 API 没有变化。底层执行仍刻意保持简单：调用一个节点，得到另一个节点，重复这一过程，直到出现 End 值。

5. 持久化工作流暴露出图谱库仍缺少的能力

Colvin 最好的例子是电商退货流程：图中将两条性质完全不同的边视为相同，一条代表立即调用函数，另一条则意味着等待 6 天，让客户打印标签并寄出包裹。概念验证可以对这个暂停一笔带过，但生产环境不行。
图谱可以通过实例化适当节点，并将其作为新的起点来恢复执行。Pydantic AI 已经在问答流程中使用这一模式，但在每个节点之间通过数据库持久化状态，仍是团队计划“很快”加入的能力。
swyx 受 Temporal 启发提出反驳：Python 库本身并不提供隔离执行或基础设施韧性。Colvin 同意，最终每个单元都应在自己的容器或 worker 中运行；只要每个 worker 的代码兼容，将下一个节点的调用序列化后就可以分布式执行。
他偏好的实验载体是通过 Pyodide 运行 Python 的 Cloudflare Workers，因为这样可以无服务器地启动数千个隔离函数。二进制依赖共享仍然困难，但 pydantic-core 这类 Rust 库可以编译为 WebAssembly。

6. Pydantic 在验证编排需求，但没有宣称要建立帝国

主持人将演进路径概括为：从单 agent，到委派和程序化交接，再到基于图的控制流。Colvin 回忆，OpenAI 曾告诉他，Pydantic AI 看起来像是 Swarm“如果做到生产可用后”会变成的样子；他补充说，“也许我不该说这个。”
为了复现 Swarm 直观的使用感，他开始转向图谱，因为“直接用 Python 代码调用下一个 agent”无法满足用户。但仅仅过了几周，他还没有形成标准的前五大图谱分类；他想先看看开发者实际会构建什么。
Colvin 拒绝宣布已经战胜 LangChain：“那是你们该去查清楚的事，不是我的。”Pydantic 目前仍是一个库，而不是 Temporal、Prefect、Airflow 或 Dagster 所提供的部署基础设施；他说，最小图谱抽象究竟有多大用处，仍需通过实践验证。
他对控制力最强的论据来自经济层面：大型自主运行可能在错误变得可见前就消耗大量时间和资金。逐节点迭代能让应用检查进度并及时退出，而不是等模型已经漫游很久后，才被一个笼统的最大步数错误打断。

7. 更好的模型可能抹去今天大量的 agent 脚手架

Alessio 提出“苦涩的教训”式质疑：开发者拆解任务、加入反思，并编排推理时算力；而研究人员可能训练一个更大的模型直接吸收这套模式，比如把 Strawberry 变成 DeepSeek R1。“我们正在这里与苦涩的教训对抗。”
Colvin 基本认同。如果模型真能像支持者暗示的那样，快速变得更快、更强，应用可能只需给一个模型互联网访问权限，“双手合十，祈求一切顺利”，从而不再需要 agent、框架和图谱中的很大一部分。
他的类比来自客服行业：银行会为训练不足的呼叫中心员工编写严密脚本，而面向高净值客户的银行则会雇用那些被期待能在咖啡桌前打动客户、并拥有自主判断权的人。“它们越聪明，我们就越不需要告诉它们该做什么”，也越不需要限制它们的路径。
在此之前，复合系统仍会创造有用的干预点。Agent“在运行良好时确实运行良好”，但仅有可观测性并不能阻止一次糟糕的运行；显式节点则为开发者提供了检查、重定向或终止的位置。

8. 模型可移植性与 eval 仍是悬而未决的工程问题

swyx 质疑每个框架都维护 OpenAI、Claude、Google 等模型的适配器，倾向于采用 LiteLLM 或 Portkey 这样的共享层。当他以 DeepSeek 为缺失案例时，Colvin 立即纠正说：Pydantic AI 已经支持它。
Colvin 的顾虑包括类型安全、关于适配器质量的未经确认的报告，以及标准化代理可能将请求转发给另一家公司的风险。他还看到行业正围绕 OpenAI API 收敛：DeepSeek、Grok 和 Ollama 都在实现它，使 OpenAI SDK 成为事实上的兼容层。
Pydantic AI 会在提交合并到 main 时运行一小组真实模型测试。据称，Google 的 Generative Language API 当时约有 20%的请求返回 503 错误，并反复导致测试失败；而 Vertex 暴露了类似 API，但可靠性明显更高。
Pydantic AI 还支持 test-model 和 function-model 方案，可以在不发起真实调用的情况下模拟模型行为。至于 eval，Colvin 的“诚实答案”是，他不知道普适解。30 个示例可能以 15%的工作量提供 200 个示例大部分的统计价值，但选择正确的评估设计更难；因此 Logfire 暴露 SQL，让用户探索自己的生产数据，而不是接受一套预设框架。

9. Logfire 将 AI trace 与应用其他部分连接起来

Colvin 预计，“AI 可观测性”最终会像 Web 可观测性和云可观测性一样消失为一个独立类别：所有通用平台最终都需要它。他的切入口是通用可观测性加一等 AI 支持，因为只看模型的 trace 会遗漏太多周边应用行为。他也看到了开发者体验上的机会：Sentry 让 Python 接入很容易，而基础的 Datadog/Python 配置并不简单。
OpenTelemetry 正在向生成式 AI 语义属性收敛，最初主要围绕单次 LLM 调用。Agent 层面的约定仍不成熟，消息也在转向 OTel events；Colvin 指出，prompt 和 completion token 字段可能会把昨天的范式固化下来，因为推理 token 和采样方法都在变化。
更深层的问题是数据敏感性。传统遥测会尽量省略参数：医院的 SQL trace 不需要暴露患者身份或 STI 药物。但在生成式 AI 中，这些事实纠缠在自然语言 prompt 里，因此普通的密码键名清洗无法可靠奏效，部分客户也会要求自托管。
Logfire 还会在 span 开始时输出信息，而不是只在结束时输出。等待一个 20 秒的模型请求——或一个 30 分钟的批处理任务——结束后才显示 trace，是“致命的”；提前获得 span 数据，可以让运营人员观察长时间运行的工作如何展开。
Colvin 说，LangChain 有自己的可观测性平台，没有走 OpenTelemetry 路线，因此外部埋点更加困难。Pydantic 的优势在于它控制自己的 agent 框架，可以直接实现这些约定。

10. DataFusion 与克制增长定义了这场商业押注

Logfire 先从 ClickHouse 转向 Timescale，随后又转向 DataFusion；Colvin 承认，这段历程并没有让董事会成员高兴。当时 ClickHouse 的 JSON 支持不够便利，在 interval 和 datetime 上也有令人痛苦的边界问题，尤其是在用户必须自行编写大量时长相关 SQL 的情况下。
DataFusion 是“用来构建数据库的工具箱，而不是数据库”。它基于 Rust 的实现让 Pydantic 可以优化字符串比较内核，并用自己的解析器加入 JSON 支持；Colvin 说，后者是他用一个周末实现的。
这一选择也保住了经济性：ClickHouse 和 Timescale 主要通过托管产品提供对象存储加缓存的架构，而这些托管产品的利润会成为 Logfire 自身利润之下的一层。Colvin 承认，相比在 ClickHouse 上快速发布，DataFusion“肯定拖慢了我们”，但他希望长期来看，开放架构能够胜出。
Pydantic 和 Pydantic AI 采用 MIT 许可证；Logfire 则明确是闭源、营利性产品。开源浏览器沙盒 pydantic.run 旨在运行经过测试的示例，消除本地配置摩擦；Colvin 计划加入 OpenAI 和其他模型的代理，也可能把它接入 Logfire。他希望在招聘前先获得更多商业牵引：“有几年的 runway，而不是几个月，感觉相当不错。”

Brian Tolkin，Opendoor 产品负责人：如何组建最优秀的产品团队 | E1257 DeepSeek 对 AI 未来意味着什么｜科技老兵谈看法