一、单体 Agent 的能力边界Agent 开发初期通常采用一个模型、一套 System Prompt 和多个 Tool 的形式。模型理解用户问题后自主选择工具并整理结果。这种结构开发成本低能够快速覆盖知识问答、数据查询和简单任务执行。这类结构为增强型智能体。当业务能力有限时它非常有效。问题出现在 Tool 数量和业务类型持续增长以后。课程推荐、课程咨询、购买和知识问答全部进入一个 Agent 后Prompt 会不断扩张工具定义也越来越多整个 Agent 的职责逐渐失去边界。因此Agent 架构升级通常来自复杂度增长而不是单纯追求更多模型。二、增强型 Agent 的适用范围增强型 Agent 可以表示为Input ↓ LLM Prompt Tools ↓ Output这种架构最适合业务能力相对集中、工具数量可控的场景。例如一个科研助手主要负责文献检索、数据库查询和简单统计计算把这些能力集中到同一个 Agent 中可以减少不必要的路由和编排。增强型 Agent 的优势来自结构简单。模型拥有较高决策自由度应用代码只需要提供能力和必要约束。当工具之间已经属于不同业务领域或者 Prompt 中开始出现大量互不相关的规则时就需要考虑把单一 Agent 拆分【业务、工具、Prompt规则多了需要区分时单体增强型Agent也需要架构升级】。三、链式工作流的阶段化处理链式工作流适用于业务步骤比较固定、单次模型调用难以保证质量的复杂任务。它通过多个阶段依次完成任务后一个阶段使用前一个阶段的输出。例如文章生成可以设计成主题 ↓ 大纲生成 ↓ 大纲检查 ↓ 正文生成 ↓ 内容检查 ↓ 最终输出链式架构的优势在于阶段职责明确。Prompt 可以围绕当前任务单独设计甚至可以为不同阶段选择不同模型【即控制每一步骤的结果受控更加准确、符合预期而不是放任单步结果】。它的限制同样明显。模型调用次数增加以后延迟和成本会同步增加。因此链式工作流适合“复杂度主要来自多个固定步骤”的任务。四、路由工作流的业务拆分路由式架构解决的是另一种复杂度用户请求存在多个相互独立的业务方向。基本结构可以表示为用户输入 ↓ Router / 意图识别 ↓ 推荐 Agent 咨询 Agent 购买 Agent 知识 AgentRouter 只负责分析用户意图后续业务交给专业 Agent。课程以智能客服和课程助手为例售前、售后或者课程推荐等不同业务可以进入独立处理模块。这种方式最大的价值是降低单个 Agent 的职责范围。推荐 Agent 只需要推荐工具购买 Agent 管理交易流程知识 Agent 负责知识检索。不同业务 Prompt 和 Tool 不再堆积在同一个上下文中。新增业务时只需要增加对应 Agent 和路由规则原有 Agent 可以继续独立演进。五、工作流节点与 Agent 的关系学习工作流时容易产生一个概念误区图中出现一次 LLM Call就把这个节点直接理解成一个完整 Agent。更准确的理解是工作流节点描述的是一个执行单元。节点可以只是一次模型调用也可以包含 Tool Calling、Memory 和多轮迭代。是否称为 Agent应根据它是否具有独立目标、状态和决策能力判断。因此路由架构中 Router 可以只是一次轻量意图分类也可以由模型实现。后面的业务节点可以是简单 Service也可以是真正具有 Tool Calling 能力的 Agent。这种理解更有利于工程设计因为架构应该围绕任务职责拆分而不是围绕名称拆分。六、三类架构的选型逻辑增强型、链式和路由式分别解决不同来源的复杂度。能力集中、任务简单 → 增强型 处理过程固定、多阶段 → 链式 业务类型并列、多分支 → 路由式真正的系统可以组合这些结构。例如入口使用 Router根据用户意图进入“论文分析 Agent”论文分析 Agent 内部再采用链式流程先提取结构再分析内容最后生成报告。所以 Agent 架构并不是六选一的模板。不同结构可以出现在系统的不同层次。七、总结Agent 架构设计的核心是找到复杂度真正出现的位置。工具越来越多时需要缩小单个 Agent 的职责任务步骤固定且较长时可以引入链式工作流业务具有明确分支时路由式结构更适合扩展。一个成熟的架构通常从简单结构开始。当单体 Agent 已经无法清晰表达业务边界时再引入工作流和多 Agent 编排。这样的演化路径更容易控制开发成本也更容易解释系统为什么采用当前架构。