前言

最近一段时间各类Agent大火，甚至不少公司都让前后端这波过剩的人转向Agent开发，开出的薪资都很高，但我自己冷静下来分析发现现在市面上主流的Agent实际上就是一个大模型API的套壳罢了。

本文所有图片均由我自己开发的agent版drawio生成

所以在我同时略懂AI和前后端开发的情况下我在从架构层面思考目前的Agent有什么问题，我总结了以下几点：

  1. 市面上大部分Agent基本纯依赖LLM作为决策器，这导致LLM作为大脑既要承担决策还要负责分析，最终导致大模型给出的目标决策在高难度任务下容易混乱，即使采用大量提示词进行限制。
  2. 大部分Agent消耗Token的力度太强，现有的Agent的模式很难找到一个token消耗和性能的平衡点，作为商业产品来说用户长期付费意愿太低，这是因为无论用户发送了什么Prompt，都被所谓的Agent进行了提示词包装，多论对话后超长的上下文消耗token太厉害，而且不管是简单还是复杂的任务都调用大模型使得任何任务的权重实际上是一样的，加剧了token消耗。
  3. 记忆管理机制不强，很多Agent采用向量数据库作为长期记忆，但是长期记忆中的某些部分实际上是必须要结构化的，例如性别等内容，还有一个问题是使用向量数据库有一个明明数据库中有但是查不到的问题【后续解释这个问题】，有些采用本地json作为长期记忆，虽然解决了需要结构化的问题但是又可能占据用户磁盘空间，作为商业产品来说不合适，而且也失去了向量检索的功能。
  4. 开发脚手架的定制化问题，要不就是不使用langchain直接自己写调度但开发速度太慢，要不就是全部依靠langchain（这是大部分情况），这导致定制化程度太低，最重要的是作为商业产品来说，业务框架可能是Java的，但是agent执行的代码可能是python的，这种不一致会导致业务和agent两边需要多余的调度时间。

存在以上问题以后我决心自己开发一套自己Agent脚手架，在开始之前整理下目前Agent领域的一些现状。

什么是Agent

Agent(也就是智能体)，这个概念很早就有了，在AI领域主要特指的是为任何能够通过传感器（Sensors）感知其所处环境（Environment），并自主地通过执行器（Actuators）采取行动（Action）以达成特定目标的实体。

但现在实际上市面上大部分的智能体是：

由LLM完成大脑思考和规划、观察，Agent本身只负责调度、执行、传递日志等功能

但是我认为目前所有的Agent在构建上都只是为了做一件事：如何缓解单个模型上下文超过以后带来的遗忘问题

现有的Agent的构建方式

目前的Agent构建的范式主要有以下几种，这几种也是langchain或者google adk主流的形式：

  1. ReAct（Reason+Act）范式：模型在同一循环中生成“思考痕迹”和具体行动指令，实现边推理边执行。研究表明，ReAct 模式通过交替进行思考和工具调用，能有效提高复杂任务的可靠性，减少单纯链式思考（Chain-of-Thought）的错误传播。例如，在问答或互动决策任务中，模型利用 ReAct 方法可边检索信息边更新计划，从而取得高于基线的方法效果。
  2. 计划-执行（Plan-and-Solve）范式：首先让模型生成一个完整的多步骤执行计划，然后逐步执行计划中的每一步。这种两阶段方法适用于步骤清晰、需要系统性推进的任务。Agent 先制定详细路线（分析市场、列出要点等），再按步骤调用工具或生成内容。这种范式对可分解问题很有效，但在动态或不确定场景中可能不如 ReAct 灵活。
  3. 自我反思（Reflection/Reflexion）范式：让模型在完成输出后自动进行批评和改进。指出，这种模式下 Agent 首先生成回答或代码，然后再生成批评意见（指出不足），最后基于反馈重写输出。多轮自我批评与重写循环可以显著提升结果质量。例如，在生成代码后让模型自己检查并修正错误，就能得到更高质量的代码。该方法也可通过多智能体展开，一个智能体负责生成，另一个负责点评，最终讨论出更佳方案。
  4. 其他模式：除上述外，还有“STORM”（从多视角思考）等多智能体协作策略，或是让模型在不同提示下生成多种解答并投票等方法。总体而言，这些范式都是在“让模型多次思考并利用工具”的基础上改进质量。

由于反思范式现在在某些垂直领域很重要，这里单独写一下他目前的发展情况和变体：

反思架构变体 核心技术机制与工作流 工业应用场景与局限性
基础反思 (Basic Reflection) 构建“生成器”（Generator）与“反思器”（Reflector）的双节点网络。生成器输出草稿，反思器扮演苛刻的教师角色提供修改建议。此循环在达到预设的最大迭代次数前不断重复 。 适用于文本润色、基础代码格式化等无需外部数据验证的任务。局限在于缺乏外部事实的锚定，可能陷入逻辑自嗨 。
Reflexion 架构 引入外部环境反馈进行“强化反思”。生成器输出动作并调用外部工具执行，系统不仅依赖内部逻辑批判，更根据真实的外部观察（如代码编译报错堆栈）来定位问题，强制模型生成具体的缺陷列表与修复策略 。 广泛应用于高级软件工程智能体和需要严格验证的科学推理任务。能够有效纠正模型在长序列中的幻觉现象 。
LATS (Language Agent Tree Search) 将反思机制与经典的蒙特卡洛树搜索（MCTS）深度融合。使用置信上限公式进行节点选择，并行生成多个分支动作。通过反思对每个分支的环境反馈进行打分，并将其反向传播至根节点，以决定最优行动路径 。 适用于极高复杂度的开放域探索和长期规划，能彻底解决单一思维链遇到死胡同时无法回溯的致命缺陷，但算力成本极高 。

Harness Engineering（挽具工程）

Harness由 HashiCorp 的联合创始人、著名开发者 Mitchell Hashimoto 于 2026 年初提出，并迅速席卷了整个 AI 工程界 。Hashimoto指出，要想让 AI 工具从低效的聊天助手进化为能显著改变生活流和工作流的真正生产力，人类必须放弃单纯的提示词调试 。

后来这一想法在openai于2026年2月在一个完全由codex进行代码编写的项目中开始得到实践，并且给这套范式起了Harnes Enginerring的名字,再后来langchain开发团队也开始实践这一模式。

简单来说就是目前大家公认的Agent架构实际上是：

Agent = model + Harness engineering

这个架构的起因是大部分工程师发现其实目前的大模型已经足够强悍，只是他没有办法进行感知，就像你复制一段代码给ChatGPT去聊天让它理解代码是没有直接让Codex读你整个代码仓库理解的深。

挽具工程的核心哲学： 无论何时何地，一旦你发现智能体在自主运行中犯下了一个错误，你绝不应该停留在责怪大模型“还不够聪明”或试图通过增加一段模糊的提示词来祈求它下次注意。相反，工程师的职责是立即着手“设计一个挽具”，从物理环境机制或绝对的规则层面上构建出坚固的护栏，使得智能体从今往后“物理上”（mechanically）绝不可能再次犯下同样性质的错误 。这就像是在为一匹充满野性但力量惊人的骏马套上精准传导控制力的皮制挽具，将野性转化为沿着既定轨道拉车的工业级引擎动力 。

一句话总结Harness：

构建一个系统，目的不是为了修复代码，而是让AI可以稳定、可控、可验证的工作

记忆系统

我认为记忆系统也是为了缓解大模型上下文窗口太短的问题所诞生的，让Agent可以记住之前任务的关键信息。

工业级第三方记忆引擎：Mem0 与 Mem9

Mem0：全局自适应的高性能记忆编排层 Mem0（读作”mem-zero”）是一个专为AI助手和自治系统设计的工业级、以记忆为中心的架构层 。它坐落于智能体与底层存储系统之间，负责全盘编排记忆的生命周期 。 从技术特性上看，Mem0 支持多层级的记忆抽象，能够无缝地同时维护用户级（User）、会话级（Session）以及智能体内部状态级（Agent state）的记忆流 。在底层实现上，Mem0 默认利用高质量的向量数据库进行语义级别的记忆检索，并在其最新的学术变体中引入了基于图结构的记忆表示（Graph-based Memory），这使得系统能够捕获并推理对话元素之间复杂的实体关系网络 。在工业级落地的性能指标上，与传统将所有对话历史暴力塞入提示词的全量上下文方法相比，Mem0 将 p95 延迟降低了惊人的 91%，并节省了超过 90% 的大模型 Token 消耗成本 。此外，在严格的 LOCOMO 基准测试中，其综合准确率比 OpenAI 原生的记忆系统高出 26%，在单跳、时间、多跳和开放域问答中均表现出显著优势 。

Mem9：云端持久化与严格逻辑隔离的私有化中枢 与 Mem0 的通用编排定位不同，Mem9 的架构设计受到了多智能体协作中数据污染问题的启发，强调去中心化的智能体与中心化、强隔离的记忆中枢相结合 。 Mem9 遵循一个绝对的核心设计原则：所有的智能体插件必须是零状态的（Zero-state） 。这意味着无论开发者在本地部署多少个智能体实例，智能体本身不保留任何数据，所有累积的工作偏好、私有决策和历史上下文全部驻留在后端的 mnemo-server 中（通常由 TiDB 或 MySQL 等成熟数据库支撑） 。这种架构赋予了智能体极高的物理流动性，开发者的记忆能够跨越设备无缝跟随 。更为关键的是，在企业级多智能体共用同一租户空间的场景下，Mem9 利用底层的 agent_id 实现了严格的逻辑隔离。在每次向大模型发起请求前，Mem9 的中间件（Middleware）机制会自动拦截请求，通过混合检索技术（向量+关键词）仅从云端拉取属于当前特定智能体的相关记忆并注入系统提示词中，从根本上杜绝了多智能体协作时的记忆交叉污染和隐私泄露风险 。

顶尖厂商智能体产品中的记忆实现

Claude Code 的分层记忆系统：六层文件系统记忆架构

Anthropic 团队在构建其代码生成智能体 Claude Code 时，放弃了复杂的外部数据库架构，转而设计了一套极其精妙、与底层操作系统深度绑定的六层文件系统记忆架构 。这一设计完美体现了“实用主义”原则：通过操作系统的文件机制实现记忆的持久化。 Claude Code 的记忆优先级从高到低严格分为六个层级，以解决从个人偏好到组织级策略的冲突：

  1. **项目本地覆盖 (CLAUDE.local.md)**：优先级最高，被 Git 忽略，用于存储开发者的私人环境变量或临时覆盖规则 。
  2. **用户全局记忆 (~/.claude/CLAUDE.md)**：存储开发者个人的全局编码习惯，跨项目生效 。
  3. **项目模块化规则 (.claude/rules/\*.md)**：用于存放特定领域或特定模块（如前端框架特定写法）的细分规则 。
  4. **项目共享记忆 (CLAUDE.md)**：纳入 Git 版本控制的核心记忆，包含了整个团队的架构约定和构建命令，在每次会话启动时被强制加载到系统提示词中 。
  5. **组织级管理策略 (/etc/claude-code/CLAUDE.md)**：由企业IT部门统一部署的最高合规性约束 。
  6. 自动记忆层（Auto Memory）：最底层但最具动态性的区域，智能体通过内部钩子系统（Hooks），在每次会话结束时，自动为自己将项目探索的过程总结为 Markdown 笔记存放于此，形成跨会话的检索回忆 。

OpenAI Assistants API：线程（Threads）与状态压缩

OpenAI 在其 Assistants API 中原生集成了持久化记忆功能。系统引入了“线程”（Threads）的概念作为记忆的容器。当一个线程内不断积累的对话和工具调用结果即将突破底层模型的最大物理上下文窗口时，OpenAI 的后端基础设施会自动触发截断（Truncation）或高级的上下文压缩（Compaction）机制 。这种系统级的自动化管理使得智能体能够在长达数月的大型工程项目中跟进从需求提案到最终部署的完整生命周期，而无需开发者手动编写复杂的数据库读写逻辑 。

Trae Agent 2.0：放弃静态规划，拥抱上下文扩展

在早期的智能体设计中（如早期的 Trae Agent），系统通常采用静态的 Plan-then-Execute 工作流。然而，字节跳动团队在演进 Trae Agent 2.0 时发现，这种固化的早期规划往往导致严重的记忆断层，因为最初的计划无法预见执行中期的代码变更细节 。因此，Trae Agent 2.0 彻底移除了固定的“提案”（Proposal）规划阶段，转而采用一种高度自治的统一模型模式。在此架构下，智能体不再受限于预先生成的静态记忆，而是基于不断演进的会话状态，动态决定何时通过增强的代码检索引擎获取更多上下文，何时进行内部推理，从而在复杂 IDE 环境中实现了更高的决策准确率

检索增强生成(RAG)

检索增强生成（Retrieval-Augmented Generation, RAG）技术的诞生，最初是为了解决大语言模型依赖静态预训练数据而导致的信息滞后和知识“幻觉”问题 。然而，随着技术栈从被动的问答系统向自治的智能体系统升级，RAG 的形态和定位发生了根本性的变革，演化出了智能体化检索增强生成（Agentic RAG） 。

Agentic RAG 与 传统 RAG 的核心差异

传统 RAG 的工作流是高度线性且静态的。当用户输入问题时，系统将其直接转化为向量，在数据库中进行一次性检索（One-shot retrieval），然后将提取到的文档片段机械地拼接到上下文中并交给大模型生成答案 。在这个过程中，系统是被动的，无法判断检索到的信息是否足以回答问题，也无法进行交叉验证 。

相比之下，Agentic RAG 将大语言模型的角色从“被动的文本生成器”提升为“主动的知识策展人与行动者” 。在 Agentic RAG 架构中，检索只是智能体工具箱中的一个可选项。智能体会自主评估当前任务的信息需求，制定多步检索计划，并根据阶段性检索结果动态调整后续的查询策略 。

下表详细总结了两者的工程特征对比：

工程维度 Traditional RAG (传统 RAG) Agentic RAG (智能体化 RAG)
控制流机制 单向线性流程（查询 -> 检索 -> 生成） 。 动态循环迭代，具备条件分支和自我校验的多步决策闭环 。
查询构建能力 严重依赖用户输入的质量，查询语义通常保持不变 。 智能体会自主将复杂问题分解为多个子查询，甚至根据反馈纠正自身生成的检索词 。
数据源灵活性 通常强绑定于单一形态的向量数据库 。 能够跨越向量库、关系型数据库、外部API以及实时网页搜索引擎进行联合信息挖掘 。
可靠性与测试 逻辑简单清晰，极易通过模拟底层数据库返回进行确定的单元测试 。 状态空间庞大，由于高度的自治性，难以进行覆盖全面的集成测试，存在行为失控风险 。
计算成本与延迟 延迟极低，API 调用开销小，适合高并发的轻量级 FAQ 问答 。 由于多次触发大模型的规划和反思循环，导致推理延迟高、算力成本陡增 。