lsdefine--genericagent/memory/morphling_sop.md

morphling_sop

定义

Morphling 是一种项目级能力吸收/替代模式：给定任意目标项目，先抽取其目标与测例，再按组件选择调用、重写或少量复刻禁区规避，最终让自身或新产物在同一测例上达到或超过目标。

核心三元组

1. 目标（Target）：它解决什么问题、面向谁、核心价值是什么；目标可以是完整项目，也可以是巨型项目中的可交付子系统。
2. 测例（Tests）：它声称能通过的 benchmark、demo、CI、榜单、评测站、用户任务清单、性能/质量指标；没有测例先构造最小客观测例。
3. 行为（Actions）：对每个组件分别决定：调用、重写、舍弃；避免“复刻/抄袭”作为默认行为。

输出形态

• 调用型 morphling：把目标能力纳入自身工具链，产物是“更强的我”。
• 重写型 morphling：理解核心后从零实现更好版本，产物是可独立替代原项目的新 repo/工具/产品。
• 混合型 morphling：同一项目可分组件处理：底层复杂依赖调用，差异化核心重写，冗余模块舍弃。

流程

1. 锁定目标：记录 URL/repo/产品名；不要先评价值不值得，先看它实际解决的问题。
2. 目标拆解：识别类型：skill/教程、库、CLI、桌面/网页产品、基础设施、巨型生态、纯概念项目。
3. 测例提取：优先找官方 tests、CI、benchmark、论文/README 指标、demo 脚本、评测网站、issue 中的真实失败案例。
4. 测例补全：若目标没有公开测例，构造最小可验证任务集：核心 happy path、边界条件、目标宣称的杀手特性、用户最痛点。
5. 组件分解：列出核心模块、可替换依赖、生态/数据/模型/硬件等不可轻易重写部分。
6. 行为选择：
   • 能稳定调用且非差异化核心 → 调用/封装。
   • 质量差、耦合重、可用更简洁方式实现、或需独立发布 → 重写。
   • 巨型/长期生态部分 → 缩小到子系统或调用成熟依赖。
   • 复刻/照抄只作为理解阶段，不作为交付策略。
7. 实现闭环：先做能跑通测例的最小版本，再补强超过目标的维度。
8. 对照验证：在同一测例上跑目标与 morphling 产物，记录通过率、速度、稳定性、成本、易用性。
9. 固化成果：调用型写入工具链/SOP；重写型形成 repo、README、测试与交付说明。

边界判断

• Office 这类巨型生态不做整体替代，拆成具体子系统或能力点。
• Stable-diffusion-webui 这类“大但核心可抽离”的项目可以重写核心体验，因为历史包袱可能大于真实复杂度。
• UI-TARS-Desktop 这类路线差异项目：调用可吸收其纯视觉能力；重写则意味着做一个独立多模态桌面 Agent，并跑同类 GUI benchmark。

执行方式

• Morphling 任务应通过 Goal Hive 执行（参见 goal_hive_sop），利用 Master 调度 + Worker 并行实现 + 持续验收的长程模式完成。

完成标准

• 必须有测例或明确构造的测例。
• 必须说明每个核心组件采用调用/重写/舍弃的理由。
• 必须能在同一考卷上与目标对比。
• “更好”不能只靠主观判断，至少落在一个可测维度：通过率、性能、成本、稳定性、易用性、可维护性、覆盖范围。