跨Agent调用实战：四种技术路线与避坑指南

如果你最近在做Agent开发，大概率已经意识到一个问题：单个Agent再强，也扛不住所有事。我自己在搭Agent项目的时候，第一个撞上的墙不是模型能力不够，而是怎么让两个Agent互相配合。你说让一个Agent既懂日志排查、又会网络诊断、还要能写回复工单，模型上下文塞满不说，工具列表乱到连LLM自己都开始瞎选。跨Agent调用就是在这种背景下被反复讨论的解法，同时伴随着的还有各种技术路线之间的争论。这篇内容我会把跨Agent调用的几种主流实现方式、实操代码、以及目前路线之争的核心分歧一次聊透，适合正在做Agent开发、或者在团队里负责评估多Agent架构的同学。

多说一句，这不是纯理论文章。下面所有代码和结论，都来自我最近在真实项目里反复试错后的沉淀。你照着抄能跑，踩坑点也会给你标出来。

1. 为什么说跨Agent调用是Agent开发绕不开的坎

1.1 单体Agent的失控：工具、上下文、权限三座大山

先聊一个我实际遇到的场景。早前我图省事，把IT运维助手做成了一个单体Agent，工具列表里挂了日志查询、指标分析、告警推送、网络检测、工单创建等十几个工具。刚开始模型还能勉强分辨该调哪个，但随着工具描述越来越长，问题开始冒头。

首先是上下文爆炸。每轮对话都要把工具描述塞给模型，十几个工具的描述加起来上千token，真正的用户诉求反而被挤到后面。其次是工具误选率上升。当两个工具的功能边界模糊，比如“日志查询”和“指标分析”，模型经常选错。最麻烦的是权限，一个Agent同时持有读日志、写工单、发通知的权限，一旦被prompt注入或者误操作，影响面非常大。

拆成多个Agent之后，上面三个问题会自然缓解。每个Agent只负责一块小领域，工具描述短、上下文清爽、权限可以按Agent细粒度划分。但拆开之后就出现新问题：A Agent需要B Agent的产出才能继续干活，这时候跨Agent调用就不可避免了。

1.2 什么是跨Agent调用：一句话版本

跨Agent调用，就是允许一个Agent去请求另一个Agent的计算能力或结论。整体逻辑跟微服务很相似，服务A调用服务B的接口拿数据，只不过这里“服务”变成了“Agent”，参数和返回值从结构化JSON变成了自然语言、半结构化结果、甚至是一段执行计划。

拿做饭类比，单Agent就像一个人又要洗菜又要切菜又要炒菜还要摆盘，跨Agent调用就像后厨分工：洗菜Agent把净菜交给切菜Agent，切好的食材再传给炒菜Agent，每个环节只认自己负责的那一小块标准接口。

不过后厨传菜靠的是盘子，Agent之间传的是什么、怎么传、谁来定这个“盘子”的标准，正是当下主线之争的核心。

1.3 谁最需要关心跨Agent调用

如果你只是写个单轮对话机器人，跨Agent调用确实跟你没关系。但只要你开始做复杂任务拆解、或者想构建一个可靠的自动化工作流，这个问题就躲不掉。

具体分几类：

• 做Agent开发的，需要把复杂任务拆成多个子Agent协作，比如客服系统、数据分析平台。
• 做Agent框架与编排的，需要选择合适的调用协议和调度方式，比如在LangGraph、自研Workflow之间做选型。
• 做Agent安全的，跨Agent调用意味着信任边界从单进程扩展到网络，一旦调用链路被攻击，影响范围是面状的。
• 使用Agent平台的，也需要理解平台底层的Agent互调逻辑，便于排查任务执行中断类问题。

我甚至看到不少人面试Agent相关的岗位，最后都会被问到“多个Agent之间怎么通信”。这个问题背后考察的，就是你对跨Agent调用技术路线的理解深度。

2. 跨Agent调用的四种技术路线与选型思路

先说结论：现在行业里所谓的路线之争，核心分歧在于“Agent之间的协作到底应该像函数调用一样严格，还是像人类团队一样松散”。围绕这个分歧，我把它拆成四条路线，每条都有自己的道理，也各有明显的短板。

2.1 路线一：把子Agent封装成工具函数，主Agent统一调度

这是目前最简单、也最流行的一条路线。思路很直白：子Agent对外只暴露一个类似函数的接口，包含名称、描述、入参Schema、返回值格式，主Agent通过Function Calling机制去调用它。

具体执行的时候，主Agent先规划要不要调用这个“函数”，LLM返回一个结构化调用请求，然后运行时把请求转发给子Agent，得到结果后塞回主模型的上下文里，继续下一步推理。

我为什么首先推荐这条路线？因为它是四条路线里最可控的。调用链是显式的父子关系，主Agent拥有绝对决策权，子Agent的“主动性”被压到最低。对于客服工单、数据处理这类确定性强的场景，这种控制模式非常适合，出了问题也容易定位。

但它的局限同样明显。子Agent永远处于被动响应状态，无法主动汇报、无法跨级协作。你很难用它搭建对等的多Agent协作网络，一旦需要多级嵌套，主Agent的上下文会被反复撑大，整个系统可能退化成一个超级Agent套壳。

2.2 路线二：通过MCP和A2A协议实现Agent互调

协议派的人在回答跨Agent调用时，会直接给你看两套东西：MCP和A2A。

MCP全称是Model Context Protocol，它解决的原始问题是让Agent更方便地访问外部数据源和工具，而不是Agent与Agent之间对话。但在实践中，很多人会把子Agent的能力包成一个MCP Server，主Agent作为MCP Client去发现和调用这些能力。这种方式的好处是工具接入标准化了，换掉底层模型也不影响工具侧。

A2A则是Agent到Agent之间的通信协议，思路更接近“对等协作”。A2A引入了AgentCard的概念，每个Agent公布自己的能力描述和接入地址，其他Agent通过标准HTTP端点发现能力并提交任务。它支持流式事件、任务状态回传、人机协作确认等机制，比单纯把Agent当函数调用更进一步。

这两套协议前者偏工具标准化，后者偏Agent间任务编排。目前生态还在早期，A2A更是刚起步，很多工具库还不完善，我建议先观察再投入，但它们的思路一定会影响后续Agent互调的方向。

2.3 路线三：用编排引擎把Agent编成流程图

如果你对可靠性要求极高，那么编排引擎路线更值得考虑。这派思路是把Agent当成工作流里的一个节点，节点之间的调用关系由引擎在代码层面显式定义。LangGraph就是这类框架的代表，它还支持子图嵌套，本质上就是一种跨Agent调用的结构化管理方式。

在这个模式下，跨Agent调用不再依赖大模型临场“灵机一动”决定要不要调，而是预先设计好拓扑：第一步调A，A的输出满足条件就走B，不满足就走C。这样做的好处是执行路径可预测、可单测、可回放，适合金融风控、运维巡检这类要求结果稳定的场景。

代价就是灵活度相对低。工作流画得越细，越像以前的BPM流程引擎，Agent的“智能感”会被流程逻辑稀释。我在项目中遇到的情况是，一旦任务形态频繁变化，维护那张流程图的成本会比维护Agent本身还高。

2.4 路线四：事件驱动架构，让Agent异步协作

还有一类团队，尤其是处理高并发或长耗时任务的，会把Agent之间解耦成事件流。子Agent订阅消息队列里的任务，处理完发一个完成事件，下游Agent收到事件后再继续。中间可以接RabbitMQ、Kafka、Redis Stream这类中间件。

这条路线最大的优点是完全松耦合，Agent不需要知道谁在上游、谁在下游，新增一个Agent只需订阅对应事件。适合批量数据处理、异步审批流、大规模任务分发等场景。

它的弱点也相当突出：链路难追踪，调试靠补日志；事件丢失或重复消费会把状态搞乱；Agent之间的即时交互体验做不出来。更关键的是，事件消息里塞自然语言结果还是结构化结果，经常成为团队吵架的导火索。

2.5 四条路线怎么选，看这张对比表

现实项目里这四种不是非此即彼，我自己会混合使用：外层采用编排引擎保证主干稳定，内部节点用Function Calling调用具体Agent，变化较快的调研类任务则走事件异步。

3. 实操落地：我手写三种方式实现跨Agent调用

光说路线容易飘，下面我拿一个具体场景，把三种主流方式都实操一遍。我的项目背景是一个IT工单智能处理系统：用户报障后，主Agent要先调用日志分析子Agent看异常、再调用网络诊断子Agent排查链路、最后调用工单回复子Agent生成答复，整个流程模拟跨Agent调用。代码做了简化，但关键细节都保留。

3.1 场景设定：一个IT工单处理的多Agent系统

先定义子Agent返回的数据结构。因为后面所有调用方式都依赖这个契约，最好从一开始就把字段定清楚：

@dataclass class AgentResult: agent_name: str status: str # success / failed / need_more_info summary: str details: dict confidence: float

我强烈建议所有子Agent返回的summary控制在200个字符以内，details里放结构化的机器可读信息。原因后面说，这里先记住：summary是给主Agent的LLM看的关键内容，details是给程序逻辑用的。

3.2 方式一：Function Calling 封装子Agent，10分钟搞定

这是最快的方案。把子Agent注册成主模型的一个tool，模型根据对话内容决定何时触发。以OpenAI风格的Function Calling为例，先定义工具Schema：

{ "type": "function", "function": { "name": "log_analysis_agent", "description": "分析服务器日志并返回异常摘要，适用于排障场景", "parameters": { "type": "object", "properties": { "service_name": {"type": "string", "description": "服务名"}, "time_range": {"type": "string", "description": "时间范围，如 2024-01-01T00:00:00+08:00/2024-01-01T00:30:00+08:00"} }, "required": ["service_name"] } } }

然后主Agent侧通过一个简单的循环来执行调用：

import json from openai import OpenAI client = OpenAI(api_key="sk-xxx", base_url="http://localhost:8000/v1") messages = [{"role": "user", "content": "帮我查一下订单服务最近30分钟有没有异常"}] tools = [get_log_analysis_tool_schema()] for step in range(5): # 安全迭代上限 resp = client.chat.completions.create( model="qwen-max", messages=messages, tools=tools, tool_choice="auto" ) msg = resp.choices[0].message messages.append(msg) if msg.tool_calls: for tc in msg.tool_calls: args = json.loads(tc.function.arguments) tool_result = run_sub_agent(tc.function.name, args) # 这里触发子Agent messages.append({ "role": "tool", "tool_call_id": tc.id, "content": json.dumps(tool_result, ensure_ascii=False) }) else: print("最终回复：", msg.content) break

跑起来你会发现几个坑。第一，run_sub_agent这一步必须设置超时和错误捕获，否则子Agent内部报错会让整个主流程直接挂掉。第二，工具描述里的参数说明非常关键，写“service_name”而不是“服务名”会让模型误填更多噪声。第三，我在循环里加了5次上限，防止模型陷入工具调用死循环。

3.3 方式二：把子Agent独立成HTTP服务

如果子Agent要独立部署，或者需要被多个上游调用，把它变成HTTP服务更合适。我这边用的是FastAPI加SSE流式返回，子Agent一边执行一边吐结果，主Agent实时就能看到进度，比干等更友好。

子Agent侧的核心接口可以这样写：

from fastapi import FastAPI from fastapi.responses import StreamingResponse from pydantic import BaseModel app = FastAPI() class TaskRequest(BaseModel): task_id: str input_text: str trace_id: str @app.post("/agent/log_analysis") async def run_log_analysis(req: TaskRequest): async def gen(): yield f"data: {json.dumps({'type': 'status', 'message': 'started'})}\n\n" result = await analyze_log(req.input_text) yield f"data: {json.dumps({'type': 'result', 'result': result})}\n\n" return StreamingResponse(gen(), media_type="text/event-stream")

主Agent侧，我用httpx做异步调用，然后按SSE格式解析流式数据：

import httpx async def call_sub_agent(url: str, payload: dict, timeout: float = 30.0): async with httpx.AsyncClient(timeout=timeout) as client: async with client.stream("POST", url, json=payload) as resp: result = None async for line in resp.aiter_lines(): if line.startswith("data:"): event = json.loads(line[5:]) if event["type"] == "result": result = event["result"] break return result

这个方案最大的价值是部署解耦，子Agent可以由不同团队维护，技术栈也不要求完全一致。只要HTTP契约稳定，谁调用谁都行。我实际踩过的坑是SSE连接容易因为代理超时断开，所以在生产环境我会在前置网关把这类路径的超时时间调到60秒以上，并且主Agent侧必须有超时重试。

3.4 方式三：把子Agent包装成MCP Server

如果你更看重标准协议，MCP是当前最值得投入的方向。用Python的mcp库，把子Agent能力暴露为标准tool并不复杂。下面是经过我简化的关键代码：

from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent app = Server("log-analysis-agent") @app.list_tools() async def list_tools(): return [ Tool( name="analyze_service_logs", description="分析指定服务在指定时间窗口内的日志，返回异常片段和可能的根因", inputSchema={ "type": "object", "properties": { "service_name": {"type": "string"}, "time_range": {"type": "string"} }, "required": ["service_name"] } ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): result = await analyze_main(arguments["service_name"], arguments.get("time_range")) return [TextContent(type="text", text=result.summary)]

在主Agent侧，用MCP Client连接这个Server后，就能像调用普通MCP工具一样调用子Agent能力。整个过程里你需要额外处理stdin/stdout的传输层，我在小项目里直接用了官方的stdio_server，部署上比较轻量。

MCP的好处在于生态兼容性。同一个子Agent能力封装成MCP Server后，理论上任何支持MCP的Agent客户端都可以接入，不用为每个上游单独定制协议。不过MCP目前对长任务、流式输出的支持还在演进，如果你的子Agent执行时间动辄几分钟，用MCP做同步调用会等得很痛苦，建议配合回调或任务ID轮询。

3.5 上下文怎么传给子Agent，这里有个容易翻车的细节

跨Agent调用和普通API调用最大的区别在于：入参和出参都是自然语言，而自然语言的可压缩性非常差。把主Agent的整段历史对话全量传给子Agent，看起来信息最完整，实际会导致两个问题。

第一是token成本爆炸。调用链路每深一层，上下文就会指数级放大。第二是噪声干扰，子Agent并不需要知道用户当初是怎么抱怨的，它只需要知道服务名、时间范围和“帮我查异常”这个意图。

我的做法是维护一个“上下文契约”，每次跨Agent调用前，由主Agent把会话压缩成一个结构化摘要，只保留任务目标、关键参数、已完成步骤。这个摘要我控制在300~500字之间。如果你发现自己摘要完了子Agent还是答非所问，往往是摘要时丢失了关键上下文，这时候要回头检查摘要模板，而不是简单加长摘要。

另一个必须加的东西是trace_id。无论走HTTP、MCP还是Function Calling，我要求所有子Agent在入参里带上trace_id，在日志和返回结果里带上trace_id。没有链路ID，多Agent系统的排障会变成灾难，后面我会专门讲这个问题。

4. 路线之争：工具派、协议派、编排派谁会成为主流

技术从来不单纯靠“谁更好”来胜出。跨Agent调用这轮路线之争，本质上三方对Agent的定位、对智能的理解、对商业形态的押注都不同。

4.1 工具派的核心逻辑：Agent就是高级函数

工具派认为，Agent没必要拥有对等的“人格化协作”，所有Agent本质上就是被更高层智能调用的工具函数。你给子Agent配了模型、记忆、工具，但它依然是个黑盒服务，调用方只需要定义输入输出。

这个逻辑的好处是全局可控，而且工程上完全复用现有微服务体系，团队上手成本低。很多企业内部的Agent平台都在走这条路，因为老板关心的是流程能不能被审计，而不是Agent之间聊得开不开心。

但这一派有个根本短板：跨Agent能力的组合缺少涌现性。当主Agent把一切都当成函数调用时，它很难容忍子Agent“临时冒出个新需求”。Agent之间无法形成真正的动态协商，系统只能解决预定义好的问题。

4.2 协议派的核心逻辑：标准化才能规模化

协议派说的是，单点方案做得再好，没有标准就没法规模化。只有MCP、A2A这类协议真正成熟，Agent之间才能像今天的Web服务一样即插即用。到时候一个Agent可以动态发现另一个Agent的能力，跨组织协作就像现在的API市场一样简单。

我认可这条逻辑，因为互联网行业已经用历史证明了标准协议对产业生态的巨大推动力。但协议派面前有座大山：现在的Agent协议标准远不止一个，A2A、MCP、各家私有协议都在抢地盘，连Agent服务发现、任务描述格式这些基础问题都还没有统一。协议迭代速度能不能跟上模型能力迭代，是很大的未知数。

4.3 编排派的核心逻辑：可靠性优先于智能

编排派更接近传统企业软件工程师的思维方式：Agent再智能，也只是流程里的执行节点，流程的正确性必须先被证明，然后才谈智能优化。用LangGraph这类工具把调用关系显式画出来，配上状态管理和人机确认节点，系统是可靠可控的。

这个路线的劣势是，一旦任务场景变化快，流程维护成本会反噬前面的“可靠性”。我自己在项目中就被流程版本迭代折腾过：需求一变，流程图改一版，状态定义改一版，回归测试还要再跑一遍，整体节奏远没有纯动态调用灵活。

4.4 我的判断：这场路线之争短期内不会收敛

原因有三个。第一，Agent还远没到技术收敛期，模型能力每隔几个月就会变化一次，好比地基还没打好，标准协议很难定下来。第二，不同场景的需求差异太大：金融风控要的是可控和审计，创意工作流要的是灵活和探索，工具派和编排派各占一头，谁也无法覆盖全部。第三，商业利益牵扯太重，每个平台都想把自己定义为“其他Agent的调度中枢”，都希望自己是规则的制定者。

我给你的建议是：不要赌未来哪个路线一定赢，而是先选一个当前场景里最合适、并且留有抽象边界的方案落地。今天我可以在Function Calling之上加一层编排引擎，明天也可以把它换成A2A客户端，关键在调用层要隔离好。

5. 跨Agent调用高频问题排查与避坑记录

跨Agent调用方的好处之一是“什么都是玄学”，坏处也一样。因为中间隔了模型推理，排障思路和传统API完全不一样。下面这些问题都是我从真实项目中积累的，照着排查效率会高很多。

5.1 子Agent执行中途报错的排查步骤

你在Agent开发里一定见过这类错误，类似“agent execution terminated due to error.”，出现在子Agent执行中，但没有任何堆栈信息。我第一次遇到时也懵了半小时，后来总结出标准排查顺序：

有些框架会在错误信息里带内部error code，先检索这个code的官方文档，大概率能直接命中问题。如果是自定义Agent，建议在子Agent外层捕获所有例外，把标准错误映射成一个统一格式的错误结构返回给上游，避免LLM自由发挥把错误描述得五花八门。

5.2 调用链上的记忆丢失和上下文爆炸

跨Agent调用的记忆问题非常陈旧，但至今没有银弹。记忆分两块：参数记忆和结论记忆。参数记忆指的是任务执行到一半时，主Agent需要的中间参数，必须显式保存，不能只靠LLM自己记得。结论记忆则是指子Agent产出的结论要不要缓存在专门的记忆层，避免下次再执行一遍。

我踩过的坑是：子Agent执行完返回summary时，因为summary写得不够结构化，主Agent后续引用时出现幻觉，把结果记错了。所以前面我才强调summary要控制在200字内、details要结构化。这不仅是节省token，更是为了保证后续链路引用时的精确度。

如果你用的是LangGraph这类框架，可以在节点级别定义状态schema，把跨Agent传递的数据类型固定下来，这样每个节点都能从state里读取必要字段，记忆丢失问题会好很多。

5.3 两个Agent互相调用导致死循环

这个问题的触发方式比想象中容易：Agent A在遇到不确定信息时，会调用Agent B去确认；Agent B发现自己也缺信息，又回过头来问Agent A。两边模型一旦进入这种循环，资源就被吃光，日志里全是你调用我、我调用你的记录。

我的处理手段有三种，通常会一起用：

• 每个调用请求带上max_depth，子Agent转发调用时深度+1，超过阈值直接拒绝并返回“请人工介入”。
• 全局维护一个调用痕集合，如果同一个trace_id下出现了重复的（caller, callee）对，立即中断并告警。
• 在提示词里写明“如果你没有足够信息，直接说明缺少什么，不要调用其他Agent来追问”。

这三种手段可以覆盖大部分死循环场景。剩下的一小部分，靠超时机制保底。

5.4 跨Agent调用的权限边界怎么划

单体Agent时代，权限模型围绕用户设计。跨Agent调用之后，问题变得微妙：主Agent拥有用户授权，它调用子Agent时，子Agent是否天然继承这个授权？我见过很多项目直接让子Agent用同一个服务账号，结果任何一个子Agent被注入恶意指令，都能拿到整个系统的读写权限。

我的建议是采用最小权限继承。主Agent调用子Agent时，在请求里显式声明授权范围，比如“只读日志，不写工单”，子Agent执行前先校验权限声明，不允许执行超出范围的工具。同时把敏感操作单独拆成“需要人工确认”的能力，跨Agent调用触发敏感操作时，返还给主Agent走人机确认节点。

5.5 大家都在做链式追踪，我先落地了一版简易方案

正式的Agent可观测性平台可能需要不少成本，但如果只是自用，你可以用日志加trace_id快速搭一版。规则很简单：每个跨Agent调用入口生成trace_id，以日志形式记录每个Agent的入参、出参、耗时、错误码，集中采集后按trace_id串联起来。

我之前用纯文本日志都能排查80%的调用异常。记录格式长这样：

2025-06-01 10:22:33.123 [TRACE=7ab01] [AGENT=coordinator] [CALL=log_analysis] input="service=order-service time=last30min" 2025-06-01 10:22:34.001 [TRACE=7ab01] [AGENT=log_analysis] [CALL=query_logs] ok latency=230ms 2025-06-01 10:22:34.876 [TRACE=7ab01] [AGENT=log_analysis] result="status=success summary=found 3 error entries"

后期如果规模上来了，再去接专门的trace系统，协议侧的trace_id可以无缝衔接。记住，跨Agent调用排查第一原则：没有链路ID，就不要谈排障。

6. 关于路线之争，我目前的取舍与个人体会

在跨Agent调用这个问题上，我目前的做法是：项目主干用编排引擎兜底，保证关键业务路径的可控和可测试；内部探索性环节用Function Calling做动态调用，让模型有自由发挥的空间；同时对MCP、A2A保持跟进，但不会把核心链路押在尚未成熟的协议上。这个组合不一定最优，但对我这种既要稳定又要灵活的小团队来说，是试错成本最低的状态。

我个人还有个小体会：跨Agent调用能不能做好，技术选型只占三成，剩下七成都在约定规范。包括每个Agent的输入输出契约、错误码体系、上下文摘要格式、trace_id强制使用规则。这些规范看起来很土，但它们才是多Agent系统能不能长期演进的基础。你先跟团队把Agent之间的契约文档写清楚，再去纠结用MCP还是A2A，会顺手很多。