你理解的Agent是什么？和写死的Workflow有什么区别？
本文目录
30秒版回答
我理解的 Agent 是：大模型 + 工具 + 记忆 + 一个由模型驱动的控制循环。模型每一轮根据当前目标和上一步的观察结果，决定调用哪个工具、传什么参数，或者判断任务已经完成。
它和 Workflow 的本质区别在于控制流由谁决定：Workflow 的步骤和分支是工程师提前写死的，Agent 的步骤是模型在运行时动态决定的。
所以选型上我的原则是：路径能提前枚举的用 Workflow，路径不可预知、需要边看边做的才用 Agent。生产上最常见的其实是混合架构——外层用确定性流程兜住边界，只在少数开放环节放模型自主决策。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
面试官：「你简历上写了做过 Agent 相关的东西，那你先说说，你理解的 Agent 是什么？它和我们平时用调度系统编排的 Workflow 有什么区别？」
这道题几乎是 Agent 方向的开场必问题。它看起来是概念题，实际上面试官在用它筛人：很多候选人一开口就是“Agent 就是能自主思考的 AI”，这种回答等于什么都没说。
数据开发回答这道题有天然优势——我们天天和 DAG、调度、重试、依赖打交道，Workflow 是什么我们比谁都清楚。只要把 Agent 讲成“由模型在运行时决定下一步的 Workflow”，再讲清楚什么时候该用、什么时候不该用，就已经超过大部分人了。
面试官在考什么
• 能不能用工程语言定义 Agent，而不是背营销话术。
• 是否理解 Agent 的核心循环：感知 → 推理 → 调用工具 → 观察结果 → 再推理，直到任务完成或触发终止条件。
• 有没有选型判断力：知道 Agent 不是越多越好，很多场景用确定性 Workflow 更便宜、更稳。
• 能不能结合数据场景：比如数据质量排查、任务失败诊断、智能问数，到底哪些环节适合交给模型决策。
展开一：Agent 的四个组成部分
面试时不要只说“Agent 能自主决策”，要把它拆成可以落地的组件。我一般拆成四块：
| 组件 | 作用 | 数据开发能类比的东西 |
|---|---|---|
| 模型（LLM） | 理解目标、规划步骤、生成工具调用参数、判断是否完成 | 调度系统里的“决策器”，但决策逻辑不是写死的 |
| 工具（Tools） | 执行真实动作：查元数据、跑 SQL、读日志、调接口 | 一个个封装好的算子 / Operator |
| 记忆（Memory） | 保存对话历史、中间结果、长期偏好和知识 | 任务上下文、状态表、Checkpoint |
| 控制循环（Loop） | 推理 → 行动 → 观察 → 再推理，直到完成或触发上限 | 一个“下一个节点由模型决定”的 DAG 执行器 |
这里面最容易被忽略的是控制循环的终止条件。一个 Agent 如果没有最大步数、最大 Token、最大耗时这几道闸，模型一旦陷入“查一下 → 不确定 → 再查一下”的死循环，成本和延迟都会失控。
下面是一个最小 Agent 循环的伪代码，不依赖任何具体框架，面试时在白板上能画出来就够了：
# 最小 Agent 循环（伪代码，与具体 SDK 无关）
def run_agent(goal, tools, max_steps=8, max_tokens=50_000):
messages = [system_prompt(tools), user(goal)]
used_tokens = 0
for step in range(max_steps): # 闸门1：最大步数
resp = llm.chat(messages, tools=tools)
used_tokens += resp.usage.total
if used_tokens > max_tokens: # 闸门2：Token 预算
return fail("超出预算", messages)
if resp.stop_reason == "end_turn": # 模型认为任务完成
return resp.text
for call in resp.tool_calls: # 模型决定调用哪些工具
result = tools[call.name].run(**call.args) # 真实执行
messages.append(tool_result(call.id, result)) # 观察结果回填
return fail("超出最大步数", messages) # 兜底：不允许无限循环注意这段代码里决定下一步做什么的是 llm.chat 的返回值，而不是 if/else。这就是 Agent 和 Workflow 在代码层面最直观的区别。
展开二：Workflow 和 Agent 的对比
Workflow 也可以调用大模型，比如“抽取字段 → 分类 → 写库”三步，每一步都调 LLM，但步骤顺序是固定的，这依然是 Workflow，不是 Agent。很多人把“用了大模型”和“是 Agent”混为一谈，这是一个减分点。
# Workflow：步骤写死，模型只负责每一步内部的“理解”
def ticket_workflow(ticket):
fields = llm_extract(ticket) # 第1步：抽取字段（固定）
category = llm_classify(fields) # 第2步：分类（固定）
if category == "退款": # 分支是工程师写的
return refund_flow(fields)
return default_flow(fields)
# Agent：模型自己决定先查订单、还是先查物流、还是直接回复
def ticket_agent(ticket):
return run_agent(goal=ticket,
tools=[query_order, query_logistics, refund, reply])| 维度 | Workflow（确定性编排） | Agent（模型驱动） |
|---|---|---|
| 控制流 | 工程师预先定义的 DAG / 分支 | 模型运行时动态决定 |
| 可预测性 | 高，同样输入走同样路径 | 较低，同样输入可能走不同路径 |
| 成本与延迟 | 可精确估算 | 随步数波动，长尾明显 |
| 调试方式 | 看节点日志即可 | 需要完整 Trace，回放每一步推理 |
| 适用场景 | 流程固定、步骤可枚举、强合规 | 开放问题、步骤不可预知、需要探索 |
| 典型例子 | 每日报表生成、固定格式抽取 | 任务失败根因排查、开放式数据分析 |
展开三：常见的几种编排模式
面试官如果追问“你知道哪些 Agent 设计模式”，可以按“确定性从强到弱”的顺序说，这样体现你有一个清晰的光谱认知：
• 提示链（Prompt Chaining）：上一步输出作为下一步输入，步骤固定。适合可以拆成固定子任务的场景。
• 路由（Routing）：先分类，再分发到不同的专用流程。比如问数请求先判断是“查指标”还是“查明细”。
• 并行（Parallelization）：同一问题拆成多路同时处理，再汇总，或者多次投票提升可靠性。
• 编排者-执行者（Orchestrator-Workers）：一个主 Agent 动态拆任务，分给子 Agent 执行。拆法是运行时决定的。
• 评估-优化（Evaluator-Optimizer）：一个负责生成，一个负责评审打回，循环到满足标准。适合生成 SQL 后自动校验。
• 自主 Agent：完全由模型循环决策，只设预算和权限边界。
前三种本质都是 Workflow，后三种才逐步引入模型对控制流的决策权。能用前面的就不要用后面的，这是工程上的基本原则。
典型场景：任务失败自动排查，从全 Agent 改成混合架构
拿数据团队最常见的需求举例：夜里调度任务失败，希望 AI 自动给出根因和修复建议。
第一版很多团队会做成全自主 Agent：给它查日志、查元数据、查上游任务状态、查集群资源等十几个工具，让它自己排查。结果通常是：简单问题它也要绕七八步，单次排查耗时和 Token 波动很大；偶尔还会在“查日志 → 看不懂 → 再查日志”里打转。
更稳的第二版是混合架构：确定性的部分用 Workflow 先做掉——拉取错误日志、匹配已知错误码（OOM、文件不存在、分区未就绪、权限不足）、检查上游是否成功。命中已知规则直接给结论；只有规则没命中的“长尾问题”，才交给 Agent 带着已收集的上下文去自由探索。
# 混合架构：规则兜住 80% 的常见问题，Agent 只处理长尾
def diagnose(task_run):
ctx = {
"error_log": fetch_error_log(task_run, tail=200), # 确定性步骤
"upstream": check_upstream(task_run),
"resource": get_queue_usage(task_run.queue),
}
hit = match_known_rules(ctx) # OOM / 分区未就绪 / 权限 等
if hit:
return hit.to_report() # 不调用模型，便宜且稳定
# 只有未命中规则才进入 Agent，并且带上已收集的上下文
return run_agent(goal=f"排查任务失败根因: {task_run.id}",
tools=[read_log, query_meta, query_lineage],
context=ctx, max_steps=6)这个例子在面试里非常好用，因为它同时体现了三件事：你懂 Agent，你不迷信 Agent，你会用数据工程的思路给 Agent 加边界。
追问链
追问一：那你怎么判断一个场景该不该用 Agent？
我会问三个问题。第一，步骤能不能提前枚举？能枚举就用 Workflow。第二，出错的代价有多大？涉及写操作、资金、合规的环节，要么不用 Agent，要么加人工确认。第三，成本和延迟能不能接受波动？Agent 的步数不固定，P99 延迟可能是 P50 的好几倍，在线强 SLA 场景要慎重。
三个问题里只要有一个答案是“不能接受”，就优先考虑 Workflow 或者混合架构。
追问二：Agent 陷入死循环怎么办？
工程上要有多层保护：最大步数、最大 Token、最大耗时三道硬闸；对同一个工具、同样参数的重复调用做检测，连续重复就强制终止；工具返回错误时要返回结构化的错误信息，告诉模型“为什么失败、可以怎么改”，而不是只返回一个异常栈，否则模型只会盲目重试。
另外要把每一步都记录进 Trace，事后能回放到底卡在哪一步，这样才能针对性地改提示词或工具设计。
追问三：多 Agent 是不是比单 Agent 更强？
不一定。多 Agent 带来的是职责隔离和上下文隔离，比如一个负责检索、一个负责写 SQL、一个负责校验，每个 Agent 的上下文更短、更聚焦。但代价是调用链变长、成本上升、失败点变多、调试更难。
我的经验原则是：先把单 Agent 的工具和提示词做好，只有当单个 Agent 的上下文明显装不下、或者任务天然可以并行拆分时，才拆成多 Agent。
加分说法 vs 减分说法
| ✔ 加分说法 | ✘ 减分说法 |
|---|---|
| Agent = 模型 + 工具 + 记忆 + 控制循环，区别在于控制流由谁决定 | Agent 就是能自主思考的 AI |
| 能枚举的路径用 Workflow，开放问题才用 Agent | 用了大模型就是 Agent |
| 生产上常用混合架构，规则兜底、Agent 处理长尾 | 所有流程都应该 Agent 化 |
| Agent 必须有步数、Token、耗时三道闸 | 只讲框架名字（某某框架很好用），讲不出原理 |
| 主动提到 Trace 和可回放，体现工程化思维 | 完全不提成本、延迟和失败处理 |
怎么挂到你的项目上
话术模板：“我们团队在做任务失败自动诊断时，一开始也尝试过全 Agent 方案，但发现简单问题绕路、成本不稳定。后来我把它改成了混合架构：日志拉取、已知错误码匹配、上游检查这些用确定性流程做，只有规则没覆盖的长尾问题才交给 Agent。这样既保住了稳定性，又保留了处理新问题的能力。”
如果你还没做过，可以说成：“如果让我设计，我会这样做……”，把上面的混合架构讲出来，面试官同样认可设计能力。
总结
这道题的得分关键是用工程语言定义 Agent：控制流由模型在运行时决定。然后马上给出选型原则和混合架构，证明你不是只会追热点。数据开发天天写 DAG，把 Agent 讲成“动态 DAG”，再补上闸门、Trace 和失败处理，这一题就稳了。
下一篇聊 Agent 的“手”：Function Calling、MCP、A2A 分别解决什么问题？为什么 MCP 被叫作 AI 时代的 USB 接口？
你们团队现在做的 AI 应用，是 Workflow 多还是 Agent 多？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长