企业官网建设流程全解析

一篇关于Agent记忆、上下文、Skills与Harness的深度实战总结。我拆解了标题里四个核心概念的边界与协作关系，融入了论文思路和落地工程经验。

开篇

这几年做大模型Agent落地，最折磨人的不是模型能力不够，而是经验无法沉淀。同一个错误，Agent会一犯再犯；昨天刚调通的流程，今天换个Session又从头来一遍；团队里攒下的提示词和工具调用规范，散落在每个人的本地笔记里，根本形成不了资产。如果你也遇到这些问题，那说明你正在被同一个难题卡住：Agent到底怎么记住东西，怎么在恰当的时候调用经验，又怎么把新发现写回去，形成正向循环？

围绕这套体系，业内其实已经沉淀出一套比较完整的架构语言：记忆（Memory）、上下文（Context）、技能（Skills）和Harness（外挂编排层）。这四个词单独拎出来都能聊很久，但真正的难点在于它们之间的协作关系。这篇总结，我把论文里的思路和自己在实际项目里的摸索放在一起，重点聊聊经验是怎么被保存、调用和更新的。适合正在做Agent框架设计、智能体产品化落地，或者单纯想搞清楚“给Agent加记忆到底是在加什么”的朋友。

1. 记忆系统：Agent的“第二大脑”到底存了什么

1.1 记忆分类：短期工作记忆与长期持久记忆

先理清概念。在认知科学里，人类的记忆分为工作记忆和长期记忆，Agent的架构设计几乎是照搬了这套范式，但工程实现上要粗糙得多，也实用得多。

短期工作记忆对应的是当前这个任务执行周期内的状态信息。最简单的实现就是一个上下文窗口，模型能看到的最近几轮对话、当前待处理的任务描述、中间推理结果。它的特点是容量有限、用完即走，不需要考虑持久化。我们做实际项目的时候，会在这个窗口里额外维护一个可变的结构化信息块，比如当前任务的子目标列表、已经确认的约束条件、当前步骤依赖的临时变量。这其实就是把“工作记忆”显式地建模出来，而不是完全依赖模型的隐性理解。

长期持久记忆则是跨Session、跨任务保存的信息。这里又需要细分：

• 语义记忆：关于外部世界的知识，比如某个接口的调用规范、某类业务场景的特殊规则。它通常是静态的，经过确认后才写入。
• 情景记忆：过往具体事件的记录，比如“上次跑这个流程时，在第三步因为数据格式问题卡住了，后来做了字段归一化才通过”。这类记忆有明确的时间戳和上下文关联，对Agent后续决策的参考价值极高。
• 程序性记忆：这层其实已经偏向Skills的范畴了，它保存的不是一段文本描述，而是“如何做”的流程步骤，可以被直接执行。

这里的核心认知是：不要把长期记忆当成一个简单的键值存储或者向量数据库，它更像一个带有元信息的经验仓库。每条记忆都需要说明适用范围、置信度、最近命中时间、使用次数，否则你很快就会被一堆互相矛盾的历史记录淹没。

实操建议：我给记忆条目设计了五要素结构——触发场景、解决方案、适用范围、置信度、来源（自动总结/人工写入）。没有这五个字段的记忆，后续根本没法做召回和冲突处理。

1.2 实践中的记忆结构：从原始日志到结构化记忆库

很多团队做记忆，第一个版本就是“把历史对话全部存进向量库，用的时候查TopK塞进Prompt”。这个方案Demo期能用，但到了真实业务里，召回质量会很快失控。原因在于原始对话日志的信息密度太低，大量篇幅都是寒暄、中间过程的试错、重复表述，把这些直接作为记忆单元存进去，噪声会淹没信号。

我摸索出来的比较合适的路径，是加一个“记忆提炼”环节。每一轮任务跑完之后，不是把完整记录入库，而是由模型基于本次执行日志做一个结构化提取：

• 本次任务的目标是否达成？
• 中间是否遇到了预期之外的阻碍？
• 最终采用了哪个方案绕开/解决？
• 有哪些操作对结果有显著正向影响？

提取结果会被压缩成一条“经验条目”，再经过重要性阈值筛选和相似度去重，最后才写入长期记忆。整个过程类似给项目写复盘日报，只是执行者从人变成了模型。

记忆的物理存储上，我建议不要只用单一存储介质。速度敏感的近期记忆用Redis，语义检索用向量库，精确匹配用关系型数据库，冷数据落到对象存储。各有各的用场。比如召回策略里，往往是先做场景匹配过滤（结构化条件），再做向量相似度排序，最后用重排序模型微调TopK，而不是一上来就全库向量检索。

踩坑记录：早期我图省事，把记忆统一放向量库，结果“昨日操作记录”这种高频近期记忆检索总是不准——因为近几天产生的记录在向量空间里并不天然聚集，TopK会被一些语义相近但场景无关的旧记忆挤占。后来把时间衰减因子加入排序公式，效果才明显改善。

2. 上下文工程：窗口里的空间博弈与经验抽取

2.1 上下文窗口是稀缺资源

很多人对上下文管理的理解，停留在“把窗口塞满能提升回答质量”，但这个认知在Agent场景里会害死人。你要意识到，上下文窗口的本质是被激活的工作记忆空间，它是Agent推理时唯一能实时“看到”的信息源，空间极其有限。

假设你的上下文窗口是128K，一个复杂的业务任务需要塞入：

• 任务定义与用户目标描述（大约1–2K）
• 工具能力说明，即有哪些函数可用（大约5–10K）
• 相关历史记忆的召回结果（可能10K–30K）
• 当前任务过程中动态获取的文档/网页/库代码（可能20K–50K）
• 模型已经生成的中间推理与行动历史（每次调用都会几何级膨胀）

这些内容一起抢有限窗口。任何一个部分超出预算，要么溢出截断，要么挤占其他部分的“注意力权重”。窗口里放了什么、不放什么、按什么顺序放，直接决定Agent的任务成功率，这比模型选型还重要。

当前主流的上下文工程思路，是把历史对话全文替换成高度压缩的结构化摘要。我们在实战中发现，保持前几轮原始对话内容（用于模型理解任务背景的细微之处），配合后轮精简摘要（只保留结论、当前进度、关键决策项），是一个性价比很高的组合。

2.2 上下文整理的实操流派

我接触过几套上下文管理的具体玩法，各有各的适用场景：

滑动窗口：最简单，保留最近N轮对话全文，更早的直接丢弃。适合闲聊型或单轮决策型场景，但在复杂多步任务中效果很差，因为关键约束往往出现在早期对话里，滑出窗口后Agent就“失忆”了。

滚动摘要：每次对话轮次超过阈值时，先用模型把已有的对话记录压缩成摘要，再用摘要+最近对话替代全量历史。这个方案能控制长度，但摘要会丢失细节，多轮压缩后错误会累积。建议每轮摘要都保留底层的原始决策依据引用ID，方便后续向前追溯。

结构化上下文块：这是目前我认为最健壮的方案。把上下文拆成多个语义块，每块有固定的槽位：目标、约束、进度、变更记录、风险列表。每次构建Prompt时，先把固定信息（当前任务信息）拼上，再按需加载记忆块和技能说明，最后才是最近几轮的完整行动轨迹。

在这个环节里，最重要的是显式地告诉模型“哪些信息是历史经验，哪些是当前任务上下文”。可以用简单的标记符区分，比如用差异化的标签包住不同来源的内容。模型对这种结构化的输入非常敏感，它知道该优先依赖哪部分信息，做决策时就能减少串扰。

实测下来，仅把上下文按信息源分区并标注，任务成功率能提升两到三成。这个提升不来自模型能力，而来自信息组织的秩序感。

3. Skills：把经验固化为可复用的“肌肉记忆”

3.1 从自然语言经验到结构化工具

在Agent的语境里，Skills指的是“可被调用的、完成特定任务的能力单元”。它和记忆的最大区别在于：记忆是被动查询的信息，Skill是主动执行的动作序列。换作人类的类比，记忆是你“知道怎么做番茄炒蛋”的知识，Skill是你“动手做出一盘成品”的操作能力。

很多团队的第一版Skills就是一篇Markdown文档，描述某个场景下的操作步骤，然后塞进System Prompt。这样做的问题是：

• Prompt里的描述与步骤是“文本知识”，模型每次都要现场理解并推导执行，正确率波动大
• 步骤之间没有强约束，模型可能跳过中间校验直接出结果
• 没法做版本管理，改动一个步骤要重新生成整段Prompt

正确的方式是把Skills往“工具化”方向升级。每个Skill包一个清晰的输入输出声明、前置条件校验、执行步骤模板，有的还需要包含失败回退策略。模型在完成任务时，通过决策机制判断该调用哪个Skill，然后按预设流程执行，而不是靠临场发挥。

这里还要分一层，另一个方向是微调小模型来内化Skill，让模型不再需要在Prompt里读取步骤描述。这种方式在大规模重复执行的场景下效果不错，但开发成本高、迭代周期长，适合工业化批量复用的技能。比较务实的路线是：验证频繁且标准的流程做成独立微调或可复用的工具，证明有效的提示词固化为Skill模板，还没验证的思路留在临时记忆里。给经验不同层次的沉淀级别。

团队里可以定一条规矩：同一个操作在日志里出现超过三次，就要讨论是否固化成Skill。每次临时性的人工处理，都是未被提取的经验浪费。

3.2 Skill注册与命名的实战细节

Skill库做大了以后，新的问题出现了：模型不知道该调用哪个Skill，或者Skill描述太相似导致误调。这里有几个提升命中率的实战细节：

1. 给每个Skill写“触发场景”列表，列举典型情况下的触发条件。这不是简单地用自然语言重述Skill名，而是直接罗列“当用户输入包含XX意图，或在流程的XX步骤检测到XX状态”时，调用该Skill。
2. 在Skill描述里加入明确的“不适用场景”。这能帮助模型做负向排除。很多团队只顾写正向触发条件，却不写哪些情况不应该用，导致模型强行套用不合适的Skill。
3. Skill命名遵循“动词+业务对象+场景”模式，比如generate_chart_spec_with_error_fallback，比chart或者make_chart_tool清晰得多。模型在做工具选择的语义匹配时，对这种描述性强的名称命中率更高。

还有一个很多教程不会提的细节：Skill的输入参数尽量收敛，默认值尽量可靠。因为模型在生成调用参数时，本质是在做一次“小型的受控生成”，如果你给它太多可选空参数，它很容易填出格式正确但语义错误的默认值。宁可把一个Skill拆成两个边界清晰的窄技能，也不要造一个带八个可选参数的万能大Skill。

4. Harness：编排层如何串联记忆、上下文与Skills

4.1 Harness承担了什么

单独看记忆、上下文、Skills都是相对独立的技术点，但Agent能完成复杂任务，靠的是把它们编排在一起。这个编排逻辑就是Harness（控制框架）。如果用一句话概括：Harness决定了Agent“在每一步看到什么、能做什么、做完了怎么记”。

早期的Harness实现就是一个while循环，不断调用模型，拿到行动指令，执行工具，把结果拼回上下文。但进入工业界后，这个裸循环根本撑不住。一个合格的Harness至少要处理以下几件事：

• 任务规划拆解：把大目标拆成可执行的子任务，并决定子任务之间的依赖关系
• 记忆路由：在恰当的时间节点主动召回相关记忆（而不是一股脑全塞进去）
• 工具路由：根据当前子任务目标，过滤出可用的Skill集合；给模型塞200个Skill描述既费Token又干扰决策
• 评估与反思：执行完一步后判断结果是否达成预期，决定继续、重试还是换策略
• 经验回写：任务执行完成或中途失败时，触发记忆提炼流程，把过程经验写回长期记忆

有了Harness之后，Agent的架构从“模型自己推理一切”变成了“框架引导模型做推理”，后者的可控性、可观测性和调试友好度都显著提升。

认知升级：不要把Harness当成一套代码库，把它当成一套Agent行为和记忆的元规则。Harness是那层兜底框架，它既要考虑模型的依赖，也要考虑在模型做不好时如何有人工的介入位置，是Agent系统真正的主干。

4.2 一个走向工业级的Harness设计参考

我基于开源项目做过二次开发，也自己从零写过一个轻量级的Harness，经验是：不要一开始就追求大而全的编排框架，而是从小规模主循环开始，逐层叠加控制逻辑。核心主循环参考如下：

1. 接收输入：解析用户目标，确认约束条件。
2. 上下文构建：从长期记忆召回场景相关的记忆，按结构化块组装上下文。
3. Skill过滤：基于当前子任务，筛选出可调用的Skill子集。
4. 模型推理：模型给出下一个行动决策（调用工具/推理/输出最终答案）。
5. 工具执行：执行模型决策的Skill，记录执行结果。
6. 结果评估：用一个评估器判断执行结果是否符合预期，不符合则决定是否重试或切换Skill。
7. 进度更新：将执行结论写入工作记忆，更新当前进度与风险列表。
8. 循环或终止：任务未完成则回到第2步；任务完成则触发经验提炼与记忆更新。

这个循环看起来简单，但每一步都有可深挖的细节。比如第4步模型推理时，为了让模型不乱试，可以限制它一次只能执行一个工具调用，不允许“想当然”地同时做多件事；又比如第6步评估器，早期的设计是让模型自己评估自己的输出，但模型存在“自我美化”倾向，对失败不够敏感。比较有效的做法是单独用一个小模型实例，或基于规则写一套针对特定任务结构的校验器，只检查关键产出物是否出现、格式是否正确、是否符合目标约束。

还有一个常常被忽视的环节是人工介入通道。工业级场景下，Agent不可能长期完全自主运行。Harness里应当预留状态导出、人工审查、手动修改后重新注入的机制。实际上，一个设置了“置信度低于阈值即请求人工确认”的Harness，比一个硬着头皮做完整个任务的Agent，给业务带来的安全感高很多。

5. 经验更新闭环：记忆如何被修正、淘汰与再验证

5.1 回灌机制：在线学到的经验写回记忆

如果记忆只增不改，那Agent会逐渐被过期或错误的经验“污染”，决策质量反而越来越差。经验的动态更新是Agent系统真正迈向长期智能的分水岭。这一环节我把它叫作“回灌机制”。

回灌分为两个层面：

任务级回灌：单个任务执行完成后，Harness触发总结逻辑，把这次任务中新出现的有效方案、遇到的坑、最终的解决方式提炼成记忆条目。以结构化字段呈现，经过重要性过滤后写入长期记忆。这个层级是自动完成的，但必须经过“该经验是否已被证实有效”的确认：

• 如果任务执行成功且路径清晰，该经验可以写入，并标注置信度较高
• 如果任务执行失败，最多记录“此路径不可行”作为负面记忆，标注低置信度，等待后续验证

经验更新回灌：这个层级处理的是“已有记忆需要被修正”的情况。比如某条Skill的故障回退策略，在实际执行中反复出问题，那就应该在运行日志自动统计时发现这条Skill的错误率上升，触发重新验证流程。

工业界落地时，回灌机制不能完全依赖模型在任务末尾的自动总结，因为模型存在“越总结越自信”的现象，会把没验证过的假设写成经验。折中方案是：每条自动写入的记忆都降级为“待验证”状态，只有在后续任务中再次命中且成功，置信度才会被提升。一套简单但有效的置信度更新机制：

• 新经验初始置信度0.5
• 每被成功引用一次，置信度上升0.1
• 每被引用但失败一次，置信度下降0.15
• 置信度低于0.3的记忆自动进入待复核队列，人工决定是否删除或改写
• 置信度高于0.8的记忆，后续检索时可优先返回

5.2 版本化与淘汰策略

长期运行的系统，经验会持续积累，但很多经验是有时效性的。比如某个外部接口的集成方案，在对方API升级后就完全失效了；又比如某个业务规则调整后，之前沉淀的操作步骤反而会误导Agent。所以记忆系统必须支持版本化回溯和主动淘汰。

版本化不只是把旧版本存起来，更关键是记录每条经验的“适用期”。我在设计时给经验加了几个生命周期字段：

• created_at：知识产生时间
• last_verified_at：最后被验证有效的时间
• source_task_id：产生该经验的任务ID，可回溯
• deprecated_at：标志该记忆是否已废弃

然后在日常运行中增加定期巡检，像清理房间一样的机制，把长时间未被命中的记忆降权，把命中但频繁失败的记忆降级。还有一个容易被忽略的点：对过期原始数据直接物理删除，但对其衍生的经验做“失效标记”。因为原始数据往往包含大量上下文，删除会丢失排查线索；而失效标记能确保它在召回排序里被迅速过滤掉。

避坑心得：不要在记忆里存“永远正确”的绝对化结论。真实业务中，“在XX条件下，操作Y通常有效，但如果遇到Z异常则需要切换方案”这种概率化记忆，比“操作Y可解决问题”这种断言式记忆靠谱得多。模型在决策时能理解条件差异，反而更灵活。

6. 常见问题排查与避坑速查

6.1 记忆污染与错误召回

症状：Agent在后续对话中反复提到“根据以往经验”，但引用的经验明显与当前场景无关，甚至给出误导性建议。

排查思路：

1. 检查召回逻辑的过滤条件是否过宽。比如只做了向量相似度排序，但没有做业务场景的硬过滤。
2. 检查写入记忆的内容是否是原始日志而非提炼后的经验条目。原始日志包含大量噪声，检索时噪声也会被匹配进来。
3. 检查置信度字段，确认是否所有自动写入的记忆都被当成高置信度来召回。如果没有置信度门槛，很容易造成低质量经验污染。

解法：写入端做提炼与去重，召回端做场景约束+置信度分级，必要时引入一个重排序模型，对召回Top50结果做精细排序，再截断TopK进入上下文。

6.2 上下文拥堵与信息覆盖

症状：任务执行过程中，Agent突然“忘掉”了最早设定的关键约束，开始按自己的偏好操作。

排查思路：大概率是上下文窗口被中间过程塞满，早期关键信息被截断或压缩掉了。这属于上下文管理的问题，不是模型记忆力的问题。

解法：上文提到的结构化上下文块方案可以解决。把固定信息（目标、约束）放在所有动态信息之前，并且每次循环中重复注入核心约束。模型对Prompt头部信息的跟随度明显高于中部和尾部。

6.3 Skills与提示词的职责边界不清

症状：同样的操作逻辑，有时候模型按Skill执行，有时候又按System Prompt里的泛化描述自由发挥，结果不稳定。

排查思路：说明System Prompt里混入了本应由Skill承载的详细操作步骤。模型在看到两种“互相独立”的来源时，会倾向于按更省力的方式行事——如果Prompt里有直接步骤，它很可能不会去调用Skill。

解法：明确分层：System Prompt只保留角色定义、安全边界、决策框架；具体操作流程全部由Skill承载；记忆只提供背景经验，不提供执行步骤。这样各干各的，边界清晰，问题自然减少。

6.4 实战问题速查表

结尾：一点真实的个人体会

写了这么多，最后说点跟技术方案无关但很实际的东西。Agent的记忆系统，本质上是一个团队的“组织经验资产”，而不是单纯的技术组件。我们做Agent和做管理系统有一个非常相似的规律：如果团队本身没有一个把成功经验和失败教训沉淀下来的方法论，那Agent的记忆库做得再花哨，最终存的也是一堆没有生命力的碎片。

从我实际运营的经验来看，上线后的头一个月，几乎每天都在和记忆污染作斗争。后来我学乖了，把“经验更新的反馈闭环”的优先级提到最高，甚至高于任务成功率指标。因为一旦回灌逻辑正确运转，任务成功率会自然地随运行时间上升；反过来，如果只盯着单次任务效果，忽略经验沉淀，系统就会一直在同一个坑里摔跤。

这个领域后续还有很大的扩展空间，比如记忆的多模态化（让Agent记住图片里的关键信息）、经验跨Agent迁移（A系统学到的经验能无损传递给B系统），以及Skills的自动生成与自动验证（让Agent自己总结技能并测试确认）。从论文到工业界，这些方向已经有了雏形，但真正落地还有很长一段路。如果你也正在踩类似的路，希望这篇文章能帮你少走几个弯路。