第 8 章：Agent 组件与编排评测

8.1 Agent 的风险经常发生在“会回答”之后

客服 Agent 正确理解了用户要办理部分退款，也选择了退款工具。但它把整单金额填进了部分退款参数，导致工具返回的预估金额错误。最终回答看起来专业，业务结果却是错的。

这类问题不属于普通问答错误。Agent 不只是生成文本，它还会选择工具、读写状态、执行流程、处理异常，甚至影响真实业务系统。

因此，Agent 评测要从答案正确性延伸到过程的安全性、稳定性和可追踪性。

本章关注四类对象：

1. Tool Call。
2. Memory。
3. Workflow。
4. Agent 编排。

轨迹级评分会在第 14 章展开，本章先建立组件失效模式和基础字段。

8.2 Tool Call 评测

Tool Call 至少要评五件事。

维度	判断问题
工具选择	是否选择了正确工具
参数生成	参数是否完整、准确、类型正确
Schema 遵循	是否符合工具输入输出协议
权限边界	是否在授权范围内调用
结果使用	是否忠实使用工具结果回答

客服 Agent 的工具调用错误包括：

• 应调用退款规则工具，却只检索政策文档。
• 应查询订单状态，却调用物流工具。
• 订单 ID 与商品 ID 混淆。
• 未完成身份核验就调用敏感工具。
• 工具返回失败后仍给出确定回答。

Tool Call 评测要同时覆盖“是否调用”和“调用是否正确”。只统计工具调用率没有意义。

8.3 Tool Call 的副作用与幂等性

有些工具是只读的，例如查询订单状态；有些工具会产生副作用，例如提交退款、修改地址、取消订单。

副作用工具需要更严格的评测。

工具类型	风险	评测重点
查询类	泄露隐私、查错对象	权限、参数、结果使用
计算类	金额和规则错误	参数准确、规则版本
提交类	不可逆业务操作	二次确认、幂等性、审计
通知类	错发消息、误导用户	收件人、内容、触发条件

对于提交退款这类工具，Agent 不应仅凭用户一句“帮我退”就执行。它需要身份核验、订单确认、金额确认和用户二次确认。

幂等性也很关键。Agent 反复调用同一提交工具，可能造成重复操作。评测要检查是否有去重、事务和状态保护。

8.3.1 在可控环境中评测副作用工具

提交退款、取消订单、修改地址、发送通知这类工具不能直接在生产环境里做离线评测。评测环境至少要满足三项要求。

要求	含义	评测价值
沙箱数据	使用可控的订单、用户、权益和支付状态	避免影响真实用户和财务数据
可回放	同一工具调用可以重复执行并得到可解释结果	支持版本对比和回归验证
可审计	每次调用记录参数、权限、操作者、终态和副作用	支持归因、合规和事故复盘

对于客服 Agent，副作用工具评测不应只检查“工具是否返回成功”，还要检查业务终态。例如退款预提交成功后，订单状态是否仍处于待用户确认，金额是否正确，是否生成了二次确认记录，是否没有触发财务出款。

更稳妥的方式是把副作用工具拆成两层：

1. 计划层：Agent 生成拟执行动作和参数。
2. 执行层：业务系统在权限、幂等、审批和确认通过后执行。

评测重点应先落在计划层，确认 Agent 是否生成了正确、安全、可审批的动作；执行层则通过沙箱和业务规则引擎验证终态。

代码 Agent 等执行型系统的副作用与客服场景不同，本章统一放到 8.9 节对照说明，避免在客服主线中反复切换案例。

8.4 Memory 评测

Memory 包括短期状态和长期记忆。

短期状态用于当前会话，例如用户已提供订单号、选择了部分退款、完成了身份验证。

长期记忆用于跨会话信息，例如用户偏好、常用地址、历史问题。但长期记忆带来隐私和污染风险。

Memory 评测关注：

维度	问题
写入正确性	是否把正确事实写入记忆
读取相关性	是否只读取与当前任务相关的信息
状态保持	多轮中关键状态是否保留
状态隔离	不同用户、订单和会话是否隔离
隐私边界	是否写入不应保存的敏感信息
过期机制	记忆是否有有效期和删除机制

客服 Agent 如果把一个用户的退款状态带到另一个用户会话，就是严重 Memory 隔离问题。

Memory 评测最容易被低估。很多团队只检查 Agent 有没有“记住用户说过什么”，却没有检查“应该记什么、不应该记什么、什么时候应当忘记”。对于客服 Agent，记住用户已经完成身份验证有助于减少重复询问；但把身份状态跨订单、跨会话或跨用户复用，就会变成权限风险。记住用户偏好可以提升体验；但记住未脱敏的地址、手机号或投诉细节，可能违反隐私边界。

Memory 的质量取决于记录是否准确、相关、隔离且可过期，不取决于记忆量。评测 Case 应同时包含“应该保留的状态”和“不应保留或不应读取的信息”，并结合最终回答、状态快照和 Trace 判断。

这些是评测维度，不是统一的产品保存期限或隐私实现规范。具体保留范围、删除方式和跨会话策略应由业务目的、数据分类、安全设计与适用规则共同确定；评测负责验证既定策略是否被正确执行，不能替代策略制定。

8.5 Workflow 评测

Workflow 是业务流程约束。不同任务对流程自由度要求不同。

类型	特点	示例
固定流程	步骤顺序严格	身份核验后才能查订单
半固定流程	有核心步骤，但允许跳转	售后咨询可先定位问题再选择工具
动态流程	根据环境反馈规划	代码 Agent 调试失败后选择下一步

客服 Agent 的高风险流程通常应更固定。退款、账号、隐私、投诉等场景不能完全依赖模型自由规划。

Workflow 评测要检查：

• 必要步骤是否执行。
• 步骤顺序是否正确。
• 异常分支是否覆盖。
• 是否触发人工兜底。
• 终态是否符合业务要求。

流程评测适合用状态检查器和 Trace 检查，而不是只看最终文本。

8.5.1 高风险流程要刚性化

Agent 编排的自由度应随风险等级变化。低风险咨询可以允许模型灵活组织回答；高风险业务动作则需要刚性流程约束。

场景	建议流程自由度	必要约束
普通政策咨询	较高	引用当前政策，不编造承诺
订单状态查询	中等	身份核验后查询，只返回本人订单
部分退款计算	较低	查询订单、校验规则、计算金额、解释依据
提交退款申请	很低	身份核验、订单确认、金额确认、用户二次确认、审计记录
隐私与账号问题	很低	严格权限、必要时转人工
投诉升级	中低	识别情绪和风险，按 SOP 转人工或建单

评测时也要按自由度设置不同标准。对于普通咨询，可以接受多种合格表达；对于提交退款，步骤遗漏就应判定失败，即使最终回答语气自然。

流程刚性化并不意味着放弃智能。它意味着把模型能力放在合适位置：让模型理解用户意图、组织解释和处理复杂语言；让工作流约束身份、权限、金额、审批和副作用。

8.6 Agent 编排失效模式

Agent 编排常见失败包括：

失效模式	说明
计划错误	任务拆解遗漏关键步骤
工具错用	选择工具错误或参数错误
循环调用	重复执行无效步骤
状态丢失	忘记前文关键信息
结果未利用	工具返回正确结果，但回答忽略
异常恢复失败	工具失败后编造或卡住
多 Agent 传播错误	一个 Agent 的错误被其他 Agent 放大

代码 Agent 反复运行同一失败命令，就是循环调用和异常恢复失败。客服 Agent 调用退款工具后没有使用返回的扣费结果，就是结果未利用。

编排失效的危险之处在于，它常常不会表现为语言质量差。Agent 可以语气自然、解释完整，却在过程里漏掉身份核验、调用错误工具、忽略工具返回或重复执行高成本动作。用户看到的是一个“像样的回答”，系统内部发生的是错误流程。

因此，编排评测要特别关注决策点。每个高风险任务都应明确：哪些步骤需要发生，哪些步骤不得发生，哪些异常触发兜底，哪些动作需要用户确认。决策点定义清楚后，Trace 评分就能逐项验证业务约束，无须泛泛判断“过程是否合理”。

8.7 Trace 是 Agent 评测的一等对象

对于 Agent，最终回答只是结果。Trace 才能解释过程。

本章先按证据用途说明 Trace 需要回答什么问题，不在这里维护第二份完整 Schema。

证据组	Trace 要回答的问题
任务边界	目标、初始状态、可用工具和权限是什么
行动链	Agent 采取了哪些动作，顺序与参数是什么
环境反馈	工具返回、状态变化和异常是什么，后续是否正确利用
结果与资源	最终状态是否达成，成本、延迟和副作用是否可接受

Trace 不是记录越多越好，也不要求保存模型的完整隐式思维过程。它要保存足以支持评测、归因、复现和审计的可观察证据。组件快速接入所需的最小字段见 8.11，跨团队交换和完整评分以第 14 章为准。

8.7.1 Trace 评分的基础维度

Trace 进入评测后，不应停留在日志附件层面，还要支持步骤级评分。

维度	判断问题	客服 Agent 示例
必要性	每一步是否服务于任务目标	是否进行了必要的订单查询
顺序性	步骤顺序是否符合业务流程	是否先身份核验再查询订单
参数正确性	动作输入是否准确	退款工具是否使用正确商品 ID
观察利用	是否正确使用环境返回	工具返回不可退时是否停止承诺
异常恢复	失败后是否采取合理策略	工具超时后是否重试或转人工
风险控制	是否在高风险节点触发保护	高金额退款是否进入审批
成本效率	是否存在无效循环和过度调用	是否重复查询同一订单

这些维度可以形成 Trace Rubric。最终答案评分告诉团队“结果怎么样”，Trace 评分告诉团队“过程是否可信”。对于会产生业务动作的 Agent，过程可信本身就是质量要求。

8.8 客服 Agent 案例：参数金额错误

用户说：

我这单买了两个商品，只退耳机，耳机用了 20 元券，积分要扣吗？

Agent 的过程：

1. 正确识别为部分退款。
2. 调用退款工具。
3. 参数中把整单金额填入商品退款金额。
4. 工具返回预估结果。
5. Agent 按错误结果回答用户。

最终回答看起来没有幻觉，也有工具依据。但工具参数错了。

评测应给出：

维度	结果
意图识别	通过
工具选择	通过
参数准确性	失败
工具结果使用	表面通过，但基于错误参数
业务终态	失败

这说明 Agent 评测不能省略过程拆解。

8.9 代码 Agent 案例：循环成本

代码 Agent 的工具包括文件读写、Shell 命令和测试执行，风险重点从“说错”转向“做错”。与客服 Agent 的订单查询和退款计算相比，它还需要额外检查：

• 文件修改是否保留 Diff 和可回滚记录。
• 命令是否在授权范围内，并记录标准输出、标准错误和退出状态。
• 执行环境是否与真实工作区隔离。
• 同一任务重复执行是否造成叠加修改或其他破坏。

代码 Agent 在修复测试失败时，连续运行同一条失败命令，每次得到同样错误，却没有改变策略。最终它耗费大量时间和 token，仍未解决问题。

这类问题的最终状态是失败，但更重要的过程信号是：

• 重复运行同一步骤。
• 没有从错误输出中提取新假设。
• 没有切换诊断路径。
• 成本和延迟失控。

这说明执行型 Agent 评测要包含循环检测、异常恢复和成本控制。

8.10 交付物一：Tool / Memory / Workflow 与编排评测清单

先检查可独立拆测的组件能力：

组件	评测项
Tool	工具选择、参数准确、Schema、权限、幂等、结果使用
Memory	写入正确、读取相关、状态保持、隔离、隐私、有效期
Workflow	必要步骤、步骤顺序、异常分支、终态、人工兜底

再检查组件如何被编排执行。这里的行是编排职责，不与上表的组件类型并列：

编排职责	评测项
Planner	任务拆解、步骤必要性、风险识别
Executor	动作执行、错误处理、重试策略
Multi-Agent 协作	角色边界、信息传递、错误传播

这两张表适合在 Agent 评测方案设计阶段配套使用：组件表回答“单项能力是否正确”，编排表回答“这些能力是否被正确组织”。

8.11 交付物二：Agent Trace 基础字段表

下表用于组件评测快速接入，只保留最小字段。跨团队交换、平台存储和完整轨迹评分以第 14 章 14.12 节及配套《Agent Trace Schema 模板》为权威版本。

字段	类型	说明
trace_id	string	轨迹唯一标识
case_id	string	关联评测样本
goal	string	任务目标
step_id	string	步骤编号
state_before	object	步骤前状态
action_type	enum	response / tool_call / state_update / handoff
tool_name	string	工具调用时的工具名
arguments	object	工具参数或动作输入
observation	object	环境或工具返回
state_after	object	步骤后状态
error	object	异常信息
cost	object	Token、工具、沙箱成本
latency_ms	number	耗时
final_state	object	任务终态

后续轨迹级评分、归因和回放都建立在这些字段上。

8.12 常见误区

8.12.1 只看工具调用率

工具调用率高不代表质量高。关键是是否该调用、参数是否正确、结果是否被正确使用。

8.12.2 让模型自由处理高风险流程

退款、隐私和账号问题需要流程约束，不能完全依赖自由规划。

8.12.3 记录 Trace 但不用于评测

Trace 不是日志归档。它要进入过程评分、根因归因和回归验证。

8.12.4 忽略成本和循环

Agent 能最终完成任务，不代表过程可接受。无效循环和过度工具调用会让系统不可用。

8.13 本章小结

Agent 评测需要覆盖 Tool Call、Memory、Workflow 和编排过程。

客服 Agent 的风险可能发生在工具选择、参数构造、状态保持、流程顺序、异常恢复和结果使用中。最终答案正确与否只是一个维度。

本章建立了组件级失效模式和 Trace 基础字段。后续章节会基于这些对象进一步展开样本设计、轨迹评分和平台化执行。

现在我们理解了被评对象，从下一章开始进入评测设计环节——如何从模糊的业务目标，一步步拆解到可执行的指标树。