Zuno 已经有一个来自研究工作的事件抽取模型。输入一段材料，它返回结构化事件。后来团队希望试一个新的法律 LLM；新模型也能返回事件列表，字段甚至可以做成完全相同的 JSON Schema。
最简单的替换方式是在工作流里把旧 Python class 换掉，或者给两个实现各写一个 wrapper。只有一个稳定内部模型、任务范围很窄时，这样做完全合理。没有必要为了抽象而先建立 registry、版本体系和独立服务。
替换开始频繁以后，接口相同就不够了。旧模型把什么算作一个事件，新 LLM 是否使用同样的边界；空数组表示材料里确实没有事件，还是模型没有完成判断；两者分别支持哪些材料、案由和长度；错误会怎样暴露；旧结果和新结果能不能放在同一条业务链里比较——这些都不是 JSON Schema 能回答的问题。
如果每个差异都写进 Runtime，工作流会逐渐充满实现特例。换一次模型，Planner、fallback、错误处理、Eval 解释和下游判断都要重新理解供应方。研究资产越多，上层越依赖具体实现，最终很难说清“系统需要的专业能力”究竟是什么。
05 因此先固定专业承诺，再允许实现变化。以事件抽取为例，上层真正需要稳定的是：输入在业务上表示什么，输出代表什么事实候选，支持范围在哪里，哪些情况应该明确拒绝或要求复核，下游可以怎样解释结果。工程上把这份稳定承诺称为 Capability；研究模型、规则系统、LLM 或外部服务只是提供这份承诺的 Provider。
这个边界首先解决替换问题。某个论文模型停维、部署地址变化，或者新的 LLM 更合适时，只要新的实现仍然遵守同一专业含义，上层不需要跟着改写。如果“事件”的定义、支持范围或失败语义本身已经变化，系统就承认专业契约发生了变化，而不是把语义漂移藏在同一个接口后面。
假设新的 LLM 已经接入成功。所有字段都符合约定，错误码也能正常解析，健康检查持续为绿色。把它直接开放给全部案件仍然过早：它可能在普通合同文本上表现很好，却在超长材料、扫描件转写文本或某一类争议焦点上稳定漏事件。
这里有两个不同的问题。第一个问题是“这个实现有没有遵守约定”，可以通过接口、字段、错误语义和必要来源检查；第二个问题是“它对当前这类任务是否足够好”，需要冻结数据、版本和配置以后，用真实任务和已知失败类型去测。
工程参考把前一个检查称为 Conformance，把基于质量证据形成的适用资格称为 Qualification。当具体任务到来时，系统再结合任务类别、材料条件、风险要求和当前资格，得到现在可选的实现集合，也就是 Eligibility。这些名字描述的是一条很普通的工程判断链：接得上，经过验证，在这个任务上现在仍然适用。
健康检查不能替代这条链。Provider 今天能请求成功，只说明 transport 还活着；模型、Prompt、ProcessingSpec 或数据分布发生明显变化以后，旧质量证据也可能失效。资格需要能够重新验证和撤销，而不是某次通过后永久保持绿色。
专业能力还要允许明确说“不会做”。一个事件抽取实现只支持中文合同正文，就应在其他输入上返回 unsupported；材料不足时可以要求补充或人工复核。为了让 Dashboard 上的 success rate 更好看，强迫每次调用都产生结构完整的答案，会把能力边界转化成稳定的幻觉来源。
同一个 Provider 出现 503、GPU 暂时不可用或连接超时，通常属于执行故障。输入、专业含义和任务前提没有变化时，Runtime 可以在预算允许范围内重试，也可以切换到另一个当前仍有资格提供同一能力的实现。
另一种故障看起来更安静。某次模型升级以后，API 仍返回 200，字段一个不少，但“事件结束时间”的含义已经变了，或者以前明确 unsupported 的材料现在被模型强行给出答案。继续 Retry 不会修复这种问题，只会更稳定地产生无法与历史比较的结果。语义变化需要阻断旧资格、重新评测，必要时形成新的能力版本。
Fallback 也因此不是“谁还能返回 JSON 就用谁”。Provider A 故障以后，B 只有在当前任务的专业质量、材料条件和数据政策下仍然合格，才是合法替代。没有满足最低条件的实现时，系统可以改变计划、进入人工复核或明确 abstain，而不是为了维持可用率偷偷降低专业语义。
版本记录服务于同一个目的。CapabilityVersion 表示专业承诺本身发生变化；ProviderVersion 记录某个实现的模型权重、规则、部署或重要推理配置变化。质量回退时，团队才能区分“我们重新定义了这项能力”和“提供同一能力的某个实现退化了”。
每次实际调用还应留下自己用了哪份专业承诺、哪个实现、哪些材料版本和关键配置。这样一个 Runtime Step 多次尝试不同 Provider 时，不会把几次调用混成一个事实；Cache 也只能在真正影响专业结果的条件仍然相同时复用。缓存命中说明计算结果可以复用，不会自动把它升级成 Domain 的正式事实，也不会跳过当前 Security 判断。
课题组已经积累的事件抽取、事件对齐、冲突识别、法条推荐、事实—法条对应和法律模型评测，最容易被做成一组彼此孤立的 Demo：每篇论文包一个 Tool，再让一个“总 Agent”决定调用哪个。这样能快速展示，却会把长期价值绑在论文实现和 Prompt 上。
更稳定的做法是先问专业人员长期需要什么结构。事件抽取和事件对齐可以共同支撑案件时间线；双方陈述的冲突识别可以支撑争议焦点研究；事实—法条对应与法条推荐可以共同形成候选法律依据及其事实解释。论文模型、LLM 和规则只是这些专业任务的不同 Provider，具体组合可以随证据变化。
这也意味着一个 Research Artifact 未必等于一个 Capability。有些论文实现同时包含多个可独立评价的专业步骤；有些能力则需要组合多项研究成果和通用模型。切分边界应由稳定输入输出、专业语义和独立资格决定，而不是由论文目录决定。
LawBench、LJPCheck、CMDL 一类研究资产的角色又不同。它们更适合作为 Qualification 和 Regression 的上游依据：LawBench 帮助拆分法律能力维度，LJPCheck 提醒团队不能只看 headline accuracy，CMDL 这类复杂多主体数据可以暴露简单 Task Class 看不到的退化。它们不因为是研究成果就自动成为 Provider，也不能直接替真实法院任务给出生产资格。
因此 Research Artifact 进入 Zuno 的完整路径更接近：先提炼专业语义，再选择或实现 Provider，然后由 09 在明确 Task Class、DatasetVersion、配置和失败分类下产生资格证据。进入真实案件后，Provider 产生的仍然是 Candidate；专业人员最终修改、接受或拒绝什么，由 02 保存。真实使用中的稳定失败再回到 09，成为下一轮 qualification、研究问题或 Provider retirement 的输入。
这条闭环保护了研究价值。模型更新不需要推翻上层产品结构，真实案件也不会只是一次性消费论文能力；任务定义、失败样本、专家修改和资格证据会逐步积累，使下一项研究成果更快知道“应该替换哪里、需要证明什么、什么情况下不能上线”。
课题组的论文模型、实验脚本和规则资产首先是 Research Artifact。它们证明团队拥有方法、代码或实验结果，但并不会自动成为长期业务可以依赖的系统能力。
把研究成果接入 Zuno 时，先明确它到底解决什么专业任务、接受什么输入、输出如何解释、适用范围和已知失败是什么，再把它作为一个 Provider 放到稳定的 Capability 下面。接口行为能够复现以后，还要用当前任务需要的 Eval 证据判断它在哪些 task class 中有资格使用。它最终产生的仍然是机器候选；专业人员是否把结果接纳成正式法律事实，由 02 的业务边界决定。
这条路径同样适用于 Buy。成熟 OCR、通用 embedding、基础模型和第三方 API 没有必要因为 Zuno 是自研项目就重新实现。外部服务与自研研究模型可以在同一专业承诺下比较质量、成本、部署和治理条件；真正值得长期 Build 的部分，应来自法律专业语义、评测数据或已有研究资产带来的实际优势，而不是来自“必须拥有全部技术栈”的愿望。
05 也不会因为拥有“能力”这个名字就吞掉相邻责任。一个专业能力内部可以调用 LLM，真实模型请求、Provider routing 和 Usage 仍由 Model Gateway 记录；它可以提出某个现实动作建议，真正发送并确认外部世界发生了什么仍由 Effects 处理。专业计算成功、模型 transport 成功和现实动作成功面对的是不同故障，合并成万能 Tool Registry 会重新把这些语义压回一个 God Layer。
如果系统只有几个稳定内部函数，没有多个可替换实现，没有独立质量门槛，也没有跨工作流复用要求，Capability 完全可以薄到一个清楚的 Python Protocol、版本常量和测试集合。没有证据支持时，不需要 registry、marketplace，也不需要独立网络服务。
研究资产增多、Provider 经常替换、同一专业任务存在多种实现，或者质量资格需要与 Runtime 解耦以后，更完整的生命周期才开始有价值。最直接的检验是 Provider exit：旧研究模型停止维护、外部服务退出或质量下降时，团队是否只需要撤销或替换这个实现，就能让上层继续依赖同一专业承诺。如果仍然必须同时重写 Runtime 和 Domain，说明这层边界还没有真正建立。
复杂度也必须接受 Eval。专用研究模型、通用 LLM 和外部服务应该在可比任务、数据和预算下比较；某个 registry、qualification 流程或 Provider abstraction 长期没有带来替换、质量控制或复用收益，就应该继续缩薄，而不是因为已经实现就永久保留。
Target： 05 拥有 Capability 语义与版本、Provider binding、Conformance、Qualification / Eligibility 以及调用来源；研究成果先转换成稳定专业承诺，再由不同 Provider 实现。它产生专业 Candidate / Proposal，不拥有 Formal Admission、模型 transport 或现实 Effect truth。
Current： 历史代码已经存在 Skill / Tool、模型、研究算法和部分评测路径，但 Target 中统一 Capability lifecycle、Provider qualification、按 Task Class 的能力画像和研究—产品反馈闭环不能从这些实现自动推断为已完成。
Gap： 需要进一步冻结 Capability / Provider 的字段级 Contract，建立按 task class 的资格证据、semantic drift 检测、Provider exit 测试，以及真实法律任务上 Build / Buy / LLM / 专用模型的可比评测。LawBench / LJPCheck / CMDL 等研究资产如何进入长期 Regression 与 qualification 也仍需要数据和实验设计。
工程 / Agent 精确参考与跨模块一致性规则见 reference.md。