智能体架构
系统由哪些部件构成、怎么连起来，"系统里有什么、各自负责什么"。
一、核心架构:五个组件
任何 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 同时能读不可信内容、能访问敏感数据、又能对外发送信息,风险最高。设计时尽量不要让三者同时具备。
七、从零设计架构的步骤
- 定任务与验收标准:什么算做完?怎么判断对错?
- 列工具与权限:最少需要哪些能力?各给多大权限?
- 选最简结构:单 Agent 循环起步
- 设计状态存放:进度、产物放哪,崩了能否恢复
- 加护栏:步数上限、审批点、沙箱
- 加观测与评测:日志 + 一组测试任务
- 用数据决定是否变复杂:瓶颈在哪,再针对性地加(多 Agent、检索、压缩等)
八、一句话总结
Agent 架构 = 一个循环 + 模型 + 工具 + 上下文管理 + 护栏观测。 模型提供智能,其余四块决定它能不能用、敢不敢用、出错能不能兜住。