本文探讨了各种架构组件，如人类、辅助程序、AI Agent、AI模型、MCP主机/客户端/服务器。由于数据在这些组件之间持续传递，我们首先会讨论一种思考方式，即输入到某个组件的数据类型以及从该组件输出的数据类型。在与其他构建AI Agent的工程师交流时，这种思考方式很有帮助。
接下来，我会介绍每个组件，解释其在整体架构中的主要用途，以及何时、如何利用其他组件。希望你读完本文后，能理解每个组件的用途以及实现这些功能的最佳方式。
人类、AI模型与软件集成
人类和AI模型都会接收非精确输入，例如自然语言文本、图像/视频和音频，并尝试去“理解”或“弄明白”这些输入。由于非精确输入需要解读，不同的人类和AI模型可能会产生不同的或非精确的输出：
非精确数据 ⇨ 人类/AI ⇨ 非精确数据
另一方面，软件接收精确输入，例如标量值（布尔值、整数、浮点数）、格式规范的字符串（URL、日期/时间、UUID、JSON、XML、CSV等），以及由这些组成的结构/数组。由于精确输入无需解读，不同的软件对相同输入的解读是完全一致的。例如，用一种编程语言编写的服务可以创建一个JSON对象并输出给用另一种编程语言编写的客户端，而服务和客户端对这个JSON对象的理解完全一致。另外，软件会产生精确输出：
精确数据 ⇨ 软件 ⇨ 精确数据
人类和AI模型通常会产生非精确输出。但它们也可以尝试产生精确输出：
带有精确数据要求的非精确数据 ⇨ 人类/AI ⇨ 尝试生成的精确数据
例如，人类想要将脑海中的算法（非精确的想法）转换出来，并尝试输出某种编程语言的源代码（精确输出）。同样，通过非精确的自然语言可以要求AI模型生成精确的数据输出。以下是一个AI提示词示例：
给定以下结构：structure Person { string FirstName string LastName string CompanyName string EmploymentDate // 格式为YYYY-MM-DD}为“2015年6月1日，约翰·史密斯以全职员工身份加入微软”生成一个JSON对象（仅此而已）。当我将这个非精确输入的提示词发送给AI模型时，得到了以下精确输出：
{ "FirstName": "John", "LastName": "Smith", "CompanyName": "Microsoft", "EmploymentDate": "2015-06-01"}上述JSON对象可以作为精确输入传递给软件，以便进行可靠处理。
在要求AI模型输出精确数据时，如果提示词中包含的名称（如FirstName、LastName等）具有描述性，能让AI模型更好地理解其含义，那么成功生成精确数据的可能性会高得多。
当然，需要认识到人类和AI模型都可能出错，这也是我强调它们是“尝试”输出精确数据的原因。但这并不能保证一定成功，而且如果软件尝试处理非精确输入，很可能会失败，显然这是我们希望避免的：
非精确数据 ⇨ 软件 ⇨ 💣（失败）
本次讨论的主要要点如下：
非精确数据是人类和AI模型的有效输入，但不是软件的有效输入。
如果人类或AI模型输出非精确数据，该输出是面向人类或其他AI模型的。
如果人类或AI模型输出精确数据，该输出可面向人类、AI模型或软件。但尝试输出精确数据可能会失败，在这种情况下，传递非精确数据很可能会产生不可预测的结果。
基于A2A的AI智能体
AI智能体（AI Agent）代表人类或其他AI智能体追求目标并完成任务。每个AI智能体都专长于某一组离散的技能，因此可能需要依赖其他专业AI智能体来完成任务的部分环节。下图展示了人类使用“行程预订智能体”的场景，而该智能体又可能会借助其他AI智能体来完成整个行程的预订。
AI智能体会接收输入请求，并结合自身具备的领域特定知识对请求进行推理。这一过程会生成执行计划，然后利用其可调用的各种工具执行操作。在本节中，我们将按照谷歌的Agent-to-Agent（A2A，智能体到智能体）协议中对AI智能体的定义来展开探讨。下图为可视化说明，可供讨论过程中参考。
从使用者的角度来看，AI智能体通过HTTP服务实现，该服务暴露的操作接收非精确输入并返回非精确输出。此外，AI智能体拥有名称、描述以及一组技能（每个技能都有自己的名称和描述），用于说明该AI智能体能够执行的任务类型。所有这些属性都是非精确的字符串值，因此通常由人类或AI模型（而非软件）来选择特定的AI智能体并使用它来执行任务。以下是一个AI智能体的属性示例：
名称：地理空间路线规划智能体描述：提供高级路线规划、交通分析和自定义地图生成服务。该智能体可计算最优路线、结合实时交通估算出行时间，并创建包含兴趣点的个性化地图。技能 #1： 名称：交通感知路线优化器 描述：计算两个或多个地点之间的最佳驾驶路线，考虑实时交通状况、道路封闭情况以及用户偏好（例如避开 toll 道路、优先选择高速公路）。技能 #2： 名称：个性化地图生成器 描述：基于用户定义的兴趣点、路线和风格偏好，创建自定义地图图像或交互式地图视图。可叠加数据层。客户端AI智能体会根据服务端AI智能体公开的描述和技能，向服务端AI智能体发起任务。发起新任务后，客户端与服务端AI智能体之间会形成一个可能长期存在的对话。当客户端AI智能体添加用户消息（由AI模型处理）或服务端AI智能体添加智能体消息（由AI模型生成的响应）时，任务会逐步推进。
需要注意的是，AI模型是无状态的，因此AI智能体必须尽可能保留对话历史，并将其发送给AI模型以推进对话。每个AI模型都会说明其“上下文窗口”（context window），即它支持的最大对话规模。为了管理对话历史的大小，AI智能体通常会采用一些策略，例如删除旧消息或尝试删除与对话“相关性较低”的消息。
每条消息包含一个或多个部分（文本、文件URI/数据或JSON数据）。任务的最终智能体消息包含由服务端AI智能体生成的输出成果（文档、图像、结构化数据）。该成果也包含一个或多个部分。
以下是任务对话消息的示例（仅聚焦核心概念）。
客户端向AI智能体发起任务对话：
用户消息：部分：文本：我想预订一张机票
AI智能体响应，表明需要输入信息：
状态：input-required（需要输入）智能体消息：部分：文本：没问题，我可以帮您！您想飞往哪里，从哪里出发？另外，您偏好的出行日期是什么时候？
客户端向对话中添加所需的输入消息：
用户消息：部分：文本：我想从纽约（JFK）飞往伦敦（LHR），大概10月10日出发，10月17日返回。
AI智能体完成任务处理：
状态：已完成智能体消息：部分：文本：好了，我已经为您找到合适的航班。详情请见成果物。成果物：部分：数据：{"from": "JFK","to": "LHR","departure": "2024–10–10T18:00:00Z","arrival": "2024–10–11T06:00:00Z","returnDeparture": "…"}
在内部，AI智能体有一个主执行循环，称为“协调器（orchestrator）”。协调器的职责是推动任务对话直至完成。有多种工具可帮助开发者构建协调器，例如LangChain、Semantic Kernel和AutoGen。
处理新消息时，协调器通常需要用AI智能体特定的“知识”来增强消息的提示词，以提高输出质量。这种技术称为检索增强生成（RAG）。具体来说，协调器为用户消息的提示词获取一个嵌入向量，然后对数据文件、PDF等进行相似性搜索，找到与用户提示词内容相似的源内容。协调器会将这些内容嵌入到提示词中。
此时，协调器会将整个对话发送给AI模型。AI模型的输出有两种可能：
非精确结果，该结果会被附加到任务对话中。
一组精确的特定工具名称，用于调用工具。工具名称要么指向另一个专业AI智能体，要么指向某个软件函数（通常由下文讨论的MCP服务器实现）。调用这些工具是协调器的职责，而调用软件函数使AI智能体能够执行操作并具备“智能体特性（agentic）”。例如，软件函数可以添加日历条目、创建数据库记录、发送电子邮件等。每个工具的字符串结果会被附加到任务对话中。本文后续的序列图将可视化这一工作流程。
之后，协调器会循环继续对话，直至任务完成。
