1为什么这件事值得认真对待

AI 圈每天都有新消息，但大多数都可以当作噪音忽略。然而 2026 年 5 月 13 日，技术博主 dotey 对 Anthropic 开源的 claude-for-legal 仓库所做的架构解析，是那种值得你放下手头事情、认真读完的内容。

不是因为”法律 AI”这个赛道有多热，而是因为这个仓库背后展示的工程思维，代表了 Anthropic 对于”企业如何真正用好 Claude”这个问题的官方答案。

让我先从一个直觉上的问题说起：为什么大多数企业的 AI 试点项目都失败了？

答案通常不是”模型能力不够”。GPT-4、Claude 3.5 Sonnet 这些模型早就能处理相当复杂的推理任务。真正的瓶颈在于工程化缺失——企业无法把一次性的 AI 演示变成可以稳定运行、可以迭代优化、可以让不同团队分工协作的系统。

而 claude-for-legal 恰好提供了一套解决这个问题的参考架构。它不是一个产品，而是一个方法论。它告诉你：当你要用 Claude 在专业领域落地时，工程结构应该长什么样。

dotey 的解读让这套架构变得更加清晰可见。他用”工作手册”这个比喻来解释 Skill，用”总调度”来解释 Orchestrator，这些比喻很接地气，也很精准。本文将在此基础上进一步展开，把每一层的设计逻辑、工程细节和行业复用价值都说清楚。

2四层架构总览：先建立整体感知

在深入每一层之前，我想先给你一张全局地图。因为只有理解了各层之间的关系，你才能真正理解每一层存在的理由。

这张图从上到下，代表了用户交互到核心知识的完整调用链。用户通过 Plugin（界面层）触发操作，Agent 层负责编排执行逻辑，MCP 层负责连接外部世界，而 Skill 层则是整套系统的知识内核。

一个关键的认知：这四层各司其职，彼此解耦。你可以在不动其他三层的情况下，单独替换任意一层。这就是为什么这套架构能够复用——更换 Skill 层的内容，就能把整套基础设施迁移到全新的专业领域。

3第一层 Skill：把专业知识变成可执行的”工作手册”

Skill 是什么

dotey 用”工作手册”来比喻 Skill，这个比喻非常到位。但我想更精确地定义它：Skill 是一个封装了特定专业任务完整执行流程的结构化知识模块。

在 claude-for-legal 仓库中，每个 Skill 是一个独立目录，目录里的核心文件是 SKILL.md。以 nda-review（保密协议审查）为例，这个 Skill 目录里包含：

• SKILL.md：主文件，定义任务目标、执行步骤、输出格式、质量标准
• 示例文件：few-shot 示例，告诉模型”优秀的输出长什么样”
• 模板文件：输出报告的格式模板
• 配置文件：该 Skill 的元数据（名称、描述、版本、所需权限等）

SKILL.md 的内部结构

一个设计良好的 SKILL.md 通常包含以下几个部分：

# NDA Review Skill

## 任务目标
审查保密协议（NDA），识别不平等条款、潜在风险点，
并生成结构化的法律意见摘要。

## 执行步骤
1. 文档解析：提取协议核心条款
2. 风险识别：对照检查清单逐项评估
3. 严重性分级：High / Medium / Low
4. 建议生成：针对每个风险提供修改建议
5. 摘要报告：生成可提交给客户的报告

## 检查清单
- [ ] 保密范围是否过于宽泛？
- [ ] 保密期限是否合理？
- [ ] 例外情形是否完整？
- [ ] 违约责任是否对等？
- [ ] 管辖法律和争议解决是否明确？

## 输出格式
使用 report-template.md 中定义的格式。
严重风险以红色标记，中等风险以黄色标记。

这种结构的价值在于：它把隐性的专家知识变成了显性的可执行指令。一个经验丰富的法律顾问审查 NDA 时，脑子里有一套完整的检查流程，但这套流程通常存在他的头脑里，无法传授，无法规模化。Skill 机制做的事情，就是把这套流程外化、结构化、可调用化。

Skill 设计的三个关键原则

为什么 Skill 是这套架构最核心的创新

很多人在谈到 AI 应用架构时，会把焦点放在模型选择或推理框架上。但在我看来，Skill 机制才是 claude-for-legal 架构最根本的创新点。

原因是：Skill 解决了 AI 应用中”专业知识如何沉淀”的问题。

传统方式下，专业知识沉淀在 prompt 里。但裸 prompt 有几个致命问题：难以组织（一个超长 prompt 无法模块化管理）、难以协作（多人无法同时维护一个 prompt）、难以复用（每个新场景都要重写）。

Skill 把 prompt 工程提升到了软件工程的层次。每个 Skill 是一个可维护的代码单元，遵循软件开发的最佳实践——关注点分离、接口定义、版本管理、单元测试。

4第二层 MCP Connector：连接 AI 与真实世界的标准化接口

MCP 是什么，为什么它如此重要

MCP（Model Context Protocol）是 Anthropic 在 2024 年末推出的开放协议，旨在为 AI 模型和外部工具/数据源之间建立标准化的通信接口。如果你了解 REST API，MCP 对 AI 工具调用的意义，大致相当于 REST 对 Web 服务的意义。

在 claude-for-legal 架构中，MCP Connector 层扮演的角色是外部世界的统一入口。Agent 不直接读取文件系统、不直接查询数据库、不直接调用第三方 API——所有这些操作都通过 MCP Connector 来完成。

法律场景下的 MCP Connector 类型

MCP 的标准化价值：从集成成本说起

在 MCP 出现之前，企业想把 Claude 接入自己的数据源，需要针对每个数据源写定制化的集成代码。5 个数据源，就需要 5 套不同的代码。这不仅开发成本高，维护成本更高——每次 API 变更都要同步更新所有集成点。

MCP 用一个标准协议解决了这个问题。只要你的数据源有 MCP Connector，Claude 就可以直接接入，无需额外适配。更重要的是，MCP Connector 是可以复用和共享的——社区已经在为各种常见系统开发 MCP Connector，企业可以直接使用现成的轮子。

MCP 对 AI 工具生态的意义，类似于 USB 接口对硬件生态的意义。在 USB 出现之前，每种设备都有自己的接口，接一个新设备可能需要安装专有驱动；USB 统一了接口标准之后，”即插即用”成为可能。MCP 正在为 AI 工具实现类似的”即插即用”。

安全与权限：MCP 不只是”接管员”

MCP Connector 的另一个重要职责是安全边界的守护者。在 claude-for-legal 的设计中，每个 Connector 都实现了：

• 读写权限分离：某些 Connector 只允许读取，不允许写入或删除
• 数据范围限制：Connector 只暴露被明确授权的数据集，Agent 无法越界访问
• 操作审计日志：所有通过 MCP Connector 的操作都被记录，支持合规审计
• 速率限制：防止 Agent 无限制地调用外部 API，控制成本

这些安全机制之所以放在 MCP 层而不是 Agent 层，是因为安全控制应该尽可能靠近数据源，而不是依赖上层逻辑的自律性。这是纵深防御（defense in depth）的工程实践。

5第三层 Agent：理解 Orchestrator 与 Subagent 的分工

单 Agent 系统的局限性

在展开 Agent 层的设计之前，我需要先解释为什么需要多 Agent 系统，而不是”一个 Claude 搞定所有事”。

想象一下这个场景：律所需要对一份 200 页的收购合同做尽职调查，需要同时检查：知识产权条款、劳工协议、环境合规、税务安排、竞业限制、反垄断风险……每个方向都需要深度分析。

如果让一个 Claude 实例顺序处理这些任务，有几个问题：

• 上下文窗口耗尽：200 页文档 + 所有分析过程的上下文会超出模型限制
• 处理效率低下：顺序执行 8 个方向，总时间是所有子任务时间的总和
• 质量不一致：单个实例处理太多任务，后期任务可能因为上下文负担过重而质量下降

claude-for-legal 的 Agent 层通过 Orchestrator + Subagent 的双层结构解决了这些问题。

Orchestrator：总调度的三个核心职责

Orchestrator 是整个 Agent 系统的大脑，它不直接处理文档内容，而是负责：

Subagent：并行执行的专注者

Subagent 是实际处理工作的执行单元。每个 Subagent：

• 接收 Orchestrator 分配的单一子任务和对应的文档片段
• 加载相应的 Skill（如 nda-review 的 SKILL.md）作为工作指南
• 通过 MCP Connector 获取所需的外部数据
• 执行分析，生成结构化输出
• 将结果返回给 Orchestrator

Subagent 的关键设计原则是无状态（stateless）——每个 Subagent 实例在完成任务后即销毁，不保留跨任务的状态。这保证了并发安全性和可预测性。状态管理完全由 Orchestrator 负责。

并行处理的工程价值：以数字说话

并行处理不只是速度的提升，更是质量的提升。一个只专注于”检查知识产权条款”的 Subagent，比一个同时处理八个方向的通用 Agent，在知识产权分析上的深度和准确度要高得多。专注带来精准，分工带来卓越。

Orchestrator 与 Subagent 之间的通信协议

在 claude-for-legal 的参考实现中，Orchestrator 和 Subagent 之间的通信通过结构化的 JSON 消息实现：

// Orchestrator -> Subagent 的任务分配消息
{
  "task_id": "due-diligence-002-ip",
  "skill": "ip-review",
  "document_chunks": ["chunk_14", "chunk_15", "chunk_23"],
  "priority": "high",
  "deadline": "2026-05-14T18:00:00Z",
  "context": {
    "client": "AcquiCo Ltd",
    "target": "StartupXYZ Inc",
    "deal_type": "asset_acquisition"
  }
}

// Subagent -> Orchestrator 的结果消息
{
  "task_id": "due-diligence-002-ip",
  "status": "completed",
  "findings": [
    {
      "severity": "high",
      "category": "patent_ownership",
      "description": "三项核心专利未完成从创始人到公司的转让",
      "recommendation": "在交割前完成专利权属转让文件"
    }
  ],
  "confidence": 0.92,
  "processing_time_ms": 4823
}

这种结构化通信的好处是双重的：对于 Orchestrator，它可以解析和处理来自任意 Subagent 的输出；对于整个系统，这些结构化的中间结果成为可审计的工程产物，方便调试、监控和质量评估。

6第四层 Plugin：把复杂系统变成简单按钮

Plugin 的本质：用户界面的最后一公里

四层架构中，Plugin 是最靠近用户的一层。它的职责不是处理任何复杂逻辑，而是把整套复杂系统封装成用户可以轻松触发的界面元素。

在 Claude Desktop 环境中，Plugin 表现为界面上的功能按钮或命令。用户看到的是”审查 NDA”按钮，点击后 Claude Desktop 就会触发完整的四层工作流——调用 Orchestrator、启动 Subagent 群、通过 MCP 获取文件、加载对应 Skill——但用户完全感知不到这些底层复杂性。

好的产品设计的最高境界是：让用户感觉”这很简单”，而工程师知道”这很复杂”。Plugin 层做的正是这件事。

Plugin 的技术结构

一个 Claude Desktop Plugin 通常包含：

• manifest.json：插件的元数据文件，声明插件名称、版本、所需权限、触发方式
• 入口脚本：处理用户操作、将其转化为对 Orchestrator 的调用请求
• UI 定义：按钮样式、对话框设计、结果展示模板
• 错误处理：当后端任务失败时，向用户显示友好的错误信息而非技术堆栈

Plugin 层的解耦价值

Plugin 层存在的深层价值，在于它完成了用户界面与业务逻辑的彻底解耦。

考虑这个场景：法律事务所决定升级其 AI 系统的后端——更换模型版本、优化 Orchestrator 逻辑、调整 Skill 内容。这些变化对用户来说应该是透明的。用户点击的还是同一个”审查 NDA”按钮，体验不变，但背后的能力已经全面升级。

反过来，如果事务所想调整用户界面——比如把按钮从侧边栏移到顶部菜单、改变结果显示格式——只需要修改 Plugin 层，完全不影响后端的三层逻辑。

这种解耦在企业级系统中极其重要，因为 UI 的迭代周期和后端逻辑的迭代周期往往是不同步的。

7四层模型的行业复用逻辑：为什么法律版只是开始

架构的本质是行业无关的

dotey 在解读 claude-for-legal 时特别强调了一点：整套架构可以复用到任何专业领域。这不是一句营销辞令，而是架构设计的刻意为之。

让我们来做一个思想实验：如果要把这套架构迁移到医疗领域，需要改变哪些部分？

结论是：迁移工作量大约只有原始开发工作量的 20-30%。这就是模块化架构的复利效应。

六个可以立即套用的专业领域

让我们具体看看，四层架构可以如何映射到不同的专业领域：

金融与投资银行

Skill 示例：earnings-report-analysis（财报分析）、credit-risk-assessment（信用风险评估）、regulatory-filing-review（监管文件审查）
MCP 目标：Bloomberg 数据终端、SEC Edgar、内部风控数据库
典型 Orchestrator 任务：对一只股票进行多维度投研分析，同时启动基本面分析、技术面分析、行业对比、监管风险四个 Subagent 并行处理

医疗健康

Skill 示例：clinical-note-summarization（病历摘要）、drug-interaction-check（药物相互作用检查）、radiology-report-extraction（影像报告提取）
MCP 目标：电子病历系统（Epic、Meditech）、FDA 药品数据库、ICD-10 编码库
典型 Orchestrator 任务：患者入院评估，并行分析既往病史、当前用药、过敏史、检验结果

咨询与战略分析

Skill 示例：market-sizing（市场规模估算）、competitive-landscape-analysis（竞争格局分析）、swot-generation（SWOT 分析生成）
MCP 目标：行业数据库（Statista、IBISWorld）、公司备案数据库、新闻 API
典型 Orchestrator 任务：对某个进入新市场的决策进行全面分析，并行完成市场规模、竞争格局、法规环境、财务预测四个维度

人力资源与招聘

Skill 示例：resume-screening（简历筛选）、jd-optimization（职位描述优化）、interview-question-generation（面试题生成）
MCP 目标：ATS 系统（Workday、Greenhouse）、LinkedIn API、内部职位数据库
典型 Orchestrator 任务：处理一批候选人简历，每个简历由独立 Subagent 处理，快速完成大规模初筛

教育与培训

Skill 示例：curriculum-design（课程设计）、quiz-generation（测验题生成）、learning-gap-analysis（学习差距分析）
MCP 目标：LMS 系统（Canvas、Moodle）、学习者数据库、教材内容库
典型 Orchestrator 任务：为一个班级生成个性化学习计划，每个学生由独立 Subagent 分析其学习数据并生成建议

软件开发与代码审查

Skill 示例：code-security-scan（代码安全扫描）、architecture-review（架构审查）、api-documentation-generation（API 文档生成）
MCP 目标：GitHub/GitLab API、CI/CD 系统、依赖漏洞数据库（CVE）
典型 Orchestrator 任务：对大型 PR 进行多维度审查，并行完成代码风格、安全漏洞、性能影响、测试覆盖四个方向的分析

复用的边界：哪些东西不能直接复用

当然，架构复用不是”一键克隆”，有些东西是需要重新投入的：

• 领域知识的积累：Skill.md 里的检查清单、质量标准、示例——这些需要该领域的专家来编写和验证。工程可以复用，专业知识不能偷懒。
• 数据权限的梳理：每个行业的数据合规要求不同（医疗有 HIPAA，金融有 SOX），MCP Connector 的权限配置需要针对行业法规重新设计。
• 测试用例的建立：每个新 Skill 都需要建立行业特定的测试用例，才能保证输出质量。
• 用户工作流的理解：Plugin 层的设计要贴合目标用户的实际工作流程，而不是照搬法律版的界面设计。

总结起来，架构（骨架）可以完全复用，内容（血肉）需要专业构建。这个比例大概是 30% 工程 + 70% 领域知识。对于愿意在领域知识上投入的团队，四层架构提供了绝佳的工程起点。

8对开发者的实操启示：如何真正用起来

从零开始的路径建议

如果你是一个开发者，想基于 claude-for-legal 的架构思想在自己的领域做类似的系统，我建议按以下顺序推进：

第一步：定义你的 Skill 清单（1-2 周）

在写任何代码之前，先和领域专家坐下来，把该领域最高频、最有价值的工作任务列出来。不要贪多，先把最核心的 3-5 个任务定义清楚。每个任务问自己：

• 这个任务的输入是什么格式？
• 专家处理这个任务时，有哪些固定步骤？
• 一个”优秀”的输出长什么样？有没有具体示例？
• 有哪些常见的错误或遗漏需要特别提醒？

把这些问题的答案整理成 SKILL.md 的初稿。这个阶段不需要任何代码，但它决定了整个系统的上限。

第二步：搭建 MCP Connector（1-2 周）

确定你的系统需要接入哪些外部数据源。优先检查是否已有现成的 MCP Connector 可用（Anthropic 和社区维护了越来越多的官方 Connector）。如果需要自开发，MCP 的官方文档提供了详细的 SDK 支持，接口规范相对清晰。

第三步：实现最简化的 Agent 层（2-3 周）

先实现单 Subagent 版本（不并行），验证 Skill 加载、MCP 调用、输出格式的端到端流程。当单 Agent 版本稳定后，再引入 Orchestrator 和并行 Subagent 架构。过早追求并行会带来不必要的调试复杂度。

第四步：建立测试体系（持续进行）

为每个 Skill 建立”金标准”测试集——已知输入和期望输出的配对。每次修改 SKILL.md 后，跑一遍测试集，确保变更没有导致质量退步。这是保证系统长期可维护的关键。

第五步：Plugin 封装（1 周）

当后端稳定后，再做 Plugin 层的封装。先做最简化的版本，后续根据用户反馈迭代界面设计。

常见陷阱与如何避免

工具链建议

基于 claude-for-legal 的架构思想构建系统，以下工具组合值得参考：

• Anthropic Claude API：显然是模型选择，claude-3-7-sonnet 或 claude-opus-4 视预算和要求选择
• MCP SDK：Anthropic 官方提供 Python 和 TypeScript 版本的 MCP SDK
• LangSmith 或 Langfuse：Agent 执行链路的可观测性工具，对调试多 Agent 系统至关重要
• Git + 结构化目录：Skill 仓库的版本管理，不需要特殊工具，标准 Git 工作流即可
• pytest 或 vitest：Skill 质量的自动化测试框架

9对企业决策者的启示：从”试用 AI”到”构建 AI 系统”

思维方式的根本转变

许多企业在 AI 这个问题上陷入了一个思维定式：把 AI 当作一个可以”拿来即用”的服务，期望购买一个 AI 工具、配置一下就能解决业务问题。

claude-for-legal 这套架构告诉我们一个不那么舒适但更真实的答案：在专业领域真正落地 AI，需要把 AI 当作一个工程系统来构建，而不是当作一个产品来购买。

这不是说 AI SaaS 产品没有价值——对于通用场景，现成产品完全够用。但如果你的业务有专业深度、有私有数据、有定制化的工作流程，那就需要自己构建，而不是套用通用工具。

企业 AI 落地的三个成熟度阶段

claude-for-legal 提供的，就是从 L2 迈向 L3 的参考蓝图。对于有意在 AI 上建立长期竞争优势的企业，这张蓝图值得认真研究。

构建自己的 Skill 库：知识资产的积累

我想特别强调 Skill 层对企业的战略意义。

一个企业随着时间积累的 Skill 库，本质上是企业专业知识的结构化沉淀。每一个 SKILL.md，都凝结了最优秀的专家的工作方法和经验。这些 Skill 一旦建立并经过验证，就成为企业难以被复制的知识资产。

竞争对手可以购买同款 Claude Pro，但无法复制你们积累多年的 Skill 库。在 AI 时代，模型是通用资源，Skill 是核心壁垒。

这也是为什么我建议企业现在就开始投入 Skill 的建设——即使是以最简单的 SKILL.md 形式，先把专业流程写下来，后续再逐步完善。知识积累是有时间价值的，越早开始越好。

10Claude 生态正在加速：我们身处的历史时刻

生态构建的信号

claude-for-legal 不是一个孤立的项目，它是 Anthropic 系统性构建 Claude 企业生态的一个缩影。结合最近几个月的动态来看，一幅清晰的图景正在浮现：

• MCP 协议的快速普及：自 2024 年末推出以来，MCP 已经获得了微软、Atlassian、Zapier、Cloudflare 等主流科技公司的支持，社区 Connector 数量持续增长
• Claude Desktop 的功能扩展：Plugin 机制的开放，意味着第三方开发者可以为 Claude Desktop 生态贡献工具，类似 VSCode 插件市场对编辑器生态的意义
• 参考实现的开源：claude-for-legal 不是第一个，也不会是最后一个。Anthropic 正在为越来越多的垂直领域提供参考架构
• 企业级功能的迭代：Projects、Memory、Team 协作功能的持续完善，显示 Anthropic 正在把企业市场作为核心战场

为什么是 Claude，而不是其他模型

我知道这篇文章读到这里，会有人问：这套架构思想是通用的，为什么不用 GPT-4o、Gemini 来实现？

这是一个合理的问题。从纯技术角度看，四层架构确实是模型无关的。但在工程实践层面，Claude 有几个具体优势：

• MCP 是 Anthropic 的亲儿子：MCP 协议由 Anthropic 设计，Claude 对 MCP 的原生支持最成熟、最稳定
• 超长上下文窗口：法律文档通常篇幅很长，Claude 的 200K token 上下文在处理长文档时有明显优势
• 指令遵循能力：Skill 机制依赖模型严格遵循 SKILL.md 中定义的步骤和格式，Claude 在这方面的表现一贯出色
• Constitutional AI 的安全性：在法律、医疗等高风险专业领域，模型的安全性和可预测性至关重要，Claude 的安全设计在企业场景更受信赖

这不只是技术趋势，是行业变革

让我最后说一句可能有点宏观的判断：claude-for-legal 代表的这种架构模式，将在未来 3-5 年内成为专业知识工作者行业的基础设施。

就像 ERP 系统在 1990 年代改变了制造业的运营方式，CRM 系统在 2000 年代改变了销售管理方式，基于 Skill + Agent + MCP + Plugin 四层架构的 AI 工作系统，将在 2020 年代末改变法律、医疗、金融、咨询等知识密集型行业的工作方式。

早期进入者——无论是了解这套架构并开始构建自己 Skill 库的企业，还是深入学习这套范式并提供架构咨询的工程师——都将获得显著的先发优势。

而这一切的起点，是能够真正使用 Claude 的完整能力，而不只是偶尔在网页端问几个问题。

11总结：四层架构的核心价值与行动建议

在结束这篇文章之前，让我用最简洁的语言，把 claude-for-legal 四层架构的核心价值提炼出来：

四层架构的本质

• Skill 层 = 把专家知识变成可执行、可测试、可迭代的工作手册
• MCP 层 = 用标准化接口连接 AI 与真实世界的数据和服务
• Agent 层 = 用 Orchestrator + Subagent 的分工实现并行、高质量的复杂任务处理
• Plugin 层 = 把复杂系统封装成用户能直接使用的简单界面

最重要的三个结论

第一，这是一套行业无关的通用架构。换掉 Skill 的内容，整套工程基础设施可以直接复用到任何专业领域。法律版只是第一个参考实现。

第二，Skill 层是企业真正的护城河。模型是通用资源，Skill 库是私有资产。企业应该把构建和维护高质量 Skill 库，作为 AI 时代的核心知识资产来对待。

第三，现在是进入这个生态的最佳时机。MCP 生态正在快速成熟，参考架构已经存在，先行者的优势窗口还没有关闭。对于个人开发者，现在理解和实践这套架构；对于企业，现在开始构建第一批 Skill——都是正确的时间节点。

你的下一步行动

• 阅读 Anthropic 在 GitHub 上的 claude-for-legal 仓库（搜索”anthropic claude-for-legal”）
• 阅读 MCP 官方文档，了解 Connector 开发规范
• 选择你所在领域最高频的 3 个任务，尝试写出第一个 SKILL.md
• 通过 海外客拼车 Claude Pro，获取 Claude 的完整企业级能力，开始实际验证你的 Skill 设计

AI 的下一轮竞争，不是模型之战，而是工程架构之战。理解 claude-for-legal 背后的设计哲学，你已经领先了大多数人一步。

参考来源：dotey (Twitter/X)，发布于 2026-05-13，对 Anthropic claude-for-legal 仓库的架构解析。
免责声明：本文为技术分析与观点文章，不构成任何投资或业务决策建议。Claude 相关产品和功能以 Anthropic 官方最新声明为准。
版权：本文由 hiwaike.com 资讯组原创，转载请注明来源。