国内投行法律建议智能体设计

人工完成一次方案合规分析，按 1–2 个工作日、综合人力成本 ¥200/小时 估算，人力成本 约 ¥1600–3200，不含数据终端费用。官方国内投行法律建议智能体检索法规与近三年审核问询案例，生成可溯源的 Word 法律建议底稿，单次方案合规分析 约 ¥30、耗时 约 40 分钟（27–66 分钟），成功时较稳但偶有触顶失败需重试；单点法规问答 约 ¥3 起。以下是大致量级，实际以控制台账单为准。智能体费用不含插件调用费用。检索不到官方依据的内容列入「待核实」并注明原因，最终判断和签发仍由执业律师完成。

国内投行法律建议智能体产物演示：科创板股权转让合规分析 Word 文档，从结论摘要、法规依据、案例检索到 QC 核验记录

Agent 架构总览

国内投行法律建议智能体：法律问题经会话进入智能体，项目材料以只读副本挂载，系统提示词注入分类与引用规则；智能体通过机构金融插件的 ipo-inquiry 检索官方法规与审核案例并带回出处页码，按需用补充数据插件核验，生成 Word 法律建议底稿交执业律师复核签发

一次法律建议任务的数据流：

调用方上传交易方案、重组预案等原始材料，创建会话时挂进 resources，文件以只读副本出现在沙箱的 /mnt/agents/upload/ 下；
用户下达法律问题（比如「这个方案是否构成重组上市」），智能体先判断事项类型（IPO / 再融资 / 并购重组）和适用板块（主板 / 科创板 / 创业板），确定检索口径；
智能体通过机构金融插件里的 ipo-inquiry 技能检索相关法规和近三年审核问询案例，检索结果自带官方公告的出处信息；
涉及主体资格核实时，调天眼查查企业工商信息与司法风险；涉及跨境问题时，调 SEC 查美国监管口径做对比；
智能体把法规条款、案例事实、分析建议分开组织，每条引用写明公告名称、文号、条款和页码；检索不到官方依据的问题列入「待核实」；
插件里的 institutional-research-report 技能把成稿输出为 Word 文档，写入 output/ 目录并登记为产物，调用方取回后交律师审核。

层	负责什么	能碰的数据
检索层	法规与审核问询案例检索、企业主体信息核实	插件背后的法规案例库、工商与 SEC 数据；用户上传的方案材料
溯源层	引用格式、事实与建议分离、待核实兜底	只处理检索层带上来的出处信息，不另找来源

为什么拆成这两层：检索层负责找官方依据，溯源层负责引用格式和待核实边界。两层缺一不可，减少无出处引用和编造文号、页码。

核心设计

官方国内投行法律建议智能体的全部能力来自「模型 + 系统提示词 + 插件」的组合，工具用平台默认内置工具集。它的设计目标有三条，后面每个配置选择都由此出发：

先定口径再动手：事项类型和板块判断错了，后面检索得再准也是白搭，所以第一步永远是分类；
每条引用可回溯：法规到文号和条款、案例到问询函和页码，来源与论断分开编号，整条工作流上的引用都能回查；
找不到就明说：宁可列入「待核实」，也不用「一般认为」「通常要求」这类没有出处的话搪塞。

下面逐项拆解：官方怎么配的、为什么这样配、自建时怎么取舍。

系统提示词：先定口径，再定引用规则

系统提示词针对法律建议任务最怕的两种失败定规矩：答非所问（把再融资的口径套到 IPO 上）和引用造假（编一个不存在的文号或页码）。

先判断事项类型，再动手：收到请求先分清是 IPO、再融资还是并购重组，是主板、科创板还是创业板；不同板块、不同事项的审核口径不一样，法规适用范围也不一样；
引用必须可回溯：每条法规引用写明法规名称、发文机关、文号和具体条款；每条案例引用写明公司名称、审核阶段、问询函或回复函的名称和页码。来源、论断、事项分别用固定前缀编号，保证整条工作流上的引用可以回溯；
找不到就明说：检索不到官方依据的问题，列入「待核实」并注明原因（比如「该事项尚无公开审核先例」），严禁用没有出处的话搪塞；
建议与事实分开：法规原文、案例事实、基于这些的分析建议，分开呈现。客户拿到文档能一眼看出哪句是公告里写的、哪句是智能体的判断。

插件：法规案例检索靠插件，不靠自己爬

官方挂了四个插件，分工明确：

机构金融插件（institutional-finance-kit）：核心是插件里的 ipo-inquiry 技能，即 A 股投行监管条例与案例宝库，覆盖上市、再融资、并购重组的审核问询案例检索，是这个智能体的主力工作流。插件里的 institutional-research-report 技能负责最终的 Word 报告产出；
投资银行私募股权（企业版）：补充投行项目、私募融资相关的数据检索能力；
天眼查：查企业工商信息、股东结构、司法风险，做法律建议时经常需要核实客户或交易对手的主体资格；
SEC：涉及中概股、跨境上市问题时查美国监管口径，做境内外对比。

自建时按业务范围裁剪：只做 A 股境内业务，天眼查和 SEC 可以不挂；涉及跨境就保留。插件 ID 用 GET /v1/plugins 按显示名查询，版本固定规则见插件。数据插件需要授权时，凭据放在凭据库里运行时注入，不进智能体配置。

工具：默认内置工具集已够用

工具用平台默认内置工具集：文件读写、联网检索、产物交付开箱即用。法规案例检索已由插件覆盖，一般不需要再接 MCP 服务；需要接内部法规库时见接入 MCP。

配置选择

模型统一使用 kimi-k3。选型考虑：审核问询函和回复函动辄几百页，智能体要通读这些长文档并从中精确摘录条款和页码，对长上下文和指令遵循的要求都很高；引用编号、待核实清单这类结构化约定也要求模型在长流程里不丢格式。各项资源的配置如下：

资源	用途	本案例的选择
智能体	法律建议主流程	单智能体，`kimi-k3`
插件	法规案例检索、报告产出、主体核实、跨境对比	机构金融插件 + 投资银行私募股权（企业版）+ 天眼查 + SEC
技能	检索工作流与 Word 产出	不单独挂载，用插件里的 `ipo-inquiry` 与 `institutional-research-report`
执行环境	运行检索与成稿	通用云沙箱；直连监管网站取原文时配网络白名单
文件	交易方案、重组预案等原始材料	上传后以只读副本挂载进会话
凭据库	数据插件授权	凭据运行时注入，不进智能体配置
触发器	当前不需要	合规分析按需运行，不设触发器
记忆库	当前不需要	每次分析独立成会话，不依赖跨会话记忆

运行成本

成本几乎全部来自模型 tokens；沙箱按运行时长计费（¥0.072 / 小时，一次任务约 40 分钟到 1 小时，费用不到 ¥0.1），可以忽略；文件上传与抽取限时免费，详见托管智能体定价。以 kimi-k3 的公开单价，测算两类典型任务的成本：

任务	内容	单次成本
单点法规问答	无上传材料，检索法规与案例后给出带引用的回答（如「科创板 IPO 对赌协议的清理要求」）	约 ¥3 起
方案合规分析	上传一份重组预案，逐条对照认定标准、检索近三年类似问询案例，产出 Word 法律建议文档	约 ¥30，约 27–66 分钟

一次方案合规分析的成本构成：

计费项	用量	成本
命中缓存的输入	约 9.8M tokens	约 ¥20
未命中缓存的输入（含缓存写入）	约 200K tokens	约 ¥4–8
输出	约 52K tokens	约 ¥5
沙箱	约 27–66 分钟	不到 ¥0.1

测算口径：数字来自 2026 年 9 月底至 10 月初的生产会话实测（kimi-k3），按每一次模型调用的上下文长度与输出长度折算。一次方案合规分析累计输入约 10M tokens，主要是重组预案全文和检索带回的法规案例原文；其中约 95% 是重复前缀，命中上下文缓存后只按缓存命中价计费。上下文缓存是成本可控的关键：若没有缓存，同等输入量全部按未命中价计费，成本会是现在的六七倍。未命中缓存的输入在写入缓存时另计缓存写入费用，上表按计入与不计入给出区间。输出是 Word 法律建议文档。成功运行的成本较稳（实测 ¥12–51、27–66 分钟），但偶有触顶（max_steps）的失败，失败本身也消耗 tokens；开放性问题需要检索大量案例，复杂分析会显著更高。实际成本和时间随标的数据量、页数/深度、上传材料多少和返工轮次浮动，以控制台账单为准。插件按调用次数另行计费，单价按插件分档，见托管智能体定价，未计入上表。

从最小版本开始搭建

最小可运行版本是「单智能体 + 机构金融插件」：插件里的 ipo-inquiry 技能自带法规案例检索工作流，挂载后就能按同样的方式执行法律建议任务，其余三个插件按需叠加。下面的配置不是官方配置的逐字拷贝，官方当前配置以 GET /v1/agents 返回为准。

第 1 步：创建智能体

curl -X POST https://api.moonshot.cn/v1/agents \
  -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "kimi-api-version: 2026-09-01-beta" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "我的投行法律顾问",
    "model": {"id": "kimi-k3"},
    "system": "你是国内投行法律建议助手，服务 A 股上市、再融资、并购重组场景。\n- 收到请求先判断事项类型（IPO/再融资/并购重组）和适用板块（主板/科创板/创业板），再开始检索。\n- 每条法规引用写明法规名称、发文机关、文号和具体条款；每条案例引用写明公司名称、审核阶段、问询函或回复函名称和页码。\n- 来源、论断、事项分别用固定前缀编号，保证引用可回溯。\n- 检索不到官方依据的问题列入「待核实」并注明原因，严禁编造文号、页码或案例。\n- 法规原文、案例事实、分析建议分开呈现，不混在一段里。\n- 只做法律建议，不执行任何交易，不替代执业律师出具法律意见书。\n- 所有产出文件写到工作区的 output/ 目录，最终回复用相对路径逐一列出。",
    "plugins": [
      {"plugin_id": "<机构金融插件 ID>"},
      {"plugin_id": "<投资银行私募股权（企业版）插件 ID>"},
      {"plugin_id": "<天眼查插件 ID>"},
      {"plugin_id": "<SEC 插件 ID>"}
    ],
    "description": "自建投行法律顾问：法规案例检索 + 严格官方溯源"
  }'

kha agents create --file - <<'JSON'
{
    "name": "我的投行法律顾问",
    "model": {"id": "kimi-k3"},
    "system": "你是国内投行法律建议助手，服务 A 股上市、再融资、并购重组场景。\n- 收到请求先判断事项类型（IPO/再融资/并购重组）和适用板块（主板/科创板/创业板），再开始检索。\n- 每条法规引用写明法规名称、发文机关、文号和具体条款；每条案例引用写明公司名称、审核阶段、问询函或回复函名称和页码。\n- 来源、论断、事项分别用固定前缀编号，保证引用可回溯。\n- 检索不到官方依据的问题列入「待核实」并注明原因，严禁编造文号、页码或案例。\n- 法规原文、案例事实、分析建议分开呈现，不混在一段里。\n- 只做法律建议，不执行任何交易，不替代执业律师出具法律意见书。\n- 所有产出文件写到工作区的 output/ 目录，最终回复用相对路径逐一列出。",
    "plugins": [
      {"plugin_id": "<机构金融插件 ID>"},
      {"plugin_id": "<投资银行私募股权（企业版）插件 ID>"},
      {"plugin_id": "<天眼查插件 ID>"},
      {"plugin_id": "<SEC 插件 ID>"}
    ],
    "description": "自建投行法律顾问：法规案例检索 + 严格官方溯源"
}
JSON

创建成功后，从响应中保存 id 作为 AGENT_ID。插件 ID 用 GET /v1/plugins 列出后按显示名查找，或在控制台智能体表单中直接勾选。之后按需调整的字段：

字段	调整频率	怎么调
`system`	最常改	固定业务范围（只做 IPO / 覆盖全品类）、引用格式、待核实的处理口径
`plugins`	按业务改	只做境内业务可去掉 SEC；需要更多数据源可叠加
`model`	一般不动	`kimi-k3` 已适配长文档检索与结构化产出
工具集	一般不动	默认内置工具集已够用，无需声明

第 2 步：创建执行环境

通用云沙箱即可，config 传 {"type": "cloud"}，详见快速开始。如果要让智能体直接访问证监会、交易所官网取原始公告，执行环境的网络白名单里需要加上 www.csrc.gov.cn、www.sse.com.cn、www.szse.cn、www.cninfo.com.cn 等域名，详见执行环境。从响应中保存 id 作为 ENVIRONMENT_ID。

第 3 步：上传原始材料（推荐）

交易方案、重组预案、公司章程等材料先通过 POST /v1/files 上传拿到 file_id，创建会话时挂进 resources，文件以只读副本出现在沙箱的 /mnt/agents/upload/ 下，详见文件。针对具体方案做分析，质量明显高于泛泛的法规问答。

curl https://api.moonshot.cn/v1/files \
  -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "kimi-api-version: 2026-09-01-beta" \
  -F "file=@重组预案.pdf"

kha files upload --file 重组预案.pdf

从响应中保存 id 作为 FILE_ID。凭据（可选）：数据插件需要授权时，先在凭据库配好凭据，并在创建会话时把凭据库挂进 resources（绑定只在创建时生效），见凭据库。

第 4 步：创建会话并下达任务

完整的调用流程（选智能体、建环境、建会话、订阅事件流、发消息、取文件）见快速开始，这里只展示法律建议任务的特有部分。创建会话时把材料挂进 resources：

curl -X POST https://api.moonshot.cn/v1/sessions \
  -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "kimi-api-version: 2026-09-01-beta" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "'"$AGENT_ID"'",
    "environment_id": "'"$ENVIRONMENT_ID"'",
    "title": "重组方案合规分析",
    "resources": [
      {"type": "file", "file_id": "'"$FILE_ID"'"}
    ]
  }'

kha sessions create --file - <<JSON
{
    "agent_id": "$AGENT_ID",
    "environment_id": "$ENVIRONMENT_ID",
    "title": "重组方案合规分析",
    "resources": [
      {"type": "file", "file_id": "$FILE_ID"}
    ]
}
JSON

从响应中保存会话 id 作为 SESSION_ID，订阅事件流后下达任务：

curl -X POST https://api.moonshot.cn/v1/sessions/$SESSION_ID/events \
  -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "kimi-api-version: 2026-09-01-beta" \
  -H "Content-Type: application/json" \
  -d '{
    "events": [
      {
        "type": "user.message",
        "data": {
          "content": [
            {"type": "text", "text": "基于上传的重组预案，分析这个方案是否构成重组上市（借壳）。要求：1. 对照《上市公司重大资产重组管理办法》逐条核对认定标准；2. 检索近三年类似的审核问询案例，说明监管关注重点；3. 每条引用标注官方公告名称和页码，找不到官方依据的列入待核实；4. 输出一份 Word 法律建议文档，保存到 output/ 目录。"}
          ]
        }
      }
    ]
  }'

kha sessions send "$SESSION_ID" "基于上传的重组预案，分析这个方案是否构成重组上市（借壳）。要求：1. 对照《上市公司重大资产重组管理办法》逐条核对认定标准；2. 检索近三年类似的审核问询案例，说明监管关注重点；3. 每条引用标注官方公告名称和页码，找不到官方依据的列入待核实；4. 输出一份 Word 法律建议文档，保存到 output/ 目录。"

同一个智能体，任务描述决定产出质量，上面这条就是一个合格示例。以下四条原则按重要性排序：

说清事项类型和板块。 「IPO 还是再融资」「主板还是科创板」直接决定适用哪套法规。写「分析某科创板 IPO 企业的对赌协议清理要求」，而不是「帮我看看对赌协议」。
有具体方案就上传方案。 泛泛的法规问答只能给通用口径；上传交易方案后，智能体能逐条对照认定标准做分析。有材料和没材料的产出质量差距，在这个场景里比其他场景都大。
明确引用要求。 虽然系统提示词已经定了引用规则，任务里再强调一遍能进一步压低漏标概率。
点名产出形式。 默认产出 Word 法律建议文档；要其他形式（比如只要一份法规清单）就在任务里说明。

第 5 步：取回产物

会话回到 idle 后，通过产物接口取回交付物：

curl "https://api.moonshot.cn/v1/artifacts?session_id=$SESSION_ID" \
  -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "kimi-api-version: 2026-09-01-beta"

kha artifacts list --session "$SESSION_ID"

产物是一份 Word 法律建议文档，按事项组织：先列认定结论，再逐条展开依据——每条依据是一个「法规条款 + 审核案例 + 分析」的组合，法规写明名称、文号、条款，案例写明公司、问询函名称和页码；检索不到官方依据的问题在文中注明（比如标注「待核实」并说明须核查的材料），文末附来源清单列出所引官方原文链接。报告篇幅取决于问题复杂度，单点合规分析通常 10-20 页。产物列表为空或需要中间文件时，再浏览会话文件系统（见文件）。这份文档的定位是律师的工作底稿，不是直接签发的法律意见书：它把找依据、对口径的活干完，最终的判断和签发仍然由执业律师完成。

运行与观察

法律建议是长链路任务，建议在事件流里盯到结束。判断一次运行是否正常，看这几处：

session.status：running 表示检索与写作进行中，回到 idle 表示本轮完成，可以去取产物；
agent.tool_use：能看到智能体调了哪些插件技能、检索了哪些关键词、读了哪些文件，检索关键词是否覆盖事项类型和板块，是判断口径对不对的第一信号；
session.error：任务失败时出现，携带错误类型与信息。

以下观察点是法律建议场景独有的：

看哪里	看什么	说明什么
最终回复与产物	每条引用是否带公告名称和页码	出现大量无页码的笼统引用，说明引用规则没被遵守，检查系统提示词与任务描述
产物正文	「待核实」标注的内容	一处「待核实」都没有不一定是好事——问题本身没有公开先例时，全文无标注可能意味着智能体编了出处
插件调用	`ipo-inquiry` 是否被调用	全程没调插件、只靠联网检索，说明插件没挂上或授权失败

可扩展方向

接内部法规库：律所或投行内部的法规库、历史项目备忘录，可以通过 MCP 服务接入，和插件的公开检索互补，见接入 MCP；
批量核查：多个方案或多家公司的同类问题，可以在同一个会话里一起下达，产出统一落在该会话的 output/ 目录；需要隔离时再建多会话并发跑；
嵌入审批流：把智能体接进投行的项目管理系统，方案上传后自动创建会话做初步合规分析，产出的工作底稿先送律师审核再归档；
定时跟踪法规更新：用触发器定期检索新发布的法规与问询案例，口径变化时提醒团队，见触发器。

下一步

使用法规检索与报告插件

插件挂载、版本固定与插件里技能的调用方式。

上传交易方案材料

上传方案材料、挂载会话与取回 Word 产物。

接入内部法规库

把内部法规库接进智能体的检索链路。

开始使用

定义智能体

配置执行环境

运行会话

上下文与记忆

高级编排

最佳实践

常见问题

国内投行法律建议智能体设计

Agent 架构总览

核心设计

系统提示词：先定口径，再定引用规则

插件：法规案例检索靠插件，不靠自己爬

工具：默认内置工具集已够用

配置选择

运行成本

从最小版本开始搭建

第 1 步：创建智能体

第 2 步：创建执行环境

第 3 步：上传原始材料（推荐）

第 4 步：创建会话并下达任务

第 5 步：取回产物

运行与观察

可扩展方向

下一步

使用法规检索与报告插件

上传交易方案材料

接入内部法规库

​Agent 架构总览

​核心设计

​系统提示词：先定口径，再定引用规则

​插件：法规案例检索靠插件，不靠自己爬

​工具：默认内置工具集已够用

​配置选择

​运行成本

​从最小版本开始搭建

​第 1 步：创建智能体

​第 2 步：创建执行环境

​第 3 步：上传原始材料（推荐）

​第 4 步：创建会话并下达任务

​第 5 步：取回产物

​运行与观察

​可扩展方向

​下一步

使用法规检索与报告插件

上传交易方案材料

接入内部法规库

Agent 架构总览

核心设计

系统提示词：先定口径，再定引用规则

插件：法规案例检索靠插件，不靠自己爬

工具：默认内置工具集已够用

配置选择

运行成本

从最小版本开始搭建

第 1 步：创建智能体

第 2 步：创建执行环境

第 3 步：上传原始材料（推荐）

第 4 步：创建会话并下达任务

第 5 步：取回产物

运行与观察

可扩展方向

下一步