AI 智能体的六代架构及其评估方法 - 博客 - Braintrust

来源: https://www.braintrust.dev/blog/six-generations-ai-agents 抓取时间: 2026-07-21 16:21:42

AI 智能体的六代架构及其评估方法

2026 年 5 月 21 日 Ameya Bhatawdekar 和 Tony Xu 33 分钟 最佳实践

2022 年底，ChatGPT 和 text-davinci-003 改变了团队在产品中添加 AI 的方式。你不需要训练定制模型，只需要编写一个提示词，添加几个示例，就能在一个周末内交付有用的功能。

四年后，"AI 智能体"的含义变得更加广泛。工具使用、检索、记忆、沙箱、技能、审批和持久状态，所有这些都围绕着日益强大的模型。技术栈不断变化，因为每一种新的模型能力都会打破关于智能体应该如何构建的旧假设。

架构只是故事的一半。另一半是评估。

每一种新能力都会创造出上一代评估无法发现的失败模式。当模型变得更智能时，智能体的能力也会增强。当智能体的能力增强时，你需要评估的范围也会扩大。架构跟随模型能力，而评估跟随架构。

本文将追踪这些发展轨迹。智能体架构如何演变，每一代打破了什么，以及因此需要什么样的评估。

什么是评估？

评估是对 AI 系统的可重复测试。

传统软件测试通常是确定性的，输入 X 应该产生输出 Y。AI 系统则不同。相同的输入可以有多个有效答案，智能体可以在不同运行中采取不同路径但仍然成功。

实际上，评估包含三个部分。

• 数据：代表性案例，包括输入、上下文、预期行为和元数据。
• 任务：被测系统，无论是提示词、链、智能体、工作流还是框架。
• 评分：代码、启发式方法、大语言模型评判或人工审核，定义"良好"的含义。

一个有用的思维模型是：评估就是 AI 的测试驱动开发（TDD）。在软件中，测试确定"工作"的含义，以便实现可以安全地更改。评估对 AI 做同样的事情。它们让你可以交换提示词、模型、工具和架构，而不会丢失重要的行为。

随着模型的改进，重新实现 AI 功能的边际成本变得越来越低。没有变得更便宜的是知道新版本是否比旧版本更好。这个答案存在于你的评估中。实现将不断变化。评估集将成为持久资产、你的规范、你的回归测试套件和你的机构记忆。

智能体系统的六代架构

我们将介绍六代智能体架构及其各自所需的评估策略。

1. 提示词
2. 链
3. ReAct 循环
4. 工作流图
5. 现代智能体循环的回归
6. AI 框架

对于每一代，我们将查看主流架构模式、它引入的新失败模式，以及最适合的评估单位。

设置：认识 Sentinel

为了保持具体性，我们将在每一代中贯穿一个现实的例子。

Sentinel 是一个 SRE 事件响应智能体。它监控由大约 40 个微服务组成的关键业务应用程序，并承担实际的值班职责。它进行监控、告警、提出缓解建议，有时还会执行这些建议。它具有破坏性能力和实际后果，因此它不是一个聊天机器人。

Sentinel 的工具目录如下。 只读工具包括 query_metrics、search_logs、read_dashboard、get_recent_deploys、get_pr、get_runbook 和 query_db。 写入工具包括 rollback_deploy、restart_pod、page(team, severity) 和 post_slack。

我们将贯穿每一代的事件如下。在 UTC 时间 02:14，PagerDuty 触发，消息为"checkout-service 5xx 率在 5 分钟内超过 3%"。值班人员正在睡觉。Sentinel 的工作是识别可能的根本原因，推荐或执行操作，并在不确定时升级。

现在让我们追踪 Sentinel 如何在六代智能体技术栈中构建。

第一代：提示词

在这个例子中，架构是一个提示词，一次大语言模型调用。没有工具，没有检索，没有记忆。

这是 AI 功能的第一波浪潮，包括分类、摘要、提取和重写。当一个任务适合单次响应时，它工作得非常好。

整个架构就是一个提示词和一个响应。

系统：你是 Sentinel，一个 SRE 事件响应助手。
人类： PagerDuty 告警：checkout-service 5xx > 3% 持续 5 分钟。
        给出可能的原因和下一步。
AI：     可能的原因：最近部署、依赖中断、资源饱和。
        下一步：检查部署、检查日志、审查仪表板、如果不清楚则呼叫值班人员。

就是这样。没有证据收集，没有工具，没有验证。输出听起来可能合理，但它只是从告警文本和模型的先验知识中进行推理。

第一代的 Sentinel 会生成一个通用的、看似合理的检查清单。检查最近的部署。检查上游依赖。查看日志。检查资源饱和。但它实际上不能做任何这些事情。它无法访问你的系统，也不知道 02:11 发生了什么。

出现的问题

评估很简单，因为失败模式几乎完全是答案质量问题。一个任务，一个评分面。当出现问题时，通常是以下情况之一。

• 幻觉事实，如虚构的服务、不存在的操作手册或你没有追踪的指标。
• 看似合理但错误的建议，如回滚一个没有发生的部署，或重启不是原因的服务。
• 遗漏步骤，响应跳过明显的事情，如最近的部署和依赖关系。
• 优先级差，最可能的原因被埋在通用检查清单下。

没有中间步骤可以归咎，没有工具可以误用。评估单位是答案，这就是你所有测试覆盖的地方。

第一代评估策略

从一个小的、精选的黄金集开始，包含 50 到 500 个代表性的告警，每个都与优秀值班人员会写的内容配对。多样性胜过数量。覆盖不同的严重性，如 SEV1 和 SEV3。覆盖不同的服务，包括无状态、有状态和第三方依赖。覆盖不同的原型，如部署回归、依赖中断、容量和配置更改。添加一些"误报"，其中正确的答案是"升级，不要假设"。

然后有目的地选择几个评分器。宽松的引用匹配检查答案是否提到了预期的可能原因。事实性大语言模型评判检查答案是否与告警一致，并且不包含虚构的服务或指标。覆盖范围检查响应是否清晰优先地提出了部署、依赖健康和资源饱和问题。校准检查在告警模糊时寻找表达的不确定性。安全检查验证响应不会在没有证据的情况下推荐破坏性操作，如回滚、重启或缩减。

一个具体的数据集行看起来像这样。

json

{
  "input": "PagerDuty：checkout-service 5xx > 3% 持续 5 分钟。可能的原因？值班人员应该做什么？",
  "expected": {
    "likely_causes": ["最近部署", "下游依赖", "数据库/连接池饱和"],
    "should_recommend": ["检查过去 60 分钟的部署", "检查依赖仪表板", "如果不清楚则呼叫主值班人员"],
    "should_not_recommend": ["没有证据的立即回滚"]
  },
  "scorers": ["事实性", "覆盖范围检查", "校准", "安全检查"]
}

这些相同的评分器成为 CI 阈值。黄金集上的事实性保持在固定水平以上，安全性保持在 100%，在没有证据的情况下没有破坏性建议，并且覆盖率在发布之间不会回归超过几个百分点。该机制与后代将用于阶段评分的机制相同。只是被控制的面更窄。

由于没有工具，没有追踪，没有复合决策，这就足够了。一旦 Sentinel 在第二代开始接触真实数据，端到端评分就变得太粗糙，无法调试失败。

第二代：链

在下一代中，架构是一个固定的步骤流水线。仍然是线性的，但智能体可以在运行时检索上下文并将其缝合到提示词中。

这是一个大的转折点。许多有用的 AI 任务依赖于当前上下文，如最新部署、今天的日志或特定的客户记录。检索使答案成为实例特定的，因为模型现在可以推理来自真实世界的证据。

在这里，"智能体"意味着一个小的流水线。先获取证据，然后让模型解释它。

状态只是一个字典，每个固定步骤都会丰富它。

python

incident = parse_alert(alert_text)
# {"service": "checkout-service", "window": "5m", "severity": "SEV2"}

evidence = {
  "deploys": get_recent_deploys("checkout-service", lookback="60m"),
  "dashboard": read_dashboard("checkout-service", window="15m"),
  "logs": search_logs("checkout-service", window="10m", query="status:500"),
}

report = LLM(
  system="你是 Sentinel。仅使用提供的证据。",
  user=f"告警：{alert_text}\n证据：{evidence}\n返回假设和下一步。"
)

关键思想是每个步骤都是硬编码的。模型获得比第一代更新鲜的证据，但如果第一次检索遗漏了，它不能决定扩大部署窗口、更改日志查询或调用不同的工具。

常见模式包括检索增强生成，即检索、填充上下文然后回答；多步骤提示流水线，如摘要、草稿然后细化；以及分类然后选择提示词的路由器。

第二代的 Sentinel 可以获取部署元数据、提取最后 200 行日志并查询仪表板。但是序列是硬编码的。如果检索出错，例如查询错误、服务错误或日志嘈杂，链的其余部分会继承这个错误。

出现的问题

链引入了纯提示词评估无法捕获的新一类错误，因为模型不再是唯一可能出错的东西。

• 检索遗漏了相关证据，当导致事件的部署发生在 75 分钟前但链只回溯 60 分钟时，留给模型的是一个干净的数据包，它省略了真正的原因，并产生一个自信的错误报告。
• 早期错误级联，当 parse_alert 提取错误的服务名称时，每个下游调用都查询错误的东西，Sentinel 会产生一个关于错误系统的流畅答案。
• 链无法适应，所以即使模型可以判断日志是噪音，它也不能要求不同的查询。
• 端到端分数隐藏了故障位置，告诉你它失败了但没有说为什么。

评估单位变成了最终答案加上中间步骤。你需要每个阶段的评分器，而不仅仅是输出的一个评分器。

第二代评估策略

保留第一代的答案级评分，并添加阶段级评分以定位故障。

对于阶段级评分器，解析步骤获得模式验证和字段准确性。parse_alert 是否生成了有效的 {service, window, severity} 对象，并且它是否选择了正确的服务？检索评分器检查召回率和精确度。get_recent_deploys、read_dashboard 和 search_logs 是否返回了已知相关的证据，而没有用不相关的上下文淹没模型？推理评分器检查上下文忠实度。报告是否只使用了检索到的证据中的事实，没有幻觉的服务或指标？端到端评分器保持为第一代的答案质量评分器。

数据集变得更丰富。第二代评估行同时携带输入和真实的中间状态。

python

{
  "input": "PagerDuty：checkout-service 5xx > 3% 持续 5 分钟 ...",
  "expected": {
    "parsed": {"service": "checkout-service", "window_minutes": 5, "severity": "SEV2"},
    "should_retrieve_deploys": ["deploy-checkout-7842"],
    "should_retrieve_logs_matching": ["UpstreamConnectionError"],
    "final_causes": ["错误部署", "依赖超时"]
  },
  "scorers": ["解析字段准确性", "检索召回率", "上下文忠实度", "答案覆盖率"]
}

阶段分数让你可以对每个故障进行分类。如果解析失败，修复解析器或其提示词。如果解析通过但检索失败，扩大回溯范围、更改查询或修复索引。如果检索通过但推理失败，改进推理提示词或其少样本示例。如果一切都通过但答案是错误的，你的黄金标签可能是错误的，所以让评审员参与进来。

使用阶段分数，你可以设置 CI 阈值。黄金集上的解析准确性保持在阈值以上，例如 95% 到 99%，具体取决于风险。标记事件集上的检索召回率每周下降不超过 2 个点。SEV1 子集上的上下文忠实度保持在 100%，永远不会有幻觉的服务。

这是评估从"一个分数"变成"与你的链结构相关的分数菜单"的时候。你的评估面现在与你的系统具有相同的形状。

第三代：ReAct 循环

在这里，架构是大语言模型作为工具循环内的控制器。思考，然后行动，然后观察，重复直到模型决定完成。

下一代的原因很简单。一旦一个任务需要多个工具和多个步骤，固定的链就会成为束缚。真正的调查是交互式的。你检查证据，决定接下来检查什么，然后继续直到你有足够的信心采取行动。ReAct 将模型从文本生成器变成了过程的控制器。

这是"智能体"开始具有今天含义的第一次。不再是单一响应，而是一个决定下一步做什么的过程。

一切都存在于一个不断增长的消息线程中。模型选择每个下一个工具调用。

系统：你是 Sentinel。需要时使用工具。
        工具：read_dashboard、search_logs、get_recent_deploys、
               query_traces、rollback_deploy、page_oncall。
人类：  PagerDuty 告警：checkout-service 5xx > 3% 持续 5 分钟。

AI：     思考：首先检查这是否与部署相关。
        行动：get_recent_deploys
        输入：  {"service": "checkout-service", "lookback": "60m"}
工具：   deploy-checkout-7842 在峰值前 8 分钟发布。

AI：     思考：在推荐回滚之前需要运行时行为的证据。
        行动：search_logs
        输入：  {"service": "checkout-service", "window": "10m", "query": "status:500"}
工具：   错误提到来自 payments-api 的 UpstreamConnectionError。

AI：     思考：我有足够的证据停止调用工具。
        最终答案：可能是部署回归或支付依赖超时。
        建议在回滚前检查部署 7842 和支付健康状况。

重要的转变是控制。模型不再只是写答案。它决定了调查的路径。

第三代的 Sentinel 可以检查错误峰值、决定查询日志、检查最近的部署以及决定回滚或呼叫人工。这种灵活性带来了新的核心风险。模型现在正在做出改变执行路径的决策。

出现的问题

失败模式从"答案是错误的"转变为"行为是错误的"。

• 错误的工具选择浪费了步骤，当 Sentinel 检查日志而不是部署时。
• 错误的工具参数使智能体陷入噪音，当它搜索错误的服务、错误的窗口或使用过于宽泛的查询时。
• 无限循环或过早停止发生，当智能体要么永远四处探索，要么在第一个微弱信号时带着自信的错误答案停止时。
• 复合错误开始出现，当早期的误读（如指责下游服务）影响每个后续决策时。
• 成本和延迟爆炸出现，当一个 5 个工具调用的运行变成 25 个，因为模型重新表述相同的查询时。
• 不安全的行动成为可能，一旦 rollback_deploy 和 page_oncall 进入注册表，错误的工具选择可能会在凌晨 3 点因为错误的原因叫醒某人或回滚错误的部署。

你不能再只给答案评分。两次运行可以通过完全不同的追踪产生相同的报告，而其中一个追踪可能是不安全的或负担不起的。

第三代评估策略

评估单位从输出转移到追踪。你仍然对最终答案进行评分，但你也对智能体采取的路径以及对于采取行动的智能体，它是否产生了正确的外部状态进行评分。

追踪级评分器涵盖多个维度。工具选择准确性询问正确的第一个工具是什么。对于 5xx 峰值，通常是 read_dashboard 或 get_recent_deploys，而不是 rollback_deploy。在黄金集上标记这一点。参数质量对每个工具调用的结构化参数进行模式有效性、语义正确性（如正确的服务和合理的窗口）以及安全约束（如没有默认参数的破坏性调用）进行评分。轨迹相似性将执行的序列与一个或多个黄金轨迹进行比较。精确匹配通常太严格，所以改为评分"它是否包含必要的调用"、"它是否避免了禁止的调用"以及"它是否保持在 N 个额外步骤之内"。终止质量询问智能体是否以真正的答案停止、达到了步骤预算，还是停止得太早。安全和影响范围评分检查 Sentinel 在任何破坏性工具调用之前是否满足了记录的先决条件，如证据、置信度和严重性。

预算成为一流的指标。"正确"是不够的。在 40 个工具调用中的完美答案是一个成本问题。追踪每次运行的工具调用数、每次运行的输入和输出令牌数、挂钟延迟和升级率（即交接与行动）。然后在保持在预算内的条件下对正确性进行联合评分。

一个具体的评估行看起来像这样。

python

{
  "input": "PagerDuty：checkout-service 5xx > 3% 持续 5 分钟 ...",
  "expected": {
    "must_call":     ["read_dashboard", "get_recent_deploys"],
    "must_not_call": ["rollback_deploy"],  # 没有高置信度不允许
    "max_tool_calls": 8,
    "final_recommendation_includes": ["最近部署", "依赖检查"]
  },
  "scorers": [
    "工具选择准确性",
    "参数模式检查",
    "轨迹覆盖率",
    "禁止工具检查",
    "预算合规性",
    "最终答案检查"
  ]
}

因为模型控制路径，相同输入的两次运行可能会发散。第三代设置依赖于持久化追踪，其中每次运行都被捕获为结构化追踪，以便你可以稍后重新评分。它们依赖于重放，当你更改提示词或模型时，你重新运行黄金集并比较追踪（不仅仅是输出）。它们依赖于 CI 中的回归门，关于工具选择准确性、禁止工具发生率、成本百分位数和端到端成功。

这是评估真正看起来像行为测试的第一代。更接近模糊测试和契约测试，而不是传统的 ML 指标。

第四代：工作流图

在这个阶段，架构使控制流变得明确。你不是一个不透明的循环，而是将图编码为 DAG 或状态机，运行时决定下一个运行哪个节点。

这个下一个演进是实际的。早期的 ReAct 智能体太不可靠。2023 年时代的模型会偏离格式、幻觉工具参数、无限循环或过早停止。所以团队做了当组件不可靠时他们总是做的事情。他们从中夺走了关键控制权。工作流将高风险决策（如路由、排序、重试和护栏）移到确定性代码中，并在有界步骤内使用大语言模型，在那里更容易约束和调试。

工作流保持相同的成分——大语言模型和工具，但运行时拥有排序。

图是一组在类型化状态上的命名节点。

python

state = {
  "alert": alert_text,
  "incident": None,
  "evidence": None,
  "hypotheses": None,
  "action": None,
  "report": None,
}

state["incident"] = classify_incident(state["alert"])        # 大语言模型，有界
state["evidence"] = gather_evidence(state["incident"])       # 确定性工具
state["hypotheses"] = rank_hypotheses(state["evidence"])     # 大语言模型，有界

if state["incident"]["severity"] == "SEV1" and state["hypotheses"][0]["confidence"] < 0.7:
    state["action"] = {"type": "page_oncall"}
else:
    state["action"] = {"type": "recommend"}

state["report"] = render_report(state)

模型仍然在节点内工作，但运行时决定路径。这使系统更可预测、更容易检查，并且更容易逐个节点测试。

第四代的 Sentinel 对事件进行分类，然后获取部署和仪表板，然后运行固定的检查清单，然后生成报告，然后推荐缓解措施或执行安全操作。

出现的问题

工作流用灵活性换取确定性，这种权衡体现在评估中。

• 分布外事件脱离图，当由第三方 DNS 问题引起的 SEV1 不符合 Sentinel 的 classify-evidence-hypotheses-action 形状时，迫使工作流将其路由到一个不真正适合的节点。
• 特殊情况堆积起来，因为每个奇怪的事件都添加了一个分支、一个护栏或一个节点，六个月后图有 30 多个节点，没有人记得哪些分支仍然可达。
• 第三代失败模式出现在节点内，因为每个大语言模型支持的节点仍然可能选择错误的工具或遗漏证据，尽管这些失败现在至少局限于一个节点。
• 出现新的"图设计"失败模式，当护栏阈值错误、节点的输出模式漂移或两个分支对 state["severity"] 的含义有分歧时。

好处是，因为结构是明确的，每个失败都是可定位的。你终于可以像对待普通软件一样对待智能体，进行组件测试和集成测试。

第四代评估策略

工作流使评估感觉很像软件测试。你对每个节点、节点之间的契约、端到端运行和图覆盖率进行评分。

节点级评估充当单元测试。每个节点都有自己的评估集。classify_incident 在标记的告警上获得分类准确性，并在 incident_type 上获得混淆矩阵。gather_evidence 在标记的"真正原因"信号上获得检索召回率，与第二代相同的形状。propose_hypotheses 获得针对真正根本原因的 top-1 和 top-3 命中率，加上置信度分数的校准。decide_action 获得策略合规性，询问当严重性为 SEV1 且置信度低于 0.7 时，智能体是否路由到 page_oncall。render_report 获得答案质量检查，主要是大语言模型评判。

契约评估充当集成测试。在节点之间，编写类型化断言。classify_incident 必须返回 {service, severity, type}，严重性在 {SEV1, SEV2, SEV3} 中。gather_evidence 必须填充 deploys、dashboard 和 logs，永远不是 None。propose_hypotheses 必须返回一个非空的排名列表，置信度在 [0,1] 中。这些很便宜，并且在涉及模型行为之前捕获了大量的回归。

分支和策略覆盖率很重要，因为工作流有路径。如果你不能证明你锻炼了它们，你就不能声称系统有效。按分支划分黄金集。目标是至少 N 个 decide_action 路由到 page_oncall 的案例，至少 N 个 decide_action 路由到 recommend 的案例，每个 incident_type 至少 N 个案例，以及每个严重性级别至少 N 个案例。随着时间的推移跟踪覆盖率，就像 CI 中的代码覆盖率一样。

端到端评估使用与之前相同的最终报告评分，但按分支报告，以便你可以看到，例如，SEV1 → page_oncall 的质量下降了，尽管全球平均水平是平坦的。

一个具体的评估表看起来像这样。

python

[
  {
    "input": "checkout-service 部署后 5xx 峰值",
    "expected_branch": "recommend",
    "expected_top_cause": "最近部署",
    "scorers": ["分类准确性", "检索召回率", "Top1根本原因", "策略合规性", "答案检查"]
  },
  {
    "input": "checkout-service 宕机，最近没有部署，依赖仪表板红色",
    "expected_branch": "page_oncall",
    "expected_top_cause": "依赖中断",
    "scorers": ["分类准确性", "检索召回率", "Top1根本原因", "策略合规性", "答案检查"]
  },
  {
    "input": "嘈杂的告警，任何地方都没有真正的信号",
    "expected_branch": "page_oncall",     # 不确定性应该升级
    "expected_top_cause": None,
    "scorers": ["策略合规性", "校准检查", "答案检查"]
  }
]

每个 PR 在更改的节点上运行节点级评估，在整个图上运行契约检查，以及在采样切片上运行端到端评估。重大发布运行完整的分支覆盖矩阵。这是第一代，你可以以从普通软件获得的那种信心交付智能体更改。

第五代：现代智能体循环的回归

在第五代，架构回到了循环，因为模型变得足够好。

这是一个钟摆摆动。一旦前沿模型针对工具使用和长程推理进行了后训练，工作流的灵活性税开始占主导地位。当问题空间有界时，图很棒，但它们在长尾中很脆弱，并且演进成本高昂。有了更强大的模型，团队可以回收原始的"带工具的 while 循环"架构，并让模型再次选择路径，而不需要不断增长的手工维护图。

许多现代成功的智能体基本上与第三代的循环相同，只是有了更强大的模型和更严格的运行时护栏。

python

MAX_TOOL_CALLS = 20

while len(tool_calls) < MAX_TOOL_CALLS:
    resp = LLM(messages=messages, tools=TOOLS)

    if resp.final_answer:
        return resp.final_answer

    obs = call_tool(resp.tool_name, resp.tool_args)
    messages += [resp, {"role": "tool", "content": obs}]

return escalate("调查超出预算")

循环没有改变。模型改变了。现代模型可以持续更长时间的调查，从微弱证据中恢复，重新制定糟糕的查询，并在有足够信心时停止。运行时仍然需要预算，因为新的失败模式不再只是"错误答案"，而是"以太多成本获得的正确答案"。

第五代的 Sentinel 可以持续长时间的调查。它运行多个工具调用，在证据薄弱时重新制定查询，维护假设列表，并生成可审计的报告。

出现的问题

循环恢复了灵活性，随之而来的是第四代旨在抑制的失败模式。只是现在有了更强大的模型、更长的追踪和更高的赌注。

• 非确定性出现，当同一事件的两次运行采取不同但合法的路径时，将第三代的"预期轨迹"评分器点亮为误报。
• 成本爆炸，因为更强大的模型愿意继续工作，所以一个简短的事件可以悄悄地变成一个 30 个工具调用的调查。
• 评估脆性来自假设一个正确答案或一个正确轨迹的数据集，这对于一个可以用三种合理方式解决同一问题的系统来说是错误的。
• 失败变得更罕见和更奇怪，现代模型以长程方式失败，如早期错误分类在 15 个步骤中复合，或基于单个错误日志行构建自信的错误根本原因。
• 方差成为指标，因为"平均良好"不如"始终良好、方差低、在预算内"重要。

你不能像评估第四代那样评估第五代智能体。点估计是谎言。单轨迹期望是谎言。评估面必须承认智能体现在是合理行为的分布。

第五代评估策略

使用多试验评估，而不是点估计。运行每个案例 N 次并报告分布，而不仅仅是平均值。跟踪 pass@k（智能体在 k 次尝试中至少成功一次吗？）、pass^k（智能体在 k 次尝试中的每一次都成功吗？）、中位数和 p95 工具调用、中位数和 p95 成本、中位数和 p95 延迟以及最终答案质量的方差。

pass@k 衡量能力。如果智能体有几次机会，它能至少找到一次正确的解决方案吗？pass^k 衡量一致性。它能在重复运行中可靠地解决同一任务吗？对于面向客户的智能体，pass^k 通常是更重要的数字。人们不会体验你的平均表现。他们体验他们面前的那一次运行。

比较或爬山评估改变了问题。停止问"B 版本正确吗？"，开始问"B 在相同案例上比 A 好吗？"对于 Sentinel，成对评判接受事件 X 并询问哪个报告对值班工程师更有用，A 还是 B。如果新版本在高严重性切片上失去了成对比较，回归门会阻止发布。平局很重要。一个成本降低 40% 的平局是一个胜利。

跨度级评分不再将整个追踪作为一个对象进行评分。单独标记和评分跨度。read_dashboard 跨度获得查询正确性检查。search_logs 跨度获得有用查询和合理窗口检查。假设形成跨度获得似是而非的候选与固定检查。最终推荐跨度获得可操作和安全内容检查。这将"智能体得出了好答案"与"每个步骤都是合理的"分离开来，这随着追踪变长而变得更加重要。

预算内成功成为头条指标。"正确且在预算内"取代了"不惜任何代价正确"。对于 Sentinel，SEV1 成功需要不超过 10 个工具调用和 30 秒的挂钟时间。SEV3 成功需要不超过 5 个工具调用和 0.10 美元的成本。一个用 35 个工具调用解决 SEV3 的运行不是通过。这是一个伪装的成本事件。

一个具体的评估行看起来像这样。

python

{
  "input": "PagerDuty：checkout-service 5xx > 3% 持续 5 分钟 ...",
  "trials": 8,
  "budgets": {"max_tool_calls": 10, "max_cost_usd": 0.30, "max_latency_s": 30},
  "expected": {
      "acceptable_root_causes": ["最近部署", "依赖超时", "数据库池耗尽"],
      "resolution_signals": ["错误率低于阈值", "正确服务恢复", "没有不安全的回滚"],
      "must_not": ["rollback_deploy 没有置信度 >= 0.8"]
    },
    "scorers": [
      "实现解决",
      "跨试验通过率",
      "与基线成对评判",
      "跨度质量检查",
      "预算合规性",
      "方差检查"
    ]
}

这也是生产到评估飞轮变得重要的时候。当一次运行在生产中因糟糕的推荐、超出预算或不安全的行动而失败时，追踪会被捕获并通过在线评分转换为新的评估行。随着时间的推移，数据集不再是"我们想象可能会崩溃的东西"，而是"实际上已经崩溃的东西"。

第六代：AI 框架

在最后阶段，架构将循环包装在一个框架中。记忆、沙箱、技能、工具发现、权限、持久状态、审批和集成。

一旦团队注意到现代前沿模型的一些特定情况，框架模式就会出现。它们不仅更擅长运行工具循环。它们足够强大，可以很好地使用更丰富的外围设备。给一个强大的模型一个沙箱，它会编写和运行脚本，而不是"用英语思考"20 步。给它一个记忆工具，它会为下一个会话留下自己的面包屑。给它一堆参考文档，它会提取重要的那段。

框架通过一小组扩展智能体范围的外围设备来利用这一点。

工具发现意味着工具不需要提前硬编码。智能体可以按需列出和加载它们，越来越多地通过 MCP 风格的注册表，保持默认上下文小，同时仍然让它在需要时"伸手"。

记忆是智能体会话间读写的持久存储，所以你不再需要为每个新线程支付"重新解释世界"的税。

代码执行给智能体一个沙箱运行时，如 bash 或 Python，它用于实际计算、转换数据、验证假设和生成工件。对于许多任务，这比纯语言推理更便宜、更可靠。

技能是智能体按需加载的长格式指令、脚本和参考材料的可重用包，所以你可以积累剧本，而不必永远将它们塞进系统提示词中。

将这一切联系在一起的仍然是模型。这些外围设备在 2023 年时代的模型中都没有多大帮助。每一个都假设模型可以遵循长指令、从动态注册表中选择、编写工作代码并记住咨询自己的记忆。

权衡是一个新的瓶颈，即上下文。每个外围设备都会添加令牌和状态，工作变成决定智能体应该看到什么、何时看到，以及如何防止它被不相关的历史淹没。上下文工程取代了提示工程成为日常工作。

循环仍然是那个循环。真正的产品是围绕它的一切。记忆、执行、权限和重放。

实际上，框架通常提供工具发现，通常通过 MCP，按需加载工具。它提供记忆用于会话间的持久状态。它为代码执行和文件操作提供沙箱。它提供技能作为可重用的指令包和剧本。它提供审批和策略作为破坏性操作周围的护栏。它为重放、时间旅行和分叉执行提供持久状态。

第六代的 Sentinel 不再是"一个可以调用工具的大语言模型"。它是一个事件响应系统。它使用沙箱运行模型生成的代码并安全地测试缓解措施。它持久化调查状态。它回忆以前的事件和剧本。它与 Slack、PagerDuty、GitHub、CI 和仪表板集成。

python

ctx = Harness.for_incident(alert_text)

messages = [
  ctx.memory.read(["services.checkout", "past_incidents"]),
  ctx.skills.load(["sre-triage", "dependency-debugging"]),
  {"role": "user", "content": alert_text},
]

tools = ctx.tool_registry.load_for("checkout-service")

while ctx.within_budget():
    resp = LLM(messages=messages, tools=tools.names())
    ctx.event_log.append(resp)

    if resp.final_answer:
        return resp.final_answer

    if ctx.policies.requires_approval(resp.tool_name, resp.tool_args):
        return ctx.request_approval(resp.tool_name, resp.tool_args)

    obs = ctx.tool_broker.call(resp.tool_name, resp.tool_args, sandbox=True)
    messages += [resp, {"role": "tool", "content": obs}]

模型仍然选择下一步，但框架控制加载什么上下文、哪些工具可用、执行什么策略以及记录什么内容用于重放。

出现的问题

模型不再是唯一需要评估的东西。每个外围设备都有自己的失败模式，外围设备之间的每个交互都有更多失败模式。

• 上下文工程失败，当框架拉入 300 MB 的不相关记忆，用旧剧本淹没模型，并使运行偏离轨道时。
• 工具注册表失败，当发现加载了错误的 MCP 服务器时，将错误的工具放在智能体的手中，所以 Sentinel 最终在其 SRE 工具包中有一个"营销-CRM"工具。
• 记忆中毒，当一个糟糕的过去笔记如"回滚总是能解决这个问题"被持久化时，会使每一个未来的运行产生偏差。
• 沙箱滥用，来自运行昂贵的查询或破坏性脚本，因为没有限定沙箱允许做什么。
• 策略差距，当添加了新的破坏性工具但未更新审批策略时，让 Sentinel 采取了没有人签署的行动。
• 集成漂移，当 PagerDuty 模式更改、Slack 通知程序静默失败或审计日志遗漏轮换时出现。
• 仅生产失败覆盖根本不会离线出现的事情，如陈旧的记忆、部分中断、奇怪的触发器排序和多天的对话。

评估单位现在是系统，而不是运行。你必须测试智能体做什么，框架允许什么，以及当这两者碰撞时现实会做什么。

第六代评估策略

在第六代，评估需要回答一个更实际的问题。我们会相信这个智能体在现实世界中再次运行吗？

单个离线数据集不再足够。Sentinel 现在有记忆、工具、审批、沙箱和实时集成。失败可能来自模型，但也可能来自模型周围的框架。加载了错误的记忆、发现了错误的工具、缺少审批策略或沙箱命令产生了不安全的结果。

所以评估策略变成了一个分层系统。每一层捕获不同类别的失败。

冒烟测试检查框架是否完全工作。在测量智能之前，证明管道工作。Sentinel 可以端到端运行几个黄金事件吗？它可以读取记忆、加载技能、发现工具并写入事件日志吗？它可以调用沙箱并获得有效的结果吗？除非审批策略允许，否则破坏性工具是否被阻止？这不是启动门。这是接线检查。它告诉你框架连接得足够好，可以进行评估。

离线评估检查智能体是否解决已知案例。运行与前几代相同类型的评估，但对完整追踪进行评分，而不仅仅是最终答案。阶段分数覆盖解析、检索、分类和假设生成。追踪分数覆盖智能体是否选择了具有正确参数的正确工具。跨度分数覆盖每个重要步骤是否有用、安全和有根据。预算分数覆盖运行是否保持在成本、延迟和工具调用限制内。框架分数覆盖它是否加载了正确的上下文、发现了正确的工具、执行策略和验证沙箱输出。这一层回答了，在我们已经理解的事件上，新版本是否比旧版本表现更好。

模拟检查智能体是否处理实时环境。离线评估是静态的。框架时代的智能体不是。它们对不断变化的状态、工具输出、用户回复和环境条件做出反应。这就是模拟很重要的原因。模拟创建智能体周围世界的受控版本。对于 Sentinel，这可能意味着一个假的值班人员，他在事件中途用新约束回复，模拟的仪表板、日志、部署历史和 PagerDuty 状态，随着事件展开而变化的工具输出，以及注入的失败，如错误的日志行、陈旧的记忆或不稳定的依赖。现在你可以测试静态数据集无法捕获的行为。当第一个日志查询嘈杂时，Sentinel 会恢复吗？当值班人员添加新信息时，它会问一个合理的后续问题吗？它会忽略隐藏在日志行中的提示注入吗？它会注意到记忆与当前证据相矛盾吗？当环境模棱两可时，它会升级而不是行动吗？这一层回答了智能体是否可以在现实情况中操作，而不仅仅是回答冻结的测试用例。

重放和影子运行检查新版本是否安全交付。一旦你有生产追踪，你就可以将它们用作发布门。重放使用相同的输入和工具观察，对候选版本重新运行过去的生产事件。这让你可以问，如果我们上周交付了这个提示词、模型、技能或框架配置，它会做得更好还是更差？影子运行将实时流量发送到候选版本，而不让它采取行动。当前的生产智能体仍然服务请求。候选版本在它旁边运行，获得评分，并且只有在质量、安全性和预算上击败当前版本时才会被提升。重放用于受控的回归测试。影子运行用于验证在今天的真实流量上的行为。它们一起缩小了离线评估和生产之间的差距。

在线评分让生产继续教我们。评估成为运行时的一部分。采样生产追踪并对答案质量、工具使用、安全性和预算进行评分。监控通过率、升级率、破坏性行动率、延迟和成本。当行为漂移时发出警报。将失败和侥幸变成新的评估案例。这是评估和可观察性合并的地方。追踪不再只是工程师在错误后检查的东西。它是下一个评估、下一个重放和下一个发布决策的原材料。

这就是框架时代的评估主导开发版本。生产行为变成更好的评估，更好的评估变成更安全的发布。

构建飞轮

教训不是每个团队都应该以相同的架构结束。有些团队需要提示词。有些需要链。有些需要确定性工作流。有些已经准备好循环和框架。正确的架构取决于任务、风险、模型和产品的成熟度。

但运营模型在任何地方都是相同的。

生产是现实出现的地方，有奇怪的用户请求、遗漏的检索、昂贵的工具路径、工作流边缘案例、陈旧的记忆和糟糕的上下文。如果你没有捕获那些时刻，你只是从你想象的系统中学习，而不是人们实际体验的系统。

第一步是将生产行为转化为数据。记录输入、输出、工具调用、检索的上下文、模型选择、延迟、成本和人工更正。审查失败和侥幸，而不仅仅是明显糟糕的答案。将追踪聚类成失败模式，如检索遗漏、糟糕的工具选择、弱推理、不安全行动、成本爆炸或糟糕的交接。将重要的失败转换为具有明确预期行为和评分器的评估案例。

然后使用那些评估来交付。每个提示词更改、模型升级、检索调整、工作流分支、工具添加或框架更改都应该针对生产给你的案例运行。如果候选版本在质量上获胜、保持在预算内并且没有在安全性上回归，就交付它。如果它失败了，评估会告诉你为什么。

这就是为什么评估是 AI 开发的 TDD。它们不是发布前的一次性基准测试。它们是让你不断重写应用程序同时保留重要行为的机制。

Sentinel 可能开始是一个提示词，变成一个链，变成一个工作流，回到一个循环，并最终成长为一个框架。实现将不断变化。飞轮不应该。可靠的 AI 团队使生产证据不断流入评估，并使评估成为他们交付的每一个有意义的更改的门。

感谢 Tony Xu 对本文的贡献。