FDE和AI Deployment - 当Agent做得完全符合要求

最近在想 Agent 的目标设计，我越来越觉得有一种风险比 hallucination 更难发现：Agent 没有理解错，也没有违反规则，它只是非常认真地完成了我们交给它的目标。
问题出在目标本身。
假设一家公司的 Customer Support 团队上线了一个 Agent，业务负责人给它的目标很清楚：
Primary objective:

Reduce Average Handling Time
by 30%
上线前的 baseline 是：
Average Handling Time      11.4 min
First Response Time         4.8 min
Customer Satisfaction      89%
Reopen Rate                 6%
三个月以后，结果看起来相当漂亮：
Average Handling Time       7.6 min
First Response Time         2.1 min
Customer Satisfaction      86%
Reopen Rate                14%
Handling Time 降了 33%。
目标完成。
但如果继续往下看，会发现 Agent 学会了一套非常有效的行为：对于信息不完整的问题，它更倾向于快速给出一个可能的答案；需要进一步调查的 case，会尽量使用现成的 resolution template；一些原本应该转给 Level 2 Support 的问题，也开始在第一层直接关闭。
每一个动作，都在帮助它缩短 Handling Time。
于是 dashboard 上最重要的数字越来越漂亮。
与此同时，越来越多客户重新打开 ticket。

这类问题很有意思，因为 Agent 很可能没有做任何传统意义上的“错误”。
Prompt 没有被 injection。
Evidence 没有丢失。
权限也没有越界。
甚至从 optimization 的角度看，它做得非常好。
系统要求：
Reduce handling time
Agent 就不断寻找能够降低 handling time 的行为。
真正值得追问的是：
我们到底把什么东西定义成了 success？

很多企业系统都会有类似的 proxy。
销售团队希望提高：
Lead Conversion Rate
招聘团队希望降低：
Time to Hire
供应链团队希望降低：
Inventory Holding Cost
客服团队希望缩短：
Average Handling Time
Finance 希望提高：
Straight-through Processing Rate
这些指标本身都很合理，因为企业需要把抽象目标变成可以测量的东西。
问题是，一旦某个指标开始决定 Agent 的行为，它就不再只是一个 dashboard metric。
它开始变成一个 optimization target。
而 optimization target 会改变系统的行为。

比如 Invoice Agent 的目标是：
Maximize automated processing rate.
原来：
Auto Process       72%
Human Review       28%
上线以后变成：
Auto Process       91%
Human Review        9%
看起来效率提高很多。
进一步分析才发现，Agent 开始把一些 evidence 不完整、但“看起来很可能正确”的 invoice 直接放行。
因为每升级一次 Human Review，都会降低它的自动处理率。
如果 evaluation 只奖励：
Automation Rate ↑
那 Agent 学会减少 escalation，其实非常符合目标。
这时候再告诉系统：
遇到不确定情况应该交给人。
还不够。
因为我们同时在用另一个指标不断奖励它：
尽量不要交给人。
这两个目标之间存在冲突。

所以我现在越来越喜欢在 Agent 上线前做一个简单的问题：
如果这个指标被优化到极致，会发生什么？
假设目标是：
Reduce support handling time.
把它推到极端：
Handling Time = 0
最简单的方法是什么？
关闭所有 ticket。
显然不行。
如果目标是：
Increase fraud detection.
推到极端：
Flag every transaction.
Detection Rate 会非常高。
业务也基本无法运行。
如果目标是：
Reduce inventory.
推到极端：
Hold no inventory.
库存成本最低，同时可能失去任何应对需求波动的能力。
这种极端化测试非常简单，却经常能暴露一个问题：
Metric 能测量目标的一部分，但它通常没有完整表达业务想要的结果。

因此我觉得一个 Agent Objective 不应该只有：
MAXIMIZE

Automation Rate
或者：
MINIMIZE

Handling Time
更完整的结构应该同时包含几个东西：
PRIMARY OUTCOME

Resolve customer issues efficiently.
OPTIMIZATION TARGET

Reduce average handling time.
QUALITY FLOOR

Customer satisfaction >= 88%
SAFETY BOUNDARY

Do not close unresolved cases.
ESCALATION REQUIREMENT

Ambiguous high-impact cases
must reach human review.
COUNTER-METRICS

Reopen rate
Complaint rate
Escalation quality
Incorrect closure rate
这时候 Agent 才不会只看到一个可以不断向上或者向下优化的数字。

我觉得 Counter-Metric 特别重要。
因为一个指标告诉我们：
想让什么变好。
另一个指标则告诉我们：
为了让它变好，我们正在牺牲什么。
还是刚才的客服 Agent。
如果只看：
Average Handling Time

11.4 min → 7.6 min
上线非常成功。
但把 counter-metrics 放进来以后：
Handling Time         -33%

Reopen Rate           +133%

Escalation Rate        -41%

Incorrect Closure      +67%

Customer Satisfaction   -3 pts
整个故事已经完全不同。
Handling Time 的 improvement 依然是真实的。
只是现在我们终于看到了它是怎么来的。

这也是为什么我觉得 Agent Evaluation 最后不能停留在：
Did the Agent achieve the KPI?
还应该继续问：
How did it achieve the KPI?
因为两个系统可以得到同一个 business metric，却通过完全不同的行为路径实现。
Agent A 把 Handling Time 从 11 分钟降到 8 分钟，是因为它更快找到了正确 evidence。
Agent B 也降到 8 分钟，是因为它减少了 investigation，然后更快关闭 case。
最终 KPI 一样。
Deployment quality 完全不同。

如果继续往下推，会出现一个很重要的概念：
Objective Drift。
很多时候业务一开始想要的是：
Resolve customer problems efficiently.
进入项目以后，为了方便测量，变成：
Reduce handling time.
进入 dashboard 以后，又变成：
AHT < 8 minutes.
最后进入 Agent objective：
Minimize AHT.
每经过一次转换，原来的 business intent 都可能丢掉一点。
最后 Agent 非常准确地优化了一个数字，但这个数字已经无法完整代表最初想解决的问题。
我觉得这可能是很多 Agent deployment 以后会遇到的真实问题。

所以如果把这个场景做成 Deployment Lab，我会让用户先面对一个看起来非常成功的系统：
TARGET

Reduce Average Handling Time 30%

RESULT

-33%

STATUS

TARGET ACHIEVED
然后一点点把 production evidence 打开：
. check 1point3acres for more.Reopen Rate

6% → 14%
继续：
Incorrect Closure Rate

2.1% → 5.6%
再继续：
Level 2 Escalation

18% → 9%
最后给出一些真实 conversation traces，让用户自己判断：
Agent 是不是“坏了”？
我觉得比较有意思的答案是：
它可能完全没有坏。
它正在按照我们设计的 incentive 工作。

接下来用户需要重新设计 Objective Contract：
OBJECTIVE CONTRACT
里面不只写：
Target
还要写：
Business Outcome

Optimization Metric

Quality Floor

Counter-Metrics

Non-negotiable Constraints

Escalation Conditions

Authority Boundary

Review Trigger
比如：
Business Outcome

Resolve customer issues
with less operational effort.
Optimization Metric

Median handling time < 8.5 min
Quality Floor

CSAT >= 88%
Counter-Metric

Reopen rate <= 7%
Constraint

Unresolved high-impact cases
cannot be auto-closed.
Review Trigger

Any counter-metric exceeds
threshold for 3 consecutive days.
这时候 success 才开始从一个单独 KPI，变成一个有边界的业务结果。

而且我觉得这里还有一个很容易被忽略的问题：
谁有权修改 Agent 的 objective？
假设运营团队发现：
Human Review Rate
太高
于是把目标从：
Escalate when evidence is incomplete.
调整成：
Escalate only when confidence < 60%.
这看起来只是一次参数优化。
但实际上，它已经扩大了 Agent 的 operational authority。
所以 objective change 也应该留下 record：
OBJECTIVE CHANGE RECORD

Previous objective

New objective

Reason

Expected business impact

New failure modes

Authority impact

Approver

Evaluation required
因为改变 Agent 想要优化的东西，本身就是一种 deployment change。

我越来越觉得，企业里的 Agent 最危险的状态之一，并不是：
Agent ignores instructions.
而可能是：
Agent follows instructions extremely well.
只是我们给它的目标过于狭窄。
这种问题尤其难发现，因为系统看起来通常很成功。
KPI 在改善。
报告是绿色的。
Agent 也没有报警。
直到几个月以后，大家才发现业务已经开始围绕这个 metric 发生变化。

所以我觉得 Agent Objective 最后至少应该回答几个问题：
我们真正想改善的业务结果是什么？
用哪个 metric 作为 proxy？
这个 metric 被过度优化时，最可能牺牲什么？
哪些 counter-metrics 能最早发现这种代价？
哪些边界无论 KPI 多漂亮都不能突破？
什么变化会触发重新评估？
这些问题定义清楚以后，Agent 才不会只是一个非常高效的数字优化器。
我最近想把这个场景继续做进 Deploy to Value，因为前面的很多 Lab 都在研究“当 Agent 做错以后怎么办”，但还有另一类 deployment failure 值得单独讨论：
Agent 做得完全符合要求，但我们要求错了。
我暂时很喜欢这个 Lab 的名字：
The Agent Did Exactly What You Asked.
因为这可能是整个问题里最麻烦的部分。
deploytovalue.com