聊一下最近在做的一个 AI Agent 项目的架构演进。从最初的单模型调用，到现在的多智能体协同，踩了不少坑，分享一下经验。
一、为什么要做 Agent 架构
最开始我们就是简单的：
response = llm.chat(prompt)
用户输入，大模型输出，完事。
但很快就遇到问题了：
- 大模型不能调用工具： 它只能说，不能真的去查数据库、调 API
- 上下文窗口有限： 复杂任务拆不开
- 多轮对话状态管理混乱： 聊到后面就忘了前面说啥
这时候就需要 Agent 架构了。
二、第一阶段：单 Agent + Function Calling
最早的架构很简单：
用户请求
↓
Supervisor Agent（大模型）
├── 调用工具1：查数据库
├── 调用工具2：发请求
└── 调用工具3：写文件
↓
返回结果
核心就是 Function Calling：
- 大模型决定要调用哪个工具
- 我们执行这个工具
- 把结果喂回给大模型
- 大模型继续推理
这个阶段的代码大概长这样：
tools = [ {"name": "search_db", "description": "查询数据库", "parameters": {...}}, {"name": "call_api", "description": "调用外部API", "parameters": {...}},]
def run_agent(query):
messages = [{"role": "user", "content": query}]
while True:
response = llm.chat(messages, tools=tools)
if not response.tool_calls:
return response.content
for tool_call in response.tool_calls:
result = execute_tool(tool_call)
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": result
})
这个阶段的问题：
- 一个 Agent 干所有事，上下文越来越长
- 任务复杂一点就 hold 不住
- 成本高，每次都调用最大的模型
三、第二阶段：多 Agent 分工
后来任务复杂了，单 Agent 搞不定，就拆成了多个：
┌─────────────┐
│ Orchestrator │ （总调度）
└──────┬──────┘
│
┌──────────────┼──────────────┐
↓ ↓ ↓
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Search │ │ Writer │ │ Executor│
│ Agent │ │ Agent │ │ Agent │
└─────────┘ └─────────┘ └─────────┘
每个 Agent 负责一件事：
- Search Agent： 专门负责信息检索
- Writer Agent： 专门负责内容生成
- Executor Agent： 专门负责执行操作
Orchestrator（总调度）负责：
- 理解用户要干什么
- 把大任务拆成小任务
- 分发给对应的 Agent
- 收集结果，整合输出
这个阶段的好处：
- 每个 Agent 上下文都很短，不会超长
- 可以给不同 Agent 配不同大小的模型（省钱）
- 每个 Agent 职责单一，容易调试
四、第三阶段：工具层标准化
Agent 多了之后，发现一个问题：每个 Agent 都要自己写工具调用逻辑，重复造轮子。
于是我们抽了一层工具层：
┌─────────────────────────────────┐
│ Agent 层 │
├─────────────────────────────────┤
│ 工具抽象层（MCP风格） │
├─────────────────────────────────┤
│ 数据库 │ API │ 文件 │ RPA ... │
└─────────────────────────────────┘
所有工具都统一接口：
class BaseTool:
name: str
description: str
parameters: dict
def run(self, **kwargs) -> str:
pass
这样：
- 新工具只要实现这个接口就能被所有 Agent 调用
- 不用每个 Agent 写一遍工具调用代码
- 工具可以复用
五、踩过的坑
坑 1：不要过度设计
最开始我们搞了很复杂的多 Agent 架构，结果发现 80% 的场景单 Agent 就够了。
经验： 先从最简单的开始，不够了再拆。
坑 2：上下文管理很重要
Agent 跑着跑着就把上下文撑爆了，成本暴涨，效果还变差。
解决方法：
- 每完成一个子任务就做摘要
- 只保留必要的上下文
- 用向量数据库存历史信息，要用的时候再检索
坑 3：错误处理
Agent 很容易 "走火入魔"—— 在错误的方向上越跑越远。
解决方法：
- 加最大步数限制
- 加人工检查点（关键节点让人确认）
- 加回退机制
六、总结
AI Agent 的架构演进，本质上就是：
从 "一个大模型干所有事"，到 "多个专业模型分工协作"。
这个趋势和软件架构的演进是一样的：
- 从单体应用 → 微服务
- 从单进程 → 分布式系统
未来的 Agent 系统一定是：
- 多个专业小模型协同
- 有总调度做任务规划
- 有标准化的工具层
- 有完善的错误处理和监控
