一个Agentic AI系统到底由什么组成？五个核心部件

面试官向后靠在椅背上，问："那么，什么是Agent（智能体）？"大多数候选人回答"能使用工具的LLM"，面试官点点头，却什么也没记下来。在基础AI认证考试中也是如此——一道题给出四个看似都合理的选项，而那些错误选项正是从这个半对答案中衍生出来的。

一篇来自confidentprep.com的文章给出了一个更有力的答案：一个agentic AI系统由五个部分组成，且顺序固定——循环（loop）、工具（tools）、连接（connection）、记忆（memory）和协调（coordination）。文章还专门讨论了"什么时候不该增加更多agent"。每个部分都有一个面试官和考官会故意探查的混淆点，而这些混淆大多源于没有问清一个问题：连接的两端分别是什么？

循环先于任何技术：Agent的定义性特征

一个强候选人会这样开场：

"Agent是一个使用基础模型来决定朝目标采取哪些行动的系统。它执行这些行动，读取返回的结果，然后再次决策。它不会在一次推理中产出一个答案。定义性的属性是那个循环。如果没有任何东西能返回并改变它的决策，那它就是一次单纯的模型调用，无论输出多好。"

基础模型（foundation model）是在广泛数据上训练的大型模型，许多应用都构建在其之上。循环才是答案的核心——你甚至可以替换系统中所有技术，只要循环还在，它仍然是agent。

把它想象成"一个拿着借书证的研究员"和"一个凭记忆回答问题的人"之间的区别。研究员会去查资料，查到的东西会改变他的下一个问题；而凭记忆答题的人永远不会被"意外"改变方向。

Agent先决策、行动、观察结果，然后再次决策或给出答案

结果返回后的那个分支才是agent的本质：要么再次行动，要么给出答案。模型本身并没有获得新能力，新能力在于结果作为上下文被送回来了。

基础模型（Foundation Model） 是这一讨论的前提概念。它指在海量、多样数据上以自监督方式预训练的大型模型（如GPT、Claude、Gemini系列），具备广泛的语言理解与生成能力，可被下游任务直接使用或微调。与传统为单一任务训练的专用模型不同，基础模型的通用性使其成为构建agent的理想底座——它能在没有针对每个场景重新训练的情况下，承载决策、工具调用和结果解读等多样职责。理解这一点很重要：agent的新能力并不来自模型本身被替换或升级，模型在整个循环中始终是同一个基础模型。真正的增量在于系统架构——把模型的输出接到运行时上，再把运行时的结果送回模型。因此在面试中，若候选人把agent的能力来源归于"更强的模型"，往往暴露出对架构层面的理解不足。

跟进问题一：模型请求，运行时执行

"当agent使用工具时，模型实际做了什么？"

标准答案：工具使用意味着让模型能够访问外部函数、API或数据源。模型决定需要某个工具，并决定传入什么参数。而运行时（runtime）是模型周围的软件，它执行实际调用并把结果返回上下文。模型随后解读这个结果，决定下一步做什么。

弱候选人常犯的错误是说出"模型查询数据库"或"模型预订了档期"。任何暗示模型直接执行了操作的答案，都把这个机制搞反了。对面试官来说，这等于在说：你从没真正看过一个agent运行。

就像医生开血液检查单——医生不会自己跑化验，他下单，实验室执行，结果返回，诊断可能因此改变。

运行时（Runtime） 是这里的核心概念，值得展开。运行时是包裹在模型外部的软件层，负责解析模型输出的意图、实际发起函数调用或API请求、捕获返回结果，并将其格式化后重新注入对话上下文。它通常还承担参数校验、超时处理、错误重试和权限控制等职责。模型本身是纯推理组件，没有网络访问能力、没有文件系统、也不能执行任何副作用操作。区分"模型决策"与"运行时执行"是理解agent安全边界的关键：模型可以建议一次数据库写入，但真正决定是否执行、以什么凭据执行的是运行时。这也解释了为什么agent系统的安全策略通常实现在运行时层，而非模型提示词里——因为真正能造成外部影响的代码在那里。

跟进问题二：MCP连接agent与外部系统

"什么是Model Context Protocol（MCP），它消除了什么问题？"

标准答案：MCP是一个开放协议。它标准化了AI应用如何将模型连接到外部工具和数据源，从而用一个通用接口替代为每个系统做定制集成。它消除的问题是"乘法级"的：三个应用各自连接四个系统，需要12个独立集成；有了共享协议，每侧只需实现一次，就变成7个。再增加第五个系统时，成本也从三次实现变成一次。

就像USB-C：以前每个设备都需要自己的线缆，有了统一接口标准后，任何设备都能对接任何外设，双方都不需要提前知道对方。

弱候选人常犯的错误，按出现频率排列：

• "MCP让agent之间相互对话。" 并不是。MCP连接的是agent与外部系统。Agent之间的通信是另一个独立概念，叫做通信模式（communication patterns）。
• "MCP是一个产品或托管服务。" 它是一个开放协议。云服务可以支持它，但这是另一回事。它从来不该被列在"可选服务"清单里。
• "你必须用MCP才能使用工具。" 工具使用早于MCP就存在，没有它也能工作。当只有两三个连接时，定制集成是可以接受的；共享协议的价值随着连接对数的增长而增长。

一个问题就能澄清以上的大部分混淆：连接的两端是什么？ 如果一端是agent、另一端是外部系统，那就是MCP；如果两端都是agent，那就是通信模式。

Model Context Protocol（MCP） 由Anthropic于2024年末提出并开源，采用客户端-服务器架构。MCP服务器暴露工具、资源（resources）和提示模板，MCP客户端（通常是AI应用）按统一格式发现并调用它们。文中提到的"乘法级"问题在数学上正是N×M与N+M的差异：N个应用与M个系统各自定制集成需要N×M份工作，而共享协议后每侧各实现一次，总计N+M。这一模式在软件工程史上反复出现——它和USB、HTTP、ODBC等接口标准化的逻辑一致。需要强调的是，MCP本身不实现任何工具，它只规定"如何描述和调用工具"，具体能力仍由各系统的服务器提供。

跟进问题三：记忆是关于什么该留存的决策

"agent是如何记住东西的？"

标准答案：模型在调用之间是无状态的。之前的对话轮次每次都要重新发送，所以记忆从来不是自动的，也从来不是免费的。记忆管理意味着决定agent要携带什么向前、携带多久、以及丢弃什么。工作记忆（working memory）保存当前任务，比如最近的轮次和最后一次工具结果，任务结束时就被丢弃。持久记忆（persistent memory）保存耐久事实，比如客户偏好或既往结果，存储在模型之外并有选择地检索。

弱候选人的典型错误是："把整段对话历史都给它就行了。"但所有被携带向前的内容都会在每次调用时重新提供并重新计算。成本和延迟都会增长，重要的东西反而被稀释。留存还带来风险：一次性验证码如果被放进持久存储，那是负担而不是功能。

就像医院交接班——并不是把整个班次发生的一切都传下去。重要的是要被传递的，而且交接是一个摘要，不是逐字记录。

所以有用的问题不是"我们如何记住更多？"而是"什么必须留存，什么必须不留？"

无状态（Stateless） 是理解记忆问题的技术基础。大模型API本身不保存对话历史——每次调用都是独立的，模型只能看到本次请求中显式传入的内容。所谓"对话记忆"实际上是应用层在每次调用时把历史轮次重新拼接进上下文。这带来两个直接后果：其一，上下文长度即成本，token数随轮次累积线性甚至更快增长；其二，模型对历史的"记忆"始终是被动的——它无法主动回忆没有传进来的内容。因此工作记忆与持久记忆的分野不只是设计风格，而是架构必需：工作记忆随任务生命周期存在并销毁，持久记忆则存放在模型之外的向量数据库或键值存储中，仅在相关时检索注入。

跟进问题四：排列方式与消息流是两个独立问题

"列举一些多agent模式。" 弱候选人只给一个清单；强候选人会先问：你说的是哪一种模式？

标准答案：多agent系统使用多个专门的agent，用来应对单一通用agent会被拉得太薄的情况。这里有两个独立的问题。

系统模式描述agent如何被组织：

• Supervisor（监督者模式）：一个主导agent分解任务、委派给专家、再组装结果
• Sequential（顺序模式）：每个agent的输出是下一个agent的输入
• Parallel（并行模式）：独立agent同时工作，结果被合并
• Hierarchical（层级模式）：监督者的监督者

通信模式描述agent之间如何交换信息：

• Direct（点对点）：一个agent调用另一个并等待
• Broadcast（广播）：一个agent同时通知多个
• Shared state（共享状态）：agent读写共同的存储
• Message queue（消息队列）：消息异步传递

弱候选人的错误在于：当被问及agent如何交换信息时，回答"Supervisor"。这答的是另一个问题。

把它想象成一个组织：系统模式是组织架构图，通信模式是备忘录如何传递。一个监督者系统可以用点对点传消息，也可以用共享状态，选择其中一个并不决定另一个。

跟进问题五：协调拥有计划，包括何时停止

"什么是工作流编排，应该由谁拥有它？"

标准答案：工作流编排是协调agentic应用的各个步骤。它涵盖排序、路由、失败处理与重试，以及决定任务何时完成。最后一项职责很容易被忽略。计划可以由两种方式拥有：在确定性编排中，开发者定义工作流，它可预测、可测试、可审计，但无法适应意外情况；在模型驱动编排中，模型选择每一步，它能适应新情况，但运行路径在多次运行之间会变化。

弱候选人的错误在于：把模型驱动编排当作"高级默认选项"。在受监管或需要审计的流程中，"路径在多次运行间变化"是一个缺陷。

就像空中交通管制员——每位飞行员驾驶自己的飞机，而管制员决定谁移动、按什么顺序、以及何时序列完成。

跟进问题六：一个好工具的单agent才是默认选项

"什么时候你会用多个agent而不是一个？"

标准答案：只有当任务跨越真正不同的专业领域时才使用多个agent，并且要能说出理由。一个任务即使很长，只要仍在同一个专业领域内，那就还是一个agent做更多步骤。每增加一个agent，都会放大四件事：模型调用（每次都有成本）、延迟（步骤之间互相等待）、失败模式（任何agent都可能卡住或传递坏结果）、调试成本（"是哪个agent做了那个决定"会成为一个真问题）。

弱候选人的错误：因为场景里出现了"complex"这个词，就伸手去拿多agent。

文章给出了一个说明性案例。一个物流助手回答"我的包裹在哪？"，通过读取追踪数据库即可。它需要记住每个客户偏好的通知渠道。当物流中断时，它的建议需要定价、海关和运力方面的专业知识。经过考虑的设计有两条路径：普通查询走一个带工具的agent；只有中断场景才走一个协调三位专家的supervisor。把简单查询送到多agent路径上只会增加成本和延迟，什么都换不来。

核心要点回顾

• Agent由循环定义。 如果没有任何结果能返回并改变决策，那它就是一次单纯的模型调用。
• 模型请求，运行时执行。 拒绝任何暗示模型自己查询、调用或预订了东西的答案。
• 问清连接的两端。 Agent对外部系统是MCP；agent对agent是通信模式。MCP是协议而非产品，工具离开它照样能用。
• 记忆是关于什么该留存的决策。 区分工作记忆与持久记忆，"全都保留"是成本而非安全默认。
• 结构与消息流是两个独立问题，编排拥有计划，包括知道何时停止。
• 一个好工具的单agent才是默认选项。 只有当存在真正不同的专业领域时才升级。

文章的边界也很清晰：它讲的是agentic系统的"组成部分"，并没有回答商业上"agent到底用来做什么"，也没有涉及如何在实现这些部件的具体托管服务之间做选择，或者它们在规模上的成本。这些都是另外的问题，考试通常也会把它们放在不同的目标下测试。