企业官网建设流程全解析

很多做智能助手的人应该都遇到过同样的尴尬：一个虚拟代理（Virtual Agents）在云端跑得好好的，换到手机、网关、车载设备上，突然就变得又慢又笨。用户的诉求也不复杂，就是连续问几轮，让代理结合上一轮的结果做下一步决定。可每次换到边缘端，代理就像失忆一样，记不住刚才的结论，也解释不清楚它接下来打算干什么。于是，一种新思路开始被讨论得越来越多：用小型语言模型（SLMs）加边缘计算，把这套代理能力下沉到本地。

这听起来像是一个部署问题，但我个人觉得，它背后更根本的变化是：当模型变小、资源变紧、场景更局部时，虚拟代理的 Think（思考）过程和 Memory（记忆）过程，不能再被当作大模型自带的神秘能力来用，而必须被拆成显式、可设计、可评估、可优化的系统模块。理解了这一点，才会真正看懂这个英文标题把 SLMs、Edge-Computing 和 “Think and Memory Processes” 放在一起做探索性评估的用意。

1. 边缘化不是把模型搬个家，而是把能力三角重新切换

先说一个常见的误区：很多人一听到“小模型部署到边缘”，第一反应是“模型变小了，能力变弱了”。但如果只是从参数量大小来理解，就很容易忽略边缘计算带来的系统约束变化。真正重要的不是变弱，而是原本云端方案里被掩盖住的设计问题，现在全部暴露出来了。

1.1 云端方案把思考与记忆压成了模型内部的黑盒

过去在云上做大模型应用，开发者的工作其实相对简单。要做一个虚拟代理，只需要把用户历史、工具描述、系统提示词全部拼到 Prompt 里，然后把这一段很长的文本交给大模型。大模型的上下文窗口越来越大，它能够“看”到足够多的历史，所以表现出一种能力：它能继续处理当前请求，也能在回答时引用前几轮的信息。从外部看，这就是记忆；当模型按照一句“请一步步思考”开始输出内部推理时，这看起来就是思考。

但问题在于，这两件事都被封装在模型内部，成了一个黑盒。

作为开发者，你没有办法控制模型的记忆保留策略。模型看到的是你拼接进去的全部历史，它不会主动区分哪些是用户临时说的，哪些是长期偏好，哪些是已经过期的状态。你也没有办法直接干预模型的推理步骤。模型可能因为某一段历史太长、信息太杂乱，最后给出的答案前后矛盾。更现实的是，把所有输入都上云，会带来延迟、成本和隐私问题。

在大模型的场景里，这些问题还能忍。因为模型能力足够强，即使内部过程混乱，最终结果大多数时候能看。可一旦把模型换成了 SLM，把运行环境放到了边缘设备，这套“全交给模型”的方式就会迅速失效。窗口变小，算力受限，本地运行的小模型无法吞下完整历史，也无法完成特别复杂的端到端推理。这时候，唯一的出路就是把思考过程和记忆过程显式化。

1.2 端侧约束把“模型能力”逼成了“系统能力”

边缘计算的核心优势并不复杂：数据不需要传回云端，推理可以在本地完成，响应延迟更短，隐私保护更好。但代价也很明显：处理器的算力有限，内存占用有峰值约束，功耗不能太高，有些设备甚至没有稳定的网络连接。

在这样一个受限环境里，运行虚拟代理就不能再追求“一个模型解决所有问题”。你会发现，真正决定一个代理好不好用的，不再只是模型本身，而是整个管道的设计方式。

我习惯把这套改动理解成三个转移：

• 上下文从“隐式拼接”变成“显式状态”。不再是直接把所有历史塞给模型，而是把提炼后的摘要、关键实体、任务进度单独管理。
• 记忆从“Prompt 工程”变成“状态工程”。需要有一套外部存储，决定写入什么、读取什么、什么时候过期。
• 思考从“单次生成”变成“多步流程”。模型每一次只负责一个较小、较具体的推理动作，比如抽取意图、生成工具参数、判断结果是否完成。

从表面看，这种设计增加了复杂度，前端多了模块，流程多了步骤。但从结果看，复杂度反而被控制住了。因为在云端大模型方案里，复杂推理和上下文管理主要依靠模型内部的隐性能力，而边缘方案必须通过流程和状态来显式兜底。这就引出了标题中的两个关键词：Think 和 Memory。它们在小模型和边缘环境下，不再是自然涌现的能力，而是工作流中的实体组件。

注意：边缘化不是单纯地“换一个小模型”，而是先承认大模型隐式能力强，再主动把关键能力改成显式模块。这是一个思维方式上的切换。

2. Think 过程：小模型的“思考”如何从黑盒变成可拆解链路

如果说大模型的 Think 过程是一条很宽的河，所有推理可以一次性完成；那么 SLM 的 Think 过程更像一条只能承载小船的窄河道。你不能让所有信息一股脑地涌进来，而是要把它拆成若干段，让模型一段一段走完。

2.1 小模型的思考能力，很大程度取决于任务如何被切分

许多刚接触 SLM 的团队会犯一个错误：他们让一个小模型直接回答一个完整指令，结果输出不稳定，于是得出结论“小模型太笨了”。但是实际上，很多失败并不是模型笨，而是把一个本来需要多步骤完成的复杂任务，强行塞给了一次推理。

举个例子。假设用户说：“帮我看一下今天下午的会议，如果时间和预算允许，替我订一间离公司三公里以内、可以无烟用餐的餐厅。”

如果让 SLM 直接输出最终结果，它需要同时完成意图识别、时间解析、地点约束解析、公司位置匹配、餐厅搜索条件判断、会议时间冲突判断等多个任务。对一个几亿或几十亿参数的小模型来说，这一步跳得太大了。

更合理的做法是，先把任务拆成几个更小的子问题：

1. 识别意图：用户想订餐厅，不是改会议。
2. 提取时间范围：今天下午，需要避开会议时间。
3. 提取地点范围：离公司三公里以内。
4. 检查记忆偏好：用户是否有忌口、是否有常去的餐厅。
5. 调用工具：查询附近符合条件的餐厅。
6. 合并结果并输出。

这样每个子问题对 SLM 来说，都变成了一个结构更清晰的小任务。小模型不需要在一段文本里同时完成推理、记忆检索和工具调用，它只需要按流程推进。因此，Think 过程的本质就是任务分解和流程编排。

2.2 思考链路的典型四段式：感知、计划、执行、校验

如果把思考过程进一步抽象，我会建议团队先从一个最小的四段式开始：感知（Observe）、计划（Plan）、执行（Act）和校验（Check）。这个流程还有很多变体，但对探索性项目来说，四段式已经够用了。

感知环节负责清理当前输入，并结合历史提取关键信息。不要一上来就让模型回答用户，而是先让它回答“当前用户真正想要的结果是什么，已经具备的输入是什么，还缺失的输入是什么”。这一步可以避免后续工具调用时出现参数缺失。

计划环节负责生成下一步动作列表。例如调用哪个工具、需要哪些参数、判断是否需要读取长期记忆。小模型这一步输出最好固定成结构化格式，比如 JSON 或字段列表，而不是自由文本，否则后续流程很难稳定解析。

执行环节才真正调用外部工具或写记忆。这里的执行，不只是调用 SLM 生成内容，还可能包括查询本地数据库、调用设备接口、发送 HTTP 请求等。

校验环节往往被忽视，但它才是 SLM 方案能否稳定运行的关键。小模型很容易在参数格式、日期计算、字段名拼写上出错，所以校验不能靠模型自觉，必须用规则和 Schema 去兜底。如果校验失败，就重新回到计划环节，而不是直接把错误结果交给用户。

这个链路真正的好处在于，每一点都是可观测、可复现的。如果最终输出不对，你可以回看是计划错了、执行错了，还是校验漏掉了。对探索性评估来说，这种可观测性比最终答案漂亮更重要。

{ "step": "plan", "intent": "book_restaurant", "slots": { "time": "today_afternoon", "location": "within_3km", "dietary": "no_smoking" }, "need_memory": true, "actions": ["search_restaurant", "check_schedule"] }

这是我个人比较建议的一种中间输出结构。它不需要模型写长篇大论，只需要填充关键字段。Think 过程是否稳定，往往就体现在这些结构化字段是否正确。

2.3 评估 Think 过程，不是只看回答漂不漂亮

很多项目在评估阶段，只让几个人试用虚拟代理，然后凭感觉打分。这种方法在大模型演示阶段还可以，但一旦进入 SLM 加边缘计算的方向，就必须换成过程化指标。

建议至少记录以下几类数据：

• 任务完成率：多少个测试场景走到了正确结束状态。
• 计划一次通过率：模型第一次生成的计划是否能够直接执行下去。
• 修正次数：校验失败后，经过多少轮修正才恢复。
• 无效工具调用率：有多少次是因为参数错误才触发工具调用失败的。
• 单轮平均耗时：从用户输入到响应结束用了多少时间。

另外，要关注“思考失败”的分类。把失败原因分成四类也足够了：意图识别错、计划生成错、执行参数错、校验逻辑漏。每一类失败都应该能在日志里找到对应的环节。否则，“Think 过程优化”就只能是一句口号，没有下手点。

我更建议团队在探索阶段做一件看上去很枯燥的事：把每一次失败时的思考链路完整留存下来。最终回答只是一个结果，回答背后的过程才是改进系统的钥匙。

3. Memory 过程：端侧记忆不是缓存，是状态工程

如果说 Think 过程决定了虚拟代理能不能“把事情做对”，那么 Memory 过程决定的是虚拟代理能不能“持续把事情做对”。在一个边缘设备上，记忆不是一个缓存目录，而是一整套关于状态读取、写入、同步和过期的工程系统。

3.1 记忆要先分成三层：会话、用户和任务

很多团队一提到“记忆”，第一反应就是“把历史消息存起来”。这个理解太粗糙了。历史消息只是最浅层的会话记忆。如果所有信息都堆在一起，系统很快会面临两个问题：不知道该读哪段历史，也不知道哪段历史已经失效。

我更建议把虚拟代理的记忆分成三类：

第一类是会话记忆（Session Memory）。它对应的是当前一次连续交互。可能是最近几轮的用户消息、代理回复、已经确认过的中间结果。会话记忆的特点是实时性强，但生命周期短。任务结束或对话关闭后，这类记忆通常可以压缩成摘要或者直接删除。

第二类是用户记忆（User Memory）。它对应的是跨会话存在的用户偏好和事实。比如用户不吃香菜、通常选择靠窗座位、工作日晚上不方便接电话。这类记忆需要持久化，并且会长期影响代理的行为。

第三类是任务记忆（Task Memory）。它对应的是业务状态。比如一个订餐任务已经进行到哪一步，某个待办事项是否完成。任务记忆和会话记忆有关，但又不完全一样。它可以超越单次对话，在用户离开后继续保留，下次回来时可以恢复进度。

把记忆拆成三层，不只是方便存储，更核心的是帮助系统决定“什么时候可以把一段记忆忘掉”。会话记忆可以短暂，用户记忆要稳定，任务记忆要有明确的生命周期。边缘场景下存储资源有限，如果没有分层，大量过期信息会不断堆积，最终让模型的记忆效率严重下降。

3.2 写记忆比读记忆更值得花时间设计

从使用频率来看，大家更关心“如何从记忆中读取到正确信息”，因为模型在回答问题时需要相关上下文。但在实际工程中，写记忆才是一件更值得花时间的事。因为记忆系统的上游没有做好，下游读取建模做得再好也只是在烂数据里翻找。

写记忆至少有四个决策要处理。

第一，什么时候写入？并不是用户说的每一句话都要写入长期记忆。只有出现明确偏好、任务完成、用户纠正、关键状态变化时，才值得触发一次写入。用事件驱动会比“每轮对话后全量保存”更可控。

第二，写什么？是保留用户原话，还是保存一条提炼后的字段？我通常建议在存储层保留两种信息：一条结构化摘要负责支撑快速判断，一段原文或日志负责追溯确认。如果只保存原话，后续检索会面对大量噪声；如果只保存摘要，一旦摘要写错，整个记忆都会失真。

第三，保留多久？记忆没有永久一说。用户可能过几天就改变偏好，业务任务更可能在完成后失效。每条记忆都必须有时间戳、来源会话、有效状态。否则代理会一本正经地使用几天前已经失效的错误信息。

第四，冲突怎么办？用户在昨天说“不要靠窗”，今天又说“选一个安静一点的靠窗位置”。真实情况可能是，用户还是希望靠窗，但对“稳定”的偏好变了。这时新信息并不总是能覆盖旧信息，系统需要区分“临时状态”和“长期偏好”，把冲突也记录下来。

注意：记忆写入最好是事件驱动，而不是全量保存。每一轮对话都往记忆里塞数据，最后得到的不是长期记忆，而是不断膨胀的噪声池。

3.3 边缘记忆的痛点：多设备、隐私与防误用

边缘计算带来一个直接优势：敏感数据可以不出设备。这个优势同时也带来新的复杂度。如果用户有手机、平板、车载系统多个入口，不同设备上的记忆如何同步，就是一个绕不开的问题。

一种相对稳妥的做法是“本地优先”。高隐私的原始信息保留在设备本地，云端只保存用户主动确认过的共享摘要。这样既保证了主要交互延迟低，也尽量避免把敏感内容扩散到整个系统。但也要接受一个现实：不同设备上的记忆并不一定完全一致。代理需要能够在回答中说明“我是根据这台设备上的记忆给出的建议”，而不是假装自己什么都记得。

另一个容易被忽略的问题是记忆误用。代理读到了用户记忆中的偏好，但在当前任务中并不适合应用它。比如用户平时非常喜欢吃辣，但最近因为身体原因在控制饮食，如果代理只按长期偏好推荐川菜，反而会造成困扰。所以记忆读取必须和当前任务场景结合，不能每次都用最高分匹配。必要时，代理应该主动问一句：“这次还按你原来的口味推荐吗？”

边缘记忆，真正要解决的不是“怎么记住更多”，而是“如何在正确时间，只读取影响当前决策的那一小部分信息”。

4. 像做一次探索性评估一样搭最小实验

回到标题里最容易被忽略的定位词：Exploratory Evaluation。探索性评估的意思，不是要立刻做出一个可商用的虚拟代理，而是先搞清楚“在 SLM 加边缘计算的约束下，Think 和 Memory 到底对系统有多大的影响”。这种评估不需要完美，但需要可重复、可对照、可解释。

4.1 先圈定一个封闭任务域，再做对照测试

如果你也想验证类似方案，我不建议一开始就做一个通用助手。先选一个业务边界清楚、动作数量有限的领域，比如“本地餐饮预订”“会议日程管理”“智能家居控制”。领域越封闭，越容易判断哪个环节出了问题，也越容易用小型模型跑出可用结果。

选定任务域之后，可以构造四组实验配置：

然后准备一批统一的任务脚本。每个脚本最好覆盖几种典型情况：新用户第一次提问、老用户连续多轮对话、对话中途被中断后恢复、用户主动纠正偏好。每组脚本至少重复多次，不要只跑一遍就下结论。对探索性项目来说，稳定性比单次成功率更重要。

这样设计的好处非常直接：如果 Think Only 的完成率明显高于 Baseline，说明任务拆分能帮小模型补上能力缺口；如果 Think + Memory 的提升主要来自 Memory，说明这个任务域对长期状态更敏感。两种判断指向的优化路径完全不同。

4.2 评估指标要分成四类，而不是只测成功率

很多评估只看“模型回答得像不像”。但在边缘代理场景里，资源消耗和稳定性同样关键。建议把指标分成四类，不一定要面面俱到，但至少每类选一项来记录。

第一类是延迟。端到端响应时间要拆开看：模型推理时间、记忆检索时间、工具调用时间、校验时间。如果记忆查询比模型推理还慢，那记忆系统就需要换实现方案。

第二类是资源。边缘设备不是服务器，峰值内存、平均 CPU、偶尔的 NPU 占用都会影响其他业务。小模型可以跑在量化模式下，但量化和精度通常会有副作用，需要做权衡。

第三类是任务质量。成功率之外，还要看平均完成轮次、修正次数、恢复率。用户第一次成功只能算单点成功，失败后能否快速恢复才是系统是否健壮的关键。

第四类是稳定性。同样一段输入连续执行多次，是否会出现明显波动。对 SLM 来说，温度参数调得太高会不稳定，输出格式要约束到足够确定。

做过一轮之后，你会发现最终要优化的往往不是模型本身，而是整个流程中的瓶颈，比如某个工具调用返回格式不统一、某类实体抽取经常失败、某段记忆摘要导致上下文误导。这些才是探索性评估真正要找出来的东西。

4.3 实验排查顺序：先判断断在思考，还是错在记忆

跑实验的过程中一定会遇到问题。最常见的是：结果不对。这时候不要急着调整 Prompt，建议先按下面的顺序排查，能省下大量时间。

第一，先看日志，确认失败发生在哪一层。是模型根本没有生成正确计划，还是计划正确但执行参数错误，还是最终回复时读到了错误的记忆片段。

第二，再看输入。当前问题本身是否描述清楚，用户的意图有没有歧义，上下文截断是否把关键信息丢弃了。边缘方案里，输入不能只看当前这句话，还要看从记忆里读到了什么。

第三，再看记忆。检索出来的内容是不是过期的？匹配到的偏好是否和当前任务冲突？写入时有没有把临时状态误当成长期偏好存进去？很多问题看起来像模型不懂，实际上是记忆数据错了。

第四，再看环境和参数。SLM 是量化后的版本还是原始版本？模型温度是否设置得太高？上下文长度上限有没有过于保守？边缘设备资源是不是在推理时被其他进程抢占？

第五，最后再看模型边界。如果任务本身需要模型完成复杂的多步常识推理，已经超出了 SLM 在端侧的能力范围，那就不是调参能解决的，需要回到任务拆解和工具补偿，或者考虑是否真的适合端侧。

排查时先问“这一步的输入合法吗”，再问“这一步的实现对不对”。顺序反了，往往会绕很多弯路。

5. 真正落地时，哪些边界最容易决定成败

探索性评估跑通之后，下一步是判断这个东西能不能放回真实项目里。在这里，我见过最多的问题不是模型能力不够，而是团队没想清楚适用边界，把所有任务都往一套框架里塞。

5.1 适合先用 SLM 和边缘计算落地的场景

如果场景符合下面几个特征，相对适合采用这套方案：

任务边界清楚，动作集合有限。比如控制几类家电、填写固定格式的表单、处理售后问答中的高频操作。动作集合越小，规划环节越容易稳定。

对隐私有明确要求。语音数据、日程、健康信息如果留在本地处理，比上传云端更让人放心。此时边缘计算是刚需，不只是为了省流量。

交互可以容忍一定的任务化。用户并不要求代理像朋友一样闲聊，而是希望它能把事情办完。这种场景下，用结构化的 Think 流程完全能够满足体验。

需要离线或弱网可用。在车载、工地、门店等场景，网络不能始终可靠，把核心推理放在本地，即使效果平庸，也比断网后完全不可用强。

5.2 不适合一上来就做的场景

同时，另一种场景要谨慎。开放域闲聊、创意生成、复杂情感陪伴，这些任务非常依赖模型的知识储备和文本生成泛化能力，属于大模型的长板。硬要在小模型上用边缘部署去做这些，体验大概率会让人失望。

高影响、高风险决策类场景也要谨慎。比如医疗建议、法律判断、金融转账。小模型推理的容错空间很小，如果代理还能自动执行高影响动作，出错后造成的代价会非常大。这类项目不建议做成无人值守的全自动流程，至少要加入人工审批或者强规则校验。

判断边界有一个通用原则：如果任务的正确执行主要依赖“大量常识”，而不是“少量业务规则和步骤”，那么 SLM 方案的性价比会迅速下降。反之，如果任务的正确执行可以被拆成清楚步骤，可以用外部工具辅助，可以靠规则校验，那么即使模型小一点，整套系统也完全能够跑得稳。

5.3 长期运行还缺的不是模型，而是可观测、可回滚、可校准

探索性评估可以只关注准确率和延迟，但如果要长期运行，至少要补上三大工程能力。

可观测性。每一次请求都要有唯一标识，思考链路的中间输出、记忆读取结果、工具调用参数、校验失败原因都要有日志。不要等到用户投诉“它乱说话”时才发现完全没有排查入口。

可回滚。记忆系统是最容易出问题的部分。一个错误的摘要写入后，会影响后续很多轮交互。因此记忆字段要有版本、更新时间、来源。如果用户反馈较正，要能够回滚到上一次正确状态，而不是继续用脏数据误导模型。

可校准。用户说“你理解错了”，不能只当一句抱怨，要变成一条结构化反馈。比如记录用户对某个记忆字段的纠正，下次读取时优先使用校准后的值，而不是历史默认值。

这些能力表面上和 Think、Memory 没有直接关系，但它们决定了整套系统能不能在一个真实产品里活下去。边缘环境下的模型更新成本比较高，不可能每次效果不好就去重训模型。更多时候，你依赖的是思考链路可调整、记忆状态可修正、错误样本可追踪。

如果我现在要启动一个类似方向的探索，我不会一上来追求完整记忆和复杂思考，也不会急着换更大的模型。我会先选定一个非常具体的任务域，搭一条最小的思考链路，再设计一个最小可用的记忆结构，然后拿一款能力勉强够用的 SLM，在边缘环境里反复执行同一批任务脚本，记录每一次失败发生在思考的哪一步，或者记忆的哪个字段。

这个过程真正的产出不是一款完美代理，而是一张错误地图。这也是我读这个标题时，最认同“Exploratory Evaluation”这个定位的原因：它不急着证明某个方案一定好用，而是先帮团队搞清楚，在边缘与小模型的约束下，哪些思考必须保留，哪些记忆必须被结构化管理，哪些复杂度可以被毫不犹豫地砍掉。虚拟代理想从小模型身上获得接近大模型的体验，不能靠幻想模型潜力，只能靠把 Think 和 Memory 变成认真对待的工程问题。