以阿里 AgentScope 的 AgentTeams 为例，这类项目在编排层解决得很彻底——通信基础设施、任务流转、共享存储、人在环、可观测性都到位了。但任务流转打通不等于协作打通，Worker 之间即使能够互相点名、委派任务、提交结果，方案讨论和共识形成本身仍然没有被充分结构化地表达出来。更细一层看，即使是按需查询、共享文件系统、工作流状态这些信息组织方式，解决的也主要是"消息传不传得到"、"文件传不传得到"和"任务走到哪一步"，没有哪一处把"一个 Agent 攒下来的上下文该以什么粒度对另一个 Agent 可见"当成一个独立的设计问题去处理。
一、编排层解决的，是"谁能说话、谁能听见"，不是"说的话有没有意义"
多 Agent 系统里经常被含混在一起的两件事，其实该拆开看。一件是通信基础设施：Agent 之间能不能把消息送到彼此手上，走什么通道，人类能不能看见、能不能插手。另一件是协作语义：这些消息里，有没有真正意义上的讨论、反对、达成共识这些内容。前者是管道，后者是管道里流的水。
AgentTeams 是个很好的观察样本，因为它把前者做得相当完整：凭据安全、通信基础设施、共享存储、可观测性、人在环、多运行时兼容，几乎覆盖了工程侧能想到的所有环节。它甚至已经把一部分任务协作语义做成了 Project、Task、DAG、Loop、委派、提交和验收。但结构上它仍然是 Manager-Workers，这些语义主要回答的是任务如何被拆开、交给谁、推进到哪一步；方案共同讨论、分歧仲裁、证据引用和共识形成，还没有被提升成独立的协作对象。管道修得再好，决定不了里面流的是清水还是空气。
二、借道人类协议：为什么是 Matrix
AgentTeams 一个挺聪明的选择，是把 Matrix 协议直接拿来当 Agent 和人类共用的通信总线。人类不需要额外学一套监控系统，打开任意 Matrix 客户端，进同一个房间，就能旁听、能插话。
这个设计的巧妙之处在于，它没有把"Agent 之间怎么通信"和"人类怎么可见、怎么介入"当成两个需要分别解决的问题。如果分开做，通常的路径是先给 Agent 造一套专属通信协议，再在上面叠一层监控和干预系统给人看。AgentTeams 反过来，直接把 Agent 塞进一个人类已经在用、协议本身足够成熟的聊天系统里——Agent 和人在同一个房间里，是同一套底层协议下的两种参与者，不是两套系统拼起来的。只是 Matrix 在这里承担的是消息和可见性，Project/Task 状态、共享文件和 Controller 生命周期仍然由另外几层系统负责。
三、可见，不等于可懂
问题出在下一层。如果只看 Matrix 这一层，Worker 之间靠 mention 机制互相点名，确实很像是把每个 Agent 拉进同一个群。这解决的是消息传不传得到，不是消息里有没有实质内容。但 AgentTeams 并不只有群聊：TeamHarness 还提供了任务委派、结果提交、项目推进和文件同步等工具，Project/Task 也定义了任务状态和依赖关系。真正的留白不在于它完全没有协作语义，而在于这些语义主要描述任务状态，没有继续描述方案是怎么讨论出来的。
一个人类如果真的打开客户端去旁听，大概率看到的仍然是一连串任务分派和结果汇报，因为方案讨论、共识形成这些东西，从设计上就没有被结构化地标注出来，是不是发生过、发生得怎么样，得自己从消息记录里去拼。AgentTeams 已经能够把项目节点、依赖、下一步和阻塞点整理成工作流视图，但可见的主要还是"任务发生了什么"，不是"一个判断为什么成立、有哪些反对意见、反对意见有没有被处理"。
四、留白比解决的部分更值得看
编排层里跟"信息该怎么流转"沾边的设计，其实提到了好几处，但拆开看，没有一处真正把"一个 Agent 积累的上下文该以什么方式、什么粒度让另一个 Agent 看见"当成一个独立的问题来处理。
围绕信息流转，AgentTeams 其实已经有几条工程化处理：Worker 可以通过消息和工具请求其他成员，可以通过共享文件按需读取结果，也可以通过 Project/Task 状态读取任务进度。这些机制已经在控制消息噪音和上下文规模，但 Worker 拉到的是什么粒度的东西，是一段摘要、一个结构化结论，还是完整执行轨迹，这一层没有展开。
为了不让全连接通信在 Worker 数量增加时把 context 撑爆，常见的工程约束会包括按能力路由、成员关系限制、按需查询和通信预算。这些更像是控制谁能跟谁说话、说多少的流量阀门，不是上下文本身该怎么分层披露的设计。AgentTeams 的 Skill、Team 成员和 Matrix 权限能够限制协作范围，但还没有进一步规定：一个结论应该向谁可见、应该带哪些来源、以什么摘要粒度出现、在什么条件下失效。
AgentTeams 案例里还提到用 MinIO 做跨 Worker 的共享文件系统，降低 token 消耗。这是另一条路子：不把东西塞进 context 反复传递，存到共享存储里，需要时按引用去取。但共享的是文件产出物，不是 Agent 各自在对话里积累的那部分上下文。
唯一明确提到分层可见性的，是任务结束后的团队复盘产出——团队共享知识库，所有 Worker 都能读；角色专属经验，只对当前岗位有意义。这是两层可见性没错，但这是复盘沉淀下来的经验资产，不是任务执行过程中实时的上下文流转。
四处放在一起看，编排层已经处理了消息传不传得到、文件传不传得到、任务走不走得通，但还没有把"上下文该怎么分层暴露"和"共识该如何被验证"单独立项。
编排层能做到的极限，大概就是让人类想看的时候能看见，让 Agent 之间能把消息、文件和任务结果递到彼此手上。它可以记录任务如何流转，却还不能决定那些消息里有没有真正的讨论，也不能决定一个 Agent 攒下来的经验，该以什么方式、什么粒度、带着哪些证据，变成另一个 Agent 能直接用的东西。这两件事，都还在 AgentTeams 当前的编排层够不着的地方。