企业官网建设流程全解析

如果你也在折腾AI Agent，多半会有同感：单轮问答早就不是瓶颈，真正让人头疼的是让它稳定地干完一整条链路——记住用户十分钟前说过的话，自主决定调哪个工具，还能源源不断地接入新的数据源。我最近在重构Hermes Agent时，把会话、工具、MCP、记忆这四个能力全翻了一遍，过程中踩了不少坑，也沉淀了一套可以复用的设计思路。这篇文章不会讲太多模型本身有多能打，而是把这四块掰开揉碎，告诉你它们分别解决什么问题、内部怎么接线、哪些细节最容易翻车。计划给Agent加完整能力、或者正在给助理类应用做架构升级的开发者，应该都能从中找到一些参考。

1. 能力版图：会话、工具、MCP、记忆各管什么

1.1 先分清“模型能力”和“Agent能力”

很多人以为Agent强不强，完全取决于底层大模型的聪明程度。这个观点对了一半。模型能力决定的是“推理天花板”，比如同样的需求，能力强的模型能更快理解意图、更准确地规划步骤；但真正让一个Agent能落地使用的，是它会不会聊天、能不能干活、能不能连上用户已有的系统、能不能记住上次聊到哪。换句话说，模型像刚入职的高材生，聪明但缺乏业务上下文和办公环境。Agent能力就是给他配齐工位、电话、资料库和一套工作流程的人。

Hermes Agent把能力收敛到四个维度，不是拍脑袋选的。会话解决“怎么说”，工具解决“怎么干”，MCP解决“怎么连外部世界”，记忆解决“怎么记住和怎么想起来”。四者单独拎出来都不算新东西，但把它们按一个统一架构组织起来，Agent才从“聊天机器人”变成“能持续执行任务的数字员工”。

1.2 四者在完整链路中的位置

我先用一条文字链路说明它们在一次任务里如何配合：

用户输入 → 会话管理（组装上下文、判断当前状态）→ Agent决策（选择工具或直接回答）→ 工具执行 / MCP服务端调用 → 结果回填会话 → 记忆层异步更新 → 下次会话按需召回

从这条链路能看出，会话是唯一入口，所有输入输出都过它；工具和MCP是出口，负责把决策变成实际动作；记忆则贯穿整个生命周期，既要读取也要写入。经常有人把工具和MCP混为一谈，我后面会详细讲它们的关系——简单说，工具是Agent内部注册的函数，MCP则是外部服务按标准协议暴露能力的通道，MCP里的能力到达Agent侧后，本质上也是以工具的形式参与决策。

下面这张表可以快速建立整体认知：

理解了这个版图，后面的每个模块就都有明确的定位了。

2. 会话模块：多轮对话的上下文与状态控制实操

2.1 三个隐藏痛点：膨胀、漂移、失稳

对话模块看起来简单，无非是把用户消息和模型回复拼进历史。但实际操作中，最先暴露的是上下文膨胀问题：每轮请求如果都把全部历史原样塞给模型，token消耗会随着对话轮次线性增长，等窗口逼近上限，模型就开始“捡了芝麻丢西瓜”，把早期最重要的指令忽略掉。

第二个痛点是主题漂移。用户可能一开始说“帮我准备下周的项目汇报”，中间聊了十分钟天气和午饭，最后又说“把PPT里第二页改成柱状图”。如果没有会话层做锚定，模型很可能把“准备汇报”这个主线任务忘掉，专注去回答那些零散话题。

第三个痛点是状态失稳。用户中途修改约束，比如先说“用邮件发送”，过一会儿改成“还是生成下载链接吧”。如果会话层不维护显式状态，模型可能在同一次任务里反复横跳，甚至给出互相矛盾的结果。这三个问题，靠提示词是压不住的，必须用代码层去管理。

2.2 上下文压缩的三种实战策略

我试过不少上下文管理方案，真正稳定的是下面三种组合：

• 滑动窗口：只保留最近N轮对话原文，简单直接，适合交互频次不高的场景。
• 摘要压缩：定期调用一次模型，把旧的历史对话压缩成结构化摘要，保留关键指令、用户偏好、已完成步骤和待办事项。
• 指令锚定：把系统提示词和用户的核心约束固定在窗口最前端，保证模型每轮都能看到“主线任务”。

这三者不是互斥的。我的习惯是“指令锚定 + 滑动窗口 + 摘要压缩”三层一起用。比如一个16k上下文的模型，预算分配大概是：系统提示词20%，近期对话50%，历史摘要20%，记忆检索结果10%。这不是一个放之四海皆准的数字，但能作为起点——如果发现模型老忘记早期指令，优先压缩的是历史摘要部分，而不是砍系统提示词。

还有个小细节容易被忽略：摘要不要只压缩“用户说了什么”，还要压缩“系统已经答了什么、任务做到哪一步”。否则下次模型只知道用户要什么，不知道之前已经给过什么，就会重复劳动。

2.3 会话状态机设计

Agent会话不是单纯聊天，是需要推进度的。我在Hermes Agent里给会话加了一个显式状态字段，取值范围大致有：collecting（收集需求）、tool_executing（工具执行中）、reviewing（结果确认）、done（任务结束）。模型在每一轮决策之前，会先读取当前状态，判断现在允许做什么动作。

举个例子，工具执行是异步的，模型已经发出了“创建日程”的调用，但服务端还没返回结果。这时候用户如果追问“帮我看看明天有没有空”，会话层应该根据状态机判断：当前处于tool_executing，新请求需要排队，而不是让模型同时开两个互相干扰的任务。等工具结果回来，再恢复上下文，把结果交给模型继续处理。

使用状态机最大的好处，是让流程控制不依赖模型的“自觉”。你让模型凭感觉记住当前任务阶段，十次里总有几次会漂移；但用代码维护状态，行为就是确定性的。我在实践中甚至会把状态机的当前值作为一条系统级消息拼进上下文，让模型明确知道“现在正处于结果确认阶段，不要主动发起新任务”。

2.4 流式输出与中断恢复

这方面的坑在客户端联调时最容易暴露。模型在调用工具之前会先输出一段“好的，我来帮你安排日程”，然后请求被中断，转到工具执行；等工具返回结果后，模型又继续输出“已经创建成功”。这两段输出之间如果处理不当，用户会看到前半句话之后突然卡住，体验非常割裂。

我的做法是在会话层维护一个输出缓冲区。前一段流式输出结束后，先把内容缓存，等工具结果回来后，让模型基于“前文已输出内容 + 工具结果”继续生成，再由会话层把两部分拼接成一条完整消息。用户中途打断的情况也要处理，比如正在流式输出时用户说了“等等，改成明天”，这时候要能终止当前生成、清空缓冲、把用户的修正话术作为最新一轮输入重新进入决策流程。

3. 工具模块：函数调用的声明、执行与编排细节

3.1 工具定义决定了模型能不能选对

很多人以为给模型注册工具就是写个函数名加参数列表，结果评测时发现模型频繁选错工具，或者把参数填得乱七八糟。问题八成出在工具定义上。以日程创建为例，这样定义会明显提高选择准确率：

{ "name": "create_calendar_event", "description": "创建日历日程。当用户提到安排会议、提醒、预约行程时使用；仅在用户表达明确的时间意图时使用，不要在对时间只是随口一提时触发。", "parameters": { "type": "object", "properties": { "summary": { "type": "string", "description": "日程标题，尽量简短" }, "start_time": { "type": "string", "format": "date-time", "description": "开始时间，ISO 8601格式，含时区" }, "attendees": { "type": "array", "items": { "type": "string" }, "description": "参与人邮箱列表，可以为空" } }, "required": ["summary", "start_time"] } }

关键点有三个：工具名用“动词+名词”的清晰结构，不要用缩写；description里不仅要写“什么时候用”，还要写“什么时候不要用”，这个负例对模型帮助极大；参数要有明确格式约束和示例，模型对ISO时间格式的把握并不稳定，你写明格式，它出错概率就低一个量级。

3.2 调用链路的可靠性设计

工具调用的标准链路是：模型返回结构化tool_calls→ 解析出工具名和参数 → 构造工具结果 → 以role: "tool"消息回传给模型。这里面最容易被忽视的是tool_call_id。如果工具结果不回传对应的ID，模型就无法把工具结果和之前发起的调用对齐，轻则重新调用一次，重则逻辑混乱。

我在实际联调中还碰到过另一个高频问题：模型偶尔会返回不严格的JSON，比如参数末尾多一个逗号、字符串里混入换行符。这时候不要直接用严格解析器，一报错就中断整个请求，而应该加一层宽松解析容错，先尝试标准解析，失败后再做清洗和二次解析。工具执行本身的异常，也要转换成模型能读懂的文本格式返回，比如“数据库连接超时，请稍后重试”，而不是把堆栈直接怼给模型。

3.3 多个工具调用的并发与幂等

很多模型支持一次返回多个tool_calls。比如用户说“帮我约明天下午的会议室，并通知王工”，模型可能同时发起“查会议室”和“查联系人”两个调用。这两个调用互相独立，应该并发执行，而不是串行排队，否则响应延迟会翻倍。

并发执行后，还有一个必须考虑的幂等问题。模型有时会因为超时或网络抖动，对同一个工具发起重复调用。我在Hermes Agent设计时，给每个工具执行加了一层请求ID去重：同一轮决策内，相同工具相同参数只执行一次，后续重复请求直接返回第一次的结果。否则用户会在不知情的情况下收到两条重复日程。

3.4 工具数量的克制与分组加载

工具不是注册得越多越好。模型可选工具超过一定数量后，选择准确率会明显下降，token开销也会猛增。我见过一些项目一口气注册上百个工具，结果模型频繁调错，排查起来非常痛苦。更合理的做法是分组加载：先给模型暴露一组“导航级”工具，像是search_knowledge、list_available_features、execute_task，模型根据第一轮意图决定往哪个方向深入，然后再动态加载对应的子工具集。

这个思路类似手机桌面：你不会把所有App平铺一屏，而是先看分类文件夹，再点进具体应用。工具分组同样能减少模型的选择压力，同时降低每次请求的token消耗。

4. MCP模块：用标准协议把外部能力接进Agent

4.1 为什么有了工具还要MCP

如果Agent只服务自己内部的几个函数，工具机制完全够用。但现实中的Agent往往要连数据库、文件系统、内部API、第三方SaaS。每接一个数据源，传统做法是写一个定制适配器：拉数据、格式化、注册成工具。接得多了，适配器代码越来越难维护，而且每家的认证方式、数据格式都不一样，接口变一下，就要跟着改一轮。

MCP（Model Context Protocol）就是为了解决这个“接口碎片化”问题而出现的标准协议。它把外部能力抽象成统一的工具、资源、提示词和采样四类原语，Agent只需要实现一次MCP客户端，就能接入所有符合协议的MCP服务端。打个比方：工具函数是一个个插座，MCP是统一的插座规格和配电箱，你不再关心插座那头接的是空调还是烤箱，只要规格一致就能通电。

4.2 MCP核心概念与消息结构

MCP的基础传输采用JSON-RPC 2.0，支持stdio和streamable HTTP两种方式。stdio适合本机进程，比如Agent和文件服务跑在同一台机器上；HTTP适合远程服务，比如内部知识库、云端服务这些需要通过网络访问的场景。

它的核心原语可以这样理解：

初始化握手是MCP接入最容易出错的地方。客户端需要先发送initialize请求，带上协议版本号和服务端能力声明，服务端会回应自己支持的版本和能力集；随后客户端再发送initialized通知进场。很多人跳过了版本协商，直接请求工具列表，结果服务端返回空列表或者协议错误，原因就是握手没有完成。

4.3 接入一个MCP服务端的完整步骤

一个典型的MCP配置长这样：

{ "mcpServers": { "local_files": { "transport": "stdio", "command": "npx", "args": ["-y", "mcp-server-filesystem"], "env": { "ALLOWED_DIRS": "/data/workspace" } }, "internal_notes": { "transport": "http", "url": "https://internal.example.com/mcp", "headers": { "Authorization": "Bearer ${ACCESS_TOKEN}" } } } }

接入流程本身不复杂：根据配置启动MCP客户端，完成初始化握手，然后通过tools/list动态获取服务端暴露的工具列表，拿到工具schema后，Agent侧不需要写死任何工具的调用逻辑，直接根据模型决策，通过tools/call把参数转发给服务端，再把结果返回模型。整个过程里唯一要提前确认的，是协议版本和认证方式。

这里要特别强调一下工具发现机制。传统的工具注册是在代码里写死的，想增删一个工具要重新发版；MCP的服务端可以动态返回工具列表，Agent能在每次会话启动时重新拉取，这意味着外部能力是热更新的。服务端新增了一个“查询订单”工具，客户端代码完全不用动，模型下一轮就能调用到。

4.4 权限边界与安全设计

MCP把外部能力接入变得更方便，但并不意味着权限可以放松。我的原则是：Agent层只做转发，MCP服务端必须做二次校验。文件类MCP要限制可访问目录，数据库类MCP要使用最小权限的独立账号，HTTP类MCP要校验用户身份和请求范围。模型生成的参数并不总是可靠的，任何可能产生副作用的能力（删除、覆盖、发送、转账）都应在地服务端再做一次拦截和确认。安全设计不在这一篇文章里展开，但它应该和功能同步设计，而不是补丁式追加。

5. 记忆模块：分层存储、检索与遗忘的落地经验

5.1 记忆的三种类型

记忆模块是Agent从“好用的工具”走向“靠谱的助手”的分水岭。我把它分成三层：短期记忆就是当前会话窗口里的对话历史，对应messages数组；工作记忆是正在执行的任务状态，包括目标、已完成步骤、下一步计划，对应会话状态机里的上下文栈；长期记忆则是会话结束之后仍然保留的信息，通常存在向量数据库里，比如用户偏好、历史偏好、关键事实。

三者的关系可以这样类比：短期记忆是桌面上的草稿纸，工作记忆是当前任务托盘，长期记忆是抽屉里的笔记本。没有工作记忆，Agent做着做着会忘掉当前任务；没有长期记忆，用户每次回来都要重新自我介绍。

5.2 长期记忆的写入策略

长期记忆不是把每句话都存进去。我在Hermes Agent里定义了四类值得写入的内容：用户偏好、事实性的个人信息、已完成的关键任务、明确的长期目标。写入之前要先经过一道“过滤+提纯”步骤，把工具执行的中间报错、一时的情绪表达、无意义的闲聊过滤掉，避免污染记忆库。

提纯这一步可以用规则，也可以让一个小模型来做。我更推荐用一个小模型做结构化抽取，输出“实体、关系、偏好、结论”这样的字段，然后由代码判断是否写入向量库。要注意写入时机：不要在会话进行到一半就急着写，任务结束、状态机进入done时统一写一次，效率和准确性都会更好。

5.3 分块、向量化与混合检索

长期记忆如果要支持语义检索，分块和索引策略很重要。我一般把每条记忆按512到1024字符分块，相邻块之间重叠约128字符，避免语义被切断。向量化时选择embedding模型，不光看维度，更要看它对中文和领域术语的召回效果。

检索侧的核心参数是top_k和相似度阈值。top_k我通常控制在5到20，阈值设在0.75左右，低于阈值的结果宁可不注入上下文，也不要硬塞给模型。混合检索的收益很高：BM25做稀疏检索负责精确匹配，向量检索做语义匹配，最后再用一个重排模型合并排序。这套组合在记忆召回率上明显优于单一向量检索。

5.4 记忆注入的位置

记忆检索出来之后，注入的位置也有讲究。我习惯把长期记忆放在系统提示词下方、历史对话上方，并且带时间戳。效果大概是这样：

【长期记忆（2025-06-12，来源：历史会话）】 用户偏好使用中文回复，项目汇报喜欢用柱状图，常用的会议室是A302。 用户当前目标：完成Q3季度汇报PPT初稿。

这样模型能清楚区分“这是旧记忆”和“这是当前对话”，不会把很久之前的偏好当成刚性指令，也不会把当前对话里的临时需求混进长期记忆。

5.5 遗忘与修正机制

记忆不是只增不改。用户说“我之前说的不对”时，系统要能降低旧记忆的权重；新旧记忆冲突时，以最近一次用户明确表达为准。我的做法是在记忆表里加一个软删除标记，同时保留修改历史，这样既能满足“忘记”的需求，也不至于物理删除导致追溯困难。时间衰减也要考虑进去，一条半年前的用户偏好，如果没有近期重复出现，检索权重要自动下调。

还有一个避坑经验是防止记忆“越积越乱”。建议给每次会话设定写入上限，比如最多写20条记忆，超出时触发合并，让模型把多条相关记忆压缩成一条。否则向量库里的碎片会越来越多，检索质量也随之下降。

6. 四大模块联调中的高频问题与排查速查

6.1 会话层的典型故障

最典型的症状是聊了几轮后模型“失忆”，明明开头交代过的重要约束，到第五轮像没听过一样。排查思路是先看请求体里的历史消息顺序和截断情况。如果发现早期指令被窗口截掉了，问题一定出在上下文压缩策略上；如果历史还在但模型仍然失忆，那往往是指令锚定没做好，系统提示词被塞到了窗口末尾。另一个故障是token消耗异常增长，通常是因为同一份内容既存在于会话历史里，又存在于记忆注入块里，重复放了两遍。

6.2 工具层的典型故障

模型“假装调用”工具是个很有趣的现象。比如模型直接输出“正在创建日程...”，却没有返回tool_calls结构。这通常是因为工具结果回传格式不对，或者tool_call_id不匹配，模型被迫用文本模拟工具行为。修复链路后，模型自然会回归结构化调用。重复执行的问题则多半是缺少幂等设计，建议在一轮决策内做请求ID去重。

6.3 MCP层的典型故障

stdio模式最常见的坑是MCP子进程闪退。排查时先看启动命令和配置路径是否对，再看依赖的运行时版本是否匹配，最后在客户端加自动重启策略。HTTP模式则要重点看超时参数，外部服务响应慢时，客户端默认等待时间不够就会误判失败。tools/list返回空列表时，九成是初始化握手阶段的能力协商没有完成，先检查协议版本和initialized通知是否都正常。

6.4 记忆层的典型故障

检索结果和当前问题完全无关，基本是相似度阈值定得太低，什么噪音都往里装。写入爆炸导致token预算失控，是过滤和提纯步骤没生效，需要检查是不是把工具执行的日志也写进了长期记忆。还有“旧记忆删不掉”的问题，原因多半是软删除只改了状态位，但检索层没过滤掉已删除的条目，索引重建一下就能解决。

下面这张表可以存起来当排查速查：

7. 写在最后：四块能力串起来之后的工程化体会

把这四块能力串起来之后，我最大的体会是：真正拖垮Agent的往往不是模型不够聪明，而是外围这四层不够可靠。会话状态机做得稳，任务就不会半路跑偏；工具链路做得严谨，模型就不会频繁犯低级错误；MCP接入得标准，新增数据源就不再是痛点；记忆写得好，Agent才真的越用越顺手。它们的优先级有先后，建议按“会话 → 工具 → MCP → 记忆”的顺序推进，先把最小闭环跑通，再逐层加深。

最后再分享一个小经验：调试Agent时，建议在所有外部交互的入口加日志，把每一次送入上下文的内容都打印出来。你会发现很多诡异问题，根源都是上下文被污染——要么历史截断少了关键约束，要么记忆注入带了错误信息，要么工具报错被原样塞给了模型。把上下文链路看清了，一半的“模型表现不佳”问题其实都能在代码层解决。