阿里常问的 Agent 题：业务目标怎么翻译成模型和工具设计

业务方把这句话拍在桌上：“用大模型，把我们的客服成本降三成。”

如果你的第一反应是“上哪个模型”，这轮基本就结束了。面试官复述这句话，想看的是你有没有一个翻译器：把模糊的业务愿望，翻译成能被度量、能被实现、能被验收的技术约束。

这类题没有唯一的“标准答案”，但有一个稳定的破题顺序。下面按顺序拆。

这一轮分析的结论

业务目标先翻译成可度量的目标函数：一个北极星指标、一组能高频观测的代理指标、一条不能被平均掉的硬约束门控。然后判断这件事该不该用 Agent——流程确定就别让模型决定分支，有写操作就必须有人和审批。接着把业务动作翻译成工具契约，读写真分开、写操作带幂等和对账。成本按单位成功任务算，上线用业务指标而不是模型指标验证。翻译的产物不是一张架构图，而是一张“业务承诺 → 可观测证据”的对照表。

第一段：先把业务目标翻译成可度量的目标函数

“降三成”至少有四种口径：单笔服务成本降三成、人工介入率降三成、客服人力编制降三成，还是把赔付算进去的总服务成本降三成。口径不同，方案完全不同。

面试官通常就卡在这里。他会追问一句“降三成具体指什么”，答不出，后面讲的架构再漂亮也接不上。

翻译完还要分层。目标函数不是一个数，而是三层：

$$\max \; \text{NorthStar} \quad \text{s.t.} \quad \text{Guardrail} \ge \theta$$

• 北极星：业务真正付钱买的结果，通常是钱或人天。
• 代理指标：你能高频、低成本测到的中间量，比如检索命中率、工具成功率。
• 硬约束门控：一票否决项，比如越权、错误承诺、资损。

把这三层写成一段可执行声明，比在文档里写“提升智能水平”有用得多：

objective: reduce_cost_per_resolved_ticket
north_star: 单位被解决工单成本（含人工复核与返工）
proxy:
  - first_contact_resolution
  - auto_handle_rate
guardrail:
  - unauthorized_action_rate: 0
  - wrong_policy_promise_rate: <= 0.2%
  - complaint_rate: <= baseline
window: 7d_rolling

一句话记住：代理指标可以涨，但门控不能被换掉。 很多项目栽在“用平均解决率把一次资损事件平均掉”。

第二段：先判断这件事该不该用 Agent

面试官常接着问“为什么不直接写 if-else”。别急着辩护，先做判断。

判断只需要三问：

1. 流程确定吗？ 确定就别让模型决定分支，写 workflow。
2. 输入开放吗？ 自然语言、图片、多轮追问这类开放输入，才需要模型的判断力。
3. 动作有副作用吗？ 有写操作就必须有审批和幂等，而且默认由人来按下最后一步。

这里要特别防一个反例：自动化偏置。自动建议一旦有默认值，人工往往照着点通过，“有人兜底”并不等于安全。所以门控要设计成“人必须看过证据才能点通过”，而不是“弹窗让人点确定”。

第三段：把业务动作翻译成工具契约

业务方说的“帮他改个地址”“发张优惠券”“催一下物流”，落到系统里都是契约。一个工具至少要写清：谁可以调用、什么前提成立、幂等键是什么、返回什么状态、失败怎么对账。

{
  "name": "order.address.update",
  "actor": "agent",
  "input": {"order_id": "string", "address": "object", "idempotency_key": "string"},
  "preconditions": ["order_status in [paid, packing]", "same_tenant"],
  "result": {"status": "accepted|rejected|unknown", "revision": "int"},
  "side_effect": true,
  "on_unknown": "reconcile_then_confirm"
}

三条纪律，答到位基本就不会被追着打：

1. 读写真分开：读工具可以给 Agent 自由，写工具必须走审批。
2. 业务系统是唯一事实源：Agent 说“已发货”不算数，物流系统才算数。
3. unknown 不等于 failed：未知结果先对账再决定，禁止自动重放写操作。

写实现时，幂等不是靠提示词提醒模型“别重复提交”，而是靠业务侧的幂等键落库。模型可以重试，重复提交必须被系统挡下。

第四段：数据与检索要先对齐业务口径

Agent 答错，很多时候不是模型问题，是它拿到的事实和业务方口径不一致。

三类口径冲突最常出现：

• 时间口径：优惠是否含今日、物流时效按自然日还是工作日、账期按哪一天切。
• 版本口径：政策、价格、合同已经改版，索引里还是旧版。
• 归属口径：同一张订单，在客服系统和交易系统里的状态并不相同。

上线前把这段当检查项过一遍：

口径三连问：
这条事实来自哪个系统、哪个版本、哪一刻？
两个系统冲突时，谁说了算？
用户看到的承诺，能不能在业务系统里被追溯到？

这三问回答不上来的检索方案，先别上线。它们决定的是“用户能不能依据你的回答去做决定”。

第五段：把成本算进业务账

面试里只报“每次调用 0.01 元”是不够的，业务方关心的是单位成功任务成本：

$$C_{success} = \frac{C_{model} + C_{tool} + C_{human} + C_{infra}}{N_{success}}$$

关键在分母：是正确完成的任务数，不是调用次数。加上人工复核和返工之后，很多看起来便宜的方案会变贵。

成本要按业务价值分档，便宜的部分尽量便宜，贵的部分才用强模型：

这样回答的好处是：当面试官问“成本还能再降吗”，你优化的是低价值档，而不是拿高风险场景去冒险。

第六段：上线用业务指标验证，不是模型指标

模型指标必须能桥接到业务指标，否则上线就是玄学。

护栏要先设硬门槛，再谈优化：越权率和资损类指标不能被平均成功率抵消。灰度也要按切片看，别只看整体——长尾查询往往就是事故来源。

一个可复述的翻译示例：电商售后 Agent

把前面六段压成一份可以直接讲出来的翻译稿：

business_ask: "客服成本降三成"
translated:
  north_star: "单位被解决工单成本 -30%"
  guardrail:
    - 错误承诺率 <= 0.2%
    - 资损事件 = 0
  scope_in: [查物流, 改地址, 退换引导, 补偿咨询]
  scope_out: [大额赔付, 合同变更]
  tools:
    read: [order.get, logistics.track, policy.search]
    write: [order.address.update, refund.apply]
  gate: "写操作默认人工确认，超额走审批"
  rollout: "5% 灰度 → 长尾查询切片 → 7 天护栏复盘"
  evidence: "request-pack + 护栏看板 + 抽检样本"

讲这段时注意顺序：先砍范围，再定工具，最后定灰度。scope_out 比 scope_in 重要——范围砍对了，成功率自然上去；范围不砍，再强的模型也会在大额赔付上翻车。

一个常见的翻车现场：降本变成了成本转移

有个团队把自动处理率从三成提到接近八成，模型指标很漂亮，财务那边却发现总成本没降。

原因不复杂。他们把“难度高、金额小”的工单交给了模型，把“金额大、容易起纠纷”的工单留给了人工。自动处理率是按单量算的，涨得很好看；但人工盯的全是最难的活，单均成本反而更高。

复盘时暴露了三个问题：

• 代理指标和北极星不同向：一边按单量算，一边按金额和人力算。
• 没有做切片对照：整体指标在变好，高金额切片在恶化，平均值把问题盖住了。
• 人工复核成本没进分子：模型省下的钱，变成了人工加班和返工的钱。

这类问题不是模型能力问题，是翻译问题。目标函数选错，越努力越偏。

四个常见坑

把业务目标当成“必须用大模型”

业务方要的是降本，不是用大模型。能写规则的先写规则，模型的判断力要用在真正不确定的地方。

只报模型指标，不报业务指标

“检索命中率提升 12%”没有回答“人工介入率降了没有”。模型指标是过程，业务指标才是结果。

让模型直接执行写操作

一次错误的退款比一千次回答慢一点要严重得多。写操作要有审批、幂等和审计。

用平均指标掩盖长尾事故

平均值会把资损、错误承诺这类长尾事故稀释掉。门控指标必须独立于平均值单独看。

L1 / L2 / L3 追问

L1： 业务方说“用大模型降本”，你先问什么？

先问口径：降的是单笔成本、人力编制还是含赔付的总成本；再问不能碰的底线是什么。口径没对齐之前，任何技术选择都是猜。

L1： 为什么不能让模型直接执行退款？

退款是不可逆的写操作。模型可能误判意图、拿错订单或重复提交，所以必须由业务系统做幂等和额度校验，并把最后一步交给审批。

L2： 业务要求和现有系统口径冲突怎么办？

先确认哪个系统是权威事实源，把冲突写成显式的优先级规则，再在检索层做版本和时刻标注。冲突不能靠提示词“让模型判断”，那会把不确定性推到最不可控的地方。

L2： 怎么证明降本不是把成本转嫁给了人工？

把人工复核时间、返工率和接管率一起放进单位成功任务成本的分子。只看模型调用费，等于把成本挪到了看不见的地方。

L2： 什么情况下你会拒绝“上 Agent”这个需求？

流程完全确定、输入高度结构化、又要求可审计时，用规则或 workflow 更便宜也更稳。硬要用 Agent，只是给不确定的地方引入了额外的不确定。

L3： 上线后模型指标都涨了，业务指标没动，怎么排查？

先查桥接是否成立：代理指标和北极星是否同向。常见原因是代理指标选错（优化了检索命中但没优化解决率），或者优化集中在低价值切片，也可能是人工接管把收益吃掉了。用灰度对照和切片分解定位，而不是继续调模型。

L3： 怎么设计护栏，保证一次资损事件不会被平均值掩盖？

门控指标独立计算、单独告警、单独发版权限，不参与平均。任何一次越权或资损都要能冻结写路径，并保留 request-pack 供复盘。

L2： 怎么保证代理指标的改善真的带动了北极星？

先把两者的计算口径写清楚，再要求它们在同一批切片上同向变化。如果代理指标涨了而北极星没动，先查是不是口径不同步，再查收益是不是被别的环节吃掉了。

L2： 为什么“自动处理率”这类指标特别容易骗人？

因为它按单量算，不按价值算。模型最容易接手的往往是小额、简单、风险低的单子，把这类单子拿走，等于把简单活挑走、把难活留下，单量上升但单均成本可能反而恶化。

L3： 验收单上出现两个部门各认一半的指标怎么办？

先指定唯一的 owner，再由 owner 决定口径；另一方作为共同观测方，保留质疑和发起复盘的权限。指标不能有两个签字人，否则出事时没人负责，顺利时两边都来认领。

L4： 业务方要求“下个月就上线”，你砍什么？

先砍范围，把高风险写操作留在人工；再砍架构复杂度，用 workflow 骨架加受限 Agent；最后砍指标野心，先只承诺人工介入率改善。绝不砍的只有两样：门控和审计留痕。

L5： 业务目标和技术上能做成的事有根本冲突，怎么回？

把冲突翻译成可验证的问题，给出两条路径的代价：加审批换安全，或缩范围换确定性，并声明各自的失败边界。用数字说明哪条更接近业务目标，而不是用“技术上做不到”结束对话。

L5： 你怎么向业务方解释“这个需求不适合用 Agent”？

不用技术语言，用成本和风险语言：这件事的输入足够规范，规则就能覆盖绝大多数情况，模型只会增加不可解释的分支和审批负担。然后把省下的预算指向真正开放、真正需要判断的环节。

面试官追问时怎么接

拿到“客服成本降三成”这类业务目标，我先翻译口径：北极星是单位成功任务成本，代理指标是首次解决率和自动处理率，门控是越权率和错误承诺率，且门控不参与平均。第二步判断形态：确定性流程走 workflow，只在开放输入处用受限 Agent，写操作一律审批加幂等。第三步把业务动作落成工具契约，读写分离，业务系统是唯一事实源，unknown 先对账。第四步对齐数据口径，标注系统、版本和时刻。成本按单位成功任务算，把人工和返工放进分子。最后用灰度按切片验证业务指标，护栏先于优化，保留 request-pack 供复盘。整个过程先砍范围，再定工具，最后谈规模。

自检清单

• 能把业务语翻译成北极星、代理指标和门控三层
• 能判断该用 workflow、受限 Agent 还是直接转人工
• 工具契约包含读写分离、幂等、审批和对账
• 数据口径标注了来源系统、版本和时刻
• 成本用单位成功任务成本，分子含人工与返工
• 上线用业务指标和切片验证，门控独立于平均值

相关阅读

• 字节常问的 Agent 题，面试官到底在追什么？
• Workflow 还是 Agent？先看这件事到底有多不确定
• 工具调用怎么做权限控制和审计？
• 线上成本突然翻倍，Agent 项目从哪里开始降本
• 项目里的指标怎么来的？别只报一个漂亮数字

资料来源

• ARIS-in-AI-Offer：借鉴分层追问、公式化目标与可复习检查清单的组织方式