Agent 与 Workflow 的边界——控制权归谁

面试里最常见的失分点，是把这条光谱压缩成"用没用 Agent 框架"。用了 LangGraph 写一条固定的三节点直线图，那仍然是 workflow；用 200 行裸 Python 写一个带工具的 while 循环让模型自己决定何时退出，那就是 Agent。框架不决定性质，控制权决定性质。

# Workflow：路径写死在代码里，模型只负责单点判断
def review_invoice(file):
    fields = ocr_extract(file)                 # 代码决定：第一步一定是 OCR
    checked = rule_engine.validate(fields)     # 代码决定：第二步一定是规则校验
    if checked.all_passed:                     # 代码决定：分支条件
        return approve(fields)
    reason = llm.complete(REVIEW_PROMPT, ...)  # 模型只在这一点上做判断
    return reject(fields, reason)

# Agent：路径由模型每一轮现场决定
def review_invoice_agent(file, max_steps=12):
    messages = [system(AGENT_PROMPT), user(f"审核这张发票：{file}")]
    for step in range(max_steps):                    # ← 唯一的硬约束：步数上限
        resp = llm.chat(messages, tools=TOOLS)       # ← 模型决定：调哪个工具、还是收工
        if not resp.tool_calls:
            return resp.content                      # ← 模型决定：什么时候结束
        for call in resp.tool_calls:
            result = dispatch(call)                  # 代码只负责忠实执行
            messages.append(tool_result(call.id, result))
        messages.append(resp)
    return fallback("超出步数上限，转人工")            # ← 兜底必须有

第二段里，代码只做三件事：提供工具、忠实执行、兜底。"下一步干什么"这个决策，整个交给了模型——这是全部收益的来源，也是全部风险的来源。

Agent 的适应性收益，只在下面这几种情况下才真实存在：

1. 路径无法枚举。"这条 SQL 为什么慢"——可能要看执行计划，可能要看表统计信息，可能要查最近的 DDL 变更，具体先看哪个取决于前一步看到了什么。你没法为所有组合铺轨道。
2. 需要中途改主意。检索发现文档里说的是旧版本 API，得回头换关键词重查——workflow 的直线结构表达不了这种回溯。
3. 输入分布开放。用户可能问任何东西，长尾占比高且形态各异。
4. 验证比生成便宜。写代码难，跑测试确认对不对很容易——这类任务模型可以自己迭代逼近，闭环成立。

反过来，如果你的任务不满足这几条中的任何一条，Agent 带来的只有成本、延迟和不可复现。

经验法则：五条里有三条倒向 workflow，就别上 Agent；如果只有"老板想要 Agent"这一条理由，那是零条。

生产系统里纯 workflow 和纯 Agent 都少见，主流是确定性主干 + 自主长尾：

这套结构在面试里的说服力远高于"我们全上了 Agent"，因为它证明你算过账。

• 解决什么：路径不可枚举、需要回溯改主意的开放任务；把"穷举分支"的工程成本转移给模型的运行时决策。
• 代价是什么：① token 成本通常是等价 workflow 的数倍（每轮都要重发历史与工具定义，实际倍数取决于步数与上下文长度，务必自己实测）；② 延迟从单次调用变成 N 次串行；③ 不可复现，同输入不同路径，测试和归因都变难；④ 故障面扩大——工具的每一次副作用都可能被模型重试；⑤ 可观测成本，你必须建 trace 才知道它在干嘛（T3-11）。
• 什么时候不该用：路径固定的流水线；单步高危且不可回滚的操作（转账、删库、对外发消息）作为主干；有硬性同步 SLA 的接口；需要逐步向监管解释决策依据的场景。这几种情况下，正确答案是 workflow，并把模型限制在单点判断上。

• 必须有步数上限和预算上限，两者都要。只有步数上限，模型可能在第 3 步就吃掉 20 万 token。
• 写操作默认需要确认。高危工具走分级自治（T3-10），不要让模型直接落库。
• 工具必须幂等或带幂等键。开篇那个"重复写三条工单"的故障，根因不在模型而在工具没做幂等——模型重试是常态，不是异常。
• 别用 Agent 做本可以用一次 SQL 解决的事。见过用 Agent 三轮工具调用去查"某用户今日订单数"的系统，这是纯粹的浪费。
• 框架不是自主度的证据。评审里问一句"哪些决策点是模型定的"，就能戳穿伪 Agent。

一面几乎必问 Q3-01（"什么是 Agent"）作为暖场，这题的作用是筛掉只会背概念的人。二面会追 Q3-02（"什么时候不该上 Agent"）——这是一道反套路题，面试官想看你有没有被 2025 年那波 Agent 热冲昏头。如果你简历上写了 Agent 项目，几乎一定会被问「你这个为什么不是 workflow」，这是简历深挖阶段最常见的第一刀（详见拷打模板 P2）。

1. 先给判据，再给定义："我判断一个系统是不是 Agent，只看下一步动作是代码决定的还是模型决定的。"——一句话把你和背书的人分开。
2. 画光谱：说明这不是二元对立，中间有路由、编排器-执行器等形态。
3. 举自己的例子并主动交代代价："我们那个场景 6% 的长尾走 Agent，主干还是 workflow，因为主干路径只有四条，上 Agent 会让成本涨 7 倍、延迟涨 20 倍。"
4. 补一句反向判断："如果面的是一个强合规场景，我会建议把模型压回单点判断。"

只读过资料的回答：

• 把 Agent 定义成"会调用工具的大模型"——那是 Function Calling，不是 Agent。
• 用框架名回答本质问题："我们用了 LangGraph，所以是 Agent。"
• 说 Agent 的优点是"更智能、更灵活"，说不出任何量化代价。
• 认为 workflow 是落后的、Agent 是先进的，存在明显的技术鄙视链。

真做过的回答：

• 主动报出成本与延迟的倍数关系，且能说清倍数从哪来（每轮重发历史 + 工具定义）。
• 提到幂等性——这是被重试坑过的人才会条件反射说出的词。
• 说得出自己的兜底策略：步数上限多少、超限之后怎么办、有没有无进展检测。
• 能给出"什么时候我劝团队别上 Agent"的具体案例，而且理由是算过的账，不是感觉。
• 谈到不可复现给评测带来的麻烦，并说了怎么应对（固定随机性做回归、看轨迹而非只看结果）。