AI 解决过一次问题，换一个任务仍然从头摸索，往往因为留下的只有聊天结果：当时用了什么输入、哪一步有效、哪些条件下会失败，都没有成为下次能调用的方法。

　　腾讯 11 月 2 日介绍的 Hyra 2.0，将“研发工具”作为目标。对日常开发更容易借鉴的，是它怎样分别保存项目状态、Agent 工作记忆和共享经验，再把可迁移的方法整理成 Skill。

先看结果：列名一样，为什么读取失败？

　　一份带 UTF-8 BOM 的 CSV，首字段肉眼是 fruit，程序读到的却多了一个不可见字符。下面的独立 Python 例子只改读取编码，首字段就从 \ufefffruit 恢复为 fruit。

　　图：本文 CSV 教学例子的实际执行结果。带 BOM 的字段名使按 fruit 取值失败；改用 utf-8-sig 后字段恢复，count 为2。结果图由真实输出排版，不是 Hyra 产品界面。

三种记录，各自回答一个问题

　　图：腾讯 Hyra Team 原文中的 Harness 架构。底部将 Project state、Agent memory 与 Books 分开，Books 中的方法再经过复盘整理为 Skills。图示为作者方案。

记录	应保存什么	不宜直接塞进去什么
项目状态	哪项任务在执行、等待什么、产物与证据在哪里	每个Agent的全部推理过程
Agent工作记忆	当前假设、已排除路线、下一步计划	未经检查就要求所有任务遵守的结论
共享Books	方法、理由、适用条件与原始证据	只有一句“以后这样做就行”

　　例如，一个 Worker 正在检查 CSV 读取问题，它的当前假设属于工作记忆；“已经生成测试文件，正在等检查结果”属于项目状态；能够复用于下一份文件的读取方法，才有机会进入 Books 和 Skill。

从修复结果到可复用Skill，中间差了什么？

　　开头的独立标准库例子中，同一份CSV用普通UTF-8读取时，首字段多了BOM；改成utf-8-sig后，字段名恢复，数量值读到2。这支持的判断很具体：这份文件的问题来自首字段BOM，不能据此把所有乱码都归到编码。

　　“这次成功了”还不能直接当作通用方法。Hyra原文把Books中的经验分为“观察”“已验证”“约定”：单次现象先作为观察，经独立复现再提高可信程度，影响团队行为的约定需要人类确认。

经验如何推进	CSV例子里应留下什么	为什么不能省略
记录观察	列名看起来正确，程序却多读出不可见字符	保留真实现象，避免只有“已经修好”
找到适用条件	文件确为带BOM的UTF-8，首字段受影响	防止把其他编码、分隔符或引号问题套进来
检查方法能否复用	有BOM和无BOM两类输入都应检查	单个样例通过不能代表所有情况
整理为Skill	写清何时调用、怎样处理、何时停止	下次遇到相似问题时能正确选择方法

　　一份可调用的方法，应说明触发现象、检查位置、处理动作与停止条件。套到这个例子：列名异常时先查首字段是否有BOM，确认后选择对应读取方式；若报的是解码错误或分隔符异常，就转查其他原因。

　　Skill真正复用的是“在什么条件下做什么”，而不只是上一次成功的答案。 Books保留理由和证据，Skill提取可执行的方法；后面出现反例时，还能回到原记录修正。

复核为什么要回到原始问题

　　Hyra 的 Worker 报告完成时，需要附代码版本、实验结果、日志或原始轨迹。需要独立验证时，新的 Review Worker 先接触原始问题和证据，减少执行者结论的影响。

　　套到 CSV 例子，复核者应该自己查看原文件字节、字段名和读取结果，再判断是否符合结论。如果只是看“已修复”三个字，然后回答“同意”，没有增加多少可靠信息。

　　实际整理经验时，可以从一项反复遇到的小任务开始：保存最小输入和结果，说明适用条件，换一个样例再检查，最后将稳定步骤收成可调用的方法。Skill 的价值来自下一次能正确用上，以及遇到反例时能改得动。

　　资料：腾讯 Hyra Team：Hyra 2.0 官方介绍。