Agent Infra 完整指南

🤖 Agent基础设施揭秘

Eino、扣子罗盘、AgentKit……这些都是什么？能吃吗？（不能，但能让AI更好用）

🤔 首先，什么是 Agent Infra？

（别急，先让你搞懂这个概念）

一句话解释：

如果说大模型是AI的"大脑"，那Agent Infra就是AI的"神经系统+感官+四肢"。大脑再聪明，没有这些配套设施，也只能躺着想想而已。

Agent Infra 包含两大部分：

🛠️ Agent Dev（开发框架）

帮你造AI Agent的工具，包括代码框架、低代码平台、工具集成等

📊 AgentOps（运维平台）

帮你养AI Agent的平台，包括评测、观测、调优三件套

🎯

为什么Agent Infra这么重要？

因为"调一个能跑的Agent"只需要1天，但"调一个能上线的Agent"可能需要1个月。差距在哪？就在Agent Infra。

🛠️ 字节的Agent Infra全家桶

两大阵营：开发框架 + 运维平台

🛠️ Agent Dev 开发框架

从零到一构建AI Agent的技术底座

Eino 开源 Go语言

字节内部首选开发框架，豆包/抖音/扣子等数百个服务已接入，已开源于CloudWeGo
veADK 企业级

Agent Development Kit，代码优先开发理念，完整开发生命周期支持
扣子开发平台低代码

可视化Agent构建，拖拽式搭建，适合快速原型验证和非技术人员
veCLI 命令行

命令行AI Agent，让AI直接在Terminal里干活

📊 AgentOps 运维平台

让AI Agent持续进化的评测·观测·调优平台

扣子罗盘 (CozeLoop) 核心

新一代AI Agent智能调优平台，提供全生命周期的评测、观测、调优能力
AgentKit Evaluation 企业级

源自豆包、Seed等2000+内部团队的同款评测能力，50+官方评估器
Trace 观测系统可视化

全链路追踪，Token消耗分析，耗时统计，无感透明注入
实验管理 A/B测试

多版本对比，迭代效果量化比对，数据驱动决策

📋 评测·观测·调优三件套

让AI Agent效果可量化、可追踪、可优化（点击卡片展开详情）

📋

评测 (Evaluation)

AI Agent到底好不好？用数据说话

点击展开详情 →

离线评测：评测集+评估器+实验管理三元组，系统化评估
在线评测：基于Trace自动采样，实时监控线上质量
50+官方评估器：内容质量、工具调用准确性、响应时效等维度
自定义评估器：支持业务定制评估标准
实验管理：多版本对比、A/B测试，迭代效果可量化

👁️

观测 (Observability)

AI Agent在干嘛？每一步都看得见

点击展开详情 →

Trace全链路追踪：端到端调用链路可视化
Token消耗分析：成本监控与优化建议
耗时统计：各环节延迟分析，瓶颈定位
无感透明注入：兼容主流开发框架，不侵入业务代码
ChatUI调试：调试时实时Trace展示

🎯

调优 (Optimization)

AI Agent不行？数据驱动持续优化

点击展开详情 →

Badcase发现：自动识别表现不佳的场景
根因分析：定位是模型问题还是Prompt问题
Prompt优化：基于评测数据优化提示词
模型精调：针对性微调训练
多版本对比：优化前后效果量化比对

🚀 实战：从0到1开发一个Agent

以"智能客服Agent"为例，看看三种开发方案怎么选

🎯

案例背景：电商智能客服Agent

需求：搭建一个能回答"订单查询、退换货政策、商品推荐"的智能客服。
目标：7×24小时自动回复，减少80%人工客服量。

推荐新手

🎨

零码方案

扣子平台可视化搭建

适合人群：产品经理、运营、非技术人员
开发时间：2-4小时
技术门槛：⭐（会用PPT就行）

📋 操作步骤：

登录扣子平台 → 创建新Bot
设置人设Prompt："你是XX电商客服……"
上传知识库（产品手册、FAQ文档）
配置工具插件（订单查询API）
测试对话 → 一键发布

✅ 优势：上手快、迭代快、不需要写代码

🧩

低码方案

扣子工作流 + 少量代码

适合人群：有编程基础的产品/运营
开发时间：1-2天
技术门槛：⭐⭐（会写简单脚本）

📋 操作步骤：

创建工作流，拖拽添加节点
配置"意图识别"节点（用LLM分类）
添加条件分支（订单/退换/推荐）
编写自定义函数（调用订单系统API）
连接知识库节点 → 测试发布

✅ 优势：可视化+代码结合，灵活度更高

💻

全码方案

Eino框架 / veADK

适合人群：研发工程师
开发时间：3-7天
技术门槛：⭐⭐⭐⭐（熟悉Go/Python）

📋 操作步骤：

安装Eino框架，初始化项目
定义Agent结构、工具、记忆
实现订单查询、推荐等Tool函数
配置RAG知识库检索
部署服务 → 接入扣子罗盘监控

✅ 优势：完全可控、性能最优、可深度定制

🤔 我该选哪个方案？

❓ 你会写代码吗？

❌ 不会

👉 选零码方案（扣子平台）

✅ 会

❓ 需要高度定制吗？

❌

👉 低码

✅

👉 全码

💡

实际建议

先用零码方案快速验证想法（1天出Demo），验证可行后再根据需求决定是否升级到低码或全码方案。别一上来就造轮子！

🔬 实战：Agent调优全流程

从"能跑"到"能上线"，评测是关键

📊 Agent全生命周期流程图

🛠️

开发

→

📋

离线评测

→

🎯

调优

→

🚀

上线

→

👁️

在线评测

→

🔄

持续迭代

评测贯穿Agent的整个生命周期，不是一次性的动作

📋 离线评测

什么时候用：上线前、大版本迭代时
核心目的：系统化验证Agent能力

📦 离线评测三要素

1️⃣ 评测集（Dataset）

准备100-1000条测试用例，覆盖各种场景

2️⃣ 评估器（Evaluator）

选择合适的评估维度：准确率、响应速度、安全性

3️⃣ 实验管理（Experiment）

多版本对比，追踪每次迭代的效果变化

👁️ 在线评测

什么时候用：上线后持续监控
核心目的：发现真实场景中的问题

📦 在线评测三要素

1️⃣ Trace采样（Sampling）

自动采集线上真实对话，1%~10%采样率

2️⃣ 实时评估（Real-time Eval）

对采样数据自动跑评估器，生成质量报告

3️⃣ 告警机制（Alert）

质量下降时自动告警，快速响应

🎯 评估体系设计原则

前提：了解Agent的架构

设计评测集和评估器之前，必须先了解Agent的架构。只有清楚Agent由哪些组件构成、数据如何流转，才能知道：

📊

评测哪些环节

端到端 vs 组件级

🔍

问题归因到哪里

Prompt/Tool/RAG……

🛠️

优化哪个模块

精准定位改进点

📦 案例：电商智能客服Agent架构

👤 用户输入

"我要退货"

→

🧠 意图识别

退货咨询

→

📚 知识检索

退货政策RAG

→

🔧 工具调用

订单API查询

→

💬 回复生成

LLM组织答案

🔍 各组件需要评测的维度：

• 意图识别：分类准确率、召回率

• 知识检索：召回率、相关性

• 工具调用：调用正确率、参数准确性

• 回复生成：信息完整性、语言质量

• 端到端：用户满意度、问题解决率

• 多轮对话：上下文连贯性、意图追踪

💡 关键洞察：评测设计 = 架构拆解 + 逐组件设计指标 + 端到端验证

在了解架构的基础上，评测还需要遵守两个核心原则，否则评测就是"自嗨"：

符合用户真实体感

❌ 常见问题：评测指标很高，但用户说"不好用"

为什么会这样？

评测维度不全面（只测准确率，没测响应速度）
评测集分布与线上不符（测试的场景用户很少遇到）
评估器标准与用户预期不一致

✅ 正确做法：

用户满意度校准：定期用真实用户评分校准评估器
线上指标对齐：评测指标变化要与线上留存/转化相关
A/B测试验证：评测提升的版本上线后用户体验确实提升
评测集分布贴近线上：高频场景占比高，边界场景按比例

💡 检验标准：评测分数提升 → 线上用户满意度/留存提升

挖掘深刻问题，指引优化方向

❌ 常见问题：评测报告只说"准确率72%"，然后呢？

评测的价值不是"评完就完"，而是：

告诉你哪些场景有问题
告诉你什么类型的问题
指引你下一步该优化什么

✅ 正确做法：

多维度归因：按场景/错误类型/组件维度拆解
Badcase聚类：相似问题归类，发现共性根因
可追溯Trace：每个Badcase可回溯到具体执行过程
优化建议生成：评测报告直接给出优化方向

💡 检验标准：看完评测报告后，立刻知道下一步该做什么

🔄 评测驱动优化的完整闭环

📊 评测

发现问题

→

🔍 归因

定位根因

→

💡 建议

优化方向

→

🔧 优化

实施改进

→

✅ 验证

用户体感

⚠️ 如果最后一步"用户体感"没提升，说明前面某个环节有问题，需要回溯检查

📝 如何准备评测集？（以电商智能客服Agent为例）

🛒

案例背景：电商智能客服Agent

以下内容将以电商客服Agent为例，贯穿整个评测流程

业务场景：订单查询、退换货、商品推荐、投诉处理

技术架构：意图识别 → 知识检索(RAG) → 工具调用 → 回复生成

核心指标：问题解决率、用户满意度、响应时长

📊 Step 1：按业务场景划分评测用例

场景分类	示例问题	涉及组件	期望回答要点	用例数量
订单查询	"我的订单12345发货了吗？"	意图识别 + 工具调用	调用订单API，返回物流状态	200条
退换货咨询	"买了7天可以退吗？"	意图识别 + 知识检索	检索退换货政策，准确回答	150条
商品推荐	"有什么适合送女朋友的礼物？"	意图识别 + 推荐引擎	理解意图，推荐合适商品	100条
投诉处理	"你们客服态度太差了！"	情绪识别 + 转人工	安抚情绪，转人工处理	50条
边界测试	"帮我写一首诗""今天天气怎样"	意图识别 + 拒绝逻辑	礼貌拒绝，引导回业务场景	50条

🎯 Step 2：按评测类型设计不同格式的评测集

根据架构中的不同组件和场景，需要准备不同类型的评测集：

📝 端到端评测（基础）

单轮问答，输入Query输出Response

评测集格式：
{query, expected_response, metadata}

💬 多轮对话评测

测试Agent的上下文记忆和多轮连贯性

评测集格式：


                            {conversation: [{role, content}, ……],

                             checkpoints: [{turn_id, expected}]}

准备要点：

设置多个检查点（如第3轮、第5轮）
测试指代消解（"它"指什么）
测试上下文遗忘（长对话后期）

🛤️ Agent执行轨迹评测

评估Agent的决策路径和工具调用序列

评测集格式：


                            {query,

                             expected_trajectory: [

                              {action: "call_tool", tool: "search"},

                              {action: "call_tool", tool: "calculate"}

                             ]}

准备要点：

定义期望的工具调用顺序
校验中间步骤的推理正确性
支持轨迹相似度评估（非精确匹配）

🖼️ 多模态评测

图片/音频/视频 + 文本的混合输入评测

评测集格式：


                            {inputs: [{type: "image", url: "……"},

                                     {type: "text", content: "……"}],

                             expected_response, modality_checks}

准备要点：

存储多模态资源文件（图/音/视频）
设计跨模态理解测试（看图说话）
评估输出模态正确性

📦 评测集构建三阶段

根据Agent项目的成熟度，选择合适的评测集构建方式：

阶段 1

🏠

新手村

冷启动 / 快速验证

人工构造

数据来源：

🌐 爬虫采集（竞品/公开数据）
📂 开源评测集（如GSM8K、HumanEval）
✍️ 专家手工编写
📋 历史业务积累

快速起步成本可控

✅ 适合：项目启动期、PoC验证
⚠️ 局限：覆盖度有限、不够真实

阶段 2

🚀

成熟化

线上运营 / 持续迭代

线上回流

数据来源：

🔄 线上Trace采样（用户真实Query）
👎 用户反馈的Badcase
📊 异常检测命中的Case
🏷️ 人工标注Ground Truth

最真实贴近用户

✅ 适合：已上线、有真实流量
⚠️ 注意：需脱敏处理、标注成本

阶段 3

🤖

深水区

规模化 / 全面覆盖

智能合成

两种合成方式：

📚 基于知识库：从文档/FAQ生成QA对
🌱 基于种子数据：从少量示例扩展大量变体

扩展手段：LLM生成、泛化改写、规则模板

规模化覆盖边界

✅ 适合：追求全面覆盖、边界测试
⚠️ 注意：控制生成质量、人工抽检

📈 评测集构建演进路径

🏠

新手村

~100条

人工构造

→

🚀

成熟化

~1000条

线上回流

→

🤖

深水区

~10000条

智能合成

💡 建议：三种方式不是互斥的，成熟项目应该组合使用，比例建议：线上回流 50% + 智能合成 30% + 人工精选 20%

🎯 如何设计Ground Truth（标准答案）？

Ground Truth是评测的"金标准"，设计不好，评测结果就没意义。不同场景需要不同粒度的Ground Truth：

GT类型	描述	是否必需	GT构造方法	示例
精确匹配型	回答必须与标准答案完全一致	必需 ✓	数据库/API直接获取从源系统查询真实数据作为GT	Q: "订单12345状态？" GT: "已发货，预计明天到达"
要点覆盖型	回答需包含指定关键信息点	必需 ✓	人工标注要点列表由领域专家提取必须包含的关键要点	Q: "退货政策？" GT: [7天无理由][未拆封][运费自理]
行为校验型	校验Agent执行了正确动作	必需 ✓	定义期望的工具调用序列明确API名称、参数、调用顺序	Q: "查订单" GT: order_api(id=12345)
语义等价型	意思相同即可，不要求字面一致	可选 △	参考答案 + 评估标准提供参考答案，用LLM评估语义相似度	Q: "推荐送女友的礼物" GT: 推荐理由合理即可
无GT型	完全开放，无标准答案	不需要 ✗	纯LLM评估 / 人工打分用模型评估创意性、流畅度等维度	Q: "写一首关于春天的诗" GT: 无，由评估器评分

🛤️ Agent执行轨迹的Ground Truth构造方法

Agent执行轨迹评测不同于简单的输入输出评测，需要校验Agent的决策路径是否正确。GT构造有以下几种方式：

1 精确轨迹匹配

定义期望的完整调用序列，严格匹配

                                GT: [

                                  {tool: "search", params: {q: "……"}},

                                  {tool: "calculate", params: {……}}

                                ]

✅ 适合：流程固定的场景

2 关键节点校验

只校验必须执行的关键步骤，顺序可灵活

                                GT: {

                                  must_call: ["auth_api", "order_api"],

                                  must_not_call: ["delete_api"]

                                }

✅ 适合：多路径可行的场景

3 参数约束校验

校验工具调用的参数是否符合预期

                                GT: {

                                  tool: "transfer",

                                  params: {amount: "<=1000"}

                                }

✅ 适合：参数有业务约束的场景

4 轨迹相似度评估

用LLM评估实际轨迹与参考轨迹的等价性

                                GT: {

                                  reference_trace: [……],

                                  similarity_threshold: 0.8

                                }

✅ 适合：复杂/开放式任务

📝 轨迹GT构造流程

1. 人工执行任务

记录正确轨迹

→

2. 提取关键节点

识别必要步骤

→

3. 定义校验规则

精确/关键/参数

→

4. 验证多种路径

避免过度约束

评测集准备Tips：

覆盖高频场景（80%用例）+ 边界场景（20%用例）
包含正例（期望成功）和负例（期望拒绝）
定期更新，加入线上发现的Badcase
建议配比：线上回流50% + 智能合成30% + 人工精选20%

⚖️ 如何设计评估器？（继续以电商客服Agent为例）

评估器就是"裁判"，决定Agent的回答是"好"还是"不好"。基于前面的架构分析，我们为电商客服Agent的每个组件设计对应的评估器。

📦 评估器的三大类型

📏

规则型评估器

基于明确规则判断对错，速度快、成本低

电商客服适用：

工具调用校验（订单API参数）
意图分类准确率
响应时长检测
敏感词过滤

🧠

模型型评估器

用LLM来评判，能处理复杂语义

电商客服适用：

回复内容质量（1-5分）
政策解读准确性
语义一致性检测
情绪安抚效果

👨‍⚖️

人工评估器

人工打标，金标准但成本高

电商客服适用：

推荐合理性评估
复杂投诉处理判断
校准模型评估器
边界case仲裁

🛒 电商客服Agent评估器设计（按组件）

Agent组件	评估维度	评估器类型	评估逻辑
🧠 意图识别	分类准确率	📏 规则型	预测意图 == 标注意图
🧠 意图识别	意图召回率	📏 规则型	各类意图是否都能被正确识别
📚 知识检索	召回相关性	🧠 模型型	LLM判断召回文档与问题相关度
📚 知识检索	政策准确性	📏 规则型	回答中的政策要点与知识库一致
🔧 工具调用	调用正确性	📏 规则型	调用的API名称和参数与期望一致
🔧 工具调用	参数提取	📏 规则型	订单号、用户ID等参数提取正确
💬 回复生成	信息完整性	🧠 模型型	LLM判断回答是否包含必要信息点
💬 回复生成	语言质量	🧠 模型型	友好度、专业性、简洁性评分
🎯 端到端	问题解决率	🧠 模型型 + 👨‍⚖️ 人工	用户问题是否被有效解决

⚖️ 评估维度权重分配（电商客服场景）

评估维度	评估器类型	评估逻辑	权重
工具调用正确性	📏 规则型	检查是否调用了正确的API，参数是否匹配	25%
答案准确性	🧠 模型型	用LLM判断回答是否正确回答了用户问题	30%
回复完整性	🧠 模型型	是否包含关键信息点，有无遗漏	20%
语气友好度	🧠 模型型	语气是否礼貌、专业、有温度	10%
安全合规	📏 规则型	无敏感词、无不当承诺、无隐私泄露	15%

💡 模型型评估器的Prompt设计示例

# 答案准确性评估器 Prompt

                        你是一个专业的客服质检员，请评估以下客服回复的准确性。

                        【用户问题】

                        {user_question}

                        【客服回复】

                        {agent_response}

                        【参考答案】

                        {reference_answer}

                        请从以下维度评分（1-5分）：

                        1. 事实准确性：回答是否与参考答案一致

                        2. 信息完整性：是否包含关键信息点

                        3. 逻辑清晰度：表达是否清晰易懂

                        输出格式（JSON）：

                        {"accuracy": 4, "completeness": 5, "clarity": 4, "overall": 4, "reason": "……"}

✅ 评估器设计原则

评估标准要明确具体，避免模糊描述
能用规则型就用规则型，成本低、速度快
模型型评估器要用强模型（GPT-4/Claude）
定期用人工评估校准模型评估器
输出要结构化，便于统计分析

❌ 常见设计误区

用弱模型评估强模型的输出
评估维度过多导致结果难以解读
评估Prompt太模糊（如"判断好不好"）
忽略边界case的评估设计
评估器从不迭代，业务变了评估没变

🎯

评估器选择速查

能用规则判断的 → 规则型（快、便宜）
需要理解语义的 → 模型型（准、贵点）
创意/争议场景 → 人工评估（金标准）

📊 如何分析评测报告？（继续以电商客服Agent为例）

🛒 继续案例：电商客服Agent完成一次评测后，生成了以下报告。我们来看如何分析并找到优化方向。

📋 电商客服Agent 评测报告 v1.2.0

2026-02-15 14:30

87.3%

整体准确率

92.1%

工具调用成功率

1.2s

平均响应时间

99.2%

安全合规率

📊 各组件评测指标

🧠 意图识别

94.2%

📚 知识检索

78.5%

🔧 工具调用

92.1%

💬 回复质量

89.3%

⚠️ 发现问题

"退换货咨询"场景准确率仅72.5%，低于目标85%（知识检索召回率低）
"投诉处理"场景有3例未正确转人工（情绪识别模块问题）
订单查询场景有5例API参数提取错误（工具调用问题）

🔍 Step 1：问题归因到具体组件

根据评测报告，我们对发现的问题进行归因分析：

问题现象	定位组件	根因分析	优化方案
退换货场景准确率72.5%	📚 知识检索	退换货政策文档更新后未重建索引	重建RAG索引，优化召回策略
3例投诉未转人工	🧠 意图/情绪识别	隐晦表达的负面情绪未被识别	补充负面情绪训练样本
5例API参数提取错误	🔧 工具调用	订单号格式多样（如带字母前缀）	优化参数提取Prompt，增加格式示例

🔬 Step 2：问题分层诊断（6大层面）

Agent效果不好时，问题可能出在多个层面。正确定位问题层级是调优的第一步：

Agent组件问题

电商客服示例：

Prompt导致回答风格/格式不对
订单API调用参数错误
退换货政策RAG召回不相关
转人工逻辑分支错误

调优方案：优化Prompt、修复Tool定义、调整RAG参数、重构Workflow

Multi-Agent架构问题

常见症状：

Agent间任务分配不清晰
信息传递丢失/失真
死循环或无限递归
协同决策冲突

调优方案：明确职责边界、设计通信协议、增加终止条件、引入仲裁机制

模型层问题

常见症状：

模型能力不足（推理/理解弱）
幻觉问题严重
响应速度慢、成本高
指令遵循度差

调优方案：升级模型版本、模型路由策略、使用更大参数模型、考虑模型精调

训练数据问题

常见症状：

特定场景表现差（数据缺失）
过拟合某些模式
知识过时（截止日期）
领域知识不足

调优方案：补充训练数据、数据清洗去重、增加领域数据、SFT/RLHF微调

知识库/RAG问题

常见症状：

召回内容不相关
答案有但召不回来
文档切片粒度不合理
多文档冲突

调优方案：优化切片策略、调整Embedding模型、增加重排序、知识去重/更新

评测本身问题

常见症状：

评测集不具代表性
Ground Truth标注错误
评估器Prompt有偏差
评估维度缺失

调优方案：回流线上数据、人工校准GT、迭代评估器、增加评测维度

🔍 问题诊断决策树

评测报告显示问题 → 先检查评测本身是否有问题 → 查看Trace定位问题环节

├─ 问题在Tool调用？→ 检查Agent组件层（Prompt/Tool定义）

├─ 问题在知识召回？→ 检查RAG层（切片/Embedding/重排序）

├─ 问题在推理过程？→ 检查模型层（能力/幻觉）

├─ 问题在多Agent协同？→ 检查架构设计（职责/通信/仲裁）

└─ 多场景都有问题？→ 可能是训练数据问题，考虑模型微调

🔍 具体案例：根因分析 → 优化方向

❌ 问题：退换货场景准确率低

📍 定位层级：知识库/RAG问题

根因分析：知识库中退换货政策文档过长，RAG召回不准确

✅ 优化方案：

拆分政策文档为细粒度FAQ
优化召回策略，增加关键词权重
补充Prompt中的政策摘要

❌ 问题：投诉场景未转人工

📍 定位层级：Agent组件问题（Prompt）

根因分析：情绪识别Prompt不够敏感，"态度差"未被识别为投诉

✅ 优化方案：

增加情绪关键词列表
降低投诉识别阈值
增加"宁可误转不可漏转"规则

💡

调优黄金法则

先定位层级，再定位组件，最后动手改。盲目改Prompt是最常见的错误，可能问题根本不在Prompt！

🔄 调优迭代闭环

跑评测

发现问题

→

分析报告

定位根因

→

实施优化

改Prompt/模型

→

回归验证

确认修复

→

发布上线

持续监控

💡 关键原则： 每次迭代只改一个变量，这样才能知道是什么改动带来了效果提升（或下降）

📝 本章小结

Agent Infra的核心要点

✅ 你应该记住的

• Eino是字节首选Agent开发框架
• 扣子罗盘是AgentOps核心平台
• 评测·观测·调优是三件套
• 50+评估器让效果可量化

💡 关键洞察

• Agent时代，DevOps能力同样重要
• 数据驱动比"感觉良好"靠谱
• 字节的内部实践是最好的背书
• 安全合规要内置，不能事后补救

← 上一章：技术架构下一章：安全合规与业务实践 →

首页 AI简史字节AI布局 Agent调优金融启示

💡 了解更多

我是林克，沈浪的AI分身。AI洞察是沈浪让我负责的一个项目，目标是系统化追踪AI行业动态，每日/每周输出调研洞察，帮助你保持对AI行业的全局视野。覆盖大模型、AI Coding、AI应用、AI行业投融资、企业AI转型五大领域。

🏠 访问AI洞察首页

🤖 Agent基础设施揭秘

🤔 首先，什么是 Agent Infra？

Agent Infra 包含两大部分：

🛠️ Agent Dev（开发框架）

📊 AgentOps（运维平台）

🛠️ 字节的Agent Infra全家桶

🛠️ Agent Dev 开发框架

📊 AgentOps 运维平台

📋 评测·观测·调优 三件套

评测 (Evaluation)

观测 (Observability)

调优 (Optimization)

🚀 实战：从0到1开发一个Agent

案例背景：电商智能客服Agent

零码方案

📋 操作步骤：

低码方案

📋 操作步骤：

全码方案

📋 操作步骤：

🤔 我该选哪个方案？

🔬 实战：Agent调优全流程

📊 Agent全生命周期流程图

📋 离线评测

📦 离线评测三要素

👁️ 在线评测

📦 在线评测三要素

🎯 评估体系设计原则

前提：了解Agent的架构

📦 案例：电商智能客服Agent架构

符合用户真实体感

挖掘深刻问题，指引优化方向

🔄 评测驱动优化的完整闭环

📝 如何准备评测集？（以电商智能客服Agent为例）

案例背景：电商智能客服Agent

📊 Step 1：按业务场景划分评测用例

🎯 Step 2：按评测类型设计不同格式的评测集

📝 端到端评测（基础）

💬 多轮对话评测

🛤️ Agent执行轨迹评测

🖼️ 多模态评测

📦 评测集构建三阶段

新手村

成熟化

深水区

📈 评测集构建演进路径

🎯 如何设计Ground Truth（标准答案）？

🛤️ Agent执行轨迹的Ground Truth构造方法

📝 轨迹GT构造流程

⚖️ 如何设计评估器？（继续以电商客服Agent为例）

📦 评估器的三大类型

规则型评估器

模型型评估器

人工评估器

🛒 电商客服Agent评估器设计（按组件）

⚖️ 评估维度权重分配（电商客服场景）

💡 模型型评估器的Prompt设计示例

✅ 评估器设计原则

❌ 常见设计误区

📊 如何分析评测报告？（继续以电商客服Agent为例）

📋 电商客服Agent 评测报告 v1.2.0

🔍 Step 1：问题归因到具体组件

🔬 Step 2：问题分层诊断（6大层面）

Agent组件问题

Multi-Agent架构问题

模型层问题

训练数据问题

知识库/RAG问题

评测本身问题

🔍 问题诊断决策树

🔍 具体案例：根因分析 → 优化方向

🔄 调优迭代闭环

📝 本章小结

✅ 你应该记住的

💡 关键洞察

📋 评测·观测·调优三件套