- Introduction to Agents
- Agent Tools & Interoperability with MCP
- → Agent Quality
- Context Engineering: Sessions, Memory
- Prototype to Production 剩下的顺序可能按照3-2-4-5来读。让我们优先来读这篇Quality~ 文中的斜体代表非原文但容易被理解为原文的内容。
依然是超大引用块（看了下其他几篇也都有）
The future of AI is agentic. Its success is determined by quality.
Agent固有的非确定性使其结果具有不一致性。Agent的非确定性来自于内部的随机
不一致性对于软件工程来讲是件麻烦事，对于设计为期望有一致性结果的工具来说出现一致性的调试是很折磨的。这里有三重非确定性：第一重是Agent的过程非确定性；第二重是Agent的结果非确定性；第三重是评估标准非确定性。问题溯源的每一步都有不确定性存在，即概率存在
这本指南基于三部分构建：
- 轨迹是真相：不能只关注最终结果，而需要关注Agent整个决策过程的质量和安全性
- 可观测性是基础：无法判断一个看不到的过程，需要有日志、追踪和指标
- 评估是一个持续循环：Human-in-the-Loop (HITL, 人在回路)讲评估转化为数据，再转化为改进
这篇白皮书有读者定位了：
- 面向所有读者：关注《非确定性世界中的Agent Quality》章节，理解核心问题：为什么传统的QA对AI Agent失效了。认识AI Agents质量评估的四大支柱：有效性、效率、稳健性和安全性。
- 面向产品经理、数据科学家和QA负责人：重点关注《Agent评估艺术：过程评估》章节，了解评估「Outside-In」的层级结构、「LLM-as-a-Judge」的范式和人在循环的重要性。
- 面向工程师、架构师和SRE（站点可靠性工程师）：重点关注《可观测性》章节，了解监控和可观测性的区别，认识三大支柱：日志、追踪和指标。
- 面向团队负责人和策略师：阅读《总结》章节。该章节整合了上述概念形成可操作的手册，介绍了《Agent Quality Flywheel》迭代模型，总结了构建可信AI的三个核心原则。
后三个方向可以理解为「如何评价」、「如何找问题」、「如何迭代」
非确定性世界中的Agent Quality
传统软件比作了送货卡车；AI agent比作了F1赛车。
即使Agent通过了100项单元测试，却仍会在实际应用中出现灾难性故障。
Agent的结果可能性更多了，测试的空间变得更大了
传统软件会问「Did we build the product right?」 AI Agent会问「Did we build the right product?」
AI Agent的能力是非线性的，调用的LM模块的准确结果是不可预估的
为什么Agent质量需要新方法
传统软件中，故障是明确的：系统崩溃、抛出空指针异常，或者返回明显错误的计算结果。通过追溯可以找到问题引入点。但AI agents的错误是质量的细微下降，具有隐蔽性：返回结果成功，输出看似合理，但存在严重错误且有操作危险性。
在传统软件中的复杂优化问题也会有细微质量下滑的现象，是较难识别的
未能把握这一转变的组织将面临重大失败、运营效率低下和声誉受损的风险。
可以预见未来更多的AI Agent软件上线后，会看到很多奇奇怪怪的bug
以下是四种现实世界的失败模式：
| 故障模式 | 描述 | 示例 |
|---|---|---|
| 算法偏见 (Algorithmic Bias) | 智能体在运行中执行并可能放大训练数据中存在的系统性偏见，导致不公平或歧视性的结果。 | • 负责风险总结的金融智能体，根据训练数据中的偏见，对特定邮政编码的贷款申请进行过度惩罚。 |
| 事实幻觉 (Factual Hallucination) | 智能体生成看似合理但实际上错误或虚构的信息，且表现出极高的自信。这通常发生在它无法找到有效来源时。 | • 研究工具在学术报告中生成了一个非常具体但完全错误的日期或地理位置，损害了学术诚信。 |
| 性能与概念漂移 (Performance & Concept Drift) | 随着智能体交互的现实世界数据（即“概念”）发生变化，其原始训练内容变得过时，导致智能体的性能随时间而下降。 | • 欺诈检测智能体无法识别出新的攻击模式。 |
| 突发非预期行为 (Emergent Unintended Behaviors) | 智能体为了实现目标而演化出新颖或意想不到的策略，这些策略可能效率低下、无益甚至具有剥削性。 | • 寻找并利用系统规则中的漏洞。 • 与其他机器人进行“代理战争”（例如：反复覆盖对方的编辑内容）。 |
这些问题无法用断点调试来解决。一致性问题导致问题复现的概率指数下降
无法编写单元测试来防止涌现性偏见。无法定义边界case
需要深入数据分析、模型重新训练和系统性评估 — 这是一门新学科
算法偏见：根据数据驱动的招聘算法已经有很强的偏见
事实幻觉：文献准确度这几年已经提升了不少；Gemini的Double-check response挺好用的
性能与概念漂移：第一章提到可以用人在回路来纠正；旧数据该如何去清洗呢？
突发非预期行为：目的为导向的设计的天生问题。给予更多的权限，就会有更大的风险
范式转变：从可预测的代码到不可预测的智能体
根据Google Agent System Level定义，从左到右可以认为是从L-1到L3
- 传统机器学习：通过Precision、Recall、F1-Score和RMSE评估。问题复杂但正确的标准清晰
- 被动LLM：输出有概率性。评估变得复杂，需要依赖人工评分和模型间的基准测试。
- LLM+RAG：糟糕的答案可能因为LLM推理能力差或者向量数据库检索到了不相关的片段。
- 主动式AI Agent：进一步需要评估思考、行动、观察、工具调用、记忆这几个构建。
- Multi-Agent：需要评估系统级涌现现象，带来了新的挑战：突发系统故障和协作和竞争式评估。前者包括智能体间的资源竞争、通信瓶颈和系统系死锁；
随着系统的扩充，评估的难度会越来越大。到LLM Agents就需要用人的方式来评估；到Multi-Agent需要用团队的方式来评估。
Agent评估艺术：过程评估
分为四大支柱：
- Effectiveness, 有效性：衡量任务成功与否。
- Efficiency, 效率：衡量是否很好地解决了问题。关注token消耗、实际时间和轨迹复杂度。
- Robustnees, 稳健性：当现实世界混乱时，是否能平稳处理。接口超时、数据缺失、用户提示模糊等。
- Safety & Alignment, 安全与对齐：是否在定义的伦理边界和约束范围内运行。 一个全面的Agent Quality框架需要一个全面的Agent可见性架构。 核心问题是「Did we build the right product?」
这里的right是带有疑惑的提出的。噼里啪啦两三下弄出一个Agent，然后简单试了下没问题，随后开始问「这对吗？」
对于Agent这类新式软件，不能只评估结果，还需要评估过程。
Outside-In的层级评估
我们的方法还是传统的那套：追本溯源。这里叫做「Outside-In」
评估层第一个问题「Output evaluation」，即「Agent是否有效地实现了用户目标？」 我们衡量：
- 任务成功率：是否成功解决了二元或者分级问题
- 用户满意度：用户反馈评分
- 整体质量：如果目标是定量的，需要评估准确度和完整度
Inside-Out视角：轨迹评估
从Outside-In视角发现问题后，为我们就转向Inside-Out视角。 我们通过系统地评估Agent执行轨迹来分析：
- LLM的规划：检查核心推理过程。
- 工具使用：是否调用了正确的工具、必要的工具。是否使用正确。
- 工具观察结果的解读：是否理解工具的结果。
- RAG性能：是否通过RAG找到关键的信息，而不是无用的信息。或者LM无视了检索到的信息。
- 轨迹效率和稳健性：是否有低效的资源分配，是否能处理异常。
- 多智能体动态：智能体检是否存在误解或者死循环，是否存在冲突。
就是把最终问题拆解到各个组件。思考：用个Agent做这个事情也是可以的
评估器：评估什么以及如何评估
自动化指标
即具备快速、量化性的指标，例如基于字符串相似度、基于嵌入的相似度。提到TruthfulQA的任务基准
后面有时间来解读下各类Benchmark
自动化指标是第一道关卡，主要用来查看宏观趋势变化
LLM-as-a-Judge
采用LLM来评估。用LLM我们就可以构建「这个摘要好不好？」、「这个计划是否合乎逻辑」这类评价标准了。通过提供Agent的输入、原始提示词、参考答案和评估标准，LLM可以进行逻辑推导形成分析。推荐使用比较两个Agent的方式来做相对评估。
Agent-as-a-Judge
采用Agent来评估Agent。Agent评估思考伏笔收回 关键的评价维度包括：
- 计划质量：规划是否清晰且可行？
- 工具使用：是否选择了正确的工具并正确使用？
- 上下文处理：是否有效地利用了先前的信息？ Agent需要提供信息的日志
Human-in-the-Loop
人在回路在处理深度主观性和复杂领域知识方面发挥重要作用。 HITL是建立径人类校准的基准的不可或缺的方法，可以确保Agent的行为符合复杂的人类价值观、情景需求以及特定领域的准确性。
用户反馈和Reviewer界面
评估还要收集真实世界的用户反馈，包括点赞、点踩、快速划过和短评论 点踩行为发生后，评估会将这次案例呈现到Reviewer的UI中，来定位问题
负责任的AI与安全评估
未来对于Agent安全性的评估和提升绝对是一个大难题
这里提供三种手段：
- 系统性红队测试：构建对抗性场景来破坏Agent的行为
- 自动过滤与人工审核：用硬性标准来过滤信息，并结合人工评审
- 遵守指南：通过定义好的道德标准和原则评估Agent的属猪，确保一致性
如果Agent Systeam到达L4的话，Agent创建的Agent又该如何去控制其安全性呢？以及如果一个系统都是由Agent构成的，如何确保这个系统是安全的呢？
可观测性
一个很有趣的类比：
- 传统软件像是流水线厨师，制作汉堡用的是严格且确定的流程
- 监控就是确认每一步操作是否争取
- 类比软件开发就是按照变量、函数、判断、循环来提前脑测运行逻辑
- AI Agent就像是神秘盒挑战赛的美食大厨：大厨收到目标「制作一款绝妙的甜点」和一篮食材。大厨可能会做出巧克力熔岩蛋糕、解构版提拉米苏或者藏红花风味的意式奶冻。
- 需要从监控面向观测，理解其制作甜点的过程
- 类比软件开发就是在Agent Think-Action-Observe过程中确认每一步的动作合理性。我们在一个While循环中塞入了几个Tool和提示词，但Agent的行为就会因为这些改动而产生非线性变化，较传统软件开发而言这是非常夸张的。你所见的代码外表已经不能呈现这个函数的变化，你需要结合对业务场景去推演他会走什么流程。
可观测性的三大支柱：日志、追踪和指标
日志
记录每个动作的时间、行为 我们需要重建Agent的思维过程，必须要包括丰富的上下文。
- 核心信息：完整的上下文：提示词/响应对、中间推理步骤（思维链）、结构化的工具调用（输入、输出、错误）以及Agent内部状态的变化
- 简而言之就是DB变化、Function调用、LLM询问。和传统的软件相比，我们增加了LLM询问这个步骤。这个步骤是Agent软件的核心变化，我们需要关注每一个LLM询问的输入和输出都是什么才能理解一次Agent运行的思考部分。本质上传统软件将部分函数通过LM方式实现就构成Agent了，获得了泛化性但也失去了可控性。
- Tradeoff：要注意不能存储导致性能开销过大的信息。
追踪
在日志的基础上，查看这一次运行结果出问题的地方。 又推荐了一次OpenTelemetry。人去确认的话可视化可以提升很多效率。 除了生命周期、属性监控等传统软件概念外，需要增加一个LLM对话的监控
指标
依据日志和追踪，需要评估Agent的系统指标：
- 性能：延迟、错误率
- 成本：token总数、API成本
- 有效性：任务完成率、工具使用频率
对于运营、设置预警机制而言成本和性能至关重要。三个指标加在一起就能评估完成一项任务的经济和时间成本。
除了系统指标，还需要关注质量指标：
- 正确性与准确性
- 轨迹遵循度
- 安全性和责任性
- 有用性与相关性
系统指标可以简单运算获得；质量指标如果不通过LLM和Agent感觉不太能落地，但是评估Agent质量的Agent又该如何评估呢？无线套娃同时引入HITL？可能2-3个Agent配合HITL就可以运行
整合所有要素
拥有了日志、追踪和指标后，我们需要将这个要素系统地组织起来 三个关键的运营实践：
- 仪表盘与告警：一个层次化且美观的仪表盘（系统指标、质量指标）；一个及时反馈预警的通信管道
- 安全性与个人身份信息：要保证整个监控需要保护用户信息。这一点如何监管？如果不是本地部署LLM全靠自觉？
- 粒度和开销的权衡：观测不能影响到运行效率的。建议用动态采样法：开发用DEBUG日志，生产环境采用较低的INFO日志并且跟踪所有的错误和部分的正确请求。
结论
这一篇会整合上述的内容，讲抽象原则转为可靠、自我改进系统的操作手册。
文中称之为 智能体质量飞轮。
由四部分组成：
- 定义质量（目标）：我们需要一个方向，始于质量的四大支柱：有效性、成本效益、安全性和用户信任。这里的四个支柱和前面提到的四个支柱没有完全对齐，但内容是基本一致的。 需要思考具体的工作我们需要怎么定义以上几点的要求。
- 配置可见性工具（基础）：需要构建Agent的结构化日志、端到端追踪。可观测性是生成【衡量质量支柱】证据的基础实践。
- 评估过程（引擎）：我们采用Outside-In的方式既评估最终的输出，也评判整个运行过程。可以采用LLM-as-a-Judge来保证效率，采用人在回路的标准来确保基准事实。
- 构建反馈循环（动量）：我们要确保每一次生产故障在被捕获和标注年后，都能通过程序转换为回归测试。
贴心地提到如果白皮书没记住什么，至少要记住三条原则：
- 评估是架构支柱：评估不再只仅看结果，也需要评估日志和跟踪信息
- 轨迹即真相：Agent软件是需要打开盒子去深入查看思维过程的
- 人类是仲裁者：软件需要基于人类价值观，人在回路是连接真实世界和Agent的桥梁
我们需要构建能被信任的Agent，而不仅仅是能运行的Agent
写于2025-12-28