凌晨一点，线上网络故障尚未闭环。

协作群消息不断刷屏：有人贴出告警截图，有人追问影响范围，有人转发历史工单，还有人提出“优先排查传输链路”。

事件调度智能体已经完成多轮运行。 它调用指标查询工具，获取小区维度性能数据；检索历史案例，匹配三条相似故障；随后输出分析结论，初步判定“问题大概率由高负荷、弱覆盖引发”。

但新的难题接踵而至： 它是否需要继续深挖传输链路？ 要不要直接创建现场处置工单？ 是否主动通知值班专家介入？ 假设指标接口超时，本次任务判定失败，还是自动重试？ 群内专家提出“这份结论存在偏差”，系统应当重新分析，还是等待人工确认？

问题根源不在于Prompt撰写得不够完善， 而是控制权边界没有被提前设计清楚。

倘若模型同时拥有事件理解、步骤规划、工具选择、生产操作、任务终止的全部权限，系统表面高度智能化，本质只是把一整套业务责任，塞进一个无法观测的黑盒循环。

这类架构在Demo阶段极易制造错觉：模型能够推理、调用工具、自主纠错。 落地生产之后，关注点不再是“模型能不能做完任务”，而是：系统能否对任务进行解释、暂停、恢复、审计与人工接管。

一、先别急于谈Agent：AI应用存在一条清晰的架构谱系

大模型、RAG、工具、Skill、记忆、工作流、多智能体，全部只是实现手段。 它们分别解决不同层级的问题：

• 模型：负责概率性理解、判断与文本生成

• RAG：补充外部知识库信息

• 工具：访问数据、执行外部动作

• Skill：封装稳定、专业化的能力单元

• 记忆：存储跨轮次、跨任务信息

• 工作流：约束标准化业务流程

• Agent：动态规划、自主选择工具

• 多智能体：拆分上下文、权责与访问权限

架构师设计系统，不能从“选用哪个开发框架”切入。 应当先回答六个核心问题：

1. 任务执行路径是否固定？

2. 流程推进中会不会持续产生新增信息？

3. 任务耗时是数秒，还是持续数日？

4. AI执行动作是否会影响真实生产系统？

5. 输出结果能否客观核验对错？

6. 异常出错后，谁具备接管能力？

答案不同，最优架构方案截然不同。

下面八种架构，并非由低级到高级的技术进化链条。更像是八种不同功能的交通工具：短途通勤无需重型卡车，长途货运也不能依靠单车。

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双向校验模式。

举例：代码单元测试是否通过、接口是否返回指定字段，属于容易验证； “网络故障根因是否确认”“处置方案是否合理”，很难依靠布尔值判断，需要人工参与评审。

五、可直接落地的架构选型参考表

这张表格不能直接替架构师做出最终决策，作用是避免被技术名词裹挟。 同一套业务系统，往往会融合多种架构：

事件接入 → 路由器识别事件类型 → 状态图管控任务全生命周期 → 编排者拆解多项分析子任务 → 多个Skill并行运算 → 确定性规则校验结果 → 人工审批确认 → 工具执行操作 → 闭环验证

系统不会只贴上单一架构标签。 架构设计的本质，是为每一项控制权找到最合适的归属。

六、结语：别让Agent替人类承担责任

AI系统上线生产之后，最重要的指标，从来不是模型推理轮次、系统内置Agent数量。 更值得持续追问的问题清单： 当前任务处于哪个状态？ 状态流转的触发原因是什么？ 模型获取了哪些证据做出判断？ 它为何选择调用这个工具？ 工具执行是否经过权限校验？ 失败场景会不会重复执行高危操作？ 哪些步骤允许自动运行？ 哪些步骤必须人工确认？ 判定任务完成的依据是什么？ 一旦判断失误，能否回退至最近检查点？

这些问题看上去没有“自主智能”吸引人，却决定系统能否稳定长期运行。

一套成熟的AI应用，不会放任模型无限自由发挥。 而是让模型在适合发挥创造力的领域拥有足够空间，在边界清晰的场景严格止步；故障发生时，系统支持暂停、回滚、移交人工处置。

因此AI架构设计，无关模型选型、框架选型、Agent数量多少。 本质是设计一套控制权分配方案： 模型负责概率性理解与推理； 程序保障稳定流程与安全边界； 工具承载受控外部动作； 状态系统负责长期记忆与故障恢复； 人类承担高风险决策与最终业务责任。

权责清晰划分，系统才能拥有工程秩序。 倘若所有职责全部塞进一套工具调用循环，系统即便足够“聪明”，没人能预判它下一步的行为。

我们最终追求的，从来不是最大化自主性。 而是和业务风险相匹配的自主性。 这才是AI架构设计真正要解决的核心命题。