# 智能体架构 系统由哪些部件构成、怎么连起来，"系统里有什么、各自负责什么"。 > 原文：[智能体架构](https://qmbim.com/articles/95d47279-0e2d-4b99-8ff6-ab3f12874d3e) > 作者：迈智数创 · 发布于 2026-10-10 > 转载请注明出处并保留原文链接。 --- ## 一、核心架构:五个组件 任何 Agent 系统,拆开都是这五块: ``` ┌──────────────────────┐ 用户/事件 ───►│ ① 编排循环 │◄─── 控制整个流程 │ (Agent Loop) │ └───┬──────────────┬───┘ │ │ ┌──────────▼───┐ ┌─────▼──────────┐ │ ② 模型(大脑) │ │ ③ 工具(手脚) │ │ 推理、决策 │ │ API/代码/浏览器 │ └──────────────┘ └─────┬──────────┘ ▲ │ ┌──────────┴───────┐ ┌───▼──────────┐ │ ④ 上下文与记忆 │ │ ⑤ 护栏与观测 │ │ 历史/检索/文件 │ │ 权限/审批/日志 │ └──────────────────┘ └──────────────┘ ``` | 组件 | 职责 | 对应前面哪一层 | |---|---|---| | **① 编排循环** | 调模型 → 解析 → 执行工具 → 回传,判断何时停 | 第 3 层的 30 行代码 | | **② 模型** | 理解、规划、决定调什么工具 | 第 1 层 | | **③ 工具** | 真正对外部世界产生作用 | 第 2、4 层 | | **④ 上下文与记忆** | 决定模型每一步"看到什么" | 第 5 层 | | **⑤ 护栏与观测** | 权限、审批、限额、日志、评测 | 第 7 层 | **关键认识**:模型只是五块之一。系统质量往往取决于③④⑤这些"模型之外"的部分。 --- ## 二、部署架构:Agent 跑在哪里 决定了它能做什么、有多安全。 | 形态 | 说明 | 例子 | |---|---|---| | **嵌入应用** | 作为后端的一个模块,处理请求后返回 | 客服机器人、应用内助手 | | **本地运行** | 跑在用户机器上,直接访问文件和终端 | 命令行编码助手 | | **沙箱/云端** | 每个任务一个隔离容器,可长时间运行 | 云端编码 Agent、数据分析 | | **事件驱动** | 由定时器、webhook、消息队列触发 | 自动分诊工单、定时巡检 | **沙箱**是目前很重要的一种:Agent 在隔离环境里执行代码和命令,出错也不影响真实系统,这是给 Agent 更大权限时的主要安全手段。 --- ## 三、工具接入架构 工具怎么接进来,有三种常见方式: ``` ① 内置函数 Agent 进程内直接调用,最简单 ② MCP 服务 工具是独立服务,通过标准协议接入,可跨语言、跨 Agent 复用 ③ 代码执行 给模型一个沙箱,让它自己写代码调用各种库 ``` | | 优点 | 缺点 | |---|---|---| | 内置函数 | 简单、快 | 与 Agent 耦合,难复用 | | MCP | 解耦、可复用、生态大 | 多一层通信,要管服务的权限 | | 代码执行 | 极灵活,工具数量不再受限 | 必须有沙箱,安全要求高 | --- ## 四、状态与持久化架构 Agent 如果要跑得久,必须想清楚状态存在哪: | 状态类型 | 存放位置 | 作用 | |---|---|---| | 对话历史 | 内存 / 数据库 | 当前任务的上下文 | | 任务进度 | 数据库 / 文件(如 todo、进度日志) | 断点续跑、跨会话交接 | | 长期记忆 | 向量库 / 文件 | 跨任务积累经验和偏好 | | 工作产物 | 文件系统 / 对象存储 | 中间结果、最终交付物 | **设计原则**:Agent 进程本身应该是**可丢弃的**,状态存在外部,进程崩了能从上次进度恢复。 --- ## 五、几种典型的整体架构 **1. 单 Agent + 工具(最基础)** ``` 用户 → [循环 + 模型] ⇄ 工具 ``` 适合大多数场景,先从这里开始。 **2. 主从多 Agent** ``` 用户 → 主 Agent ─┬─► 子 Agent A(独立上下文) ├─► 子 Agent B └─► 子 Agent C ◄── 各自只返回摘要 ──┘ ``` 适合广度任务、需要并行。 **3. 交接式(路由 + 专家)** ``` 用户 → 分诊 Agent ─► 专家 A / 专家 B / 专家 C ``` 适合客服、多业务线入口。 **4. 带人工审批的流水线** ``` 触发 → Agent 执行 → 【人工审批】→ 继续执行 → 交付 ``` 适合高风险操作(转账、发布、删数据)。 **5. 长程异步 Agent** ``` 任务队列 → 沙箱中的 Agent(持续运行,定期写进度)→ 完成后通知 ``` 适合耗时数小时的任务。 --- ## 六、架构层面的安全设计 安全问题要在架构里解决,不能只靠提示词: | 风险 | 架构手段 | |---|---| | 误操作造成破坏 | 沙箱隔离、只读默认、危险操作需审批 | | 提示词注入(网页/邮件里藏指令) | 把工具返回内容视为**不可信数据**;高权限和不可信输入隔离 | | 权限过大 | 每个工具、每个子 Agent 最小权限 | | 失控烧钱 | 步数、token、时间、费用上限 | | 出了问题查不清 | 完整日志:每步的输入、输出、工具调用 | 一个重要原则:**如果一个 Agent 同时能读不可信内容、能访问敏感数据、又能对外发送信息,风险最高**。设计时尽量不要让三者同时具备。 --- ## 七、从零设计架构的步骤 1. **定任务与验收标准**:什么算做完?怎么判断对错? 2. **列工具与权限**:最少需要哪些能力?各给多大权限? 3. **选最简结构**:单 Agent 循环起步 4. **设计状态存放**:进度、产物放哪,崩了能否恢复 5. **加护栏**:步数上限、审批点、沙箱 6. **加观测与评测**:日志 + 一组测试任务 7. **用数据决定是否变复杂**:瓶颈在哪,再针对性地加(多 Agent、检索、压缩等) --- ## 八、一句话总结 > **Agent 架构 = 一个循环 + 模型 + 工具 + 上下文管理 + 护栏观测。** > 模型提供智能,其余四块决定它**能不能用、敢不敢用、出错能不能兜住**。