智能体已经能够帮开发者整理需求、编写代码，甚至独立完成一些相对复杂的任务。但在实际使用中，我们经常会遇到一个问题：智能体这次犯了错，经过纠正后完成了任务，下次遇到类似情况，却可能再次出现相同的问题。
以日常需求交付为例，一项功能经过评审后调整了业务规则，智能体可能正确更新研发任务清单，却遗漏了验收检查表中的对应内容。开发者发现问题后，需要重新检查材料、解释要求，再让智能体修改。
如果类似问题不断重复，人工纠错依然会占用不少时间。那么，能不能让智能体从任务结果中总结经验，主动调整自己的工作方式，并把这些调整保留下来？
这正是递归自我改进（Recursive Self-Improvement，RSI）希望解决的问题。
openJiuwen 将 RSI 能力引入了 WorkSwarm。我们选择了一项常见的需求交付工作，通过真实操作观察智能体如何完成任务、根据反馈提出改进，以及这些改进是怎样接受验证的。
智能体如何自我改进？
在讨论 RSI 之前，需要先理解智能体的工作方式。
传统的大模型主要根据输入生成内容。智能体在此基础上增加了工具调用、任务规划、文件操作和执行管理等能力，可以持续处理一项任务，并交付具体成果。
openJiuwen 是面向智能体开发与应用的开源项目，WorkSwarm 则提供了面向实际任务的智能体工作环境。开发者可以通过 WorkSwarm 组织任务、管理技能，让智能体参与文档处理、研发协作等工作。
不过，智能体最终能否完成任务，除了模型自身的能力，还会受到提示词、工具、技能、上下文以及执行约束等因素影响。
在 openJiuwen 的技术体系中，这些与模型运行相关的工作机制被称为 Harness。
可以这样理解，模型负责理解和生成内容，Harness 则进一步规定智能体应该如何完成任务，包括使用哪些工具、遵循什么流程，以及在交付结果前进行哪些检查。
这也为智能体的自我改进提供了方向。
当任务出现问题时，开发者可以调整提示词或技能，让智能体采用新的处理方式。RSI 则尝试让智能体参与这个过程，根据任务反馈分析问题、生成修改方案，再通过评测判断修改是否值得保留。
目前，openJiuwen 的 RSI 支持两个主要优化方向。
- Harness 优化主要面向提示词、技能等工作配置，通过调整智能体的执行方式，尝试改善后续任务表现。
- Artifacts 优化则面向具体交付产物，例如科研论文、算法程序等，让系统围绕目标持续修改和验证产物。
本次实测选择 Harness 优化。
我们希望观察的是，智能体在需求交付中遇到问题之后，能否将具体的纠错要求整理成一套更通用的检查方法，并形成能够继续验证的工作配置。
这类改进有一个值得关注的特点。它可以围绕现有模型的工作方式进行调整，无需先对大模型进行重新训练。
对于已经使用智能体开展实际工作的开发者，这意味着可以从现有任务、提示词和技能出发，尝试逐步完善智能体的执行流程。
需求交付能否做对？
为了观察 RSI 的实际工作过程，我们选择了一个常见的业务场景——活动报名工具的需求交付。
在日常软件开发中，一项需求通常不会在第一次讨论时就确定全部细节。随着业务评审推进，报名人数、审核规则、通知方式和人员分工都可能发生调整。
这些变化需要同步到研发任务、验收条件和待确认问题中，才能让开发人员按照最新要求开展工作。
我们按照这一过程准备了多组活动资料，每组提供三份文件，分别是旧版需求、最新评审记录和分工安排。
WorkSwarm 需要读取这些材料，最终生成研发任务清单、验收检查表和待确认问题。本次使用 WorkSwarm 0.2.7，接入 DeepSeek 官方模型服务，调用模型为
deepseek-flash，开启 high 思考模式。我们准备了 12 组先期任务用于优化，另留 6 组材料观察后续任务表现。整个过程先运行普通业务任务，再进入 WorkSwarm 的 RSI 实验功能，观察它如何根据任务反馈生成修改候选。
需求变更是否遗漏？
我们先观察 WorkSwarm 能否准确处理业务材料中的变化。
以公益读书讲座为例，旧需求采用提交成功即报名有效的方式，评审后调整为先提交申请、再由工作人员审核，只有审核通过才占用活动名额。与此同时，活动容量由 45 人调整为 30 人，短信通知也被取消。
这些变化涉及多项研发工作。任务清单需要反映新的审核流程，验收检查表需要检查审核状态和人数限制，取消的功能不能继续列入本期开发范围。
对于还没有明确的业务规则，智能体还需要区分已经确定的事项和等待进一步确认的事项。
从实际执行来看，WorkSwarm 在明确业务要求的整理上表现较好。
先期 12 组任务中，我们检查了 120 项具体业务要求，其中 110 项通过核对。部分活动的业务要求全部处理正确，说明智能体已经能够从多份材料中提取关键信息，并将它们整理成结构化交付内容。
但需求交付还有一个更深一层的问题：单个要求写对了，并不代表整套交付文件已经完全一致。
例如，研发任务清单中正确写出了报名截止时间，验收检查表却可能采用另一种边界条件。或者某项规则已经被列为待确认问题，其他文件却提前按照某个答案安排开发。
这些细节在单独阅读某一份文件时未必明显，却会影响开发人员对需求的理解。这也为 RSI 提供了一个具体的优化方向。如果智能体能够在交付前主动检查同一条规则在不同文件中的表达，就有机会减少重复出现的关联性问题。
修改能否通过复测？
在 WorkSwarm 的 RSI 实验中，系统会根据任务材料、执行结果和评价反馈尝试生成改进方案。这次最值得关注的，是原生优化流程生成的一项技能候选。
它的名称为
time_boundary_consistency_check，对应时间边界一致性检查。这项技能针对的是需求交付中常见的时间规则问题。例如，报名截止时间为某天18点，那么恰好18点提交的申请是否有效？审核截止之后，尚未处理的申请应该进入什么状态？研发任务和验收条件是否采用了同一套规则？
类似问题往往会分散在多份文件中。如果智能体只检查每份文件中的时间是否正确，仍然可能遗漏文件之间的差异。
WorkSwarm 生成的技能候选，针对这种情况提出了更具体的处理方法。
首先，确定每个时间节点采用什么边界规则。对于已经明确的时间要求，需要统一包含或排除该时刻的判断口径。
接下来，按照时间节点查找它在不同交付文件中的所有出现位置，逐一检查任务说明、状态表和验收条件。
对于业务材料没有明确规定的事项，则继续保留待确认状态，避免为了统一文档而自行补充规则。
同时，这项技能还限制了修改范围，要求不要因为处理时间问题而擅自改变容量、权限等其他业务条件。
这项候选最有意思的地方，是它对问题进行了进一步归纳。在单次需求交付中，开发者通常会指出某个截止时间写错了，或者某份验收文件中的条件需要调整。
而这次生成的技能候选，将问题整理成了更通用的检查步骤。
以后处理其他活动时，虽然日期和业务规则可能发生变化，但统一时间边界、检查所有关联位置、保留未决事项的处理思路仍然具有参考价值。
这让我们看到了 Harness 优化的一种具体形式——将任务中发现的问题，转化为可以审阅和进一步验证的工作规则。
当然，生成候选之后，还需要判断它是否真正符合预期。
本次候选在原生定点核对中出现了评分变化，但独立核对仍发现部分业务问题，后续验证也遇到了技能激活轨迹识别和配置引用兼容方面的限制，因此没有形成可发布的改进版本。
这说明候选内容的合理性、实际执行情况和最终能否采用，还需要分别验证。对于开发者来说，这个过程仍然值得观察。我们已经能够查看 WorkSwarm 实际生成的技能内容，理解它针对的问题，并根据具体规则检查修改是否合理。
改进能否用于新任务？
一次改进是否有价值，还要看它能否用于后续的同类任务。
以活动报名工具为例，不同活动可能涉及报名截止、候补确认、取消报名和审核截止等时间要求。虽然业务规则各有不同，但都需要检查同一时间条件在研发任务、状态说明和验收条件中是否保持一致。
本次 WorkSwarm 生成的时间边界一致性检查技能候选，就将这类问题整理成了三个具体步骤。
首先，明确截止时刻的判断口径；其次，检查同一时间规则在不同文件中的所有出现位置；最后，对业务材料尚未确定的规则继续保留待确认状态。
这种处理方式具有一定的通用性。即使活动内容和具体日期发生变化，智能体仍然可以按照相同的方法检查时间规则，无需为每个活动单独设计一套检查步骤。
我们还准备了另外 6 组活动，在原始配置下分别进行首次执行和普通重做。两次生成的结果出现了一定波动，部分问题得到改善，也有部分内容出现新的问题。
本轮尚未形成可安装的最终改进配置，因此还没有验证这项技能在新会话中的实际表现。不过，从已经生成的技能候选来看，WorkSwarm 展示了将具体业务问题整理为通用检查规则的能力。
接下来值得关注的是，这类技能能否在新的任务中正确加载，并持续检查不同交付文件中的时间条件，同时保持原本正确的业务内容。
人工返工能否减少？
对于开发者而言，智能体自我改进最终还是要回到实际工作效率上。如果一套工作规则能够在后续任务中反复使用，那么开发者就有机会减少相同问题的重复检查。
从这次实操来看，WorkSwarm 展示出了两个值得关注的特点。
- 首先，它已经能够承担较为完整的需求整理工作。
开发者可以提供现有需求、评审记录和人员分工，让智能体生成研发任务、验收条件和待确认事项。在本轮任务中，大部分明确的业务要求都得到了正确处理。
这意味着开发者可以先获得一套结构化交付初稿，再把核对重点放在跨文件关系、尚未确定的业务规则以及复杂边界条件上。
- 其次，RSI 提供了将问题进一步整理为工作配置的途径。
这次生成的时间边界检查技能，就是一个比较直观的例子。
它将开发者关心的时间一致性问题，整理成可以逐项审阅的检查要求。即使最终没有形成可发布的改进，我们仍然能够看到智能体提出的具体策略，并据此理解它希望如何调整执行方式。
对于持续处理同类任务的开发者，这种改进方向具有实际意义。
我们可以进一步设想，在需求分析、代码检查、文档交付等重复性工作中，如果能够积累经过验证的提示词和技能，就可以逐渐完善智能体的工作流程。
本次实测让我们看到了 WorkSwarm 如何根据任务反馈生成具体的技能候选，为后续优化工作方式提供了新的思路。至于这类改进能够在多大程度上减少人工核对和返工，还需要结合后续任务的实际应用效果进一步验证。
从使用角度来看，更合理的做法是先选择错误能够明确判断、任务可以重复执行的小型场景，在验证修改有效之后，再逐步扩大应用范围。这样既方便理解每一次改进的作用，也更容易控制优化过程中消耗的时间和模型资源。
总结
通过这次 WorkSwarm 实操，我们对 RSI 有了更具体的认识。
一方面，WorkSwarm 已经能够处理包含多份需求材料的业务任务，生成结构化的研发交付内容。在明确业务要求的整理方面，它表现出了较好的完成能力。
另一方面，openJiuwen 的 RSI 让我们观察到了工作方式优化的实际过程。系统能够根据任务反馈提出技能和提示词修改候选，其中时间边界一致性检查技能，将具体业务问题整理成了具有一定通用性的检查步骤。
这让开发者能够进一步审阅智能体打算怎样修改自己的工作方式。
通过这次实测，我们看到 WorkSwarm 能够将需求交付中发现的具体问题，整理成具有明确检查步骤的技能候选，为智能体持续优化工作方式提供了新的思路。随着评价和验证机制进一步完善，这类改进有望在更多任务中发挥作用，让智能体逐步积累可以复用的工作经验。
对于希望尝试 RSI 的开发者，可以先从已经遇到过的实际问题入手，提供明确的任务材料和检查要求，观察智能体能否生成合理的改进方案，再通过复测判断这些调整是否值得保留。
智能体要想越用越好，关键在于能否把一次任务中的经验，逐步积累成经过验证、可以继续使用的工作能力。
