评估智能体式人工智能

📄← 模块索引↗ · 📄↑ 总索引↗

完成本节后，你应当能够：

• 解释评估智能体式人工智能对智能体系统的贡献。
• 判断何时该使用它、何时更简单的设计就已足够。
• 将该模式实现为可观察、可测试的组件。
• 识别其主要的成本、安全与可靠性风险。

从第一个原型开始就要评估，并且每当提示词、模型、工具、数据或编排逻辑发生变化时都要重新评估。

没有评估，团队就无法区分真正的改进与看似不错却不稳定的演示效果。

箭头表示控制流与数据流的走向，不一定对应不同的模型。图中的方框可以由一个确定性函数、被多次调用的同一个模型，或多个不同模型来实现。在整个流程中应保留追踪标识符（trace identifiers）。

1. 构建具有代表性的测试集。 在实现之前，先写清楚输入、预期输出、负责人和失败条件。
2. 定义任务层面的成功指标。 让这一决策在日志或结构化状态中可被观察，以便后续评估。
3. 记录运行轨迹与中间输出。 在此边界处应用最小权限原则，并验证相关假设。
4. 运行基线方案与候选方案。 记录结果以及足够复现或诊断所需的元数据。
5. 对错误分类并确定修复优先级。 在继续之前，将结果与明确的验收标准进行比较。
6. 发布前进行回归测试。 依据既定策略，将失败情形导向重试、回退方案，或人工审核。

• 状态（State）： 在结构化的运行记录中保存消息、工具调用、观察结果、产出物、决策理由、尝试次数、token 用量、延迟以及最终状态。
• 契约（Contracts）： 为每个组件定义带类型的输入、带类型的输出、允许的副作用、超时时间和错误类别。
• 控制（Controls）： 使用最小权限凭证、白名单工具、有界循环、输入校验、输出校验，并为有实际影响的动作设置审批关卡。
• 可观测性（Observability）： 在符合隐私规则的前提下，记录 prompt 或其版本、模型与参数、工具参数、工具结果、异常、时间戳和成本。
• 评估（Evaluation）： 测试具有代表性的案例、边界案例、对抗性案例和失败恢复案例，并与最简单可行的基线进行比较。

从引用有效性、论断支持度、覆盖面、连贯性、延迟与成本等维度衡量研究报告的质量。

输入：用户目标 + 约束条件
状态：{run_id, step, observations, budget, status}
决策：下一个有边界的动作
校验：权限、参数与策略
执行：模型调用、确定性代码或工具
观察：结构化结果或分类后的错误
停止：验收标准通过、预算用尽，或转交人工

• 该使用场景确实证明了此模式优于更简单的一次性调用。
• 输入、输出与成功标准都已明确。
• 工具调用及其副作用均已校验并获得相应权限。
• 循环设有硬性预算上限和有意义的停止条件。
• 失败情形会触发安全的重试、回退方案，或转交上报。
• 质量、延迟与成本被一并测量。
• 回归测试中至少包含一个失败案例。

1. 什么样的可观察失败，会表明这一模式被误用了？
2. 哪一部分应当是确定性的，而不应交给 LLM 处理？
3. 每一步所需的最小上下文是什么？
4. 人工审批或上报关卡应设在哪个位置？
5. 哪个指标能证明新增的复杂度是值得的？

为一个范围狭窄的任务实现一个最小可行版本。保存三条轨迹：一次成功的运行、一次可恢复的失败，以及一个必须停止或上报的案例。为每条轨迹编写一个回归测试，并将结果与直接生成的基线进行比较。