企业官网建设流程全解析

1. 为什么我会把项目代号从 Clawdbot 改成 Moltbot：一次持续三周的重构记录

先交代一下背景。我手上这个智能体项目，最初代号叫 Clawdbot，核心定位就是标题里的前半句——“探索与发现”。它接到的任务大多是开放式的：给一个方向，自己去找资料、做交叉验证、输出结构化结论。从第一个能跑的版本上线，到后来整体推翻重写，前后大约两个月。重写后的版本代号 Moltbot，语感上来自“蜕壳”这个词，因为整个重构过程给我的感受，就像帮一个只会按指令挥爪子的机械体，换了一套能自己生长的神经系统。

标题里的>>符号，我理解为“演进到”的关系，不是简单的版本升级，而是设计思路的替换。Clawdbot 解决的问题很朴素：能不能让模型自己拆解任务、调工具、汇总结果。它做到了。但当我拿它跑真正有深度的探索类任务——比如“梳理某一个开源社区近三个月关于检索增强生成（RAG）系统在工程落地上的实践动向”——它的执行记录里开始频繁出现同一个毛病：越往后越偏题，收集到的线索堆成了一大片，结论却越来越薄。

Moltbot 的出现不是因为 Clawdbot 跑不动，而是因为我发现了它跑不动的底层原因。这个原因说出来其实不复杂：它没有自我评估机制，所以控制不了探索的深度和方向。这篇文章不聊理论框架，也不做空泛的行业展望，就围绕我从 Clawdbot 迁移到 Moltbot 过程中实际踩过的问题、改过的代码结构、调过的参数，以及两组真实对比测试的结果，把“探索与发现”类 AI 智能体从能跑，到跑得聪明这个阶段该做的事完完整整摊开讲。

1.1 “探索与发现”类任务的三个真问题：目标漂移、深度失控、信息孤岛

先说清楚我为什么会盯上“探索与发现”这个方向。因为它是智能体应用里最接近“研究助理”的场景——不是回答一个问题就结束，而是要一个大方向，产出覆盖多源的综合结论。这种任务和传统问答类智能体对能力的要求完全不同，我拆下来主要有三个层：

第一层是目标漂移。任务超过三个检索步骤之后，模型很容易被中途某个信息吸引走。比如它搜索“端侧推理框架对比”，看到某一篇关于量化技术的文章不错，就顺着量化往下挖了两轮，回来时已经忘了最初要对比的是哪些框架。这个问题在第一代里极其常见，几乎每三条执行日志里就有一条能对得上。

第二层是探索深度无法量化。怎么判断一个话题“已经摸得差不多了”？全靠模型感觉。有时候它对一个子主题翻来覆去地搜索，产出内容却高度重复；有时候又蜻蜓点水，搜一轮就急着写结论。我没有办法在程序里给它划定“探索边界”，因为边界本身和任务内容强相关，写死在代码里不可行。

第三层是信息孤岛。每一轮检索的结果用完就丢，下一轮重新开始，模型不知道“已经掌握什么线索、缺什么视角”。这就导致同一个来源在报告里反复出现，而真正缺失的信息没人发现。

这三个问题在 Clawdbot 的架构里基本无解，因为它们的根子都在“智能体自身的管理能力”上——它缺的不是工具，而是管理工具的能力。Moltbot 的一切改动，本质围绕这三层来补。

2. Clawdbot 的能力边界：第一代方案的执行回路与它在真实任务中的表现

2.1 第一代架构拆解：三件套工具链加一段长提示词

Clawdbot 的架构是我从零手搓的，最早期就三个组件：一个负责调度的模型封装层，一组检索和解析工具，一个报告生成器。调度层负责读任务指令，决定调用哪个工具；工具层包含网页搜索、页面正文提取、关键词过滤和去重；报告生成器把检索到的内容合并成Markdown结构输出。整段流程串起来是这个模式：

收到任务 → 模型拆解出检索关键词 → 逐个关键词发起搜索 → 抓取关键页面正文 → 按固定模板汇总输出。

当时为了稳定，我在提示词里写死了输出格式，要求每条线索必须带五个字段：来源、摘要、可信度、相关任务项、下一步动作。这个设计在早期非常好用，所有输出都能回溯，格式永远统一，排查问题看日志一目了然。我现在回头看，Clawdbot 的前两个星期，它确实是我需要的东西。

崩溃通常发生在第三个星期之后，当任务复杂度开始上升时。它的三个组件之间缺少一个“指挥官”，调度模型看似在指挥，实际上只是在执行“下一步调用哪个工具”的局部决策，不掌握全局进展。

2.2 执行日志里反复出现的三类翻车现场

我在跑了大约二十天后，开始有意识地统计执行日志里的失败模式。统计了整整一周，翻车集中在这三类：

第一类，长任务后半程偏离主线。一个任务是“对比四种主流向量数据库在百万级数据下的召回表现”。它前两轮还算正常，分别检索了各数据库的基础信息和性能报告。到第三轮时，它搜到一篇关于索引算法的论文，开始深入研究SSD索引结构，连续发了四轮相关检索。最终报告里四个数据库的对比数据残缺，索引算法倒是列了一大段。我看了半天日志，发现没有任何机制能在第二轮结束时提醒它“对比目标还没完成”。

第二类，重复线索不做归并。同一篇文章在多个渠道转载，它会把每一条转载都当成独立线索收集。一份报告里出现五六个指向同一原文的重复条目，严重干扰结论部分的整合。我加了基于标题相似度的去重，但只能去除完全相同的内容，语义重复的照样混进来。

第三类，停止条件混乱到随缘。任务描述说“尽量全面”，它能连续搜索二十多轮；说“挑三个重点方向”，它在第三轮就停手。停止逻辑完全没有和任务中的信息覆盖度挂钩，给我的感觉就是——Clawdbot 分不清“够了”和自己“累了”的区别。

2.3 复盘结论：Clawdbot 只有执行回路，没有评估回路

把这三种翻车放到一起，对应关系很清晰：目标漂移对应了没有全局规划；重复信息对应了没有状态记忆；停止条件混乱对应了没有达成度判断。这三点指向同一个结构缺陷——执行回路和评估回路是分离的。

Clawdbot 的执行回路非常完整：拆解指令、调用工具、处理结果、输出报告，每一步都按部就班。但它没有任何一个环节能回答四个问题：现在做到哪一步了？这一步做得对不对？和任务目标比还差多少？下一步应该修正还是继续？

没有这组能力，它就是一个“听话但没有全局观”的执行工。发现问题之后，我花了一周时间尝试在 Clawdbot 上打补丁——加中间评估提示词、增加停用词、写更细的输出模板——全部效果有限。补丁解决不了结构性问题，这成为 Moltbot 重构的直接导火索。

3. Moltbot 的“蜕壳”改进：第二代方案里的五个关键设计

3.1 入口处新增“目标分解阶段”：从直接干活变成先做计划

Moltbot 的第一个改动，是任务进入执行前先做一轮目标分解。收到用户任务后，系统不会立即调用任何检索工具，而是先让模型根据任务内容生成一个两层结构的设计：

第一层是一组关键问题，数量大概三到七个，完全由任务内容决定；第二层是每个问题对应的检索路径，也就是“为了回答这个问题，应该从哪里查起、查哪些类型的信息”。

举个例子，任务“了解某智能体编排框架的插件开发生态”分解之后会长这样：

关键问题1：该框架的插件机制支持哪些类型的扩展？ 检索路径：官方文档 → 插件开发教程 → 社区插件列表 → 插件示例仓库 关键问题2：当前社区活跃度如何？ 检索路径：最近三个月更新日志 → 公开仓库提交频率 → 社区讨论热点

这一步不产生任何检索调用，但后面的所有行为都以它为锚。模型在后续任何环节都会知道“当前操作是为了回答哪个问题”，一旦发现正在检索的内容和所有关键问题都不相关，它就有理由主动修正方向。我在实际使用中感觉，这个阶段是 Moltbot 相对 Clawdbot 行为改进最明显的一处：从凭感觉探索，变成有依据地探索。

3.2 探索履历与线索标签：让中途发现变成结构化资产

第二个改动是引入“探索履历”机制，这是解决信息孤岛的关键。Clawdbot 每轮检索的结果用完就丢，Moltbot 则维护一个全局的线索列表。每轮检索后，新得到的信息会被追加到列表中，并打上几类标签。

这些标签不依赖模型理解，而是由规则生成，包括：所属关键问题、涉及子主题、与已有线索是“重复”“补充”还是“冲突”。后续检索时，系统会把“已有线索摘要+已覆盖子主题清单”拼回当前上下文中，让模型明确知道哪些方向已经有足够材料，哪些还缺。

这个设计的直接收益是：重复搜索行为大幅减少。测试中，同一个任务里 Moltbot 检索轮次比 Clawdbot 少了两到三成，输出里却多出不少 Clawdbot 之前根本碰不到的“冷线索”，因为它知道自己缺什么，而不是反复去找已经有的。

3.3 内置自评估与停止阀：给探索过程装上限位器

停止条件的实现，是这次重构最核心的结构变化。Moltbot 在每个检索轮次结束后，会执行一次自评估流程，评估项目包括当前覆盖率、信息冲突程度和剩余检索价值。每项都以数值打分，并记录到当前任务的运行状态中。

停止逻辑如下：若连续两轮评估显示覆盖率超过设定阈值（比如百分之八十），并且剩余检索路径的目标相关性低于另一个阈值（比如百分之三十），则探索阶段自动结束，进入报告生成。这个机制解决了 Clawdbot 时代最头痛的“不知道什么时候该停”问题。

我也在测试中踩过阈值设置不当的坑——一开始把覆盖率阈值调到百分之九十五，结果任务经常耗尽最大检索轮次才结束，产出却没有显著提升。后来改成百分之八十配合连续两轮判定，任务耗时和输出质量取得了比较合理的平衡。

3.4 探索入口从纯文本扩展为多模态：截图和图表不再被遗漏

第三个结构性改动，扩展了探索入口。Clawdbot 只能处理文本内容。但在实际测试中我发现，技术类素材大量以截图、架构图、对比表的形式存在，这些内容用纯文本检索是根本碰不到的。

Moltbot 接入了一类图像采集工具：当检索结果中出现图表类内容时，会触发截图和OCR处理流程，把图像里的文字信息提取后作为文本线索加入履历。这轮改动让我运营的探索任务覆盖面提升了一个档次——很多只在视频截图、数据图表里出现的细节，第一次进入最终的输出报告。

3.5 工具接入改为注册表模式：新增能力不再需要重新调试主流程

最后一个改动是工具层的管理方式。Clawdbot 时代每加一个新工具，都要在调度提示词里增加一段调用说明，还要在主流程里加处理分支，改动牵一发动全身。

Moltbot 把工具改成注册表模式。每个工具维护一份独立的描述文件，包含功能声明、输入输出参数、适用场景和典型失败模式。调度模型通过扫描注册表来了解“当前有哪些可用能力”，新增工具只写描述文件，不需要改动主流程逻辑。后来我陆续给 Moltbot 加了几个新检索源，接入时间从原先的半天级缩短到半小时级，而且从未因为接入新工具影响过原有功能。

4. 实测对比：同一个探索任务下，两款智能体的差距具象呈现

4.1 测试环境与任务设定：尽量做到只差代号

为了验证重构值不值得，我做了一组并排测试。测试环境保持一致：同一个模型版本、同一台设备、同样的最大运行轮次限制。任务模板选了一个能体现“探索与发现”能力的开放式问题——梳理某开源技术子领域当前的方案生态，要求至少覆盖六个子主题、引用不少于十二个来源、结论处必须标明信息置信度。这个任务我在 Clawdbot 时代跑过不只一次，对它的表现有非常直观的印象。

4.2 输出质量对比：覆盖度、信息深度和结构完整性的差异

先看覆盖度。Clawdbot 最终报告实际覆盖的子主题是四个，来源数九个，其中三个来源内容高度重叠。Moltbot 实际覆盖了全部六个目标子主题，引用来源十九个，重复率明显降低。

再看深度。Clawdbot 的报告里大量内容是机械地摘要原文，缺少跨来源的归纳和对比。而 Moltbot 因为有了探索履历和线索冲突检测，报告中自动出现了一些“来源A的数据与来源B不一致，差异点集中在…”这样的综合分析段落，可信度和信息量都高出不少。

4.3 运行耗时与API成本：进化方案没有预想中昂贵

比较让人意外的是效率变化。Clawdbot 在这个任务上跑完了全部最大轮次限制，耗时约十九分钟，调用工具次数远超实际需要。Moltbot 任务完成时间约十三分钟，少于Clawdbot，调用次数也有明显下降。主要省在重复检索：因为已探索领域会被标记，Moltbot 不会反复搜索同一个话题。即便加入了自评估和目标分解带来的额外模型调用，总API成本也只是基本持平，没有明显上升。

4.4 边界情况：两款方案同时失效的场景

最后也说说边界情况。两个方案在遇到一类场景时都会失效：任务目标本身就模糊，且没有任何可参考的检索起点。我在测试中故意给了它一个空泛任务“探索推荐算法”，两款方案都表现为检索关键词过于宽泛，得到大量低质量结果，最终报告空泛。这说明智能体的上限依然受制于任务设定本身，它能把清晰的探索任务做得更强，但无法凭空定义模糊的目标。

5. 复现要点与避坑记录：从Clawdbot迁移到Moltbot容易踩的五个坑

5.1 目标分解阶段的提示词不能照抄，必须绑定自己的工作节奏

如果你也想给智能体加“目标分解”阶段，我建议不要直接拿别人现成的目标分解提示词套上去。目标分解的效果取决于任务说明书的质量——我在 Moltbot 上花了不少时间反复调整分解阶段的提示词，才让它生成的“关键问题”贴合我的真实需求。最初照搬通用模板时，模型生成的关键问题经常停留在概念层，比如“什么是RAG”，实际检索时根本用不上。后来在模板中强制要求“每个关键问题必须包含一个可检索的实体词和一个预期信息类型”，效果才稳定下来。

5.2 自评估阈值不能一开始就追求“完美”

覆盖率的阈值影响全局效率。我在测试中发现，把目标覆盖率设到百分之九十以上，系统会为了最后几个边角信息反复发起低价值检索；而阈值偏低会导致输出太单薄。几次试下来，以百分之八十为探索终止线，配合连续两轮确认，能兼顾深度和效率。如果你的任务里信息源比较分散，建议调低到百分之七十五观察一下；如果任务面比较窄，再考虑调高。

5.3 探索履历是上下文大户，塞不下就分层

探索履历设计得再精妙，也不可能把所有原始信息全部塞回上下文。跑长任务时我发现上下文窗口很容易被履历挤满，导致模型读不到最新的检索结果。解法是给履历做分层：保留进入上下文的是一层压缩摘要和标签，原始全文留在外部存储中。模型需要判断某一个信息是否要深入时，再按需读取原文。这个改动看起来不起眼，但对长任务稳定性影响极大。

5.4 工具注册表里的失败模式字段，日常用不到、故障时救命

注册表描述文件里“典型失败模式”这个字段，我一开始觉得是多余的，随便填了两句。直到某次一个数据源改了接口格式，工具频繁报错，但模型的日志里看不出原因，才发现当初填写的失败模式字段恰好能帮助我快速定位“是否该停用这个工具而不是反复重试”。现在我在每个工具的注册文件里都会认真记录可能发生的异常类型和处置建议。

5.5 测试任务不要只测“顺利情况”，要加上干扰源

最后这条来自教训。Clawdbot 时代我做测试，偏好挑边界清晰、信息充足的任务，导致很多问题没暴露。Moltbot 稳定后，我特意加了几组“难啃”的测试任务，包括信息源互相矛盾、子主题之间重叠度高、网络中夹杂大量无关结果等场景。这些压力测试逼出了不少隐藏问题，尤其是冲突检测和停启阀的稳定性，都是在干扰环境下调好的。如果你做类似系统，建议至少在测试集里留三分之一给这种“脏”任务。

从 Clawdbot 到 Moltbot 这段重构经历，我最大的体会是：做“探索与发现”类智能体，真正值钱的部分不是让它多会调用工具，而是让它多会“管理自己”。能意识到自己探索到什么程度、缺什么信息、何时该停，这些元能力的价值远超任何单个工具的效果。如果你正在做类似的智能体项目，遇到我前面描述的翻车情况，不妨先停下来想一想：它缺的是一次补丁，还是那条执行回路之外的评估回路。