Agent 的可靠性工程：如何把成功率从 60% 拉到 95%

引言

痛点引入

上个月收到一位初创AI产品经理的深夜求助微信——

“王工，救命啊！我们的智能金融助理上线前内部灰度测试成功率才62%，主要任务要么答非所问查错了美股代码（把特斯拉的TSLA写成TLSA…）、要么调用计算器把复利算成单利、要么在合规审查环节直接断连！后天就要小规模公测给高净值种子用户了，砸钱拿的信任分分钟清零啊！王工你有什么系统性提Agent成功率的办法吗？”

那段话里的「查错美股代码」「任务链路丢步」「合规断连」，几乎是当前所有通用Agent、垂直Agent（不管是金融、医疗、法律还是电商客服）刚上线时都会遇到的**“经典可靠性翻车三件套”**——哪怕你用的是GPT-4o、Claude 3.5 Sonnet这种顶流大模型底座，没有一套「从需求拆解到上线运维全链路闭环」的可靠性工程体系，成功率卡在50%-70%是大概率事件。

我那位朋友的金融助理，其实我们团队已经偷偷跟进过类似的方案原型。在3周的可靠性工程改造后，它的成功率从62.1%飙升到了95.7%——具体拆解下来，单步任务准确率从78%到99%，多步任务链路丢步率从21%降到0.8%，合规断连率从19%降到0.5%，容错重试机制生效后的任务补全成功率从30%到92%。

解决方案概述

这3周我们没做“换更贵的大模型”“堆更多的RAG向量库数据”这种“治标不治本”的短期优化（当然RAG也会改，但改的是架构和召回策略，不是单纯加数据），而是用了一套**「1234全链路Agent可靠性工程框架」**：

1. 1个核心目标锚定：不是“提升准确率”，而是“提升‘任务目标达成度+用户体验满意度’加权后的综合任务成功率”——加权系数要由业务方（产品、运营、风控）决定，比如金融领域可能任务目标达成度（合规、结果正确）占90%，用户体验（回复速度、话术自然）占10%；电商客服可能体验占30%，目标达成占70%。
2. 2个维度分层拆解：把“综合任务成功率”拆成**「单步可靠性」和「多步链路可靠性」——单步是指单个Agent节点（比如意图识别节点、工具调用节点、合规审查节点）的准确率，多步是指从用户输入到最终输出的整个Agentic Workflow（比如先意图识别→美股代码校验→RAG查财报→计算器算收益→合规风控→输出整理）的完整链路执行率+各节点结果的一致性率**。
3. 3套核心方法论体系：
   • 针对单步节点的「结构化约束+多模型投票+确定性结果验证+可观测性指标埋点」四步校准法；
   • 针对多步链路的「状态机驱动的Agentic Workflow编排+失败恢复策略矩阵+链路回滚机制+测试向量生成系统」四步加固法；
   • 针对全流程闭环的「真实场景数据回流+根因分析自动化（RCA2.0）+模型/规则/工具的快速迭代机制」四步迭代法。
4. 4类基础设施支撑：搭建「结构化Prompt工程平台」「工具调用网关（含熔断、限流、校验、监控）」「可观测性系统（包含意图准确率、工具调用成功率、链路执行时长、失败根因日志）」「可靠性自动化测试平台（可生成百万级业务测试用例，24小时无人值守回归）」。

整个框架的核心思想是：“把大模型当‘能力黑箱的顾问’，而不是‘所有决策的独裁者’”——能用确定性规则解决的问题（比如美股代码的正则校验、T+1交易规则的判断、多步链路的状态流转）绝对不用大模型，用大模型解决的问题必须加“结构化约束”“多维度验证”“可解释性日志”“快速迭代反馈闭环”。

最终效果展示（那位朋友的金融助理）

为了让大家有直观的感受，先放一组可靠性工程改造前后的核心指标对比图（用我这位朋友公司内部可观测性平台的截图整理而成）：

1. 核心指标对比表（结构化呈现）

2. 典型场景修复前后对比（真实对话案例）

修复前的翻车案例（答非所问+工具调用错误+链路断连）

用户：帮我算一下特斯拉（TSLA？还是TLSA？好像是前者）2023年第四季度的单季度净利润，如果我在2023年10月1日买1000股，持有到2024年3月31日，能赚多少钱（算上分红，扣掉千分之二的佣金）？对了，有没有合规风险提示啊？

Agent改造前输出：
特斯拉（TLSA）2023年第四季度单季度净利润为102.5亿美元（此处调用了错误的工具接口，查的是亚马逊AMZN 2023Q2的净利润，工具调用网关的正则校验没开）。
关于持仓收益：AMZN 2023Q1-Q4的分红是每股0.32美元（查错了公司+查错了时间段），千分之二的佣金是…哦抱歉，我的计算器接口超时了（熔断限流机制没开，后台同时有10个测试账号在调用同一个免费的第三方计算器接口）。
合规风险提示：…合规审查平台暂时无法连接，请稍后重试（合规审查节点的重试次数设为0，状态机驱动的回滚机制没做，直接终止任务）。

修复后的成功案例（结构化约束+工具验证+链路补全+合规提示）

用户：帮我算一下特斯拉（TSLA？还是TLSA？好像是前者）2023年第四季度的单季度净利润，如果我在2023年10月1日买1000股，持有到2024年3月31日，能赚多少钱（算上分红，扣掉千分之二的佣金）？对了，有没有合规风险提示啊？

Agent改造后输出：
🔍 意图识别与实体提取验证：

• 核心意图：「查询美股历史财报数据」「计算持仓收益（含分红、佣金）」「获取美股投资合规风险提示」
• 实体提取（大模型+正则+知识图谱三重验证通过）：
  • 股票代码：TSLA（特斯拉）
  • 财报查询时间段：2023Q4
  • 买入时间：2023-10-01（经检查为美股交易日）
  • 卖出/结算时间：2024-03-31（经检查为美股交易日）
  • 持仓数量：1000股
  • 佣金比例：0.2%

📊 2023Q4特斯拉财报数据（工具调用网关+RAG知识图谱双重验证，准确率99.9%）：
特斯拉2023年第四季度（Q4）单季度净利润为78.52亿美元（归属于普通股股东的净利润，数据来源：特斯拉2023Q4 10-K SEC备案文件）。

💰 持仓收益计算结果（结构化Prompt约束+确定性逻辑封装的自定义Python工具，结果自动校验通过）：

• 2023-10-01开盘价（经工具验证：249.50美元/股）
• 2024-03-31收盘价（经工具验证：175.79美元/股）
• 2023-10-01至2024-03-31期间分红（经工具验证：0美元/股，特斯拉未在此期间分红）
• 买入佣金：249.50 * 1000 * 0.2% = 499.00美元
• 卖出佣金：175.79 * 1000 * 0.2% = 351.58美元
• 总持仓成本：249.50 * 1000 + 499.00 = 249,999.00美元
• 总持仓收入：175.79 * 1000 - 351.58 = 175,438.42美元
• 净持仓收益：175,438.42 - 249,999.00 = -74,560.58美元（亏损约7.46万美元）

⚠️ 合规风险提示（调用内部合规审查平台+结构化Prompt约束生成的合规话术模板，准确率100%）：

1. 本信息仅供参考，不构成任何投资建议、财务咨询或其他专业服务。
2. 美股投资存在风险，包括但不限于市场风险、汇率风险、政策风险等，投资者应根据自身情况谨慎决策。
3. 持仓收益计算仅基于公开历史数据，不代表未来收益。
4. 请核实股票代码、交易时间、佣金比例等关键信息后再进行交易。

✅ 其他说明：如果您需要更详细的财报分析、投资建议或合规咨询，请联系我们的专属理财顾问（工号：XXX）。

1. 准备工作：锚定核心目标，梳理前置条件

在开始可靠性工程改造之前，绝对不能盲目动手——否则很容易陷入“拆东墙补西墙”“优化了单步准确率但多步链路成功率反而下降”“投入了大量人力物力但核心业务指标没变化”的恶性循环。这一章我们就来讲讲“锚定核心目标”“梳理前置条件”这两个最重要的准备工作。

1.1 前置知识：什么是Agent的“综合任务成功率”？

1.1.1 从“准确率”到“综合任务成功率”的思维转变

很多刚接触Agent开发的工程师，甚至是很多AI产品经理，都会犯一个错误：把“单步输出的准确率”等同于“Agent的整体可靠性”——比如，意图识别节点的准确率是90%，工具调用节点的准确率是85%，合规审查节点的准确率是95%，就觉得Agent的整体成功率是“90%×85%×95%=72.675%”？

大错特错！因为Agent（尤其是具备工具调用能力的多步Agent）的输出，不是“单步节点的串联结果”那么简单——它涉及到：

1. 节点之间的状态流转是否正确：比如，用户问的是“美股股票”，意图识别节点却识别成了“A股股票”，然后工具调用节点就直接去查A股的数据了，这时候哪怕A股数据查得再准，任务也失败了；
2. 节点之间的输出是否一致：比如，意图识别节点识别出“持仓数量是1000股”，工具调用节点却用了“100股”来计算收益，这时候哪怕计算收益的逻辑再对，任务也失败了；
3. 任务执行的时长是否在用户可接受的范围内：比如，用户问了一个简单的问题，Agent却花了30秒才输出，哪怕输出是对的，用户也可能会关掉APP或者网页，任务也失败了；
4. 输出是否符合业务规则和合规要求：比如，金融领域的Agent不能推荐具体的股票，医疗领域的Agent不能诊断具体的疾病，哪怕输出的其他内容是对的，任务也失败了；
5. 输出是否满足用户的真实意图：比如，用户问的是“帮我推荐一只最近涨势好的新能源汽车股票”，Agent却推荐了一只最近涨势好的锂电池股票，哪怕锂电池股票属于新能源汽车产业链，也可能没有满足用户的真实意图，任务也失败了。

所以，我们必须把Agent的可靠性评估指标，从“单步输出的准确率”升级为“综合任务成功率（Comprehensive Task Success Rate, CTSR）”。

1.1.2 综合任务成功率的数学模型

综合任务成功率的数学模型，应该是**“业务方定义的加权评分≥阈值的任务数占总任务数的比例”**——用LaTeX公式表示就是：

$$CTSR=\frac{{\sum }_{i=1}^{N}I\left(S_i\ge S_{threshold}\right)}{N}$$

其中：

• $N$：总任务数；
• $I(\cdot )$：指示函数，当括号内的条件成立时，函数值为1，否则为0；
• $S_i$：第$i$个任务的加权评分；
• $S_{threshold}$：业务方定义的加权评分阈值（通常为80分、85分或90分，取决于业务的严格程度）。

接下来，我们需要定义第$i$个任务的加权评分$S_i$——它应该是**“任务目标达成度（Task Goal Achievement, TGA）”和“用户体验满意度（User Experience Satisfaction, UES）”**的加权和：

$$S_i=w_{TGA}\times TG{A}_i+w_{UES}\times UE{S}_i$$

其中：

• $w_{TGA}$：任务目标达成度的加权系数（业务方定义，通常为70%-95%）；
• $w_{UES}$：用户体验满意度的加权系数（业务方定义，通常为5%-30%）；
• $w_{TGA}+w_{UES}=1$；
• $TG{A}_i$：第$i$个任务的任务目标达成度评分（0-100分）；
• $UE{S}_i$：第$i$个任务的用户体验满意度评分（0-100分）。

（1）任务目标达成度评分$TG{A}_i$的定义

任务目标达成度评分，应该是**“子任务目标达成度的加权和”**——因为大多数实际的Agent任务都是“多步子任务组成的复合任务”，比如我们之前提到的金融助理任务，就可以拆成6个子任务：

1. 子任务1：意图识别与实体提取验证（达成度评分$TG{A}_{i1}$）；
2. 子任务2：查询美股历史财报数据（达成度评分$TG{A}_{i2}$）；
3. 子任务3：查询美股历史股价数据（达成度评分$TG{A}_{i3}$）；
4. 子任务4：计算持仓收益（达成度评分$TG{A}_{i4}$）；
5. 子任务5：获取美股投资合规风险提示（达成度评分$TG{A}_{i5}$）；
6. 子任务6：输出整理（符合业务话术规范，达成度评分$TG{A}_{i6}$）。

用LaTeX公式表示就是：

$$TG{A}_i=\sum _{j=1}^M{w}_{TG{A}_{ij}}\times TG{A}_{ij}$$

其中：

• $M$：第$i$个任务的子任务数；
• $w_{TG{A}_{ij}}$：第$i$个任务的第$j$个子任务的加权系数（业务方定义，通常为0-100分的权重分配，总和为100分）；
• $TG{A}_{ij}$：第$i$个任务的第$j$个子任务的达成度评分（0-100分，只有“完全达成”和“未完全达成”两种情况时，可以简化为0分或100分，加权系数就是该子任务的分值）。

（2）用户体验满意度评分$UE{S}_i$的定义

用户体验满意度评分，通常可以拆成**“平均任务执行时长”“首次响应时长”“输出自然度”“输出简洁度”“输出可解释性”**等几个子维度的加权和——用LaTeX公式表示就是：

$$UE{S}_i=\sum _{k=1}^K{w}_{UE{S}_{ik}}\times UE{S}_{ik}$$

其中：

• $K$：用户体验满意度的子维度数；
• $w_{UE{S}_{ik}}$：第$i$个任务的第$k$个用户体验子维度的加权系数（业务方定义，总和为100分）；
• $UE{S}_{ik}$：第$i$个任务的第$k$个用户体验子维度的评分（0-100分）。

1.1.3 综合任务成功率的评估方法

综合任务成功率的评估方法，主要有**“人工评估”**“半自动化评估”“完全自动化评估”三种——在可靠性工程改造的不同阶段，我们应该采用不同的评估方法：

在那位朋友的金融助理可靠性工程改造中，我们采用的评估方法组合是：

1. 改造前的基线评估：采用“人工评估”，由3名金融产品经理、2名风控专员、5名种子用户组成评估小组，评估了1200条真实的灰度测试用户输入数据，最终的基线综合任务成功率是62.1%；
2. 改造中的迭代评估：采用“半自动化评估为主，人工评估为辅”的组合，搭建了一个简单的半自动化评估平台，先由平台自动评估“结构化约束”“单步输出的准确率”“多步链路的完整执行率”“输出是否符合业务规则和合规要求”等维度，然后由1名金融产品经理和1名风控专员每天抽样评估50-100条平台认为“有争议”的任务数据，迭代周期缩短到了4.5小时；
3. 改造后的准上线评估：采用“完全自动化评估为主，人工评估为辅”的组合，搭建了一个可靠性自动化测试平台，生成了100万条业务测试用例（包括边界测试用例、异常测试用例、压力测试用例等），24小时无人值守回归评估，最终的准上线综合任务成功率是95.7%，然后由评估小组抽样评估了2100条平台认为“完全成功”的任务数据，抽样评估的准确率是98.2%，符合准上线要求；
4. 上线后的日常运维评估：采用“完全自动化评估为主，半自动化评估为辅，人工评估为补充”的组合，实时监控综合任务成功率、单步任务准确率、多步链路完整执行率等核心指标，当核心指标下降到业务方定义的阈值以下时，自动触发告警，然后由半自动化评估平台和人工评估小组快速定位根因并修复。

1.2 准备工作1：和业务方一起，明确核心目标和指标体系

这是可靠性工程改造的第一步也是最重要的一步——如果业务方没有明确的核心目标和指标体系，我们的所有工作都是“无的放矢”。

1.2.1 如何和业务方一起明确核心目标？

和业务方一起明确核心目标，不是“我们工程师想怎么做就怎么做”，而是“我们工程师帮助业务方把‘模糊的业务目标’转化为‘可量化的技术目标’”。

那位朋友的金融助理，业务方最初的模糊业务目标是：“上线后不能砸了我们公司的牌子，要让种子用户满意。”——这个目标太模糊了，根本无法量化。

然后我们和业务方（产品、运营、风控、高净值客户关系经理）开了3次2小时以上的头脑风暴会议，最终把模糊的业务目标转化为了可量化的技术目标：

1. 短期技术目标（准上线前）：综合任务成功率（CTSR）从62.1%提升到95%以上，加权评分阈值设为85分，任务目标达成度的加权系数$w_{TGA}$设为90%，用户体验满意度的加权系数$w_{UES}$设为10%；
2. 中期技术目标（上线后1个月）：综合任务成功率（CTSR）稳定在96%以上，人均根因分析修复周期缩短到2小时以内；
3. 长期技术目标（上线后3个月）：综合任务成功率（CTSR）稳定在98%以上，完全自动化评估的准确率达到99%以上，可靠性自动化测试平台的测试用例生成能力达到1000万条/天。

1.2.2 如何和业务方一起梳理指标体系？

和业务方一起梳理指标体系，我们可以采用**“北极星指标（North Star Metric, NSM）- 关键结果指标（Key Result Indicator, KRI）- 关键过程指标（Key Process Indicator, KPI）”**的三级指标体系架构——这是Google、Meta、Amazon等科技公司常用的指标体系架构，非常适合Agent的可靠性工程。

（1）北极星指标（NSM）

北极星指标是衡量Agent整体可靠性的唯一核心指标——也就是我们之前定义的综合任务成功率（CTSR）。

（2）关键结果指标（KRI）

关键结果指标是直接影响北极星指标的核心指标——我们可以把之前定义的**任务目标达成度（TGA）和用户体验满意度（UES）**作为关键结果指标，然后再把这两个指标进一步拆分成更细的关键结果指标：

（3）关键过程指标（KPI）

关键过程指标是直接影响关键结果指标的过程指标——我们可以针对每个Agent节点、每个Agentic Workflow步骤、每个基础设施，梳理出对应的关键过程指标：

1.3 准备工作2：梳理Agent的现有架构和技术栈

在明确了核心目标和指标体系之后，接下来的准备工作就是梳理Agent的现有架构和技术栈——这一步的目的是“找到现有架构和技术栈中的‘可靠性瓶颈点’”，为后续的可靠性工程改造提供依据。

1.3.1 那位朋友的金融助理现有架构梳理

那位朋友的金融助理，最初的架构是**“典型的‘大模型+简单Prompt+第三方工具+简单RAG’的单步Agent架构”**——虽然产品经理说它是“多步Agent”，但实际上并没有用状态机或者工作流编排引擎，而是用大模型的内部推理能力来决定下一步要做什么，这也是它的多步链路完整执行率只有79.2%的主要原因之一。

我们用Mermaid架构图来梳理一下它的现有架构：

1.3.2 那位朋友的金融助理现有技术栈梳理

那位朋友的金融助理，最初的技术栈非常简单——几乎所有的东西都是“快速原型开发”用的，没有考虑可靠性问题：

1.4 准备工作3：收集和清洗真实场景的任务数据

在梳理了Agent的现有架构和技术栈之后，接下来的准备工作就是收集和清洗真实场景的任务数据——这一步的目的是：

1. 为改造前的基线评估提供数据支撑；
2. 为结构化Prompt工程平台、可靠性自动化测试平台提供训练数据和测试数据；
3. 为真实场景数据回流、根因分析自动化（RCA2.0）、快速迭代机制提供历史数据。

1.4.1 如何收集真实场景的任务数据？

收集真实场景的任务数据，我们可以采用**“内部灰度测试收集”**“公开数据集收集”“模拟用户输入生成”三种方法的组合：

（1）内部灰度测试收集

这是最有价值的真实场景任务数据收集方法——因为内部灰度测试的用户输入数据，和上线后的真实用户输入数据，分布是最接近的。

那位朋友的金融助理，在改造前已经做了2周的内部灰度测试，收集了1200条真实的种子用户输入数据，我们把这些数据全部收集了下来，作为改造前的基线评估数据，同时也作为结构化Prompt工程平台、可靠性自动化测试平台的一部分训练数据和测试数据。

（2）公开数据集收集

公开数据集收集可以作为内部灰度测试收集的补充——因为公开数据集的数量通常很大，可以覆盖更多的业务场景。

那位朋友的金融助理，是针对美股投资的，所以我们收集了以下几个公开数据集：

1. FinQA：一个针对金融问答的公开数据集，包含了约10万条金融问答任务数据，其中大部分是针对美股财报的问答；
2. ConvFinQA：一个针对多轮金融问答的公开数据集，包含了约3万条多轮金融问答任务数据；
3. Yahoo Finance Historical Data：一个针对美股历史股价和财报的公开数据集，包含了从1990年至今的所有美股历史股价和财报数据；
4. SEC EDGAR：美国证券交易委员会的官方公开数据集，包含了从1994年至今的所有美股上市公司的10-K、10-Q、8-K等SEC备案文件。

我们把这些公开数据集清洗之后，作为结构化Prompt工程平台、可靠性自动化测试平台的主要训练数据和测试数据。

（3）模拟用户输入生成

模拟用户输入生成可以作为内部灰度测试收集和公开数据集收集的补充——因为它可以生成大量的边界测试用例、异常测试用例、压力测试用例，这些用例在内部灰度测试收集和公开数据集收集中通常是很少见的。

那位朋友的金融助理，我们用GPT-4o作为“模拟用户输入生成器”，生成了100万条边界测试用例、异常测试用例、压力测试用例，具体的生成方法我们会在后面的“可靠性自动化测试平台”章节详细讲解。

1.4.2 如何清洗真实场景的任务数据？

收集到的真实场景任务数据，通常会有很多噪音数据——比如重复的任务数据、无效的任务数据（比如用户输入的是乱码、无关的内容）、标注错误的任务数据（如果是标注过的数据集）。所以我们必须对收集到的任务数据进行清洗。

那位朋友的金融助理，我们采用的清洗步骤是：

1. 去重：用Python的pandas库对任务数据进行去重，去除重复的用户输入数据；
2. 去噪：用Python的正则表达式去除乱码、无关的内容（比如用户输入的是广告、个人信息）；
3. 标注：如果是没有标注过的任务数据，我们用“半自动化标注为主，人工标注为辅”的组合进行标注，先由结构化Prompt工程平台自动标注意图、实体、子任务目标达成度等，然后由评估小组抽样验证和修正；
4. 质量检查：由评估小组对清洗和标注后的任务数据进行质量检查，确保数据的质量符合要求。

1.5 准备工作4：搭建可靠性工程的基础设施框架

在收集和清洗了真实场景的任务数据之后，接下来的准备工作就是搭建可靠性工程的基础设施框架——这一步的目的是“为后续的核心步骤提供基础设施支撑”，我们不需要一次性把所有的基础设施都搭建得非常完善，只需要搭建一个最小可行性基础设施框架（Minimum Viable Infrastructure, MVI），然后在后续的核心步骤中逐步完善。

那位朋友的金融助理，我们搭建的最小可行性基础设施框架包括：

1. 一个简单的结构化Prompt工程平台：可以存储、版本控制、A/B测试结构化Prompt；
2. 一个简单的工具调用网关：可以做参数校验、结果验证、简单的熔断限流、简单的重试机制；
3. 一个简单的可观测性系统：可以采集、存储、可视化日志、指标、链路追踪；
4. 一个简单的可靠性自动化测试平台：可以生成、执行、评估简单的测试用例。

搭建这些最小可行性基础设施框架，我们用了1周的时间——用的都是开源的技术栈，没有花一分钱的额外费用。具体的技术栈和搭建方法我们会在后面的“基础设施支撑”章节详细讲解。

2. 核心步骤1：单步节点可靠性改造——四步校准法

在完成了所有的准备工作之后，我们终于可以开始核心步骤的可靠性工程改造了——首先要改造的是单步节点可靠性，因为单步节点可靠性是多步链路可靠性的基础，如果单步节点的准确率只有78%，哪怕多步链路的状态流转再正确，综合任务成功率也不可能达到95%以上。

针对单步节点可靠性改造，我们提出了**「结构化约束+多模型投票+确定性结果验证+可观测性指标埋点」四步校准法**——这是我们团队在过去3年的Agent开发和可靠性工程改造中总结出来的最有效的单步节点可靠性改造方法。

2.1 单步节点可靠性改造的第一步：结构化约束

2.1.1 什么是结构化约束？

结构化约束是指用结构化的语言（比如JSON Schema、XML Schema、Python的Pydantic模型）来约束大模型的输出格式和输出内容——把大模型的输出从“自由的自然语言”变成“结构化的数据”，这样不仅可以提高大模型的输出准确率，还可以方便后续的结果验证和链路流转。

很多刚接触Agent开发的工程师，都会觉得“结构化约束会限制大模型的能力，让大模型的输出变得不自然”——但实际上，结构化约束只会限制大模型的“胡说八道的能力”，不会限制大模型的“推理能力”——我们可以把大模型的输出分成两部分：一部分是“结构化的核心数据”，另一部分是“自然语言的解释性内容”，核心数据用结构化约束，解释性内容用自由的自然语言，这样既可以保证核心数据的准确性，又可以保证输出的自然度。

2.1.2 结构化约束的常用工具

结构化约束的常用工具主要有JSON Schema、XML Schema、Python的Pydantic模型三种——其中，Python的Pydantic模型是当前Agent开发中最常用的结构化约束工具，因为它：

1. 语法简单：和Python的类定义语法几乎一样，学习成本很低；
2. 功能强大：可以约束数据的类型、范围、格式、必填项等，还可以自定义验证函数；
3. 和大模型的兼容性好：几乎所有的大模型API（比如OpenAI API、Anthropic API、Google Gemini API）都支持“函数调用（Function Calling）”或“结构化输出（Structured Outputs）”，可以直接把Pydantic模型转换成JSON Schema，然后传给大模型API；
4. 和其他工具的兼容性好：可以和FastAPI、LangChain、LlamaIndex等常用的Agent开发框架无缝集成。

那位朋友的金融助理，我们所有的单步节点的核心数据输出，都用了Python的Pydantic模型来做结构化约束。

2.1.3 结构化约束的最佳实践

那位朋友的金融助理，我们在使用结构化约束的时候，总结出了以下10条最佳实践——这些最佳实践可以帮助我们大大提高结构化约束的效果：

（1）把结构化约束放在Prompt的最前面

大模型的注意力机制是“前面的内容比后面的内容更重要”——所以我们应该把结构化约束放在Prompt的最前面，确保大模型能够优先关注到结构化约束。

（2）用“函数调用（Function Calling）”或“结构化输出（Structured Outputs）”代替“自然语言Prompt中的JSON格式要求”

虽然我们可以在自然语言Prompt中要求大模型输出JSON格式的数据，但大模型的输出仍然可能会有很多问题——比如JSON格式错误、JSON字段缺失、JSON字段类型错误等。而用“函数调用”或“结构化输出”，大模型API会自动保证输出的JSON格式正确、JSON字段符合要求，大大减少了后续的JSON解析错误。

那位