考察点
这道题出自字节跳动 AI Agent 岗二面，属于系统设计类问题。面试官想看的不是你背没背过 Agent 的定义，而是你在真实项目里有没有做过「哪些逻辑写死、哪些交给模型」的权衡——这直接决定系统的稳定性、成本和可调试性。追问通常会往失败处理、重试策略、怎么证明划分合理（数据/评测）这几个方向走。
参考答案
划分的第一性原则
我在项目里用的是一条很朴素的标准：能枚举出所有分支的，写 Workflow；枚举不出来、需要语义理解的，才交给 LLM。
具体拆成三个判断维度：
- 确定性：这个节点的输入输出能不能写测试用例穷举？比如参数校验、格式转换、权限检查、调用外部 API 拿到结构化结果后的字段映射，这些是 100% 确定性逻辑，用代码实现，一次写对永远不抖。交给 LLM 只会引入不必要的错误率和 token 成本。
- 开放性：这一步需不需要理解自然语言的意图、做模糊匹配或多步推理？比如判断用户这句话是想查订单还是投诉、从非结构化文档里抽实体、决定下一步该调哪个工具——这些分支空间本质上是无限的，代码 if-else 写不全，交给 LLM。
- 错误的代价：这一步错了会不会造成资损、误发消息、删数据？代价高的动作，哪怕语义上需要 LLM 参与，最终执行前也要过一道确定性校验或人工确认。
一个典型的划分实例
以一个客服工单 Agent 为例，我当时的切分是：
| 环节 | 实现方式 | 原因 |
|---|---|---|
| 用户意图识别、槽位抽取 | LLM | 开放语义，规则覆盖不全 |
| 工具选择（查订单/查物流/转人工） | LLM + 白名单约束 | 需语义判断，但限定可选集合 |
| 参数校验、订单号格式检查 | 代码 | 确定性，错了直接返回让用户重说 |
| 调用订单系统 API | 代码 | 纯 IO，无智能需求 |
| 退款审批金额 < 阈值 | Workflow 自动批 | 业务规则可枚举 |
| 退款金额 ≥ 阈值 | 转人工 | 错误代价高 |
| 最终回复生成 | LLM | 需要自然语言表达 |
关键的一点：LLM 决策的节点我会用结构化输出把决策空间收窄。工具选择不是让模型自由生成，而是给 JSON schema 限定 enum，模型只能在白名单里选，选错的可能性从「任意字符串」缩到「有限的几个选项」，再配合低温度（temperature=0 或 0.1）压住随机性。
失败分支设计
失败分支我按「能不能恢复」分三类处理：
- 可重试的瞬时失败：工具调用超时、HTTP 5xx、限流 429。策略是指数退避重试，一般 3 次（1s、2s、4s），配合 jitter 防止雪崩。超过次数进降级分支。
- LLM 输出不合法：JSON 解析失败、schema 校验不过、选了不存在的工具。这类不走网络重试，而是带着错误信息重新 prompt 模型——把上一次的错误输出和校验报错一起塞回上下文让它修，重试 1-2 次，大部分能自愈。还失败就降级到规则兜底（比如意图识别失败默认走人工客服）。
- 业务失败：工具正常返回但结果为空、或返回业务错误码（订单不存在）。这不是异常，是合法分支，Workflow 里显式画出这条路径，让 LLM 基于「没查到」这个事实生成追问或解释，而不是让它瞎编。
兜底和观测
每个 LLM 节点都有降级路径：重试耗尽后要么走规则兜底，要么转人工，绝不能让 Agent 在失败状态下继续往下跑——错误会沿链路放大。另外每个节点打结构化日志（输入、输出、耗时、重试次数、最终走哪个分支），失败分支的占比本身就是核心监控指标：某个 LLM 节点的 schema 失败率突然升高，通常是上游 prompt 改动或模型版本切换引起的，能第一时间发现。
可能的追问
- 怎么判断某个节点从 Workflow 换成 LLM 是值得的？ 答：看规则维护成本和覆盖率的拐点——规则数膨胀到难以维护、且 badcase 主要来自「规则没覆盖」而不是「规则写错」，就该考虑换 LLM；换之前先在历史数据上离线评测准确率。
- 重试会不会导致延迟超标？ 答：会，所以重试次数和总超时预算是一起定的，比如单节点 3 次指数退避最多 ~7s，整条链路的延迟预算要预留出来；对延迟敏感的场景可以降级到更快的小模型而不是硬重试。
- LLM 决策节点怎么做灰度和回滚？ 答：prompt 版本化管理，新 prompt 先 shadow 跑（只记录不出结果）或小流量灰度，对比核心指标（任务完成率、人工转接率）达标再全量。