# Legal Agent Orchestrator：多Agent协作的法律AI工作流系统

> 这是一个基于Claude Code的法律AI工作流系统，通过八个专业法律Agent协作生成可审计的法律意见书，每个Agent拥有独立的管辖区域、知识库和MCP工具，实现真正的多专家协同推理。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-15T22:45:20.000Z
- 最近活动: 2026-04-15T22:49:15.818Z
- 热度: 150.9
- 关键词: 法律AI, 多Agent系统, Claude Code, 法律工作流, GDPR, PIPA, AI编排, 审计轨迹
- 页面链接: https://www.zingnex.cn/forum/thread/legal-agent-orchestrator-agentai
- Canonical: https://www.zingnex.cn/forum/thread/legal-agent-orchestrator-agentai
- Markdown 来源: ingested_event

---

# Legal Agent Orchestrator：多Agent协作的法律AI工作流系统\n\n## 引言：超越单LLM的法律AI新范式\n\n当前市面上的大多数"法律AI"产品本质上都是单一的大语言模型，用户向它提问，它给出回答。这种模式存在根本性的局限：一个模型无论多么强大，其知识都是混合在一起的，无法真正同时扮演韩国隐私法专家和欧盟GDPR专家——因为这两个角色的知识会相互干扰，最终输出往往是两种法律体系的模糊混合。\n\nLegal Agent Orchestrator项目采用了一种完全不同的架构。它不是让一个模型假装成多个专家，而是真正部署八个独立的Claude Code Agent，每个Agent都有自己的CLAUDE.md系统提示、技能文件、知识库和MCP工具。这些Agent在物理上是完全隔离的实例，拥有各自独立的200K上下文窗口，通过编排器协调完成复杂的法律分析任务。\n\n这种架构的核心洞察是：真正的多专家推理需要真正的多Agent隔离，而不是单Agent的角色扮演。\n\n## 系统架构：编排器与专业Agent的协作网络\n\n整个系统由中央编排器和八个专业法律Agent组成，采用"摄入-分类-分派-组装"的标准化工作流。\n\n### 中央编排器的职责\n\n编排器运行在Claude Code主会话中，承担以下核心功能：\n\n**1. 案件摄入（Intake）**\n\n当收到法律问题时，编排器首先生成唯一的CASE_ID，初始化`events.jsonl`日志文件。这个日志采用追加写入模式，记录整个案件处理过程中的每一个关键事件，形成不可变的审计轨迹。\n\n**2. 智能分类（Classify）**\n\n编排器使用`skills/route-case.md`技能对问题进行多维度分类：\n- 管辖区域（韩国、欧盟、美国、国际等）\n- 法律领域（数据隐私、合同法、游戏法规、知识产权等）\n- 任务类型（研究、起草、审查、翻译等）\n\n分类结果决定了后续的分派策略和协作模式。\n\n**3. 智能分派（Dispatch）**\n\n基于分类结果，编排器选择合适的专业Agent，并通过Claude Code的Agent工具启动独立会话。关键设计在于：每个子Agent都是全新的Claude实例，拥有完整的200K上下文窗口，可以加载自己的系统提示、技能、知识库，并执行MCP查询。\n\n**4. 结果组装（Assembly）**\n\n子Agent完成任务后，将结果写入文件（如`research-result.md`、`opinion.md`）。编排器读取这些结果，提取关键发现，组装成最终的交付物：`opinion.docx`（客户-facing文档）、`case-report.md`（完整案件报告）、`events.jsonl`（审计日志）和`sources.json`（引用来源）。\n\n### 八大专业法律Agent\n\n| 专家Agent | 仓库 | 专业领域 | 阶段 |\n|-----------|------|----------|------|\n| 김재식 (Kim Jaesik) | general-legal-research | 跨国法律研究，覆盖17+司法管辖区 | Phase 1 ✓ |\n| 한석봉 (Han Seokbong) | legal-writing-agent | 法律文件起草（韩/英双语） | Phase 1 ✓ |\n| 반성문 (Ban Seong-mun) | second-review-agent | 法律文件最终审查与核实 | Phase 1 ✓ |\n| 정보호 (Jeong Bo-ho) | PIPA-expert | 韩国个人信息保护法专家 | Phase 2 ✓ |\n| 김덕배 (Kim De Bruyne) | GDPR-expert | 欧盟GDPR数据保护专家 | Phase 2 ✓ |\n| 심진주 (Sim Jinju) | game-legal-research | 游戏行业法律研究 | Phase 2 ✓ |\n| 고덕수 (Ko Duksoo) | contract-review-agent | 合同审查与谈判建议 | Phase 2 |\n| 변혁기 (Byeon Hyeok-gi) | legal-translation-agent | 法律文件多语言翻译 | Phase 2 |\n\n每个Agent都是独立的GitHub仓库，可以被单独更新和维护。编排器通过`./setup.sh`脚本克隆这些仓库，实现100%的Agent复用，不做任何修改。\n\n## 三种协作模式\n\n编排器支持三种不同的Agent协作模式，根据案件复杂度和领域交叉程度灵活选择：\n\n### 模式一：顺序交接（Sequential Handoff）\n\n这是最简单的模式，适用于单一管辖区域或聚焦领域的案件。典型流程是：\n\n研究Agent → 起草Agent → 审查Agent\n\n每个Agent完成后，将结果传递给下一个Agent，最终由编排器组装交付。Phase 1的端到端测试已验证此模式。\n\n### 模式二：并行研究后合并（Parallel Research → Merge）\n\n适用于跨领域但不需要辩论的案件，例如同时涉及韩国PIPA和欧盟GDPR的合规问题。\n\n[PIPA专家 ∥ GDPR专家] → 起草Agent → 审查Agent\n\n两位专家并行研究各自领域，结果合并后进入起草阶段。Phase 2.2已验证此模式。\n\n### 模式三：多轮辩论（Multi-Round Debate）\n\n这是最强大的模式，也是该系统的杀手级功能。适用于跨管辖区域且专家意见可能分歧的复杂问题。\n\nPIPA专家 → GDPR专家反驳 → PIPA专家回应 → 起草裁决 → 审查\n\n两位来自不同司法管辖区的专家真正展开辩论——不是同一个模型在角色扮演，而是两个真正独立的Agent，各自基于自己的知识库进行推理。这种深度是单LLM系统无法达到的。Phase 2.3正在开发此模式的骨架。\n\n## 上下文效率：为什么这种架构更优\n\n一个常见的误解是：编排器需要携带所有子Agent的上下文，导致上下文窗口迅速耗尽。实际上恰恰相反——这是最高效的多Agent架构。\n\n```\n编排器（~25-40K实际使用）\n    ↓ Agent工具调用\n子Agent A（全新200K）\n子Agent B（全新200K）\n子Agent C（全新200K）\n    ↓ 结果文件\n编排器（读取摘要）\n```\n\n编排器只消耗约25-40K的token，用于分类提示、分派指令和读取结果摘要。每个子Agent在自己的完整200K窗口中运行，可以加载完整的CLAUDE.md、所有技能、知识库，并执行实时MCP查询。\n\n相比之下，如果使用LangGraph、CrewAI等框架包装现有Agent，会损失40-50%的能力：MCP工具无法使用，技能系统需要重新实现，知识库浏览行为改变。最终得到一个漂亮的演示，但法律意见书的质量只有原来的一半。\n\n## 完整的审计轨迹\n\n与大多数商业法律AI产品的黑盒特性相反，Legal Agent Orchestrator的设计理念是"过程即产品"。\n\n每个案件的处理过程都被完整记录在`events.jsonl`中，包括：\n- 哪个专家Agent被分派\n- 引用了哪些来源（A级/B级/C级分级）\n- 事实核查员标记了哪些问题\n- 修订周期如何解决问题\n- 如果发生速率限制错误，编排器如何触发元验证救援\n\n最终交付的`case-report.md`将所有这些信息整合成一个连贯的叙述性文档，客户可以看到完整的推理链条，而不是一个孤立的答案。\n\n## Token消耗与质量权衡\n\n一个典型的案件可能在每个子Agent上消耗60K-170K的token，Phase 1的端到端测试总共消耗超过200K。这不是bug，而是设计选择。\n\n每个子Agent获得完整的200K上下文窗口，以便加载其CLAUDE.md、所需技能、知识库，并执行实时MCP查询。上下文共享和激进截断可以大幅降低token消耗——但会以同等幅度降低质量。\n\n该系统优化的目标函数是"每个案件的质量"，token消耗是为此付出的代价。在Claude Code Max上，边际美元成本为零，真正的成本是挂钟时间。如果你需要一个便宜的法律聊天机器人，这个项目不适合你。如果你想要一份有辩护力的法律意见书和完整的审计轨迹，这种消耗是入场券的价格。\n\n## 典型工作流程示例\n\n假设收到一个涉及韩国游戏公司处理欧盟用户数据的法律问题：\n\n**阶段1：案件摄入**\n编排器生成CASE_ID，初始化事件日志。\n\n**阶段2：智能分类**\n识别出涉及：韩国管辖 + 游戏行业 + 数据隐私 + 欧盟用户（GDPR适用）。\n\n**阶段3：并行分派**\n同时启动：\n- 심진주（游戏法律研究Agent）：研究韩国游戏行业数据处理的特殊要求\n- 정보호（PIPA专家）：分析韩国个人信息保护法的适用\n- 김덕배（GDPR专家）：分析欧盟用户数据的GDPR合规要求\n\n**阶段4：结果合并**\n三位专家的结果合并，识别出韩国法与欧盟法的交叉点和潜在冲突。\n\n**阶段5：起草**\n한석봉（法律起草Agent）基于合并研究结果撰写法律意见书，遵循韩国法律备忘录格式（쟁점→결론→분석）。\n\n**阶段6：审查**\n반성문（审查Agent）对起草的文档进行逐字来源核查，验证引用是否准确对应主要法律数据库（law.go.kr、eur-lex等），返回分级评论。\n\n**阶段7：修订与交付**\n如有需要，进行修订，最终由编排器组装成客户交付包。\n\n## 技术实现细节\n\n### Agent隔离机制\n\n每个子Agent通过Claude Code的Agent工具启动，是操作系统层面的独立进程，拥有：\n- 独立的CLAUDE.md系统提示\n- 独立的skills/目录\n- 独立的知识库（如GDPR专家的1,060+条索引）\n- 独立的MCP服务器连接\n\n这种隔离确保了知识不会交叉污染——GDPR专家不会"记得"PIPA专家说过什么，反之亦然。\n\n### 知识库结构示例\n\n以GDPR专家为例，其知识库包含：\n- 5部欧盟法律（321条+535条考虑因素）\n- 120份EDPB文档\n- 51份CJEU判决\n- 33份执法决定\n\n总计1,060+条索引，通过结构化RAG提供精确检索。\n\n### 文件传递协议\n\nAgent之间的协作完全通过文件系统进行：\n- `A-result.md`：Agent A的详细结果\n- `A-meta.json`：Agent A的元数据（token消耗、耗时、置信度等）\n\n编排器只读取摘要和关键发现，完整结果通过文件路径引用，避免上下文膨胀。\n\n## 局限性与未来方向\n\n当前系统的一些已知限制：\n\n**依赖Claude Code运行时**：这是有意为之的设计选择。使用Claude Code作为编排运行时是非标准的，但它保留了Agent的完整能力。包装成Web框架会失去MCP、技能系统等核心功能。\n\n**挂钟时间较长**：多Agent协作意味着多个串行或并行的LLM调用，复杂案件可能需要数十分钟。这是质量与速度的权衡。\n\n**多轮辩论模式仍在开发**：Phase 2.3正在构建真正的辩论模式骨架，目前主要是顺序和并行模式。\n\n未来可能的方向包括：\n- 更智能的Agent选择算法\n- 自动化的质量评估 gates\n- 与更多法律数据库的MCP集成\n- 支持更多司法管辖区的专家Agent\n\n## 结语\n\nLegal Agent Orchestrator代表了对法律AI的重新思考：不是追求单一模型的万能，而是拥抱多专家的专精。它承认法律问题的复杂性——不同司法管辖区的法律体系有着根本性的差异，不能简单地在同一个上下文中混合处理。\n\n通过真正的Agent隔离、完整的审计轨迹、以及灵活的协作模式，该系统为需要高质量、可辩护的法律分析的场景提供了一个实用的解决方案。它不是为快速问答设计的，而是为那些真正重要的法律决策——那些需要理解推理过程、需要可追溯来源、需要专家级深度的决策——而构建的。\n\n对于法律科技领域的从业者和研究者来说，这个项目提供了一个有价值的参考架构：如何用多Agent系统解决单LLM无法胜任的复杂推理任务。