第 8 章：Tool Call、Memory、Workflow 与 Agent 编排
第 8 章：Tool Call、Memory、Workflow 与 Agent 编排
8.1 Agent 的风险经常发生在“会回答”之后
客服 Agent 正确理解了用户要办理部分退款，也选择了退款工具。但它把整单金额填进了部分退款参数，导致工具返回的预估金额错误。最终回答看起来专业，业务结果却是错的。
这类问题不属于普通问答错误。Agent 不只是生成文本，它还会选择工具、读写状态、执行流程、处理异常，甚至影响真实业务系统。
因此，Agent 评测必须从“答案是否正确”扩展到“过程是否安全、稳定、可追踪”。
本章关注四类对象：
- Tool Call。
- Memory。
- Workflow。
- Agent 编排。
轨迹级评分会在第 14 章展开，本章先建立组件失效模式和基础字段。
8.2 Tool Call 评测
Tool Call 至少要评五件事。
| 维度 | 判断问题 |
|---|---|
| 工具选择 | 是否选择了正确工具 |
| 参数生成 | 参数是否完整、准确、类型正确 |
| Schema 遵循 | 是否符合工具输入输出协议 |
| 权限边界 | 是否在授权范围内调用 |
| 结果使用 | 是否忠实使用工具结果回答 |
客服 Agent 的工具调用错误包括：
- 应调用退款规则工具，却只检索政策文档。
- 应查询订单状态，却调用物流工具。
- 订单 ID 与商品 ID 混淆。
- 未完成身份核验就调用敏感工具。
- 工具返回失败后仍给出确定回答。
Tool Call 评测要同时覆盖“是否调用”和“调用是否正确”。只统计工具调用率没有意义。
8.3 Tool Call 的副作用与幂等性
有些工具是只读的，例如查询订单状态；有些工具会产生副作用，例如提交退款、修改地址、取消订单。
副作用工具必须更严格评测。
| 工具类型 | 风险 | 评测重点 |
|---|---|---|
| 查询类 | 泄露隐私、查错对象 | 权限、参数、结果使用 |
| 计算类 | 金额和规则错误 | 参数准确、规则版本 |
| 提交类 | 不可逆业务操作 | 二次确认、幂等性、审计 |
| 通知类 | 错发消息、误导用户 | 收件人、内容、触发条件 |
对于提交退款这类工具，Agent 不应仅凭用户一句“帮我退”就执行。它需要身份核验、订单确认、金额确认和用户二次确认。
幂等性也很关键。Agent 反复调用同一提交工具，可能造成重复操作。评测要检查是否有去重、事务和状态保护。
8.3.1 副作用工具必须在可控环境中评测
提交退款、取消订单、修改地址、发送通知这类工具不能直接在生产环境里做离线评测。评测环境至少要满足三项要求。
| 要求 | 含义 | 评测价值 |
|---|---|---|
| 沙箱数据 | 使用可控的订单、用户、权益和支付状态 | 避免影响真实用户和财务数据 |
| 可回放 | 同一工具调用可以重复执行并得到可解释结果 | 支持版本对比和回归验证 |
| 可审计 | 每次调用记录参数、权限、操作者、终态和副作用 | 支持归因、合规和事故复盘 |
对于客服 Agent，副作用工具评测不应只检查“工具是否返回成功”，还要检查业务终态。例如退款预提交成功后，订单状态是否仍处于待用户确认，金额是否正确，是否生成了二次确认记录，是否没有触发财务出款。
更稳妥的方式是把副作用工具拆成两层：
- 计划层：Agent 生成拟执行动作和参数。
- 执行层：业务系统在权限、幂等、审批和确认通过后执行。
评测重点应先落在计划层，确认 Agent 是否生成了正确、安全、可审批的动作；执行层则通过沙箱和业务规则引擎验证终态。
对于代码 Agent 这类执行型系统，Tool Call 的风险性质与客服 Agent 有本质区别。客服 Agent 的工具是查询订单、计算退款，风险集中在"答错"或"参数填错"；代码 Agent 的工具是文件读写、Shell 命令执行、测试运行，风险不是"说错了什么"而是"做了什么"——误删源文件、执行危险命令、修改 CI 配置绕过检查。因此，代码 Agent 的 Tool Call 评测重点不是回答正确性，而是副作用审计：每次文件修改必须有 Diff 记录、每条命令必须记录 stdout/stderr、禁止执行白名单外命令、必须支持沙箱回滚。幂等性要求同一修复任务重复执行不应产生叠加破坏。
8.4 Memory 评测
Memory 包括短期状态和长期记忆。
短期状态用于当前会话，例如用户已提供订单号、选择了部分退款、完成了身份验证。
长期记忆用于跨会话信息，例如用户偏好、常用地址、历史问题。但长期记忆带来隐私和污染风险。
Memory 评测关注：
| 维度 | 问题 |
|---|---|
| 写入正确性 | 是否把正确事实写入记忆 |
| 读取相关性 | 是否只读取与当前任务相关的信息 |
| 状态保持 | 多轮中关键状态是否保留 |
| 状态隔离 | 不同用户、订单和会话是否隔离 |
| 隐私边界 | 是否写入不应保存的敏感信息 |
| 过期机制 | 记忆是否有有效期和删除机制 |
客服 Agent 如果把一个用户的退款状态带到另一个用户会话，就是严重 Memory 隔离问题。
Memory 评测最容易被低估。很多团队只检查 Agent 有没有“记住用户说过什么”，却没有检查“应该记什么、不应该记什么、什么时候必须忘记”。对于客服 Agent，记住用户已经完成身份验证有助于减少重复询问；但把身份状态跨订单、跨会话或跨用户复用，就会变成权限风险。记住用户偏好可以提升体验；但记住未脱敏的地址、手机号或投诉细节，可能违反隐私边界。
因此，Memory 的质量不是记得越多越好，而是记得准确、相关、隔离、可过期。评测 Case 应同时包含“应该保留的状态”和“不应保留或不应读取的信息”。这也是为什么 Memory 评测不能只看最终回答，需要结合状态快照和 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 应包含：
| 字段 | 说明 |
|---|---|
| goal | 当前任务目标 |
| state | 当前状态 |
| action | 模型生成、检索、工具调用、转人工等动作 |
| observation | 工具或环境返回 |
| tool_call | 工具名称、参数、结果 |
| error | 错误和异常 |
| final_state | 任务终态 |
| cost | Token、工具、沙箱等成本 |
| latency | 各步骤耗时 |
Trace 字段不是为了记录越多越好，而是为了支持评测、归因和复现。
8.7.1 Trace 评分的基础维度
Trace 进入评测后，不能只作为日志附件。它应支持步骤级评分。
| 维度 | 判断问题 | 客服 Agent 示例 |
|---|---|---|
| 必要性 | 每一步是否服务于任务目标 | 是否进行了必要的订单查询 |
| 顺序性 | 步骤顺序是否符合业务流程 | 是否先身份核验再查询订单 |
| 参数正确性 | 动作输入是否准确 | 退款工具是否使用正确商品 ID |
| 观察利用 | 是否正确使用环境返回 | 工具返回不可退时是否停止承诺 |
| 异常恢复 | 失败后是否采取合理策略 | 工具超时后是否重试或转人工 |
| 风险控制 | 是否在高风险节点触发保护 | 高金额退款是否进入审批 |
| 成本效率 | 是否存在无效循环和过度调用 | 是否重复查询同一订单 |
这些维度可以形成 Trace Rubric。最终答案评分告诉团队“结果怎么样”，Trace 评分告诉团队“过程是否可信”。对于会产生业务动作的 Agent，过程可信本身就是质量要求。
8.8 客服 Agent 案例：参数金额错误
用户说：
我这单买了两个商品，只退耳机，耳机用了 20 元券，积分要扣吗？
Agent 的过程：
- 正确识别为部分退款。
- 调用退款工具。
- 参数中把整单金额填入商品退款金额。
- 工具返回预估结果。
- Agent 按错误结果回答用户。
最终回答看起来没有幻觉，也有工具依据。但工具参数错了。
评测应给出：
| 维度 | 结果 |
|---|---|
| 意图识别 | 通过 |
| 工具选择 | 通过 |
| 参数准确性 | 失败 |
| 工具结果使用 | 表面通过，但基于错误参数 |
| 业务终态 | 失败 |
这说明 Agent 评测必须拆过程。
8.9 代码 Agent 案例：循环成本
代码 Agent 在修复测试失败时，连续运行同一条失败命令，每次得到同样错误，却没有改变策略。最终它耗费大量时间和 token，仍未解决问题。
这类问题的最终状态是失败，但更重要的过程信号是：
- 重复运行同一步骤。
- 没有从错误输出中提取新假设。
- 没有切换诊断路径。
- 成本和延迟失控。
这说明执行型 Agent 评测要包含循环检测、异常恢复和成本控制。
8.10 交付物一：Tool / Memory / Workflow 组件评测清单
| 组件 | 评测项 |
|---|---|
| Tool | 工具选择、参数准确、Schema、权限、幂等、结果使用 |
| Memory | 写入正确、读取相关、状态保持、隔离、隐私、有效期 |
| Workflow | 必要步骤、步骤顺序、异常分支、终态、人工兜底 |
| Planner | 任务拆解、步骤必要性、风险识别 |
| Executor | 动作执行、错误处理、重试策略 |
| Multi-Agent | 角色边界、信息传递、错误传播 |
这张清单适合在 Agent 评测方案设计阶段使用。
8.11 交付物二：Agent Trace 基础字段表
| 字段 | 类型 | 说明 |
|---|---|---|
| trace_id | string | 轨迹唯一标识 |
| case_id | string | 关联评测样本 |
| goal | string | 任务目标 |
| step_id | string | 步骤编号 |
| state_before | object | 步骤前状态 |
| action_type | enum | LLM / retrieve / tool / human / system |
| action_input | object | 动作输入 |
| action_output | 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 基础字段。后续章节会基于这些对象进一步展开样本设计、轨迹评分和平台化执行。
现在我们理解了被评对象，从下一章开始进入评测设计环节——如何从模糊的业务目标，一步步拆解到可执行的指标树。