最近在做一个AI智能体项目业务方给了一个看着简单、做起来绕的需求每天有一批乱七八糟的文档进来需要系统先判断每份文档属于什么类型再根据类型自动起草一封对应的邮件。比如合同到期要写催签邮件发票异常要写对账通知客户投诉要写道歉说明。这个活儿人来做一天得两三个小时还容易漏。团队决定直接上智能体这条路线把文档分类和邮件撰写串成一个完整的Agent工作流再用评估工具把每个环节的输出质量量化出来。整套方案用LlamaAgents Builder做编排Promptfoo跑评估模型侧用GPT-5.4统一负责语义理解和内容生成。折腾下来我把从设计、编码到评估落地的完整过程都走了一遍踩了不少坑也沉淀了一套能直接复用的打法。这篇文章就围绕这个项目展开把LlamaAgents Builder、Promptfoo、GPT-5.4在文档分类数据与邮件撰写场景里的用法讲透附上我实际跑过的代码和配置。不管你是刚接触智能体的新手还是已经写了几个Agent但不知道怎么系统评估的老手这篇文章应该都能给你一些启发。1. 项目拆解这个智能体到底要解决什么问题1.1 业务痛点与需求边界先还原一下业务场景。某公司每天会收到大量来自不同渠道的文档有电子合同、发票、客户反馈、项目报告、付款凭证偶尔还混着乱七八糟的扫描件。过去这些文档靠一个运营助理逐个打开、判断类型、再决定下一步动作。这个流程有两个天然问题第一人眼分类的标准不稳定同一个文档今天算投诉明天算建议第二分类之后写邮件也是大工程措辞要礼貌、信息要准确、语气要和场景匹配。所以业务方提的第一个需求是能自动识别文档类型。第二个需求是根据类型自动生成一封邮件。乍一听很简单实际上有个隐性的坑——邮件不能光靠类型就能写出来。比如同样是合同类文档新签合同和到期合同要写的邮件完全不同。如果智能体只做粗粒度分类邮件的可用度会非常低。这就是需求边界的核心不仅要分类还要从文档里抽取关键字段让后面的邮件撰写有数据可用。1.2 分解成四个子任务我把整个需求拆成了四个子任务这也是后面构建Agent工作流的物理基础。第一个子任务是文档内容解析。PDF、Word、扫描件这些格式要先转成纯文本这一步虽然不性感但做不好后面全白搭。第二个子任务是粗粒度分类判断这是什么文档。第三个子任务是关键信息抽取从分类后的文档里提取邮件需要的内容比如合同编号、到期日期、发票金额、客户名称。第四个子任务才是邮件撰写把前面得到的分类和抽取结果填入合适的邮件模板并且根据上下文补全措辞。这四个子任务不是简单的串行关系。合同类文档需要抽到期日发票类文档需要抽金额和开票方投诉类文档需要抽反馈原文。分类结果决定了后面抽什么字段抽取结果又决定邮件怎么写。这种动态的、由上游结果决定下游动作的流程正是Agent相对传统规则脚本的核心优势所在。1.3 为什么选择LlamaAgents Builder、Promptfoo和GPT-5.4这个组合技术选型的时候我们其实比过几套方案包括直接写Python函数编排、用通用工作流平台、以及自己封装Prompt调用。最后锁定这个组合理由很直接。LlamaAgents Builder解决的是Agent怎么组织的问题。它基于LlamaIndex生态核心思路是把LLM调用、工具调用、多Agent协作都抽象成可编排的组件构建出来的Agent既能单步执行也能暴露成服务。它不像LangGraph那样逼着你把所有状态流转控制在自己手里也不像纯代码编排那样每个分支都要手写。对我们这种流程清晰但分支多、每步都要接大模型的场景它的抽象层级刚刚好。Promptfoo解决的是怎么算做得好的问题。Agent项目最容易被诟病的一点是演示跑通了但没人知道质量稳不稳。Promptfoo把Prompt、模型、测试用例和断言放在同一个配置体系里可以批量跑评估、做回归对比、甚至做红队测试。每改一次Prompt或者模型版本跑一条命令就能看到指标变化这个反馈闭环太重要了。GPT-5.4在这个项目里负责实际的语义理解和生成。文档分类、信息抽取、邮件润色这些任务模型的指令跟随能力直接决定最终质量。我们用GPT-5.4做主力模型因为它的分类一致性和长文本理解在同类模型里表现比较突出。当然模型迭代很快这套架构里的模型可以随时替换Promptfoo就是验证替换后质量有没有下降的工具。提示不要为了用Agent而用Agent。如果业务流程固定、输入格式规范传统脚本更快更稳。Agent的价值体现在上游输出不确定、下游动作需要动态决策的场景本项目恰好属于这一类。2. 用LlamaAgents Builder搭建文档分类Agent2.1 先把文档分类拆成可执行的工作流用LlamaAgents Builder之前有个习惯特别重要先把业务动作翻译成Agent能理解的工作流。我习惯用一张纸画出来左边是输入右边是输出中间是每一步要用什么模型、什么工具。以文档分类Agent为例工作流是这样的。输入是一段解析好的文本我们默认前面已经用解析服务把PDF转成了纯文本。第一步粗分类器输出文档类型可选项有合同、发票、客户反馈、付款凭证、项目报告、其他。第二步根据类型路由到对应的抽取器合同抽合同编号、甲方乙方、到期日发票抽发票编号、金额、开票方客户反馈抽原文关键句和情绪倾向。第三步把类型 字段封装成一个结构化的分类结果对象输出。这里有个关键设计粗分类和字段抽取不要放在同一个Prompt里。一开始我也试过一步到位式Prompt让模型同时输出类型和字段结果发现准确率和召回率都不稳定原因是任务混在一起后模型注意力被分散。拆成两步后每一步的目标单一Prompt可以写得更尖锐模型也更容易遵循。2.2 Agent构建参考实现下面是文档分类Agent的参考实现用Python写的核心是基于LlamaAgents Builder的AgentWorkflow和FunctionTool抽象。具体API版本以你本地环境为准但整体结构是稳定的。from typing import Dict, List from llama_agents import AgentWorkflow, FunctionTool from llama_index.core.tools import FunctionTool as BaseTool # ---------- 工具层分类与抽取 ---------- def classify_document(text: str) - str: 粗粒度文档分类返回文档类型标签。 这里用结构化Prompt让模型输出限定枚举值分类一致性更好。 prompt f 请判断以下文档属于哪个类型只能输出以下之一 contract, invoice, customer_feedback, payment_receipt, project_report, other 文档内容 {text[:3000]} 输出类型 # 实际项目中这里调用GPT-5.4建议temperature0 result llm_complete(prompt, temperature0) return result.strip() def extract_contract_fields(text: str) - Dict[str, str]: prompt f 从以下合同文本中抽取字段 contract_no, party_a, party_b, expiry_date, sign_date 如果没有对应字段填写未找到。 按JSON格式返回。 合同文本 {text[:3000]} return json_extract(llm_complete(prompt, temperature0)) def extract_invoice_fields(text: str) - Dict[str, str]: prompt f 从以下发票文本中抽取字段 invoice_no, amount, amount_unit, issuers_name, invoice_date 按JSON格式返回。 发票文本 {text[:3000]} return json_extract(llm_complete(prompt, temperature0)) # ---------- 路由分类结果决定抽取动作 ---------- def extract_fields(doc_type: str, text: str) - Dict[str, str]: if doc_type contract: return extract_contract_fields(text) elif doc_type invoice: return extract_invoice_fields(text) else: # 其他类型不抽取留给邮件Agent处理 return {note: 无需结构化抽取} # ---------- 注册工具并构建Agent ---------- tools [ FunctionTool.from_defaults( fnclassify_document, nameclassify_document, description输入文档文本输出文档类型标签, ), FunctionTool.from_defaults( fnextract_fields, nameextract_fields, description输入文档类型和文本输出结构化字段, ), ] agent_workflow AgentWorkflow( namedocument_classifier, toolstools, state默认分类Agent, # 可理解为Agent的指令上下文 verboseTrue, )这段代码最值得关注的是extract_fields这个工具的设计。它接收两个参数一个是classify_document的输出一个是原始文本。Agent在运行时做的事情是先调用classify_document拿到类型再把这个类型作为参数传给extract_fields实现路由。这本质上就是一个函数调用链但LlamaAgents Builder把它包装成了Agent的自主决策过程。2.3 工具注册、上下文与分类输出约束用LlamaAgents Builder有几点我踩过坑后总结出来的经验。工具描述一定要写清楚。FunctionTool.from_defaults里的description不是给人看的是给模型看的。模型靠description决定要不要调用这个工具、什么时候调用。如果description写得太含糊比如处理文档模型就可能在输入是纯文本的时候就调了导致参数错配。我最后把description写成输入文档文本输出文档类型标签模型就非常听话。上下文不要一股脑全塞。我们第一版把完整文档文本加系统提示全塞给每一步的LLM调用结果token消耗直接爆炸。后来做了一个截断策略粗分类只看前3000字符因为文档类型特征通常出现在开头字段抽取则根据类型决定看多少合同只看关键段落。这个策略在实测里对准确率影响极小但成本降了六成。输出限制要做硬约束。分类任务用temperature0并且提示词里明确要求只输出枚举值。抽取任务要求输出JSON并且在解析前先做格式校验避免模型偶尔输出markdown包裹的JSON导致json.loads失败。这些小细节看似不起眼但在批量跑评估的时候任何一条解析失败都会污染整个评估结果。注意LlamaAgents Builder并不是一个画个流程图就能跑的零代码工具。它更像是一个有Agent概念的编排框架你仍然要自己写工具函数、自己控制Prompt质量。工具函数的质量上限决定了Agent的质量上限。3. 邮件撰写Agent分类结果如何驱动邮件生成3.1 邮件模板的策略分类只定类型邮件要带数据邮件撰写Agent是整个项目里最有智能感的部分也是最容易翻车的部分。翻车原因基本都是只给模型一个文档类型就让它写邮件结果写出来全是正确的废话。比如让模型写一封合同邮件它大概率会写出您好我们注意到您有一份合同需要处理请尽快确认。这封邮件没有任何信息增量收件人看了等于没看。问题出在邮件内容缺少数据支撑。正确的姿势是邮件撰写Agent的输入不应该是文档类型而应该是文档类型加结构化字段。合同到期催签邮件必须带合同编号和到期日期发票对账邮件必须带发票编号和金额投诉回复邮件必须带上客户的原始反馈要点。没有这些数据模型再强也写不出可用的邮件。所以整个链路是这样的文档分类Agent输出{type: contract, fields: {contract_no: HT-2024-001, expiry_date: 2025-03-31}}这个结构化对象作为输入传给邮件撰写Agent。邮件Agent的Prompt把所有字段都展开解释一遍并要求成文时每一个关键字段都必须出现在邮件正文里。3.2 邮件撰写Agent的参考实现邮件撰写Agent的代码结构如下核心是动态Prompt构建和输出校验。from llama_agents import AgentWorkflow, FunctionTool from typing import Dict import re def draft_email(doc_type: str, fields: Dict[str, str], recipient_hint: str ) - str: 根据文档类型和结构化字段撰写邮件。 recipient_hint 是可选的收件人信息例如某公司财务部。 prompt f 你是一名专业的商务邮件撰写助理。请根据以下文档分类结果和提取字段撰写一封可直接发送的商务邮件。 文档类型{doc_type} 结构化字段 {json.dumps(fields, ensure_asciiFalse)} 额外收件人提示{recipient_hint if recipient_hint else 无} 要求 1. 邮件主题行以【】开头并概括目的例如【合同到期提醒】 2. 邮件正文必须包含上述所有关键字段不得遗漏 3. 语气礼貌、专业根据文档类型切换 - contract 到期提醒催签措辞委婉但明确 - invoice 异常说明金额和编号请求核对 - customer_feedback 投诉先道歉再说明处理态度 4. 输出格式 Subject: 主题 Body: 正文 email_text llm_complete(prompt, temperature0.3) # 简单校验核心字段是否都出现在邮件中 for key, value in fields.items(): if value and value ! 未找到 and value not in email_text: return fERROR: 字段 {key}: {value} 未出现在邮件中请重新生成 return email_text email_tool FunctionTool.from_defaults( fndraft_email, namedraft_email, description输入文档类型和结构化字段撰写对应商务邮件, ) email_agent AgentWorkflow( nameemail_writer, tools[email_tool], state邮件撰写Agent负责根据分类结果生成邮件, verboseTrue, )这个实现有几个值得展开的细节。温度设为0.3而不是0是因为邮件撰写是生成任务需要一点随机性来让措辞自然但又不允许过度发挥。字段校验是纯粹用代码做的硬检查不允许模型说字段已包含就放过它。我甚至见过模型在邮件里写您的合同编号为XXXX——真把占位符写进去了所以硬校验必须做。3.3 数据联动与上下文传递的细节两个Agent之间怎么传数据这个环节很多人会写错。最直接的错误是把原始文档文本直接传给邮件Agent让它自行处理。这样做的后果是邮件Agent承担了分类加抽取加撰写的全部工作Prompt又会变得臃肿输出质量重新回到正确废话的水平。正确做法是让分类Agent先完整执行把分类结果对象持久化然后把对象作为邮件Agent的输入。我通常用一个轻量的内存队列分类Agent输出一个文档实例后将结果写入队列邮件Agent消费这个结果再生成邮件。中间任何一步失败都会记录日志并重新触发不会出现邮件已经发了但分类结果是错的这种尴尬。上下文传递还有一个容易忽略的细节Prompt里的字段名和实际提取的字段名必须一致。比如代码里用expiry_datePrompt里也必须是expiry_date不要写成到期日期。模型对字段名的敏感性远超想象字段名不一致会导致模型把关键信息忽略掉这种问题在评估阶段才会暴露出来而且很隐蔽。提示如果邮件Agent生成的邮件在评估里经常漏字段第一反应不要调Prompt而是检查传入的结构化字段本身是否完整。很多时候不是模型不会写而是上游抽取就没抽到。4. 用Promptfoo给智能体装上质量仪表盘4.1 为什么评估必须前置而不是最后补大部分Agent项目死在评估环节。不是说没有评估而是评估做得太晚、太随意。传统做法是开发完直接丢几个样例进去跑一遍肉眼看输出没问题就算完成。等上线后才发现某个类型的文档分类偏了、某类邮件语气不对再回头改Prompt费时费力。Promptfoo的价值在于把评估前置到开发循环里。它做的事情本质上是批量化、可复现、可断言地跑测试用例你定义一批输入和对应的期望输出配置好要调用的模型和Prompt运行一条命令就能看到通过率、失败用例、甚至两个模型版本的对比结果。我建议的用法是这样每改一版Prompt先跑一遍Promptfoo的测试集全部通过才能合并代码。这一条规则看着简单实际贯彻下来能把Agent质量提升一个档次。4.2 promptfooconfig.yaml设计场景、断言与指标下面是我在这类项目里实际用过的Promptfoo配置主要面向文档分类和邮件撰写两个场景。配置文件通常叫promptfooconfig.yaml。# promptfooconfig.yaml prompts: - 对以下文档进行分类请输出纯文本类型标签{{doc_text}} - | 根据文档分类结果撰写邮件要求如下 文档类型{{doc_type}} 结构化字段{{fields}} 必须包含所有字段语气礼貌专业。 providers: - openai:gpt-5.4 config: temperature: 0 tests: # 场景1文档分类 - description: 合同分类-正面-到期条款 vars: doc_text: 本合同编号HT-2024-001甲方为某某公司乙方为某某供应商合同有效期为2024年1月1日至2025年3月31日到期前30日双方应协商续签事宜。 assert: - type: contains value: contract - type: is-json - description: 发票分类-正面 vars: doc_text: 发票号码INV-20250315-88金额为人民币12,500元开票方为某某科技有限公司开票日期为2025年3月15日。 assert: - type: contains value: invoice - type: is-json - description: 合同分类-反例-不应是发票 vars: doc_text: 这是一份采购合同双方约定交付和付款条款。 assert: - type: not-contains value: invoice # 场景2邮件撰写 - description: 合同到期催签邮件-必含到期日 vars: doc_type: contract fields: contract_no: HT-2024-001 expiry_date: 2025-03-31 party_a: 某某公司 party_b: 某某供应商 assert: - type: contains value: HT-2024-001 - type: contains value: 2025-03-31 - type: contains value: 催签 safe: true # 允许AI选择近似表达safe标记为宽松匹配实际按需使用 - description: 发票对账邮件-必含金额 vars: doc_type: invoice fields: invoice_no: INV-20250315-88 amount: 12,500 issuers_name: 某某科技有限公司 assert: - type: contains value: INV-20250315-88 - type: contains value: 12,500跑一下评估的命令很简单promptfoo eval结果会输出到终端也可以生成一个HTML报告promptfoo eval -o report.html配置里有几个设计上的细节。providers里设置了temperature: 0这和我们项目里分类Agent的设定保持一致。评估要想反映真实质量评估环境和实际运行环境必须完全一致否则测了个寂寞。safe: true那个断言我标了注释——实际使用中我很少直接用safe参数更常用的做法是写多个contains去覆盖关键短语避免模型换了个同义表达就误判失败。另一个建议是给每个测试用例配上清晰的description。Promptfoo的报告里会列出这个描述否则一旦有失败用例光看输入输出你根本不知道它测的是什么场景。我吃过的亏是没写描述跑完出现两个失败用例我花了半小时才回忆起来那是在测投诉邮件的场景。4.3 评估结果怎么解读以及怎么把指标喂回给开发跑完Promptfoo拿到通过率只是一个开始。我一般会分三步看结果。第一步看断言通过率。低于80%说明有大问题先别急着调Prompt回头检查工作流和数据链路。第二步看失败的用例集中在哪个场景。如果全部失败在投诉邮件那问题大概率在投诉邮件的Prompt分支或者样例数据本身。第三步看模型输出原文判断是模型没听懂还是任务要求本身模糊。这两类问题的修法完全不同前者要改指令后者要改测试用例。我还会把Promptfoo作为Prompt迭代的回归测试工具。每次调整邮件撰写的Prompt之后运行全量测试集对比通过率变化。这样做最大的好处是一次改动如果导致某个已经通过的场景变差会立刻被暴露而不是上线后由用户发现。注意Promptfoo的断言只能检查文本里有没有某个词它不能判断这句话是否真诚、语气是否得体。所以在自动化评估之外至少保留一小撮人工评审样例专门看那些断言覆盖不到的主观维度。5. 全流程串联从文档进来到评估结果报告5.1 一个端到端的运行链路前面几节分开讲了分类Agent、邮件Agent和评估系统现在把它们串在一起看一个完整的运行链路。我在项目里用一个简单的Python脚本做总控做的事情就三个阶段。第一阶段输入解析。原始文档进来后先统一转成纯文本做简单的长度检查过短的文档标记为待人工确认。第二阶段Agent工作流执行。把文本交给文档分类Agent拿到{type, fields}结构再把这个结构交给邮件撰写Agent生成邮件草稿。第三阶段结果持久化与评估。生成的内容、使用的模型版本、Prompt版本、耗时都记录成一条结构化日志。这条链路里有一个很重要的工程实践版本记录。每个Agent工作流都打上agent_version标签每次Prompt修改都复用Promptfoo的配置作为该版本的锚点。这样做的好处是任何一次线上输出质量问题都能快速定位到哪个版本的哪个Agent在哪个环节出的问题。from dataclasses import dataclass from typing import Optional, Dict, Any dataclass class AgentRunRecord: doc_id: str agent_version: str doc_type: Optional[str] fields: Dict[str, Any] email: str model_name: str prompt_version: str success: bool error_message: Optional[str] None5.2 参数选择与调优记录这个项目里我调过几组参数记录一下实测结果方便参考。第一组是分类Agent的temperature。从0到0.2再到0.5各跑了一遍0和0.2在文档分类准确率上几乎没有差别但0.5开始出现分类标签之间的混淆比如把付款凭证识别成发票。最后定了temperature: 0分类任务不允许任何随机性。第二组是抽取的文本长度。合同类文档经常很长全量塞进去效果不一定好反而是把开头和涉及日期、金额的段落拼接起来效果最好。我试过只取前3000字符、全量文本、以及规则切分后取重点段落三种方案第三种准确率最高但实现成本也最高。项目初期先用前3000字符作为兜底稳定性和成本都居中。第三组是邮件撰写时是否给示例范例。开始不给示例模型写得非常自由格式不统一。后来在Prompt里加了两个few-shot示例一个合同催签邮件一个发票对账邮件格式立刻规整了。这里有个细节few-shot示例的质量要求比线上输入还高模型会模仿示例的措辞风格如果示例本身写得很烂输出会更烂。5.3 线上运行效果与资源占用这套方案跑了一段时间业务侧的反馈是文档分类准确率在测试集上大概是94%左右邮件可用率稍低约87%。分类错误主要集中在项目报告和客户反馈的边界样本上这个我们在评估里提前预判到了。邮件可用率上不去的原因是部分字段抽取失败导致邮件缺数据属于上游问题不是生成问题。资源占用方面单份文档从进入系统到邮件生成完毕平均耗时15秒左右其中大头是两次完整的LLM调用。如果对延迟敏感可以考虑把粗分类和字段抽取合并但准确率会掉2到3个百分点。这就是典型的延迟和准确率的取舍我的建议是只要业务不要求实时就别省这一步。成本方面每份文档处理一次大约消耗的token数在4000到6000之间主要看文档长度。为了防止恶意超长文本导致费用飙升我在进入Agent工作流之前做了截断超过8000字符的文档直接拒绝并提示转人工。这个阈值不是随手定的是测试后发现在8000字符以内抽取准确率随长度增加保持平稳再长就开始下降了。6. 常见问题排查与避坑经验6.1 典型的三个陷阱和一个排查表这个项目从开发到落地我遇到的典型问题基本可以归成三类。第一类是上游抽不出字段下游全乱套。典型表现是分类正确但邮件里总是缺字段。排查思路是先看分类Agent的输出确认结构化字段里到底有没有值再看中间变量是否有截断最后看邮件Agent的Prompt是否引用对了字段名。我遇到过最离谱的一次是字段名里有一个下划线写成了空格模型直接忽略。第二类是评估通过率很高线上表现却不行。这通常是测试用例分布和线上真实数据分布不一致导致的。线上来的文档五花八门测试集里没有覆盖到的边缘格式比如文档是图片扫描件、表格型PDF、中英混排文本一上来就把处理链路打穿了。解决方案是把这些边缘样本不断补充进Promptfoo的测试集让评估集跟着线上数据一起演进。第三类是GPT-5.4输出随机带来的偶发性失败。即便我们设置了temperature为0模型在某些情况下依然会输出异常格式比如多包一层引号、漏掉一个括号。这类问题不能靠改Prompt根除必须用代码做输出层的防御式解析。我的经验是每一个LLM输出都要过一层格式校正器负责清理多余符号、修复JSON括号、截断非法输出。别嫌丑这个丑东西能救你一命。现象排查方向常见解法分类类型偶尔不稳定温度设置、Prompt枚举约束temperature设为0明确要求只输出枚举值邮件经常漏关键字段上游字段抽取是否完整、字段名是否一致硬校验字段是否出现在邮件正文token成本偏高文本全量塞入、Prompt冗余截断策略、字段精简、few-shot不超过2个评估通过但线上差测试集与真实分布不一致把线上边缘样本反向补充进测试集模型输出偶尔非法格式模型随机性增加输出格式校正器而非依赖Prompt6.2 我的几点实操心得回顾这个项目有几个心得是真正从踩坑里长出来的。第一个心得Agent项目里Prompt的质量上限低于工具链的质量上限。你Prompt写得多完美结构字段抽取不出来一切都白搭。所以投入时间去打磨工具函数、做数据清理、做输出校验性价比要远高于反复调Prompt。第二个心得评估体系要跟着业务一起进化不要指望一次搭好一劳永逸。Promptfoo的测试集每周我都会补充几条新用例遇到线上异常样本就顺手加进去。这条习惯坚持下来Agent的回归测试集越来越厚系统也越来越稳。第三个心得结构化中间结果胜于一切微调。文档分类输出结构化的type fields带来的收益比任何Prompt技巧都大。因为它让系统从一段文本流到另一段文本变成了一段文本变成数据数据再变成另一段文本。一旦中间层是结构化数据调试、评估、替换模型全都变得清晰可控。第四个心得在正式用Promptfoo全量评估Agent之前可以先拿它只测单个Prompt的效果。比如先测分类Prompt在50条数据上的准确率再测抽取Prompt在20条人工标注数据上的字段命中率最后再全链路测。从小处着手定位问题的速度会快非常多。我个人现在做任何Agent项目都会默认带上一套评估配置哪怕只是最基础的场景覆盖。不跑评估就发布Agent就像不带安全网走钢丝——也许运气好能走完但掉下去的代价太惨痛。LlamaAgents Builder、Promptfoo、GPT-5.4这一套组合我实测下来稳定性可接受迭代效率是真的高。这个内容后续还可以往多Agent协作、自动评估集生成的方向继续扩展如果你正好也在做类似的智能体项目建议你也从这套构建加评估的闭环开始。 最近在做一个AI智能体项目业务方给了一个看着简单、做起来绕的需求每天有一批乱七八糟的文档进来需要系统先判断每份文档属于什么类型再根据类型自动起草一封对应的邮件。比如合同到期要写催签邮件发票异常要写对账通知客户投诉要写道歉说明。这个活儿人来做一天得两三个小时还容易漏。团队决定直接上智能体这条路线把文档分类和邮件撰写串成一个完整的Agent工作流再用评估工具把每个环节的输出质量量化出来。整套方案用LlamaAgents Builder做编排Promptfoo跑评估模型侧用GPT-5.4统一负责语义理解和内容生成。折腾下来我把从设计、编码到评估落地的完整过程都走了一遍踩了不少坑也沉淀了一套能直接复用的打法。这篇文章就围绕这个项目展开把LlamaAgents Builder、Promptfoo、GPT-5.4在文档分类数据与邮件撰写场景里的用法讲透附上我实际跑过的代码和配置。不管你是刚接触智能体的新手还是已经写了几个Agent但不知道怎么系统评估的老手这篇文章应该都能给你一些启发。1. 项目拆解这个智能体到底要解决什么问题1.1 业务痛点与需求边界先还原一下业务场景。某公司每天会收到大量来自不同渠道的文档有电子合同、发票、客户反馈、项目报告、付款凭证偶尔还混着乱七八糟的扫描件。过去这些文档靠一个运营助理逐个打开、判断类型、再决定下一步动作。这个流程有两个天然问题第一人眼分类的标准不稳定同一个文档今天算投诉明天算建议第二分类之后写邮件也是大工程措辞要礼貌、信息要准确、语气要和场景匹配。所以业务方提的第一个需求是能自动识别文档类型。第二个需求是根据类型自动生成一封邮件。乍一听很简单实际上有个隐性的坑——邮件不能光靠类型就能写出来。比如同样是合同类文档新签合同和到期合同要写的邮件完全不同。如果智能体只做粗粒度分类邮件的可用度会非常低。这就是需求边界的核心不仅要分类还要从文档里抽取关键字段让后面的邮件撰写有数据可用。1.2 分解成四个子任务我把整个需求拆成了四个子任务这也是后面构建Agent工作流的物理基础。第一个子任务是文档内容解析。PDF、Word、扫描件这些格式要先转成纯文本这一步虽然不性感但做不好后面全白搭。第二个子任务是粗粒度分类判断这是什么文档。第三个子任务是关键信息抽取从分类后的文档里提取邮件需要的内容比如合同编号、到期日期、发票金额、客户名称。第四个子任务才是邮件撰写把前面得到的分类和抽取结果填入合适的邮件模板并且根据上下文补全措辞。这四个子任务不是简单的串行关系。合同类文档需要抽到期日发票类文档需要抽金额和开票方投诉类文档需要抽反馈原文。分类结果决定了后面抽什么字段抽取结果又决定邮件怎么写。这种动态的、由上游结果决定下游动作的流程正是Agent相对传统规则脚本的核心优势所在。1.3 为什么选择LlamaAgents Builder、Promptfoo和GPT-5.4这个组合技术选型的时候我们其实比过几套方案包括直接写Python函数编排、用通用工作流平台、以及自己封装Prompt调用。最后锁定这个组合理由很直接。LlamaAgents Builder解决的是Agent怎么组织的问题。它基于LlamaIndex生态核心思路是把LLM调用、工具调用、多Agent协作都抽象成可编排的组件构建出来的Agent既能单步执行也能暴露成服务。它不像LangGraph那样逼着你把所有状态流转控制在自己手里也不像纯代码编排那样每个分支都要手写。对我们这种流程清晰但分支多、每步都要接大模型的场景它的抽象层级刚刚好。Promptfoo解决的是怎么算做得好的问题。Agent项目最容易被诟病的一点是演示跑通了但没人知道质量稳不稳。Promptfoo把Prompt、模型、测试用例和断言放在同一个配置体系里可以批量跑评估、做回归对比、甚至做红队测试。每改一次Prompt或者模型版本跑一条命令就能看到指标变化这个反馈闭环太重要了。GPT-5.4在这个项目里负责实际的语义理解和生成。文档分类、信息抽取、邮件润色这些任务模型的指令跟随能力直接决定最终质量。我们用GPT-5.4做主力模型因为它的分类一致性和长文本理解在同类模型里表现比较突出。当然模型迭代很快这套架构里的模型可以随时替换Promptfoo就是验证替换后质量有没有下降的工具。提示不要为了用Agent而用Agent。如果业务流程固定、输入格式规范传统脚本更快更稳。Agent的价值体现在上游输出不确定、下游动作需要动态决策的场景本项目恰好属于这一类。2. 用LlamaAgents Builder搭建文档分类Agent2.1 先把文档分类拆成可执行的工作流用LlamaAgents Builder之前有个习惯特别重要先把业务动作翻译成Agent能理解的工作流。我习惯用一张纸画出来左边是输入右边是输出中间是每一步要用什么模型、什么工具。以文档分类Agent为例工作流是这样的。输入是一段解析好的文本我们默认前面已经用解析服务把PDF转成了纯文本。第一步粗分类器输出文档类型可选项有合同、发票、客户反馈、付款凭证、项目报告、其他。第二步根据类型路由到对应的抽取器合同抽合同编号、甲方乙方、到期日发票抽发票编号、金额、开票方客户反馈抽原文关键句和情绪倾向。第三步把类型 字段封装成一个结构化的分类结果对象输出。这里有个关键设计粗分类和字段抽取不要放在同一个Prompt里。一开始我也试过一步到位式Prompt让模型同时输出类型和字段结果发现准确率和召回率都不稳定原因是任务混在一起后模型注意力被分散。拆成两步后每一步的目标单一Prompt可以写得更尖锐模型也更容易遵循。2.2 Agent构建参考实现下面是文档分类Agent的参考实现用Python写的核心是基于LlamaAgents Builder的AgentWorkflow和FunctionTool抽象。具体API版本以你本地环境为准但整体结构是稳定的。from typing import Dict, List from llama_agents import AgentWorkflow, FunctionTool from llama_index.core.tools import FunctionTool as BaseTool # ---------- 工具层分类与抽取 ---------- def classify_document(text: str) - str: 粗粒度文档分类返回文档类型标签。 这里用结构化Prompt让模型输出限定枚举值分类一致性更好。 prompt f 请判断以下文档属于哪个类型只能输出以下之一 contract, invoice, customer_feedback, payment_receipt, project_report, other 文档内容 {text[:3000]} 输出类型 # 实际项目中这里调用GPT-5.4建议temperature0 result llm_complete(prompt, temperature0) return result.strip() def extract_contract_fields(text: str) - Dict[str, str]: prompt f 从以下合同文本中抽取字段 contract_no, party_a, party_b, expiry_date, sign_date 如果没有对应字段填写未找到。 按JSON格式返回。 合同文本 {text[:3000]} return json_extract(llm_complete(prompt, temperature0)) def extract_invoice_fields(text: str) - Dict[str, str]: prompt f 从以下发票文本中抽取字段 invoice_no, amount, amount_unit, issuers_name, invoice_date 按JSON格式返回。 发票文本 {text[:3000]} return json_extract(llm_complete(prompt, temperature0)) # ---------- 路由分类结果决定抽取动作 ---------- def extract_fields(doc_type: str, text: str) - Dict[str, str]: if doc_type contract: return extract_contract_fields(text) elif doc_type invoice: return extract_invoice_fields(text) else: # 其他类型不抽取留给邮件Agent处理 return {note: 无需结构化抽取} # ---------- 注册工具并构建Agent ---------- tools [ FunctionTool.from_defaults( fnclassify_document, nameclassify_document, description输入文档文本输出文档类型标签, ), FunctionTool.from_defaults( fnextract_fields, nameextract_fields, description输入文档类型和文本输出结构化字段, ), ] agent_workflow AgentWorkflow( namedocument_classifier, toolstools, state默认分类Agent, # 可理解为Agent的指令上下文 verboseTrue, )这段代码最值得关注的是extract_fields这个工具的设计。它接收两个参数一个是classify_document的输出一个是原始文本。Agent在运行时做的事情是先调用classify_document拿到类型再把这个类型作为参数传给extract_fields实现路由。这本质上就是一个函数调用链但LlamaAgents Builder把它包装成了Agent的自主决策过程。2.3 工具注册、上下文与分类输出约束用LlamaAgents Builder有几点我踩过坑后总结出来的经验。工具描述一定要写清楚。FunctionTool.from_defaults里的description不是给人看的是给模型看的。模型靠description决定要不要调用这个工具、什么时候调用。如果description写得太含糊比如处理文档模型就可能在输入是纯文本的时候就调了导致参数错配。我最后把description写成输入文档文本输出文档类型标签模型就非常听话。上下文不要一股脑全塞。我们第一版把完整文档文本加系统提示全塞给每一步的LLM调用结果token消耗直接爆炸。后来做了一个截断策略粗分类只看前3000字符因为文档类型特征通常出现在开头字段抽取则根据类型决定看多少合同只看关键段落。这个策略在实测里对准确率影响极小但成本降了六成。输出限制要做硬约束。分类任务用temperature0并且提示词里明确要求只输出枚举值。抽取任务要求输出JSON并且在解析前先做格式校验避免模型偶尔输出markdown包裹的JSON导致json.loads失败。这些小细节看似不起眼但在批量跑评估的时候任何一条解析失败都会污染整个评估结果。注意LlamaAgents Builder并不是一个画个流程图就能跑的零代码工具。它更像是一个有Agent概念的编排框架你仍然要自己写工具函数、自己控制Prompt质量。工具函数的质量上限决定了Agent的质量上限。3. 邮件撰写Agent分类结果如何驱动邮件生成3.1 邮件模板的策略分类只定类型邮件要带数据邮件撰写Agent是整个项目里最有智能感的部分也是最容易翻车的部分。翻车原因基本都是只给模型一个文档类型就让它写邮件结果写出来全是正确的废话。比如让模型写一封合同邮件它大概率会写出您好我们注意到您有一份合同需要处理请尽快确认。这封邮件没有任何信息增量收件人看了等于没看。问题出在邮件内容缺少数据支撑。正确的姿势是邮件撰写Agent的输入不应该是文档类型而应该是文档类型加结构化字段。合同到期催签邮件必须带合同编号和到期日期发票对账邮件必须带发票编号和金额投诉回复邮件必须带上客户的原始反馈要点。没有这些数据模型再强也写不出可用的邮件。所以整个链路是这样的文档分类Agent输出{type: contract, fields: {contract_no: HT-2024-001, expiry_date: 2025-03-31}}这个结构化对象作为输入传给邮件撰写Agent。邮件Agent的Prompt把所有字段都展开解释一遍并要求成文时每一个关键字段都必须出现在邮件正文里。3.2 邮件撰写Agent的参考实现邮件撰写Agent的代码结构如下核心是动态Prompt构建和输出校验。from llama_agents import AgentWorkflow, FunctionTool from typing import Dict import re def draft_email(doc_type: str, fields: Dict[str, str], recipient_hint: str ) - str: 根据文档类型和结构化字段撰写邮件。 recipient_hint 是可选的收件人信息例如某公司财务部。 prompt f 你是一名专业的商务邮件撰写助理。请根据以下文档分类结果和提取字段撰写一封可直接发送的商务邮件。 文档类型{doc_type} 结构化字段 {json.dumps(fields, ensure_asciiFalse)} 额外收件人提示{recipient_hint if recipient_hint else 无} 要求 1. 邮件主题行以【】开头并概括目的例如【合同到期提醒】 2. 邮件正文必须包含上述所有关键字段不得遗漏 3. 语气礼貌、专业根据文档类型切换 - contract 到期提醒催签措辞委婉但明确 - invoice 异常说明金额和编号请求核对 - customer_feedback 投诉先道歉再说明处理态度 4. 输出格式 Subject: 主题 Body: 正文 email_text llm_complete(prompt, temperature0.3) # 简单校验核心字段是否都出现在邮件中 for key, value in fields.items(): if value and value ! 未找到 and value not in email_text: return fERROR: 字段 {key}: {value} 未出现在邮件中请重新生成 return email_text email_tool FunctionTool.from_defaults( fndraft_email, namedraft_email, description输入文档类型和结构化字段撰写对应商务邮件, ) email_agent AgentWorkflow( nameemail_writer, tools[email_tool], state邮件撰写Agent负责根据分类结果生成邮件, verboseTrue, )这个实现有几个值得展开的细节。温度设为0.3而不是0是因为邮件撰写是生成任务需要一点随机性来让措辞自然但又不允许过度发挥。字段校验是纯粹用代码做的硬检查不允许模型说字段已包含就放过它。我甚至见过模型在邮件里写您的合同编号为XXXX——真把占位符写进去了所以硬校验必须做。3.3 数据联动与上下文传递的细节两个Agent之间怎么传数据这个环节很多人会写错。最直接的错误是把原始文档文本直接传给邮件Agent让它自行处理。这样做的后果是邮件Agent承担了分类加抽取加撰写的全部工作Prompt又会变得臃肿输出质量重新回到正确废话的水平。正确做法是让分类Agent先完整执行把分类结果对象持久化然后把对象作为邮件Agent的输入。我通常用一个轻量的内存队列分类Agent输出一个文档实例后将结果写入队列邮件Agent消费这个结果再生成邮件。中间任何一步失败都会记录日志并重新触发不会出现邮件已经发了但分类结果是错的这种尴尬。上下文传递还有一个容易忽略的细节Prompt里的字段名和实际提取的字段名必须一致。比如代码里用expiry_datePrompt里也必须是expiry_date不要写成到期日期。模型对字段名的敏感性远超想象字段名不一致会导致模型把关键信息忽略掉这种问题在评估阶段才会暴露出来而且很隐蔽。提示如果邮件Agent生成的邮件在评估里经常漏字段第一反应不要调Prompt而是检查传入的结构化字段本身是否完整。很多时候不是模型不会写而是上游抽取就没抽到。4. 用Promptfoo给智能体装上质量仪表盘4.1 为什么评估必须前置而不是最后补大部分Agent项目死在评估环节。不是说没有评估而是评估做得太晚、太随意。传统做法是开发完直接丢几个样例进去跑一遍肉眼看输出没问题就算完成。等上线后才发现某个类型的文档分类偏了、某类邮件语气不对再回头改Prompt费时费力。Promptfoo的价值在于把评估前置到开发循环里。它做的事情本质上是批量化、可复现、可断言地跑测试用例你定义一批输入和对应的期望输出配置好要调用的模型和Prompt运行一条命令就能看到通过率、失败用例、甚至两个模型版本的对比结果。我建议的用法是这样每改一版Prompt先跑一遍Promptfoo的测试集全部通过才能合并代码。这一条规则看着简单实际贯彻下来能把Agent质量提升一个档次。4.2 promptfooconfig.yaml设计场景、断言与指标下面是我在这类项目里实际用过的Promptfoo配置主要面向文档分类和邮件撰写两个场景。配置文件通常叫promptfooconfig.yaml。# promptfooconfig.yaml prompts: - 对以下文档进行分类请输出纯文本类型标签{{doc_text}} - | 根据文档分类结果撰写邮件要求如下 文档类型{{doc_type}} 结构化字段{{fields}} 必须包含所有字段语气礼貌专业。 providers: - openai:gpt-5.4 config: temperature: 0 tests: # 场景1文档分类 - description: 合同分类-正面-到期条款 vars: doc_text: 本合同编号HT-2024-001甲方为某某公司乙方为某某供应商合同有效期为2024年1月1日至2025年3月31日到期前30日双方应协商续签事宜。 assert: - type: contains value: contract - type: is-json - description: 发票分类-正面 vars: doc_text: 发票号码INV-20250315-88金额为人民币12,500元开票方为某某科技有限公司开票日期为2025年3月15日。 assert: - type: contains value: invoice - type: is-json - description: 合同分类-反例-不应是发票 vars: doc_text: 这是一份采购合同双方约定交付和付款条款。 assert: - type: not-contains value: invoice # 场景2邮件撰写 - description: 合同到期催签邮件-必含到期日 vars: doc_type: contract fields: contract_no: HT-2024-001 expiry_date: 2025-03-31 party_a: 某某公司 party_b: 某某供应商 assert: - type: contains value: HT-2024-001 - type: contains value: 2025-03-31 - type: contains value: 催签 safe: true # 允许AI选择近似表达safe标记为宽松匹配实际按需使用 - description: 发票对账邮件-必含金额 vars: doc_type: invoice fields: invoice_no: INV-20250315-88 amount: 12,500 issuers_name: 某某科技有限公司 assert: - type: contains value: INV-20250315-88 - type: contains value: 12,500跑一下评估的命令很简单promptfoo eval结果会输出到终端也可以生成一个HTML报告promptfoo eval -o report.html配置里有几个设计上的细节。providers里设置了temperature: 0这和我们项目里分类Agent的设定保持一致。评估要想反映真实质量评估环境和实际运行环境必须完全一致否则测了个寂寞。safe: true那个断言我标了注释——实际使用中我很少直接用safe参数更常用的做法是写多个contains去覆盖关键短语避免模型换了个同义表达就误判失败。另一个建议是给每个测试用例配上清晰的description。Promptfoo的报告里会列出这个描述否则一旦有失败用例光看输入输出你根本不知道它测的是什么场景。我吃过的亏是没写描述跑完出现两个失败用例我花了半小时才回忆起来那是在测投诉邮件的场景。4.3 评估结果怎么解读以及怎么把指标喂回给开发跑完Promptfoo拿到通过率只是一个开始。我一般会分三步看结果。第一步看断言通过率。低于80%说明有大问题先别急着调Prompt回头检查工作流和数据链路。第二步看失败的用例集中在哪个场景。如果全部失败在投诉邮件那问题大概率在投诉邮件的Prompt分支或者样例数据本身。第三步看模型输出原文判断是模型没听懂还是任务要求本身模糊。这两类问题的修法完全不同前者要改指令后者要改测试用例。我还会把Promptfoo作为Prompt迭代的回归测试工具。每次调整邮件撰写的Prompt之后运行全量测试集对比通过率变化。这样做最大的好处是一次改动如果导致某个已经通过的场景变差会立刻被暴露而不是上线后由用户发现。注意Promptfoo的断言只能检查文本里有没有某个词它不能判断这句话是否真诚、语气是否得体。所以在自动化评估之外至少保留一小撮人工评审样例专门看那些断言覆盖不到的主观维度。5. 全流程串联从文档进来到评估结果报告5.1 一个端到端的运行链路前面几节分开讲了分类Agent、邮件Agent和评估系统现在把它们串在一起看一个完整的运行链路。我在项目里用一个简单的Python脚本做总控做的事情就三个阶段。第一阶段输入解析。原始文档进来后先统一转成纯文本做简单的长度检查过短的文档标记为待人工确认。第二阶段Agent工作流执行。把文本交给文档分类Agent拿到{type, fields}结构再把这个结构交给邮件撰写Agent生成邮件草稿。第三阶段结果持久化与评估。生成的内容、使用的模型版本、Prompt版本、耗时都记录成一条结构化日志。这条链路里有一个很重要的工程实践版本记录。每个Agent工作流都打上agent_version标签每次Prompt修改都复用Promptfoo的配置作为该版本的锚点。这样做的好处是任何一次线上输出质量问题都能快速定位到哪个版本的哪个Agent在哪个环节出的问题。from dataclasses import dataclass from typing import Optional, Dict, Any dataclass class AgentRunRecord: doc_id: str agent_version: str doc_type: Optional[str] fields: Dict[str, Any] email: str model_name: str prompt_version: str success: bool error_message: Optional[str] None5.2 参数选择与调优记录这个项目里我调过几组参数记录一下实测结果方便参考。第一组是分类Agent的temperature。从0到0.2再到0.5各跑了一遍0和0.2在文档分类准确率上几乎没有差别但0.5开始出现分类标签之间的混淆比如把付款凭证识别成发票。最后定了temperature: 0分类任务不允许任何随机性。第二组是抽取的文本长度。合同类文档经常很长全量塞进去效果不一定好反而是把开头和涉及日期、金额的段落拼接起来效果最好。我试过只取前3000字符、全量文本、以及规则切分后取重点段落三种方案第三种准确率最高但实现成本也最高。项目初期先用前3000字符作为兜底稳定性和成本都居中。第三组是邮件撰写时是否给示例范例。开始不给示例模型写得非常自由格式不统一。后来在Prompt里加了两个few-shot示例一个合同催签邮件一个发票对账邮件格式立刻规整了。这里有个细节few-shot示例的质量要求比线上输入还高模型会模仿示例的措辞风格如果示例本身写得很烂输出会更烂。5.3 线上运行效果与资源占用这套方案跑了一段时间业务侧的反馈是文档分类准确率在测试集上大概是94%左右邮件可用率稍低约87%。分类错误主要集中在项目报告和客户反馈的边界样本上这个我们在评估里提前预判到了。邮件可用率上不去的原因是部分字段抽取失败导致邮件缺数据属于上游问题不是生成问题。资源占用方面单份文档从进入系统到邮件生成完毕平均耗时15秒左右其中大头是两次完整的LLM调用。如果对延迟敏感可以考虑把粗分类和字段抽取合并但准确率会掉2到3个百分点。这就是典型的延迟和准确率的取舍我的建议是只要业务不要求实时就别省这一步。成本方面每份文档处理一次大约消耗的token数在4000到6000之间主要看文档长度。为了防止恶意超长文本导致费用飙升我在进入Agent工作流之前做了截断超过8000字符的文档直接拒绝并提示转人工。这个阈值不是随手定的是测试后发现在8000字符以内抽取准确率随长度增加保持平稳再长就开始下降了。6. 常见问题排查与避坑经验6.1 典型的三个陷阱和一个排查表这个项目从开发到落地我遇到的典型问题基本可以归成三类。第一类是上游抽不出字段下游全乱套。典型表现是分类正确但邮件里总是缺字段。排查思路是先看分类Agent的输出确认结构化字段里到底有没有值再看中间变量是否有截断最后看邮件Agent的Prompt是否引用对了字段名。我遇到过最离谱的一次是字段名里有一个下划线写成了空格模型直接忽略。第二类是评估通过率很高线上表现却不行。这通常是测试用例分布和线上真实数据分布不一致导致的。线上来的文档五花八门测试集里没有覆盖到的边缘格式比如文档是图片扫描件、表格型PDF、中英混排文本一上来就把处理链路打穿了。解决方案是把这些边缘样本不断补充进Promptfoo的测试集让评估集跟着线上数据一起演进。第三类是GPT-5.4输出随机带来的偶发性失败。即便我们设置了temperature为0模型在某些情况下依然会输出异常格式比如多包一层引号、漏掉一个括号。这类问题不能靠改Prompt根除必须用代码做输出层的防御式解析。我的经验是每一个LLM输出都要过一层格式校正器负责清理多余符号、修复JSON括号、截断非法输出。别嫌丑这个丑东西能救你一命。现象排查方向常见解法分类类型偶尔不稳定温度设置、Prompt枚举约束temperature设为0明确要求只输出枚举值邮件经常漏关键字段上游字段抽取是否完整、字段名是否一致硬校验字段是否出现在邮件正文token成本偏高文本全量塞入、Prompt冗余截断策略、字段精简、few-shot不超过2个评估通过但线上差测试集与真实分布不一致把线上边缘样本反向补充进测试集模型输出偶尔非法格式模型随机性增加输出格式校正器而非依赖Prompt6.2 我的几点实操心得回顾这个项目有几个心得是真正从踩坑里长出来的。第一个心得Agent项目里Prompt的质量上限低于工具链的质量上限。你Prompt写得多完美结构字段抽取不出来一切都白搭。所以投入时间去打磨工具函数、做数据清理、做输出校验性价比要远高于反复调Prompt。第二个心得评估体系要跟着业务一起进化不要指望一次搭好一劳永逸。Promptfoo的测试集每周我都会补充几条新用例遇到线上异常样本就顺手加进去。这条习惯坚持下来Agent的回归测试集越来越厚系统也越来越稳。第三个心得结构化中间结果胜于一切微调。文档分类输出结构化的type fields带来的收益比任何Prompt技巧都大。因为它让系统从一段文本流到另一段文本变成了一段文本变成数据数据再变成另一段文本。一旦中间层是结构化数据调试、评估、替换模型全都变得清晰可控。第四个心得在正式用Promptfoo全量评估Agent之前可以先拿它只测单个Prompt的效果。比如先测分类Prompt在50条数据上的准确率再测抽取Prompt在20条人工标注数据上的字段命中率最后再全链路测。从小处着手定位问题的速度会快非常多。我个人现在做任何Agent项目都会默认带上一套评估配置哪怕只是最基础的场景覆盖。不跑评估就发布Agent就像不带安全网走钢丝——也许运气好能走完但掉下去的代价太惨痛。LlamaAgents Builder、Promptfoo、GPT-5.4这一套组合我实测下来稳定性可接受迭代效率是真的高。这个内容后续还可以往多Agent协作、自动评估集生成的方向继续扩展如果你正好也在做类似的智能体项目建议你也从这套构建加评估的闭环开始。