ARTICLE · 1226019
从 Skill 到 Agent,一套法律 AI 能力体系应该怎样设计?
从 Skill 到 Agent，一套法律 AI 能力体系应该怎样设计？
当通用 Agent 已经具备强大的执行能力，律师真正需要构建的，究竟是什么？
律构实验室 08｜第二季 · 律师的 Skill 与 Agent · 收官篇
上一篇，我讨论了一个问题：
如果案件不断补充材料，AI 怎样判断哪些已经完成的分析需要重新核查，哪些成果仍然可以继续使用？
这涉及任务依赖、版本管理和变更影响分析。
但如果把这一季讨论的问题放在一起，还可以进一步提出一个更完整的技术问题：
如果不从头开发一个 Agent，也不把所有律师工作都做成 Skill，一套真正值得构建的法律 AI 能力体系，究竟需要哪些部分？
这个问题放在今天，已经具有不同于以往的技术背景。
Codex、WorkBuddy 等通用 Agent 已经能够读取文件、调用工具、执行程序，并围绕复杂任务组织多步骤工作。
对于相当一部分律师工作，我们不再需要自行实现底层的任务执行机制。
但这并不意味着，只要拥有一个足够强大的 Agent，就自然拥有了一套适合法律专业工作的 AI 系统。
通用 Agent 可以承担执行。
但究竟执行什么、依据什么规则、使用哪些数据、在什么条件下继续，以及形成的成果如何被复核和维护，仍然需要围绕具体专业任务加以设计。
这是第二季最终想回答的问题。
一、从 Skill 到 Agent，并不是一条简单的技术升级路线
首先需要澄清一个认识。
Skill 和 Agent 并不是从低级到高级、必须依次经过的两个技术阶段。
在 Codex 等工具中，Agent 本身就是任务的执行主体。
它能够根据目标安排步骤、使用工具，并在必要时调用已经配置的 Skill。
Skill 则承担另一类职责：将特定任务需要的指令、规则、参考资料和执行资源组织起来，供相应环境调用。
因此，一个 Agent 可以调用多个 Skill，也可以完全不调用 Skill，直接完成任务。
而一套包含多个 Skill 的工作环境，也并不需要因此再开发一个独立的 Agent。
这一区分看似简单，却直接影响法律 AI 的工程建设方式。
如果将 Skill 理解为一种需要不断升级、最终演变成 Agent 的技术形态，就容易产生错误的开发目标。
例如：
已经拥有 Codex，却仍然投入大量资源重新开发通用文件操作和任务规划功能。
已经能够直接完成的单次任务，仍然为它配置独立 Skill。
只是为了实现多个专项能力之间的调用，就引入额外的多 Agent 架构。
这些设计并非在任何情况下都没有价值。
但它们是否必要，应当由具体需求和技术约束决定，而不是由技术名称决定。
真正值得关注的，不是使用了多少种 AI 技术，而是每一种技术在专业工作中承担什么职责。
对于律师而言，一套法律 AI 能力体系也不应该简单理解为：
提示词越完善，Skill 越多，Agent 越复杂，系统就越先进。
恰恰相反。
随着通用模型和 Agent 能力增强，我们更需要判断，哪些功能已经可以直接复用，哪些专业能力仍然值得独立建设。
二、一套法律 AI 能力体系，需要明确四类职责
如果从工程角度重新组织这些能力，我更倾向于将其划分为四个相互关联的部分。
第一，是任务目标与授权边界。
任何一项法律工作，都需要先明确任务究竟是什么。
例如，同样面对一批案件材料，律师可能要求整理事实，也可能要求围绕特定法律关系展开研究，或者准备某类法律文书。
这些任务可能使用同一组材料，但工作目标、处理范围和成果要求并不相同。
因此，进入 Agent 执行之前，需要明确当前任务的目标、输入范围、允许采取的操作，以及哪些重要决定需要进一步确认。
这不是要求律师预先规定 Agent 的每一个执行步骤。
而是让 Agent 在合理自主的同时，拥有可以识别的任务边界。
第二，是通用执行环境。
这一部分可以优先利用现有 Agent。
例如，由 Codex 或 WorkBuddy 根据目标读取材料、调用工具、组织工作步骤，并在执行过程中处理必要的技术问题。
对于文件检索、程序调用、格式转换及一般性的任务规划，没有必要仅仅因为工作涉及法律，就全部自行开发。
但通用执行环境并不能替代针对具体法律任务的规则设计。
这就进入第三部分。
第三，是专业能力与执行资源。
专业能力可以通过不同形式提供。
有些要求适合通过任务指令明确。
有些规则需要在整个案件工作空间中持续适用，可以通过相应的项目级配置管理。
有些具有稳定边界、需要反复调用的专项工作，则适合封装成 Skill。
对于文件校验、编号维护、数据合并及格式处理等能够确定性执行的操作，还可以由程序承担。
这些形式并非彼此排斥。
一个 Skill 可以包含程序，Agent 也可以直接调用程序，而不经过独立 Skill。
真正重要的是合理划分模型理解、程序执行与专业复核之间的职责。
第四，是案件数据与工作成果。
这是我认为最容易被低估的一部分。
如果 Agent 每次执行以后，只留下一个无法回查依据的最终答案，那么即使单次任务完成得不错，也很难形成稳定的专业工作积累。
因此，对于需要反复处理、持续补充材料或者由不同任务接续的工作，还需要保存必要的数据关系。
例如：
原始材料及其来源；
结构化事实与引用；
任务采用的分析前提；
人工复核及更正记录；
工作成果的版本和更新关系。
不意味着所有法律工作都必须采用同一种数据格式。
而是应当根据任务的复杂程度，建立与后续使用需求相适应的数据组织方式。
由此，一套法律 AI 能力体系便有了基本的职责划分：
律师明确目标与授权，Agent 组织执行，专业能力与程序提供处理资源，案件数据承载可以复核和继续使用的工作成果。
这是一种参考架构，并不是要求所有任务都必须按照固定顺序运行。
Agent 可以在执行过程中反复读取数据、调用资源、检查结果，也可以根据任务条件调整步骤。
关键在于不同部分的职责足够清楚，能够根据具体需求组合使用。
三、回到我开发的律师 Skill，这套架构已经有哪些实际基础？
首先，我并没有为事实梳理重新开发一个 Agent。
材料理解及具体任务执行，仍然依赖现有的 AI 执行环境。
Skill 主要定义这项工作的任务边界、处理规则及相关资源。
例如，要求区分材料记载、一方陈述和待核推断；保留不同版本的事实表述；记录原文引用及待确认事项。
其次，不是所有环节都交给模型处理。
项目中的脚本负责材料清点、内容提取、数据校验、增量合并和成果渲染等工作。
其中能够确定性检查的部分，通过程序执行相应规则。
而材料语义理解、主体与事实识别、不同表述之间的关联分析，仍然需要模型参与。
再进一步，输出不只是最终展示文件。
现有项目除了七表 Excel 和离线网页，还会保存一份 case.json。
材料、主体、事实、引用及待核问题之间建立了关联编号，并保留相应的来源、复核状态和版本信息。
这样，律师看到某一事实事项时，可以沿着引用关系返回材料，而不只是阅读一段经过模型整理的描述。
最后，人工工作记录能够在既有规则下继续维护。
例如，律师已经完成的部分复核、更正和整理记录，可以通过相应的回导与更新机制保留。
新增材料影响既有记录时，系统可以将有关变化列为待确认事项，而不是直接覆盖已经保存的人工内容。
这些机制的意义，不在于让模型表现得更加聪明。
而在于使一项具体工作具有相对明确的输入、执行规则、数据结构和维护方式。
这也解释了为什么我更看重这套项目背后的工程结构，而不仅仅是它能够生成多少条事实、多少张工作表。
当然，必须明确：
目前公开的 v0.3 主要实现的是案件事实整理这一专项能力。
现有测试覆盖了数据结构、来源关联、部分增量更新和成果逻辑等方面，真实案件适用效果仍需进一步验证。
它并不等于已经建成了一套能够自主完成事实分析、证据评价、法律研究及文书交付的完整法律智能系统。
但从专业能力工程的角度看，它已经提供了一个可以继续扩展的实际起点。
四、真正的工程难点，不在于把这些部分连接起来
当通用 Agent、专项 Skill、程序和结构化数据都已经存在，把它们连接起来，并不是全部难点。
真正复杂的是：
怎样保证它们在共同工作时，仍然遵守既定的专业要求？
这涉及贯穿整个能力体系的工程控制。
首先，是质量评价。
程序能够验证某条引用是否存在，不代表它可以判断引用是否充分支持特定法律观点。
模型能够生成完整的分析报告，也不代表报告中不存在遗漏或者错误推断。
因此，针对不同任务，需要区分可以自动验证的工程要求，以及需要专业评价的内容。
这也是为什么，法律 AI 的能力评测不能只停留在能否成功运行。
其次，是执行权限。
Agent 能够自主调用工具，并不意味着它应当拥有任意修改案件数据的权限。
例如，读取事实底稿并形成新的证据分析，可以属于既定任务范围。
但直接覆盖已经由律师核对的原始记录，或者未经授权向外部提交法律文件，则属于不同性质的操作。
对能够由执行环境和程序控制的权限，应当尽可能设置可检查、可执行的限制，而不是完全依赖模型自行判断。
再次，是任务状态与专业复核。
一项工作在技术上执行完成，并不意味着其专业成果已经得到确认。
例如，事实底稿可以在部分材料尚未成功读取的情况下形成阶段性成果。
后续任务能够使用这些成果，却必须理解其处理范围和未解决事项。
因此，任务是否完成、质量检查是否通过、哪些内容已经人工复核，应当保留不同含义。
最后，是持续更新。
复杂案件中的材料和分析前提可能不断变化。
如果后续工作已经使用了某一版事实底稿，那么原始数据更新以后，还需要判断哪些既有分析可能受到影响。
但也不能因为出现新材料，就默认全部旧成果无效。
这里涉及来源关系、版本、任务依赖和变更影响管理。
这些机制并不是要消除法律专业工作中的全部不确定性。
而是让系统尽可能明确：哪些问题可以通过程序检查，哪些需要重新分析，哪些必须由律师进一步判断。
如果说 Agent 和 Skill 解决的是能力如何执行，那么工程控制进一步解决的是：这些能力在什么条件下可以被合理使用。
这也是我理解的法律 AI 能力工程与单纯组合 AI 工具之间的重要区别。
五、如果今天开始建设，我会优先做一套最小可用的专业架构
谈到能力体系，很容易直接想到大型软件平台、统一数据库、复杂调度系统甚至多 Agent 协作。
但对于个人律师或者小型专业团队而言，未必需要一开始就采用这些技术形态。
更合理的方式，是从实际任务出发，逐步建立最小可用的专业架构。
例如，可以选择某一类具有持续处理需求的复杂案件，先建立清晰的工作空间。
由律师指定材料范围、任务目标及必要的授权条件。
使用 Codex、WorkBuddy 等现有 Agent 作为执行环境。
对于已经形成明确规则的专项工作，调用相应 Skill。
利用程序完成适合确定性执行的数据检查和成果处理。
将原始材料、结构化数据、人工复核记录及不同版本的工作成果，按照明确的目录和数据规则保存。
如果下一项任务需要继续使用已有成果，再根据实际需要设计相应的数据接口。
在这个过程中，我认为有三件事尤其值得坚持。
只有某项专业工作确实存在值得复用的规则、资源或校验机制，才有必要考虑独立封装。
文件操作、工具调用和通用任务规划等功能，可以优先利用已有执行环境。
真正需要额外投入的，应当是法律专业工作特有的任务要求和工程约束。
例如，在只有一项事实梳理能力时，不必预先设计覆盖全部诉讼业务的数据模型。
当真实出现需要接续事实底稿的下游任务时，再明确它应当读取哪些数据、保留什么状态，以及怎样形成独立成果。
进一步涉及多任务协作、变更影响或长期案件管理时，再根据实际需要扩展相应机制。
这样的建设方式，并不意味着缺少系统性。
相反，它要求在架构上保持清楚的职责划分，同时避免无根据的过度设计。
一套专业能力体系，应当由真实工作中的稳定需求逐步生长，而不是先堆砌技术组件，再为它们寻找应用场景。
六、真正值得长期积累的，应当能够经受模型和工具的变化
还有一个问题，值得在第二季结束时单独讨论。
模型会升级，Agent 的执行方式和工具能力会继续变化。
一些过去需要详细指令才能完成的任务，可能逐渐由通用模型直接完成。
某些原本具有独立价值的 Skill，也可能随着技术发展而需要简化、重构，甚至不再单独维护。
这并不是能力工程的失败。
相反，如果一套专业能力始终需要依赖大量历史指令才能维持，就有必要重新审视其中哪些设计仍然必要。
这里可以区分两类不同的内容。
一类是随着技术发展可能改变的执行方式。
例如，特定模型需要的提示步骤、某种文档读取方法、某个平台的 Skill 安装方式，以及特定的工具调用流程。
另一类则是需要长期保留的专业要求。
例如，案件材料与模型生成内容应当区别对待。
事实应当能够回查其来源。
未经确认的信息不能在后续分析中无声转化为确定事实。
人工复核及更正应当具有明确记录。
重要操作应当遵守任务授权和专业责任边界。
前一类内容可能随着模型和执行环境的发展而不断调整。
后一类要求则来自法律工作的性质，不会仅仅因为模型能力提升就失去必要性。
因此，我更倾向于将专业规则、数据接口、确定性程序及复核记录，作为可以独立维护的工程资产。
这样，即使未来更换模型或 Agent 平台，也可以根据新环境重新组织执行方式，而不必将全部专业要求从头建立。
当然，这不意味着不同平台之间可以做到完全无差别迁移。
不同 Agent 对工具、权限、文件系统和 Skill 的支持方式可能存在差异，相应的适配和验证仍然必要。
但从设计上减少不必要的耦合，能够为长期演进留下更充分的空间。
真正值得沉淀的，不是某个模型版本下的一套固定操作，而是能够随着技术发展持续调整的专业规则、工作数据与验证机制。
七、法律 AI 的下一阶段，不应该只是拥有更多 Agent
讨论到这里，第二季实际上已经接近一个完整的结论。
在第一季，我主要从律师工作的具体环节出发，讨论 AI 如何参与事实整理、争议分析、证据组织和法律文书构建。
进入第二季以后，研究重点发生了变化。
我们开始考虑如何将其中值得复用的工作要求，形成相对独立的专业能力。
进一步讨论这些能力怎样验证、怎样选择恰当的实现方式，以及如何在不同任务之间保存和使用工作成果。
再进一步，当 Agent 能够持续执行任务，就需要处理执行条件、专业权限及长期更新的问题。
这些研究共同说明了一件事：
法律 AI 的能力建设，并不只是让 AI 完成更多工作，而是让它能够按照明确的专业要求，持续完成适合由其承担的工作。
这意味着，系统的成熟程度不能简单通过拥有多少个 Skill、多少个 Agent 或多少条自动化流程来衡量。
更重要的是：
能否准确界定任务及其适用范围；
能否合理组织模型、程序与专业资源；
能否保留工作成果的依据及状态；
能否对错误、异常和重要操作建立适当的控制；
能否在材料和规则变化以后继续维护已有成果。
这些要求，不一定意味着需要开发一个庞大的独立平台。
但它们构成了从零散使用 AI 工具，进一步走向专业能力工程的关键条件。
而当这些条件逐渐成熟以后，下一阶段的问题也会自然发生变化。
不再只是研究一项能力如何被调用。
而是进一步研究：
怎样建立能够长期管理案件状态的工作空间？
怎样实现不同专业任务之间的实际集成？
怎样组织多人协作、数据权限和工作记录？
怎样让一套法律 AI 能力，在真实业务中持续运行、维护和交付？
这些问题已经开始进入更加完整的法律智能系统建设。
它们也是「律构论」下一阶段值得继续研究的方向。
律构·思
从第一季的律师 AI 工作流，到第二季的 Skill 与 Agent，我越来越明确地看到：
技术能力的增强，正在改变法律专业方法的实现方式，但并不会自动替代对专业工作本身的设计。
过去，律师需要思考如何让 AI 更准确地完成一项任务。
今天，当通用 Agent 已经能够处理越来越复杂的工作，我们还需要进一步思考：
哪些专业要求值得独立沉淀？
哪些工作可以交给模型自主完成？
哪些操作应当由程序确保一致性？
哪些数据需要长期保存与维护？
哪些专业决定仍然需要明确的责任归属？
这些问题的答案，不应该由某一种技术工具预先决定。
而应当从具体法律工作的需求出发，选择合理的实现方式。
因此，如果要用一句话概括第二季，我更倾向于这样表达：
律师真正需要构建的，不是一个比通用 Agent 更复杂的 Agent，而是一套能够充分利用通用 AI，同时持续承载专业规则、工作成果与判断要求的能力体系。
执行环境可以更新，Skill 可以增加，也可以减少，专业规则可以随着实践不断修订。
但工作成果需要有依据，处理过程需要有边界，重要判断需要有清楚的责任归属。
这些要求，才是法律 AI 能力能够长期积累和演进的基础。
第二季到这里，暂时告一段落。
从律师工作方法，到法律 AI 能力工程，我们已经建立了进一步讨论智能法律实践的基础。
接下来，真正值得推进的，是让这些能力不只停留在单项任务与参考架构中，而是在具体、可验证的专业场景下，逐步形成能够持续使用的法律智能系统。
项目与延伸阅读
律构·案件事实梳理｜项目展示
https://zc6503204-collab.github.io/lugou-case-fact-workbench/
GitHub｜lugou-case-fact-workbench
https://github.com/zc6503204-collab/lugou-case-fact-workbench
本文为「律构实验室」第二季收官文章，讨论法律 AI 能力体系的参考架构与工程设计方法。现有公开项目已经实现案件事实梳理相关的专业规则、结构化数据、程序校验、人工复核及增量更新机制；跨专业任务的完整编排、依赖追踪及持续运行系统仍属于后续建设方向。
