让 JiuwenSwarm 越用越好：从用户习惯出发设计自进化 Harness

一、博客写完了，习惯能留下来吗？

让智能体写一篇技术博客，通常只需要一句话：

“帮我调研这个开源项目，写一篇中文博客，最好图文结合。”

资料收集、内容整理、初稿生成，看起来都很顺利。等到审稿时，你却发现还有几处需要修改：引用的是二手解读，正文缺少源码依据；配图有了，但没有解释核心流程；资料列了不少，却没有讲清开发者可以怎样使用。

于是，你补充了几句要求：

“技术结论优先查官方文档和源码。”

“把设计思路讲清楚，用一个具体场景串起来。”

“先给我 Markdown 和图片，方便继续编辑。”

这一版改好了。下次换个项目，相似的要求又要说一遍。

对于经常用智能体做调研、写作和办公的用户，重复沟通是一项真实成本。我们希望智能体既能完成眼前的任务，也能从这些反馈中积累经验：记住适用的习惯，改进经常出问题的步骤，在下一次同类任务中用起来。

JiuwenSwarm 已经为这件事提供了起点。华为云社区的 博客生成案例 展示了从安装 Skill、资料检索、生成初稿到配图和用户确认的完整工作链路。沿着这条链路，还可以继续设计：让用户在任务中的纠正，进入后续任务的执行方式。

二、JiuwenSwarm 的底座，为什么适合持续改进？

1. 从一句需求，到一条可推进的任务链路

Harness 可以理解为智能体的运行系统。模型提出行动，Harness 负责组织工具、上下文、记忆和任务状态，把行动落实到具体操作。

在博客场景中，它要处理的不只是“生成一段文字”，还有一连串工作：先确定主题，再查资料，读取原文，整理结构，写初稿，画图，检查内容，最后交付文件。中途用户要求换个角度，系统也要能接住这个变化。

JiuwenSwarm 的 DeepAgent 用两层循环组织这些工作：内层 ReAct 完成“推理—行动—观察”，外层 Task Loop 推进任务、接收补充和处理结束判断。Skill 提供任务做法，MCP 接入外部工具与资源，记忆保留跨任务信息，Rail 则在任务和工具调用等关键位置插入处理逻辑。Harness 文档（docs/zh/Harness.md）

图 1：JiuwenSwarm 的运行底座与已有优化入口。任务过程可以提供问题线索，扩展接口为后续改进留出位置。

这意味着，发现问题之后，开发者可以定位到具体部件：检索步骤不完整，就调整研究 Skill；工具选择不合适，就调整调用策略；内容检查太晚，就重新安排工作流。

2. Auto Harness 已经提供了改进通道

JiuwenSwarm 已有 Auto Harness，能够围绕评测结果识别差距、规划修改、实施并再次评测。共享底座的改进走 Meta Harness 路径，通过源码变更和 PR 审查推进；领域能力的改进走 Expert Harness 路径，形成可加载的扩展包。Auto Harness 文档（docs/en/AutoHarness.md）

Skill 自演进也已有经验保存、演进审查、重建与回滚机制。值得关注的是，官方文档将个人偏好、一次性事实和临时环境问题排除在通用 Skill 演进建议之外。Skill 自演进文档（docs/en/SkillSelfEvolution.md）

这个边界很符合实际使用。你喜欢短文，另一位用户喜欢详细教程，两人的写作方式都合理；一次网页打不开，也不能说明这条检索链路永远无效。

在已有能力上继续设计，关键是把日常反馈送到正确的位置。哪些内容只需要记住，哪些问题值得修改 Skill，哪些改动需要交给 Auto Harness，都应有清楚的去向。

三、核心设计：习惯进入个人层，能力进入组件层

本文建议在现有机制上接入一层反馈分流：结合用户纠正、任务过程和最终产物，分别处理个人习惯与可复用的问题。

图 2：双层适配设计。个人层减少重复沟通，组件层改进任务做法，两条路径都服务于后续任务。

1. 个人层：把合适的习惯变成默认设置

“这类文章用中文”“先交付 Markdown”“配图重点解释流程”，适合成为用户的写作默认值。任务开始时，JiuwenSwarm 根据用户、项目和任务类型加载这些设置。

默认值要有范围。例如，博客写作偏好用于技术博客；切换到英文论文润色时，系统应按新的任务要求工作。用户明确说“以后都这样”，可以保存为长期设置；只说“这次短一点”，就作为本次要求。由重复行为推断出来的习惯，可以先向用户提出建议。

这一层可以利用已有记忆和上下文机制，让任务一开始就更贴近用户要求。它也能保持公共 Skill 的通用性：同一套博客写作能力，加载不同的个人设置，就能适应不同读者。

2. 组件层：把重复问题变成可复用的改进

如果每次调研都漏读原始页面，或者工具持续使用错误参数，单纯记住“用户不满意”帮助有限。系统需要沿着任务过程找到原因，再提出具体修改。

以来源质量为例，可以检查：是否只读了搜索摘要？是否选错了页面？是否已经读到原文，却在写作时扩大了结论？不同原因对应不同改动。

候选修改可以进入既有 Skill 演进或 Auto Harness 通道。一次优先改动问题所在的部件，确认有帮助，再考虑组合优化。

3. MCP 的适应，先从“选对工具”开始

对大多数用户而言，已有工具不少，难点是调用时是否选对。

写技术博客时，有的工具擅长发现资料，有的适合读取文档，有的能搜索代码。系统可以从实际任务中积累选择经验：哪种工具适合查项目入口，哪种适合读取原文，什么条件下需要转向源码检索。

因此，MCP 相关改进可以先落在工具发现、路由和参数模板上。确实出现能力缺口时，再考虑修改适配器或接入新服务。新增服务访问仍由用户决定，个人习惯也不会自动扩大外部权限。

四、具体案例

我们以“调研开源项目并写中文图文博客”为例，把这套设计放进一次连续使用过程。

第一步：完成第一次任务，留下可用反馈

用户提出需求：

“帮我分析这个开源项目，写一篇适合开发者阅读的中文博客。解释它的设计思路，配两张流程图，交付 Markdown。”

JiuwenSwarm 调用相关 Skill 和工具完成资料收集、写作与配图。用户审稿后指出：“设计部分缺少使用场景，读者很难理解；关于项目能力的结论，要给原始来源。”

系统可以把反馈和对应内容关联起来：哪些是写作方式要求，哪些涉及实际引用问题，哪些步骤由什么 Skill 和工具完成。

第二步：分清“我喜欢这样”与“这里做错了”

这一步决定经验该存在哪里。

同一句“优先官方来源”，可能是用户的工作要求，也可能暴露了检索步骤的缺陷。结合实际任务内容，才能决定只保存约束，还是进一步修改流程。

第三步：给 Skill 一个具体、局部的改进

如果发现研究 Skill 经常停留在搜索结果页，可以提出一个很小的修改：针对正文中的关键能力声明，读取对应官方页面，并保留支持它的段落或源码位置。

如果文章总是先罗列论文再谈项目，则可以为技术博客任务增加一个适用分支：从开发者场景开篇，围绕目标项目解释设计，再用案例展示工作过程。论文只用于帮助读者理解某个机制。

这类改进需要保留适用条件。面向社区的博客和面向研究者的综述，写法本来就不同，系统可以选择相应分支。

第四步：让工具和流程配合起来

研究 Skill 明确了要做什么，工具路由负责找到合适的执行方式：先发现项目资料，再读取原始页面，必要时查源码。写作前完成关键来源检查，减少成稿后的返工。

配图也可以纳入流程。用户偏好“用图讲清设计”，写作 Skill 就应在搭建文章结构时判断哪些机制适合画图，并让图与案例保持一致。简单任务直接调用工具，复杂且独立的资料收集可以委派子智能体，具体选择结合时间和资源要求。

图 3：博客任务中的反馈去向。格式偏好进入个人层，来源和步骤问题推动组件改进。

第五步：换一个项目，复用经过确认的做法

下一次，用户只说：

“帮我分析另一个开源项目，也写成技术博客。”

按照这套设计，JiuwenSwarm 可以加载该用户的博客设置，选择适用的写作分支，沿合适的工具链取证，最后交付正文、配图和来源清单。

用户仍然可以随时调整要求：“这次给业务同事看，少写源码细节。”新的要求会改变本次执行方式。经过确认的默认习惯提供起点，具体任务决定最终做法。

这就是持续适应希望带来的变化：少一些重复说明，少一些相同返工，把更多沟通留给新任务本身。

参考资料：JiuwenSwarm 项目、社区 Auto Harness 介绍、Skill 自进化机制。本文配图为原创概念示意。