架构设计

团队花三个月,搭了一套五个角色的多 Agent 编排:Planner、Researcher、Coder、Reviewer、Reporter,各司其职,消息总线串起来,架构图画得很漂亮。 上线后效果不理想——慢,贵,而且一出错就没人知道是哪一环错的。 后来有人把其中一个单 Agent 的 system prompt 重写了一遍,加了几个工具,效果追平了那套五角色编排。token 成本只有它的零头。 这种事我见过不止一次。2026 年,“上多 Agent"几乎成了一种默认的进步姿态——好像单 Agent 是入门,多 Agent 才是工程师该交的作业。我想把话说直白:大多数时候你并不需要多 Agent。 单 Agent 加上几个好用的工具,能解决的事比你以为的多得多。多 Agent 是一种有明确代价的架构选择,不是一次免费的升级。 先说清楚:什么是"多 Agent” 这个词被用得太松了,先收紧一下。 下面这些不是多 Agent,它们只是单 Agent 在干活: 一个 Agent 在循环里调用多个工具(查数据库、读文件、发请求); 一个 Agent 把一段固定的处理流程拆成几步顺序执行; 一个 Agent 调用一个"子任务工具"——把某个隔离的小任务丢给一次独立的 LLM 调用,拿回一段摘要。最后这个尤其重要,后面会专门讲。 真正的多 Agent,指的是多个各自带独立上下文、独立决策循环的 Agent,彼此之间要协调。它们要交接任务、传递状态、有时还要互相评审或辩论。LangGraph 的状态图、CrewAI 的"角色 crew"、AutoGen(现在叫 AG2)的多轮对话编排,做的都是这件事。 区别的关键在于:有没有"协调"这个动作。 单 Agent 调工具,工具是被动的、无状态的,调完就完;多 Agent 之间,每一个都是活的、有上下文的,它们要互相对齐。协调,就是多 Agent 全部代价的来源。 多 Agent 真正适用的三种场景 不是说多 Agent 没用。它有几个单 Agent 确实啃不动的场景,而且这几个场景的特征很清楚。 一,子任务能真正并行,而且彼此独立。 这是多 Agent 最硬的理由。Anthropic 公开过他们的多 Agent 研究系统:一个 lead agent 把一个宽泛的研究问题拆成若干互不相干的子查询,同时派出多个 subagent 各查各的,最后汇总。这里的"并行"是真并行——五个子查询之间没有依赖,谁先谁后无所谓,挂掉一个不影响其余四个。读密集型的、可扇出的活,是多 Agent 的主场。 ...

Agent的核心循环 一个Agent本质上在做这件事： 1 感知 → 思考 → 行动 → 反馈 → 继续思考... 用代码表示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 while not done: # 1. 理解用户要什么 intent = understand(user_input) # 2. 想想怎么做 plan = think(intent, memory) # 3. 动手执行 result = act(plan, tools) # 4. 看看结果对不对 if verify(result): done = True else: memory.add(result) # 记住失败，下次改进 三个关键模块 1. 记忆系统 Agent和普通LLM调用的区别：Agent会记东西。 1 2 3 4 5 6 7 8 9 class Memory: short_term = [] # 当前对话历史 long_term = {} # 跨对话的知识 def remember(self, key, value): self.long_term[key] = value def recall(self, query): return search(self.long_term, query) 实际应用： ...