# 别再把所有 AI 自动化都叫 Agent：企业最常见的六种架构

企业讨论 AI Agent 时，最容易犯的错误不是模型选错，而是把完全不同的系统都塞进同一个概念里。

一个回答员工问题的知识助手、一条收到邮件后自动处理材料的工作流、一个能够自行规划调查路径的系统，以及一组互相审查结果的 Agent，解决的问题不同，需要的权限、监督方式和治理边界也不同。

CIO.com 的文章《The 6 kinds of AI agent architectures》基于作者接触的企业项目，将常见方案归纳为六种架构。这个分类不是行业标准，但它提供了一个实用的起点：**先识别业务问题的形状，再讨论模型和工具。**

## 1. 对话式助手：让人主动来问

对话式助手是最容易被识别的一类。员工或客户提出问题，系统基于持续更新的信息源回答，并可能具备用户级记忆、引用和工具调用能力。

文章举出的场景包括律所内部知识助手，以及面向财富管理客户的自助问答系统。它们的核心价值不是“自主完成复杂任务”，而是把分散在文档和资深员工经验中的知识转化为可查询的服务。

这类系统的关键边界通常是：

- 回答依据是否可追溯；
- 用户之间的记忆和权限是否隔离；
- 哪些操作只能建议，哪些操作可以代用户执行；
- 信息源过期时如何发现和纠正。

## 2. 触发式工作流：事件一发生，流程就启动

触发式工作流由外部事件驱动，例如收到邮件、创建工单或上传文件。后续步骤通常是预先设计好的，只在局部使用模型进行分类、提取、判断或生成。

文章中的商业保险案例是：经纪人邮件到达后，系统按险种分类、解析附件、提取风险字段、写入保单系统，再生成确认函草稿。私募股权案例则从收到 CIM 开始，自动提取财务摘要、对照投资标准筛选，并生成初步备忘录。

它的优势在于不要求用户改变习惯，而且容易接入已有的审计和变更控制流程。很多所谓的 Agent 项目，其实更适合采用这种“确定性流程为主、模型判断为辅”的架构。

## 3. 自主 Agent 与子 Agent：路径未知，由系统自行规划

当任务目标明确，但完成路径无法预先写死时，可以考虑自主 Agent。主 Agent 根据任务决定下一步行动，并按需调用不同的子 Agent、数据库、日志系统或外部信息源。

文章提到两个场景：咨询公司用它完成早期客户研究与项目范围界定；科技公司在生产告警后，让 Agent 形成假设、查询监控和日志、追踪部署记录，并整理根因调查摘要。

这种架构能力更强，风险也更集中。文章没有深入讨论工具权限、错误动作、幻觉和成本失控等问题，因此不能只因为任务“复杂”就选择自主模式。规划自由度越高，越需要明确工具白名单、停止条件、预算、审计记录和人工接管机制。

## 4. 多 Agent 团队：让不同角色协作和互相审查

多 Agent 架构把任务拆给多个专职角色，例如研究者与写作者、规划者与执行者，或提议者与批评者。

文章尤其强调“提议者—批评者”循环：一个模型生成结果，另一个模型按照显式标准进行评估；必要时还可以使用不同供应商的模型，降低单一模型重复自身偏差的概率。

文章中的银行合规审查和制药文献摘要都采用了类似思路。它适合高风险、需要审计或质量复核的输出，但多一个 Agent 不等于自然多一层保障。真正有价值的是明确的职责分离、评价标准和失败路由，而不是角色数量本身。

## 5. 人在回路 Agent：机器处理大部分，人保留关键判断

人在回路（Human-in-the-Loop，HITL）架构让 Agent 完成资料收集、字段整理和草稿生成，再在高风险节点交给人类审批。

医疗系统可以让 Agent 组装临床证据并起草先期授权信，由护士案例管理员审核；物业管理公司则可以让 Agent 解析维修请求、匹配供应商并生成工单，再由员工在 Slack 中批准发送。

HITL 的重点不是在流程末尾机械地加一个“确认”按钮，而是识别真正需要人类判断的位置。审批过多，自动化价值会被抵消；审批过少，又可能把责任交给无法承担责任的模型。

## 6. 定时 Agent：按运营节奏自动交付结果

定时 Agent 按固定计划运行，例如每周生成投资组合新闻摘要，或每天夜间汇总工厂质控报告。

它与触发式工作流类似，区别在于启动条件不是某个即时事件，而是时间表或批次。输出通常有固定格式，并直接进入晨会、周会或月度汇报等既有节奏。

这类架构看起来不够“自主”，却往往更容易落地：输入范围清楚、运行频率固定、结果可回看，也更方便建立基线和异常监控。

## 如何选择：先回答三个问题

文章最后给出的判断方式，可以压缩成三个问题：

1. **任务是由事件触发，还是按计划运行？**  
   前者优先考虑触发式工作流，后者优先考虑定时 Agent。

2. **执行路径已经知道，还是需要系统自行发现？**  
   路径明确时，不必为了“更智能”而引入自主规划；路径开放、需要多源调查时，才考虑自主 Agent 和受限子 Agent。

3. **人类判断必须保留在哪些节点？**  
   合规、医疗、资金、外部发布等高风险决策，应明确人工审批点；需要独立质量审查时，可以考虑多 Agent 的提议者—批评者结构。

知识问答类需求则更适合对话式助手，但应把引用、记忆、权限和工具调用边界设计清楚。

## 真正重要的不是“Agent 数量”

这组六类架构最有价值的地方，不是提供了一个新的技术分类，而是提醒团队避免从模型能力出发倒推需求。

在启动试点前，至少应写清楚：

- 触发条件与结束条件；
- 模型和工具分别负责什么；
- 可以访问哪些数据、执行哪些动作；
- 哪些节点需要人工批准；
- 失败后如何回退或转人工；
- 用什么指标判断速度、质量、成本和风险是否改善。

需要保持克制的是，原文中的企业案例主要来自作者的顾问经验，缺少可独立核验的对照数据，也没有系统讨论失败模式、成本结构、安全要求和迁移代价。因此，这六类架构适合作为**讨论和选型的地图**，不应被当成已经验证的通用标准。

企业真正需要的不是“最像 Agent”的方案，而是与任务路径、风险等级和运营节奏匹配的方案。有时答案是自主 Agent，有时只是一个触发明确、可以审计的工作流——后者并不落后，反而可能更接近可维护的生产系统。

---

**来源：** CIO.com，*The 6 kinds of AI agent architectures*  
https://www.cio.com/article/4198444/the-6-kinds-of-ai-agent-architectures.html

**说明：** 本文依据原文及其案例整理。原文引用的 Deloitte、Databricks 和 Moody's 数据未附完整调查方法，相关数字应视为背景信息，而非通用效果基准。