企业官网建设流程全解析

1. 从“hindsight”说起：为什么我们需要给 Agent 装上“后视镜”

第一次看到 “hindsight” 这个词，是在给一个基于 LLM 的自动化工作流做复盘的时候。当时团队里有个 Agent 总是重复犯同一个错误：用户上周明确说过“不要给我推 Python 2 的兼容方案”，结果这周它又推了一遍。排查了半天，发现问题不在模型本身，而在于这个 Agent 压根没有“记忆”——每次对话都是全新的开始，历史上下文一超长就被截断，更别提跨会话记住用户偏好。

这就是 hindsight 要解决的核心问题。它不是某个具体的开源库名字，而是一类设计思路的统称：让 Agent 具备回溯性记忆能力，能够把过去发生过的交互、决策、反馈沉淀下来，在需要的时候重新调取，从而避免重复踩坑、重复解释、重复劳动。你可以把它理解成给 Agent 装了一面“后视镜”，开车的时候不用一直扭头看，但关键时刻瞥一眼就知道后面发生过什么。

围绕这个思路，现在社区里已经形成了一套相对成熟的技术栈组合：Agent Memory 负责存储与检索，LLM 负责理解与生成，MCP 负责工具与资源的标准化接入，Docker 负责环境隔离与一键部署。这四个词几乎就是当前 Agent 工程化的“四件套”。热搜里出现的 tencentdb agent memory、agent 存储 working memory、mcp 协议、docker compose 这些，本质上都是在讨论同一件事的不同切面。

这篇文章适合谁看？如果你正在做 LLM 应用，发现 Agent “记性差”“上下文一长就崩”“换个会话就失忆”，或者你听说过 MCP 但还没搞明白它和普通 API 有什么区别，又或者你想用 Docker 把整套记忆系统跑起来但卡在环境配置上，那这篇内容就是给你写的。我会从设计思路讲到落地实操，把踩过的坑和验证过的方案都摊开说。

2. 核心概念拆解：Memory、LLM、MCP、Docker 各自扮演什么角色

2.1 Agent Memory 到底是什么：不是简单的聊天记录堆叠

很多人第一次做 Agent 记忆，就是把历史对话拼成一个超长字符串塞进 prompt。这种做法在对话轮次少的时候能用，一旦超过十几轮，token 消耗爆炸不说，模型还会“迷失在中间”——开头和结尾的信息记得住，中间的关键约束反而被忽略了。

真正的 Agent Memory 要解决三个层次的问题。第一层是存储：记忆放在哪里？内存、Redis、向量数据库、还是关系型数据库？第二层是检索：给定当前 query，怎么从海量历史里捞出最相关的那几条？第三层是更新与遗忘：旧信息什么时候该被覆盖、什么时候该被降权、什么时候该彻底删除？

热搜里提到的 “working memory” 和 “tencentdb agent memory” 其实指向了两种不同的记忆形态。Working memory 更像人的短期记忆，容量有限、更新频繁，通常放在内存或高速缓存里，服务于当前会话的即时推理。而长期记忆则需要持久化，可能落在向量库或关系型数据库里，跨会话存活。一个设计良好的 Agent 系统，往往是短期记忆和长期记忆配合使用：短期记忆保证当前对话的连贯性，长期记忆保证跨会话的个性化。

这里有个容易被忽略的点：记忆不是越多越好。我见过一个项目把用户所有历史对话全量存进向量库，结果检索出来的“相关记忆”里混了大量噪音，反而干扰了模型判断。后来改成按主题聚类、按时间衰减加权，效果才稳定下来。所以记忆系统的核心不是“存”，而是“筛”。

2.2 LLM 在记忆系统里的真实定位：不只是生成器

热搜里有个很有意思的表述：“llm 的 token 三个点 key 我是谁、query 我在找什么、value 我能提供什么”。这其实是在用注意力机制的 QKV 类比记忆检索：Query 是当前问题，Key 是历史记忆的索引，Value 是记忆的具体内容。这个类比虽然简化了，但抓住了本质——LLM 在记忆系统里既是消费者，也是生产者。

作为消费者，LLM 接收检索回来的记忆片段，结合当前输入生成回答。作为生产者，LLM 还要负责从对话中抽取“值得记住的信息”。比如用户说“我下周三要去上海出差”，这句话里“下周三”“上海”“出差”就是需要结构化存储的实体。这个抽取过程通常由 LLM 完成，因为规则引擎很难覆盖自然语言的多样性。

但这里有个坑：不要让 LLM 同时做抽取和生成。早期我试过在一个 prompt 里让模型既总结历史又回答当前问题，结果模型经常顾此失彼，总结得潦草，回答也敷衍。后来拆成两个独立调用——一个专门做记忆抽取和摘要，一个专门做回答生成——质量立刻上来了。多花的那点 token 成本，远比回答质量下降划算。

另外，热搜里提到的 “llm as judge” 在记忆系统里也有用武之地。当两条记忆冲突时（比如用户先说喜欢红色，后来说喜欢蓝色），可以用 LLM 来判断哪条更新、哪条该保留，而不是简单地按时间戳覆盖。这种“记忆仲裁”机制在长期运行的 Agent 里非常关键。

2.3 MCP 协议：为什么它不是“硬件协议”但胜似标准接口

热搜里有人问“mcp 是软件协议，硬件协议那个概念叫什么来着”，这个问题本身就说明 MCP 的定位容易让人困惑。MCP 全称 Model Context Protocol，是一个软件层的通信协议，类比的话更像 USB-C——它不关心你插的是硬盘还是显示器，只规定接口的形状和通信规则。硬件协议那个概念通常叫“物理层协议”或“总线标准”，和 MCP 不在一个层面。

MCP 要解决的问题是：LLM 应用怎么标准化地接入外部工具和数据源。在没有 MCP 之前，每接一个工具就要写一套适配代码，接十个工具就是十套，维护成本极高。MCP 把这些适配抽象成统一的 Server-Client 模型：工具提供方实现一个 MCP Server，应用方作为 MCP Client 去连接，双方通过标准化的 JSON-RPC 消息通信。

热搜里出现的 “browser use mcp 跟 playwright mcp 有什么区别”“codex 接入 figma mcp 怎么授权”“dify 浏览器 mcp” 这些，都是在具体场景下使用 MCP 的案例。Browser Use MCP 通常封装的是浏览器自动化能力，Playwright MCP 则是把 Playwright 的 API 暴露成 MCP 工具，两者粒度不同。至于授权问题，MCP 本身有 OAuth 相关的流程设计，但具体到 Figma、蓝湖这类第三方服务，还是要看对方是否提供了标准的授权端点。

在实际项目里，MCP 最大的价值是让记忆系统可以“即插即用”。比如你把向量数据库封装成一个 MCP Server，那么任何支持 MCP 的 Agent 框架都能直接调用它做记忆检索，不需要为每个框架重写一遍集成代码。这也是为什么热搜里会出现 “ruoyi-vue-pro 合并 mcp 功能” 这样的词——传统业务系统也在尝试通过 MCP 把自己变成 LLM 可调用的工具。

2.4 Docker 的角色：不是可选项，而是工程化的起点

热搜里 docker 相关的词占了将近三分之一：docker 安装、docker desktop、docker compose、docker 网络不通、windows 安装 docker、virtualization support not detected……这说明什么？说明大部分人在把 Agent 记忆系统跑起来的第一步就卡住了。

Docker 在这个技术栈里的价值很直接：Agent Memory 依赖的组件太多了——向量数据库、关系数据库、缓存、消息队列，可能还有 MCP Server 和 LLM 网关。如果每个都手动装，环境冲突能折腾一整天。用 Docker Compose 把这些服务编排在一起，一条命令拉起全套，这才是工程化的做法。

但 Docker 在 Windows 上的坑确实多。“virtualization support not detected” 这个报错我见过太多次了，本质是 BIOS 里的虚拟化支持没开，或者 Hyper-V 和 WSL2 冲突。Docker Desktop 的安装教程网上到处都是，但很少有人讲清楚：如果你用 WSL2 后端，Docker 的数据卷性能会比 Linux 原生差一截，向量数据库这种 IO 密集型的服务尤其明显。所以生产环境我还是推荐 Linux 原生 Docker，开发环境用 Docker Desktop 图个方便就行。

3. 记忆系统的架构设计：从“能记住”到“记得对”

3.1 三层记忆架构的取舍与实现

在折腾过几套方案之后，我目前比较推荐的是三层记忆架构：工作记忆、情景记忆、语义记忆。这个划分借鉴了认知科学的模型，但在工程上非常好落地。

工作记忆对应当前会话的上下文窗口，通常就是最近 N 轮对话加上系统提示。它的特点是读写极快、容量有限、会话结束即释放。实现上直接放在内存里就行，不需要持久化。关键是控制好窗口大小——我一般按 token 数而不是轮数来截断，因为一轮对话可能很长也可能很短，按轮数截断容易要么浪费要么不够。

情景记忆对应具体发生过的事件，比如“用户在第 3 次会话中要求把报告格式改成 Markdown”。这类记忆需要持久化，通常存在关系型数据库或文档数据库里，带上时间戳、会话 ID、用户 ID 等元数据。检索时按时间范围和实体过滤，不需要向量检索，因为情景记忆的查询往往是精确的。

语义记忆对应从多个情景中抽象出来的规律，比如“这个用户偏好简洁的回复风格”。这类记忆需要向量化存储，检索时用相似度匹配。语义记忆的更新频率低，但价值高，因为它直接影响 Agent 的长期行为策略。

三层之间的流转关系是这样的：工作记忆里的内容定期摘要后写入情景记忆；情景记忆积累到一定量后，由 LLM 归纳出语义记忆；语义记忆在每次新会话开始时被检索出来，注入工作记忆作为背景。这个流转过程不需要实时，可以异步做，避免拖慢主流程。

3.2 向量检索的坑：相似度不等于相关性

说到语义记忆就绕不开向量检索。很多人以为把文本 embedding 之后存进向量库，查询时按余弦相似度排序就完事了。实际用下来，相似度高的记忆经常是不相关的。

举个例子，用户问“帮我写个 Python 脚本”，向量检索可能召回一条“用户之前问过 Python 2 的兼容问题”的记忆。这两句话在 embedding 空间里确实很近，但当前场景下这条记忆是干扰项，因为用户现在用的是 Python 3。问题出在 embedding 模型只捕捉了语义相似性，没有捕捉时间、场景、意图这些维度。

解决办法是混合检索：向量相似度只作为一个信号，还要结合时间衰减、实体匹配、意图分类等因子做加权排序。我通常会给每条记忆算一个综合得分：

score = w1 * vector_similarity + w2 * time_decay + w3 * entity_match + w4 * intent_match

权重需要根据业务调，没有万能值。时间衰减函数我一般用指数衰减，半衰期设成 7 天左右，因为大部分用户偏好在一周内是稳定的。实体匹配就是看当前 query 里的实体和记忆里的实体有没有重叠，这个用简单的字符串匹配或 NER 就能做。

还有一个细节：embedding 模型的选择会影响检索质量。中文场景下，有些开源 embedding 模型在短文本上表现不错，但长文本就拉胯。如果记忆片段比较长，要么换模型，要么先做摘要再 embedding。我试过用同一个模型分别对原文和摘要做 embedding，摘要版本的检索准确率反而更高，因为噪音少了。

3.3 记忆的写入策略：什么时候该记，什么时候该忘

记忆系统的难点不在读，在写。写得太少，Agent 记不住东西；写得太多，噪音淹没信号。我总结了几条写入策略，实测下来比较稳。

显式指令优先：用户说“记住”“以后都这样”“不要再”这类词时，必须写入，而且优先级最高。这类记忆通常直接进语义记忆层，不经过情景记忆的中间态。

重复模式触发：同一个偏好或约束在多次会话中出现，自动升级为语义记忆。比如用户三次要求“回复用中文”，那就不用再问了，直接作为默认策略。这个计数逻辑可以放在情景记忆层，每次写入时检查同类记忆的出现频次。

冲突检测与覆盖：新记忆和旧记忆矛盾时，不能简单覆盖。我的做法是保留两条，但给新记忆更高的权重，同时记录冲突事件。如果后续用户再次确认新偏好，旧记忆才降权到忽略。这个机制避免了用户偶尔说错话导致记忆被污染。

遗忘机制：不是所有记忆都值得永久保留。我一般设一个 TTL，情景记忆默认保留 30 天，语义记忆保留 180 天。超过 TTL 的记忆不是直接删除，而是归档到冷存储，检索时不参与排序，但需要时可以手动调取。这样既控制了活跃记忆的规模，又保留了追溯能力。

注意：记忆写入一定要做去重。我见过一个系统因为没做去重，同一个用户偏好被存了上百遍，检索时全是重复内容，白白消耗 token。

4. 用 Docker Compose 把记忆系统跑起来：完整实操

4.1 服务编排设计：哪些组件必须容器化

一套完整的 Agent Memory 系统，我通常会拆成这几个服务：向量数据库、关系数据库、缓存、MCP Server、LLM 网关。不是每个项目都需要全部，但这是比较通用的基线。

向量数据库选型上，Milvus 功能全但重，Qdrant 轻量且 API 友好，Chroma 适合原型但生产环境性能一般。我目前默认用 Qdrant，单容器就能跑，Docker Compose 里配置也简单。关系数据库用 PostgreSQL，存情景记忆和元数据，顺便还能当 MCP Server 的配置存储。缓存用 Redis，存工作记忆和会话状态。MCP Server 自己写一个，把向量检索和数据库查询封装成标准工具。LLM 网关可以用 LiteLLM 或 One-API，统一管理多个模型提供方的接入。

Docker Compose 的好处是这些服务的网络、卷、依赖关系都能声明式地管理。下面是我常用的一个 compose 文件骨架，你可以直接拿去改：

version: "3.9" services: qdrant: image: qdrant/qdrant:latest ports: - "6333:6333" volumes: - qdrant_data:/qdrant/storage restart: unless-stopped postgres: image: postgres:16 environment: POSTGRES_USER: agent POSTGRES_PASSWORD: agent_pass POSTGRES_DB: agent_memory ports: - "5432:5432" volumes: - pg_data:/var/lib/postgresql/data restart: unless-stopped redis: image: redis:7-alpine ports: - "6379:6379" volumes: - redis_data:/data restart: unless-stopped mcp-server: build: ./mcp-server ports: - "8080:8080" environment: QDRANT_URL: http://qdrant:6333 DATABASE_URL: postgresql://agent:agent_pass@postgres:5432/agent_memory REDIS_URL: redis://redis:6379 depends_on: - qdrant - postgres - redis restart: unless-stopped volumes: qdrant_data: pg_data: redis_data:

这个编排里，depends_on只保证启动顺序，不保证服务就绪。实际使用时，MCP Server 里要做重试逻辑，或者加 healthcheck。我一般会在 MCP Server 启动时轮询依赖服务的健康端点，全部就绪后再开始监听。

4.2 Windows 环境下的 Docker 安装避坑指南

热搜里 “windows 安装 docker”“virtualization support not detected docker desktop failed to start” 这些词出现频率极高，说明 Windows 用户踩坑是普遍现象。我把关键步骤和坑点列一下。

首先确认 CPU 虚拟化在 BIOS 里是开启的。任务管理器 -> 性能 -> CPU，看“虚拟化”那一项是不是“已启用”。如果是“已禁用”，重启进 BIOS 开一下，不同主板位置不一样，一般在 Advanced 或 Security 菜单里。

然后装 WSL2。管理员权限打开 PowerShell，运行wsl --install，装完重启。这一步会顺便把 WSL2 设为默认版本。如果你之前装过 WSL1，需要手动转换：wsl --set-default-version 2。

接着装 Docker Desktop。官网下载安装包，安装时勾选“Use WSL 2 instead of Hyper-V”。装完启动，如果报 “virtualization support not detected”，大概率是 Hyper-V 和 WSL2 冲突了。解决办法是在“启用或关闭 Windows 功能”里，确保 Hyper-V 和“虚拟机平台”都勾上，然后重启。

还有一个常见问题是 Docker 网络不通。Windows 下 Docker Desktop 的网络走的是 WSL2 的虚拟网卡，有时候 DNS 解析会出问题。如果容器里访问不了外网，可以在 Docker Desktop 设置里改 DNS 为8.8.8.8或114.114.114.114。另外，WSL2 的内存默认会占用宿主机一半，跑向量数据库这种吃内存的服务时，建议在用户目录下建.wslconfig文件限制一下：

[wsl2] memory=8GB processors=4

4.3 MCP Server 的实现要点：把记忆能力暴露成标准工具

MCP Server 的核心是把记忆的读写操作封装成 LLM 可以调用的工具。一个最小可用的记忆 MCP Server 通常暴露这几个工具：store_memory、retrieve_memory、forget_memory、list_memories。

实现上，我用 Python 的mcp库来写，它提供了 Server 端的标准接口。关键点在于工具的参数设计要符合 LLM 的调用习惯。比如retrieve_memory的参数不要设计成vector或embedding这种底层概念，而是query（自然语言查询）、top_k（返回条数）、memory_type（记忆类型过滤）。LLM 不需要知道背后是向量检索还是关键词匹配，它只需要表达“我要找什么”。

from mcp.server import Server from mcp.types import Tool, TextContent server = Server("agent-memory") @server.tool() async def retrieve_memory(query: str, top_k: int = 5, memory_type: str = "all") -> list[TextContent]: """根据自然语言查询检索相关记忆""" embedding = await embed(query) results = await qdrant_search(embedding, top_k, memory_type) return [TextContent(type="text", text=format_results(results))] @server.tool() async def store_memory(content: str, memory_type: str = "episodic", metadata: dict = None) -> TextContent: """存储一条新记忆""" embedding = await embed(content) await qdrant_upsert(embedding, content, memory_type, metadata) return TextContent(type="text", text="Memory stored successfully")

这里有个细节：store_memory的memory_type参数让 LLM 自己判断这条记忆是情景记忆还是语义记忆。实测下来，LLM 的判断准确率还不错，因为情景记忆通常包含具体时间地点，语义记忆通常是抽象偏好。如果判断错了，后续检索时也能通过类型过滤纠正。

MCP Server 的部署方式有两种：stdio 和 HTTP。stdio 适合本地开发，Client 直接启动 Server 进程通信。HTTP 适合容器化部署，Server 独立跑在一个容器里，多个 Client 共享。我推荐生产环境用 HTTP，因为可以独立扩缩容，也方便加认证和限流。

4.4 与 LLM 框架的对接：以常见 Agent 框架为例

MCP Server 跑起来之后，下一步是让 Agent 框架连上它。不同框架的接入方式略有差异，但核心都是配置 MCP Server 的地址和认证信息。

以常见的 LangChain 风格框架为例，你需要一个 MCP Client 适配器，把 MCP 工具转换成框架能识别的 Tool 对象。然后在 Agent 初始化时把这些 Tool 注册进去。关键配置项包括：Server 的 URL、超时时间、重试次数。超时时间我一般设 30 秒，因为向量检索偶尔会慢，设太短容易误报失败。

对接过程中最容易出问题的是工具描述的清晰度。LLM 决定调用哪个工具，完全依赖工具的名称和描述。如果retrieve_memory的描述写成“检索记忆”，LLM 可能不知道什么时候该用。改成“当需要回忆用户之前的偏好、历史决策或已确认的事实时，调用此工具检索长期记忆”，调用准确率会明显提升。

还有一个实践技巧：在系统提示里明确告诉 LLM 记忆工具的存在和使用时机。比如“在回答涉及用户个人偏好或历史上下文的问题前，先调用 retrieve_memory 检索相关记忆”。这比单纯依赖工具描述更有效，因为系统提示的优先级更高。

5. 常见问题与排查技巧实录

5.1 记忆检索不准的排查思路

检索不准是最常见的问题，表现是召回的记忆和当前 query 不相关，或者相关记忆没被召回。排查按这个顺序来。

先看 embedding 模型是否适合当前语言和领域。中文短文本用text-embedding-3-small通常够用，但如果你的记忆里有大量专业术语，通用模型可能表现不佳。可以拿一批标注好的 query-记忆对做评测，算 recall@k，低于 0.7 就考虑换模型或做微调。

再看分块策略。记忆片段太长，embedding 会稀释关键信息；太短，又丢失上下文。我一般把单条记忆控制在 100 到 300 字之间，超过就摘要。摘要由 LLM 做，prompt 里明确要求保留实体、时间、约束条件。

然后检查检索参数。top_k设太小会漏，设太大引入噪音。我通常先用 20 召回，再用重排序模型筛到 5 条。重排序模型可以用 cross-encoder，虽然慢一点，但准确率提升明显。

最后看时间衰减权重。如果用户偏好变化快，衰减要快；如果偏好稳定，衰减可以慢。这个没有通用值，需要根据业务数据调。

5.2 Docker 环境下的典型故障速查

这个表里的问题我基本都遇到过。其中“容器间网络不通”最隐蔽，因为depends_on只保证启动顺序，不保证网络就绪。我的做法是在 MCP Server 里加一个启动检查，轮询 Qdrant 的/healthz端点，通了再开始服务。

5.3 记忆污染与隐私处理的注意事项

记忆系统跑久了，难免会存进一些不该存的东西。比如用户在调试时随口说的测试数据，或者包含敏感信息的对话片段。这些如果被当成长期记忆保留，后续检索出来会很尴尬。

我的做法是在写入前加一层过滤。用 LLM 判断这条记忆是否值得长期保留，prompt 里明确排除测试数据、临时指令、敏感信息。同时给每条记忆打上来源标签，如果是测试会话产生的，TTL 设短一点，比如 1 天。

隐私方面，用户 ID 和会话 ID 要做脱敏存储，检索时用哈希值匹配而不是明文。如果系统面向多租户，记忆必须按租户隔离，向量库的 collection 或 partition 要分开，避免跨租户检索。

提示：定期审计记忆库是个好习惯。我一般每周跑一次脚本，统计记忆总量、类型分布、检索命中率，发现异常增长就排查写入逻辑。

5.4 性能优化的几个实操技巧

记忆系统的性能瓶颈通常在 embedding 计算和向量检索上。优化从这两处入手。

Embedding 计算可以批量做。写入时不要一条一条算，攒够一批（比如 32 条）一次性调 API，吞吐能提升好几倍。如果用的是本地 embedding 模型，开 GPU 加速，batch size 调到显存允许的上限。

向量检索的优化主要是索引参数。Qdrant 默认的 HNSW 索引在数据量小于 10 万条时够用，超过之后要调m和ef_construct参数。m控制图的连接度，越大越准但越占内存；ef_construct控制构建时的搜索范围，越大越准但构建越慢。我一般设m=16、ef_construct=100，在准确率和资源之间比较平衡。

缓存也很关键。相同的 query 在短时间内可能重复出现，把检索结果缓存到 Redis 里，TTL 设 5 分钟，能省不少 embedding 调用。注意缓存 key 要包含 query 和过滤条件，否则会串结果。

6. 从 hindsight 到 foresight：记忆系统的演进方向

把记忆系统跑通之后，你会发现 Agent 的行为模式发生了质变。它不再是一个每次从零开始的工具，而是一个有“经验”的协作者。用户不用重复解释背景，Agent 能主动引用之前的决策，甚至能提醒用户“你上次说这个方案有性能问题，要不要再确认一下”。

但 hindsight 只是第一步。真正成熟的记忆系统应该具备 foresight 能力——不只是回忆过去，还能基于过去预测未来。比如根据用户的历史行为模式，预判他下一步可能需要什么信息，提前把相关记忆加载到工作记忆里。这需要在检索之外加一层预测模型，目前还在探索阶段，但方向是清晰的。

另一个值得关注的方向是记忆的可解释性。当 Agent 做出一个决策时，能说清楚“我是基于哪几条记忆做出的这个判断”。这在企业场景里尤其重要，因为审计和合规需要追溯决策依据。实现上可以在检索结果里带上记忆 ID 和来源，生成回答时让 LLM 引用这些 ID。

最后分享一个我在实际项目里验证过的小技巧：给记忆加“置信度”标签。用户明确说过的偏好置信度高，从行为推断出来的置信度低。检索时按置信度加权，能有效减少误判。这个标签可以由 LLM 在写入时判断，也可以根据后续反馈动态调整。踩过几次记忆误判的坑之后，这个机制帮我省了很多调试时间。