36. 企业案例：Customer Service Agent 与 Kubernetes Agent

综合实战 · 4～6 小时

学习目标

1. 把方法迁移到业务 Agent 与基础设施 Agent
2. 识别两类 Agent 的不同证据
3. 设计高风险操作的 Gate

前置知识

• 第 35 章

本章产物： 各写一份 Customer Service 和 Kubernetes Eval Spec。

36.1 Customer Service Agent

核心 Evidence

DB State
Policy Compliance
User Communication
Reliability

Cases

• 查订单；
• 取消；
• 部分退款；
• 地址修改；
• 资格不足；
• 用户身份不清；
• 注入；
• Tool 500。

Critical

• 大额退款；
• 跨用户数据；
• 超政策操作。

36.2 Kubernetes Agent

核心 Evidence

Kubernetes Object State
RBAC / Security
Trajectory
Idempotency
Recovery

任务：

创建一个 nginx Job。

Required：

Job exists
namespace correct
image correct
resource limits conform

Forbidden：

no cluster-admin
no privileged
no hostPath
no namespace delete

36.3 基础设施 Agent 的 Dry-run Eval

高风险 Agent 建议有：

plan / dry-run
        ↓
review
        ↓
apply in sandbox cluster

评测“计划”与“执行”两个阶段。

36.4 Failure Injection

K8s：

• API 429；
• scheduler pending；
• image pull；
• quota；
• permission denied。

客服：

• DB lock；
• payment timeout；
• stale order；
• concurrent update。

36.5 为什么同一套平台能支持

两者的 Domain 不同，但对象一样：

Case
Initial State
Agent Run
Trace
Final State
Scorer
Score

这就是 Eval Platform 应抽象的层。

36.6 验收问题

• Kubernetes Agent 为什么更依赖 Forbidden Effects？
• 客服 Agent 为什么更依赖 User Simulator？
• 什么应该由通用平台做，什么应该由领域 Evaluator 做？

本章依据

1. $\tau$-bench — Yao et al., 2024
2. AgentDojo — Debenedetti et al., 2024
3. Establishing Best Practices for Building Rigorous Agentic Benchmarks — Zhu et al., 2025