Vibe Coding 之后：把工程经验编译成组织能力

从凭感觉航行，到共同建造一支会学习的 Agent 船队

摘要

Vibe Coding 让我们在没有完整路线图时也能开始工作。但代码生成得更快，不代表问题解决得更好；一次任务完成，也不代表团队获得了可以复用的能力。

当代码生成的边际成本下降，团队需要积累的资产就不应只有代码，还应包括领域知识、搜索策略、验证方法，以及将执行经验转化为后续能力的学习机制。协作方式也需要随之改变：不是每个人指挥一支私有 Agent 军团，而是共同建设一支共享船队，让人在需要判断和授权的节点介入。

衡量这套系统的关键，不是今天生成了多少代码，而是今天付出的探索成本，能否减少明天的重复劳动。

一｜航向与本质：从能出发，到能抵达

1.1 凭感觉航行，需要怎样的导航系统

使用 Agent 开发，常有一种驾驶小船出海的感觉。我们知道大致方向，也能描述目的地，但不知道中间该经过哪些海域。于是，让 Agent 查代码、搜索资料、修改实现、运行测试，再根据反馈调整航向。

这让出发变得容易，也让偏航不易察觉。

Agent 读了很多文件，却没有找到关键依赖；修复了一处报错，却破坏了任务描述之外的业务约束；所有局部测试都通过了，结果仍不符合需求。屏幕上的工具调用没有停，但任务可能已经在原地打转。

模型提供动力，但动力不等于方向，更不等于抵达。

海上航行需要海图、仪表和航行日志。Agent 工程也需要这样的外部系统：提供任务上下文，记录执行动作，反馈环境变化，限制风险，并检查结果。本文将这套执行与控制环境称为 Harness。Tracing、测试、权限和质量门禁都可以是其中的一部分，而不只是执行结束后的一份日志。

Harness 要让我们看见：Agent 依据哪些事实作出动作，在哪一步失败，是否重复探索，耗费了多少资源，以及结果满足了哪些验收条件。Skill 提供遇到特定情况时的行动方法；Evaluator 则依据验收标准评估结果。它们是不同职责，不必是彼此独立的产品。

Vibe Coding 之后，并不是不再凭直觉提出方向，而是不再只凭直觉判断进展。

1.2 代码是负债，知识才是资产

“代码是负债”是一种维护视角，不是对代码价值的否定。

代码让业务规则成为可执行行为，也带来理解、评审、测试、部署、兼容和迁移成本。AI 降低了生成代码所需的投入，却不会因为生成变快，就消除这些持有成本。缺少验证和治理时，生成速度也可能成为负债增长的速度。

因此，代码可以看作必要的可执行库存。团队既要维护库存，也要维护生成和演化它的依据：解决什么问题，有哪些业务不变量，为什么选择当前方案，哪些路径已经失败，以及如何证明修改没有破坏原有行为。

从这个角度看，代码是领域知识在特定环境下的一次编译结果。能够支持后续修改、重建和验证的知识系统，才是值得共同积累的资产。

这不意味着知识文件天然比代码更有价值。过期的架构说明、没有适用边界的经验、缺少测试的 Skill，同样需要维护，也可能误导后续工作。可追溯的证据、可执行的方法、可重复的评测和明确的责任人，这些条件不足时，复用就需要承担额外风险。

协作的重心不应只是维护代码，而应包括维护产生代码、验证代码和纠正错误的能力。

1.3 把 Agent 执行看成有成本的搜索

复杂工程任务没有预先给定的路线。Agent 需要在需求、代码、文档、工具和实验结果之间寻找线索，提出假设，再用动作检验假设。这可以用启发式搜索来理解。

A* 的评价函数 f(n) = g(n) + h(n) 提供了一个类比：g(n) 表示已经付出的探索成本，h(n) 表示对剩余成本的估计。这里不是说 LLM 或 Agent 实现了 A*，也不是说 Prompt 和 Skill 就是搜索算法；它们影响的是搜索方向、路径优先级和动作选择。

Prompt 描述目标与约束，Context 提供当前状态，Tools 决定可执行的动作。Skill 将历史经验变成优先检查项、操作步骤和应避免的路径；Router 负责选择相关能力；Harness 提供执行反馈；Evaluator 判断候选结果是否满足目标。Wiki 保存知识，Human Tool 则补充系统无法独立获得的判断与授权。

这些组件共同决定搜索效率。好的 Skill 可能减少弯路，但无法弥补错误目标、缺失上下文或无效验收标准。

Uber 的工程文章给出了一个具体对照：同一模型处理同一个查询问题，使用包含 2400 万节点、8000 万条边的 Context Graph 时，38 秒得到正确答案；没有图谱时，搜索约 20 分钟、创建两个子 Agent、遇到三次错误，仍得出错误结论。这是一个案例，不是所有任务的平均收益，但它说明：成本可能消耗在寻找正确上下文，而不是生成代码上。[1]

我们要优化的，不只是模型每次调用的价格，还包括它为了完成任务走了多少无效路径。

二｜演化与机制：记录经验之后，还缺什么

2.1 HPO 实践：从检索知识，到触发行动

在 HPO Agent 的实践中，我们建设了一个工程经验沉淀 Skill：查 Bug、调研或写代码时，只要一个非平凡任务经历了多轮探索、失败和修正，这段过程就进入待沉淀范围。目标是保留那些下一次可以不必重走的路径。

第一版使用 index 文件组织经验检索。知识保存下来了，但命中不稳定。

这条链路需要跨过几道门槛：Agent 要识别当前场景值得检索，找到相关记录，判断适用条件，再据此改变动作。即使文件存在，也不等于这些步骤会发生。读到一条经验，与按这条经验执行，是两件事。

人类的熟练动作可以提供一个类比：我们不会在每次遇到熟悉情况时都从头翻笔记，而会调用已经掌握的操作方法。对 Agent 而言，将经验写成带有触发条件、执行步骤和验证要求的 Skill，是把知识转化为程序性能力的一种方式。

这里的“本能”不是修改模型权重，也不是保证 Skill 一定触发，而是让可复用方法进入任务的执行路径。

几个职责需要分开：Wiki 保存知道什么，Skill 描述怎样做，Router 与 Trigger 决定何时使用，Evaluator 检查使用后是否有效。 HPO 的 index 体验暴露了这条链路中的缺口，但还不是关于所有知识库或 Skill 方案的对照实验。

学习也不必只有 Skill 这一个出口。有些经验适合成为操作方法，有些应当修正领域事实，还有些应当变成测试或权限约束。是否产生学习，要看下一次行动发生了什么变化，而不只是新增了哪个文件。

2.2 WikiSkill：将知识积累与 Skill 修改连接起来

WikiSkill 为这种学习过程提供了一个研究实现。它将工作空间划分为 Raw、Wiki 和 Skill 三层：Raw 保存原始轨迹，Wiki 积累模式和历史，Skill 承载执行方法。Inference Agent 产生轨迹，Wiki Maintainer 整理经验，Skill Proposer 提出修改，再由验证集决定接受或回滚。[2]

其消融实验中，在执行 Agent 不访问 Wiki 的条件下，引入持久 Wiki、Wiki Maintainer，并让 Skill Proposer 使用 Wiki，平均成绩从 48.7% 提升到 63.7%。在此基础上，允许训练阶段的执行 Agent 也访问 Wiki，成绩降到 60.9%。作者推测，执行 Agent 可能从 Wiki 直接获得解题知识，使轨迹不能充分暴露 Skill 的缺陷。这不是“长上下文必然有害”的结论。[2]

论文还有一个与 HPO 实践相关的边界：实验将活跃 Skill 直接注入 Prompt，没有评测大规模 Skill 库中的检索和触发。[2]

这项工作支持的是将“积累知识”和“改进执行方法”连接起来，而不是把两者混成一个越来越长的 Prompt。它也提醒我们，Skill 的质量与 Skill 的可达性需要分别评估：一个方法可能有效，但任务到来时未必选得到它。

2.3 上下文快照：让经验有据可查

当前 HPO 实践的一个缺口，是没有完整保存经验产生时的上下文快照。

一条“遇到某类错误，先执行某个命令”的经验，可能依赖特定版本、仓库结构和前置条件。只保存结论，后续就无法判断：方法为什么有效，哪些条件发生了变化，人是否在中间补充了关键判断。

Episode Snapshot 应当保存一次执行的证据，而不只是最终答案：

保存对象是可审计的输入、动作和结果，不是把模型不可验证的私有思维过程当作事实。快照为复盘和 Replay 提供依据，也不意味着动态环境可以原样重现。

从证据到能力，可以按下面的链路推进：

Episode：发生了什么
    ↓
Pattern：什么机制可以复用，边界在哪里
    ↓
Candidate：候选 Skill、规则或检查项
    ↓
Eval：与原有方法比较，并检查回归
    ↓
发布：进入适用任务的执行路径；出现问题时回滚

这不是等同类事故多发生几次才行动。跨任务的重复证据有助于提炼通用方法；一次能够复现、原因清楚的事故，也可以推动有针对性的回归测试。关键是证据与适用范围相匹配，不把局部成功写成通用结论。

2.4 像构建 SDK 一样构建 Skill

传统软件工程通过 SDK 封装能力，让使用者不必重做底层实现。复用建立在接口、版本、测试和维护责任之上。Skill 也需要这样的工程纪律，而不是只写一段“效果不错”的 Prompt。

下面是一份适合团队维护的能力契约，不是某个 Skill 格式的强制标准：

这份契约同时服务使用者和维护者：使用者知道何时依赖它，维护者知道怎样判断修改是否有效。

还可以借鉴 SDK 的另一层分工：完整方法作为 Skill Source 保存，进入 Agent 上下文的内容作为 Control Artifact 管理。前者保留背景、证据、示例和历史；后者突出匹配条件、操作策略、禁区和验证要求。二者应能相互追溯，而不是成为两套独立维护的事实。

“编译”在这里指提炼、组织、适配和验证，不要求存在一个确定性的编译器。产物是否合格，要由执行效果决定。

三｜实践与范式：让教训进入控制流程

3.1 DSH：知识如何积累，错误如何被拦住

DeepSeek Harness（DSH）的仓库治理提供了一个观察窗口。它把知识分配给不同载体：AGENTS.md 写任务规则，架构文档描述当前系统，Agent Notes 记录设计取舍，Post-mortem 解释事故机制，.agents/skills/ 保存工作方法，测试与质量门禁检查变更。[4][5][8][9]

这套分工的价值，是让维护者区分当前事实、历史理由、行动指导和执行约束。它们可以关联，但不应互相替代。

知识随变更积累，也有退出机制。 DSH 要求非平凡变更在同一 PR 中新增或更新 Agent Note，记录选择及放弃的方案。活跃状态是 proposed / implemented / rejected；低未来价值的已实施记录进入独立的 archived/ 树，保留 implemented 状态并冻结，不再作为当前行为的依据。[6]

这比“所有文档永久保留在同一个检索范围”多了一层治理：什么仍是现行规则，什么只适合解释历史，需要被区分。

索引不能成为另一个事实源。 DSH 的 Agent Notes 不维护中心化 INDEX.md，使用状态与类别目录以及仓库搜索定位内容。[6] 这与 HPO 的问题相关，但不相同：前者处理索引与正文的同步负担，后者暴露检索到行动之间的断点。不能据此得出“取消 index 就能提高 Agent 命中率”。

对团队而言，索引可以承担导航和检索职责，但应当能从权威内容重建。它不能替代原始记录的边界和证据。

复盘之后，还要检查错误经过的路径。 DSH 的 Post-mortem 0001 记录了一次 ACP 服务在真实编辑器连接时崩溃的事故。当时有 178 个通过的单元测试和 100% 行覆盖率，但手工挂载插件的测试绕过了真实 Loader 和服务解析路径。修复增加了不依赖 API 密钥的真实 Loader 覆盖，以及相关包规则。[7]

这个案例的重点是测试是否经过错误实际发生的入口，而不只是有多少条测试。

写进 Post-mortem，意味着后续可以查到事故；写进 AGENTS.md 或 Skill，意味着后续执行有了行动指导；写进回归测试，并把测试接入不可跳过的 Gate，才是在所覆盖的条件下阻止错误通过。三者的约束强度不同。

一条防线是否有效，需要用它应当拦住的反例来检验。

DSH 的这些材料展示了围绕变更、文档和测试的知识治理，不能据此声称项目已经实现从所有执行轨迹到 Skill 更新的完整自动学习闭环。可借鉴的是：知识沉淀应成为变更的一部分，关键教训还要获得可执行的约束形式。

3.2 EvoMap：经验如何被其他 Agent 使用

当经验不再只服务一个仓库，新的问题就出现了：它由谁产生，在哪个环境验证，其他 Agent 怎样获取，发现问题后能否撤销？

EvoMap 的文档用 Gene、Capsule 和可选的 EvolutionEvent 表达这几类信息。Gene 是包含前置条件、约束和验证方式的策略模板；Capsule 保存应用策略后的已验证实例，包括触发信号、影响范围和环境指纹；EvolutionEvent 记录演化过程。平台还定义了内容寻址，以及发布、获取、反馈、验证和撤销等动作。[10]

这是平台文档描述的机制，不等于所有经验已经具备跨环境复用效果。值得借鉴的是它为经验补充了身份、环境、验证记录和生命周期，使“分享一个 Prompt”变成“交付一个可以追溯的能力对象”。

运行时表示：不是越短越好，而是要能指导动作

《From Procedural Skills to Strategy Genes》研究的是另一个层面：同一份经验以什么形式进入模型上下文。它与 EvoMap 的协议思路有关，但不能用论文实验代替平台整体效果的证明。[11]

这份技术报告在 45 个科学代码场景中进行了 4,590 次受控试验。按检查点评测、再对两个模型取平均，无指导、文档型 Skill 和 Gene 的通过率分别是 51.0%、49.9% 和 54.0%。这是该报告的评测口径，不是完整工程任务的交付成功率；平均优势也不代表 Gene 在每个模型上都优于 Skill。[11]

报告中的 Skill 是文档型完整包，Gene 则突出任务匹配信号、策略步骤和 AVOID 提示。实验发现，直接追加失败历史可能削弱原有控制效果；重新组织为结构化警告，比朴素堆叠历史更有效。这些结果限于报告使用的模型与任务，不能推出所有文档都应删减，或所有 Skill 都应改名为 Gene。[11]

对工程建设的启发是将维护表示与执行表示分开：

Skill Source
背景、证据、边界、示例、测试与变更记录
    ↓ 提炼、适配，并验证效果
Control Artifact
匹配信号、操作策略、AVOID、约束与验证要求

压缩的目标不是字数最少，而是保留足以改变动作的有效信息。删掉适用条件或失败边界，即使 Prompt 更短，也可能让经验被误用。

可以分发，不等于可以直接信任

经验流通也会传播错误。环境错配需要兼容范围与本地验证；来源不明的操作需要权限和沙箱限制；多个能力同时加载，需要检查约束冲突；过期内容需要废弃或撤销，而不是继续留在推荐路径上。

这些是团队采用能力分发机制时需要补齐的工程条件。内容哈希可以用来校验内容一致性，不能证明策略正确、安全或适合当前任务。平台上的排名和使用记录可以帮助发现候选能力，也不能替代本地 Eval。

DSH 与 EvoMap 分别照亮了两段链路：前者让仓库内的知识进入变更和验证流程，后者为经验跨 Agent 流通定义对象与接口。两者都需要回到同一个问题：后续任务是否因此少走了弯路，是否仍在适用边界内。

四｜组织与协同：共同建设一支 Agent 船队

4.1 共享能力，而不是复制个人工作台

每个人驱动多个 Agent，可以提高个人产出。但如果 Prompt、Skill、知识和任务经验都留在私人环境里，团队仍会重复建设：同类问题被不同 Agent 从头探索，方法在个人环境中有效，却无法交接给别人。

我们需要改变的，不是一个人可以使用多少 Agent，而是能力属于谁、由谁维护、怎样被复用。

不是每个人拥有一支 Agent 军团，而是大家共同创造一支属于团队的 Agent 军团。

这不等于把所有任务交给一个中央 Agent，也不意味着所有上下文和权限都全局开放。系统可以保留多个领域 Agent、工程 Agent 和验证 Agent，按任务组合；共享的是有版本的知识与 Skill、工具接口、评测集、执行记录和发布规则。任务数据和操作权限仍需按作用域隔离。

共享还会扩大错误的影响。一条私人 Skill 的问题可能只影响一次任务，一条共享 Skill 的问题可能进入多个工作流。因此，版本固定、独立 Eval、灰度发布、责任人、审计与回滚，不是规模扩大后才补的附件，而是共享本身的条件。

4.2 按领域维护能力，跨任务组织执行

模块 Owner 解决了代码和系统的责任划分，但一个业务任务未必落在一个模块内。Agent 可以跨仓库调用工具和修改实现，却不会因此免除跨系统约束。

知识和方法可以围绕领域组织。例如，实验平台能力不只包含某个服务的代码，还包含实验定义、数据流、不变量、历史失败模式、领域 Skill、验证案例，以及需要人授权的边界。不同任务使用同一份领域能力，也把新证据反馈回来。

工程师的长期职责就不只是完成分配到的需求，而包括维护一个或多个领域的能力包：知识是否仍然正确，Skill 是否适用，Evaluator 是否覆盖关键风险，异常应该交给哪个角色处理。

这里增加的是领域能力责任，不是取消模块责任。发布、故障、权限和代码质量仍需要明确 Owner。领域能力负责跨任务复用，模块 Owner 负责系统运行，两者需要协作，而不是互相替代。

4.3 人是 Human Tool，也仍是系统的建设者

如果每一步都需要人盯着，Agent 只是把“亲自执行”换成“实时监工”。理想的运行方式是：Agent 在授权边界内推进任务，遇到需要业务判断、信息补充或风险授权的节点时，再调用人。

从执行视角看，这就是 Human Tool。它不是一个模糊的“找人帮忙”按钮，而是一个需要设计的协作接口。

调用要说明需要哪类能力，由哪个角色回答；触发原因是什么；已经掌握哪些事实、尝试过哪些方案；希望人解决的最小问题是什么。授权还需要范围和有效条件；无法及时获得回答时，系统要有暂停或降级路径。输入、裁决和后续结果都要留下记录。

例如，Agent 不应只提交“任务卡住了”，而可以提交：

已验证三种路径：A 违反现有架构约束，B 会增加线上风险，C 技术上可行，但需要把数据延迟从 5 分钟放宽到 20 分钟。请确认本次任务是否接受这一变化；未经确认，不执行相关变更。

人回答的是一个有上下文、有权限边界的问题。Agent 获得结果后继续执行，而不是把整项任务交回给人。

人的裁决也不是天然正确的通用规则。同样的取舍，在不同业务阶段可能得到不同答案。Human Tool 调用首先进入 Episode；重复出现且边界稳定的判断，再经过评审和验证，成为规则、Evaluator 或 Skill 候选。需要每次授权的操作，不能因为过去曾被批准，就省略下一次审批。

从 Agent 执行视角看，人是一种可调用的 Tool；从组织治理视角看，人仍是目标、责任与授权的主体。

而在系统建设阶段，人也不是被动等待调用。领域知识、Skill、评测和治理机制需要团队共同维护。Human Tool 描述的是运行时的介入方式，不是人的全部工作。

4.4 tobe：把协作状态从聊天中分离出来

tobe 是对这类协作空间的一个早期探索。按仓库说明，它仍是可信本地环境下的单人 AI Wiki：一个 Human Owner 与多个 AI Agent 协作，正式变更需要人确认。高级能力包括带有上下文边界和工具确认的 Room，以及彼此独立的持久化 Execution Job、Room Session 和 Git Knowledge 生命周期。[3]

它还不是多人组织系统，不能作为组织级协作效果的证据。这个原型的价值，在于将几个问题分别建模：聊天是否结束，不应决定任务是否继续；Agent 提出建议，不等于知识已经成为正式事实；知识经过 review 和 merge，还需要明确何时成为运行时可用的快照。[3]

任务、知识、权限和执行记录拥有各自的生命周期，才有条件被不同人和 Agent 接续，而不依赖某一次对话一直存在。

五｜落地路线：从一次任务建立学习循环

建设共享船队，不必从采购或编排更多 Agent 开始。可以先选择一个高频、边界清楚、结果能够验证的领域，建立从执行证据到能力发布的闭环。

学习循环涉及的九项工作可以分成三组。它们不是所有经验都必须逐项经过的流水线，而是系统需要具备的职责。

5.1 留下证据：保存 Episode、安排知识归属、提炼 Pattern

保存 Episode，让任务目标、上下文、工具动作、结果、成本和人的介入可追溯。

安排知识归属，让事实回到架构文档，取舍进入 Agent Note，事故机制进入 Post-mortem，方法进入 Skill，可执行约束进入测试或 Gate。索引负责导航，不复制另一份权威内容。

提炼 Pattern，记录可复用机制、适用条件、反例和证据。保留哪些经验，应看它能否指导未来任务，而不是文档数量是否增加。

5.2 改变动作：建设 Skill、生成 Control Artifact、增加护栏

建设 Skill，优先处理反复消耗搜索成本、又能够验证效果的方法，补齐触发条件、操作步骤、禁区、验收和升级规则。

生成 Control Artifact，把完整方法组织为任务执行所需的控制信息，保留与来源、版本和模型适配关系的追溯。它可以就是一份简洁的 Skill，也可以是从完整包中生成的运行时表示，不必为了分层而增加一套重复维护的文件。

增加护栏，让事故复盘推动可执行变化。适合固定检查的错误，进入回归测试和 Gate；需要情境判断的方法，进入 Skill 并接受评测。写入提示不等于已经获得强制约束。

5.3 验证与共享：建立 Eval、纳入 Human Tool、管理能力生命周期

建立 Replay 与 Eval，比较候选方法、现行方法及必要的无 Skill 基线。既检查任务成功率和成本，也检查误触发、不适用场景和已有任务的回归。验证使用的环境与线上不一致时，要保留这段差距，而不是把离线通过当作交付完成。

纳入 Human Tool，记录调用原因、事实输入、裁决和结果，再决定哪些信息值得形成候选规则。减少人工介入不是单独的目标：该升级的问题被漏掉，比多问一次更危险。

管理能力生命周期，为知识、Skill、Control Artifact 和 Evaluator 指定 Owner、版本、兼容范围与发布条件。团队可以使用 Candidate → Validated → Promoted 表示候选、已验证和已推广；不再推荐的版本标为 Deprecated，存在风险的版本标为 Revoked，从装载路径中移除。这是团队可以采用的治理设计，不是各个案例共有的协议。

这套系统是否产生复利，要回到实际任务观察：同类问题的搜索步骤和单位有效结果成本有没有下降，历史错误是否重现，Skill 是否在正确场景触发，Human Tool 是否在需要时被调用，模型升级后已有能力是否仍然有效。Agent 数量、Skill 数量和生成代码量，都不能单独回答这些问题。

结语：让一次探索成为整支船队的经验

Uber 报告超过 70% 的 PR 被归因于本地或云端 Agent，已有超过 3600 个 Skill、每日超过 3 万次 Skill 执行；受管理 Agent 配有基于真实工作的评测。这反映了其内部生产流程的规模，不等于这些 PR 都由 Agent 自主完成。[1]

组织建设的重点，也不应停留在把个人聊天窗口放大。我们需要一套共同维护的系统：能够发现偏航，保存执行证据，将经验转化为方法或防线，验证后交给其他任务使用，并在需要时调用人。

代码会修改，模型会升级，曾经有效的 Skill 也会过时。可以积累的，是团队理解问题、验证方法、纠正错误和更新能力的机制。

个人使用 Agent，得到一次任务的效率；团队共同建设 Agent，才有机会让一次探索惠及后续任务。

让整支船队只为同一片暗礁付一次代价。 这不是不会再犯错的承诺，而是对每次复盘的要求：付过的成本，应当留下下一次可以使用的知识、方法或防线。

参考资料

文中的 HPO 内容来自实践记录，不作为受控实验结论。外部案例分别承担工程案例、研究实验、仓库规范或原型说明的作用；据此提出的团队建设方法是工程归纳，不代表这些项目已经实现同一套完整系统。网页与仓库引用核对于 2026 年 9 月 4 日，论文使用下列版本。

1. Uber Engineering. Running a Software Factory Efficiently at Uber Scale. 2026-08-27.
2. WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution. arXiv:2608.27454v1. 重点参见 §3、§5.1 与 Limitations。
3. wangwu-30/tobe：README. 重点参见 Advanced Runtime 与 Trust and Release Boundaries。
4. deepseek-ai/deepseek-harness.
5. DeepSeek Harness. AGENTS.md 与 Architecture.
6. DeepSeek Harness. Agent Notes Specification.
7. DeepSeek Harness. Post-mortem 0001: ACP server crashed on connect.
8. DeepSeek Harness. Documentation Rules.
9. DeepSeek Harness. Agent Skills Directory 与 Testing Guide.
10. EvoMap. 生态介绍：Gene、Capsule、EvolutionEvent 与能力注册机制.
11. From Procedural Skills to Strategy Genes: Towards Experience-Driven Test-Time Evolution. arXiv:2604.15097v2. Beta technical report，重点参见 §4 与 Appendix B。