跨Agent调用的架构决策：从通信协议到上下文隔离的实践指南

先交代一个背景：我手上有三个Agent，一个负责需求分析和任务拆解，一个负责写代码，一个负责代码审查。分开跑的时候每一个都很正常，一旦想让它们协作，第一个撞上的问题不是模型能力，而是最基础的通信问题——A的输出怎么变成B的输入？两个Agent之间到底是用自然语言对话，还是直接传结构化数据？调用的边界在哪里，超时重试怎么处理，上下文会不会互相污染？

这些问题我踩了一两个月，试过几种方案，最后被同事一句话点醒：跨Agent调用根本不是某个框架的配置项，而是一套需要自己设计和维护的架构决策。今天把这段实践和背后那条"路线之争"的脉络写清楚，希望能让正在做Agent开发的同行少走点弯路。本文适合已经有一个能跑通的Agent、打算做多Agent协作的开发者，也适合在设计Agent平台时纠结选型的技术负责人。

1. 单Agent的边界撞墙之后：跨Agent调用要解决的三个真实问题

1.1 单体Agent的上下文和工具双重瓶颈

一个Agent想干所有事，最大的敌人是上下文窗口。我给一个Agent同时挂了代码生成、代码审查、测试执行、文档生成四组工具，刚开始觉得"全能"，跑了几轮就发现它开始犯低级错误：明明只需要生成一段Python函数，它却把审查规则里的限制条件也考虑进去，生成结果变得特别保守；或者在做测试的时候，突然调用了文档生成的工具，输出完全跑偏。

原因在于，一个模型在有限的上下文里同时装载"如何写代码""如何审查代码""如何跑测试""如何写文档"这些差异巨大的指令，指令之间会互相干扰。更现实的问题是工具数量膨胀之后，模型在每一步都要从十几个工具里选一个，工具选择错误的概率会直线上升。把一个大Agent拆成多个专注的Agent，不是锦上添花，而是单体Agent在上下文和工具选择两个维度上撞墙之后的必然结果。

1.2 三种主流协作模式：流水线、编排、竞速评审

拆完之后怎么协作，实践中我发现主流需求可以归纳成三种模式。

第一种是流水线模式（Pipeline），最直观：需求Agent拆解任务，代码Agent写代码，审查Agent给出修改意见，每个Agent负责一段，输出成为下一个的输入。这种模式逻辑简单，链路清晰，但每一环的延迟是累加的，如果中间某个Agent输出格式不对，后面全线崩盘。

第二种是编排模式（Orchestrator），有一个主控Agent负责动态决策：它读任务，判断这一步该交给哪个子Agent，汇总结果后再决定下一步。这种模式灵活，但主控Agent本身会成为瓶颈，而且主控的决策质量完全取决于它对子Agent能力的理解程度，经常出现"派错活"的情况。

第三种是竞速/评审模式，多个Agent做同一件事，比如让三个不同风格的Agent分别生成方案，再由一个评审Agent投票或打分选出最优。这种模式结果质量高，但成本是成倍增长的，适合高价值决策场景。

这几种模式不是互斥的，实际项目中经常混合使用。但无论哪种模式，落到实现层面都需要回答三个问题：Agent之间怎么通信、传什么格式的数据、失败时怎么处理。

1.3 通信协议、数据契约、执行语义：跨Agent调用的三要素

我习惯把跨Agent调用拆成三个要素，任何一个设计不到位，整个系统都会埋雷。

第一个是通信协议。两个Agent在同一个进程里，可以直接函数调用；在不同服务里，可以走HTTP、消息队列，或者用MCP这类标准化协议。协议的本质是"传输通道"，它决定了调用的同步异步、可靠性和延迟特征。

第二个是数据契约。A传给B的是什么？是纯文本描述，还是带有固定字段的JSON？契约不清晰，Agent之间就会像两个语言不通的人互相比划，表面上在对话，实际上各说各的。我见过最典型的翻车现场是：需求Agent输出的任务描述在结果里，代码Agent却从对话历史里找任务，结果反复找不到，白白烧了三次token。

第三个是执行语义。一次跨Agent调用是同步等结果，还是异步拿回执？超时设多少？失败重试最多几次？重试会不会导致下游重复执行？这些问题没有提前定义，后面线上出故障时根本无从下手。

2. 四条技术路线：工具调用、消息队列、MCP、语义路由的全面对比

2.1 工具调用路线：把Agent硬包装成函数，简单但不适合复杂协作

最早的跨Agent调用方案，就是把AgentB封装成AgentA的一个工具。AgentA在推理时发现任务需要B的能力，就发起一次工具调用，背后的执行器收到请求后运行B，然后把B的结果作为工具返回值交还给AgentA。

这个路线最大的优势是简单，完全符合LLM工具调用的既有范式，AgentA不需要知道B的存在细节，只需要知道"有这个工具、传什么参数、拿什么结果"。

但它有硬伤。首先，工具调用天然是同步阻塞的，A调用B之后必须等B返回，如果B内部还要调用C、D，整条链路就会变成一个长同步调用，任何一个环节超时，A都要跟着超时。其次，工具调用的错误处理很粗糙，B返回一个报错字符串，A能不能理解并自行修复？大多数情况下，A只会把这个错误原封不动地夹在对话里继续执行，根本不会做真正的容错。这个路线适合的子Agent是执行时间短、逻辑稳定、不需要复杂状态同步的场景。

2.2 消息队列路线：用异步消息化解耦跨进程协作

第二个路线是把跨Agent调用改成消息传递。A把任务封装成一条消息，发到队列里，B监听队列，消费消息后处理，再把结果发回结果队列，A通过异步方式接收。

这个路线的核心价值是解耦和削峰。A不需要等B处理完再继续，中间可以穿插其他任务；B实例也可以水平扩展，多个B同时消费队列，吞吐量大幅提升。消息队列本身自带的ack、重试、死信机制，让失败处理有了制度保障。

缺点是延迟和复杂度。一个消息从A发到队列再到B处理完回到A，链路比同步调用长很多，不适合对时延敏感的场景。另外，消息契约一旦定义就难以变更，字段改名要经过严格的版本兼容流程，否则新旧实例同时跑的时候会互相踩踏。消息队列适合长流程、跨进程、需要高可靠性的任务流，但要求团队有比较强的中间件运维能力。

2.3 MCP路线：把Agent能力标准化成服务接口

MCP（Model Context Protocol）这两年是Agent工具化方向最被看好的协议之一。它的思路是把Agent的能力封装为标准化的服务端接口，其他Agent通过MCP客户端像调用工具一样调用这些接口。

这个路线的意义在于标准化和生态。一旦Agent能力以MCP形式暴露，任何支持MCP协议的Agent客户端都能直接对接，不需要为每个Agent定制通信代码。服务发现、鉴权、参数校验这些能力也随协议一起逐步完善，相当于把跨Agent调用的"方言"统一成了"普通话"。

要泼一盆冷水：MCP本质上更适合"工具型"交互，也就是请求-响应模式，对于需要多轮对话、需要共享上下文、需要记忆的协作场景，MCP目前的表达能力还不太够。我试过把一个需要和用户来回确认需求的Agent包成MCP服务，调用方传进来的参数只有两三个固定字段，需求确认的过程根本没法展开，最后只能放弃。MCP适合能力开放和工具集成，不适合承载复杂的对话式协作。

2.4 语义路由/Agent网关路线：调用方只面对一个入口

第四个路线是Agent网关。调用方不直接接触任何具体Agent，而是面对一个统一入口，入口内部根据任务语义，由LLM或规则引擎判断该把请求路由给哪一个Agent。

这个路线的核心收益是调用方与Agent实例完全解耦。上层业务不需要维护"什么任务找谁"的映射关系，新增一个Agent或替换一个Agent，网关侧配置一下就行，对调用方透明。网关还可以统一做鉴权、限流、日志和链路追踪，跨Agent调用的治理能力一下子上来了。

代价同样明显：网关本身会成为新的单点和瓶颈。路由判断依赖LLM推理的话，一次路由额外引入几百毫秒延迟和一次模型调用成本；路由判断一旦出错，请求被送到错误的Agent，下游会连锁出错，而且排查起来比直连难得多。我觉得这个路线不是"开局就能用"的，而是Agent数量多到一定程度、调用关系乱到无法维护之后的治理选择。

2.5 路线对比小结

用一张表把这四条路线的核心差异列出来，方便直接对照选型。

选型口诀基本是：进程内、轻量、要即时反馈，用工具调用；跨服务、长任务、要高可靠，用消息队列；对外标准化能力，用MCP；Agent数量失控了，再考虑上网关。大多数人一上来就想上网关，或者想拿MCP解决一切协作问题，其实都是没想清楚自己缺的到底是传输通道还是标准化协议。

3. 实战拆解：从零实现一套跨Agent调用的可运行方案

3.1 场景定义与数据契约先行

我自己搭的演示系统是一个简化版的开发协作流水线：需求Agent负责把用户描述转化成可执行需求文档；代码Agent根据需求文档生成代码；审查Agent检查代码并输出修改意见。三个Agent独立部署，跑在同一个Python进程里，方便演示，但调用的边界完全按跨服务的方式来设计。

动手写代码之前，我做的第一件事是定义数据契约。三个Agent之间的数据流有三段：需求Agent到代码Agent的"需求文档"，代码Agent到审查Agent的"待审查代码"，审查Agent到代码Agent的"审查意见"。对应设计了三个JSON Schema，每个Schema都带版本号字段。

以需求文档为例，字段包括需求ID、原始描述摘要、功能点列表、约束条件列表、验收标准、创建时间。代码Agent消费的时候，只需要关注这几个字段，不会被需求Agent的对话历史里那些分析过程干扰。这个设计在后面帮了大忙——审查Agent改字段的时候，通过版本号能立刻定位是哪个环节出了问题，而不是靠猜。

3.2 混合架构：工具调用做同步应答，队列做异步流水

我的最终架构是一个混合方案：把三种Agent的执行器注册到一个AgentRegistry里，Agent之间的调用分两种形态。

一种是AgentA需要AgentB立即返回结果的场景，比如代码Agent向审查Agent发起审查请求，代码Agent必须拿到审查意见才能做修改。这种我用工具调用强同步，但封装了超时和重试。

另一种是流水线场景，需求Agent处理完任务后，把需求文档投递到任务队列，代码Agent从队列里拿任务开始写代码。这种我不让需求Agent同步等代码Agent的结果，而是把队列当拼接缝，需求Agent完成自己的职责就结束，后面的环节独立跑。

这么设计的理由是：代码生成可能花几十秒甚至几分钟，让需求Agent同步等一个几分钟的任务，既浪费它的时间，也会让它带着"上一个任务还没结束"的心理负担处理下一个任务，影响质量。队列隔开之后，每个Agent的任务边界变得非常干净。

3.3 核心代码骨架：Agent注册表与调用链

下面给出一份可以跑通的最小骨架，语言用Python，Agent本身用OpenAI格式的接口，但跨Agent调用逻辑与模型无关。

import json import time from typing import Any, Callable from dataclasses import dataclass, field from collections import deque @dataclass class Agent: name: str version: str executor: Callable[[dict], dict] # 每个Agent声明自己能处理的消息类型，用于路由和校验 accepts: list[str] = field(default_factory=list) class AgentRegistry: def __init__(self): self._agents: dict[str, Agent] = {} def register(self, agent: Agent): self._agents[agent.name] = agent print(f"[registry] {agent.name}@{agent.version} 已注册") def resolve(self, name: str) -> Agent: return self._agents[name] class CallChain: """同步工具调用的外层封装，统一处理超时和重试""" def __init__(self, registry: AgentRegistry, timeout: float = 30.0, max_retry: int = 2): self.registry = registry self.timeout = timeout self.max_retry = max_retry def call(self, target_agent: str, payload: dict) -> dict: agent = self.registry.resolve(target_agent) last_err = None for attempt in range(1, self.max_retry + 2): try: start = time.time() # 执行器内部自行做LLM调用，这里只关心结果 result = agent.executor(payload) if not isinstance(result, dict): raise ValueError("执行器必须返回dict") result.setdefault("_trace", { "target": target_agent, "attempt": attempt, "duration_ms": int((time.time() - start) * 1000), }) return result except Exception as e: last_err = e print(f"[callchain] 调用 {target_agent} 第{attempt}次失败: {e}") time.sleep(2 ** attempt) # 指数退避 raise RuntimeError(f"调用 {target_agent} 超过重试上限: {last_err}") _task_queue: deque[dict] = deque() def enqueue_task(task: dict): """异步投递任务，返回任务ID，调用方不用等结果""" task_id = f"task-{int(time.time() * 1000)}" _task_queue.append({"task_id": task_id, **task}) return task_id def worker_loop(registry: AgentRegistry, agent_name: str): """模拟队列消费者，持续处理发往指定Agent的任务""" while True: if not _task_queue: time.sleep(0.5) continue task = _task_queue.popleft() if task.get("target") != agent_name: # 不是本Agent的任务，放回队尾 _task_queue.append(task) time.sleep(0.1) continue agent = registry.resolve(agent_name) result = agent.executor(task) print(f"[queue] {agent_name} 完成任务 {task['task_id']}，结果摘要: {json.dumps(result)[:200]}")

实际执行时，每个Agent的executor内部调用LLM并把模型输出解析成契约里的JSON格式。关键点是：注册表让"按名字找Agent"变得统一，调用链封装了超时重试，队列实现了异步解耦，三个组件合起来就是一个最简可用的跨Agent调用基础设施。

3.4 上下文隔离：只传契约结果，不传完整对话

这里必须单独强调上下文隔离，这是我踩坑最深的地方。最早我图省事，把AgentA的完整对话历史直接拼进AgentB的system prompt，结果AgentB把AgentA的思考过程当成了自己的分析依据，输出了一系列项目里根本不存在的问题，编造得有理有据，差点让人以为审查Agent真的发现了严重bug。

正确做法是：跨Agent调用传递的永远是执行结果，不是对话过程。A的完整思维链是A的私有信息，B只需要看到A产出的结构化契约结果。这就像团队协作，你交给下游的应该是交付物，而不是把你在工位上说的每句话都录下来发给他。上下文隔离能显著降低下游Agent的上下文占用，也能避免它被上游的"心理活动"带偏。

另外要维护好调用链的追踪ID。每个跨Agent调用都带一个上游task_id，日志里通过task_id可以把整条流水线串起来。没有这个ID，线上排查的时候得靠肉眼猜哪条消息属于哪次调用，那种痛苦经历过一次就不想经历第二次。

4. 路线之争的本质：控制权、上下文与工作流原子性

4.1 中心化编排与去中心化自组织之争

跨Agent调用的路线之争，表面上是技术选型差异，本质上是控制权之争。中心化编排方案里，一个主控Agent或一个代码层面的Orchestrator掌握全局，每一步让谁执行、按什么顺序执行，全部由中心节点决定。去中心化自组织方案里，Agent之间通过消息互相协商，谁有能力谁接活，没有全局控制节点。

中心化最大的优点是可预期，执行顺序、资源分配、失败处理都有明确归属，特别适合流程固定的业务场景。缺点上面也说过，主控Agent是全系统的认知瓶颈，它如果判断错了子Agent的能力边界，整个任务链都会偏。去中心化在系统弹性和故障隔离上更有优势，但"没有全局视角"这个特点让它很难保证复杂流程的正确性，很容易出现Agent之间互相等消息造成活锁。

我的实际体会是，拿"中心化还是去中心化"当口号争没有意义，关键看工作流的原子性。如果你的业务天然是固定流程，中心化编排能用代码写清楚，就别硬掰成自组织；如果业务流程本身高度动态，每条任务路径都不同，才需要借助去中心化的灵活性。大多数项目属于前者，所以中心化编排依然是当前最务实的起步方案。

4.2 对话式协作与结构化数据之争

这是我在团队里吵得最凶的一条路线之争。支持对话式的人认为，Agent天然以自然语言为核心，Agent之间用自然语言对话最符合模型的理解方式，AgentA把任务用一句话发给AgentB，AgentB自己解析。支持结构化数据的人认为，Agent之间传递的应该是严格Schema的JSON，字段明确、语义清晰，模型不需要臆测。

两种方案都有过失败案例。对话式协作的问题是稳定性差，模型会用各种不同的措辞表达同一个意思，下游Agent的理解也会跟着波动；而且对话历史越长，语义漂移越严重，录人类对话的Agent经常自己加戏。结构化数据的问题是灵活性差，超出Schema范围的信息不知道怎么传，偶尔出现一个不在预设字段里的需求，整个链路就要改。

我现在的倾向是"结构化为主，对话为辅"：主体信息走JSON契约，模型的自由解释放在一个专门的reasoning字段里。这样既保证了主链路的确定性，也给模型留下了表达空间。纯粹的自然语言Agent间对话，目前更适合语义高度灵活但错误容忍度高的场景，比如头脑风暴、方案构思，不适合工程化的协作链路。

4.3 共享上下文、黑板架构与持久记忆

第三种路线之争围绕上下文展开。一种做法是把所有Agent的上下文放进一个共享空间，每个Agent都能看到全局信息，这就是黑板架构（Blackboard）。另一种做法是每个Agent只维护自己的上下文，通过专门设计的消息传递交换信息。

黑板架构在视觉上很优雅，所有Agent都在同一块黑板上写字、读字，协作看上去非常直观。但工程上它有个致命问题：黑板内容迅速膨胀，每个Agent读取时都要从大量无关信息中筛选自己的部分，token消耗巨大，而且信息间的相互引用容易产生隐性耦合。我在一个Demo项目里试过黑板，跑了几轮后，每个Agent的prompt都膨胀到近万token，响应时间肉眼可见地变慢。

持久记忆是另一个被频繁讨论的方向。跨Agent调用时，与其每次把上下文传过去，不如让Agent们共享一个外部记忆库，需要什么信息按需检索。这个思路我很认可，但要注意记忆库不是垃圾桶，写入记忆的信息需要经过筛选和结构化，否则Agent从记忆库里检索出来的全是噪音，效果比不检索还差。我在实践中更倾向按任务维度建独立记忆空间，任务结束就清理，而不是做一个全局大水缸。

4.4 Harness、Skills与Agent编排的关系再梳理

很多同行问过"Harness和Agent到底什么区别""Skills和Agent的区别"，跟跨Agent调用有什么关系。

我的理解是，Harness是承载Agent运行的执行环境，它负责加载模型配置、维护上下文、处理工具调用循环、管理生命周期。跨Agent调用发生的时候，真正做调度、路由、消息投递的往往是Harness层面的事情，而不是Agent内部逻辑。Agent只关心"我收到了什么输入、该产出什么输出"，至于消息是从哪个Agent来的、要不要重试，这些交给Harness处理。

Skills是Agent拥有的可复用技能模块，本质上是预定义的调用模板和行为规范。跨Agent调用可以把一个Agent的Skill暴露给另一个Agent使用，这时候Skill就扮演了"可复用单元"的角色。但Skill和Agent的边界要清楚：Skill是静态的能力描述，Agent是动态的决策主体。试图用一堆Skill拼成一个Agent简单，但要在Agent之间动态传递Skill执行权，复杂度就完全不一样了。把这两个概念分开，设计和讨论的时候会清爽很多。

5. 线上实测：跨Agent调用最常见的五个坑与排查链路

5.1 死循环调用：A调B、B调A，如何快速打断

我遇到过最尴尬的线上事故是Agent A调用Agent B，而B在处理过程中又发起调用Agent A的意图不明请求，两个Agent互相调用直到把token预算烧穿。根因是编排逻辑里缺少调用深度限制和环路检测。

排查链路是这样的：先看链路追踪日志，发现同一个task_id在两分钟内反复出现A→B、B→A的调用记录，基本可以确定是死循环。定位到代码后，发现是A的一个工具描述里写了"如果处理过程中需要额外信息，可以调用'需求澄清助手'"，而B恰好也注册了"需求澄清助手"这个名字，B为了完成任务又去调用它，恰好这个助手在实现上回指了A。

修复方案有两层。第一层是硬性限制：在CallChain里加最大调用深度，超过就抛异常并终止链路，同时加环路检测，记录本次调用链上的Agent名集合，重复出现就立刻熔断。第二层是软性治理：工具描述要写清楚"只做xx，不要调用其他Agent"，给模型明确边界。这两层缺一不可，硬限制保命，软治理保质量。

5.2 上下文污染：B拿到了A的思考过程，给出错误结论

上下文污染是跨Agent调用里最隐蔽的问题。症状是下游Agent产出结果"听起来很有道理但完全不着边际"，而且这类错误很难通过单元测试发现，因为它不是逻辑错误，是信息源错误。

我的案例是审查Agent引用了代码生成Agent思考过程中的一个假设——"这段代码目前没有性能瓶颈"——然后顺着这个假设写出了"无需优化"的审查结论。但实际情况是代码生成Agent在思考过程中提到这个假设时本来就带了一个"暂不考虑性能"的限定，审查Agent把这个上下文中的限定丢掉了。

排查思路：先对比上下游Agent的输入输出，确认B的输入里包含A的原始对话内容；然后查A的Executor是不是把完整消息历史传给了B。修复方法很直接，就是前面说的上下文隔离——B的prompt里只允许出现契约定义的输入字段。我在系统里加了一条硬编码规则：跨Agent调用时，除reasoning字段外，任何来自上游的非结构化工文本都会被拦截并告警。

5.3 超时重试导致重复执行：幂等性设计

异步消息队列方案里最常见的事故是重复执行。B执行任务花了40秒，而A设置的是30秒超时，A判定失败并重试，但第一次执行其实已经成功并把结果写入了结果队列。B最终被触发了两次，生成了两份结果，下游拿到两份一样的数据，轻则去重麻烦，重则重复扣费或执行两次有副作用的外部调用。

排查链路是看结果队列里的task_id有没有重复。修复的关键是给任务加幂等键，B在处理前先查这个任务是否已经被处理过，处理过就直接返回已有结果。这个逻辑要在B的业务逻辑之前做，不能在LLM调用之后做，因为LLM调用本身就有副作用。

另一个实用技巧是超时时间要参考任务耗时的分布来设置。先跑一段时间的基线数据，看90分位耗时，超时时间设为90分位耗时的两倍以上，而不是随便拍一个数。我见过太多系统把超时设成5秒，而下游Agent光生成本文就要15秒，这种超时形同虚设，只会制造无谓的重试。

5.4 数据契约不一致：字段变更引发连锁故障

跨Agent调用的数据契约一旦上线，每个字段就都承担了跨系统的语义责任。我遇到过一次事故：需求Agent更新了Schema，把验收标准的字段名从acceptance_criteria改成了acceptance_checklist，但代码Agent没有同步更新。代码Agent收到了新字段，按旧字段处理，结果验收标准在代码生成阶段直接丢失，生成的代码完全没有按验收标准来做。

这种问题的排查链路通常很长，因为报错发生在下游的下游，而且报错信息往往只是"缺少必要的字段"这种模糊描述。解决思路有三个层面：契约校验前置，调用链入口做JSON Schema校验，字段不符合直接拒绝而不是带病向下传；版本号协商，每次Schema变更要带版本号，下游Agent发现版本不匹配时，不是硬解析而是明确报错；线上加契约监控，用CI任务定期比对所有Agent的Schema定义，不一致就报警。

5.5 安全边界与权限收敛：最小化Agent的可见范围

跨Agent调用还有一个绕不开的安全问题：Agent可以被其他Agent调用，那它能不能随便调用别人？如果A被提示词注入，攻击者能不能通过A去调用B，再通过B调用C，形成一条绕过原本身份鉴权的攻击链？

我的处理原则是"默认最小化可见性"。每个Agent注册到注册表时，都要声明自己的可见范围：哪些Agent可以调用它、它自己允许调用哪些Agent。调用链在发起调用前先查一下双方的可调关系，不合规直接拒绝。这类似于微服务架构里的调用白名单，Agent同样需要。

另一条是鉴权信息不能随着上下文传递。A在调用B时，绝不能把自己的API Key或身份凭证夹在payload里传过去。B需要什么凭证，由B自己的环境变量或密钥托管服务来提供，A不需要也不应该知道。这个原则在单Agent时代容易被忽略，多Agent协作时代就成了底线级别的要求。

单独再补一句：给Agent系统做安全测试，一定要专门测跨Agent注入链路。方法是构造一个恶意输入，喂给流程入口Agent，看它会不会把恶意指令传播到下游，并在某个下游Agent处执行。我测出来的结果是，如果不做上下文隔离，这种跨Agent注入的成功率高得吓人，做完隔离之后基本被阻断在入口Agent那一层。

写到这里，我想把最后一次项目复盘时跟同事说的那段话再拿出来：跨Agent调用不是选一个框架就能躺平的事，它本质上是架构设计，通信协议、数据契约、执行语义、上下文边界、安全访问，哪一个环节偷懒，后面都会在线上用故障来提醒你。路线之争争到最后一地鸡毛的时候，不妨回到最原始的问题上去——你的业务到底是固定流程多一点，还是动态决策多一点；你的Agent是更多依赖自然语言协作，还是更依赖确定性数据。把这两个问题想清楚，很多架根本不用吵。

几个具体的建议，亲测有效。第一，项目第一天就把契约文件建出来，哪怕你还没想好用什么协议，Schema先定好，后面改动成本最低。第二，跨Agent调用日志一定要带链路ID，这个投入产出比极高。第三，不要一上来就搞去中心化自组织，先跑通一条中心化流水线，把问题和边界摸清，再逐步放开灵活性。我没见过哪个项目是因为开始方案太简单而失败的，倒是见过不少因为一上来就上了复杂的多Agent协作框架而拖垮进度的。