Hugging Face Agent 评测：任务验收表怎么做

任务边界与样本

先把代理要完成的工作写成可判断的任务，而不是只写“生成一篇文章”。每条任务至少包含输入资料、允许使用的工具、必须交付的字段、不可编造的信息和失败后的处理方式。

• 任务目标：例如根据指定资料生成一篇结构化文章。
• 输入范围：固定资料文件、检索关键词、受众和输出语言。
• 工具边界：列出允许调用的检索、解析、校验或保存工具。
• 完成条件：正文、标题、标签、引用记录和状态字段均存在。
• 禁止行为：不得补写资料中没有确认的事实，不得跳过必要的校验。

资料包只确认 Hugging Face Blog feed 中存在代理、工具使用和评测相关条目索引，未提供某个固定评测接口、分数公式或命令。因此下面使用通用记录模板，不把它描述成 Hugging Face 的官方产品能力。

样本要能在不同版本、不同模型或不同提示词下重复运行。不要只保存最终文章，输入和环境也要一起归档。

1. 建立样本编号，例如 content-agent-001，并为每个任务写清目标和难点。
2. 保存资料快照、资料来源、抓取时间、文件摘要和允许引用的事实范围。
3. 固定代理版本、模型标识、提示词版本、工具清单和关键参数。
4. 准备正常样本、缺资料样本、工具报错样本和格式边界样本。
5. 为每个样本写预期结果，区分必须满足、可以接受和明确失败三类条件。

执行过程记录

过程记录不必保存不可读的全部内部内容，但要保留能够解释决策的事件。建议每个事件都有时间、步骤编号、动作类型、输入摘要、输出摘要和状态。

1. 记录任务接收：保存样本编号、任务目标和输入摘要。
2. 记录规划：说明代理准备先检索、解析、校验还是直接生成，并标注依赖关系。
3. 记录工具请求：保存工具名称、参数摘要、调用顺序、调用原因和返回状态。
4. 记录结果处理：标记哪些结果被采用、舍弃或要求重试。
5. 记录失败恢复：说明错误原因、修正动作、重试次数和最终影响。
6. 记录最终交付：保存生成结果、校验结果、人工处理和发布状态。

可直接使用以下过程字段：run_id、sample_id、step_index、action_type、tool_name、input_digest、output_digest、status、error_class、retry_count、human_review。

工具调用核对

工具调用评估不只看“有没有调用成功”，还要看调用是否必要、参数是否符合任务边界，以及结果有没有真正进入后续步骤。涉及工具接入的流程，可以参考工具调用怎么接入 AI 写作流程，但本表仍应按自己的工具契约填写。

• 调用前：工具名称和参数是否在允许清单内。
• 调用时：是否带齐必填字段，是否重复发送相同请求。
• 调用后：是否检查返回状态、空结果和部分结果。
• 结果使用：正文中的事实是否能回到对应结果。
• 异常处理：超时、权限失败、格式错误时是否停止危险动作。
• 最小权限：代理是否只执行完成任务所需的动作。

评分与案例

评分应服务于定位问题，不要只给一个总分。建议把事实、过程、工具、格式和完成度分开记录，每项同时写分数、证据和改进动作。

1. 事实准确性：关键结论是否有资料依据，未知信息是否明确标注。
2. 任务完成度：是否完成全部必交字段，是否遗漏核心步骤。
3. 格式合规性：标题、正文结构、标签和输出类型是否符合约定。
4. 工具使用：工具选择、参数、顺序、结果处理和权限边界是否正确。
5. 失败恢复：出现错误后是否识别原因，是否避免无意义重试。
6. 可复现性：相同样本能否通过记录还原运行过程。

评分表可采用五级描述：通过、基本通过、需修改、严重缺陷、无法判定。无法判定时不要猜测，应先补齐日志或样本信息。

假设任务是“根据三份固定资料生成一篇带标题、简介、步骤和排错部分的文章”。代理先读取资料摘要，再调用内容字段校验，最后生成正文。验收时应逐项核对：

• 是否读取了三份指定资料，而不是只使用其中一份。
• 是否将资料未确认的参数写成了确定结论。
• 是否在生成前完成了任务结构规划。
• 字段校验失败时，是否修改输出而不是直接发布。
• 最终正文是否包含操作步骤、示例、排错和发布检查项。

若正文看起来完整，但工具日志显示没有读取指定资料，应将任务判为过程缺陷，而不是仅凭成品给出通过结论。

故障排查与复测

常见故障需要同时记录现象、原因和修正动作，避免只把结果标为失败。

• 最终正文完整但事实来源缺失：原因可能是只检查了字数和格式。修正动作是增加事实与来源关联字段，对关键结论逐条回溯。
• 代理反复调用同一工具：原因可能是没有保存调用状态或没有设置重试上限。修正动作是使用调用编号、幂等键和最大重试次数。
• 工具返回空结果后仍继续写作：原因可能是空结果没有被视为阻断状态。修正动作是把空结果分为可继续、需补查和必须停止三类。
• 输出字段偶尔缺失：原因可能是只在提示词中描述格式。修正动作是增加结构校验，缺字段时退回修改流程。
• 失败后重试导致样本无法对比：原因可能是没有保留原始运行。修正动作是每次重试创建新的 run_id，并关联原始失败记录。
• 不同评审人结论不一致：原因可能是标准含糊。修正动作是为每个等级补充正例、反例和证据要求。

失败案例不是废稿，而是下一轮测试的输入。归档时要保留原始任务、过程日志、最终结果、评审意见和修正版本，避免只保存一句“生成失败”。

1. 按失败类型归类：事实、规划、工具、格式、恢复或发布风险。
2. 记录首次失败位置、触发条件、影响范围和是否可稳定复现。
3. 保存原始输入与输出，敏感资料先替换为等价占位内容。
4. 为修正方案建立独立版本，不覆盖旧日志。
5. 用同一失败样本复测，再用至少一个相邻样本确认没有只修好单点。
6. 将已修复案例加入回归集合，并记录最后复测时间和结论。

上线验收

发布前由执行人和复核人分别检查，任何一项无法确认都不应直接进入生产。

• 任务边界、允许工具和禁止行为已写入样本说明。
• 输入资料、版本、参数和运行编号可以互相追溯。
• 规划、工具调用、结果处理和失败恢复均有过程记录。
• 关键事实能够回到资料或工具结果，未知内容没有被补写。
• 标题、正文、标签和其他输出字段均通过结构校验。
• 常见工具故障已有停止、重试或人工接管动作。
• 失败样本已分类归档，原始运行没有被覆盖。
• 至少完成一次正常样本和一次异常样本复测。
• 人工复核人、复核时间、修改内容和发布状态已记录。

完成这套流程后，团队评估的不再只是“文章写得像不像”，还可以定位代理在哪一步理解错误、调用失误或恢复失败，从而把一次性验收变成可持续的回归测试。