前两周我还有点怀疑：坐在我隔壁的同事每天到点交稿，下午居然还有时间摸鱼追剧，稿子质量却一点没掉。后来才发现，她不是一个人在战斗，真正干活的是一套叫 Hermes Agent 的智能体项目，跑的正是 AI 写稿的自进化闭环。我看完的第一反应是：这不就是我一直想做又没做出来的东西吗？尤其是它用向量引擎把“断电”这个老大难问题解决掉之后，整个任务链真的像连续通了电一样，稳得离谱。这篇文章我就把整个项目的设计思路、向量记忆的实现细节、以及实际跑写稿任务的完整过程拆开讲一遍，适合正在做智能体自动化、或是对 AI 写稿流程优化感兴趣的开发者参考。

1. 先说说“养虾”和“断电”这对难兄难弟

1.1 什么才算真正的“养虾式维护”

先解释一下标题里的“养虾”。我不知道这个词最早是谁带出来的，反正我们内部现在一说“养虾”，就是指那种永远需要人伺候的自动化任务。你以为是脚本在跑，实际上是你一天到晚在给它投喂素材、改参数、重启失败节点、清理脏数据。就像养虾一样，看着是养殖，其实从投苗到出塘，每天不是换水就是喂料，稍有不慎还要翻塘。

AI 写稿任务特别容易变成这种状态。一开始你可能只是写了一个定时生成文章的脚本，跑了两天发现模型输出经常不合格，于是你开始加规则；加了规则又发现不同选题得配不同提示词，你又开始维护一抽屉的提示词模板；再后来模型接口偶尔超时、偶尔报错，你又得写重试；等这些都弄完，你发现每次写新题材还是得人工补一堆背景资料，因为脚本没有任何记忆。到头来，这个“自动化”系统里最忙的还是你本人。

“养虾”的本质问题，是任务没有形成闭环。所有环节都依赖外部人工兜底：人工判断质量、人工补充记忆、人工排除故障。只要闭环没有建立起来，AI 写稿就跑不远，跑两天就得回来求你修这修那。

1.2 断电源头不只是服务器掉电

再看“断电”。这里说的不是机房停电，而是任务链路中间断掉：上下文断电、记忆断电、工作流断电。我见过太多跑得正好的写稿流程，因为一个非常小的问题整个断掉，前面的进度全部作废。

举几个典型场景。第一个是上下文断电：让 Agent 写一篇长文，写到一半上下文长度超限，或者隔了一个晚上，会话记录被清理了，Agent 直接把前半篇忘了，接着写出来的风格完全接不上，甚至内容前后矛盾。第二个是知识断电：昨天刚总结好的写作经验和踩坑清单，今天起新任务时完全检索不到，Agent 又从零开始探索，白白重复之前的错误。第三个是工作流断电：生成初稿这步成功了，但接下来要做的查重、打分、改写步骤因为某个中间服务超时而中断，全流程没有断点恢复机制，只能人工重启整条流水线。

这些“断电”比服务器宕机隐蔽得多，因为它们不会让系统整体崩溃，但会让整个自动化失去连续性。而 Hermes Agent 的做法，不是去修某个具体的断点，而是从底层把“状态”和“记忆”做成了可持续、可恢复、可检索的基础设施，让断电失去意义。

2. Hermes Agent 的自进化闭环，是怎么把“养虾”终结掉的

2.1 闭环设计的核心：把失败经验变成下一次输入

你去看市面上大多数 AI 写稿工具，本质上是“输入一个需求，输出一篇文章”的线性流程。这类流程的问题在于，输出完就结束了，没有任何东西被沉淀下来。写得好不好、哪里写得不好、下次怎么改进，这些信息全丢在风里。于是下一次写相似的主题，你还是可能犯一模一样的错误，永远在同一个水平线上打转。

Hermes Agent 的设计思路完全不同，它把整个流程做成了一个闭环：生成 → 评估 → 记录 → 进化 → 再生成。每完成一次写稿任务，系统不仅产出文章，还会对文章进行多维度的质量评估，把评估结论、失败原因、成功经验全部写入记忆库。下一次再有相似任务进来时，Agent 会先检索记忆，把过去踩过的坑直接拿过来当作约束条件，确保同样的错误不再犯。

这个思路听起来不复杂，但它有两个前置要求。第一，评估必须是可持续的，不能是“看了一眼觉得还行”，而是要有可量化的评分标准。第二，记忆写入必须是结构化的，不能让 Agent 把一堆乱七八糟的文本直接塞回去，否则只会污染后续任务。这两件事，我们在实际项目里花的时间比写主流程多得多，但完成之后，效果是整个系统肉眼可见地变聪明了。

2.2 四层结构分工：编排、执行、记忆、进化

把 Hermes Agent 拆开看，整个系统可以分成四个相互独立的层。第一层是编排层，负责任务拆解、状态管理和异常恢复，相当于整个系统的大脑中枢。它决定一篇写稿需求应该先做什么、再做什么、某个步骤失败了要如何处理。

第二层是执行层，负责真正调用写作模型、工具接口、知识库。这一层做的事情比较常规，但要注意的是它必须对上层暴露统一的输入输出格式，这样编排层才能像搭积木一样自由组合。

第三层是记忆层，也是我觉得最核心的一层。它把所有历史任务的关键信息向量化存储下来，包括选题背景、文章结构、写作风格、用户反馈、踩坑记录。当新任务进来时，记忆层负责找出最相关的历史经验，作为上下文喂给执行层。没有这一层，Agent 是个健忘症患者；有了这一层，它才具备“越用越聪明”的基本条件。

第四层是进化层，负责把评估结果翻译成下一次行为的调整指令。比如评估发现“开头铺垫太长导致完读率低”，进化层会生成一条类似“新文章开头要在 150 字内直接切入核心观点”的约束内容，写回提示词库。下次写稿时，这个约束会通过记忆检索自动出现在上下文中。

四个层合在一起，才构成了真正的“自进化闭环”。如果只做了前三层，没有进化层，Agent 顶多算一个带记忆的写稿工具；有了进化层，它才是一个会自己改自己的工作方式的系统。我个人的体会是，进化层的反馈信号设计是整个项目里最值得花时间打磨的部分，因为它直接决定了系统会往哪个方向进化。

3. 向量引擎：让 Agent 不再断电的关键细节

3.1 不断电的底层逻辑：状态持久化加断点续跑

为什么说向量引擎能解决“断电”？关键在于它同时承担了两件事：一是作为长期记忆的存储介质，二是作为断点恢复的检索依据。传统的键值数据库只适合精确匹配，而 Agent 运行过程中产生的经验和案例是没有办法用精确键来描述的，你总不能给每条经验手编一个 ID 然后祈祷下次问问题时的关键词完全一致。

向量引擎的思路是把每条经验嵌入成一个高维向量，然后在语义空间里做相似度检索。举个例子，Agent 曾经遇到“用户要求写产品文案，但反复强调不要夸大效果”这个问题，它处理完之后把这个经验向量化。下次来一个“写一个诚实一点的产品介绍”的需求时，关键词完全不一样，但在语义空间里它们离得非常近，Agent 就能把上次的经验捞出来用。

在断点恢复上，Hermes Agent 的做法是给每个任务维护一个状态机快照，并把这个快照跟当轮任务的关键语义绑定在一起。任务执行到任何一步意外中断，重启后先检查最新快照，根据快照里的任务 ID 和状态节点，去向量库里找回它当时的上下文摘要，然后直接从断点继续跑，而不是从头再来。这就好比你看剧看到一半手机没电，充电开机之后它直接问你“要继续从第 32 分钟开始播放吗”，而不是把你打回第一集。

所谓“不再断电”，并不是说故障不再发生，而是说故障发生后系统具备自恢复能力。而自恢复的前提，是所有关键状态都被持久化、可检索、能重建，这些事情向量引擎可以做得非常顺手。

3.2 语义记忆的写入与检索，代码级别的示例

下面我把记忆层最核心的写入和检索逻辑简化成代码骨架，大家看过之后就能明白实际实现并不复杂，复杂的部分全在语义切分和打分。

class VectorMemory: def __init__(self, embed_fn, top_k=5, min_score=0.72): self.embed_fn = embed_fn # 文本转向量的函数 self.store = [] # 简化：内存式存储 self.top_k = top_k self.min_score = min_score def write(self, text: str, meta: dict): vector = self.embed_fn(text) self.store.append({ "vector": vector, "text": text, "meta": meta, "id": len(self.store) }) def search(self, query: str): q_vec = self.embed_fn(query) scored = [] for item in self.store: score = cosine_similarity(q_vec, item["vector"]) if score >= self.min_score: scored.append((score, item)) scored.sort(key=lambda x: x[0], reverse=True) return scored[:self.top_k]

实际项目中，文本不是直接整篇丢进去向量化的。我们会对每条经验做拆分：比如把“当前任务背景”“遇到的问题”“最终处理方式”“评估结果”分别编码，再拼成一个结构化的向量记录。这样一来，检索时既可以用整段文字作为查询，也可以用其中的某个字段来做精准过滤，召回的效果比直接存整段文本好很多。

写入的时机也很有讲究。不是每次任务结束都急着写，而是等评估结果出来之后，确认这条经验确实有复用价值才写。如果评估发现这次写出来的文章质量很差，连及格线都没过，那它对应的教训也要写，只是 meta 里要标记成负样本。后续检索时可以根据场景决定要不要避开负样本。

3.3 阈值和召回策略：什么时候该信旧经验，什么时候该重新学习

向量引擎用起来最容易翻车的地方，就是盲目相信召回结果。我刚开始做的时候设的阈值很低，top_k 拉得很大，结果每次写稿都是把过去所有相关不相关的经验全部塞进上下文里，Agent 被一堆互相矛盾的建议搞到精神分裂，输出反而更差。

后来我们总结了一套召回策略。第一步，相似度低于 0.65 的记录直接不参与召回，因为这说明历史经验和当前任务基本不搭边，硬套只会添乱。第二步，相似度在 0.65 到 0.85 之间的记录，只作为背景参考，不写死成硬约束。第三步，相似度超过 0.85 的记录可以当作高相关经验，提示词里明确要求 Agent 优先遵循其中的方法论。

另外还要给记忆加上时间衰减。一条经验三个月前有效，不代表现在还有效。尤其是写作风格和平台调性这种东西，变化非常快。我们会在 meta 里记录每条经验的时间戳，检索时乘以一个时间衰减系数，让近期经验有更高的召回权重。这个细节看着不起眼，但对长期运行的系统质量影响极大。

4. 实战：用自进化 AI 写稿闭环跑完一轮真实任务

4.1 一条写稿需求从进入到完成，Agent 到底经历了什么

我直接拿一个实际的写稿任务来走一遍整体流程。假设现在进来一条需求：给某新品写一篇公众号推文，要求口语化，突出用户痛点，又不能显得太营销。这个需求先进入编排层，编排层把任务拆成五个阶段：选题检索、素材准备、大纲生成、初稿撰写、质量评估。

选题检索阶段，Agent 会先去向量库里找过去所有和“公众号推文”“口语化”“用户痛点”相关的历史记录。它找到了三条高相关经验，其中一条明确写到上次写类似推文时，开头直接堆产品卖点导致完读率很低，评估组给出的反馈是把开头改成用户故事切入。这条经验被自动注入到提示词里，作为大纲生成的硬约束。

素材准备阶段，Agent 检索行业相关数据，同时查记忆里有没有同类产品写过的素材库。因为向量检索是根据语义匹配来找的，所以它能把“用户不愿意为复杂功能学习”这种描述和以前“用户害怕操作门槛高”的经验关联起来，自动补全素材维度。

之后的生成阶段，Agent 会先把大纲提交给评估模块做一次预检。预检通过后才进入初稿撰写。初稿写完后，质量评估模块会从结构完整度、主题相关度、表达口语化程度、营销味浓度四个维度打分。如果总分低于 75，Agent 会根据打分结果定位是哪个维度拉低了分数，然后针对性地改写。

整个流程跑完，任务结果和评估明细会一起写入向量库。注意，写得不是单纯的文章文本，而是带评估结论的结构化经验记录。这样下一次写类似内容时，它就能直接利用这次的成功路径，或者绕开这次暴露出来的坑。

4.2 从一天干预 9 次到连续 7 天无人值守

这个系统刚上线的时候，说实话没有想象中那么顺。第一天跑下来，我统计了一下人工干预次数，整整 9 次。一会儿是模型接口对特定主题返回内容质量太差需要人工重写，一会儿是检索到的历史经验不准确导致大纲方向偏了，一会儿是评分模块把一篇明显还可以的文章打成了不及格，触发无谓的反复改写。

但我要说的是，自进化系统的价值在于它会自己纠偏。第二天我们只干预了 4 次，因为打分偏低的那些案例已经被写进了记忆库，当同类情况再次出现时，Agent 会先参考“上次这类文章被判不合格的原因”，主动调整写作策略。到第四天，干预次数降到了 1 次。等到第七天，我们几个开发者专门开了个监控页面盯着看了一整天，一次都要没有手动介入，从需求进入到文章归档，全流程自动跑完。

当然，我这么说不是让大家以为所有任务都能无缝自动化。能做到这一步，前期的评估信号设计和记忆写入规则花了我们非常大精力。但一旦跑顺，你就能直观地感受到“养虾”和“自进化”的差别：一个是天天围着系统转，一个是系统自己知道自己该往哪走。

5. 常见问题与排查实录

5.1 五个高频故障和对应的解决思路

我整理了一份常见问题速查表，都是在调试这类自进化写稿系统时大概率会遇到的问题，排查方向和解决办法直接对着看就行。

5.2 自进化最容易翻车的三个细节

第一个细节是反馈信号不能只看大模型评分。我们最早完全依赖模型自评，结果发现它经常夸得天花乱坠，打出来的分基本没有区分度。后来改为规则评分加模型评分的组合：规则负责检查硬性指标，比如结构是否完整、关键词是否覆盖；模型负责评估软性质量，比如语言是否自然、说服力是否到位。两个分数一起加权，才勉强可信。

第二个细节是记忆库也需要定期清理。向量检索跑到后面，库里可能积累了几万条历史经验，其中大量是重复、过时、互相矛盾的。我们设置了定期重构任务，把相似度太高、时间太久、负样本占比过高的记录合并或淘汰。否则库存越厚，检索噪声越大，Agent 反而更容易被旧经验带偏。

第三个细节是进化一定要留回滚路径。自进化系统的特点是有时会突然冒出一个“神来之笔”，但有时也会改出一个“脑残操作”。我们给每一次进化操作都生成一条 diff 记录，包括改了什么提示词、加了多少条约束、当时的评分是多少。如果后续评测证明这轮改动是负面效果，可以一键回滚到上一个稳定版本。没有这个机制，系统越进化越烂的时候，你会非常被动。

写在最后的小建议

如果你也想搭一个类似的 AI 写稿自进化系统，我最大的建议是别急着上“自进化”，先把“记忆”和“评估”做好。记忆决定 Agent 能不能用上历史经验，评估决定它记住的经验是金子还是垃圾，这两件事没做好之前，闭环跑得再勤也只会把错误越学越牢。我自己的感受是，最难写的代码从来不是调用大模型那几行，而是想清楚“什么算做好”并把这条标准落成可执行代码。等这条链路跑稳了，你自然就会体验到连续七天不用管任务、文章质量还在稳步上升的那种踏实感。