凌晨一点线上网络故障尚未闭环。协作群消息不断刷屏有人贴出告警截图有人追问影响范围有人转发历史工单还有人提出“优先排查传输链路”。事件调度智能体已经完成多轮运行。 它调用指标查询工具获取小区维度性能数据检索历史案例匹配三条相似故障随后输出分析结论初步判定“问题大概率由高负荷、弱覆盖引发”。但新的难题接踵而至 它是否需要继续深挖传输链路 要不要直接创建现场处置工单 是否主动通知值班专家介入 假设指标接口超时本次任务判定失败还是自动重试 群内专家提出“这份结论存在偏差”系统应当重新分析还是等待人工确认问题根源不在于Prompt撰写得不够完善 而是控制权边界没有被提前设计清楚。倘若模型同时拥有事件理解、步骤规划、工具选择、生产操作、任务终止的全部权限系统表面高度智能化本质只是把一整套业务责任塞进一个无法观测的黑盒循环。这类架构在Demo阶段极易制造错觉模型能够推理、调用工具、自主纠错。 落地生产之后关注点不再是“模型能不能做完任务”而是系统能否对任务进行解释、暂停、恢复、审计与人工接管。一、先别急于谈AgentAI应用存在一条清晰的架构谱系大模型、RAG、工具、Skill、记忆、工作流、多智能体全部只是实现手段。 它们分别解决不同层级的问题模型负责概率性理解、判断与文本生成RAG补充外部知识库信息工具访问数据、执行外部动作Skill封装稳定、专业化的能力单元记忆存储跨轮次、跨任务信息工作流约束标准化业务流程Agent动态规划、自主选择工具多智能体拆分上下文、权责与访问权限架构师设计系统不能从“选用哪个开发框架”切入。 应当先回答六个核心问题任务执行路径是否固定流程推进中会不会持续产生新增信息任务耗时是数秒还是持续数日AI执行动作是否会影响真实生产系统输出结果能否客观核验对错异常出错后谁具备接管能力答案不同最优架构方案截然不同。下面八种架构并非由低级到高级的技术进化链条。更像是八种不同功能的交通工具短途通勤无需重型卡车长途货运也不能依靠单车。1. LLM函数型架构将模型视作概率函数这是最简单、落地最广泛却常常被低估的架构。业务输入 → 数据预处理 → 模型调用 → 结构化输出 → 业务系统继续执行示例代码逻辑result llm.extract_complaint_info(text)模型接收原始文本抽取投诉主体、时间、地点、故障类型、影响范围返回标准化结构后续流程完全交由业务代码推进。在这套架构里模型仅持有理解权。 无权决定后续流程、挑选工具更无法判定任务何时结束规划、路由、执行、终止全部由程序管控。适用场景文本分类、内容摘要、文案改写意图识别、参数抽取、信息提取文本审核、标签生成、报告段落撰写核心优势十分务实调用延迟可控成本易于测算调试链路简短清晰评测指标明确模型可快速替换对现有生产系统改造量小大量企业业务止步于此就足够稳定运行。 例如客服系统不必搭建重型客服Agent只需要从用户对话提取业务意图交由成熟规则引擎处理 工单系统无需模型自主规划流程仅依靠模型识别事件类型、提取关键字段接入现有派单、审批链路。一名成熟架构师首先要懂得拒绝盲目“智能体化”。2. Prompt Pipeline把单次复杂调用拆分为多阶段链路单次模型调用难以稳定输出结果时可以将任务拆解为多个固定执行阶段。原始输入 → 信息提取 → 内容分析 → 结果生成 → 格式校验Anthropic将该模式命名为Prompt Chaining。以网络优化报告生成为例链路划分如下提取事件事实 → 解读性能指标 → 推导故障诱因 → 输出处置方案 → 按照模板生成完整报告每个阶段均可独立调用大模型但执行顺序由程序预先定义。对比“单条超长Prompt包揽全部逻辑”最大改进不在于调用更多模型而是中间过程可观测。报告结论出错时可以精准定位问题环节 事实提取偏差、指标解读错误、诱因判断失误、方案生成异常或是最终格式化出错。 每个阶段支持独立评测、重试、替换组件。适用场景长文档分析、标准化报告生成合同解析、多级内容审核数据清洗与信息归纳流程稳定的业务分析Prompt Pipeline是至关重要的中间形态。 它比单次调用更擅长处理复杂任务又比自由Agent更容易管控。对于多数业务场景最优解不是放任模型自由规划而是把复杂流程拆成多个可测试、可管控的概率节点。3. 路由型架构先判定任务流向综合性AI产品往往承载多样化请求是多类业务的统一入口。 用户请求接入系统后首先判定请求类型用户请求 → 意图与复杂度判断 ├── 知识库问答链路 ├── 实时数据查询链路 ├── 内容生成链路 ├── 工具操作链路 └── 人工服务链路运营商场景举例指标释义类问题进入知识库问答实时数据查询触发数据工具道路质差分析调用专业分析Skill修改事件状态进入权限校验与操作流程无法清晰判定诉求直接转接人工。路由层可以由规则、小型模型或大模型承担。 核心不在于是否使用大模型路由而在于各链路边界清晰。一个普遍误区把所有请求统一交给全能Agent依靠Prompt约束模型不要越界。 初期开发速度很快但随着功能持续叠加Prompt会变得臃肿脆弱。新增任意工具都可能改变模型选择工具的概率新增业务规则极易和原有描述产生冲突。路由架构实现业务隔离 知识库问答拥有独立检索策略 实时查询配置专属权限、超时机制 生产操作强制接入审批流程 专业分析拥有固定输入输出规范。适用场景综合型AI门户、一站式业务助手多知识库平台、分级管控模型成本区分安全等级的任务分流但路由切忌过早拆分。面对相近场景可以先依靠统一提示词、策略变量控制复杂度再根据真实流量、评测数据、权限边界逐步拆分。 否则系统会堆砌十几个功能高度相似的Agent无人能说清差异化价值。4. 确定性工作流核心业务路径交由程序管控这类系统允许模型参与信息理解与内容生成但关键业务链路由代码、状态机、BPMN、DAG严格定义。事件触发 → 获取原始数据 → AI辅助分析 → 规则校验 → 人工确认 → 系统执行 → 结果验证模型可以嵌入链路部分节点但不能随意突破业务边界。 典型结构确定性节点 → AI节点 → 确定性校验 → AI节点 → 人工审批 → 确定性执行Google Cloud对工作流与智能体划分十分清晰工作流适配步骤明确、路径稳定、变动较少的任务智能体适配需要动态规划、自主决策的任务LangGraph也沿用类似理念工作流拥有预先定义的代码路径智能体能够动态决定执行流程与工具调用这条边界在企业级系统中至关重要。 例如修改生产系统配置模型可以理解用户意图、补全参数、解读风险影响但无权直接判定“是否执行”。权限校验、风险规则、审批流程、结果核验必须由确定性系统全权掌控。适用场景各类审批工单、事件处置流程合规流程、财务流程高风险生产操作步骤明确的故障处理强审计要求的业务企业系统很少需要一个无所不能的Agent。 真正需要的是一套具备语言理解能力的概率组件嵌入一套可审计、可恢复、支持回放的确定性业务流程。 二者并非替代关系而是分工协作。5. 单智能体循环由模型自主选择下一步动作最经典的Agent形态目标 → 感知环境信息 → 逻辑推理 → 选择工具 → 执行动作 → 获取返回结果 → 再次推理 → 直至任务完成模型持续接收工具返回信息自主决定后续动作。适用场景深度调研、开放式故障排查代码调试与修改、数据探索开放性问题综合分析跨多系统信息汇总采集单智能体循环优势是灵活性高开发门槛低。开发者不必预先写死全部路径仅提供目标、工具与约束模型就能自主探索解决方案。但风险同样突出循环轮次不可控极易无限迭代上下文持续膨胀推理成本上涨频繁出现重复尝试失败路径无法预判中间状态隐藏在对话上下文内难以保障多次执行结果一致一套简易ReAct循环可以完成“查询某个问题”这类短时任务不适合承载持续数日、跨团队推进的网络故障工单。长周期任务最大隐患不是模型不会思考而是系统无法定位执行进度。 模型上下文不是可靠的任务数据库聊天记录不等于状态机接口正常返回也不代表业务任务闭环。当任务支持暂停、等待人工反馈、持续数小时乃至数天运行时单纯循环架构必须升级为显式状态架构。6. 状态图与受约束智能体给动态决策铺设轨道状态图架构是单智能体循环与确定性工作流的融合方案。事件状态 → 当前执行节点 → AI判断 → 条件路由 → 工具执行 → 状态更新 → 流转至下一节点系统通过显式图结构定义全部业务阶段事件分析 ├── 信息不足发起信息补充请求 ├── 可自动研判执行分析Skill ├── 涉及高风险操作触发人工审批 ├── 需要现场处置创建外勤任务 └── 满足条件进入闭环验证阶段模型可以在单个节点内部自由推理但不能突破状态图划定的边界。 这就是带有约束的自主性。系统需要持久化记录完整信息当前任务所处阶段任务责任人已完成动作清单已收集证据正在等待的外部事件允许执行的后续动作失败重试策略人工介入断点闭环判定标准适用场景长时间运行任务、支持暂停恢复需要等待人类反馈故障后支持断点续跑具备清晰业务阶段划分需要完整审计轨迹前文提到的群内AI任务经理正属于这类系统。 它能够动态调用各类Skill但事件阶段、任务状态、责任人、闭环标准、提醒机制全部固化在显式状态图中。以网络故障任务为例定义完整状态流转已发现 → 信息收集中 → 分析中 → 等待人工确认 → 已派发现场任务 → 等待处置结果 → 验证中 → 已闭环群聊消息不再只是对话文本而是可能触发状态迁移的事件。 专家补充关键指标任务从「信息收集中」转入「分析中」专家确认研判结论任务从「等待人工确认」转为「已派发」现场人员上传处置结果任务进入「验证中」。倘若把所有信息全部寄存于上下文系统只能依靠模型“记住”完整流程 一旦抽象为独立状态系统模型只需要负责当前节点内的判断。 这是一道关键架构分水岭。7. 编排者与工作者模式动态拆分任务无需强行人格化单一目标能够拆解为多个独立子任务时可以采用Orchestrator Workers架构。用户目标 → 编排者拆解分析 ├── 工作者 A ├── 工作者 B ├── 工作者 C └── 编排者汇总结果复杂网络故障处理示例任务经理 ├── 覆盖分析 Skill ├── 负荷分析 Skill ├── 干扰分析 Skill ├── 告警关联 Skill └── 历史案例检索 Skill子任务支持串行执行也可以并行运行缩短整体耗时。适用场景子任务数量无法提前预估子任务相互独立可并行执行需要融合多专业视角汇总结论单一上下文承载不下全部信息容易被忽略的关键点工作者不一定是Agent。工作者可以是单次模型调用、标准化Skill、确定性工具、一套工作流、专业智能体。“编排者与工作者”描述的是运行协作关系不强制要求每个单元具备独立人格、长期记忆、自主循环。如果需求只是查询五类指标、汇总生成报告五个工作者完全可以使用稳定工具与分析链路。强行封装为五个Agent只会徒增通信成本、上下文传递开销与故障排查难度。编排模式的核心在于任务拆分与结果汇总而非堆砌Agent数量。8. 多智能体协作仅当权责真正隔离才值得拆分多智能体架构将差异化职责分配给不同独立智能体管理智能体 ├── 数据分析智能体 ├── 专业诊断智能体 ├── 风险审核智能体 ├── 执行智能体 └── 结果验证智能体微软总结主流多智能体协作模式顺序协作、并发协作、群聊交互、任务交接、动态编排。适用场景不同子任务需要隔离上下文各角色工具权限互不相同需要职责隔离、相互制衡跨多个专业领域协同处理单一上下文容量不足以承载全部信息示例任务经理Agent统筹推进全流程网络专家Agent负责技术故障研判质量审核Agent核查证据完备性执行Agent对接生产系统操作拆分价值不是让系统看起来更像组织架构而是实现权限、上下文、责任边界的物理隔离。同时多智能体存在明确成本代价通信开销上升上下文重复传递角色间信息损耗决策责任更容易模糊调试链路拉长Token成本显著增加错误容易跨角色传导常见反模式所有模块统一命名为Agent给每个智能体增加人设描述依靠自然语言互相通信。 这不属于架构设计仅仅是把函数调用替换成对话交互。 只有职责、上下文、访问权限确实需要隔离时引入多智能体才有意义。二、两类不可忽视的跨架构控制模式上面八种架构主要描述任务运行形态。 在企业级系统中还有两套横跨所有架构的控制范式人机协作、事件驱动常驻运行。1. 人机协作人不是异常兜底分支人机协作架构的核心不是让AI包揽全部工作而是AI与人协同完成业务闭环。AI分析 → 人工确认 → AI执行 → 人反馈结果 → AI更新状态 → AI持续跟进常见人工介入节点业务信息补充专业深度研判高风险权限审批处置方案选择异常场景接管最终闭环确认建立一个关键认知人工介入不该只是模型能力不足时的补救方案。 大量业务场景中人工确认本身就是流程固有的一环。例如 现场专家核实诊断结论 值班人员确认故障升级等级 业务负责人选定处置方案 管理者审批影响生产系统的高危操作。回到任务经理系统群聊早已超越普通交互界面同时承载多重职能协作空间 消息总线 人工介入入口 事件时间线 组织关系载体一条消息可能是补充信息、审批意见或是触发任务状态迁移的指令。 因此系统不能只完整存储聊天记录还需要识别消息承载的业务含义将关键动作写入任务事件流。否则时隔数日复盘群聊只剩杂乱的自然语言无法回答核心疑问 谁在何时确认了哪些结论哪条判断被专家推翻任务为何从分析阶段转入现场处置当前还缺失哪些信息下一步需要等待谁反馈2. 事件驱动与常驻智能体对话窗口之外任务持续运行传统聊天助手收到用户请求后启动执行返回结果随即终止。 任务经理属于另一类系统业务事件触发 → 智能体激活工作状态 → 持续监听事件与群消息 → 满足条件主动执行动作 → 等待外部反馈 → 恢复执行流程 → 直至任务闭环这意味着系统必须处理超长生命周期任务定时触发器、事件订阅、消息队列状态持久化、断点恢复幂等执行、超时管控、消息去重主动通知、异常自愈这类系统底层本质是事件驱动业务系统 概率决策层。模型负责判断 这条消息是否关联当前任务现有证据是否充足调用哪一套能力是否需要人工介入是否满足状态迁移条件。事件系统负责保障 消息不丢失任务状态可恢复重复消息不会引发重复操作定时任务稳定触发关键动作全程留痕执行逻辑不依赖临时会话上下文。这是常驻Agent与普通对话Agent最本质的分界线。 前者绝非简单增加一层循环而是需要完整的任务生命周期管理体系。三、架构本质是分配五类控制权AI架构选型的核心最终可以收敛为一句话决定哪些控制权交给模型哪些控制权留给程序哪些控制权必须留给人。一套业务流程可以拆解为五项核心控制权。控制权定义理解权解读用户诉求、事件信息与上下文规划权确定完整执行步骤清单路由权判定下一步调用何种能力执行权调用工具作用于真实业务系统终止权判断任务是否达成目标、允许结束不同架构本质是对五项权力做不同分配方案。LLM函数架构模型理解权程序规划、路由、执行、终止Prompt Pipeline模型各阶段局部理解与生成程序阶段顺序、输入输出约束、流程终止条件确定性工作流模型局部理解、局部判断程序全局规划、路由、执行边界、终止判定单智能体循环模型理解、规划、路由、部分终止判断程序工具执行、安全底线、资源上限管控状态图智能体模型节点内部理解与动态决策状态图业务阶段与可选流转路径程序权限校验、故障恢复、执行边界人高风险决策、最终责任承担高自主智能体模型理解、规划、路由、动作选择、终止判断程序基础安全边界、资源配额、系统级约束人极端异常介入交给模型的控制权越多系统环境适应能力越强。 与此同时执行可复现性、可预测性下降审计难度持续上升。这不代表高自主架构一定危险确定性流程永远最优。 核心权衡标准当前任务的风险等级是否值得牺牲可预测性换取灵活性四、不要只用“任务复杂”作为选型依据“任务复杂”是一个极度模糊的判断标准。 有些任务文本量大但执行路径固定优先选择工作流、Prompt Pipeline 有些任务步骤不多但处于开放环境持续涌入新信息反而更适合Agent。更加精准的架构选型需要综合六大维度评估1. 路径确定性执行步骤能否提前完整定义 路径越清晰优先选用工作流、Prompt Pipeline。2. 环境变化性执行过程会不会持续新增外部信息 变动越强越需要动态决策能力。3. 状态持续性任务耗时是秒级还是跨天数长期运行 周期越长越需要显式状态、检查点、事件驱动机制。4. 行动风险AI仅输出建议还是能够直接修改生产系统 风险越高越需要确定性管控与人机审批。5. 协作复杂度单人一问一答还是多角色、跨系统协同推进 协作链路越复杂越需要任务模型、角色划分、消息治理。6. 结果可验证性系统能否客观判定结果对错 越容易自动化核验越可以放开自主循环 难以客观判定的场景必须引入人工评审或是Evaluator-Optimizer双向校验模式。举例代码单元测试是否通过、接口是否返回指定字段属于容易验证 “网络故障根因是否确认”“处置方案是否合理”很难依靠布尔值判断需要人工参与评审。五、可直接落地的架构选型参考表业务场景推荐架构文本摘要、分类、信息抽取、标签生成LLM 函数固定模板报告、标准化文档生成Prompt Pipeline综合AI助手、统一业务入口路由型架构在成熟业务流程内嵌入AI能力确定性工作流短时开放式信息检索、工具探索任务单智能体循环长周期、有状态、支持断点续跑业务任务状态图智能体目标可拆分为多个独立子任务编排者与工作者多专业角色、权限隔离、相互制衡多智能体架构多人协同推进事件处置工单人机协作 事件驱动架构这张表格不能直接替架构师做出最终决策作用是避免被技术名词裹挟。 同一套业务系统往往会融合多种架构事件接入 → 路由器识别事件类型 → 状态图管控任务全生命周期 → 编排者拆解多项分析子任务 → 多个Skill并行运算 → 确定性规则校验结果 → 人工审批确认 → 工具执行操作 → 闭环验证系统不会只贴上单一架构标签。 架构设计的本质是为每一项控制权找到最合适的归属。六、结语别让Agent替人类承担责任AI系统上线生产之后最重要的指标从来不是模型推理轮次、系统内置Agent数量。 更值得持续追问的问题清单 当前任务处于哪个状态 状态流转的触发原因是什么 模型获取了哪些证据做出判断 它为何选择调用这个工具 工具执行是否经过权限校验 失败场景会不会重复执行高危操作 哪些步骤允许自动运行 哪些步骤必须人工确认 判定任务完成的依据是什么 一旦判断失误能否回退至最近检查点这些问题看上去没有“自主智能”吸引人却决定系统能否稳定长期运行。一套成熟的AI应用不会放任模型无限自由发挥。 而是让模型在适合发挥创造力的领域拥有足够空间在边界清晰的场景严格止步故障发生时系统支持暂停、回滚、移交人工处置。因此AI架构设计无关模型选型、框架选型、Agent数量多少。 本质是设计一套控制权分配方案 模型负责概率性理解与推理 程序保障稳定流程与安全边界 工具承载受控外部动作 状态系统负责长期记忆与故障恢复 人类承担高风险决策与最终业务责任。权责清晰划分系统才能拥有工程秩序。 倘若所有职责全部塞进一套工具调用循环系统即便足够“聪明”没人能预判它下一步的行为。我们最终追求的从来不是最大化自主性。 而是和业务风险相匹配的自主性。 这才是AI架构设计真正要解决的核心命题。 AI 架构设计的本质：决定哪些控制权交给模型
凌晨一点线上网络故障尚未闭环。协作群消息不断刷屏有人贴出告警截图有人追问影响范围有人转发历史工单还有人提出“优先排查传输链路”。事件调度智能体已经完成多轮运行。 它调用指标查询工具获取小区维度性能数据检索历史案例匹配三条相似故障随后输出分析结论初步判定“问题大概率由高负荷、弱覆盖引发”。但新的难题接踵而至 它是否需要继续深挖传输链路 要不要直接创建现场处置工单 是否主动通知值班专家介入 假设指标接口超时本次任务判定失败还是自动重试 群内专家提出“这份结论存在偏差”系统应当重新分析还是等待人工确认问题根源不在于Prompt撰写得不够完善 而是控制权边界没有被提前设计清楚。倘若模型同时拥有事件理解、步骤规划、工具选择、生产操作、任务终止的全部权限系统表面高度智能化本质只是把一整套业务责任塞进一个无法观测的黑盒循环。这类架构在Demo阶段极易制造错觉模型能够推理、调用工具、自主纠错。 落地生产之后关注点不再是“模型能不能做完任务”而是系统能否对任务进行解释、暂停、恢复、审计与人工接管。一、先别急于谈AgentAI应用存在一条清晰的架构谱系大模型、RAG、工具、Skill、记忆、工作流、多智能体全部只是实现手段。 它们分别解决不同层级的问题模型负责概率性理解、判断与文本生成RAG补充外部知识库信息工具访问数据、执行外部动作Skill封装稳定、专业化的能力单元记忆存储跨轮次、跨任务信息工作流约束标准化业务流程Agent动态规划、自主选择工具多智能体拆分上下文、权责与访问权限架构师设计系统不能从“选用哪个开发框架”切入。 应当先回答六个核心问题任务执行路径是否固定流程推进中会不会持续产生新增信息任务耗时是数秒还是持续数日AI执行动作是否会影响真实生产系统输出结果能否客观核验对错异常出错后谁具备接管能力答案不同最优架构方案截然不同。下面八种架构并非由低级到高级的技术进化链条。更像是八种不同功能的交通工具短途通勤无需重型卡车长途货运也不能依靠单车。1. LLM函数型架构将模型视作概率函数这是最简单、落地最广泛却常常被低估的架构。业务输入 → 数据预处理 → 模型调用 → 结构化输出 → 业务系统继续执行示例代码逻辑result llm.extract_complaint_info(text)模型接收原始文本抽取投诉主体、时间、地点、故障类型、影响范围返回标准化结构后续流程完全交由业务代码推进。在这套架构里模型仅持有理解权。 无权决定后续流程、挑选工具更无法判定任务何时结束规划、路由、执行、终止全部由程序管控。适用场景文本分类、内容摘要、文案改写意图识别、参数抽取、信息提取文本审核、标签生成、报告段落撰写核心优势十分务实调用延迟可控成本易于测算调试链路简短清晰评测指标明确模型可快速替换对现有生产系统改造量小大量企业业务止步于此就足够稳定运行。 例如客服系统不必搭建重型客服Agent只需要从用户对话提取业务意图交由成熟规则引擎处理 工单系统无需模型自主规划流程仅依靠模型识别事件类型、提取关键字段接入现有派单、审批链路。一名成熟架构师首先要懂得拒绝盲目“智能体化”。2. Prompt Pipeline把单次复杂调用拆分为多阶段链路单次模型调用难以稳定输出结果时可以将任务拆解为多个固定执行阶段。原始输入 → 信息提取 → 内容分析 → 结果生成 → 格式校验Anthropic将该模式命名为Prompt Chaining。以网络优化报告生成为例链路划分如下提取事件事实 → 解读性能指标 → 推导故障诱因 → 输出处置方案 → 按照模板生成完整报告每个阶段均可独立调用大模型但执行顺序由程序预先定义。对比“单条超长Prompt包揽全部逻辑”最大改进不在于调用更多模型而是中间过程可观测。报告结论出错时可以精准定位问题环节 事实提取偏差、指标解读错误、诱因判断失误、方案生成异常或是最终格式化出错。 每个阶段支持独立评测、重试、替换组件。适用场景长文档分析、标准化报告生成合同解析、多级内容审核数据清洗与信息归纳流程稳定的业务分析Prompt Pipeline是至关重要的中间形态。 它比单次调用更擅长处理复杂任务又比自由Agent更容易管控。对于多数业务场景最优解不是放任模型自由规划而是把复杂流程拆成多个可测试、可管控的概率节点。3. 路由型架构先判定任务流向综合性AI产品往往承载多样化请求是多类业务的统一入口。 用户请求接入系统后首先判定请求类型用户请求 → 意图与复杂度判断 ├── 知识库问答链路 ├── 实时数据查询链路 ├── 内容生成链路 ├── 工具操作链路 └── 人工服务链路运营商场景举例指标释义类问题进入知识库问答实时数据查询触发数据工具道路质差分析调用专业分析Skill修改事件状态进入权限校验与操作流程无法清晰判定诉求直接转接人工。路由层可以由规则、小型模型或大模型承担。 核心不在于是否使用大模型路由而在于各链路边界清晰。一个普遍误区把所有请求统一交给全能Agent依靠Prompt约束模型不要越界。 初期开发速度很快但随着功能持续叠加Prompt会变得臃肿脆弱。新增任意工具都可能改变模型选择工具的概率新增业务规则极易和原有描述产生冲突。路由架构实现业务隔离 知识库问答拥有独立检索策略 实时查询配置专属权限、超时机制 生产操作强制接入审批流程 专业分析拥有固定输入输出规范。适用场景综合型AI门户、一站式业务助手多知识库平台、分级管控模型成本区分安全等级的任务分流但路由切忌过早拆分。面对相近场景可以先依靠统一提示词、策略变量控制复杂度再根据真实流量、评测数据、权限边界逐步拆分。 否则系统会堆砌十几个功能高度相似的Agent无人能说清差异化价值。4. 确定性工作流核心业务路径交由程序管控这类系统允许模型参与信息理解与内容生成但关键业务链路由代码、状态机、BPMN、DAG严格定义。事件触发 → 获取原始数据 → AI辅助分析 → 规则校验 → 人工确认 → 系统执行 → 结果验证模型可以嵌入链路部分节点但不能随意突破业务边界。 典型结构确定性节点 → AI节点 → 确定性校验 → AI节点 → 人工审批 → 确定性执行Google Cloud对工作流与智能体划分十分清晰工作流适配步骤明确、路径稳定、变动较少的任务智能体适配需要动态规划、自主决策的任务LangGraph也沿用类似理念工作流拥有预先定义的代码路径智能体能够动态决定执行流程与工具调用这条边界在企业级系统中至关重要。 例如修改生产系统配置模型可以理解用户意图、补全参数、解读风险影响但无权直接判定“是否执行”。权限校验、风险规则、审批流程、结果核验必须由确定性系统全权掌控。适用场景各类审批工单、事件处置流程合规流程、财务流程高风险生产操作步骤明确的故障处理强审计要求的业务企业系统很少需要一个无所不能的Agent。 真正需要的是一套具备语言理解能力的概率组件嵌入一套可审计、可恢复、支持回放的确定性业务流程。 二者并非替代关系而是分工协作。5. 单智能体循环由模型自主选择下一步动作最经典的Agent形态目标 → 感知环境信息 → 逻辑推理 → 选择工具 → 执行动作 → 获取返回结果 → 再次推理 → 直至任务完成模型持续接收工具返回信息自主决定后续动作。适用场景深度调研、开放式故障排查代码调试与修改、数据探索开放性问题综合分析跨多系统信息汇总采集单智能体循环优势是灵活性高开发门槛低。开发者不必预先写死全部路径仅提供目标、工具与约束模型就能自主探索解决方案。但风险同样突出循环轮次不可控极易无限迭代上下文持续膨胀推理成本上涨频繁出现重复尝试失败路径无法预判中间状态隐藏在对话上下文内难以保障多次执行结果一致一套简易ReAct循环可以完成“查询某个问题”这类短时任务不适合承载持续数日、跨团队推进的网络故障工单。长周期任务最大隐患不是模型不会思考而是系统无法定位执行进度。 模型上下文不是可靠的任务数据库聊天记录不等于状态机接口正常返回也不代表业务任务闭环。当任务支持暂停、等待人工反馈、持续数小时乃至数天运行时单纯循环架构必须升级为显式状态架构。6. 状态图与受约束智能体给动态决策铺设轨道状态图架构是单智能体循环与确定性工作流的融合方案。事件状态 → 当前执行节点 → AI判断 → 条件路由 → 工具执行 → 状态更新 → 流转至下一节点系统通过显式图结构定义全部业务阶段事件分析 ├── 信息不足发起信息补充请求 ├── 可自动研判执行分析Skill ├── 涉及高风险操作触发人工审批 ├── 需要现场处置创建外勤任务 └── 满足条件进入闭环验证阶段模型可以在单个节点内部自由推理但不能突破状态图划定的边界。 这就是带有约束的自主性。系统需要持久化记录完整信息当前任务所处阶段任务责任人已完成动作清单已收集证据正在等待的外部事件允许执行的后续动作失败重试策略人工介入断点闭环判定标准适用场景长时间运行任务、支持暂停恢复需要等待人类反馈故障后支持断点续跑具备清晰业务阶段划分需要完整审计轨迹前文提到的群内AI任务经理正属于这类系统。 它能够动态调用各类Skill但事件阶段、任务状态、责任人、闭环标准、提醒机制全部固化在显式状态图中。以网络故障任务为例定义完整状态流转已发现 → 信息收集中 → 分析中 → 等待人工确认 → 已派发现场任务 → 等待处置结果 → 验证中 → 已闭环群聊消息不再只是对话文本而是可能触发状态迁移的事件。 专家补充关键指标任务从「信息收集中」转入「分析中」专家确认研判结论任务从「等待人工确认」转为「已派发」现场人员上传处置结果任务进入「验证中」。倘若把所有信息全部寄存于上下文系统只能依靠模型“记住”完整流程 一旦抽象为独立状态系统模型只需要负责当前节点内的判断。 这是一道关键架构分水岭。7. 编排者与工作者模式动态拆分任务无需强行人格化单一目标能够拆解为多个独立子任务时可以采用Orchestrator Workers架构。用户目标 → 编排者拆解分析 ├── 工作者 A ├── 工作者 B ├── 工作者 C └── 编排者汇总结果复杂网络故障处理示例任务经理 ├── 覆盖分析 Skill ├── 负荷分析 Skill ├── 干扰分析 Skill ├── 告警关联 Skill └── 历史案例检索 Skill子任务支持串行执行也可以并行运行缩短整体耗时。适用场景子任务数量无法提前预估子任务相互独立可并行执行需要融合多专业视角汇总结论单一上下文承载不下全部信息容易被忽略的关键点工作者不一定是Agent。工作者可以是单次模型调用、标准化Skill、确定性工具、一套工作流、专业智能体。“编排者与工作者”描述的是运行协作关系不强制要求每个单元具备独立人格、长期记忆、自主循环。如果需求只是查询五类指标、汇总生成报告五个工作者完全可以使用稳定工具与分析链路。强行封装为五个Agent只会徒增通信成本、上下文传递开销与故障排查难度。编排模式的核心在于任务拆分与结果汇总而非堆砌Agent数量。8. 多智能体协作仅当权责真正隔离才值得拆分多智能体架构将差异化职责分配给不同独立智能体管理智能体 ├── 数据分析智能体 ├── 专业诊断智能体 ├── 风险审核智能体 ├── 执行智能体 └── 结果验证智能体微软总结主流多智能体协作模式顺序协作、并发协作、群聊交互、任务交接、动态编排。适用场景不同子任务需要隔离上下文各角色工具权限互不相同需要职责隔离、相互制衡跨多个专业领域协同处理单一上下文容量不足以承载全部信息示例任务经理Agent统筹推进全流程网络专家Agent负责技术故障研判质量审核Agent核查证据完备性执行Agent对接生产系统操作拆分价值不是让系统看起来更像组织架构而是实现权限、上下文、责任边界的物理隔离。同时多智能体存在明确成本代价通信开销上升上下文重复传递角色间信息损耗决策责任更容易模糊调试链路拉长Token成本显著增加错误容易跨角色传导常见反模式所有模块统一命名为Agent给每个智能体增加人设描述依靠自然语言互相通信。 这不属于架构设计仅仅是把函数调用替换成对话交互。 只有职责、上下文、访问权限确实需要隔离时引入多智能体才有意义。二、两类不可忽视的跨架构控制模式上面八种架构主要描述任务运行形态。 在企业级系统中还有两套横跨所有架构的控制范式人机协作、事件驱动常驻运行。1. 人机协作人不是异常兜底分支人机协作架构的核心不是让AI包揽全部工作而是AI与人协同完成业务闭环。AI分析 → 人工确认 → AI执行 → 人反馈结果 → AI更新状态 → AI持续跟进常见人工介入节点业务信息补充专业深度研判高风险权限审批处置方案选择异常场景接管最终闭环确认建立一个关键认知人工介入不该只是模型能力不足时的补救方案。 大量业务场景中人工确认本身就是流程固有的一环。例如 现场专家核实诊断结论 值班人员确认故障升级等级 业务负责人选定处置方案 管理者审批影响生产系统的高危操作。回到任务经理系统群聊早已超越普通交互界面同时承载多重职能协作空间 消息总线 人工介入入口 事件时间线 组织关系载体一条消息可能是补充信息、审批意见或是触发任务状态迁移的指令。 因此系统不能只完整存储聊天记录还需要识别消息承载的业务含义将关键动作写入任务事件流。否则时隔数日复盘群聊只剩杂乱的自然语言无法回答核心疑问 谁在何时确认了哪些结论哪条判断被专家推翻任务为何从分析阶段转入现场处置当前还缺失哪些信息下一步需要等待谁反馈2. 事件驱动与常驻智能体对话窗口之外任务持续运行传统聊天助手收到用户请求后启动执行返回结果随即终止。 任务经理属于另一类系统业务事件触发 → 智能体激活工作状态 → 持续监听事件与群消息 → 满足条件主动执行动作 → 等待外部反馈 → 恢复执行流程 → 直至任务闭环这意味着系统必须处理超长生命周期任务定时触发器、事件订阅、消息队列状态持久化、断点恢复幂等执行、超时管控、消息去重主动通知、异常自愈这类系统底层本质是事件驱动业务系统 概率决策层。模型负责判断 这条消息是否关联当前任务现有证据是否充足调用哪一套能力是否需要人工介入是否满足状态迁移条件。事件系统负责保障 消息不丢失任务状态可恢复重复消息不会引发重复操作定时任务稳定触发关键动作全程留痕执行逻辑不依赖临时会话上下文。这是常驻Agent与普通对话Agent最本质的分界线。 前者绝非简单增加一层循环而是需要完整的任务生命周期管理体系。三、架构本质是分配五类控制权AI架构选型的核心最终可以收敛为一句话决定哪些控制权交给模型哪些控制权留给程序哪些控制权必须留给人。一套业务流程可以拆解为五项核心控制权。控制权定义理解权解读用户诉求、事件信息与上下文规划权确定完整执行步骤清单路由权判定下一步调用何种能力执行权调用工具作用于真实业务系统终止权判断任务是否达成目标、允许结束不同架构本质是对五项权力做不同分配方案。LLM函数架构模型理解权程序规划、路由、执行、终止Prompt Pipeline模型各阶段局部理解与生成程序阶段顺序、输入输出约束、流程终止条件确定性工作流模型局部理解、局部判断程序全局规划、路由、执行边界、终止判定单智能体循环模型理解、规划、路由、部分终止判断程序工具执行、安全底线、资源上限管控状态图智能体模型节点内部理解与动态决策状态图业务阶段与可选流转路径程序权限校验、故障恢复、执行边界人高风险决策、最终责任承担高自主智能体模型理解、规划、路由、动作选择、终止判断程序基础安全边界、资源配额、系统级约束人极端异常介入交给模型的控制权越多系统环境适应能力越强。 与此同时执行可复现性、可预测性下降审计难度持续上升。这不代表高自主架构一定危险确定性流程永远最优。 核心权衡标准当前任务的风险等级是否值得牺牲可预测性换取灵活性四、不要只用“任务复杂”作为选型依据“任务复杂”是一个极度模糊的判断标准。 有些任务文本量大但执行路径固定优先选择工作流、Prompt Pipeline 有些任务步骤不多但处于开放环境持续涌入新信息反而更适合Agent。更加精准的架构选型需要综合六大维度评估1. 路径确定性执行步骤能否提前完整定义 路径越清晰优先选用工作流、Prompt Pipeline。2. 环境变化性执行过程会不会持续新增外部信息 变动越强越需要动态决策能力。3. 状态持续性任务耗时是秒级还是跨天数长期运行 周期越长越需要显式状态、检查点、事件驱动机制。4. 行动风险AI仅输出建议还是能够直接修改生产系统 风险越高越需要确定性管控与人机审批。5. 协作复杂度单人一问一答还是多角色、跨系统协同推进 协作链路越复杂越需要任务模型、角色划分、消息治理。6. 结果可验证性系统能否客观判定结果对错 越容易自动化核验越可以放开自主循环 难以客观判定的场景必须引入人工评审或是Evaluator-Optimizer双向校验模式。举例代码单元测试是否通过、接口是否返回指定字段属于容易验证 “网络故障根因是否确认”“处置方案是否合理”很难依靠布尔值判断需要人工参与评审。五、可直接落地的架构选型参考表业务场景推荐架构文本摘要、分类、信息抽取、标签生成LLM 函数固定模板报告、标准化文档生成Prompt Pipeline综合AI助手、统一业务入口路由型架构在成熟业务流程内嵌入AI能力确定性工作流短时开放式信息检索、工具探索任务单智能体循环长周期、有状态、支持断点续跑业务任务状态图智能体目标可拆分为多个独立子任务编排者与工作者多专业角色、权限隔离、相互制衡多智能体架构多人协同推进事件处置工单人机协作 事件驱动架构这张表格不能直接替架构师做出最终决策作用是避免被技术名词裹挟。 同一套业务系统往往会融合多种架构事件接入 → 路由器识别事件类型 → 状态图管控任务全生命周期 → 编排者拆解多项分析子任务 → 多个Skill并行运算 → 确定性规则校验结果 → 人工审批确认 → 工具执行操作 → 闭环验证系统不会只贴上单一架构标签。 架构设计的本质是为每一项控制权找到最合适的归属。六、结语别让Agent替人类承担责任AI系统上线生产之后最重要的指标从来不是模型推理轮次、系统内置Agent数量。 更值得持续追问的问题清单 当前任务处于哪个状态 状态流转的触发原因是什么 模型获取了哪些证据做出判断 它为何选择调用这个工具 工具执行是否经过权限校验 失败场景会不会重复执行高危操作 哪些步骤允许自动运行 哪些步骤必须人工确认 判定任务完成的依据是什么 一旦判断失误能否回退至最近检查点这些问题看上去没有“自主智能”吸引人却决定系统能否稳定长期运行。一套成熟的AI应用不会放任模型无限自由发挥。 而是让模型在适合发挥创造力的领域拥有足够空间在边界清晰的场景严格止步故障发生时系统支持暂停、回滚、移交人工处置。因此AI架构设计无关模型选型、框架选型、Agent数量多少。 本质是设计一套控制权分配方案 模型负责概率性理解与推理 程序保障稳定流程与安全边界 工具承载受控外部动作 状态系统负责长期记忆与故障恢复 人类承担高风险决策与最终业务责任。权责清晰划分系统才能拥有工程秩序。 倘若所有职责全部塞进一套工具调用循环系统即便足够“聪明”没人能预判它下一步的行为。我们最终追求的从来不是最大化自主性。 而是和业务风险相匹配的自主性。 这才是AI架构设计真正要解决的核心命题。