~/legal-agent · hermes-cyber-terminal · 01/08
boot --talk "legal-agent-runtime"
HERMES
CYBER TERMINAL
法律 AI Agent 技术分享：从聊天问答，进入
可执行、可追踪、可复核的法律工作系统。
agent-runtime
legal-zh
llm-wiki
review-boundary
这一页用来建立基调：今天不是介绍一个聊天软件，也不是讲“提示词魔法”。重点是把法律服务中反复出现的资料整理、检索、生成、复核和交付，拆成一个可运行的系统。可以先提醒听众：Agent 的价值不在于回答更像律师，而在于把每一步留下输入、工具、依据、日志和人工确认点。
compare · chatbot-vs-agent
01 / Difference
聊天软件回答问题，Agent 推进任务。
面向律师客户时，最关键的区分不是“哪个模型更聪明”，而是谁能把工作流跑完并留下复核痕迹。
Chat UI
- 一次对话生成一段答案，历史上下文容易漂移。
- 不能稳定连接案卷、日程、检索、模板、内部知识库。
- 难以区分事实、检索结果、模型推理和律师判断。
- 交付物需要律师手动整理成清单、表格、邮件或合同批注。
Agent Runtime
- 把目标拆成计划、工具调用、记忆更新、复核和输出。
- 能接入数据库、文件、检索、消息入口、定时任务和团队知识。
- 每步保留来源、权限、日志、版本和人工确认状态。
- 输出可直接进入律师函、合同审查表、证据目录、风险清单。
这一页建议用“办案助理”类比：聊天软件像问答窗口，Agent 像能接任务、查资料、写草稿、整理表格、提醒期限、等待律师确认的工作台。重点不要贬低聊天软件，它很适合临时问答和头脑风暴；但当客户要可交付、可追责、可复制的流程时，就需要 Agent。
architecture · hermes-runtime
02 / Hermes Architecture
Hermes 的课堂讲法：
它是“持续运行层”。
Hermes Agent 的启发在于：Agent 不只在模型回答里工作，而是在消息入口、工具、记忆、定时任务和子代理之间保持状态。
Message GatewayCLI / Telegram / Discord / Slack / Email 等入口把自然语言任务变成统一事件。
Runtime Loop规划、调用工具、观察结果、更新记忆、决定下一步，不把任务停在一句回复。
Tools & Memory文件、检索、数据库、日历、模板、日志和历史工作法，形成可复用能力。
Scheduler & Subagents日报、期限提醒、法规监控、资料补全可由定时任务或子代理处理。
这一页把 Hermes 抽象成运行层来讲，而不是纠结某个具体命令。可以讲四个词：入口、循环、工具、记忆。律师客户能听懂的是：同一个 Agent 可以从邮件接收客户材料，从知识库找模板，从数据库查案件信息，从日历设置期限，然后把草稿交给律师复核。
03 / Legal Workflow
法律 Agent 的最小闭环：
输入、处理、复核、输出。
每个环节都要可解释：材料从哪里来、调用了什么工具、生成了什么中间物、谁做了最终判断。
01
材料进入客户合同包、聊天记录、证据目录、专利交底书、会议纪要。02
结构化抽取主体、日期、金额、条款、权利要求、争议焦点。03
检索增强查询法规、案例、模板、团队过往意见和项目知识库。04
草案生成输出合同审查表、律师函、证据清单、OA 答复草稿。05
律师复核标注红线、事实缺口、法源争议和对外承诺风险。06
归档学习保存版本、来源、结论、客户偏好和下一次可复用流程。
Claude for Legal ZH 的位置
它提供中国法语境下的技能层：合同审查、争议解决、知识产权、数据合规、法律检索、文书写作。Agent 应把这些能力封装成流程，而不是只把提示词塞给聊天框。
LLM Wiki 的位置
它提供知识沉淀层：原始材料保持只读，Wiki 页面负责概念、索引、日志、交叉引用和维护规则，让团队越用越厚。
这一页是技术和业务之间的桥。可以按一个合同审查例子串起来：客户发合同包，Agent 抽取条款和主体，查团队模板和法规，生成审查表，律师确认红线，最后把修改习惯和客户偏好沉淀回知识库。这里要强调：复核不是可选项，而是法律 Agent 的核心设计。
canvas-fx · knowledge-graph
04 / LLM Wiki
LLM Wiki 是法律知识的“编译层”。
原始资料只读，Wiki 维护结构化页面、索引、日志和交叉引用。知识不是每次重新检索，而是被整理成可复用的节点网络。
Raw sources：合同、法规、案例、会议纪要、客户资料保留原文。
Wiki pages：实体页、概念页、比较页、综述页和专题页承载理解。
Index / log：记录来源、更新时间、适用范围、冲突和废止提醒。
AGENTS.md / CLAUDE.md：约束命名、引用、审查和维护协作方式。
这一页可以把 Karpathy 的 LLM Wiki 思路讲成“给大模型看的团队百科”。不是把所有资料塞进向量库就结束，而是让资料有页面、有索引、有日志、有引用规则。法律场景尤其需要这点，因为法源可能过期，案例可能不适用，客户偏好也有范围。
05 / Review Boundary
课堂里必须
讲清楚的边界。
法律 Agent 的可信度来自流程设计，而不是一句“仅供参考”。每个高风险动作都要有来源、权限、日志和律师确认。
| 边界 | 课堂讲法 | 系统控制 | 法律场景 |
|---|
| 事实与推理分层 | 原文事实、检索结果、模型归纳、律师判断必须分开。 | 来源标签、引用锚点、版本号、草稿标记。 | 合同审查、证据目录、律师函事实陈述。 |
| 对外承诺限制 | Agent 可起草和整理，不得自动发送对外法律意见。 | 发送前人工确认、审批流、签发记录。 | 客户邮件、正式意见书、投标答复。 |
| 敏感信息最小化 | 客户资料按项目隔离，必要时先脱敏再进入模型。 | 权限分组、脱敏规则、日志审计、保留期限。 | 数据合规、劳动争议、商业秘密。 |
| 升级人工复核 | 涉诉讼策略、重大赔偿、时效、管辖、监管沟通必须升级。 | 风险词触发、置信度阈值、复核队列。 | 争议解决、知识产权、合规调查。 |
这一页是客户信任的关键。要讲得清楚：我们不是让 AI 取代律师判断，而是把风险边界嵌入流程。尤其是对外发送、重大权益、诉讼策略、监管沟通，这些动作必须升级到人工复核。Agent 的价值是少漏、快整理、可追踪，而不是替律师签字。
06 / Command Center
把客户演示做成
一条可验收的任务链。
# demo: 合同审查 agent
$ agent ingest ./client/SaaS-MSA.zip
[extract] parties / amount / term / liability
[search] PIPL + Civil Code + team templates
[draft] review-table.xlsx + redline.docx
[check] source tags: 42 / unresolved: 6
[wait] lawyer review required
# acceptance
输出: 条款风险表 / 修订建议 / 待补材料清单
日志: tool-calls.jsonl / citations.md / review.md
验收指标
客户买单看的是可验收：同一合同包，第一版审查缩到几十分钟，并留下复核清单。
4类试点场景
2层知识库
6个复核节点
30d形成购买理由
这一页要从成交视角讲，但语气保持技术分享。建议告诉听众：演示不要只展示聊天结果，要展示输入包、工具日志、中间表格、未解决问题、律师确认点和最终交付物。客户看到可验收，才会相信这是系统，而不是一次好运气的回答。
roadmap · pilot-to-production
07 / Pilot Roadmap
四周试点：先把一个场景跑稳。
不要一开始承诺“全所智能化”。选一个高频、边界清楚、容易验收的场景，跑通资料、工具、复核和归档。
Week 1 / 取样选择一个场景：合同初审、证据目录、专利交底、数据合规核查。收集 5-10 个历史样本，确定输入输出格式。
Week 2 / 编排把技能拆成 Agent 步骤：抽取、检索、生成、检查、复核。建立来源标签和日志格式。
Week 3 / 试跑用真实但低风险材料跑 10-20 次，记录节省时间、遗漏类型、人工修改原因。
Week 4 / 验收交付试点报告：流程图、指标、风险边界、报价抓手、下一阶段知识库扩展计划。
one workflow first
human-in-the-loop
audit log
no auto legal opinion
最后一页给出可执行路线。可以强调：试点不是做一个聊天机器人，而是把一个具体场景变成可重复流程。四周后客户应该看到三个东西：节省了多少时间，哪些风险被控制住，下一步扩展到哪些团队知识和业务场景。