004.Agentic Design Patterns ｜ 以ADK为例
Agent 开发流程，本质上是将用户的原始意图转化为机器可执行的上下文，并送入 Transformer 模型进行处理。这个过程不是一次性完成的，而是通过“感知 → 规划 → 行动”的循环迭代实现的：
- 分解请求：将用户的复杂请求拆解为可执行的子任务，明确每个子任务的目标和边界
- 构建上下文：Agent 主动从 Web、知识库、API 等外部数据源获取实时和历史信息，将非结构化数据进行提炼和格式化，形成对 LLM 高效可读的输入
- 模型推理：
- 将系统指令、工具定义以及构建好的上下文作为完整的 Prompt 块输入 Transformer Decoder
- Decoder 根据已有 token（上下文）预测下一个最可能的 token；
- 这一 token-by-token 的生成过程，就是 Agent 在「思考、规划、执行」的连续推理。
- 执行与反馈：将模型输出转化为具体行动（调用工具、发请求等），并根据执行结果更新上下文，进入下一轮推理。
可以把它理解为：
Agent 是一个围绕 Transformer Decoder 构建的循环系统。
每次循环中，Decoder 都在根据当前世界状态（上下文）一步步生成下一个最优行动，从而实现“思考—行动—反馈”的动态优化。
Function call
工具调用是 Agent 执行“行动”的关键，它将 LLM 的决策转化为对外部资源的实际操作：
- Agent (LLM) 决策： LLM 识别问题语义并根据工具描述，输出 function_call，决定调用哪个工具。
- Runtime 执行： ADK 框架的 Runtime 层面负责执行该工具（将工具名称和参数送给底层系统）。
- 结果返回： Runtime 将工具的执行结果（tool response）返回给 Agent (LLM)，Agent 根据这一结果继续生成最终回答。
User → Agent (LLM) → Runtime(执行工具) → Agent(继续生成回答)
MCP
MCP 是一种让 LLM Agent 通过标准协议安全地访问外部工具和数据源的中间层。 它把模型与外部系统解耦，让 Agent 能像调用本地函数一样使用外部资源
MCP Client 与 MCP Server 的通讯过程
- 能力发现：MCP Client 代表 LLM 向 MCP Server 查询其可用能力，MCP server 返回可调用工具清单
- 请求生成：LLM 选择合适的工具（如 get_weather），并生成包含必要参数（如 city）的调用请求
- 请求发送：MCP Client 将该请求按标准协议发送至对应的 MCP Server
- 请求执行：MCP Server 验证身份与请求合法性后，调用底层系统或服务执行操作
- 结果返回：执行完成后，MCP server 将标准化的响应返回 MCP Client，MCP Client 更新上下文并交回 LLM
本地 Function call 与 MCP 的主要区别
| 特性 | 本地 Function Call（Function Calling/Tool Use） | 模型上下文协议（MCP） |
|---|---|---|
| 集成方式 | 定制化、紧密耦合。每个 LLM 或应用都需要直接学习和调用特定的函数签名。 | 标准化、松散耦合。通过通用协议进行通信，类似于 Web API。 |
| 可扩展性 | 受限。增加新工具或修改现有工具通常需要更新和重新部署 LLM 应用代码。 | 高。Agent 可以动态发现新能力，而无需重新部署或修改其核心逻辑。 |
| 互操作性 | 低。不同 LLM 或平台之间的工具定义难以共享和重用。 | 高。促进可互操作和可重用组件生态系统。 |
| 适用场景 | 具有固定、有限数量预定义函数的简单应用程序。 | 需要与各种不断发展的外部工具、数据源和 API 交互的复杂、可扩展或企业级 Agent 系统。 |
A2A
A 2 A 是一个标准化的 Agent 间通信协议，客户端通过获取 AgentCard → 构造请求 → 发送消息 → 接收响应，实现跨进程、跨语言的 Agent 调用
