一家店每天产生订单，也会通过不同渠道收到款项。到了核对账目的时候，业务人员需要把订单明细和收款流水放在一起，确认哪些订单已经收款、哪些金额存在差异，还有哪些记录需要进一步查证。
看起来只是两张表之间的比对，实际处理起来却有不少细节。同一笔流水可能重复导出，订单编号的首尾可能多出空格，一笔订单也可能分两次收款。如果处理规则不够完整，就可能把正常收款当成异常，或者把重复记录多算一次。
开发者可以让智能体读取文件、编写程序，再将核对结果整理成清单。不过，一次任务完成之后，新的问题也随之出现。发现异常时，智能体能否把相关来源整理清楚？开发者提出的纠正要求，能否保留下来，在下一批账表中继续使用？
这也是递归自我改进（ Recursive Self-Improvement，RSI ）值得关注的地方。它尝试根据任务结果和评价反馈调整智能体的工作方式，让一次任务中发现的问题，成为后续改进的依据。
我们以一家模拟的云杉文具店为例，使用 openJiuwen 的 WorkSwarm 处理订单表和收款表，观察智能体怎样完成核对、根据反馈生成修改候选，以及经过筛选的工作配置如何进入后续任务。
RSI 如何改进智能体的工作方式？
理解 RSI，可以先从智能体完成任务的过程说起。
模型负责理解输入和生成内容，智能体还需要按照任务要求读取文件、调用工具、执行程序，并整理最终交付。影响这一过程的提示词、技能、工具和执行约束等工作配置，通常被称为 Harness。
以收款核对为例，开发者可以明确规定，同一笔流水重复出现时只能计算一次，找不到订单的收款需要单独列出，待核查事项需要保留相关来源。这些要求会影响智能体采用什么处理方式，也会影响结果能否被后续人员直接理解和核查。
当任务出现问题时，开发者通常会补充说明，或者调整提示词与技能。RSI 尝试让智能体参与这一步，根据任务结果和评测反馈分析问题，生成修改候选，再通过重新评测判断哪些调整值得保留。
openJiuwen 将相关能力引入了 WorkSwarm。开发者可以围绕实际任务，观察系统提出了什么修改，以及这些修改怎样接受检查。
目前，openJiuwen 的 RSI 支持 Harness 优化和 Artifacts 优化两个方向。Harness 优化面向提示词、技能等工作配置，关注智能体采用什么方式完成任务；Artifacts 优化面向论文、程序等具体产物，围绕产物本身进行修改和验证。
本次实际运行的是 Harness 优化，调整对象是异常来源整理技能和对账交付检查要求。负责对账的程序由业务会话中的智能体编写并运行，后续对照观察的也是不同工作配置下的最终交付。
这种改进方式可以围绕现有模型开展，无需先重新训练大模型。对于已经使用智能体处理重复性工作的开发者，可以从已有任务中的具体问题出发，查看系统生成的修改内容，再通过实际执行判断这些调整是否适合继续使用。
两张表能否准确核对？
为了观察整个过程，我们准备了云杉文具店的订单表和收款表。订单表记录订单号与应收金额，收款表记录流水号、关联订单和实收金额。智能体需要读取两份本地 CSV，完成匹配、汇总和异常整理，生成订单核对结果、流水处理明细、待核查清单以及机器可读的核对结果。
开始之前，我们先确定对账口径：订单号去除首尾空格后再进行关联；内容一致的重复流水只计一次；同一流水号对应的订单或金额发生冲突时，保留记录并列为待核查。一笔订单可以由多笔不同流水共同收款，没有对应订单的收款也不能直接丢弃。
本次使用 WorkSwarm 0.2.7 和 openJiuwen core 0.1.19，接入已配置的 deepseek-flash 模型。原生优化使用的评测集包含一组账表，并预先准备逐笔参考结果，用于判断候选是否符合要求；参考结果没有提供给办理业务的智能体。后续还安排了已有账表的回归和新账表的对照，分别检查改动能否继续使用。
首次核对是否准确？
在一组账表中，有一笔订单应收 120 元，实际分两次收到 50 元和 70 元。其中一笔 50 元的流水被重复导出，重复行的编号还带有首尾空格。
初始结果正确识别了两笔有效收款，也排除了重复记录，最终确认金额为 120 元。这个例子说明，面对分次收款和重复导出同时出现的情况，智能体已经能够按照既定口径完成核对。
另一笔订单则让我们看到了不同的问题。
这笔订单应收 145 元，其中两条记录使用了同一个流水号，但金额不同，需要列为冲突。另外还有一笔 95 元的有效收款，应当保留在已经确认的收款结果中。
初始结果将这笔订单标记为待核查，95 元的确认收款也没有算错。但异常清单只列出了冲突流水，没有把那笔有效收款的来源一起写清楚。接手的人如果只看异常清单，还需要回到原表查找关联记录，才能了解这笔订单的完整情况。
这使得我们对交付质量有了更具体的观察。
金额是否正确，是核对结果的一部分；相关记录是否完整、来源能否追溯，也会影响后续人员怎样使用这份结果。
对于需要继续核查的订单，清单应当让人看清已经确认了什么、哪些部分存在冲突，以及相关记录来自哪里。补全这些关联信息，也就成为本次 RSI 优化要解决的问题。
修改能否通过复测？
进入 WorkSwarm 的 RSI 流程后，系统根据任务结果和评测反馈生成了两个修改候选。
第一个候选补全了前面那笔订单的来源信息，但复测时又出现了新问题：一笔找不到对应订单的收款，在用于记录计入订单金额的字段中被错误填入了金额。虽然原来的遗漏得到了修正，这个候选仍未通过评测，也没有被采用。
第二个候选在补全异常来源的同时，保留了无关联收款应有的处理结果。经过完整评测和保留检查后，这个版本被 WorkSwarm 采纳并发布。
最终版本补充了异常来源整理技能，也增加了对账交付检查要求。处理待核查订单时，智能体需要结合全部相关流水整理来源。除了触发异常的冲突记录，已经计入确认金额的有效收款也需要保留下来，方便接手的人看到完整的关联情况。
这项调整有了明确的工作内容。
当订单被列为待核查时，智能体需要检查相关记录是否已经整理完整，避免异常说明只覆盖其中一部分。开发者也可以据此审阅候选，判断它提出的处理方式是否符合既定口径。
两个候选的取舍，还让我们看到了复测的作用。
修正一个已经发现的问题之后，其他原本正确的结果也需要继续检查。来源信息是否完整、无关联收款是否得到恰当处理，都属于交付要求。候选能否保留，需要结合这些要求一起判断。
从具体遗漏中形成处理规则，再通过实际结果检查规则是否有效，是这次优化过程最值得观察的部分。
改进能否在后续任务中复用？
一次任务中的问题得到修正之后，开发者还会关心，这次形成的经验能否进入下一次任务。
对于反复出现的同类工作，一些要求可以从具体数据中提取出来。订单编号、金额和文件内容会变化，但在业务口径保持一致的前提下，待核查事项需要关联完整来源、已经确认的收款需要能够追溯，这些要求仍然可以继续适用。
将它们整理成技能和检查规则，就有了独立保存、再次加载和继续验证的可能。
本次我们另行将采纳后的版本转换并打包为可安装插件，再导入另一个 WorkSwarm 实例。新会话实际读取了插件中的技能内容，并继续处理后续账表。
在统一的交付要求和共同的结果整理步骤下，改进后的配置完成了 12 批已有账表的回归核对，最终结果均达到本次要求。随后，我们安排了四组未参与优化的新账表，让未启用和启用改进配置的智能体分别处理。两组使用相同的模型和业务要求，参考结果没有提供给办理业务的智能体。
按照预先确定的规则逐笔核对后，两种配置在四组新账表中均为 4 组通过。这组对照没有观察到改进配置带来的额外准确率提升。各业务会话可以自行编写对账程序，因此这里比较的是不同工作配置下的最终交付。
通过插件转换、导入和新会话读取的记录，我们能够具体观察一项工作要求怎样进入后续任务。通过回归和新账表对照，又能够继续检查这些任务实际交付了什么结果。
对于开发者来说，经验复用需要同时关注这些环节。配置保存下来之后，需要在后续会话中被读取；规则进入执行之后，还需要结合实际结果判断它是否发挥了预期作用。
围绕明确的技能内容和检查要求，开发者能够持续审阅智能体的工作方式。后续出现新的问题时，也可以回到这些规则，判断需要补充什么、哪些要求仍然适用，以及业务口径是否已经发生变化。
可复用的工作规则，能带来什么价值？
智能体进入实际工作之后，交付结果通常还会被其他人继续使用。一份核对清单可能交给业务人员查证，一份需求文档可能交给研发人员实施，一份资料整理结果也可能成为后续判断的依据。
因此，讨论智能体的工作方式，需要同时考虑任务怎样完成，以及结果怎样被理解、核查和继续使用。
让交付结果保留足够的核查依据
这次对账中，最直观的变化是异常来源更加完整。
订单的确认收款金额没有变化，但待核查清单补充了原先遗漏的有效流水。接手的人可以据此了解相关收款与冲突记录之间的关系，再回到原表继续查证。
这个变化说明，开发者可以把来源信息纳入交付要求，让智能体在整理结论的同时，保留支持后续核查的依据。
对于需要交接的工作，这一点具有实际意义。业务人员看到一项异常时，需要知道哪些记录支持当前判断，哪些信息还不完整。来源清楚的交付，能够为接下来的核查提供更完整的材料。
在需求整理中，也可以用类似的角度检查某项要求来自哪份评审记录；在资料审查中，可以关注一条判断对应哪些原始内容。这些工作有各自的业务规则，但都可以进一步讨论结论与来源之间的关系。
让已有经验形成可以审阅的处理要求
开发者持续使用智能体时，会逐渐发现一些需要反复强调的要求。
有些要求涉及处理顺序，有些要求涉及关联信息，还有一些要求规定了交付前应当检查什么。将这些内容表达清楚，有助于开发者判断智能体打算怎样完成任务。
RSI 提供了从任务反馈中生成修改候选的途径。开发者能够查看候选提出了哪些规则，再结合业务口径与执行结果进行审阅。
这次的异常来源整理技能，就是一个具体例子。我们可以围绕它提出的问题，检查相关流水是否覆盖完整、确认收款的来源是否保留，以及新的要求是否影响了其他处理结果。
对于持续开展同类工作的团队，这也提供了一种积累经验的思路。已经明确的要求可以整理成可复用配置，后续任务继续围绕这些要求执行和检查。业务口径发生变化时，已有规则也需要重新审阅。
工作经验有了具体内容，开发者才能清楚地讨论应该保留什么、修改什么，以及怎样判断修改是否有效。
在官方展示的 Swarm Skill 机制中，这种经验积累的思路也延伸到了团队协作。协作方法可以整理成技能，执行过程中形成的经验则进入后续的保存与维护环节。对于开发者而言，这提供了一个进一步观察的方向，即怎样让已经明确的工作要求持续参与后续任务，并随着实际使用继续调整。
让待核查事项有清楚的交接方式
实际业务中，有些记录即使被准确识别，仍然需要补充信息才能作出判断。
在后续一批账表中，最终清单保留了未收款、少收、多收、流水冲突和无关联收款等 7 项异常。智能体可以整理相关订单、流水和来源行号，但仅凭两张表，无法确定一条冲突流水究竟来自录入错误、重复导出，还是另一笔真实交易。
这时，业务人员需要结合原始凭证，确认收款归属或进一步处理金额差异。
对于开发者而言，这类情况也可以纳入工作配置的设计。已经明确的规则交给智能体执行，信息不足的事项保持待核查状态，同时保留相关记录，方便业务人员接手。
这样的分工能够让任务要求更加清楚。开发者负责说明处理口径和交付标准，智能体据此整理与检查，业务人员再依据更完整的信息完成进一步确认。
随着任务持续开展，团队还可以观察哪些问题能够通过补充规则解决，哪些问题需要新增资料，以及哪些判断需要继续由业务人员完成。这些观察都可以成为后续调整工作方式的依据。
总结
通过这次对账，我们看到了 WorkSwarm 中 RSI 调整工作方式的具体过程。异常清单中的一次来源遗漏，促成了异常来源整理技能和交付检查要求的修改；不同候选接受评测筛选，采纳后的配置又经过转换和导入，在新的会话中被读取。
这个过程让开发者能够查看智能体提出了什么处理方法，也能够继续检查这些方法在实际任务中的表现。
对于反复处理同类工作的开发者，可以从已经遇到的问题入手，把业务口径、来源要求和交付标准表达清楚，再观察系统生成的候选。每项调整都应当对应具体问题，并能够通过结果检查判断是否符合预期。
适合开始尝试的场景，可以是规则明确、结果能够核对的小型任务。保留任务材料和问题记录，审阅候选的具体内容，再让它处理后续输入，能够帮助开发者逐步理解每一次修改的作用。这类Agent 开发实践，也正是 云栈社区 上许多开发者在持续探索的方向。
当一次纠错能够留下清楚的处理规则，并在后续任务中继续接受验证，智能体的工作经验才有了持续积累的可能。
发表于 4 小时前
|
查看: 4|
回复: 0
/1 
