从主流框架到自研：构建生产级多智能体协作运行时的实战复盘

1. 项目概述：从“试遍所有”到“亲手打造”的旅程

在AI Agent（智能体）开发领域，多智能体框架正以前所未有的速度涌现。作为一名长期深耕于此的开发者，我最近经历了一个极具代表性的项目周期：为了构建一个能够处理复杂、长链条任务的协作型AI系统，我和团队几乎试遍了市面上所有主流的开源多智能体框架。从那些名声在外的明星项目，到一些新兴的、专注于特定场景的解决方案，我们逐一进行了深度评估与原型验证。这个过程充满了发现、惊喜，但更多的是对“理想与现实差距”的深刻体会。最终，我们做出了一个决定：不再试图将就，而是基于我们积累的经验和明确的需求，亲手打造一个属于我们自己的运行时（Runtime）。这篇文章，就是这次“试遍所有，然后自研”旅程的完整复盘。我将详细拆解我们评估过的框架类型、遇到的共性问题、促使我们自研的核心驱动力，以及我们自研运行时（我们内部称之为“Orchestrator Core”）的关键设计思路与实现要点。无论你是在选型十字路口的技术负责人，还是对多智能体系统底层实现感兴趣的高级开发者，相信这些从一线实战中获得的经验与教训，都能为你提供有价值的参考。

2. 主流多智能体框架的深度实践与痛点分析

在决定自研之前，我们系统性地将市面上的框架分为了几个大类进行测试，每一类都代表了不同的设计哲学和适用场景。我们的测试基准是一个模拟的“电商客户服务与运营自动化”场景，涉及订单查询、库存核实、优惠计算、异常处理等多个需要不同技能智能体协作的子任务。

2.1 基于中心化编排（Orchestration）的框架

这类框架通常提供一个中心控制器（或称为“协调者”、“大脑”），由它来接收任务，分解子目标，并调度不同的智能体（或称“工具人”、“专家”）去执行。AutoGen和CrewAI是这一领域的典型代表。

AutoGen的强大之处在于其高度灵活的可编程对话模式。通过定义代理（Agent）之间的对话规则，你可以构建出极其复杂的交互逻辑。我们在测试中用它实现了一个“辩论式”决策流程，让一个“成本控制Agent”和一个“客户满意度Agent”就一个退货请求进行多轮辩论，最终由“经理Agent”拍板。这种灵活性令人印象深刻。

实操心得：AutoGen的“GroupChat”功能非常强大，但配置起来就像在编写一个多线程的通信协议，调试对话死锁或循环是家常便饭。它的学习曲线陡峭，更适合研究性质或对交互逻辑有极致定制化需求的场景。

然而，它的痛点也同样明显：状态管理薄弱。在长周期任务中，整个对话的上下文（Context）管理完全依赖于开发者在消息列表中手动维护，这对于需要持久化中间状态（比如一个不断更新的订单处理进度表）的业务流程来说，是个巨大的负担。此外，其运行时的资源消耗（尤其是当多个Agent同时持有大语言模型实例时）也缺乏精细控制。

CrewAI则采用了更贴近业务流程的“任务（Task）- 代理（Agent）”模型。它引入了“上下文（Context）”的概念，允许任务之间传递输出，这比AutoGen的纯消息传递更结构化。它的设计思想更接近一个“项目管理系统”，直观易懂。

但我们发现，CrewAI的调度策略相对固定。它的“顺序执行”或“分层执行”模式，在面对需要动态条件分支（例如：如果库存检查失败，则直接跳转到补货流程，而不是继续执行优惠计算）的复杂场景时，显得力不从心。你需要通过大量“if-else”逻辑嵌套在任务描述中来实现，破坏了流程的清晰度。

2.2 基于去中心化协作（Cooperation）的框架

这类框架没有绝对的中心，智能体之间通过共享的工作空间（如黑板Blackboard）或发布/订阅消息机制进行协作。LangGraph和Microsoft Autogen Studio的某些模式体现了这种思想。

LangGraph建立在LangChain之上，其核心是将多智能体协作抽象为一个有状态图（Stateful Graph）。节点是智能体或函数，边定义了控制流。这为可视化、调试和理解智能体间的交互提供了绝佳的抽象。

我们使用LangGraph成功构建了一个基于事件驱动的客服系统。例如，“用户消息事件”触发“意图识别节点”，然后根据意图路由到“订单查询节点”或“投诉处理节点”。图的模型非常优雅地描述了系统的工作流。

避坑指南：LangGraph的“状态”是整个图共享的一个字典。虽然灵活，但这也意味着状态竞争和污染的风险极高。如果两个并行的节点不小心修改了状态的同一个字段，结果将不可预测。你需要像处理多线程编程一样，精心设计状态的结构和访问权限，这带来了额外的复杂度。

2.3 面向特定领域的轻量级框架

我们还考察了一些为解决特定问题而生的框架，例如专注于工具使用（Tool Calling）编排或强化学习协作的库。它们通常在单一功能点上做得非常深入、高效。

然而，当我们的业务场景需要融合“工具调用”、“多轮对话”、“条件分支”、“持久化状态”以及“外部系统集成”时，这些轻量级框架就显得“捉襟见肘”。我们不得不将多个框架拼凑在一起，随之而来的是惊人的集成复杂度和维护成本。框架A的状态管理机制与框架B的消息协议不兼容，我们需要编写大量的“胶水代码”，这背离了使用框架提升效率的初衷。

2.4 共性痛点总结

经过这一轮密集的实践，我们梳理出以下几个普遍存在的痛点，这些痛点最终促使我们考虑自研：

1. 状态管理之殇：要么太弱（如AutoGen），需要开发者自己操心一切；要么太原始（如LangGraph的共享字典），容易出错。缺乏一个面向业务、支持版本化、支持回滚的强状态管理机制。
2. 调度逻辑的灵活性与简洁性难以兼得：像CrewAI这样的框架，简洁但不够灵活；像LangGraph这样用图来定义，灵活但描述复杂业务逻辑时，图可能变得极其庞大和难以维护。
3. 可观测性（Observability）匮乏：当多个智能体协作时，系统就像一个黑盒。我们很难实时回答：“当前任务进行到哪一步了？”、“哪个Agent卡住了？为什么？”、“整个流程的耗时分布如何？”。现有的框架大多只提供基础的日志，缺乏链路追踪、性能指标和可视化监控。
4. 生产级部署支持不足：许多框架起源于研究或Demo项目，对容错、重试、负载均衡、水平扩展等生产环境必需的特性考虑不足。例如，智能体执行失败后如何优雅地重试或补偿？如何将智能体作为微服务进行部署和扩缩容？
5. 与现有技术栈的融合成本高：我们的后端是云原生的，使用Kubernetes和gRPC。许多框架默认假设运行在一个独立的Python脚本环境中，将其嵌入到现有的微服务架构中，并实现高效的通信，需要大量的改造工作。

3. 自研运行时“Orchestrator Core”的核心设计

基于以上痛点，我们自研运行时的目标非常明确：构建一个专注于生产环境、状态驱动、高度可观测且易于与现有架构集成的多智能体协作核心。我们将其命名为“Orchestrator Core”。

3.1 设计哲学：状态机（State Machine）作为一等公民

我们放弃了“中心化编排”和“去中心化协作”的二分法，而是采用了状态机作为核心抽象。我们将一个复杂的多智能体任务，建模为一个状态机。每个状态（State）代表流程中的一个特定阶段（例如：“等待用户输入”、“正在查询库存”、“生成回复”）。状态之间的转移（Transition）由事件（Event）触发，而转移过程中执行的动作（Action），就是调用相应的智能体（Agent）。

为什么是状态机？

1. 天然匹配业务流程：业务流程图很容易翻译成状态机图，开发者和产品经理可以用同一种语言沟通。
2. 强大的状态管理：每个状态机实例都有自己独立、结构化的状态（State Data），完全隔离，无污染风险。状态数据可以轻松序列化、持久化，支持暂停、恢复甚至回滚。
3. 清晰的逻辑表达：条件分支（if-else）、循环（while）、并行（parallel）都可以通过状态和转移清晰地表达出来，比复杂的对话规则或庞大的图更易理解和维护。
4. 易于实现可观测性：当前处于哪个状态，一目了然。状态的历史变迁就是完整的执行链路。

3.2 核心架构四层模型

我们的运行时架构分为清晰的四层：

这个架构的关键优势在于解耦：编排层只关心“流程逻辑”，不关心智能体内部如何实现；智能体层只关心“如何完成特定任务”，不关心自己在整个流程中的位置。这使得每一层都可以独立开发、部署和扩展。

3.3 工作流定义：DSL与代码API并存

为了兼顾易用性和灵活性，我们提供了两种定义工作流的方式：

1. 声明式DSL（YAML）：适用于大多数标准业务流程。

name: “customer_service_refund” states: - id: “receive_request” type: “input” event: “request_received” transitions: - target: “validate_order” condition: “{{ .event.payload.type == ‘refund’ }}” - id: “validate_order” type: “task” action: “call_agent” agent: “order_validator” parameters: order_id: “{{ .state.data.order_id }}” transitions: - target: “approve_refund” condition: “{{ .action.result.valid }}” - target: “reject_refund” condition: “{{ not .action.result.valid }}” - id: “approve_refund” type: “task” action: “call_agent” agent: “finance_agent” parameters: amount: “{{ .state.data.amount }}” transitions: - target: “notify_customer”

这份YAML清晰定义了一个退款流程的状态机，包含条件分支。

2. 编程式API（Python SDK）：当流程逻辑极其复杂，需要动态生成或精细控制时使用。

from orchestrator_core import Workflow, State, TaskState, Condition wf = Workflow(“dynamic_workflow”) initial_state = State(“start”, type=“input”) validation_state = TaskState( “validate”, agent=“validator”, input_builder=lambda ctx: {“data”: ctx[“input”]}, result_handler=lambda result, ctx: ctx.update({“is_valid”: result[“valid”]}) ) # ... 动态添加状态和转移逻辑

这种方式提供了最大的灵活性，但需要开发者对框架更熟悉。

设计抉择：我们选择同时支持DSL和API，是因为在实践中我们发现，约80%的流程是相对固定、可由产品运营人员通过DSL配置的；而剩下20%的复杂、动态流程，则需要开发人员通过代码深度定制。两者并存覆盖了所有场景。

4. 关键实现细节与生产级特性

4.1 状态持久化与恢复

这是实现可靠长周期任务的基础。我们的状态机引擎在每次状态转移前后，都会将整个状态机实例（包括状态数据、当前状态ID、历史记录）序列化并持久化到外部存储（如Redis或PostgreSQL）。

# 伪代码：状态持久化点 class StateMachineInstance: def transition(self, event): # 1. 持久化当前状态（作为检查点） self._save_checkpoint() # 2. 执行转移逻辑和动作 next_state = self._process_transition(event) # 3. 更新当前状态并再次持久化 self.current_state = next_state self._save_checkpoint() # 4. 如果动作是异步的，则返回，等待回调事件 return self._execute_action(next_state.action)

这样做的好处是：即使系统崩溃或重启，也可以从最新的检查点恢复任务，无需从头开始。这对于处理可能持续数小时甚至数天的业务流程（如订单履约）至关重要。

4.2 智能体通信与标准化接口

我们定义了严格的智能体服务接口规范（Protocol Buffer格式）：

service AgentService { rpc Execute (AgentRequest) returns (AgentResponse); } message AgentRequest { string task_id = 1; // 全局任务ID string agent_id = 2; // 智能体ID map<string, Value> parameters = 3; // 输入参数 Context context = 4; // 完整的上下文（包含历史状态数据） } message AgentResponse { bool success = 1; oneof result { string output = 2; // 成功时的输出 Error error = 3; // 失败时的错误信息 } map<string, Value> metadata = 4; // 执行元数据（耗时、token用量等） }

所有智能体都必须实现这个gRPC接口。编排层通过服务发现（如Consul）来定位和调用智能体。这种设计使得智能体可以用任何语言编写（Go, Java, Python等），实现了技术栈的异构性。

4.3 内置的可观测性支柱

我们从一开始就将可观测性嵌入到运行时核心中：

1. 分布式链路追踪：每个任务、每次状态转移、每个智能体调用都会生成唯一的Trace ID和Span ID，并上报到Jaeger或Zipkin。我们可以在仪表盘上清晰地看到一个请求流经了哪些状态、调用了哪些智能体、每个环节的耗时。
2. 指标（Metrics）收集：运行时核心暴露Prometheus指标，包括：状态机实例总数、各状态停留时间分布、智能体调用成功率/耗时、事件队列深度等。这些指标用于设置告警和容量规划。
3. 结构化日志：所有日志均以JSON格式输出，包含丰富的上下文信息（task_id, state, agent_id），便于通过ELK或Loki进行聚合查询和关联分析。

4.4 容错与弹性机制

1. 智能体调用重试：对于可重试的失败（如网络超时、依赖服务暂时不可用），编排层会根据策略（指数退避）进行自动重试。
2. 断路器（Circuit Breaker）：如果某个智能体连续失败，断路器会“跳闸”，暂时停止向其发送请求，避免雪崩效应，并定期尝试恢复。
3. 补偿动作（Saga模式）：对于涉及多个步骤且需要事务一致性的流程，我们实现了简单的Saga模式。每个状态可以定义一个“补偿动作”（compensation），当流程后续失败时，可以自动触发前面已成功步骤的补偿，进行回滚。
4. 死信队列（DLQ）：对于最终无法处理的事件或任务，会进入死信队列，供运维人员人工排查，避免数据丢失。

5. 自研 vs 采用开源框架的决策复盘

自研一个核心运行时是一项重大的技术投入，并非所有团队都适合。以下是我们的决策 checklist，供你参考：

选择自研，如果你的项目...

• 业务场景极其复杂且独特，现有框架的核心抽象（如对话、任务链、图）无法优雅匹配。
• 对可靠性、可观测性、性能有极高的生产级要求，而现有框架在这些方面是短板。
• 团队技术实力雄厚，有能力和精力进行长期维护，并且自研能形成重要的技术壁垒。
• 需要与公司现有的微服务、部署、监控体系进行深度、无缝集成。

优先采用开源框架，如果你的项目...

• 处于快速验证想法（PoC）或原型阶段，需要快速搭建演示。
• 业务逻辑相对标准，可以被主流框架的模型较好地覆盖。
• 团队资源有限，希望聚焦业务逻辑而非底层基础设施。
• 社区生态（如预构建的智能体、工具集成）对你来说价值巨大。

对于我们而言，在深度尝试了多个框架后，发现生产级要求的差距是本质性的。自研“Orchestrator Core”虽然起步投入大，但它完美地契合了我们的业务架构和技术栈，长期来看，在开发效率、系统稳定性和运维成本上，反而带来了净收益。

6. 实施路线图与迁移建议

如果你也考虑走上类似的道路，以下是我们建议的渐进式路线：

第一阶段：抽象与协议定义不要急于写引擎代码。首先，用文档清晰地定义出你的“理想模型”：智能体如何交互？状态如何表示？事件是什么？制定出通信接口协议（如Protobuf）。这个阶段的目标是统一团队的思想，形成“宪法”。

第二阶段：打造最小可行运行时（MVP）实现一个最简的状态机引擎，支持单个线性流程的DSL解析、状态转移和智能体调用。暂时忽略持久化、高级可观测性。用这个MVP去跑通一个最简单的端到端业务场景，验证核心抽象是否可行。

第三阶段：迭代核心生产特性在MVP基础上，按优先级加入：1) 状态持久化，2) 基础监控和日志，3) 错误重试机制，4) 更复杂的流程控制（分支、循环）。每加一个特性，都用真实的业务场景来驱动和验证。

第四阶段：生态建设与工具链开发辅助工具：工作流可视化设计器、状态机调试器、执行历史查看界面。这些工具能极大提升开发者和运营人员的效率。

关于迁移：如果已有业务跑在某个开源框架上，迁移可以逐步进行。通常可以“新流程用新运行时，旧流程逐步重写”。或者将旧框架的智能体包装成符合新运行时协议的微服务，让新运行时的编排层去调度它们，实现平滑过渡。

7. 总结与展望

回顾从“试遍所有”到“亲手打造”的整个过程，其价值远不止于获得了一个好用的工具。它迫使我们对“多智能体协作”这一复杂问题进行了最深层次的思考，从简单的API调用封装，上升到了“如何设计一个可靠的分布式业务流程系统”的层面。我们自研的“Orchestrator Core”本质上是一个为AI智能体量身定制的、状态驱动的业务流程管理（BPM）系统。

目前，这套系统已经稳定支撑了我们内部多个核心的AI自动化流程，日均处理数十万次智能体协作任务。状态机的模型让业务逻辑前所未有的清晰，而强大的可观测性让我们能快速定位任何问题。未来，我们计划在智能体动态注册发现、工作流版本管理与灰度发布、以及基于历史数据的流程优化建议等方面进行持续探索。

这条路并不轻松，但如果你也面临着类似的高复杂度、高可靠性要求的AI智能体协作场景，并且对现有框架的局限性感到掣肘，那么投入资源去设计和实现一个符合自身“基因”的运行时，或许是一个值得认真考虑的战略选择。最关键的是，想清楚你要解决的核心问题到底是什么，然后让技术设计坚定不移地服务于它。