Agent 与固定流程：两类智能应用的核心区别与选型思路

一、为什么需要区分固定流程与智能体

在智能应用开发中，一个常见的困惑是：为什么有些系统被称为智能体，却表现得像固定流程；而有些系统没有智能体标签，反而具备很强的动态决策能力。这个困惑背后涉及一个更本质的问题：系统的下一步动作，究竟由谁决定。

如果执行路径在代码中预先写死，模型只在若干固定节点参与内容生成或结构化提取，那么这类系统更接近固定流程。它强调的是可预测性、可复现性和低延迟。典型场景包括：按固定顺序完成文档解析、信息抽取、格式转换、结果校验的批处理任务。

如果下一步动作由模型根据当前状态、历史消息和工具返回结果动态决定，那么这类系统更接近智能体。它强调的是灵活性和上下文适应能力。典型场景包括：需要多轮工具调用、结果不确定、任务路径无法提前枚举的复杂操作。

这一区分不是学术定义之争，而是直接影响工程实现、测试策略、故障排查方式和长期维护成本。把固定流程误判为智能体，容易引入不必要的模型调用和不确定行为；把智能体压缩成固定流程，又可能牺牲它在复杂任务中的泛化能力。

二、核心差异：控制权掌握在谁手里

两类系统的根本差异可以抽象为控制权归属。固定流程的控制权掌握在代码中：条件分支、循环次数、异常处理、工具调用顺序都由开发者预先定义。模型只承担局部推理任务，不参与全局路径规划。

智能体的控制权则部分让渡给模型。主循环通常保持稳定，负责维护消息上下文、调用模型、接收响应、分发工具结果。真正决定何时停止、下一步调用哪个工具、是否重新解释用户意图的，是模型在该轮上下文中的推理结果。

一个常见的智能体主循环可以用不到二十行核心逻辑表达：

const messages = [{ role: 'user', content: userInput }];
while (true) {
  const response = await client.messages.create({
    model: 'current-main-model',
    max_tokens: 8096,
    tools: toolDefinitions,
    messages,
  });
  if (response.stop_reason === 'tool_use') {
    const toolResults = await Promise.all(
      response.content
        .filter((item) => item.type === 'tool_use')
        .map(async (item) => ({
          type: 'tool_result',
          tool_use_id: item.id,
          content: await executeTool(item.name, item.input),
        }))
    );
    messages.push({ role: 'assistant', content: response.content });
    messages.push({ role: 'user', content: toolResults });
  } else {
    return response.content.find((item) => item.type === 'text')?.text ?? '';
  }
}

这段逻辑稳定地执行“感知、决策、行动、反馈”四个阶段，直到模型返回纯文本为止。值得关注的是，循环本身并没有随着功能增加而膨胀。子任务编排、上下文压缩、能力加载等新特性，通常通过外部机制叠加，而不是在循环内部增加复杂状态判断。

这也是两类方案在架构上的重要差异：智能体需要明确划分“模型负责推理”和“外部系统负责状态与边界”，否则主循环容易退化成难以维护的大型状态机。固定流程则天然把状态管理放在代码结构中，每一步都有明确入口和出口。

三、相同点：都需要工具与验证体系支撑

尽管控制权归属不同，两类方案在工程支撑上有明显重合。它们都需要工具定义、工具执行环境和结果回传机制。工具描述是否准确、参数约束是否清晰、返回内容是否可被模型稳定理解，直接影响最终成功率。

在实际经验中，工具选择错误的原因往往不是模型推理能力不足，而是工具描述与真实行为不一致。例如描述中写“查询用户订单”，但实际接口要求先传入用户标识再传入时间范围；描述中写“返回列表”，实际返回的是被包装过的对象结构。模型无法通过描述感知这些细节，只能根据可见信息做出判断，因此错误会持续出现。

验证测试质量同样影响两类方案。固定流程可以用确定性用例覆盖主要分支，验证成本相对可控。智能体则需要更接近真实使用方式的评测集，包括多轮工具组合、歧义输入、工具返回异常、部分成功等场景。如果评测系统本身存在问题，例如评分逻辑过于简单、环境状态没有正确隔离、结果判定依赖不稳定规则，那么即使智能体行为已经改善，也可能无法在评测中体现。

一个容易被忽视的现象是：当评测结果长期没有变化时，开发者往往倾向于反复调整提示词或模型参数，但真正的问题可能出在评测基准无法区分不同行为。先验证评测系统是否可信，再调整智能体实现，通常比直接修改主体代码更有效。

四、扩展方式差异：循环外部叠加与节点内部调整

智能体的扩展通常通过三种方式接入：扩展工具集与处理函数、调整系统提示结构、将状态外化到文件或数据库。主循环保持稳定，新增能力落在循环之外。例如需要让智能体具备长期记忆，可以在每轮结束后把关键信息写入存储，在下轮开始前注入上下文，而不是修改循环判断逻辑。

固定流程的扩展方式更接近节点内部调整。当业务规则变化时，需要新增处理节点、调整条件分支或替换某个步骤的执行逻辑。这种方式在小规模、规则明确的系统中非常直观，但随着节点增多，维护成本会非线性上升。

两者没有绝对优劣。固定流程适合规则稳定、路径清晰的场景；智能体适合目标明确但路径多变的场景。更重要的是，当前不少实际产品处于两者之间：外层是固定流程，内部某个节点使用智能体完成复杂子任务。这种混合方式往往比纯智能体更稳定，比纯固定流程更灵活。

五、选型维度对比

维度	固定流程	智能体
控制权	代码预先定义	模型动态决策
执行路径	确定性强	路径可能变化
扩展位置	节点内部与流程编排	循环外部工具与状态
调试重点	节点逻辑与数据传递	工具描述与上下文设计
失败原因分布	规则遗漏、边界处理不足	工具选择错误、上下文不足
评测难度	较低，可覆盖主要分支	较高，需考虑多轮组合
延迟表现	通常更可控	受模型推理轮次影响
长期维护	节点多时成本上升	更依赖工具与评测体系

这张表不能直接给出“应该选哪个”的答案，但可以帮助判断当前团队更需要哪种能力。如果业务方要求每一步都可解释、可预测、可审计，固定流程的确定性和故障定位能力更有优势。如果任务本身无法提前枚举所有路径，或者需要模型根据执行过程中的新信息调整策略，智能体更合适。

六、调试优先级：先看工具定义，再看评测质量

在调试智能体时，模型行为和工具定义之间的边界需要被特别关注。一条实用经验是：如果智能体在多轮交互中持续选择错误工具，首先检查工具描述是否准确、参数示例是否真实、返回结构是否和描述一致。很多看起来像推理错误的问题，修复工具定义后就能明显改善。

如果工具定义没有问题，下一步应检查系统提示是否足够清晰。系统提示需要说明当前任务目标、可用工具边界、执行约束和停止条件。缺少这些信息，模型可能在多轮循环中反复尝试同一无效工具，或者过早返回纯文本。

如果以上两者都调整过仍无明显改善，可能需要重新审视评测系统。评测用例是否覆盖了真实失败模式？评分标准是否稳定？环境状态是否正确重置？当评测本身存在偏差时，任何主体代码修改都可能被错误地判断为无效。

七、固定流程与智能体的混合使用

现实中大多数生产系统并不需要在全链路使用智能体。常见做法是在最适合动态决策的环节引入智能体，其余部分保留固定流程。例如一个内容处理管道可以设计为：固定流程负责接入、校验、存储和通知，智能体负责需要语义判断的抽取、分类或异常处理。

这种混合方式对工程团队更友好。它把不确定行为限制在局部范围内，避免调度整体不稳定；同时保留了智能体在复杂判断上的优势。团队在进行改造时，可以逐步把部分节点替换为智能体，而不是一次性推翻原有流程。

混合方式的边界设计需要明确：哪些信息传给智能体，哪些结果由固定流程继续消费；智能体的超时、空返回、多次工具调用如何被外层处理；当智能体结果不符合下游格式要求时，是重试、降级还是转人工。

八、迁移与长期维护注意事项

如果从固定流程迁移到智能体，不建议直接重写整个业务。可以先选择一个适合智能体发挥、同时风险可控的节点进行试点，通过对比原有节点与智能体节点的准确率、延迟、可解释性和异常率，评估迁移收益。

在迁移之前，需要确认是否有足够质量的工具定义、评测集和运行日志。智能体的行为高度依赖这三者。没有高质量工具定义，模型无法做出稳定决策；没有可靠评测集，改进无法被客观衡量；没有运行日志，问题发生后很难还原上下文。

长期维护智能体时，主循环逻辑应尽量保持稳定。功能扩展优先通过新增工具、优化系统提示和外部状态实现，而不是在主循环中加入越来越多分支判断。这样可以保留系统的可测试性和可理解性，也便于在不同任务间复用核心逻辑。

九、总结

固定流程与智能体的核心区别不在于是否调用模型，而在于下一步动作由谁决定。固定流程用代码控制路径，适合规则稳定、可预测性要求高的场景；智能体把路径决策交给模型，适合目标明确但执行方式多变的场景。

两者的工程支撑高度重合：都需要清晰的工具定义、可靠的验证体系和可维护的状态管理。真正影响成功率的，往往不是模型参数高低，而是工具描述是否准确、评测质量是否可信、主循环与外部状态边界是否清晰。选择哪种方案，不应只看概念标签，而应回到一个基本问题：当前任务的控制权，应该放在代码里，还是交给模型。