多智能体架构之争：固定图谱还是动态发现？

一个正在困扰开发者的架构选择

在多智能体系统（Multi-agent Systems）的搭建过程中，一个核心的架构问题正引发越来越多开发者的讨论：应该采用固定图谱（Fixed Graph），还是让智能体在运行时**动态发现（Dynamically Discovered）**彼此并进行协作？

这个问题在 Reddit 社区被抛出后，触及了当下 Agent 工程实践中最棘手的权衡点。表面上看这只是两种连接方式的差异，实际上背后牵涉到系统的可扩展性、可靠性与可观测性等一系列深层次工程挑战。

两种架构范式的本质区别

方案 A：固定图谱

固定图谱的模式非常直观：Agent A → Agent B → Agent C。开发者在设计阶段就明确定义了智能体之间的调用关系和数据流向，整个协作路径是预先编排好的。

这种模式的优势在于确定性强。每一步该由谁执行、结果传给谁，都写死在编排逻辑里。这带来了更好的可预测性、更容易的调试体验，以及更简单的错误处理机制。对于业务流程相对固定的场景（比如「检索 → 总结 → 审校」这样的流水线），固定图谱往往是更务实的选择。

它的局限也很明显：当需要新增能力或调整流程时，往往要手动修改图结构，扩展性受限。系统越复杂，维护这张图的成本就越高。

方案 B：动态发现与委派

动态模式的流程则是：Agent A → 发现有能力的智能体 → 委派任务 → 获取结果。智能体不再依赖预先定义的固定路径，而是在运行时根据任务需求，寻找并调用最合适的协作对象。

正如原帖作者所言，这种方式在概念上「感觉更具可扩展性」（feels much more scalable conceptually）。理论上，只要注册进系统的智能体越多，整体能力就越丰富，且无需重写编排逻辑。这种松耦合的设计更接近于「智能体市场」的愿景。

动态委派带来的六大新问题

可扩展性的收益并非没有代价。原帖精准地列出了动态智能体委派会引入的一系列新问题，这些恰恰是当前 Agent 工程尚未完全解决的难题：

• 发现（Discovery）：Agent A 如何知道哪个智能体具备完成任务的能力？这需要某种能力注册与查询机制。
• 信任（Trust）：动态发现的智能体是否可信？如何防止恶意或低质量智能体污染结果？
• 上下文协商（Context Negotiation）：委派任务时，需要传递哪些上下文？双方如何就输入输出格式达成一致？
• 权限（Permissions）：被委派的智能体能访问哪些资源？权限如何在委派链条上传递和收敛？
• 失败处理（Failures）：动态链路中某个环节失败时，如何优雅降级或重试？
• 延迟（Latency）：发现和协商本身会引入额外开销，多层动态委派可能显著增加响应时间。

此外，原帖还特别提到了可观测性（Observability）。当调用路径在运行时才确定，追踪一次请求究竟经过了哪些智能体、每一步发生了什么，会比固定图谱困难得多。这对生产环境的排障和监控构成了直接挑战。

可观测性问题在分布式系统中并不新鲜，但在动态多智能体场景下尤为突出。传统微服务架构中，分布式追踪（Distributed Tracing）依赖 OpenTelemetry 等标准，通过 TraceID 串联跨服务调用链路。然而 Agent 系统的调用链往往携带大量非结构化的自然语言上下文，且调用深度在运行时才能确定，这使得现有 APM（应用性能监控）工具难以直接套用。目前社区正在探索「Agent Trace」的标准化格式，LangSmith、Langfuse 等工具尝试在 LLM 调用层面提供追踪能力，但针对多智能体委派链路的全链路可视化仍是空白较多的工程领域。

LangGraph/LangChain 生态的实践思考

原帖作者特别向使用 LangGraph/LangChain 的开发者发问：是否有人真正尝试过动态的智能体间委派（agent-to-agent delegation）？

这个提问本身也反映出一个现实：尽管动态发现的理念很有吸引力，但在主流框架的实际落地中，它仍处于探索阶段。LangGraph 的设计更偏向于以图（Graph）的形式显式描述智能体协作，这天然更契合固定图谱的思路。要在其上实现真正的动态发现，往往需要开发者自行构建能力注册、路由决策等额外基础设施。

从工程实践的角度看，二者并非非此即彼。一个务实的折中方案是：在宏观流程上保持固定图谱的可控性，在特定节点内引入有限的动态委派能力。这样既能享受动态路由的灵活性，又能把不确定性约束在可观测、可调试的边界之内。

LangGraph 是 LangChain 团队于2024年推出的有状态、多步骤 Agent 编排框架，其核心抽象是将工作流建模为有向图（Directed Graph），节点代表 Agent 或工具调用，边代表状态转移逻辑。相比 LangChain 早期的线性 Chain 结构，LangGraph 支持循环（Cycle）和条件分支，更适合需要反复推理、自我纠错的 Agent 场景。其状态（State）以 Python TypedDict 显式定义并在节点间共享，这种设计使调试更直观，但也意味着图结构需要在代码中预先声明，与动态发现的理念存在一定张力。若要实现动态路由，通常的做法是将「路由决策」本身建模为一个 LLM 调用节点，由模型输出下一步应调用哪个 Agent，再通过条件边（Conditional Edge）跳转——本质上仍是在固定图结构内模拟动态行为。

该如何选择

对于大多数正在构建多智能体系统的团队，这个架构问题没有标准答案，关键在于评估自身场景：

• 如果业务流程相对稳定、对可靠性和可调试性要求高，固定图谱通常是更稳妥的起点。
• 如果面对的是开放式、能力持续扩张的场景，且团队有能力解决发现、信任、可观测性等配套问题，动态发现才值得投入。

多智能体架构仍是一个快速演进的领域。原帖引发的讨论提醒我们：真正的挑战往往不在于「哪种架构更先进」，而在于如何在灵活性与可控性之间找到适合自己系统的平衡点。