构建Agentic AI的实用技巧1. 构建 Agentic AI 的实用技巧1.1 4.1 评估Evals想提升 Agent 系统的效果首先要搞清楚到底是哪个环节导致了效果变差。评估系统的作用就在于此。快速原型和迭代是关键。推荐的方法先构建一个简易但功能完整的原型 → 试运行并观察输出 → 找出表现不佳的地方 → 针对性建立评估。1.1.1 案例一发票处理有明确答案系统从发票中提取四个必填字段特别是到期日。手动检查 10-20 张发票后发现系统经常混淆发票的开具日期和到期日。发票处理工作流构建评估找 10-20 张发票人工记录正确到期日作为对照在提示词中要求 LLM 以固定的年-月-日格式输出便于自动检查编写代码提取日期并与正确答案比对调整系统后用这个指标衡量是否有提升日期混淆问题1.1.2 案例二营销文案助理无明确答案有统一标准为 Instagram 图片生成标题要求最多 10 个词。观察发现内容不错但经常超长。构建评估准备 10-20 个测试任务编写代码计算输出词数与 10 词限制比对。这个评估没有每个例子的正确答案但有统一的长度标准。1.1.3 案例三研究智能体主观评估Agent 根据用户主题撰写研究文章。检查发现人类专家会捕捉到的重要观点Agent 有时会遗漏。研究智能体构建评估针对每个主题人工准备 3-5 个黄金标准讨论点。用 LLM 作为裁判统计文章提到了多少个标准点并打分。1.1.4 评估的 2×2 矩阵评估方式从两个维度划分客观评估代码检查主观评估LLM 裁判有每例基本事实发票日期提取每张发票有不同正确日期代码比对研究观点覆盖每个主题有不同重要观点LLM 检查覆盖度无每例基本事实文案长度检查所有标题统一 10 词标准代码统计评分量表评估根据统一标准如清晰度打分几个实用建议从 10-20 个例子开始快速获得指标不要追求完美如果系统改进了但评估分数没提高说明该改进评估本身了以专业人士的行为为灵感观察系统在哪些方面不如人类专家1.2 4.2 错误分析当系统变得复杂后仅靠直觉判断哪个环节出了问题已经不够。错误分析的核心是观察和量化找出工作流程中表现最差的组件。1.2.1 检查 Traces 和中间输出Trace 是代理运行过程中每一步产生的中间输出的集合单步输出称为 span。方法查看 trace观察每个步骤的输出质量。以科研资料查询 Agent 为例步骤 1生成搜索词请人类专家判断搜索词是否合理步骤 2网页搜索结果检查返回的 URL 和文章质量是否太多非科学博客步骤 3信息筛选LLM 是否选择了严肃的科研文章而非夺人眼球的水文1.2.2 聚焦错误并量化将精力集中在最终输出不令人满意的案例上建立电子表格统计每个组件出现错误的频率。统计示例如果发现对搜索结果不满意的频率远高于对搜索词不满意的频率如 45% vs 5%工作重点就应放在改进搜索引擎而不是更改搜索词生成逻辑。1.3 4.3 错误分析实例1.3.1 案例一发票处理工作流程PDF → PDF 转文本 → LLM 数据提取 → 数据库记录发现问题提取的到期日经常出错。收集 10-100 张出错的发票定位错误来源PDF 转文本错误文本提取太差连人类都无法识别到期日LLM 数据提取错误文本输出够好但 LLM 拉错了日期如发票日期而非到期日发票错误定位假设统计发现 LLM 数据提取导致更多错误 → 结论应优化 LLM 提示词而不是改进 PDF 转文本组件。1.3.2 案例二回复客户邮件工作流程客户邮件 → LLM 编写数据库查询 → 数据库 → LLM 起草回复 → 人工审核发现问题最终邮件回复不令人满意。定位错误来源LLM 查询编写错误SQL 查询写错无法获取客户信息数据库数据错误数据本身损坏或不正确LLM 邮件撰写错误信息正确但内容或语气不妥邮件错误定位假设统计LLM 编写查询导致 75% 的错误LLM 撰写邮件只有 30% → 优先级首先改进查询编写方式。1.4 4.4 组件级评估端到端评估和组件级评估的关系类似集成测试与单元测试。端到端评估的问题成本高即使更换搜索引擎这样的小改动都要重跑整个流程其他组件的随机性可能掩盖被改进组件的微小提升。组件级评估的优势信号更清晰避免整体系统的噪声适用于团队分工每个团队自行维护指标。1.4.1 实例研究 Agent 的网页搜索错误分析表明问题主要出在网页搜索组件。构建组件级评估针对少数查询请人类专家提供黄金标准网页资源列表用信息检索领域的标准指标如 F1 分数衡量搜索结果与黄金标准的重叠度用这个指标快速调整搜索参数更换引擎、调整结果数量、日期范围等网页搜索评估工作流程错误分析确定问题组件 → 构建组件级评估进行调优 → 运行端到端评估验证整体提升。1.5 4.5 解决识别到的问题跑完评估、定位问题后下一步是着手改进。1.5.1 非 LLM 组件的改进调参数搜索引擎的结果数量、RAG 的相似度阈值和分块大小、检测模型的阈值换组件尝试不同的服务提供商不同搜索引擎、不同 RAG 引擎找到最适合的1.5.2 LLM 组件的改进方法适用场景成本改进提示词增加明确指令、使用少样本提示低尝试不同 LLM多模型测试用评估选最优低任务分解单步指令太复杂拆成生成反思或多步调用中微调模型穷尽其他方法后仍需挤出最后几个百分点高培养模型选择直觉的方法频繁试玩不同模型、建立个人评估集、阅读他人的提示词、在实际工作流中观察不同模型的 traces 和评估结果。1.6 4.6 延迟与成本优化强调对早期团队高质量输出比延迟和价格重要得多。先让系统跑好再优化速度和成本。1.6.1 优化延迟关键计时基准测试找出瓶颈。延迟分析记录每个步骤的耗时如 LLM 1 耗时 7 秒LLM 3 耗时 18 秒定位最慢的组件优化手段并行化独立步骤、尝试更快的模型或提供商1.6.2 优化成本关键成本基准测试找出最贵的步骤。成本分析计算每个步骤的平均成本LLM 按 token 计费、API 按调用次数计费定位成本贡献最大的组件寻找更便宜的替代方案1.7 4.7 开发过程总结开发 Agent 系统主要在两项活动间切换构建写代码改进系统和分析决定下一步重点。系统从原型到成熟经历四个阶段阶段描述分析方式快速原型先做个能跑的版本手动检查输出通读 trace凭直觉找问题初步评估系统开始成熟构建小型评估集10-20 例计算整体指标严谨分析需要更精确的方向错误分析量化各组件导致问题的频率高效调优组件级精细改进构建组件级评估高效调优单个组件开发是非线性过程需要在调整系统、错误分析、改进组件和调整评估间反复横跳。许多经验不足的团队花太多时间在构建上太少时间在分析上导致工作重点不集中。
4 构建Agentic AI的实用技巧
构建Agentic AI的实用技巧1. 构建 Agentic AI 的实用技巧1.1 4.1 评估Evals想提升 Agent 系统的效果首先要搞清楚到底是哪个环节导致了效果变差。评估系统的作用就在于此。快速原型和迭代是关键。推荐的方法先构建一个简易但功能完整的原型 → 试运行并观察输出 → 找出表现不佳的地方 → 针对性建立评估。1.1.1 案例一发票处理有明确答案系统从发票中提取四个必填字段特别是到期日。手动检查 10-20 张发票后发现系统经常混淆发票的开具日期和到期日。发票处理工作流构建评估找 10-20 张发票人工记录正确到期日作为对照在提示词中要求 LLM 以固定的年-月-日格式输出便于自动检查编写代码提取日期并与正确答案比对调整系统后用这个指标衡量是否有提升日期混淆问题1.1.2 案例二营销文案助理无明确答案有统一标准为 Instagram 图片生成标题要求最多 10 个词。观察发现内容不错但经常超长。构建评估准备 10-20 个测试任务编写代码计算输出词数与 10 词限制比对。这个评估没有每个例子的正确答案但有统一的长度标准。1.1.3 案例三研究智能体主观评估Agent 根据用户主题撰写研究文章。检查发现人类专家会捕捉到的重要观点Agent 有时会遗漏。研究智能体构建评估针对每个主题人工准备 3-5 个黄金标准讨论点。用 LLM 作为裁判统计文章提到了多少个标准点并打分。1.1.4 评估的 2×2 矩阵评估方式从两个维度划分客观评估代码检查主观评估LLM 裁判有每例基本事实发票日期提取每张发票有不同正确日期代码比对研究观点覆盖每个主题有不同重要观点LLM 检查覆盖度无每例基本事实文案长度检查所有标题统一 10 词标准代码统计评分量表评估根据统一标准如清晰度打分几个实用建议从 10-20 个例子开始快速获得指标不要追求完美如果系统改进了但评估分数没提高说明该改进评估本身了以专业人士的行为为灵感观察系统在哪些方面不如人类专家1.2 4.2 错误分析当系统变得复杂后仅靠直觉判断哪个环节出了问题已经不够。错误分析的核心是观察和量化找出工作流程中表现最差的组件。1.2.1 检查 Traces 和中间输出Trace 是代理运行过程中每一步产生的中间输出的集合单步输出称为 span。方法查看 trace观察每个步骤的输出质量。以科研资料查询 Agent 为例步骤 1生成搜索词请人类专家判断搜索词是否合理步骤 2网页搜索结果检查返回的 URL 和文章质量是否太多非科学博客步骤 3信息筛选LLM 是否选择了严肃的科研文章而非夺人眼球的水文1.2.2 聚焦错误并量化将精力集中在最终输出不令人满意的案例上建立电子表格统计每个组件出现错误的频率。统计示例如果发现对搜索结果不满意的频率远高于对搜索词不满意的频率如 45% vs 5%工作重点就应放在改进搜索引擎而不是更改搜索词生成逻辑。1.3 4.3 错误分析实例1.3.1 案例一发票处理工作流程PDF → PDF 转文本 → LLM 数据提取 → 数据库记录发现问题提取的到期日经常出错。收集 10-100 张出错的发票定位错误来源PDF 转文本错误文本提取太差连人类都无法识别到期日LLM 数据提取错误文本输出够好但 LLM 拉错了日期如发票日期而非到期日发票错误定位假设统计发现 LLM 数据提取导致更多错误 → 结论应优化 LLM 提示词而不是改进 PDF 转文本组件。1.3.2 案例二回复客户邮件工作流程客户邮件 → LLM 编写数据库查询 → 数据库 → LLM 起草回复 → 人工审核发现问题最终邮件回复不令人满意。定位错误来源LLM 查询编写错误SQL 查询写错无法获取客户信息数据库数据错误数据本身损坏或不正确LLM 邮件撰写错误信息正确但内容或语气不妥邮件错误定位假设统计LLM 编写查询导致 75% 的错误LLM 撰写邮件只有 30% → 优先级首先改进查询编写方式。1.4 4.4 组件级评估端到端评估和组件级评估的关系类似集成测试与单元测试。端到端评估的问题成本高即使更换搜索引擎这样的小改动都要重跑整个流程其他组件的随机性可能掩盖被改进组件的微小提升。组件级评估的优势信号更清晰避免整体系统的噪声适用于团队分工每个团队自行维护指标。1.4.1 实例研究 Agent 的网页搜索错误分析表明问题主要出在网页搜索组件。构建组件级评估针对少数查询请人类专家提供黄金标准网页资源列表用信息检索领域的标准指标如 F1 分数衡量搜索结果与黄金标准的重叠度用这个指标快速调整搜索参数更换引擎、调整结果数量、日期范围等网页搜索评估工作流程错误分析确定问题组件 → 构建组件级评估进行调优 → 运行端到端评估验证整体提升。1.5 4.5 解决识别到的问题跑完评估、定位问题后下一步是着手改进。1.5.1 非 LLM 组件的改进调参数搜索引擎的结果数量、RAG 的相似度阈值和分块大小、检测模型的阈值换组件尝试不同的服务提供商不同搜索引擎、不同 RAG 引擎找到最适合的1.5.2 LLM 组件的改进方法适用场景成本改进提示词增加明确指令、使用少样本提示低尝试不同 LLM多模型测试用评估选最优低任务分解单步指令太复杂拆成生成反思或多步调用中微调模型穷尽其他方法后仍需挤出最后几个百分点高培养模型选择直觉的方法频繁试玩不同模型、建立个人评估集、阅读他人的提示词、在实际工作流中观察不同模型的 traces 和评估结果。1.6 4.6 延迟与成本优化强调对早期团队高质量输出比延迟和价格重要得多。先让系统跑好再优化速度和成本。1.6.1 优化延迟关键计时基准测试找出瓶颈。延迟分析记录每个步骤的耗时如 LLM 1 耗时 7 秒LLM 3 耗时 18 秒定位最慢的组件优化手段并行化独立步骤、尝试更快的模型或提供商1.6.2 优化成本关键成本基准测试找出最贵的步骤。成本分析计算每个步骤的平均成本LLM 按 token 计费、API 按调用次数计费定位成本贡献最大的组件寻找更便宜的替代方案1.7 4.7 开发过程总结开发 Agent 系统主要在两项活动间切换构建写代码改进系统和分析决定下一步重点。系统从原型到成熟经历四个阶段阶段描述分析方式快速原型先做个能跑的版本手动检查输出通读 trace凭直觉找问题初步评估系统开始成熟构建小型评估集10-20 例计算整体指标严谨分析需要更精确的方向错误分析量化各组件导致问题的频率高效调优组件级精细改进构建组件级评估高效调优单个组件开发是非线性过程需要在调整系统、错误分析、改进组件和调整评估间反复横跳。许多经验不足的团队花太多时间在构建上太少时间在分析上导致工作重点不集中。
