客服回答之外还要返回处理标记，Pydantic AI 把两类结果分开

客服助手说“我已经帮你处理”，程序却拿不到明确的处理类型，这是把自然语言直接接进业务时常见的尴尬。Pydantic AI 的银行客服样例，给出一个清楚的拆法：给用户看的建议放在字符串里，程序要用的标记另设字段。

这篇适合开发助手应用的人，不是银行业务操作指南。最值得看的材料，是官方样例中的 SupportOutput：support_advice、block_card 与 risk，分别承载建议文字、布尔标记和数值。

不从一段话里猜结果

样例让用户询问余额，或说明卡片丢失。模型返回的是同一种结构化对象，应用能直接读取每个字段，不必再用正则从客服文案猜“是否应该挂失”。当前总览还展示了给 risk 加上数值范围的写法。

这里必须分清一个很实际的边界：代码里有 block_card 字段，不等于已经对真实账户执行冻结。样例主要展示查询工具与输出类型，业务动作应由应用明确实现、核验权限，并根据真实处理结果反馈。不能让一句生成的“已经处理”替代系统里的操作记录。

结构约束的价值，是让模型与程序对结果形状有共同约定；它不替开发者决定业务规则，也不证明一个风险数字就是正确评估。

另一个值得留下的设计是 SupportDependencies。它携带 customer_id 与数据库连接，运行时通过 RunContext 交给动态说明和工具函数。例如，余额工具用这个用户 ID 查询数据，而不是让模型在文本里自行指定任意客户。

函数的其他参数和 docstring 会形成模型看到的工具说明。参数先经过验证，再进入你的函数；输出则按声明的 output_type 形成可读取对象。对于 Python 开发者，同一套类型也能被 IDE 和静态检查使用。

官方完整样例用内存 SQLite 演示客户资料，因此它是清楚可读的教学材料；真实项目需要换成自己的数据源和连接管理。用户身份如何绑定、哪些字段能读取，仍属于应用职责。

总览说明，参数或输出验证失败时，可以把错误反馈给模型重试。这比接到不合格式的文本后直接继续流程，多了一处明确的纠正机会。

但“符合字段类型”与“符合事实”是两件事。余额字段来自数据库，解释应与查询结果相符；是否触发后续动作，也需要依据确认过的业务规则。即使每个字段都能解析，应用仍要检查语义与状态。

Pydantic AI 代码采用 MIT 许可，模型提供方、数据库与可观测服务分别选择。这个样例适合从一个很小的成果开始：让助手返回一份应用真正能消费的对象，同时把数据访问留在有类型的工具里。先把建议、判断和实际动作分清，再扩成更复杂的业务流程。