Agent 开发技术正在从“静态流程图”进化到“自适应编排”
Agent 开发技术最近三个月最值得注意的进化之一，是大家开始认真反思：
为什么很多多 Agent 系统看起来很复杂，效果却不稳定？
一个越来越清楚的答案是：
- Agent 数量变多，不代表效果更好
- 静态拓扑不一定适合每个 query
- 很多系统的问题不是 agent 不够多，而是 orchestration 太死
旧路线：先画好流程图，再让所有 query 走同一条路
这其实是很多多 Agent demo 的默认做法：
- planner
- researcher
- writer
- reviewer
看起来很完整，但问题是：
- 每个任务都走同一拓扑
- 角色分工是提前写死的
- query 变化了，系统结构却不变
当任务复杂度、领域和信息密度都不同的时候，这种静态结构很容易失效。
新信号之一：HERA 直接把“拓扑是否该变化”当研究对象
2026 年 4 月，DAIR.AI 在 X 上转发了一个很有代表性的工作：HERA。
这项工作的切点非常明确：
- 认为 static orchestration 是 multi-agent RAG 的瓶颈
- 不只优化 prompt
- 还优化 query-specific agent topology
它的想法可以概括成：
- 全局层：针对 query 选择或进化更合适的 agent 拓扑
- 局部层：优化单个 agent 的角色提示和行为
这和传统“固定多 agent pipeline”是完全不同的思路。
新信号之二：MAS-Orchestra 也在问“什么时候多 Agent 才真的有用”
2 月 18 日，Salesforce AI Research 在 X 上介绍 MAS-Orchestra 时提到一个我很认同的问题：
多 Agent 并不天然优于单 Agent。
这个说法非常关键，因为过去一年很多系统默认假设：
- more agents = better performance
而 MAS-Orchestra 强调的是：
- 用明确的方法去量化 multi-agent 的收益
- 研究 degree of MAS
- 不只是堆 agent，而是让 orchestration 更合理
这代表多 Agent 研发开始从“造结构”走向“测收益”。
为什么这件事和现实产品强相关
因为在真实系统里，多 Agent 的代价并不低：
- 更高延迟
- 更高 token 成本
- 更高失败组合概率
- 更难 debug
所以真正的问题从来不是“能不能做多 Agent”，而是：
- 什么任务该并行
- 什么任务该串行
- 什么任务只要 evaluator-optimizer
- 什么任务干脆别上 multi-agent
这和最近主流框架的演化其实是同一个方向
最近这些框架的官方文档，已经能看出一些共同趋势：
- Google ADK 明确区分 workflow agents 和 LLM agents
- Microsoft Agent Framework 同时提供 agents 和 workflows
- Strands 强调 agents-as-tools 的层级组织
- OpenAI Agents SDK 更强调 harness / workspace / subagent execution
这说明行业在慢慢形成一个共识：
orchestration 不是“写几条 prompt”，而是一层独立的系统设计问题。
我觉得接下来会发生什么
多 Agent 技术接下来大概率会继续往三个方向演化：
1. query-aware topology
不同问题动态选择不同编排结构。
2. role adaptation
同一个 agent 角色不再固定，由系统根据任务上下文微调。
3. orchestration evals
不再只评模型答案，而是评：
- 拓扑是否过度复杂
- 哪个角色最常拖后腿
- 何时单 Agent 反而更优
我的判断
过去很多人把 Agent 开发理解成：
- 选模型
- 接工具
- 写 prompt
但最近三个月越来越清楚的一点是：
真正的下一层竞争力，是 orchestration engineering。
也就是：
- 任务如何拆
- 角色如何分
- 何时并行
- 何时回退
- 何时根本不需要多 Agent
这层做得好，系统才会从“好看的 demo”走向“可持续的产品”。
来源
- X.com：DAIR.AI 关于 HERA 的介绍
- HERA 论文
- X.com：Salesforce AI Research 关于 MAS-Orchestra 的介绍
- X.com：关于生产级 agent workflow patterns 的讨论