智能体的最小可用架构

智能体的本质是一个循环。感知当前状态，推理下一步，执行行动，再次感知。这个循环不断重复，直到任务完成。不同架构的差异，就在于如何组织和扩展这个基本循环。

最小可用的智能体架构只需要三个核心组件。第一个是 LLM 核心，充当决策大脑。它理解用户的目标，拆解任务，决定调用什么工具。第二个是记忆模块，存储用户的偏好、任务的中间状态和历史对话。第三个是工具调用模块，负责执行具体操作，比如调用 API、读写文件或运行代码。

这三个组件通过 ReAct 循环协作。LLM 接收用户输入后，生成结构化的工具调用请求（包含工具名和参数），这是推理（Reason）阶段。工具模块执行调用，返回结果，这是行动（Act）阶段。结果追加到上下文中，LLM 再次推理，直到任务完成。这个循环是所有 Agent 框架的底层逻辑，无论是 LangChain 还是 AutoGen，本质都是对这个循环的封装和扩展。

一个极简的天气查询 Agent 就能体现这三个组件的协作。用户说「北京今天天气怎么样」，LLM 理解目标后决策调用天气 API，工具模块执行调用并返回数据，LLM 总结结果呈现给用户。记忆模块可以存储用户偏好，比如用户说过「我喜欢晴天」，下次查天气时 Agent 会特别强调晴天信息。这个过程形成完整闭环，三个组件缺一不可。

架构设计需要遵循三个原则。匹配原则要求架构复杂度匹配任务复杂度。查天气这样的简单任务用最小可行架构就够了，不需要复杂的记忆系统或多 Agent 协作。落地原则建议优先选择自己能掌控的架构和框架。新手可以从最小可行架构开始，不依赖任何框架，完全掌控每个组件的实现细节。扩展原则提醒我们要预留扩展空间。现在是单 Agent，未来可能需要升级到多 Agent 协作，架构要支持这种演进。

从最小可行到生产可用，架构需要逐步演进。第一层是 LLM 核心层，负责理解、推理和决策。第二层是记忆层，从简单的上下文窗口扩展到向量数据库支持的长期记忆。第三层是工具层，从单个 API 调用扩展到标准化工具注册和权限控制。第四层是执行层，从直接执行扩展到异步处理和错误恢复。第五层是观测层，添加日志追踪和性能监控。每一层都建立在前一层的基础上，形成完整的生产级架构。

实际开发中会遇到一些关键设计决策。上下文管理是最重要的挑战之一。每次工具调用的结果都会追加到上下文中，随着任务推进上下文会不断增长。需要设计合理的上下文压缩策略。常见的做法有三种：滑动窗口只保留最近 N 轮对话，摘要压缩将历史信息概括为简短描述，关键信息提取只保留与当前任务相关的中间结果。工具设计要遵循无状态原则，每个工具只负责一个原子操作，通过组合完成复杂任务。对于有状态场景，比如需要维护会话的 API 调用，应该在工具外部管理状态，而不是让工具内部维护。错误处理需要在工具层实现重试和降级机制，而不是让失败传播到整个系统。工具调用失败时，LLM 可以根据错误信息调整策略，比如更换工具或修改参数。

选择架构时，核心考量只有两个：你需要多大的灵活性来应对意外情况，以及你需要多大的确定性来保证结果可靠。从简单开始，在确实需要时才增加复杂度，这是架构选型的第一原则。最小可用架构的价值不在于它能处理所有情况，而在于它能让你快速验证核心假设，然后根据实际需求逐步完善。

需要清醒认识 LLM 的能力边界。当前模型在简单推理、模式匹配任务上表现良好，但在复杂数学推理、长程规划、多步逻辑推演上仍不稳定。Agent 的设计应该扬长避短，将复杂任务分解为模型擅长的子任务，而不是期望模型完成所有推理。这也是为什么最小可用架构强调工具组合，让 LLM 负责决策和协调，让工具执行具体操作，各司其职。