4 构建Agentic AI的实用技巧

构建Agentic AI的实用技巧

1. 构建 Agentic AI 的实用技巧

1.1 4.1 评估（Evals）

想提升 Agent 系统的效果，首先要搞清楚到底是哪个环节导致了效果变差。评估系统的作用就在于此。

快速原型和迭代是关键。推荐的方法：先构建一个简易但功能完整的原型 → 试运行并观察输出 → 找出表现不佳的地方 → 针对性建立评估。

1.1.1 案例一：发票处理（有明确答案）

系统从发票中提取四个必填字段，特别是到期日。手动检查 10-20 张发票后发现，系统经常混淆发票的开具日期和到期日。

发票处理工作流

构建评估：

1. 找 10-20 张发票，人工记录正确到期日作为对照
2. 在提示词中要求 LLM 以固定的年-月-日格式输出，便于自动检查
3. 编写代码提取日期并与正确答案比对
4. 调整系统后用这个指标衡量是否有提升

日期混淆问题

1.1.2 案例二：营销文案助理（无明确答案，有统一标准）

为 Instagram 图片生成标题，要求最多 10 个词。观察发现内容不错，但经常超长。

构建评估：准备 10-20 个测试任务，编写代码计算输出词数，与 10 词限制比对。这个评估没有每个例子的"正确答案"，但有统一的长度标准。

1.1.3 案例三：研究智能体（主观评估）

Agent 根据用户主题撰写研究文章。检查发现，人类专家会捕捉到的重要观点，Agent 有时会遗漏。

研究智能体

构建评估：针对每个主题，人工准备 3-5 个黄金标准讨论点。用 LLM 作为裁判，统计文章提到了多少个标准点并打分。

1.1.4 评估的 2×2 矩阵

评估方式从两个维度划分：

几个实用建议：

• 从 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 的网页搜索

错误分析表明问题主要出在网页搜索组件。构建组件级评估：

1. 针对少数查询，请人类专家提供黄金标准网页资源列表
2. 用信息检索领域的标准指标（如 F1 分数）衡量搜索结果与黄金标准的重叠度
3. 用这个指标快速调整搜索参数（更换引擎、调整结果数量、日期范围等）

网页搜索评估

工作流程：错误分析确定问题组件 → 构建组件级评估进行调优 → 运行端到端评估验证整体提升。

1.5 4.5 解决识别到的问题

跑完评估、定位问题后，下一步是着手改进。

1.5.1 非 LLM 组件的改进

• 调参数：搜索引擎的结果数量、RAG 的相似度阈值和分块大小、检测模型的阈值
• 换组件：尝试不同的服务提供商（不同搜索引擎、不同 RAG 引擎），找到最适合的

1.5.2 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 系统主要在两项活动间切换：构建（写代码改进系统）和分析（决定下一步重点）。

系统从原型到成熟，经历四个阶段：

开发是非线性过程，需要在调整系统、错误分析、改进组件和调整评估间反复横跳。许多经验不足的团队花太多时间在构建上，太少时间在分析上，导致工作重点不集中。