很多 Agent Demo 都能跑通一条完整链路：理解用户问题、查询业务数据、调用工具，最后生成回复。但“能跑通”和“能上线”之间，还有很长一段距离。以一个 AI 客服 Agent 为例，用户说：我买的产品有问题，已经联系过一次客服，但一直没人处理。我想退款。
Agent 需要完成分诊、查询订单、查询历史工单、判断退款政策、决定处理动作、申请审批、执行退款并生成客户回复。
从技术上看，这是一个典型的多阶段 Agent Workflow：
但真正决定系统能不能上线的，不是这些步骤本身，而是评估（Evaluation）是否真的进入了流程控制层。
很多系统虽然也有“评估”，但评估只是事后打分：生成一个 report，告诉你“好不好”，却不能阻止错误发生，也不能改变执行路径。
这种评估，本质上只是测试日志，而不是生产机制。
一、Agent 不能只“跑流程”，必须“被评估控制流程”
在传统程序中，业务规则是确定性的：输入相同 → 输出必然相同
但 Agent 不一样。同一句“我要退款”，模型可能：
- 识别成退款请求，也可能当成投诉
- 正确调用退款工具，也可能遗漏审批条件
- 在退款未完成时，直接告诉用户“已退款成功”
因此生产系统不能这样写：
var response = await agent.RunAsync(userInput);await SendToCustomerAsync(response.Text);
问题不在于“能不能运行”，而在于：你默认模型输出是可信的，并直接进入业务系统
在客服场景中，这会带来三类风险：
- 判断错误：不符合政策的订单被误判为可退款
- 执行错误：金额错误或重复退款
- 表达错误：未完成退款却对客户承诺“已到账”
所以 Harness 的职责不是“调用模型”，而是：控制模型、约束模型、在模型失败时接管流程
二、评估不是一个点，而是两道“业务闸门”
在完整客服链路中，评估至少出现两次关键拦截：
1）Action Evaluation：这件事能不能做？
发生在执行动作之后：
builder.AddEdge(policy, action).AddEdge(action, actionEval).AddEdge(actionEval, response).AddEdge(response, replyEval).WithOutputFrom(replyEval);
这里的关键是：
- Action 负责“做什么”（退款/换货/升级）
- Action Evaluation 负责“能不能做”
例如：Action Evaluation：这件事能不能做？
它保护的是：
- 资金安全
- 权限边界
- 合规性
2）Reply Evaluation：这句话能不能发？
发生在回复生成之后：
.AddEdge(response, replyEval).WithOutputFrom(replyEval);
它检查：
- 是否泄露内部字段
- 是否包含敏感信息
- 是否错误承诺（如“已退款成功”）
例如：Reply Evaluation：这句话能不能发？
它保护的是：
- 客户体验
- 信息安全
- 合规表达
关键区别
Action Evaluation：防止“做错事”
Reply Evaluation：防止“说错话”
只做其中一个都会出问题：
- 只有 Reply Evaluation → 说得很好但做错事
- 只有 Action Evaluation → 做对了但对客户说错话
三、真正的评估必须能“阻断执行”，而不是“记录结果”
很多系统的问题在于：evaluation = true/false，但流程继续执行。这在生产中是不可接受的。
评估必须直接参与控制流：
if (!compliance.Allowed){finalAction = new ActionProposal(ActionKind.Escalate,RefundAmount: 0,RequiresApproval: true,Reason: compliance.Reason);}else if (proposal.Kind == ActionKind.Refund){var decision = await approvals.RequestAsync(proposal);if (decision?.Approved == true){await refunds.RefundAsync(...);}else{finalAction = new ActionProposal(ActionKind.Escalate,Reason: "审批未通过");}}
这里体现的是评估的本质：评估不是描述风险，而是控制风险
四、评估不能只靠 LLM，要“规则 + 模型”双层结构
在 Action Evaluation 中，一个关键设计是：
1）确定性规则（必须用代码）
例如：
var overLimit = action.RefundAmount > policy.AutomaticLimit;适用于：
- 金额
- 权限
- 状态
- 审批条件
特点：
- 可测试
- 可审计
- 稳定
2）LLM 语义判断（补充层）
用于：
- 是否合理
- 是否遗漏上下文
- 是否符合客户意图
推荐结构
规则层（Code）-> 语义层（LLM）
如果反过来：全靠 LLM 判断规则，系统一定会不稳定。
五、Reply Evaluation：不能让模型“自由发挥”
模型生成回复后，不能直接发送：
state.CustomerReply = resp.Text;因为可能出现：
您的退款已成功（内部 risk_level=low，execute_refund 已完成）
问题包括：
- 泄露内部字段
- 暴露工具名称
- 提前承诺未完成操作
本地评估比 LLM 更可靠
例如：
var phoneRegex = new Regex(@"\b1[3-9]\d{9}\b");var emailRegex = new Regex(@"\b[\w.-]+@[\w.-]+\.\w+\b");
适用于：
- PII
- 卡号
- 邮箱
- 内部字段
内部信息泄露检查
var internalTerms = new[]{"execute_refund","policy_compliant","risk_level","{", "}"};
本质是：客户不应该看到系统内部结构
六、评估失败必须触发“安全降级”
评估失败不能只是 log：
if (!passed){reply = SafeFallback(...);}
安全降级必须保证：
- 不泄露信息
- 不承诺未完成动作
- 不依赖模型补救
例如：
if (receipt is not null){return "退款已受理，将原路退回";}
关键原则：只有状态真实存在，才能表达状态
七、结构化输出是评估可执行的前提
如果输出是自然语言：看起来可以退款，但建议人工确认
系统无法判断：
- 是否退款
- 金额是多少
- 是否需要审批
因此必须结构化：
public class ActionResult{public string Action { get; set; }public decimal RefundAmount { get; set; }public bool RequiresHumanApproval { get; set; }}
但要注意：JSON 正确 ≠ 业务正确
所以必须双层校验：Schema 校验（格式）+ 业务校验（规则）
八、评估必须进入审计，而不是只用于运行时
评估结果必须结构化记录：
{"evaluation": {"passed": true,"checks": [{ "name": "no_pii_leakage" },{ "name": "no_internal_leakage" }]}}
同时进入审计系统：
await audit.WriteAsync("refund.approval_decided", ...);区别是：
- Evaluation：当下是否安全
- Audit：事后为什么这么做
九、评估必须可测试，否则无法上线
生产系统必须能模拟：
1）模型输出错误
Assert.DoesNotContain("13800138000", result.CustomerReply);2）审批拒绝
Assert.Equal(0, refund.Calls);3）幂等性
Assert.Equal(1, refund.Calls);核心不是：模型是否聪明
而是：系统在模型出错时是否仍然安全
十、评估在整个 Harness 中的位置
完整流程应该是：
最后
Agent 的能力上限取决于模型，但上线能力取决于评估系统。
企业真正关心的不是：它能不能回答问题
而是：
- 能不能不乱退款
- 能不能不泄露信息
- 能不能在不确定时停下来
- 能不能在错误发生前被拦住
因此必须建立一条清晰的信任链：
模型输出 ≠ 可执行结果
结构化输出 ≠ 业务正确
评估结果 = 流程控制器
高风险动作 = 必须审批
评估失败 = 必须降级
所有关键决策 = 必须可审计
评估的本质
评估不是“打分”，而是三件事：
你理解对了吗？
这件事可以做吗？
这个结果可以交付吗？
模型决定 Agent 能做什么。评估决定企业敢不敢让它真的去做。
声明：来自硅基-桂迹，仅代表创作者观点。链接：https://eyangzhen.com/8965.html
