PydanticAI打造坚固代理工作流 实现严格模式与模型无关执行

背景介绍

在生成式 AI 热潮中，越来越多企业尝试将大模型包装成业务代理（Agent），但传统实现往往依赖“最佳努力”式的自由文本输出，导致结果难以校验、系统易崩。MarkTechPost 本篇教程提供了一套基于 PydanticAI 的完整实现方案，力求在每一次模型交互后都能得到结构化、可验证的响应，从而把代理系统的可靠性提升到生产级别。

严格模式实现

• Pydantic Schema：使用 BaseModel 定义 TicketDraft、AgentDecision 等业务实体，字段均配备最小/最大长度、枚举约束以及自定义校验函数，确保模型输出始终符合业务合同。
• 输出校验器：通过 @agent.output_validator 在模型返回后再次检查关键字段（如 action 与 ticket_id 的对应关系），若不符合规则即触发 ModelRetry 让模型自行纠错。

工具注入与依赖注入

• SupportDeps 数据类封装数据库连接、租户标识和策略配置，实现 依赖注入，使每个工具函数在调用时自动获得所需上下文。
• 工具函数（@agent.tool）包括 create_ticket、update_ticket_status、query_ticket、list_open_tickets 四类，全部采用同步 SQLite 语句演示，代码可平滑迁移到生产数据库。

模型无关执行

• 构建函数 build_agent(model_name) 接收模型名称参数，返回同一套工具与 schema 的 Agent 实例。教程展示了 gpt-4o-mini 与 gpt-4o 两种模型的切换，仅需更改调用参数，业务逻辑保持不变。
• 异步执行：整个工作流在 Jupyter/Colab 环境下采用 async 调用，兼容 notebook 的事件循环，便于研发与演示。

实验案例与效果

case_a = await run_case(
    "We suspect account takeover: multiple password reset emails and unauthorized logins. Customer=Leila. Priority=critical. Open a security ticket."
)
case_b = await run_case("List our open tickets and summarize what to tackle first.")
case_c = await run_case("What is the status of ticket 1? If it's open, move it to in_progress.")

• 案例 A：模型在检测到 critical 且策略要求安全短语后自动抛出 ModelRetry，提示补充描述后重试；
• 案例 B：通过 list_open_tickets 返回结构化列表，随后可自行生成摘要；
• 案例 C：成功查询并更新工单状态，实现闭环。

这些示例表明，代理在遵循严格 schema 与业务规则的前提下，能够自主纠错、调用外部工具，并保持输出的一致性与可审计性。

业界意义

1. 可靠性提升：从“自由文本”转向“结构化输出”，显著降低因格式错误导致的系统崩溃风险。
2. 可维护性：模型层与业务层解耦，后端可随时替换底层大模型而无需改动业务代码。
3. 安全合规：通过策略注入实现细粒度权限控制，满足企业对数据安全与审计的要求。

“在真实业务场景中，代理的可靠性往往决定了能否进入生产。” — MarkTechPost

随着企业对 AI 赋能的需求日益增长，类似 PydanticAI 的类型安全框架有望成为构建稳固 AI 代理的标准工具。