服务端视角下的AI Agent 架构解析

Agent 作为生产力工具，已经渗透到各个行业中。我们用的最多是平时写代码，一句话告诉Cursor、Claude Code，它会自动规划任务并实现它；一句话让千问解决世界难题中午帮我点个外卖；还有我们组是做Agent 修图的，它能根据用户输入自动拆解需要调用的修图工具集，如【美颜、磨皮、补光】。

这两年不少都已经模糊了前端这个岗位，甚至有些大厂直接取消了，比如我们这边基本上都是全栈了，随着AI的快速发展，认识AI Agent开发是很有必要的，知道这里面核心模块有哪些？怎么协同工作？该重点盯什么？

白话版：Agent 就是个有"自主意识"的智能体，能自己完成 「感知-决策-执行-反馈」 这一套闭环，核心是"自己找事做、自己搞定事"，而不是像传统后端接口那样，你喂它一个指令，它才动一下。它比传统后端多的自主决策和动态适配能力，全靠底层架构撑着。

下面从核心模块→工作流程→架构选型→落地避坑四个维度，搞懂 Agent 架构。

一、Agent 核心架构

Agent 的本质就是模块搭班子干活，所有模块围绕自主完成目标发力。核心就5个模块：「决策模块」是总指挥，规划具体要干的活，「执行模块」是手脚，干具体活，「记忆模块」是大脑，用来存上下文，「感知模块」是五官，用来接收指令、收信息，「工具集」是武器，得靠它与外部交互。

1. 感知模块（Input Module）：Agent 的"五官"

agent首先要接收外部输入，把乱七八糟的信息（不管是结构化的还是非结构化的），翻译成 Agent 能看懂的格式。说白了，就是帮 Agent 看懂现实世界的信息。

常见的输入来源就3类：

• • 用户指令（文本、语音都算，语音得先转成文本，不然 Agent 看不懂）；

• • 外部数据（数据库查出来的结果、其他 API 返回的内容、系统日志这些）；

• • 环境状态（比如当前任务执行到哪一步了、工具调用成功还是失败）。

感知模块最关键的就是准 和快。

用户发语音指令，比如豆包，得对接 ASR（语言转文本） 接口转写，还得做异常处理------万一语音模糊、转写失败，总不能让 Agent 瞎猜吧？接收数据库数据的时候，也得做格式标准化，统一字段名、处理空值，不然后续决策模块很容易误判。

思路：用 Go 或者 Nest 写个接口适配器，把所有来源的输入，都转成统一的 JSON 格式，后续模块直接拿过来用就行。

注：本文不会讲编码，本系列文章最后会实现一个修图 Agent作为项目实践。

2. 记忆模块（Memory Module）：Agent 的"大脑存储"

Agent 运行过程中会产生信息，存储的意义在于帮决策模块记事儿，比如记上下文、记经验，这也是 Agent 和普通 API 调用最大的区别，普通 API 、纯LLM调用完就忘，而Agent 能记住之前的操作。

它分 「短期记忆」和「长期记忆」，两者分工明确。

两大记忆类型，工程落地重点在这里，如果你转行做 Agent 开放（面试可能会问）：

• • 短期记忆：只记当前任务的事，比如用户之前说过什么、当前执行到哪一步、临时计算结果，任务结束就销毁，不占内存。项目中用 Redis 缓存就够了，读取速度快，适配多用户并发。

• • 长期记忆：记能反复用的东西，比如用户偏好（比如用户喜欢 Markdown 格式的报告）、业务规则（比如接口编写必须按照依赖倒置原则）、之前踩过的坑、工具怎么调用，只要 Agent 不下线，就一直存着，还能不断更新。企业常用的是向量数据库（Milvus、Pinecone、Chroma） + MySQL，向量数据库负责语义检索（比如快速找到用户之前的偏好），MySQL 存结构化数据（比如业务规则）。

记忆模块别只想着存，还要考虑性能和一致性。

短期记忆要扛住多用户并发读取，长期记忆要支持增量更新------总不能每次查个东西都全量扫描吧？另外，得做记忆清理策略，不然缓存溢出、数据冗余。

3. 决策模块（Decision Module）：Agent 的"灵魂"

Agent 的指挥中心 ，根据感知模块 收到的信息，再结合记忆模块 存的内容，自己判断下一步该干啥。

这模块是最考验项目设计能力和大模型应用能力的，没做好，Agent 就是会被人感觉是有点呆，不醒目，恰恰这是最难的部分，需要反复调优。

决策模块的核心逻辑，分3步：

1. 1. 目标拆解：把用户的复杂指令，拆成能直接干的小任务。比如用户说帮我统计本周系统接口报错率，生成报告并发送给产品组，就拆成：查日志数据库→统计报错数据→生成报告→发邮件；
2. 2. 优先级排序：给拆好的小任务排个序，谁先干、谁后干，比如先查日志，再统计数据，最后生成报告，总不能先发邮件再统计数据吧？
3. 3. 工具选择：判断每个小任务用什么工具，比如查日志用数据库工具，发邮件用邮件 API，要是没有合适的工具或者需要新建处理脚本，就反馈给用户，让用户授权或者自己学（大多数情况落地的时候还是以反馈用户为主，自主学习有点复杂）。

决策模块要盯紧稳定和能追溯。

实践上，可以基于 GPT-4、文心一言这些大模型封装决策接口，但别直接裸调用，要加上决策校验逻辑 ------ 比如决策结果不符合业务规则，就触发人工干预，或者让它重新决策。

另外，决策过程一定要记日志，方便后期debug，不然 Agent 乱调用工具，你都不知道问题出在哪，服务端很多时候是出了问题再加日志再排查的，这是个经验问题。

很多人容易把 MCP 和 决策模块 搞混，这里澄清一下：MCP 是多智能体之间的协作规范，定义了多个 Agent 之间怎么通信、怎么配合、怎么协同完成任务。

决策模块是单个 Agent 的 "大脑"，负责思考、判断、做选择。

在多 Agent 系统里，每个 Agent 都有自己的决策模块，再通过 MCP 实现彼此协作。

4. 工具集（Tool Set）：Agent 的"手脚"

当决策模块定好下一步干啥，就靠干活工具集去执行，把想法变成实际行动，相当于 Agent 和外部世界交互的桥梁。

常用的工具就4类：

• • 数据操作工具：查数据库（MySQL、MongoDB）、操作缓存（Redis），这是咱们最熟悉的；

• • API 调用工具：调用内部微服务接口、第三方 API（比如修图算法、发短信、调支付接口）；

• • 计算工具：做数据统计、调用大模型 API 做推理；

• • 日志/监控工具：查系统日志、拿监控指标（比如 Prometheus 里的接口响应时间）。

工具集要做到好用、好扩展。

每个工具都封装成独立接口，比如我们每个修图算法会封装一个MCP工具，Agent 靠读配置就能动态加载新的工具，不用改 Agent 核心代码，直接加配置就行。

另外，每个工具都要加超时重试、异常捕获，别因为一个工具调用失败，整个任务就崩了，这个要注意。

5. 反馈模块（Feedback Module）：Agent 的"自我优化"通道

Agent 也需要跟人类一样具备复盘能力，才能趋势它不断进步。

通过收集任务执行结果和用户反馈，把这些信息更新到记忆模块里，让 Agent 下次干活更靠谱，形成感知-决策-执行-反馈 的闭环------这也是 Agent 能越用越聪明的关键。

反馈一般来源就2类：

• • 自动反馈：工具调用的结果，比如查数据库成功了、API 调用失败了，反馈模块自动捕获；其次是调用另一个LLM模型进行验证结果是否合理。

• • 人工反馈：用户对结果的评价，比如报告数据错了、步骤太繁琐了，咱们得做个交互接口，收集用户反馈，再转成 Agent 能懂的结构化信息。

反馈模块要做到标准化和快更新。

把用户反馈转成"错误类型+修正建议"的格式，自动更新到长期记忆里。

其次，根据反馈权重优化，重要的反馈优先更新，比如用户说数据错了，比格式不好看优先级高。

反馈模块的优化是个体力活，根据不同策略需要不断反复调优，绝不是两三句话能讲明白的，这里我们先有这个认知即可。

二、Agent 工作流程：从用户指令到任务完成的闭环

了解了5大模块，再看完整工作流程，就很简单了。结合服务端常见的场景比如用户让 Agent 统计本周接口报错率并生成报告：

1. 1. 感知阶段：用户发指令统计本周系统接口报错率，生成报告并发送给产品组，感知模块接收指令，转成标准化文本，同时查系统监控接口，拿到本周接口的基础数据；
2. 2. 记忆阶段：记忆模块查短期记忆（看看用户之前有没有说过偏好，比如喜欢 Markdown 报告），再查长期记忆（看看接口报错怎么统计、产品组邮箱是多少、或者是调用哪个机器人webhook接口）；
3. 3. 决策阶段：决策模块结合拿到的信息，拆分子任务、排优先级、选工具------先查日志数据库，再统计报错率和 Top5 报错接口，然后生成 Markdown 报告，最后发邮件、机器人通知；
4. 4. 执行阶段：工具集按决策来，依次调用数据库查询工具、数据统计工具、报告生成工具、邮件发送工具，每一步都实时返回结果；
5. 5. 反馈阶段：反馈模块捕获每一步的结果，要是成功了就记下来，要是失败了（比如邮件地址错了），就反馈给决策模块，让它重新调整参数；同时收集用户后续的评价，更新到长期记忆里，下次就不会再犯同样的错。

整个流程里，服务端开发的核心作用，就是搭好台子，让各个模块能顺畅协作------比如提供稳定的接口、扛住并发、保证数据一致、监控任务状态，别让模块之间掉链子。

三、Agent 架构选型：不同场景，不同方案

不是所有 Agent 都要把5大模块全堆上，服务端开发是否过度设计是个哲学问题，辩证法告诉我们根据业务场景选方案，才是最靠谱的。

常见的3种方案，对应不同场景：

1. 轻量型架构

核心模块：感知模块 + 决策模块 + 基础工具集（不用记忆、反馈模块）；

适用场景：单步任务、不用记上下文，比如查一下当前系统负载、获取今日AI资讯；

落地实现：简单粗暴，比如用 Nest 写个简单接口，决策模块直接调用大模型 API，工具集封装成单个函数，不用搞复杂的记忆和反馈，开发快、部署简单。

2. 标准型架构

核心模块：5大模块全上（感知+记忆+决策+工具集+反馈）；

适用场景：多步任务、需要记上下文，比如排查系统异常并给解决方案、根据用户偏好进行修图或者写代码；

工程实现：用微服务架构，把每个模块拆成独立服务（记忆服务、决策服务、工具服务），用 Kafka 或者 RabbitMQ 做模块间通信，能扛高并发。

3. 多智能体架构

核心：多个标准型 Agent组合。

适用场景：任务特别复杂，需要多个 Agent 分工协作，比如电商平台的智能客服+订单处理+物流跟踪，每个 Agent 负责一块，靠 MCP 配合完成整个任务；

工程实现：每个 Agent 独立部署，靠 MCP 接口交互、调度任务，服务端要有协同调度中心，监控每个 Agent 的状态，避免抢任务、干错活的情况。

典型的是Claude Code中多Agent协作，尤其是在harness engineering工程中，不同子Agent做不同的事情，由主Agent调度。

四、落地 Agent 架构的关键注意点

经验分享的意义在于学习别人的错误，避免重复犯错，比如：

1. 1. 性能优化：决策模块依赖LLM API，用上 Redis 来缓存常见的决策结果，减少调用次数，但有使用场景限制，比如调用LLM输出结果稳定（通过温度调节结果稳定性）；另外，工具调用用异步（比如Go里面用 Goroutine、Nest里面用Promise），别让一个任务阻塞整个 Agent；
2. 2. 异常处理：每个模块都要加异常捕获，比如感知模块接收输入失败、工具调用超时、决策模块误判，有降级方案------比如返回默认结果、触发人工干预；
3. 3. 安全性：工具集调用数据库、外部接口时，一定要做权限控制，遵循最小权限原则，别给 Agent 太高权限，该授权的一定要授权；另外，过滤用户输入，防止恶意 SQL 注入之类的攻击；
4. 4. 可监控：工具调用加上PromptDebugger，能够追溯模型调用行为；监控每个模块的状态------比如记忆模块的缓存命中率、决策模块的响应时间、工具调用的成功率，一定会在后续排查问题中收益。

五、总结

对于服务端开发者来说，天生的优势是懂工程、懂落地------用 Go/Nest、数据库、微服务这些熟悉的技术，把架构模块落地，让 Agent 真正能干活、这其实属于舒适圈。

难的地方在于：让Agent能够把活干好！

每一个模块看似是几句话带过，背后都是庞大的工程体系，如决策模块在推理过程中如何保证检索质量、检索速度、检索相关性，这就涉及到常见的RAG、Top-K设计、文档切割、ReRAG、Self-RAG 等，以及更多的LangChain、LangGraph、LangSmith又是什么，如何应用？这里留个引子，将新的一篇文章做详细介绍。

综上，无论是大全的通用Agent还是垂直类的Agent，都在这几个模块基础进行扩展定制，这是对Agent认知的前提。