目录
介绍
一、Agent 不能只“跑流程”，必须“被评估控制流程”
二、评估不是一个点，而是两道“业务闸门”
1）Action Evaluation：这件事能不能做？
2）Reply Evaluation：这句话能不能发？
三、真正的评估必须能“阻断执行”，而不是“记录结果”
四、评估不能只靠 LLM，要“规则 + 模型”双层结构
1）确定性规则（必须用代码）
2）LLM 语义判断（补充层）
五、Reply Evaluation：不能让模型“自由发挥”
六、评估失败必须触发“安全降级”
七、结构化输出是评估可执行的前提
八、评估必须进入审计，而不是只用于运行时
九、评估必须可测试，否则无法上线
1）模型输出错误
2）审批拒绝
3）幂等性
十、评估在整个 Harness 中的位置
最后
评估的本质
介绍
很多 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 能做什么。评估决定企业敢不敢让它真的去做。
引入地址
