> ## Documentation Index
> Fetch the complete documentation index at: https://platform.kimi.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# 国内投行法律建议智能体设计
> 拆解官方国内投行法律建议智能体的检索与溯源两层设计、逐条回溯到官方公告页码的引用规则与待核实兜底，附完整起点配置、运行成本测算与自建指引。
人工完成一次方案合规分析，按 **1–2 个工作日**、综合人力成本 **¥200/小时** 估算，人力成本 **约 ¥1600–3200**，不含数据终端费用。官方国内投行法律建议智能体检索法规与近三年审核问询案例，生成可溯源的 Word 法律建议底稿，单次方案合规分析 **约 ¥30**、耗时 **约 40 分钟（27–66 分钟）**，成功时较稳但偶有触顶失败需重试；单点法规问答 **约 ¥3 起**。以下是大致量级，实际以控制台账单为准。
智能体费用不含插件调用费用。检索不到官方依据的内容列入「待核实」并注明原因，最终判断和签发仍由执业律师完成。
## Agent 架构总览
一次法律建议任务的数据流：
1. 调用方上传交易方案、重组预案等原始材料，创建会话时挂进 `resources`，文件以只读副本出现在沙箱的 `/mnt/agents/upload/` 下；
2. 用户下达法律问题（比如「这个方案是否构成重组上市」），智能体先判断事项类型（IPO / 再融资 / 并购重组）和适用板块（主板 / 科创板 / 创业板），确定检索口径；
3. 智能体通过机构金融插件里的 `ipo-inquiry` 技能检索相关法规和近三年审核问询案例，检索结果自带官方公告的出处信息；
4. 涉及主体资格核实时，调天眼查查企业工商信息与司法风险；涉及跨境问题时，调 SEC 查美国监管口径做对比；
5. 智能体把法规条款、案例事实、分析建议分开组织，每条引用写明公告名称、文号、条款和页码；检索不到官方依据的问题列入「待核实」；
6. 插件里的 `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` 按显示名查询，版本固定规则见 [插件](/docs/hosted-agents/plugins)。数据插件需要授权时，凭据放在 [凭据库](/docs/hosted-agents/vaults) 里运行时注入，不进智能体配置。
### 工具：默认内置工具集已够用
工具用平台默认内置工具集：文件读写、联网检索、产物交付开箱即用。法规案例检索已由插件覆盖，一般不需要再接 MCP 服务；需要接内部法规库时见 [接入 MCP](/docs/hosted-agents/mcp)。
## 配置选择
模型统一使用 `kimi-k3`。选型考虑：审核问询函和回复函动辄几百页，智能体要通读这些长文档并从中精确摘录条款和页码，对长上下文和指令遵循的要求都很高；引用编号、待核实清单这类结构化约定也要求模型在长流程里不丢格式。
各项资源的配置如下：
| 资源 | 用途 | 本案例的选择 |
| - | - | - |
| 智能体 | 法律建议主流程 | 单智能体，`kimi-k3` |
| 插件 | 法规案例检索、报告产出、主体核实、跨境对比 | 机构金融插件 + 投资银行私募股权（企业版）+ 天眼查 + SEC |
| 技能 | 检索工作流与 Word 产出 | 不单独挂载，用插件里的 `ipo-inquiry` 与 `institutional-research-report` |
| 执行环境 | 运行检索与成稿 | 通用云沙箱；直连监管网站取原文时配网络白名单 |
| 文件 | 交易方案、重组预案等原始材料 | 上传后以只读副本挂载进会话 |
| 凭据库 | 数据插件授权 | 凭据运行时注入，不进智能体配置 |
| 触发器 | 当前不需要 | 合规分析按需运行，不设触发器 |
| 记忆库 | 当前不需要 | 每次分析独立成会话，不依赖跨会话记忆 |
## 运行成本
成本几乎全部来自模型 tokens；沙箱按运行时长计费（¥0.072 / 小时，一次任务约 40 分钟到 1 小时，费用不到 ¥0.1），可以忽略；文件上传与抽取限时免费，详见 [托管智能体定价](/docs/pricing/hosted-agents)。以 `kimi-k3` 的 [公开单价](/docs/pricing/chat)，测算两类典型任务的成本：
| 任务 | 内容 | 单次成本 |
| - | - | - |
| 单点法规问答 | 无上传材料，检索法规与案例后给出带引用的回答（如「科创板 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；开放性问题需要检索大量案例，复杂分析会显著更高。实际成本和时间随标的数据量、页数/深度、上传材料多少和返工轮次浮动，以控制台账单为准。插件按调用次数另行计费，单价按插件分档，见 [托管智能体定价](/docs/pricing/hosted-agents)，未计入上表。
## 从最小版本开始搭建
最小可运行版本是「单智能体 + 机构金融插件」：插件里的 `ipo-inquiry` 技能自带法规案例检索工作流，挂载后就能按同样的方式执行法律建议任务，其余三个插件按需叠加。下面的配置不是官方配置的逐字拷贝，官方当前配置以 `GET /v1/agents` 返回为准。
### 第 1 步：创建智能体
```bash cURL theme={null}
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": ""}
],
"description": "自建投行法律顾问：法规案例检索 + 严格官方溯源"
}'
```
```bash CLI theme={null}
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": ""}
],
"description": "自建投行法律顾问：法规案例检索 + 严格官方溯源"
}
JSON
```
创建成功后，从响应中保存 `id` 作为 `AGENT_ID`。插件 ID 用 `GET /v1/plugins` 列出后按显示名查找，或在控制台智能体表单中直接勾选。之后按需调整的字段：
| 字段 | 调整频率 | 怎么调 |
| - | - | - |
| `system` | 最常改 | 固定业务范围（只做 IPO / 覆盖全品类）、引用格式、待核实的处理口径 |
| `plugins` | 按业务改 | 只做境内业务可去掉 SEC；需要更多数据源可叠加 |
| `model` | 一般不动 | `kimi-k3` 已适配长文档检索与结构化产出 |
| 工具集 | 一般不动 | 默认内置工具集已够用，无需声明 |
### 第 2 步：创建执行环境
通用云沙箱即可，`config` 传 `{"type": "cloud"}`，详见 [快速开始](/docs/hosted-agents/quickstart)。如果要让智能体直接访问证监会、交易所官网取原始公告，执行环境的网络白名单里需要加上 `www.csrc.gov.cn`、`www.sse.com.cn`、`www.szse.cn`、`www.cninfo.com.cn` 等域名，详见 [执行环境](/docs/hosted-agents/environments)。从响应中保存 `id` 作为 `ENVIRONMENT_ID`。
### 第 3 步：上传原始材料（推荐）
交易方案、重组预案、公司章程等材料先通过 `POST /v1/files` 上传拿到 `file_id`，创建会话时挂进 `resources`，文件以只读副本出现在沙箱的 `/mnt/agents/upload/` 下，详见 [文件](/docs/hosted-agents/files)。针对具体方案做分析，质量明显高于泛泛的法规问答。
```bash cURL theme={null}
curl https://api.moonshot.cn/v1/files \
-H "Authorization: Bearer $KIMI_API_KEY" \
-H "kimi-api-version: 2026-09-01-beta" \
-F "file=@重组预案.pdf"
```
```bash CLI theme={null}
kha files upload --file 重组预案.pdf
```
从响应中保存 `id` 作为 `FILE_ID`。凭据（可选）：数据插件需要授权时，先在凭据库配好凭据，并在创建会话时把凭据库挂进 `resources`（绑定只在创建时生效），见 [凭据库](/docs/hosted-agents/vaults)。
### 第 4 步：创建会话并下达任务
完整的调用流程（选智能体、建环境、建会话、订阅事件流、发消息、取文件）见 [快速开始](/docs/hosted-agents/quickstart)，这里只展示法律建议任务的特有部分。创建会话时把材料挂进 `resources`：
```bash cURL theme={null}
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"'"}
]
}'
```
```bash CLI theme={null}
kha sessions create --file - <
从响应中保存会话 `id` 作为 `SESSION_ID`，订阅事件流后下达任务：
```bash cURL theme={null}
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/ 目录。"}
]
}
}
]
}'
```
```bash CLI theme={null}
kha sessions send "$SESSION_ID" "基于上传的重组预案，分析这个方案是否构成重组上市（借壳）。要求：1. 对照《上市公司重大资产重组管理办法》逐条核对认定标准；2. 检索近三年类似的审核问询案例，说明监管关注重点；3. 每条引用标注官方公告名称和页码，找不到官方依据的列入待核实；4. 输出一份 Word 法律建议文档，保存到 output/ 目录。"
```
同一个智能体，任务描述决定产出质量，上面这条就是一个合格示例。以下四条原则按重要性排序：
1. **说清事项类型和板块。** 「IPO 还是再融资」「主板还是科创板」直接决定适用哪套法规。写「分析某科创板 IPO 企业的对赌协议清理要求」，而不是「帮我看看对赌协议」。
2. **有具体方案就上传方案。** 泛泛的法规问答只能给通用口径；上传交易方案后，智能体能逐条对照认定标准做分析。有材料和没材料的产出质量差距，在这个场景里比其他场景都大。
3. **明确引用要求。** 虽然系统提示词已经定了引用规则，任务里再强调一遍能进一步压低漏标概率。
4. **点名产出形式。** 默认产出 Word 法律建议文档；要其他形式（比如只要一份法规清单）就在任务里说明。
### 第 5 步：取回产物
会话回到 `idle` 后，通过产物接口取回交付物：
```bash cURL theme={null}
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"
```
```bash CLI theme={null}
kha artifacts list --session "$SESSION_ID"
```
产物是一份 Word 法律建议文档，按事项组织：先列认定结论，再逐条展开依据——每条依据是一个「法规条款 + 审核案例 + 分析」的组合，法规写明名称、文号、条款，案例写明公司、问询函名称和页码；检索不到官方依据的问题在文中注明（比如标注「待核实」并说明须核查的材料），文末附来源清单列出所引官方原文链接。报告篇幅取决于问题复杂度，单点合规分析通常 10-20 页。产物列表为空或需要中间文件时，再浏览会话文件系统（见 [文件](/docs/hosted-agents/files)）。
这份文档的定位是律师的工作底稿，不是直接签发的法律意见书：它把找依据、对口径的活干完，最终的判断和签发仍然由执业律师完成。
## 运行与观察
法律建议是长链路任务，建议在事件流里盯到结束。判断一次运行是否正常，看这几处：
* **`session.status`**：`running` 表示检索与写作进行中，回到 `idle` 表示本轮完成，可以去取产物；
* **`agent.tool_use`**：能看到智能体调了哪些插件技能、检索了哪些关键词、读了哪些文件，检索关键词是否覆盖事项类型和板块，是判断口径对不对的第一信号；
* **`session.error`**：任务失败时出现，携带错误类型与信息。
以下观察点是法律建议场景独有的：
| 看哪里 | 看什么 | 说明什么 |
| - | - | - |
| 最终回复与产物 | 每条引用是否带公告名称和页码 | 出现大量无页码的笼统引用，说明引用规则没被遵守，检查系统提示词与任务描述 |
| 产物正文 | 「待核实」标注的内容 | 一处「待核实」都没有不一定是好事——问题本身没有公开先例时，全文无标注可能意味着智能体编了出处 |
| 插件调用 | `ipo-inquiry` 是否被调用 | 全程没调插件、只靠联网检索，说明插件没挂上或授权失败 |
## 可扩展方向
* **接内部法规库**：律所或投行内部的法规库、历史项目备忘录，可以通过 MCP 服务接入，和插件的公开检索互补，见 [接入 MCP](/docs/hosted-agents/mcp)；
* **批量核查**：多个方案或多家公司的同类问题，可以在同一个会话里一起下达，产出统一落在该会话的 `output/` 目录；需要隔离时再建多会话并发跑；
* **嵌入审批流**：把智能体接进投行的项目管理系统，方案上传后自动创建会话做初步合规分析，产出的工作底稿先送律师审核再归档；
* **定时跟踪法规更新**：用触发器定期检索新发布的法规与问询案例，口径变化时提醒团队，见 [触发器](/docs/hosted-agents/triggers)。
## 下一步
插件挂载、版本固定与插件里技能的调用方式。
上传方案材料、挂载会话与取回 Word 产物。
把内部法规库接进智能体的检索链路。