一、为什么单Agent在企业场景中“不够用”？

2025年，企业级AI落地的主流形态是“单Agent”——一个智能体，绑定一套工具，处理一类任务。这个阶段，Agent的能力边界大致是：“你问它答，你派它做，做完汇报。”

但进入2026年，随着企业AI从“单点试用”走向“规模化部署”，单Agent的局限性开始集中暴露：

上下文窗口不够用。 一个复杂的跨部门任务——比如“从询价到交付的订单全流程”——涉及销售、采购、生产、财务多个环节，每个环节都有独立的系统、数据和规则。把所有上下文塞进一个Agent的窗口里，不但Token消耗巨大，推理质量也会随上下文膨胀而下降。实测中，单Agent在超过10步的长链路任务中，成功率普遍跌到60%以下。

职责边界模糊。 单Agent被要求“什么都能做”，但企业场景中“什么都能做”恰恰是最危险的。一个Agent如果同时拥有查财务数据的权限和发邮件的权限，一旦误判，后果不堪设想。

组织感知缺失。 这是集团企业特有的痛点。单Agent通常部署在单一组织范围内，无法理解“子公司A的销售经理”和“集团财务总监”之间的权限差异。数据隔离、任务作用域、审批链路——这些多组织架构下的核心诉求，单Agent天然无法满足。

二、多智能体协同的核心架构：不是“堆Agent”，而是“编排Agent”

多智能体协同的关键，不在于你部署了多少个Agent，而在于它们之间如何协作。一个成熟的多智能体架构，通常由四层组成：

┌─────────────────────────────────────────────┐
│            接入层：统一消息网关               │
│      （企微/钉钉/邮件/API 统一接入）          │
├─────────────────────────────────────────────┤
│         编排层：任务路由与状态管理            │
│   （DAG编排 / 状态持久化 / 断点恢复）         │
├─────────────────────────────────────────────┤
│         智能体层：多Agent分工协作             │
│  ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐      │
│  │销售  │ │采购  │ │财务  │ │审计  │ ...    │
│  │Agent │ │Agent │ │Agent │ │Agent │        │
│  └──────┘ └──────┘ └──────┘ └──────┘      │
├─────────────────────────────────────────────┤
│         基础设施层：连接器与数据空间          │
│   （API连接器 / 屏幕语义理解 / 多租户数据）    │
└─────────────────────────────────────────────┘

2.1 编排层：多智能体协同的“指挥中心”

编排层的核心职责是：把一个大任务拆解为多个子任务，分配给不同的Agent，管理它们之间的依赖关系，并维护整个执行链路的状态。

实现上，编排层通常基于DAG（有向无环图）来组织子任务。每个节点是一个独立的Agent调用，节点之间有明确的依赖关系。与单Agent内部的任务拆解不同，多智能体编排的粒度更粗——每个节点是一个完整Agent的职责范围，而非一个原子操作。

2.2 智能体层：按“职责”而非“功能”划分Agent

多Agent分工的核心原则是按业务职责划分，而非按技术功能划分。

以集团企业的订单协同场景为例：

• 销售Agent：负责CRM数据查询、客户跟进状态、合同信息
• 采购Agent：负责供应商数据、交期状态、采购订单
• 财务Agent：负责回款、应收、费用数据
• 审计Agent：负责合规校验、权限审计、风险标记

每个Agent只拥有完成自身职责所需的最小权限集。销售Agent查不到财务明细，财务Agent也碰不了客户数据。这个“最小权限”设计，是多智能体架构比单Agent更安全的核心原因。

2.3 组织感知层：多租户数据空间的实现

多智能体架构要适配集团多组织场景，必须解决“数据空间”的问题。每个Agent在执行任务时，需要知道自己处于哪个组织边界内，能访问哪个租户的数据，不能越过什么界限。

实现方案上，主流做法是在基础设施层引入多租户数据空间——每个子公司拥有独立的数据空间，Agent访问数据时必须经过组织感知的权限过滤器。这个过滤器会检查：当前任务的发起者属于哪个组织、请求的Agent被授权在哪个组织范围内操作、目标数据属于哪个组织。

三、集团多组织场景的实战拆解

以“子公司合同到期提醒”这个典型场景为例，看多智能体架构在多组织环境下如何运转。

单Agent的做法：一个Agent扫描全集团合同库，发现到期合同，群发提醒。结果：A子公司的法务收到了B子公司的合同提醒——数据跨组织泄露。

多智能体架构的做法：

1. 任务发起：总部配置一个全局任务“合同到期提醒”，作用域为“按组织分发”
2. 编排层路由：编排器识别这是一个多组织任务，按合同所属组织拆分为多个子任务
3. 分组织执行：每个子任务路由到对应组织的审计Agent，该Agent只在本地数据空间内扫描合同
4. 分组织推送：提醒消息只发给对应组织的法务岗位，不跨组织
5. 汇总汇报：各组织执行完成后，编排器汇总执行结果，向总部管理员汇报

这里的关键在于：Agent的执行范围被组织边界严格限定。它不是“知道”自己不该看别的组织的数据，而是架构层面就“看不到”。

四、代码实战：一个简化版的多智能体编排器

以下是一个简化版的多智能体编排器实现，展示了任务拆分、组织路由、状态管理三个核心机制：

from typing import Dict, List, Optional
from dataclasses import dataclass
from enum import Enum
import asyncio

class TaskStatus(Enum):
    PENDING = "pending"
    RUNNING = "running"
    SUCCESS = "success"
    FAILED = "failed"
    SKIPPED = "skipped"

@dataclass
class SubTask:
    task_id: str
    agent_type: str          # 指定由哪类Agent执行
    org_scope: str           # 组织作用域，如"subsidiary_a"
    action: str              # 要执行的动作
    params: dict             # 动作参数
    depends_on: List[str]    # 依赖的子任务ID

class MultiAgentOrchestrator:
    """多智能体编排器：负责任务拆解、组织路由和状态管理"""
    
    def __init__(self, agent_registry, state_store, org_permission):
        self.agents = agent_registry          # Agent注册表：{agent_type: {org_scope: agent_instance}}
        self.state = state_store              # 状态存储（Redis/DB）
        self.permission = org_permission      # 组织权限控制器
        
    async def execute(self, instruction: str, initiator_org: str) -> Dict:
        # Step 1: 拆解任务，生成DAG
        subtasks = await self._decompose(instruction, initiator_org)
        
        # Step 2: 按依赖关系调度执行
        results = {}
        ready_queue = [t for t in subtasks if not t.depends_on]
        
        while ready_queue:
            task = ready_queue.pop(0)
            
            # 权限校验：确认执行Agent在组织作用域内有操作权限
            if not self.permission.can_execute(task.agent_type, task.org_scope, task.action):
                results[task.task_id] = {"status": TaskStatus.SKIPPED, "reason": "permission_denied"}
                self._release_dependencies(task, subtasks, ready_queue)
                continue
            
            # 路由到对应组织的Agent实例
            agent = self.agents.get_agent(task.agent_type, task.org_scope)
            
            # 执行并持久化状态
            self.state.set(task.task_id, TaskStatus.RUNNING)
            try:
                result = await agent.execute(task.action, task.params)
                self.state.set(task.task_id, TaskStatus.SUCCESS)
                results[task.task_id] = {"status": TaskStatus.SUCCESS, "data": result}
            except Exception as e:
                self.state.set(task.task_id, TaskStatus.FAILED)
                results[task.task_id] = {"status": TaskStatus.FAILED, "error": str(e)}
            
            self._release_dependencies(task, subtasks, ready_queue)
            
        return results
    
    def _release_dependencies(self, completed_task, all_tasks, ready_queue):
        """释放依赖：将已完成任务的下游节点加入就绪队列"""
        for task in all_tasks:
            if completed_task.task_id in task.depends_on:
                task.depends_on.remove(completed_task.task_id)
                if not task.depends_on:
                    ready_queue.append(task)

组织感知的权限控制器，确保Agent只能在被授权的组织范围内操作：

class OrgPermissionController:
    """组织权限控制器：限定Agent的执行边界"""
    
    def __init__(self, permission_matrix):
        # permission_matrix: {
        #   "finance_agent": {"allowed_orgs": ["group", "subsidiary_a"], "allowed_actions": ["query_finance"]},
        #   "audit_agent": {"allowed_orgs": ["subsidiary_a"], "allowed_actions": ["scan_contracts"]}
        # }
        self.matrix = permission_matrix
        
    def can_execute(self, agent_type: str, org_scope: str, action: str) -> bool:
        permission = self.matrix.get(agent_type)
        if not permission:
            return False
        if org_scope not in permission["allowed_orgs"]:
            return False
        if action not in permission["allowed_actions"]:
            return False
        return True

这套架构的核心价值在于：每个Agent的能力边界和组织边界，在执行前就被显式校验。它不是“相信Agent会守规矩”，而是“架构上就不允许Agent越界”。

五、行业趋势：多智能体协同的三个演进方向

方向一：从“固定分工”到“动态编排”

当前多智能体架构的分工是相对固定的——销售Agent只做销售相关的事。但未来的趋势是动态编排：编排器根据任务特性，在运行时动态决定“需要哪些Agent、按什么顺序协作、是否临时创建新的Agent实例”。这对编排层的灵活性提出了更高要求。

方向二：从“组织隔离”到“联邦协同”

集团多组织场景中，目前的模式是“总部统一管控+子公司在授权范围内自治”。未来的方向是“联邦协同”——子公司之间可以在明确授权的前提下，进行跨组织的Agent协作，而不需要总部作为中介。这对权限模型和信任机制提出了新挑战。

方向三：从“人管Agent”到“Agent管Agent”

多智能体系统的运维复杂度随Agent数量增加而急剧上升。行业正在探索“运维Agent”——由专门的Agent来监控其他Agent的运行状态、处理异常、优化资源分配。这个方向如果成熟，将大幅降低多智能体系统的运维门槛。

六、选型启示：评估多智能体平台的关键问题

如果你所在的企业正在评估具备多智能体能力的AI平台，建议重点追问三个问题：

1. 多Agent之间如何共享状态？ 是共享一个全局状态存储，还是各自维护独立状态？状态一致性如何保证？断点恢复的粒度是任务级还是步骤级？

2. 组织隔离在哪个层面实现？ 是应用层的“代码里检查一下”，还是基础设施层的“数据空间物理隔离”？前者可能被绕过，后者才是真正的隔离。

3. 权限边界能否细化到字段级？ 同一个Agent，在不同组织、不同角色下，能访问的数据范围是否可控？财务Agent在子公司A和子公司B，权限差异能否灵活配置？

这三个问题的答案，直接决定了多智能体平台能否在集团多组织场景中真正跑起来。

七、结语

从“一个Agent”到“一批Agent”的演进，本质上是企业AI从“工具属性”走向“组织属性”的过程。单个Agent可以是一个优秀的助手，但只有经过编排、隔离、权限控制的多智能体系统，才能成为企业真正信赖的“数字团队”。

在集团多组织场景下，多智能体协同的价值尤为突出——它把企业的组织边界和管理规则，内化为了AI系统的架构约束。当一个合同到期提醒只会触达它该触达的人，当一个销售Agent永远碰不到财务数据，AI才真正成为了“被治理的数字员工”，而非“失控的自动化脚本”。

---

本文为个人在企业多智能体架构方向的技术研究笔记，供同行参考。