从 0 到 1 设计一套「真的能在企业内跑起来」的 Agent 评测平台。

1. 平台目标 & 场景边界

2. 总体架构设计（模块图 + 数据流）

3. 评测任务体系 & 指标体系

4. 评测流水线：从“题库”到“报告”的全链路

5. 工程落地建议（技术栈、环境隔离、多租户、安全）

---

1. 平台要解决什么问题？

目标：

给公司里所有 Agent（客服机器人、搜索助理、文档助手、自动化脚本、代码 Agent…）
提供一个统一的平台，做：选型、回归测试、版本对比、质量监控。

典型企业需求：

1. 多 Agent、版本很多

   • 自研 Agent / 第三方 Agent / 不同模型版本 / Prompt 版本。

2. 场景多样

   • 客服问答、RPA 自动化、知识库检索、业务流程自动化（报销/审批）、代码辅助……

3. 希望有统一的「分数面板」

   • 不同团队谈“这个 Agent 好不好用”，可以看同一套指标。

4. 自动化回归

   • 新版本 Agent 上线前自动跑一遍评测，防止质量倒退。

5. 可追溯 & 可解释

   • 每一次评测的样本、轨迹、评分，都可检索与回放。

可以理解为：

「把 Agent 能力评测，包装成一个Jenkins + Grafana + Leaderboard + 人工标注工具的综合平台」。

---

2. 总体架构设计

2.1 模块总览

文字架构图：

1. 任务与数据管理（Task & Dataset Service）

   • 场景定义、题库管理、样本版本管理、标签管理。

2. 执行引擎（Execution Engine）

   • 调用被测 Agent（HTTP / SDK / 本地）、维护环境（Browser / FS / DB sandbox）、记录完整轨迹。

3. 评分与裁判模块（Scoring & Judging Service）

   • 规则打分、LLM-as-a-judge、规则检查器（Checker）、安全评估。

4. 结果存储与分析（Result Store & Analytics）

   • 存储每个 run 的结果、轨迹、指标；提供统计与报表。

5. 可视化与控制台（Web Console）

   • 实验配置、任务选择、Agent 版本选择、查看雷达图/对比图、Error case drill-down。

6. 集成与自动化（CI/CD & API Integration）

   • 接入 GitLab/Jenkins，Agent 新版本 push 后自动触发评测；

   • 暴露 API，给其他系统查询最新评测结果。

---

2.2 数据流/完整评测的路径

1. 产品/算法同学在控制台创建一次评测任务：

   • 选择：场景（客服/文档/自动化…）

   • 选择：题库版本（v1.2）

   • 选择：要评测的 Agent 版本（A-v3/B-v2）

   • 配置：并发数、是否启用 LLM 裁判、是否启用安全检查等。

2. 平台生成一次 Evaluation Run（有唯一 ID）。

3. 执行引擎从题库中取样本 → 调用 Agent → 在环境中执行 → 保存：

   • 输入（用户 Query/任务描述）

   • Agent 的动作序列（tool 调用、浏览器操作、API 请求）

   • 环境观测（网页 HTML、文件状态等）

   • 最终结果（答复文本 / 文件 / 状态）

4. 评分模块对每一个样本评分：

   • Task Success Checker（规则检查）

   • LLM-as-a-judge（主观质量维度）

   • 安全规则（敏感词、越权操作等）

   • 资源消耗统计（步数、token 数、时间等）

5. 结果写入 Result Store（数据库）：

   • 每个样本的各维度得分

   • 汇总统计（成功率/平均步数/安全风险等）

6. 控制台展现：

   • 单次 run 的汇总报表

   • 不同 Agent/版本之间的对比

   • Error case drill-down（点进去看具体任务轨迹和评分理由）

---

3. 场景 & 指标体系：企业级要怎样拆？

一个企业可用的体系，通常需要「三层场景 × 四类指标」。

3.1 三层场景（建议直接照搬）

1. Layer 1 – 基础工具与微任务（Micro Tasks）

   • 测：工具调用正确率、基础能力。

   • 示例：

     • 调用内部 API 获取订单信息

     • 填写某张表单

     • 把一段话录入某个系统字段

2. Layer 2 – 业务子流程（Business Subflows）

   • 测：中短链条任务完成率（5～10 步）。

   • 示例：

     • “根据客户邮件，创建一个工单 + 填写关键信息”

     • “根据知识库和文档，回答一个复杂问题并附上出处”

3. Layer 3 – 完整业务流程（End-to-End Flows）

   • 测：真正的长链条任务（十几～几十步）。

   • 示例：

     • 从原始客户问题 → 确认信息 → 检索知识 → 填写多个系统 → 给客户邮件答复

     • 根据销售数据生成周报（抓取 → 数据处理 → 图表 → 报告 → 通知）

这三层对应不同业务方：

• 微任务：供工具/中间件团队用

• 子流程：供单一业务线（客服/销售/财务）用

• 完整流程：供管理层看“整体 Agent 能力”

---

3.2 四类指标（企业向）

1）任务质量（Task Quality）

• 成功率（Success Rate）

• 关键字段正确率（例如：金额/时间/人名 是否准确）

• 回答正确性（可由规则 + LLM-as-a-judge 结合）

2）交互与体验（Interaction Quality）

• 多轮对话是否稳（状态跟踪、上下文记忆）

• 是否出现明显的幻觉/无中生有

• 是否遵守企业语气规范（tone/style）

这部分用 LLM-as-a-judge + 人工抽检来打分。

3）执行与资源（Execution & Efficiency）

• 平均步数 / 工具调用次数

• 平均耗时（end-to-end latency）

• 平均 Token 消耗（成本）

可以按“分场景成本 / 每成功任务成本”给到管理层。

4）安全与合规（Safety & Compliance）

• 是否泄露敏感信息（电话、身份证、内部系统字段）

• 是否进行了越权访问/操作（删除/修改敏感数据）

• 是否违反合规（比如给投资建议、医疗诊断等）

可以结合：

• 规则检测（正则/策略引擎）

• LLM 安全 judge（“是否给出了高风险建议”）

---

4. 评测流水线：从题库到报告

这一段可以直接变成内部技术文档里的「评测流程」。

4.1 题库 & 场景建模

4.1.1 题库结构设计

为保证可维护性，题库用统一 JSON/表结构，比如：

{
  "id": "cs_kb_qa_00123",
  "scene": "customer_support_kb_qa",
  "layer": 2,
  "input": {
    "user_query": "我上个月的账单怎么没扣款？",
    "context": {
      "user_profile": { "vip_level": "gold" }
    }
  },
  "expected": {
    "key_facts": [
      "解释扣款规则",
      "指出上个月账单状态为未出账",
      "说明何时会扣款"
    ],
    "constraints": {
      "must_cite_kb": true,
      "max_ref_docs": 3
    }
  },
  "metadata": {
    "difficulty": 2,
    "biz_owner": "CS",
    "created_by": "analyst_A",
    "version": "1.0.3"
  }
}

• Layer、scene、版本号都要有。

• expected 里放关键点和约束，为后面 LLM 裁判和规则检查提供依据。

4.1.2 题库来源

• 真实日志脱敏抽样（90%）

• 人工构造难题/特例（10%）

• 对抗样本（专门攻 Agent 的 prompt）

题库本身要做版本管理（v1, v2…），防止 offline overfit。

---

4.2 执行层：如何调用 Agent + 环境

4.2.1 接入不同 Agent

统一一个 Agent Adapter 接口，比如：

class AgentClient:
    def __init__(self, name, endpoint, auth):
        ...

    def run(self, task_input, trace_id, config):
        """
        task_input: 题库里定义的 input
        trace_id: 用于日志追踪
        config: 模型温度、是否允许调用哪些工具等
        """
        return AgentResult(
            final_output=...,        # 最终输出
            actions=[...],           # 工具/环境调用轨迹
            tokens_used=...,         
            latency_ms=...
        )

对于：

• 纯 API 型 Agent → 直接 HTTP 调用。

• 本地/开源 Agent → 通过 gRPC / docker network 调用。

4.2.2 环境模拟

• Web Agent → Browser sandbox（类似 Playwright / Selenium + 自建网页镜像）

• 文件系统 Agent → 容器里的沙盒目录（chroot 或 Docker Volume）

• 内网系统 → 测试环境（UAT），或用 mock server 录放流量。

企业场景最关键的一点：评测环境要完全与生产隔离，否则 Agent 在评测时会真的改数据。

---

4.3 评分层：规则 + LLM-as-a-judge + 安全检查

4.3.1 规则评分（Deterministic）

适用于：

• 是否调用了正确 API

• 是否在规定时间内填完表

• 某字段是否匹配预期值（订单号/金额等）

• 文件是否按格式生成

可以给每个场景写一个 checker 脚本：

def check_customer_bill_task(agent_result, expected):
    score = 0
    # 1. 检查是否解释了扣款规则
    if "扣款" in agent_result.final_output and "规则" in agent_result.final_output:
        score += 0.3
    # 2. 检查是否包含当前账单状态
    if "未出账" in agent_result.final_output:
        score += 0.3
    # 3. 检查是否给出下一步时间
    if "明天" in agent_result.final_output or "下个月" in agent_result.final_output:
        score += 0.4
    return min(score, 1.0)

真实系统中可以更结构化，比如先让 Agent 输出结构化 JSON，再用精确匹配。

4.3.2 LLM-as-a-judge：主观质量维度

针对：

• 回答是否有用（helpfulness）

• 是否覆盖关键点

• 是否语气得当

• 是否幻觉少

用强模型（比如 GPT-5.x / 其它对齐好的大模型）做裁判：

• 输入：{任务描述 + Agent 回答 + expected.key_facts + rubric}

• 输出：分维度评分 + 总分 + 解释。

裁判 prompt 要写成模板，记录版本号，方便后续改进时做对比。

4.3.3 安全与合规检测

• 规则：敏感词列表 / 正则 / 策略引擎（如 OPA）

• LLM 安全裁判：

  • “这段回答是否包含敏感数据？是否给出了投资/医疗建议？”

  • 输出：safe / unsafe + 风险类型。

最终安全分一般以 “通过/不通过 + 风险标签” 的形式给。

---

4.4 汇总与可视化

4.4.1 指标聚合

对于每个 run：

• 按 scene & layer 聚合：

  • 成功率（Hard task success rate）

  • 平均质量分（LLM-judge 总分）

  • 平均步数 / 调用次数 / 成本

  • 安全违规率

给出类似：

Scene	Success	Quality	Steps	Token/Task	Unsafe%
cs_kb_qa	82.3%	8.4/10	6.2	3.1k	0.7%
automation_form_filling	91.0%	9.1/10	8.7	4.2k	0.1%
e2e_support_resolution	68.5%	7.6/10	14.5	7.9k	1.3%

4.4.2 对比视图

• 同一场景下：不同 Agent/版本的雷达图、条形对比图。

• 显示：

  • 质量分 / 成功率 / 安全 / 成本

4.4.3 Error case drill-down

点击某个场景 → 某个样本 → 看到：

• 用户输入 & 期望

• Agent 的所有中间动作（工具调用、返回值）

• 最终输出

• 评分细节（规则分项、LLM 裁判解释、安全判定依据）

方便算法工程师/产品经理做 error analysis & prompt/model 改进。

---

5. 工程落地建议

5.1 技术栈建议

• 后端：Python（FastAPI）/ Go（高并发）、Node 也可以

• 前端：React/Vue 任意，重点是图表和交互

• 存储：

  • 元数据 & 指标：PostgreSQL

  • 轨迹（可能很大）：对象存储 + 索引（ES/Opensearch）

• 消息队列：用于调度执行任务（Kafka/RabbitMQ）

• 任务执行：K8s 上跑 worker，支持水平扩展。

5.2 环境与安全

• 所有 Agent 评测任务尽量在 测试环境 / 沙盒 中跑：

  • Web：用镜像网站或 staging 环境

  • 内网系统：连 UAT

  • 文件/OS：Docker 容器，完事销毁 Volume

• 敏感日志脱敏：

  • 去掉手机号/身份证/账号等个人信息

  • Agent 轨迹日志中对敏感字段做 mask

5.3 多租户 & 权限

• 不同业务线（客服/财务/销售）拥有自己的场景 & 题库

• 评测结果权限控制：

  • 业务线内可见本线

  • 平台 owner 可以全局看

• Audit log：记录谁发起了什么评测、读了哪些结果。

5.4 与 CI/CD 整合

• 每次 Agent 代码/Prompt/策略改动，提交后：

  • CI 触发：

    1. 单元测试

    2. 小规模评测（快速 sanity check）

  • 每晚定时跑全量评测（nightly），看长期趋势。

• 配置「上线门槛」：

  • 比如：关键场景成功率不得下降超过 2%，安全违规率不得高于基线，否则禁止部署。