首页 / 资讯中心 / 文章详情

从Clawdbot到Moltbot:AI智能体重构中的自我评估与探索控制

从Clawdbot到Moltbot:AI智能体重构中的自我评估与探索控制 ★ FEATURED ARTICLE
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 这段重构经历我最大的体会是做“探索与发现”类智能体真正值钱的部分不是让它多会调用工具而是让它多会“管理自己”。能意识到自己探索到什么程度、缺什么信息、何时该停这些元能力的价值远超任何单个工具的效果。如果你正在做类似的智能体项目遇到我前面描述的翻车情况不妨先停下来想一想它缺的是一次补丁还是那条执行回路之外的评估回路。
阅读完成 · 觉得有帮助?
咨询建站