Agent 能不能上线，关键看评估能不能真正控制业务流程

目录介绍一、Agent 不能只“跑流程”必须“被评估控制流程”二、评估不是一个点而是两道“业务闸门”1Action Evaluation这件事能不能做2Reply Evaluation这句话能不能发三、真正的评估必须能“阻断执行”而不是“记录结果”四、评估不能只靠 LLM要“规则 模型”双层结构1确定性规则必须用代码2LLM 语义判断补充层五、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 的职责不是“调用模型”而是控制模型、约束模型、在模型失败时接管流程二、评估不是一个点而是两道“业务闸门”在完整客服链路中评估至少出现两次关键拦截1Action Evaluation这件事能不能做发生在执行动作之后builder .AddEdge(policy, action) .AddEdge(action, actionEval) .AddEdge(actionEval, response) .AddEdge(response, replyEval) .WithOutputFrom(replyEval);这里的关键是Action 负责“做什么”退款/换货/升级Action Evaluation 负责“能不能做”例如Action Evaluation这件事能不能做它保护的是资金安全权限边界合规性2Reply 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;适用于金额权限状态审批条件特点可测试可审计稳定2LLM 语义判断补充层用于是否合理是否遗漏上下文是否符合客户意图推荐结构规则层Code- 语义层LLM如果反过来全靠 LLM 判断规则系统一定会不稳定。五、Reply Evaluation不能让模型“自由发挥”模型生成回复后不能直接发送state.CustomerReply resp.Text;因为可能出现您的退款已成功内部 risk_levellowexecute_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 能做什么。评估决定企业敢不敢让它真的去做。引入地址