如何构建可持续维护的评估集
本文介绍了如何为AI Agent构建可长期维护的评估（eval）指标体系。指标分三类：目标指标、护栏指标和运营指标，三者结合使用。候选指标来源于错误分析和产品目标与硬约束。并非所有候选都值得跟踪：一次性问题用prompt修改解决即可，只有需要持续追踪的泛化问题才建指标；每个指标必须与具体决策挂钩，否则就是噪音。从零开始时，可先阅读30-50条trace并用自由文本笔记聚类失败模式。此外需定期重跑错误分析、退役失效指标，并警惕Goodhart定律导致的过拟合。
相关文档
Use Jev to extract signals from millions of chat agent traces
本文介绍如何利用 Jev 类模型大规模分析数百万条聊天 Agent 生产轨迹，从中提取失败信号。传统 LLM-as-a-judge 评估依赖采样以控制成本，而 Jev 类模型可在同一上下文中并行回答多个问题，以极低成本对全部轨迹进行全面评估。文中讨论了显式反馈、行为追踪、事实结果和对话信号等不同类型的用户信号，并以航班改签客服对话为例，展示如何同时捕捉后续提问、用户挫败感和结果满意度等维度。文章最后介绍如何在 Langfuse 中配置基于 Jev 的批量评估模板，实现生产信号的监控与可视化。
为什么我们需要 Agent 评测
本文是 Agent 评测系列的第一篇文章，作者结合业界共识与个人实践，阐述了 Agent 评测的重要性。文章从一次线上问题修复切入，说明传统后端开发流程难以应对 Agent 的概率性输出与执行路径的不确定性。作者给出 Agent 评测的定义：围绕具体任务，按明确标准检查 Agent 执行过程（trace）和结果的方法。核心价值包括：防止越修越坏、判断改动是否真的变好、确认任务稳定性、明确完成标准、指导迭代优先级。文章还提出评测落地的五步流程：整理任务、写清标准、准备一致环境、运行新旧版本对比、持续更新案例，并提醒注意评测集划分、标准本身可能出错等问题。
JevOps: 决策模型正在改变 DevOps 的早期信号
文章探讨了决策模型 Jev 在 DevOps 领域的早期应用，提出“JevOps”概念。DevOps 充满大量小型语义决策（如日志是否值得调查、告警是否严重、修复是否有效等），传统依赖确定性规则、分类器或 LLM。Jev 以低成本、低延迟的方式将这些语义决策直接嵌入运维系统。文章列举了多个案例：Cribl 探索遥测管道中的语义决策、Jev Logs 实现日志分流、Jevernetes 应用于 Kubernetes 日志、Datadog 将 Jev 用于生产环境 Agent 评估、SREGym 在 SRE Agent 旁构建第二评估循环、以及 Jev 对高风险动作的语义门控审查，展示了决策模型在各运维环节的广阔前景。
Your users are already evaluating your AI
文章介绍了在 LLM/Agent 产品中，除了搭建在线评估器之外，更应优先捕获用户评判信号（signals of judgment）。用户在使用过程中已通过行为在'评判'AI 输出质量，只需在应用中埋点捕获。信号分为四类：显式评分（点赞/星级，明确但稀少）、行为信号（复制、重新生成、放弃等，覆盖率高）、会话信号（改写问题、纠正、要求转人工等）和结果信号（草稿被原样发送、工单保持关闭等，最强但最难实现）。文章还讨论了信号解读方法：负信号值得逐条排查，正信号只看趋势；以及自我选择、幸存者偏差、界面曝光、群体差异等固有偏差，提醒不要单以正信号为优化目标。
start ugly, write evals anyway：Agent 评估入门指南
文章探讨了 Agent 评估（evals）的重要性与实践方法。作者将 Agent 定义为模型加 Harness 的组合，区分了模型评估与 Harness 评估，并对比了 SDLC 中的测试与 ADLC 中的评估差异。文章澄清了评估的核心概念（task、trial、outcome、grader 等），指出评估的冷启动门槛比想象中低，从真实失败案例中提取 20-50 个任务即可起步。作者强调应只构建任务完成率和正确性两个基础指标，主张评估结果而非路径，并建议纳入负向用例、部分得分机制，坚持阅读轨迹记录，关注分心、token 消耗、延迟、上下文膨胀和一致性等信号。
The software factory stack
本文由 Zach Lloyd 撰写，详细介绍了 Warp Factories 的软件工厂基础设施栈设计。该栈基于开放、可组合、代码定义的原则，分为五层：Factories-as-code（工厂即代码）、Data and context（数据与上下文）、Compute（计算）、Inference（推理）和 Improvement（改进）。文章逐层阐述了各层的核心组件与设计理念，强调版本化、可测试、可回滚的工厂定义，以及支持多模型、多代理、自托管和持续改进的基础设施，旨在帮助团队向工厂模式转型。
Your AGENTS.md is holding you back
文章探讨了随着大模型能力提升，上下文工程的策略已从补充信息转向尽量精简信息。PostHog 分享了维护 AGENTS.md/CLAUDE.md 的三种实践方法：1) 使用 Claude Code 的 /doctor 命令进行健康检查并人工审阅，删除无法说出其防止失败的冗余指令；2) 像对待代码一样测试上下文，将 agent 犯过的错误记录为 evals，通过 wizard-ci 和 pr-evaluator 自动化验证；3) 直接让 agent 在使用上下文的过程中反馈改进建议。文章强调过时或冗余的上下文会拖累 agent 表现，需要定期清理与迭代。
Trace Engineering: 自主 AI Agent 的可观测性架构
文章指出生产环境中多 Agent 系统的故障调试不是提示词问题，而是分布式系统可观测性问题。作者提出 Trace Engineering 架构，区分了日志、轨迹与分布式执行追踪三种对象：日志记录文本输出，轨迹记录顺序对话轮次，而追踪以 DAG 形式刻画因果图，支持并行分叉与子 Agent 委托。文章进一步阐述确定性重放与因果状态重建，通过事件溯源（append-only 事件账本）记录工具载荷、随机种子与采样参数，实现 Mocked Replay（离线零成本验证）与 Live State Resumption（从快照恢复现场）两种调试模式，避免不可控的递归重试烧毁大量 Token 成本。
构建弹性生产级 Agent Harness 的 5 层架构
文章指出 Agent 可靠性的关键在于模型之外的确定性软件基础设施，即 Harness Engineering。作者提出构建弹性生产 harness 的 5 层方法：1）从模型优先转向系统优先架构，结构化工作流可将任务完成率从 31.7% 提升至 78.0%；2）实现持久化状态与检查点，避免长时间运行中丢失进度；3）通过角色分离（规划者、生成者、评估者）构建验证闭环；4）利用 hooks 和隔离运行时（如沙箱、网关）确保安全边界，防御提示注入；5）记录结构化追踪便于调试与自动化修复。文中结合 Google Antigravity、ADK 2.0、Gemini Enterprise 等工具给出实践建议。
你的 Agent 框架应该能够自我修复
文章探讨了AI Agent在生产环境中失败时，传统可观测性工具仅能提供追踪数据，而无法自动解决修复问题的瓶颈。作者介绍了开源平台Opik，它通过四层架构（Tracing追踪、Ollie诊断与修复、Test Suites测试集、Agent Sandbox沙盒）形成闭环。该平台能自动诊断错误链路，内置代码代理提出修复方案，并将真实失败转化为回归测试，从而实现Agent框架的自我修复与持续优化。
Harness Engineering：构建决定AI Agent可靠性的七层架构
文章指出，AI Agent的可靠性不取决于模型权重，而取决于周围的脚手架（Harness）。Harness分为七层：执行环境、工具接口、上下文管理、编排与生命周期、可观测性、验证和权限边界。这七层都是需要编写和版本控制的代码，而非模型属性。此外，Harness还分为由模型构建者提供的内部Harness和开发者自行组装的外部Harness。
AI 工程评估方法详解：Manual、Code 与 LLM-as-a-judge
文章阐述了 AI 工程闭环中评估环节的重要性，详细介绍了手动评估、基于代码的确定性评估以及 LLM-as-a-judge 三种主要方法。作者建议从手动审查开始建立直觉，逐步定义并自动化具体的失败模式。文章还探讨了基于参考与无参考评估的区别，并强调应结合多种方法，优先使用二值评分以确保评估的清晰性与可靠性。