字节面试官问:什么时候工作流就够了,什么时候才该上 Agent?
字节跳动,某 AI 平台组二面。面试官给了一个真实场景:客服系统每天处理上万条工单,团队想用 AI 接管一部分。候选人答了十分钟,核心观点是"agent 更智能,应该直接上 agent"。面试官追了一句:"你的 agent 调试周期是多久?如果工单处理延迟翻倍,业务能接受吗?"
这道题看似在问技术选型,实际在考判断力:你有没有能力在"能做"和"该做"之间划线。
二、大多数人怎么答的
最常见的回答是:"这个任务有多个步骤,需要调 API、查数据库、做判断,肯定得用 agent。"
问题出在一个隐含假设:多步骤 = 需要模型自主决策。但大多数多步任务的路径是固定的——先分类,再查库,再生成回复——每一步该做什么、做完跳到哪一步,你在写代码的时候就知道了。这种情况下硬上 agent,相当于把本来确定的路径交给模型"重新发明"一遍,代价是延迟更高、调试更难、结果更不可控。
典型误判: "任务复杂、步骤多,就该上 agent。" —— 其实大部分复杂任务只需要 workflow。
三、正确判断框架
五、落地案例:客服工单系统
实战拆解: 同一个客服系统,常规工单走 workflow,复杂投诉走 agent——两条路线对比。
六、上线坑点坑
坑1:为了显得先进,过早上 agent
调试成本是 workflow 的 5-10 倍。同样的输入可能走不同路径,复现问题极难。如果 workflow 能解决,永远优先 workflow。
坑2:把固定规则写成模型判断
"如果金额超过 500 就走人工审批"——这是一行 if 的事。交给模型判断只是增加不必要的不稳定性和成本。
坑 3:agent 没有 fallback
agent 决策失败后没有降级路径。必须设计好:agent 超时或信心不足时,自动退回到 workflow 或升级人工。

百度公司氛围 602人发布