律师如何用 Codex 搭第一个法律 Agent

上一篇文章里，我写的是律师应该怎样选择 AI 工具。

工具选好以后，真正的问题才开始出现：

怎么把一次性聊天，变成一个可以反复使用的法律工作流？

很多法律人第一次尝试搭 Agent，会把所有要求都写进一段很长的提示词。

比如：

请你扮演资深律师，阅读客户材料，整理事实，分析法律关系，列出证据缺口，起草沟通回复，并注意不要编造事实。

短期看，这样能跑。

但材料一多，问题很快会出现。

哪些是长期规则？

哪些是当前案件材料？

哪些是这一类任务的固定流程？

哪些是需要随时更新的检查清单？

哪些动作应该由脚本稳定执行？

如果这些东西全塞进一个提示词，最后就会变成一份很难维护、很难测试、也很难交接的长文本。

我更建议从一个很小的法律 Agent 开始。

不用先做平台，也不用先写复杂程序。

先用 Codex 搭一个能运行、能测试、出了问题知道改哪里的基础版本。

Abstract

本文用 Codex 演示一个最小法律 Agent 的搭建方式。

这个 Agent 暂时叫 legal-intake，处理一个非常常见的任务：律师收到客户微信、合同、转账记录或其他初步材料以后，先整理基本事实、客户诉求、现有材料、材料缺口和待确认问题。

它不是为了直接形成正式法律意见。

它的目标是让律师更快完成第一轮材料整理，并把不确定内容留在可复核的位置。

在这个基础版本里，一个法律 Agent 至少包含五类文件或目录：

legal-agent-demo/
├── AGENTS.md
├── cases/
├── records/
├── templates/
└── .agents/
    └── skills/
        └── legal-intake/
            ├── SKILL.md
            ├── agents/
            │   └── openai.yaml
            ├── references/
            │   └── intake-checklist.md
            └── scripts/

AGENTS.md 负责整个工作区的长期规则。

cases/ 保存脱敏案件材料。

records/ 保存任务状态、用户确认和处理记录。

templates/ 保存固定输出模板。

SKILL.md 负责说明某一类法律任务什么时候启动、按什么流程执行。

references/ 放详细检查清单。

scripts/ 放需要稳定重复执行的技术动作。

这套结构的重点，不是把文件夹做复杂。

而是把“长期规则”“案件材料”“任务流程”“专业检查”“确定性动作”分开。

只有分开，才容易维护。

1. 先说清楚：这不是写一个更长的 prompt

法律工作里，长 prompt 很容易给人一种错觉：

规则写得越多，Agent 就越可靠。

实际不是这样。

一个法律 Agent 需要的不是一段更长的指令，而是一套更清楚的分工。

至少要分出两层。

第一层是工作区。

工作区保存案件材料、过程记录、输出模板、长期规则和当前任务状态。

第二层是 Skill。

Skill 保存某一类任务的执行流程，比如客户咨询整理、合同审查、诉讼材料清单、法规案例检索、出稿前审查。

这两层不要混在一起。

案件事实不应该写进 Skill。

Skill 的业务流程也不应该散落在某一次聊天记录里。

这也是我在做 legal-skills 时反复确认的一件事：法律 Agent 真正要解决的，不是模型会不会说，而是工作流能不能被路由、被复核、被接管。

2. 建一个最小法律工作区

第一步，可以先在电脑上建一个很小的文件夹：

legal-agent-demo/
├── AGENTS.md
├── cases/
├── records/
└── templates/

cases/ 放不同事项的材料。

records/ 放当前进度、用户确认、待办事项和处理日志。

templates/ 放固定格式，比如首次咨询整理模板、材料缺口清单模板、客户沟通记录模板。

根目录的 AGENTS.md 是工作区规则。

第一版不用写得很长。

可以先写这些：

# 法律工作区规则

1. 处理材料前，先确认当前客户、案件和任务。
2. 不得混用不同案件的事实、材料和结论。
3. 发现材料缺失、事实冲突或来源不明时，必须明确标注。
4. 不得推测或补写不存在的事实和证据。
5. 输出内容应区分材料事实、当事人口述、模型推断和待确认事项。
6. 正式成果必须经过律师或法务人工复核。
7. 每次任务结束时，记录已经完成的工作和仍待处理的问题。

这份文件不是业务 Agent。

它解决的是长期边界。

比如不同案件不能混用材料，口述事实不能写成已有证据，正式成果必须人工复核。

这些规则如果每次都放在聊天框里，很容易忘。

放进工作区以后，Codex 每次处理这个目录，都能先读到同一套底层规则。

3. 再写一个只处理“客户咨询整理”的 Skill

不要一上来就做全业务 Agent。

第一个版本只处理一个高频、低切口、容易测试的任务。

比如客户咨询整理。

可以在工作区里创建：

.agents/
└── skills/
    └── legal-intake/
        ├── SKILL.md
        ├── agents/
        │   └── openai.yaml
        ├── references/
        │   └── intake-checklist.md
        └── scripts/

其中最重要的是 SKILL.md。

它至少要写清楚两件事：

什么情况下使用这个 Skill。
使用以后按什么步骤执行。

一个最小版本可以这样写：

---
name: legal-intake
description: 当律师需要整理客户首次咨询、微信聊天或初步案件材料时使用。输出事实摘要、客户诉求、现有材料、材料缺口、待确认事项和下一步建议。
---

# 客户咨询整理

1. 读取当前工作区的 AGENTS.md。
2. 确认本次材料属于哪个客户、案件和任务。
3. 读取用户提供的微信记录、文件和已有处理记录。
4. 整理已经能够确认的基本事实和客户诉求。
5. 列出现有材料能够支持的内容。
6. 标出缺失材料、冲突事实、来源不明内容和待确认问题。
7. 输出本次整理结果和下一步建议。
8. 未经用户确认，不把存疑内容写成确定事实。

这里的 description 很关键。

Codex 会根据名称、描述和上下文判断什么时候使用这个 Skill。

如果描述太泛，比如“处理法律问题”，它就很难稳定触发。

如果描述太宽，比如“处理所有案件材料、起草所有文书并给出完整建议”，后面也很难维护。

一个 Skill 最好只处理一类清楚任务。

第一个版本越小，越容易跑通。

4. 把详细清单放进 references，而不是塞进 SKILL.md

SKILL.md 适合写核心流程。

不适合承载所有细节。

比如客户咨询整理，可能要检查：

当事人和相对方是谁。
客户希望达到什么结果。
事情发生的时间顺序是什么。
目前有哪些合同、聊天、转账、通知、录音或截图。
哪些事实只有当事人口述。
哪些材料能够相互印证。
是否存在互相矛盾的说法。
下一步需要补哪些材料。
哪些事项涉及期限、管辖、主体资格或证据保全。

这些内容可以放进：

references/intake-checklist.md

再在 SKILL.md 里写清楚：

遇到材料超过 3 份、事实时间线不清楚、金额或主体存在争议、用户要求形成正式沟通记录时，读取 references/intake-checklist.md。

这样做有一个好处：

简单任务不需要加载一大堆规则。

复杂任务再读取详细清单。

这就是渐进式披露。

Agent 不需要一开始把所有知识都塞进上下文。

它只需要在合适的时候读到合适的文件。

5. scripts 只放确定性动作

很多人看到 scripts/，会忍不住开始写程序。

其实第一版可以没有脚本。

脚本应该用来处理确定性、重复性、可验证的技术动作。

比如：

批量生成材料目录。
检查文件名是否符合规则。
读取 Word 或 PDF 的基础信息。
计算文件哈希，确认版本有没有变化。
把结构化结果写入固定记录文件。
检查输出文件是否缺少必要字段。

脚本不负责替你判断案件。

它负责把某些容易出错、但可以明确验证的动作稳定下来。

如果一个动作还没有稳定下来，不要急着写脚本。

先让 Agent 手动跑几次，观察真正重复发生的问题。

等你能说清楚输入是什么、输出是什么、错误怎么判断，再把它变成脚本。

6. agents/openai.yaml 负责界面信息

agents/openai.yaml 可以保存这个 Skill 在 Codex 或相关界面中的显示信息。

例如：

interface:
  display_name: "客户咨询整理"
  short_description: "整理客户微信、案件事实、现有材料和待确认问题"
  default_prompt: "使用 legal-intake 整理这次客户咨询，并列出仍需确认的事实和材料。"

它主要解决的是入口问题。

用户打开 Skill 时，能看懂它叫什么、适合做什么、默认怎么启动。

但业务流程仍然以 SKILL.md 为准。

不要把真正的业务规则只写进界面描述里。

7. 用一组脱敏材料跑第一次测试

文件建好以后，必须实际跑一次。

可以在 cases/demo-case/ 放入一组脱敏材料：

cases/
└── demo-case/
    ├── 01-wechat-chat.md
    ├── 02-contract.md
    ├── 03-transfer-record.md
    └── case-note.md

然后对 Codex 说：

请使用 legal-intake 整理 demo-case，输出事实摘要、客户诉求、现有材料、材料缺口、待确认问题和下一步建议。

第一次测试，不要只看它写得顺不顺。

要看五件事：

它有没有先确认当前案件和任务。
它有没有读取正确文件。
它有没有把当事人口述和已有证据区分开。
它能不能发现材料缺失、时间矛盾或主体不清。
同样任务再跑一次，输出结构是否基本稳定。

如果测试不理想，不要马上换模型。

先回到文件结构里找问题。

长期规则出了问题，改 AGENTS.md。

任务流程不清楚，改 SKILL.md。

专业检查不够，补 references/。

固定技术动作不稳定，再考虑 scripts/。

这就是把法律 Agent 当成工程系统来维护，而不是当成一段一次性提示词。

8. 第一个版本做到什么程度算能用

第一个法律 Agent 不需要覆盖合同、诉讼、刑事、劳动、破产和企业法务全部业务。

它只要能在一个真实任务里稳定完成下面几件事，就已经有继续扩展的基础：

能识别什么时候应该启动。
能读取工作区里的长期规则。
能找到本次任务需要的材料。
能按照固定结构输出结果。
能标出缺失、冲突、来源不明和待确认内容。
能说明本次做完了什么，下一步还要做什么。
能把正式判断留给人工复核。

这时再考虑增加新的 Skill、接入 OCR、录音转写、法规案例库、Word 导出或多 Agent 分工，结构会清楚很多。

否则很容易一开始就把系统做得很大，但没有一个节点真正稳定。

9. 它和 legal-skills 的关系

我维护的 legal-skills，就是沿着类似思路往前走。

它不是一个单一提示词仓库。

它更像一组面向中国法律工作的可复核 Skill：

法律咨询助手。
合同审查。
合同起草。
法规案例检索。
诉讼文书起草。
法律文书出稿前审查。
刑事辩护流程。
劳动争议处理。
企业法务和合规场景。

这些 Skill 的共同目标，是把法律任务拆成材料读取、来源边界、专业分析、草稿生成、出稿检查和人工复核。

legal-intake 只是一个更小的入门版本。

它适合用来理解：

工作区规则为什么要独立出来。
Skill 为什么要有明确触发范围。
references 为什么不应该全塞进正文。
scripts 为什么只做确定性动作。
测试材料为什么必须脱敏。
正式交付为什么必须有人复核。

如果这个小结构跑通了，再把它扩展到合同、诉讼、检索和文书交付，就不会那么乱。

10. 边界：法律 Agent 不应该越过哪些线

最后还是要说边界。

这个基础 Agent 只能做材料整理和流程辅助。

它不应该直接对外形成正式法律意见。

它不应该把未经核验的事实写成确定事实。

它不应该混用不同案件材料。

它不应该在没有授权的情况下替人作出程序选择、和解判断或风险承诺。

它也不应该把模型推断包装成已经查明的事实。

一个更稳的法律 Agent，应该在关键节点停下来：

材料缺失 -> 停下来提示补充
事实冲突 -> 停下来列明冲突
来源不明 -> 停下来标注未核验
输出交付 -> 停下来进入人工复核
高风险判断 -> 停下来由律师或法务确认

法律 AI 的价值，不在于让系统看起来更会回答。

而在于让材料、来源、流程、检查和人工判断进入同一个可运行的工作区。

第一个法律 Agent 可以很小。

但它必须可读、可测、可改、可复核。

这比一开始做一个看起来什么都能做的大 Agent，更重要。

资料说明

本文根据我当前本机 Codex 工作区实践、AGENTS.md 工作区规则、OpenAI Codex Skill 创建说明，以及 legal-skills 项目的运行结构整理。Codex、Agent Skills 和相关目录约定可能随产品版本变化，实际使用时应以当前环境和官方文档为准。