AI Agent 面试题深度解析（六）：Workflow、Graph 与 Loop 篇

核心答案#

AI 系统需要工作流，本质是”复杂任务需要可被编排、可被观测、可被控制”。大模型本身只能做”输入到输出”的映射，没有持续执行复杂任务的能力。工作流把复杂任务拆成可管理的步骤，让系统具备工程上的可控性。

具体原因有五个：

第一，任务可拆解。复杂任务（如”分析用户数据并生成报告”）需要拆成多个子任务（数据获取、清洗、分析、可视化、写作）。工作流提供拆解的载体。

第二，路径可编排。任务步骤之间有依赖关系（先清洗才能分析）、有并行可能（多个数据源可同时获取）、有条件分支（数据缺失时跳过某些步骤）。工作流提供编排机制。

第三，状态可管理。长任务需要保存中间结果、记录已完成步骤、跟踪任务进度。工作流通过 State 对象管理这些状态。

第四，失败可恢复。任意步骤可能失败，网络可能超时，工具可能不可用。工作流提供重试、降级、回滚机制，让系统从失败中恢复。

第五，过程可观测。每一步走到哪里、消耗多少时间、产生什么结果、失败原因是什么——工作流提供轨迹记录和可视化。

AI 系统的工作流和传统软件工作流的区别在于：传统工作流的每个 Node 是确定性的代码，AI 工作流的 Node 可以是 LLM 调用（带不确定性）。但即使是 LLM Node，整个工作流的骨架仍然是确定的——这让 AI 系统既享受 LLM 的能力，又保留工程可控性。

常见误区是”既然用了 AI，就让它自己规划流程”。这种想法忽视了工程可控性的价值。生产级 AI 系统几乎都是”工作流编排 + 节点智能”的组合，纯粹的”AI 自主规划”在生产中很难稳定。

关键要点#

• 工作流提供复杂任务的拆解、编排、状态管理、失败恢复、可观测性。
• AI 工作流和传统工作流的核心区别是 Node 可以是 LLM 调用。
• 工作流不是”过时方案”，是生产 AI 系统的骨架。

容易踩的坑#

• 认为”AI 自主规划”可以替代工作流。
• 把工作流讲成”过时技术”。
• 没意识到工作流提供工程可控性，是 AI 落地的关键。

示范话术#

AI 系统需要工作流，本质是”复杂任务需要可被编排、可被观测、可被控制”。具体五个原因：任务可拆解、路径可编排、状态可管理、失败可恢复、过程可观测。AI 工作流和传统工作流的核心区别是 Node 可以是 LLM 调用——这让系统既享受 LLM 的能力，又保留工程可控性。我特别想强调一个常见误区：很多人觉得”既然用了 AI，就让它自己规划流程”，这忽视了工程可控性的价值。生产级 AI 系统几乎都是”工作流编排 + 节点智能”的组合，纯粹 AI 自主规划在生产中很难稳定。讲这一题我会用一句话收尾：工作流是 AI 系统的骨架，不是 AI 系统的枷锁。

核心答案#

Workflow、Graph、Loop 是三个不同层次的概念。Workflow 是任务过程，Graph 是结构载体，Loop 是控制模式。三者不是替代关系，而是从不同维度描述 AI 系统的运行方式。

Workflow（工作流） 关注”做什么、按什么顺序做”。它是一个抽象概念，描述”从输入到输出的完整过程”，由若干步骤和步骤之间的流转关系组成。Workflow 不关心具体用什么技术实现——可以用代码、可以用图、可以用状态机。

Graph（图） 关注”用什么结构承载工作流”。Graph 把工作流具象化为节点（Node）和边（Edge）的有向图。Node 是执行单元（代码块、LLM 调用、工具调用），Edge 是流转规则（顺序、条件、并行）。Graph 是 Workflow 的一种常见实现方式。

Loop（循环） 关注”如何重复执行某些步骤直到满足条件”。Loop 是控制模式，可能出现在 Graph 的某个节点内（比如 ReAct Agent 的推理-行动-观察循环），也可能出现在 Graph 的整体结构中（比如 Plan-and-Execute 中 Replanner 触发重规划）。Loop 是 Workflow 中的特定控制逻辑。

三者关系可以用一个例子说明：一个”研究某主题并写报告”的工作流。它的 Workflow 包含”主题理解 → 资料检索 → 信息整理 → 报告写作”四步；用 Graph 实现时，每个步骤是一个 Node，Node 之间用顺序 Edge 连接；“资料检索”节点内部可能有一个 Loop——重复检索-评估-补充直到资料充分。

更细致的关系可以这样总结：

• Workflow = 抽象任务过程
• Graph = 任务过程的结构化表达
• Loop = 任务过程中的控制模式

常见组合：

• Workflow + Graph：用图结构实现工作流（最常见）。
• Graph + Loop：图中某些节点内部或整体有循环。
• Workflow + Loop：工作流中有重复执行的部分。

注意：Graph Loop 和 Agent Loop 是不同的概念。Graph Loop 是图结构内的循环（结构化、可控），Agent Loop 是 Agent 系统反复推理-行动-观察的循环（动态、可能不可控）。两者经常被混用，但工程含义不同。

关键要点#

• Workflow 是任务过程（抽象），Graph 是结构载体（具象），Loop 是控制模式（特定逻辑）。
• 三者从不同维度描述 AI 系统，不是替代关系。
• 常见组合是”Workflow + Graph + 局部 Loop”。

容易踩的坑#

• 把三者混为一谈，统称”工作流”。
• 不知道 Graph Loop 和 Agent Loop 的区别。
• 没意识到 Workflow 是抽象概念，不依赖具体实现。

示范话术#

Workflow、Graph、Loop 三者我会用一句话区分：Workflow 是任务过程，Graph 是结构载体，Loop 是控制模式。Workflow 关注”做什么按什么顺序”，是抽象概念；Graph 关注”用什么结构承载工作流”，是具象化的节点和边的有向图；Loop 关注”如何重复执行直到满足条件”，是特定控制逻辑。三者从不同维度描述 AI 系统。比如”研究主题写报告”：Workflow 是四步过程；Graph 是四个 Node 加顺序 Edge；“资料检索”节点内部有 Loop 重复检索直到充分。讲这一题我会特别强调：Graph Loop 和 Agent Loop 是不同概念——前者是图结构内的循环（结构化可控），后者是 Agent 推理-行动的循环（动态可能不可控）。混用这两个词，面试官一听就知道概念不清。

核心答案#

Graph Loop 和 Agent Loop 是两类本质不同的循环，混用会暴露概念不清。区别可以从五个维度展开。

第一，驱动力不同。Graph Loop 由”图结构中的条件边”驱动——当某个条件满足时回到之前的 Node。Agent Loop 由”LLM 的推理决策”驱动——每轮推理决定下一步做什么。

第二，可控性不同。Graph Loop 路径完全由程序员编排，可控性高——条件是什么、跳到哪里、何时退出都明确。Agent Loop 路径由模型动态决定，可控性低——模型可能走出意料之外的路。

第三，退出条件不同。Graph Loop 退出条件是显式判断（比如”重试次数达到 3 次""质量评分达到 0.9”）。Agent Loop 退出条件是模型自判 + 工程兜底（最大步数、最大 Token、显式成功信号）。

第四，调试难度不同。Graph Loop 失败时直接看图结构，定位”哪个条件没满足”。Agent Loop 失败时要回放整条推理轨迹，定位”哪一步模型判断错了”。

第五，适用场景不同。Graph Loop 适合”重复执行直到满足已知条件”的场景，比如重试 3 次、调用直到拿到有效数据。Agent Loop 适合”开放式探索直到任务完成”的场景，比如 ReAct 推理-行动-观察循环。

用一个具体例子说明两者差异。考虑”调用 API 获取数据”任务：

• 用 Graph Loop 实现：调用 API → 检查返回码 → 如果失败重试，最多 3 次；返回 200 则退出。
• 用 Agent Loop 实现：让 LLM 决定”是否需要再调一次 API”，根据返回内容决定下一步。

Graph Loop 的实现是确定性的（“最多 3 次”是硬规则），Agent Loop 的实现是动态的（“是否再调”由模型判断）。生产中两种循环经常组合使用——主流程用 Graph Loop 处理已知重试逻辑，节点内用 Agent Loop 做智能判断。

常见误用是把所有循环都叫”Agent Loop”。比如”重试机制”本质是 Graph Loop，不是 Agent Loop；“用户多轮对话”本质是 Workflow，不是 Loop。术语精确是工程基本功。

关键要点#

• Graph Loop 由条件边驱动，可控性高；Agent Loop 由 LLM 推理驱动，可控性低。
• 退出条件、调试难度、适用场景都不同。
• 两者经常组合使用——主流程 Graph Loop，节点内 Agent Loop。

容易踩的坑#

• 把所有循环都叫”Agent Loop”。
• 不区分条件驱动的循环和推理驱动的循环。
• 用 Graph Loop 的方式控制 Agent Loop（会失去灵活性）。

示范话术#

Graph Loop 和 Agent Loop 我会从五个维度区分。驱动力——Graph Loop 由条件边驱动，Agent Loop 由 LLM 推理驱动；可控性——Graph Loop 路径完全由程序员编排，Agent Loop 路径由模型决定；退出条件——Graph Loop 是显式判断，Agent Loop 是模型自判加工程兜底；调试难度——Graph Loop 直接看图结构，Agent Loop 要回放推理轨迹；适用场景——Graph Loop 适合”重复到满足已知条件”，Agent Loop 适合”开放式探索到任务完成”。举个例子，“调用 API 拿数据”用 Graph Loop 是”失败重试最多 3 次”，用 Agent Loop 是”让 LLM 决定是否再调一次”。讲这一题我会特别强调术语精确——把重试叫 Agent Loop、把所有循环都叫 Agent Loop，面试官一听就知道概念没分清。

核心答案#

Loop 防止死循环需要”四道闸门”：继续条件、退出条件、最大步数、最大成本。缺任何一道，Loop 都有失控风险。

继续条件（Continue Condition）定义”什么时候继续循环”。继续条件要清晰、具体、可验证。模糊的继续条件（如”继续直到任务完成”）会让 Loop 不知道什么时候该停。生产中继续条件通常包括：质量评分阈值、关键字段非空、用户确认、特定信号触发。

退出条件（Exit Condition）定义”什么时候退出循环”。退出条件要和继续条件互补——满足继续条件就继续，不满足就退出。退出条件要显式、可观测、可触发具体动作（保存结果、通知用户、记录日志）。

最大步数（Max Iterations）是最硬的兜底。任何 Loop 都必须设最大步数，即使业务上认为不可能死循环。这是因为 LLM 不确定性可能让 Loop 走出意外路径，不设上限会无限循环。常见上限：3-5 次（重试类）、10-20 次（推理类）、50-100 次（探索类）。

最大成本（Max Cost）是经济兜底。任何 Loop 都必须设最大 Token 预算，超过就强制终止。这是成本控制的关键——Agent 失控时 Token 消耗可能几分钟内爆掉几千美元。常见做法：累计 Token 超过阈值自动 kill loop、写审计日志、通知管理员。

除了四道闸门，辅助防护有四个：

• 轨迹记录：每轮 Loop 记日志，包括输入、输出、判断依据、当前步数。事后能反查为什么没退出。
• 状态检查：每轮检查关键状态字段，发现异常（比如质量评分持续下降）就触发退出。
• 循环检测：检测到”重复调用相同工具且参数相同”或”重复进入相同状态”时强制退出。
• 用户中断：提供手动 kill 机制，用户可以主动终止失控 Loop。

死循环的常见根因有四个：继续条件写错（永远满足）、退出条件没写（默认继续）、最大步数没设（无兜底）、状态没管理（LLM 不记得之前做过了）。

Loop 防死循环的设计原则是”假设 Loop 一定会出问题，把每一种可能都加上防护”。

关键要点#

• 四道闸门：继续条件、退出条件、最大步数、最大成本。
• 最大步数和最大成本是最硬的兜底，任何 Loop 都必须设。
• 辅助防护：轨迹记录、状态检查、循环检测、用户中断。

容易踩的坑#

• 只设继续条件不设退出条件。
• 没设最大步数，让 Loop 无限跑。
• 没设 Token 预算，让成本爆炸。
• 没做循环检测，让”看起来在做、其实卡住”的 Loop 跑很久。

示范话术#

Loop 防死循环我会建”四道闸门”：继续条件、退出条件、最大步数、最大成本。继续条件定义什么时候继续，退出条件定义什么时候停——两个条件互补。最大步数是最硬的兜底，任何 Loop 都必须设——LLM 不确定性可能让 Loop 走出意外路径，不设上限会无限跑。最大成本是经济兜底，累计 Token 超过阈值就 kill。辅助防护有四个：轨迹记录、状态检查、循环检测、用户中断。我见过太多 Loop 没设最大步数也没设最大成本，结果 Agent 失控几分钟烧掉几千美元。讲这一题我会强调一个原则：假设 Loop 一定会出问题，把每一种可能都加上防护。

核心答案#

State 是工作流跨节点共享的数据容器。State 更新策略要按字段语义选择，三种基本策略是 Replace、Append、Reducer。

Replace（替换） 用新值覆盖旧值。适合单值字段——比如当前任务状态、当前步骤、当前用户输入、最新结果。一个字段只有一个”当前值”，新值来了旧值就没意义，必须替换。生产中绝大多数字段用 Replace。

Append（追加） 把新值追加到列表末尾，保留所有历史值。适合日志类字段——比如执行轨迹、错误日志、工具调用历史、用户操作记录。这些字段的价值在于”完整的演进过程”，不能丢历史。

Reducer（聚合） 把新值和旧值按规则合并成新值。适合并行写入或需要合并语义的字段——比如多个 Agent 输出的合并、并发任务的计数、并发检索结果的汇总。Reducer 是”自定义合并逻辑”，比 Append 更灵活。

具体选择可以按字段类型判断：

• 单值字段（状态、参数、当前结果）→ Replace
• 日志字段（轨迹、错误、操作记录）→ Append
• 计数/汇总字段（得分、计数、并发结果）→ Reducer
• 列表字段（候选集、待处理队列）→ 看场景，需要去重就 Replace，需要保留就 Append
• 嵌套结构字段（子任务状态、复杂对象）→ 自定义 Reducer 处理每个子字段

State 设计的常见错误有四个：

第一，所有字段都用 Replace。日志、轨迹被覆盖，丢失演进过程，出问题无法回溯。

第二，所有字段都用 Append。单值字段不断追加变成列表，占内存且难以取”当前值”。

第三，并行写入时没有 Reducer。多个节点同时写同一字段，后写的覆盖先写的，丢失数据。

第四，Reducer 设计不合理。合并逻辑有 bug，比如重复计数、合并冲突、产生 NaN。

生产级 State 设计原则有四个：每个字段明确标注更新策略、并行写入字段必须用 Reducer、日志类字段设上限避免无限增长、State 变更记审计日志便于回溯。

关键要点#

• Replace 适合单值字段，Append 适合日志字段，Reducer 适合并发/合并字段。
• 字段语义决定更新策略，不能”一刀切”。
• 并行写入字段必须用 Reducer，否则数据丢失。

容易踩的坑#

• 所有字段都用 Replace 或都用 Append。
• 并行写入没有 Reducer。
• 日志字段无上限，State 无限膨胀。
• Reducer 有 bug，产生错误数据。

示范话术#

State 更新策略我会按字段语义选。Replace 适合单值字段——当前任务状态、当前步骤、最新结果，一个字段只有一个当前值。Append 适合日志字段——执行轨迹、错误日志、工具调用历史，价值在于完整演进过程，不能丢历史。Reducer 适合并行写入或需要合并的字段——多个 Agent 输出合并、并发任务计数、并发检索结果汇总。常见错误有四个：所有字段都用 Replace 导致日志丢失、所有字段都用 Append 导致单值字段膨胀、并行写入没有 Reducer 导致数据丢失、Reducer 设计不合理产生错误数据。讲这一题我会强调：字段语义决定更新策略，并行写入字段必须用 Reducer。把这两点讲清楚，面试官就知道你设计过真实的 State 系统。

核心答案#

条件边（Conditional Edge）和动态路由（Dynamic Routing）都是工作流中的”分支决策机制”，但解决问题的层次不同。条件边由图结构静态定义，动态路由由模型在运行时动态决定。

条件边是图结构中”满足条件就走某条边”的规则。比如”如果数据为空，走 A 路径；否则走 B 路径”。条件边的特征：条件定义是静态的（在图定义时写好）、条件判断是确定性的（基于 State 字段值）、可枚举的分支数量是有限的。

动态路由是”在运行时由模型（或运行时逻辑）决定下一步走哪”的机制。比如 LLM 决定”这个问题该走技术支持还是销售支持”。动态路由的特征：路由选择是动态的（每轮执行时决定）、路由依据是不确定的（LLM 推理）、可能产生新的分支。

两者关系可以这样理解：条件边是”图层面的选择”，动态路由是”模型层面的选择”。条件边适合”决策规则明确、可枚举”的分流；动态路由适合”决策依赖语义理解、可能产生新路径”的分流。

具体差异有五个维度：

第一，决策依据。条件边依据 State 字段值；动态路由依据 LLM 输出。

第二，可预测性。条件边完全可预测；动态路由不完全可预测。

第三，可调试性。条件边失败时直接看条件判断；动态路由失败时要回放模型推理。

第四，性能。条件边判断是 O(1) 的逻辑；动态路由要调一次 LLM。

第五，Token 成本。条件边几乎不消耗 Token；动态路由每路由一次消耗 Token。

生产中两种机制经常组合——主干用条件边处理已知分支（“文件不存在则报错""数据为空则跳过”），关键决策点用动态路由让模型判断（“用户问题属于哪个分类""任务该用哪个工具”）。这种组合既保留可预测性，又享受模型智能。

常见反模式有两种：一是把所有分支都做成条件边（限制了 Agent 灵活性）；二是把所有分支都做成动态路由（成本高、调试难、不可预测）。正确的做法是”已知条件用条件边，开放判断用动态路由”。

关键要点#

• 条件边是图层面的静态选择，动态路由是模型层面的动态选择。
• 条件边适合”决策规则明确、可枚举”，动态路由适合”决策依赖语义、可能产生新路径”。
• 生产中两者经常组合使用。

容易踩的坑#

• 把所有分支都做成条件边，限制灵活性。
• 把所有分支都做成动态路由，成本高且难调试。
• 不知道两者的决策依据和性能差异。

示范话术#

条件边和动态路由我会用”图层面 vs 模型层面”来区分。条件边是图结构里写死的 if-else，依据 State 字段值判断——比如”文件不存在走 A 路径，否则走 B 路径”，完全可预测。动态路由是运行时由模型决定下一步走哪——比如让 LLM 判断”用户问题该走技术支持还是销售支持”，依赖语义理解。两者各有适用场景：条件边适合决策规则明确、可枚举的分流；动态路由适合决策依赖语义、可能产生新路径的分流。生产中我经常组合用——主干用条件边处理已知分支（文件不存在则报错、数据为空则跳过），关键决策点用动态路由让模型判断（问题分类、工具选择）。讲这一题我会强调反模式：所有分支都做条件边会限制灵活性，所有分支都做动态路由会成本爆炸且难调试。正确做法是”已知条件用条件边，开放判断用动态路由”。

核心答案#

工作流中断（崩溃、超时、人工 kill、Token 超限）后的恢复是工程化必备能力。核心思想是”任何时刻都能从最近断点继续，而不是从零开始”。

实现恢复需要四个机制：状态持久化、检查点、恢复执行、幂等性。

状态持久化（State Persistence）。工作流执行时，State 持续写入持久化存储（数据库、文件系统、对象存储）。写入时机：每完成一个 Node 写入一次、关键状态变更立即写入、写入失败要重试。生产中常用”Write-Ahead Log”模式——先写日志再执行。

检查点（Checkpoint）。检查点是”任务可以恢复的快照点”，包含：当前 State、已完成 Node 列表、当前所在 Node、已经产生的副作用记录。检查点要定期生成（每 N 步一次、每 M 秒一次、每个关键 Node 完成后一次）。

恢复执行（Resume Execution）。任务被中断后下次启动时，先检查是否有未完成任务的检查点。如果有，加载检查点，跳过已完成 Node，从中断点继续执行；如果没有，从任务起点开始。恢复时还要检查”环境是否一致”——工具版本、数据状态、外部依赖是否变化。

幂等性（Idempotency）。这是恢复的关键前提。任何 Node 的执行必须是幂等的——重复执行同一个 Node 不会产生副作用累积或数据不一致。比如”发送邮件”节点必须先去重检查是否已发送；“扣款”节点必须用唯一事务 ID 防止重复扣款；“写文件”节点必须检查内容是否已存在。

如果 Node 不幂等怎么办？两种处理方式：一种是在 Node 执行前用检查点里的副作用记录判断”是否已执行过”，执行过就跳过；另一种是把副作用操作放在”提交阶段”统一执行，恢复时只恢复计算，不重复执行副作用。

恢复的工程细节有四个：

第一，检查点的存储成本。检查点不能太频繁（否则存储和 IO 开销大），也不能太稀疏（否则恢复时丢失太多进度）。常见平衡是”每个 Node 完成写一次检查点 + 每 5 分钟写一次时间检查点”。

第二，恢复时的版本兼容。如果工作流定义升级了（Prompt 改了、Harness 改了），老检查点可能无法恢复。处理方式是检查点带工作流版本号，版本不匹配时拒绝恢复或迁移。

第三，部分恢复的边界。如果某些 Node 已经产生不可逆副作用（比如已经发了邮件），恢复时不能跳过这些 Node，要从它们的下游继续。

第四，超时恢复的区分。有些中断是临时性的（网络抖动），重试即可；有些是永久性的（工具下线），需要降级方案或人工介入。

关键要点#

• 恢复需要四机制：状态持久化、检查点、恢复执行、幂等性。
• 幂等性是恢复的关键前提，不幂等的 Node 必须做副作用去重。
• 恢复要考虑检查点成本、版本兼容、部分恢复、超时区分。

容易踩的坑#

• Node 不幂等，恢复时重复执行产生副作用。
• 没有检查点，中断后只能从零开始。
• 工作流升级后老检查点无法恢复。
• 不区分临时中断和永久中断，所有中断都简单重试。

示范话术#

工作流中断后怎么恢复，核心是”任何时刻都能从最近断点继续”。实现需要四个机制：状态持久化把 State 持续写入持久存储；检查点是任务可恢复的快照点；恢复执行时加载检查点跳过已完成 Node；幂等性是恢复的关键前提——任何 Node 重复执行都不能产生副作用累积。我特别想强调幂等性，这是最容易踩的坑：如果”发送邮件”节点不幂等，恢复时可能重复发邮件；“扣款”节点不幂等，可能重复扣款。处理方式是副作用操作带唯一事务 ID，或者用检查点里的副作用记录判断是否已执行。讲这一题我会强调四个工程细节：检查点不能太频繁也不能太稀疏、工作流升级后老检查点要带版本号、不可逆副作用的 Node 不能跳过恢复、临时中断和永久中断要区分处理。

核心答案#

工作流虽然比纯 Agent 更可控，但有自己特有的安全风险。这些风险不来自 Agent 智能，而来自工作流的结构化执行模式。常见风险有六类。

第一，节点越权。工作流编排时可能给某个 Node 过高权限，比如”删文件”节点能删任何路径。如果该 Node 的输入校验不严，被恶意输入利用，可能导致越权操作。防护：每个 Node 严格限制操作范围、参数做白名单校验、敏感操作走独立账号。

第二，状态泄露。State 是跨节点共享的数据容器，可能包含敏感信息（用户隐私、API Key、Token）。如果 State 写入日志、写入监控、写入第三方存储，可能泄露。防护：State 字段分级敏感度、敏感字段加密存储、日志脱敏、审计 State 访问。

第三，循环放大。工作流中的循环如果不设上限，可能被恶意输入或异常数据触发无限循环，导致资源耗尽、成本爆炸。防护：最大步数、最大成本、最大时间三道闸门；循环检测机制。

第四，并发竞争。多个工作流实例同时修改同一份数据，可能产生竞态条件。比如两个实例同时”读取—修改—写回”同一 State 字段，后写的覆盖先写的。防护：用数据库事务、乐观锁、悲观锁；State 更新用 Reducer；关键操作串行化。

第五，依赖注入。工作流的输入来自外部（用户输入、API 调用、Webhook），这些输入可能包含恶意指令（Prompt 注入）或攻击载荷（SQL 注入、命令注入）。防护：所有输入做格式校验、长度限制、敏感字符过滤；用参数化查询；高敏感操作不接外部输入。

第六，错误信息泄露。工作流失败时返回的错误信息可能包含内部细节（Stack Trace、数据库结构、API 路径、密钥片段）。攻击者可以利用这些信息做进一步攻击。防护：自定义错误信息（对用户友好、对内部详细）、错误日志分级、敏感字段在错误信息中脱敏。

工作流特有风险的共性是”可控性带来确定性，确定性带来可预测的攻击面”。纯 Agent 的失败模式是不确定的、随机的；工作流的失败模式是可预测的、可被利用的。所以工作流的安全防护重点不是”防模型出错”，而是”防结构被攻击”。

和纯 Agent 的安全风险对比：

• 纯 Agent 风险：Prompt 注入、模型幻觉、工具越权、Token 成本失控。
• 工作流特有风险：节点越权、状态泄露、循环放大、并发竞争、依赖注入、错误信息泄露。

防护原则是”零信任 + 最小权限”——假设任何输入都可能恶意、任何 Node 都可能被攻击、任何 State 字段都可能被泄露。每个 Node 严格按最小权限执行，每个 State 字段按敏感度分级保护，每个输入按恶意数据校验。

关键要点#

• 工作流特有风险：节点越权、状态泄露、循环放大、并发竞争、依赖注入、错误信息泄露。
• 共性是”可控性带来确定性，确定性带来可预测的攻击面”。
• 防护原则是”零信任 + 最小权限”。

容易踩的坑#

• 把工作流当成”安全的”，忽略特有风险。
• 节点权限过大，被恶意输入利用。
• State 敏感信息写入日志或第三方存储。
• 错误信息泄露内部细节。

示范话术#

工作流虽然比纯 Agent 更可控，但有自己特有的安全风险。常见六类：节点越权、状态泄露、循环放大、并发竞争、依赖注入、错误信息泄露。这些风险的共性是”可控性带来确定性，确定性带来可预测的攻击面”——纯 Agent 失败模式是随机的，工作流失败模式是可预测可利用的。我举个例子：工作流中的”删文件”节点如果权限过大，能删任何路径，恶意输入可能让 Agent 删掉生产数据；State 里如果有 API Key，写入日志就泄露；循环不设上限可能被攻击者触发资源耗尽。防护原则是”零信任 + 最小权限”——每个 Node 严格按最小权限执行，每个 State 字段按敏感度分级保护，每个输入按恶意数据校验。讲这一题我会强调：工作流不是”绝对安全”的，它的安全防护重点是”防结构被攻击”，不是”防模型出错”。