从零开始搞定AI Agent 搭建全流程

本文全面介绍AI Agent的生态，结合实践剖析，解答以下问题​

​

•

什么是真正复杂的AI Agent？​

•

如何开发复杂AI Agent？​

​

一、Agent协议​

分为 Context-Oriented (面向上下文) 和 Inter-Agent (面向 Agent 间) 两种。​

​

​

​

​

44%

​

​

​

​

56%

​

​

​

面向上下文的协议以 MCP 为代表，面向 Agent 间的协议以 A2A 为代表。​

​

1.1面向上下文协议​

​

​

​

​

60%

​

​

​

​

40%

​

​

MCP解决 Agent 如何从外部世界（数据、工具、服务）获取完成任务所需信息（上下文）的问题。​

MCP主要采用 Client - Server 架构，其核心架构主要包括以下内容：​

​

⭕

•

主机（Host）：​

​

通常是发起连接的 LLM 应用程序，如 Claude Desktop、IDE 插件等。它负责管理客户端实例和安全策略，是用户与 AI 模型进行交互的平台，同时也承担着集成外部工具、访问多样化数据资源的任务。​

​

•

客户端（Client）：​

​

是主机内的连接器，与服务器建立 1:1 会话。它负责处理协议协商和消息路由，充当主机与外部资源之间的桥梁，通过标准化的协议接口协调数据传输和指令交互，确保信息的实时性与一致性。​

​

•

服务器（Server）：​

​

是独立运行的轻量级服务，通过标准化接口提供特定功能，如文件系统访问、数据库查询等。服务器连接外部资源与 AI 模型，向 LLMs 暴露来自不同数据源的内容和信息。​

​

​

1.2面向Agent间协议：A2A​

单个 Agent 能力有限，多 Agent 协作成为趋势。面向Agent间的协议主要是为了规范 Agent 之间的沟通、发现和协作。​

​

⭕

​

1.3MCP 和 A2A 关系​

举个实际的例子使用 MCP 和使用 A2A 的都可以实现：​

​

假如 AI Agent 需要完成一个"规划 5 天深圳到厦门旅行"。​

​

​

​

​

📌

MCP：像个大总管。​

​

一个中央 Agent (MCP Travel Client) 负责调用所有外部服务（机票、酒店、天气），然后汇总信息生成计划。优点是简单可控，缺点是中心化依赖高，不易扩展。​

​

A2A：像个部门协作。​

​

任务被分配给专门的 Agent（交通、住宿、活动），这些 Agent 可以直接相互沟通（比如机票 Agent 直接问天气 Agent 获取信息），也可以和用户进行沟通（比如机票Agent完成初筛之后询问用户是否满足需求，对用户给出的建议进行迭代修改），这种方式更灵活，适合企业内复杂协作。​

​

​

​

二、Agent思考框架​

构建能够自主规划、执行和适应复杂任务的智能体，其核心在于其"思考"能力。​

​

Agent思考框架，正是为了赋予Agent这种结构化的推理和决策能力而设计的。​

​

2.1思维链（CoT）​

​

​

​

📌

一种增强大型语言模型（LLM）处理复杂推理任务能力的关键技术。​

​

其核心在于引导模型在给出最终答案前，先生成一系列结构化的中间推理步骤——这如同模拟人类解决问题时的逐步思考过程。​

通过这种方式，LLM能够更深刻地理解问题结构，有效分解复杂任务，并逐步推导出解决方案。​

​

​

50%

​

​

​

​

50%

​

​

2.2ReAct​

ReAct（Reasoning and Action）框架通过将"推理"（Reasoning）与"行动"（Action）相结合，有效地解决了这一问题。​

​

​

这种动态的交互赋予了模型一种"边思考边行动、边观察边调整"的能力，​

其核心运作机制可以概括为思考（Thought）→ 行动（Action）→ 观察（Observation）的迭代循环。​

​

📌

思考 (Thought)​

​

​

2.3Plan-and-Execute​

Plan-and-Execute 是一种对标准 ReAct 框架的扩展和优化，旨在处理更复杂、多步骤的任务。​

​

​

​

📌

它将 Agent 的工作流程明确划分为两个主要阶段：​

​

•

规划阶段：Agent 首先对接收到的复杂任务或目标进行整体分析和理解。然后，它会生成一个高层次的计划，将原始任务分解为一系列更小、更易于管理的子任务或步骤。​

•

执行阶段：计划制定完成后（可能已采纳用户意见），Agent 进入执行阶段。它会按照规划好的步骤逐一执行每个子任务。在执行每个子任务时，Agent 可以采用标准的 ReAct 循环来处理该子任务的具体细节。​

​

​

​

📌

与标准的 ReAct 相比，Plan-and-Execute 模式的主要优势在于：​

​

​

三、开发框架​

​

📌

在掌握了Agent的基本原理后，需要将这些理论转化为实际可用的代码实现。​

​

虽然开发框架并非技术瓶颈，但一个优秀的开发框架能够为提供流程编排、状态管理、工具调用等核心能力，大大加速生产级Agent应用的开发进程。​

​

​

3.1Eino​

Eino 框架由以下几个部分组成，其中Eino为核心框架逻辑。​

​

​

​

Eino框架有以下几个核心特点：​

​

📌

•

高可维护性和高可扩展性并存​

​

3.2组件（Component）​

组件是大模型应用能力的提供者，提供原子能力的最小单元，是构建AI Agent的砖和瓦，组件抽象的优劣决定了大模型应用开发的复杂度。​

​

📌

Eino 的组件抽象秉持着以下设计原则：​

​

常用的组件类型可以大致分成一下对话处理类组件、文本语义处理类组件、决策执行类组件和自定义组件这几类。​

​

3.3对话处理类组件​

ChatTemplate​

​

模板化处理和大模型交互参数的组件抽象。​

主要作用是将用户提供的变量值填充到预定义的消息模板中，生成用于与语言模型交互的标准消息格式。​

例如结构化的System Prompt、多轮对话模板等场景。​

​

​

​

​

ChatModel​

​

直接和大模型交互的组件抽象，它的主要作用是将用户的输入消息发送给语言模型，并获取模型的响应。​

提供了非流式的Generate和流式的Stream方法获取大模型输出内容。​

​

​

代码块​

Go

type BaseChatModel interface {​

Generate(ctx context.Context, input []*schema.Message, opts ...Option) (*schema.Message, error)​

Stream(ctx context.Context, input []*schema.Message, opts ...Option) (​

*schema.StreamReader[*schema.Message], error)​

}​

​

​

​

3.4文本语义处理类组件​

Document.Loader、Document.Transformer​

​

主要用于获取和处理文本文档，从不同来源（如网络 URL、本地文件等）加载文档内容，并将其转换为标准的文档格式。​

​

​

代码块​

Go

​

​

Embedding​

​

将文本转换为向量表示,它的主要作用是将文本内容映射到向量空间，使得语义相似的文本在向量空间中的距离较近。一般用于语义检索场景。​

​

​

代码块​

Python

type Embedder interface {​

EmbedStrings(ctx context.Context, texts []string, opts ...Option) ([][]float64, error)​

}​

​

​

Indexer​

​

存储和索引文档的组件。它的主要作用是将文档及其向量表示存储到后端存储系统中，并提供高效的检索能力。主要用于构建向量数据库。​

​

​

​

代码块​

Python

type Indexer interface {​

Store(ctx context.Context, docs []*schema.Document, opts ...Option) (ids []string, err error)​

}​

​

​

Retriever​

​

从各种数据源检索文档的组件。它的主要作用是根据用户的查询（query）从文档库中检索出最相关的文档，主要用于RAG场景。​

​

​

​

代码块​

Python

type Retriever interface {​

Retrieve(ctx context.Context, query string, opts ...Option) ([]*schema.Document, error)​

}​

​

​

3.5决策执行类组件​

ToolsNode​

​

是一个用于扩展模型能力的组件，它允许模型调用外部工具来完成特定的任务。​

​

​

代码块​

Go

// 基础工具接口，提供工具信息​

type BaseTool interface {​

​

​

四、自定义组件​

​

📌

Lambda​

​

Lambda 组件底层是由输入输出是否流所形成的 4 种运行函数组成，对应 4 种交互模式。​

也是流式编程范式: Invoke、Collect、Transform。​

​

​

​

代码块​

Go

type Invoke[I, O, TOption any] func(ctx context.Context, input I, opts ...TOption) (output O, err error)​

type Stream[I, O, TOption any] func(ctx context.Context, input I, opts ...TOption) (output *schema.StreamReader[O], err error)​

type Collect[I, O, TOption any] func(ctx context.Context, input *schema.StreamReader[I], opts ...TOption) (output O, err error)​

type Transform[I, O, TOption any] func(ctx context.Context, input *schema.StreamReader[I], opts ...TOption) (output *schema.StreamReader[O], err error)​

​

4.1编排（Compose）​

​

📌

Eino提出了基于有向图（Graph）模型的编排解决方案。​

​

每个节点承担特定职责，节点间以上下游数据类型对齐为基本准则，实现类型安全的数据传递。​

​

​

从以下几个维度对比了使用Eino编排框架与传统开发的优势：​

​

​

​

4.2Graph：运行图​

以一个简单的查询天气的例子介绍如何使用图编排​

​

​

​

代码块​

Go

func main() {​

ctx := context.Background()​

// 创建运行图​

g := compose.NewGraph[map[string]any, *schema.Message](​

compose.WithGenLocalState(func(ctx context.Context) *state {​

return &state{}​

}))​

// Prompt模板​

promptTemplate := prompt.FromMessages(​

schema.FString,​

schema.SystemMessage("你是一个智能助手，请帮我解决以下问题。"),​

​

​

4.3Callbacks：切面​

Callback有以下几个触发时机，分别对应了Handler里边的回调方法：​

​

代码块​

Java

​

​

​

​

​

​

58%

​

​

​

Eino通过数据复制的方式。​

保证了在Callbacks的处理过程中数据流的并发安全性。​

每个Handler都能消费到一份独立的数据流。​

​

42%

​

​

​

4.4Checkpoint：检查点​

Human In The Loop（HITL）是一种让人类用户能够实时参与和干预AI Agent执行过程的机制。​

​

HITL可以实现以下重要功能：​

​

📌

•

质量审核​

​

在人机协同工作中，用户可以在重要决策节点实时干预，例如审核AI生成的内容、修改推荐结果等，确保关键任务（如数据库敏感数据、运维操作等）的准确性和安全性。​

​

​

​

Eino框架通过Checkpoint（检查点）机制优雅地实现了Human In The Loop的能力。​

​

​

​

以下展示使用CheckPoint的能力实现Human In The Loop的效果：​

​

代码块​

Go

func main() {​

_ = compose.RegisterSerializableType[myState]("state")​

ctx := context.Background()​

g := compose.NewGraph[map[string]any, *schema.Message](​

compose.WithGenLocalState(​

func(ctx context.Context) *myState {​

return &myState{}​

},​

​

​

五、tRPC-A2A-Go​

在实际的多智能体系统开发中，将 Agent 封装为支持 A2A 协议的服务具有诸多优势。​

​

📌

tRPC-A2A-Go 框架为开发者提供了完整的 A2A 协议客户端和服务端实现.​

​

帮助开发者快速将 Agent 封装为标准的 A2A 服务，兼容主流的智能体生态，显著降低了多Agent协同系统集成和运维的难度。​

​

​

​

​

​

5.1A2A Server​

​

📌

将Eino框架的Agent使用A2A协议对外提供服务有以下几个步骤：​

​

​

完成AgentCard描述Agent的能力，创建A2A Server​

​

代码块​

Go

func NewA2AServer(agent *Agent) (*server.A2AServer, error) {​

var err error​

agentCard := getAgentCard() // 按照A2A协议标准生成AgentCard，描述Agent能力​

redisCli, err := tgoredis.New("trpc.redis.deepresearch")​

if err != nil {​

return nil, fmt.Errorf("failed to create redis client: %w", err)​

}​

// 创建基于Redis的任务管理器​

​

将A2A Server注册到tRPC服务上，并启动服务​

​

代码块​

Go

func main() {​

s := trpc.NewServer()​

agt, err := deepresearch.NewAgent()​

if err != nil {​

log.Fatal(err)​

}​

​

​

5.2A2A Client​

创建一个A2A客户端使用A2A协议向Agent发起任务分为以下几个步骤：​

①创建A2A客户端​

​

代码块​

Python

// 客户端​

a2aClient, err := a2aclient.NewA2AClient(agentConfig.ServerURL, a2aclient.WithTimeout(time.Minute*10))​

​

②调用StreamTask发起流式任务​

​

代码块​

Python

taskChan, err := a2aClient.StreamTask(c, protocol.SendTaskParams{​

ID: taskID,​

Message: initMessage,​

})​

​

③流式处理任务执行结果​

​

代码块​

Go

for v := range taskChan {​

switch event := v.(type) {​

​

​

六、从零开发多Agent协同系统​

接下来，将结合实际Demo，从整体架构到核心模块的实现，完整展现一个多Agent协同系统的开发过程。​

​

​

6.1Agent设计​

下面以Demo中的几个典型Agent为例，详细介绍设计思路与实现方式，基于Eino框架快速落地多智能体协作系统。​

6.2旅行规划​

​

​

​

旅行规划 Agent 使用经典的 ReAct 框架实现。主要集成了高德地图 MCP 能力，实现了路线规划、交通方式推荐、实时路况查询等功能，以及 Tavily 进行 AI 搜索，能够检索目的地的景点介绍、游玩攻略、美食推荐等内容。在此之上，通过增加了Lambda:user_input节点等待用户下一轮对于行程规划的建议和追问。​

6.3深度搜索​

​

​

​

深度搜索 Agent 利用大模型对复杂问题进行多角度分析，边推理边搜索。在执行流程内部，通过ChatModel:think进行问题分析，并判断上下文的资料是否足够回答用户问题，如果不够那么输出关键词借助搜索工具获取资料补充上下文，如果足够，通过ChatModel:summary模型，输出对于问题的分析总结报告。​

6.4意图识别​

​

​

​

​

📌

这种设计让意图识别Agent具备了高度的灵活性和可扩展性。​

​

•

一方面，它能够根据用户需求动态选择并对接不同类型的下游专家Agent，实现多智能体间的高效协作与任务流转；​

•

另一方面，专家Agent采用标准化A2A协议进行封装，具备天然的可插拔能力，通过AgentCard描述能力让意图识别Agent进行判断当前的任务类型，支持在系统运行时无缝添加、替换或扩展新的专家Agent。​

​

​

​

​

6.5连接生态​

Connector是A2A多Agent系统实现"能力复用"和"生态扩展"的关键。​

​

它的核心目标是将标准化的Agent能力，通过协议适配、接口封装等方式，快速对接到不同的外部平台和应用场景，实现"写一次，处处可用"。​

​

​

📌

•

解耦​

​

Agent本身只关注业务逻辑和A2A协议实现，不直接依赖于任何具体平台。Connector负责协议转换、消息编解码、上下游适配，最大程度降低Agent与外部生态的耦合度。​

​

•

标准​

​

所有对接均基于A2A协议的标准输入输出格式，保证能力的可组合性和可迁移性。无论是对接IM、Web、App还是第三方API，均通过统一的协议层进行交互。​

​

•

可扩展​

​

Connector采用插件化、模块化设计，支持按需扩展新的平台适配器。只需实现对应的适配接口，即可将Agent能力无缝接入新的生态系统。​

​

​

​

6.6接入Cherry Studio​

​

​

​

​

📌

通过实现 OpenAI 兼容的 Connector，将 Agent 能力以标准 chat/completion 协议对外暴露，可以直接在 Cherry Studio 客户端中便捷地接入和调试 Agent，实时体验其交互效果与能力表现，极大提升了开发和测试的效率与直观性。​

​

​

实现chat/completion接口，获取model作为Agent名字，调用A2AServer，将任务执行结果，使用SSE协议流式输出到chat/completion响应里​

​

代码块​

Go

func (s *Server) chatHandler(c *gin.Context) {​

var req api.ChatRequest​

if err := c.ShouldBindJSON(&req); errors.Is(err, io.EOF) {​

c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "missing request body"})​

return​

} else if err != nil {​

c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": err.Error()})​

​

​

配置Cherry Studio模型，连接 connector 服务​

​

​

​

6.7Agent观测​

数据看板：通过Dashboard，可以实时查看LLM应用的质量、成本、延迟等多维度指标，全面监控和分析智能体系统的运行状态。​

​

​

八、总结​

以上系统梳理了 AI Agent 的核心理念、主流协议（MCP、A2A）、思考框架（CoT、ReAct、Plan-and-Execute），并结合 Golang 生态下的 Eino、tRPC-A2A-Go 等工程化框架，结合实际例子详细讲解了如何优雅地开发、编排和观测复杂的智能体系统。​

​

•

协议标准化是 Agent 生态的基础：​

​

MCP、A2A 等协议的出现，极大降低了工具和 Agent 的集成门槛，让"能力复用"成为可能。未来，协议的进一步融合和演进，将推动智能体生态走向真正的互联互通。​

​

​

•

思考框架决定 Agent 的智能上限：​

​

从 CoT 到 ReAct，再到 Plan-and-Execute，结构化的推理与行动流程，是 Agent 胜任复杂任务的关键。合理选择和实现思考框架，是打造高鲁棒性、高可解释性 Agent 的核心。​

​

​

•

工程化框架让复杂 Agent 开发变得高效：​

​

Eino、tRPC-A2A-Go 等框架，通过组件化、强类型、编排与切面机制，极大提升了开发效率和系统可维护性。无论是单体智能体，还是多 Agent 协作，都能快速落地生产级应用。​

​

​

•

可观测与人机协同是生产级 Agent 的基础能力：​

​

只有让 Agent 的推理过程、工具调用、任务状态对用户和开发者透明，实现高质量的交付和持续优化。Human In The Loop 机制，则为关键场景下的安全性和可控性提供了保障。​

​

​

•

选择适合自身场景的协议与框架：​

​

没有万能的协议和框架，只有最适合当前业务和团队的技术选型。理解协议的边界、框架的能力，结合实际需求做出权衡，才能真正发挥 AI Agent 的价值。​

​

​