经济金融研究工具说明
AI 智能体 · API · Skill · MCP · Workflow

1.1五层工具坐标系

市面上 AI 工具名字繁多：DeepSeek、豆包、MCP、Skill、Workflow……新手最常见的困惑是「它们到底是什么关系」。本章先给一个五层坐标系：越往上越贴近「做事」，越往下越贴近「技术」——上层调用下层，下层支撑上层。研究员不必记住每个产品，只需要想清楚「手头这件事，该在哪一层解决」。

把五层翻译成研究员的语言：

1.2以本机内容为例的一组数字

这套坐标系不是纸上谈兵。以本讲义编写与演示所用的本机环境为例，能落地的规模是：

四款智能体分别为 WorkBuddy（腾讯）、ZCode（本讲义演示环境）、豆包办公（字节跳动豆包电脑版）、Codex（OpenAI）。技能目录在 ~/.zcode/skills，工作流在 ~/.zcode/workflows，均为本机实测数字；同花顺 MCP 覆盖股票 / 债券 / 基金 / 指数 / 港美股数据工具。具体以各产品当前版本与官方文档为准。

这组数字说明两件事。其一，技能与工作流是越用越多的个人资产：每个 Skill 是一次方法论沉淀，每条 Workflow 是一套流程固化，都不随对话清零——本机 304 个技能、10 条工作流，是日积月累沉淀下来的。其二，数据侧不必从零自建：同花顺 MCP 一个服务就提供 20 多个数据工具，覆盖股票 / 债券 / 基金 / 指数 / 港美股；行内数据仓也可以 MCP 形式自建接入（见第五节）。

1.3研究链条 × 工具映射

坐标系落到日常，就是研究链条的每个环节各有一组趁手工具。研究链条可归并为三段：输入侧（选题、文献、数据）、分析侧（实证、作图）、输出侧（写作、评审、发布）。下表把八个环节的「传统做法—AI 辅助做法—推荐工具—银行研究示例」排成一张对照表，也是全书的使用索引：读完后续章节后，回到这张表按图索骥。

用法提示：表中任何一格都不要求写代码——Skill 装上即用，MCP 配好即取，工作流填参即跑；具体安装与配置见第四、五、六节。

1.4三条使用心法

工具年年换，心法不变。以下三条来自一线使用的教训，比任何具体工具都值得先记住。

三条心法落到操作上，就是一张「提示词三要素」对照表。以银行研究最常见的任务——「写一段 LPR 下调对上市银行净息差影响的点评」——为例：

1.5一句话定位与全书路线图

后续七章按「会做 → 连得上 → 更专业 → 成规模 → 收口」展开，各用一句话预告：

读完全书的标准很简单：回到表 1-2，找到你本周最耗时间的那一格，用对应工具把它重做一遍。

2.1Agent 与聊天机器人的差别

研究员熟悉的网页对话框是「聊天机器人」：一问一答，产出止于窗口内的文字，后续搬运靠人工。智能体则是把大模型装进一个运行时（Runtime）：配上工具（读写本地文件、联网取数、执行命令）、记忆（跨会话保留偏好与中间产物）、规划（把一句话目标拆成多步并自己执行），交付的是落了盘的成品。先分清这层差别，再谈选型。

2.2四款产品卡：形态与能力

四款产品对应四种形态：办公生态桌面工作台（WorkBuddy）、编码型终端智能体（ZCode）、PC 办公 Agent（豆包办公）、工程化编码智能体（Codex）。每张卡给出定位一句话、核心能力、银行研究场景与上手路径。

2.3横向对比

四款产品能力有重叠但侧重不同。结论先说：WorkBuddy 胜在办公生态连接与长期记忆，ZCode 胜在全栈运行时与流程编排，豆包办公胜在中文办公与金融技能开箱即用，Codex 胜在代码工程化。九个维度逐项对齐如下。

2.4同一任务，四种做法

任务：把近三年四大行年报中的净息差（NIM）、不良率、拨备覆盖率整理成一张表并出图。同一个活，四款产品各有顺手路径——差别不在「能不能干」，而在人守哪一道闸、成品落在哪、明年能不能复跑。

四条路径没有绝对优劣：一次性任务选前三条顺手，年年要跑的活值得用第四条一次性工程化。耗时均为示意量级，取决于数据可得性与 PDF 质量，不构成性能承诺。

2.5怎么选：按需求对号入座

不必纠结「哪款最好」，按手头要做的事对号入座即可；同一段工作流里换用两三款也是常态。

2.6使用智能体的三条安全习惯

智能体能动真实文件与系统，安全习惯比产品选择更重要。把任何一个任务交给智能体，都建议按下面五步走：

3.1为什么要 API

研究员日常的网页对话有三个天然上限：一次只能处理一段文本、结果靠复制粘贴、参数无法固化。一旦任务变成"把今年 300 份央行及监管公告逐条打分""每晚自动汇总 30 家上市银行业绩快报""全部城投公告入库时自动抽要点"，网页对话就不够用了。API 把模型变成一个可编程的部件，价值集中在三点：

3.2三步接入：从注册到第一次调用

在 DeepSeek 开放平台（platform.deepseek.com）注册即可开通，接口文档在 api-docs.deepseek.com。DeepSeek 接口兼容 OpenAI 格式：用 OpenAI 官方 SDK，改 api_key 与 base_url（https://api.deepseek.com）两处即可调用——这意味着学会一家，各家基本都会。

代码 3-1　Python（OpenAI SDK）：判断一份央行公告的政策方向并强制输出 JSON——这是"公告打分"任务的最小可用形态。

from openai import OpenAI
client = OpenAI(api_key="sk-***", base_url="https://api.deepseek.com")

resp = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": "你是银行业研究助理。只输出 JSON。"},
        {"role": "user", "content": "判断下面央行公告的政策方向(宽松/中性/收紧)、涉及工具、"
                                    "对银行净息差的影响方向，并给出 0-1 的信号强度：\n" + notice_text}
    ],
    response_format={"type": "json_object"},
    temperature=0.2,
)
print(resp.choices[0].message.content)

// 返回体结构节选示意，字段以 api-docs.deepseek.com 为准
{
  "model": "deepseek-chat",
  "choices": [{
    "index": 0,
    "message": {"role": "assistant", "content": "{...JSON 字符串...}"},
    "finish_reason": "stop"
  }],
  "usage": {"prompt_tokens": 812, "completion_tokens": 96}
}

代码 3-2　curl 版本：不装任何环境即可调通，适合快速验证密钥与网络；密钥经环境变量传入，不留在命令历史里。

# 先执行 export DEEPSEEK_API_KEY=sk-***
curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-chat",
    "messages": [
      {"role": "system", "content": "你是银行业研究助理"},
      {"role": "user", "content": "用 150 字概括这份研报的核心观点并保留关键数字：..."}
    ],
    "stream": false
  }'

两个模板只差"外壳"，核心都是一次 HTTP 请求：选模型、给消息、设参数。研究中最常用的参数如下表。

3.3模型与接口选择

模型选错，时间与费用双输。DeepSeek 当前提供两个模型名（所对应的底层版本以官网说明为准）：

国内主流厂商普遍提供兼容 OpenAI 格式的接口，切换成本极低：

3.4金融研究五种典型调用

落到银行研究场景，API 调用反复出现的就五类任务。它们的共同心法是：system 定身份与规则，user 给材料与任务，输出给 schema，结论靠校验——模型输出永远只是半成品，必须设计校验环节。

# system 消息全文（示意）
你是银行业研究助理。从用户给出的业绩报告原文中抽取以下字段，
严格按 JSON 输出，不得添加注释字段：
{
  "bank_name": "银行简称",
  "period": "报告期，格式 YYYY-MM-DD",
  "nim": "净息差（%），原文没有则填 null",
  "npl_ratio": "不良贷款率（%）",
  "provision_coverage": "拨备覆盖率（%）"
}
规则：
1. 数字必须与原文完全一致，保留原始小数位，不做换算；
2. 每个字段附 "evidence" 子字段，摘录原文中支撑该数字的短语；
3. 原文未披露的字段填 null，禁止推测；
4. 只输出 JSON，不输出任何其他文字。

3.5批量任务模板

把代码 3-1 扩成"读 CSV、逐条调用、写回 CSV"的骨架，就是绝大多数批量任务的起点（示例：对一批评级公告或货币政策公告打方向分）。密钥从环境变量读取，重试用指数退避：

代码 3-3　Python 批量模板（示意）：读取 announcements.csv，逐条打分写入 scored.csv。

import csv, time, json, os
from openai import OpenAI
client = OpenAI(api_key=os.environ["DEEPSEEK_API_KEY"], base_url="https://api.deepseek.com")

def score(text, retry=3):
    for i in range(retry):
        try:
            r = client.chat.completions.create(
                model="deepseek-chat", temperature=0,
                response_format={"type": "json_object"},
                messages=[{"role": "system", "content": SYSTEM_PROMPT},
                          {"role": "user", "content": text}])
            return json.loads(r.choices[0].message.content)
        except Exception as e:
            time.sleep(2 ** i)          # 指数退避：失败后等 1s、2s、4s 再试
    return {"error": "failed"}

with open("announcements.csv", encoding="utf-8") as f, \
     open("scored.csv", "w", newline="", encoding="utf-8") as out:
    w = csv.writer(out); w.writerow(["id", "direction", "strength", "evidence"])
    for row in csv.DictReader(f):
        s = score(row["text"])
        w.writerow([row["id"], s.get("direction"), s.get("strength"), s.get("evidence")])

• 限流与重试：网络错误与限流用指数退避（示例：第 i 次失败后等 2^i 秒），最多 3 次；仍失败落标记，不中断整批；
• 幂等与断点续跑：每条的处理状态落盘，程序崩溃后重跑只补失败与新增条目，不重复扣费；
• 抽检比例：示例——每批随机抽 5% 人工复核，错误率超过约定阈值即停批、改提示词后重跑；
• 成本预估：示例公式 = 条数 ×（平均输入 token + 平均输出 token）× 对应单价。先拿 20 条试跑测出平均 token，再估算全量费用后放行。

3.6成本与工程要点

3.7从 API 到 Function Calling 到 MCP

代码 3-4 演示 Function Calling 的机制：模型不直接编造"某银行净息差是多少"，而是返回"我想调用 get_nim，参数是……"；由你的程序真正执行查询，把结果作为 role=tool 消息回填，模型再基于真实数据写结论——数据始终不出你的程序，模型只做决策与表达。

代码 3-4　Python（示意）：声明工具，模型决定调用，程序执行后回填。

tools = [{
  "type": "function",
  "function": {
    "name": "get_nim",
    "description": "查询某银行某报告期的净息差（%）",
    "parameters": {"type": "object",
                   "properties": {"bank_code": {"type": "string"}, "period": {"type": "string"}},
                   "required": ["bank_code", "period"]}
  }
}]
r = client.chat.completions.create(model="deepseek-chat", messages=msgs, tools=tools)
call = r.choices[0].message.tool_calls[0]          # 模型决定要调 get_nim 以及参数
result = get_nim(**json.loads(call.function.arguments))   # 你的程序真正执行
# 把 result 作为 role=tool 消息回填，再让模型写结论

最后一个常被忽略的事实：智能体本身也是 API 的用户。ZCode、Codex 等智能体都可以配置成走 DeepSeek、GLM 等模型接口——本讲义的演示环境就是通过厂商编码套餐接入 GLM 模型的。因此"接 API"有两层含义：自己写程序调模型，以及把智能体接到自选的模型上。后者不需要写代码，改配置即可。

4.1Skill 是什么：把方法写成文件夹

一个 Skill 就是一个普通文件夹，核心是一份 SKILL.md：开头是 YAML frontmatter（元信息头），至少写 name（技能名）与 description（何时使用）；正文是写给智能体的操作指南。此外可以带三个可选目录——scripts/ 放可执行脚本、references/ 放规范与口径表、assets/ 放模板。下面用本讲义自拟的示例技能「商业银行净息差（NIM，Net Interest Margin）跟踪」看它的两个侧面：

# 讲义自拟示例（节选）
---
name: bank-nim-tracker
description: 跟踪并解读商业银行净息差：当用户提到净息差、
  NIM、资产负债定价，或要做银行息差同业比较时使用。
---
# 商业银行净息差跟踪
## 何时使用
## 取数口径（优先 MCP：同花顺 get_stock_financials；注明报告期与是否年化）
## 分析步骤：1 取数 → 2 同业对齐 → 3 拆解资产端/负债端
  → 4 对照 LPR 与存款利率调整 → 5 出表出图
## 输出模板：一表（同业对比）+ 一图（趋势）+ 300 字解读
## 红线：口径不混用；每个数字注明报告期与来源；不给投资建议

三个可选目录什么时候需要？只写方法不带动作，SKILL.md 一个文件就够；要固化取数、出图等操作，加 scripts/；有指标定义、口径对照这类查表型知识，放 references/（需要时才读）；有固定版式，放 assets/。

• description 决定触发：智能体把当前任务与各技能的 description 匹配，决定要不要加载这个技能——description 写得准，技能才用得上；
• 渐进披露：只在被触发时才读入正文与附件，平时不占用日常上下文，所以正文可以写得细、写得长；
• 可带脚本与模板：方法、口径、代码、模板装在一个文件夹里整体复用。在 ZCode 中可用 /技能名 显式调用或自动触发；WorkBuddy、Codex、Trae 读取通用目录 ~/.agents/skills。

正文怎么写？右卡示例的骨架就是现成模板：

• ## 何时使用：先划边界，减少误触发；
• ## 取数口径：写清优先走哪个工具、必须注明报告期与单位；
• ## 分析步骤：把动作排成有顺序、可执行的清单；
• ## 输出模板：固定产出形态（一表一图一段解读）；
• ## 红线：写死不能碰的事（口径混用、无来源数字、投资建议）。

一句话：把你会怎么带新同事做这件事，原样写给智能体。

体感判断：每次都要粘贴同样一大段话术，说明该升级成 Skill；某类任务智能体总把口径做错，说明缺一份写清口径的 SKILL.md。

4.2Skill 与提示词模板、模型微调的边界

研究员更熟悉提示词模板（一段可复制的问法）。三者的分工可以一句话记：提示词模板改「这一次怎么问」，Skill 沉淀「一类事怎么做」，模型微调改变「模型本身会什么」。逐项对比如下：

对研究部门而言，Skill 的关键优势在「能带口径表与模板」「可版本管理」两行：方法跟着口径和模板走、改动可回溯——这也正是内部审计与监管检查最看重的两点。

示例：想让个人晨报格式统一——用提示词模板每次粘贴即可；想让全组净息差点评按同一套口径——做成 Skill；想让模型默认就说行话、无需任何提示——才轮到微调。

4.3本机技能库画像

技能库能长到多大、由什么构成？以本机为样本先看数字：

构成上大致分几层：学术方法论与工作流（wf-* 系列）、办公文档套件（docx / pptx / xlsx / pdf 等）、豆包办公金融套件（doubao-*，72 个）、金融数据与检索，以及管理技能本身的「元技能」。304 个听来很多，但日常高频使用的其实集中在下一节的清单里——技能不怕多，怕的是不知道自己有什么。

数字背后的观察：技能库的增长主要来自套件式安装——一次装一组（如 doubao-*、sd-*），而不是逐个手写；个人自建的是少数，却通常是价值最高的部分。

两组数字的关系：通用目录的 323 = 304 的镜像，再加少量只装在通用目录的补充技能。

口径说明：以上数字为本机当前快照，随安装与卸载增减；重要的不是绝对数，而是「技能可以积累」这个事实。

实操建议：每月花十分钟盘点一次自己的技能目录，把当月重复做过两次以上的事情记下来——它们就是下一个值得沉淀成 Skill 的候选。

4.4按研究环节的精选清单

以下六张表沿研究链条排列：选题文献（A）→ 数据实证（B）→ 写作评审（C）→ 日常办公（D），再加豆包办公金融套件（E）与技能管理（F）。每行给出「做什么」与「银行研究怎么用」各一句；技能名均为本机真实安装名。

「银行研究怎么用」只是入口示例而非全部用法，同一技能常可跨环节复用：如 sentiment-analysis 既用于央行公告解读，也用于财报电话会纪要。

用法建议：按手头任务在对应组里先挑一两个试用，用顺再补；清单是菜单，不是必装列表。

速查：选题文献 → 表 4-2；数据实证 → 表 4-3；写作评审 → 表 4-4；日常办公 → 表 4-5；豆包套件 → 表 4-6；技能管理 → 表 4-7。

4.4.1　A 组：选题、文献与政策梳理

研究链条的最前端：把题选对、把文献读全，决定后面所有投入是否值得。这组技能围绕公开学术资源，适合开题与综述阶段。

注意：arxiv 预印本未经同行评审，引用时标注状态；顶刊检索与预印本检索配合用，快与稳兼得。

A 组串起来是一条完整链路：检索（econ-lit-search / arxiv / sd-*）→ 综述（literature-review）→ 查新（novelty-check）→ 写作与投稿（journal-advisor、citation-validator）。

4.4.2　B 组：数据、实证与建模

取数、清洗、建模是研究工作量最大的一段，也是技能最密集、省时最多的一段。其中 ifind-finance-data 是 Skill 与 MCP 配套的实例，详见 4.5。

这组内部分工清晰：找数据源（datapro-search）→ 取数（ifind / sec-edgar / datacommons）→ 清洗（data-cleaning）→ 建模（regression / financial-models）→ 呈现（multi-stock-comparison）。

B 组提醒：涉及行情与高频数据的技能，产出引用时注意数据版权与使用范围，对外发布前过一遍合规。

4.4.3　C 组：作图、写作、润色与评审

从结果到成稿：图要规范、文风要稳、成稿要有人挑毛病——挑毛病这一步，可以让智能体先来一遍。

C 组的使用节奏：初稿完成后先跑评审类拿问题清单，改完再用润色类，最后 fit-page-limit 收版面——顺序反了，返工是白做的。

4.4.4　D 组：文档、办公与信息获取

研究的日常底座：Word / PPT / Excel / PDF 四件套，加上检索、浏览器自动化、新闻监控、邮件与协同平台。D 组最「不 AI」，却最常被用到。

浏览器与邮件类技能涉及账号权限：首次使用先在测试账号上验证行为，再接工作账号。

D 组涉及行内系统与账号（邮件、钉钉 / 飞书、浏览器登录）：凭据放密管系统，敏感数据不出行内环境，接入前先过部门信息安全规范。

4.4.5　E 组：doubao-* 办公金融套件精选

豆包系技能成套出现（本机 72 个），技能名即场景，覆盖建模、分析、公告、行业、合规与日常办公。下表挑研究与办公最常用的一批。

E 组与 B–D 组功能有重叠（建模、可视化、PDF 等），并存不冲突：套件内技能风格一致、成组更新，适合日常办公；跨套件的专项技能口径更细，适合出研究产出。

4.4.6　F 组：技能管理

技能多了就要运营：创建、发现、安装、审查、分发、改进，每个环节都有现成技能——用技能来管理技能。

元技能的好处是把「建技能」这件事本身标准化：新手照 4.6 的六步走，产出质量与熟手相差无几。

F 组技能本身就是 4.6 六步流程的工具化——先照着流程手工走一遍，再让元技能接手。

4.5Skill 与 MCP 怎么配合：ifind-finance-data 实例

MCP（Model Context Protocol，模型上下文协议）解决「接通数据源、真取数」；Skill 解决「怎么问、口径怎么对、什么不能做」。两者是分工关系，不是替代关系。本机的 ifind-finance-data 就是配套实例，它的 frontmatter 只声明触发条件：

---
name: ifind-finance-data
description: 当用户提到 iFinD 金融数据或请求其支持的数据操作时使用。
---

正文是一组使用规则，这类规则正是 Skill 的价值所在（以下为要点摘录）：

• 条件：只在 MCP 工具可用时使用；
• 选最窄的：挑能直接回答问题的那一个工具，不做多余调用；
• 忠实转述：保留工具返回的名称、标识、单位、时间与范围；
• 不编造：工具没返回的数据就说没有；
• 不绕路：不用 shell 或 HTTP 绕过连接器取数；
• 密钥安全：密钥不进提示与日志；
• 写操作确认：任何对外写操作先经确认。

这些规则看似约束，实为保险：把「智能体自由发挥」压缩进口径之内，出错时也能倒查——哪一步、调了哪个工具、按什么口径，规则里都有据可依。

该技能配套的连接器提供 10 个工具：get_stock_financials（财务）、get_stock_performance（行情）、get_stock_summary（估值摘要）、get_stock_shareholders（股本与股东）、get_risk_indicators（风险指标）、get_stock_info（公司档案）、get_stock_events（公司事件）、get_esg_data（ESG 数据）、search_stocks（检索）、stock_highfreq_quotes（高频行情）。

十个工具对应十类问题，选哪个由问题决定、不由习惯决定——这正是「选最窄的」规则的落地。

若连接器不可用，技能按规则应如实说明、不硬答——这正是「不编造数据」红线的日常意义：宁可少答，不可编数。技能与连接器还要成对维护：工具名变了，技能里的指引也得跟着改。

把一次真实的取数请求走一遍，看两层怎么咬合：

↺ 研究员核对产出后归档；发现的口径偏差回流修订技能

4.6怎么用、怎么写

个人使用门槛很低，四步走：

↺ 用的过程就是发现缺口的过程：哪里总要手工补救，哪里就缺一个技能

判断「用现成还是自建」：这件事第二次出现、且有行内口径要遵守——两条都满足才值得写成技能；只是个人偶发习惯，提示词模板更轻。

给每个技能指定维护人：谁最懂这件事，谁就是 owner；owner 调岗时技能随交接清单移交——否则一年后没人敢改，技能库会变成化石层。

4.7常见坑

上线前自查三问：description 一句话能否复述？正文第一步是否可直接执行？技能里有没有不该出现的密钥与数据？

把 4.4 的清单当菜单而非任务清单：不必都装，按自己的研究环节挑高频的两三个先用起来，用顺了再补——技能库是长出来的，不是一次配齐的。

5.1一句话定义：AI 世界的 USB-C

USB-C 的比喻对研究员还有一层实际含义：过去每接一个数据源，就要给每个智能体各写一份对接代码——N 个客户端配 M 个数据源，是 N×M 的定制成本；MCP 把它变成 N+M：数据方（或行内 IT）发布一个 MCP Server，所有支持协议的客户端（ZCode、WorkBuddy、Claude、Cursor 等，以各产品当前版本为准）即插即用。研究部门为什么要关心，浓缩成三条收益：

5.2架构与三类原语

MCP 的架构可以画成三层：研究员面对的智能体客户端、中间的协议层、底下的服务层。银行落地时，服务层再分成「行内自建（可信边界内，只读优先）」与「外部接入（经安全审查）」两块——这是图 5-1 与通用教程架构图最大的不同。

协议层之上，每个 MCP Server 向客户端暴露三类原语（primitives），对应三种使用方式，各有银行研究场景：

三类原语中日常最高频的是 Tools；Resources 管「原样引用」，Prompts 管「问法统一」，在行内落地阶段同样有价值。

5.3本机已接 MCP 实例

下表是本机智能体当前已接入、实际可用的 MCP 服务与工具节选——本章演示均出自这套真实配置，不是概念示意图。看完这张表，读者对「智能体连上了什么」应有具体体感。

行内落地时建议照此维护一张「服务—工具—口径」对照表，作为全组的取数地图，并纳入版本管理。

5.4真实演示：一句话取四大行估值与盈利

以下不是设想，是本机智能体接好同花顺 MCP 后的一次真实取数。对智能体的提问原话：

耗时对比：上述全过程约 10 秒；传统路径——打开终端、逐个找指标、导出、拼表、核对口径——约 10–20 分钟。MCP 改变的不是分析本身，而是「从提问到拿到可信底稿」的前置成本：底稿来得快，研究员的时间才能花在判断上。

这套提问可直接复用：换成股份行、城商行一组标的，或改要营业总收入、EPS(TTM)、单季度同比等财务指标，仍是同一句话的问法——本节的价值不在这一次结果，而在可复制的提问方式。

5.5银行怎么落地：三原则、三阶段

落地从配置开始。各客户端的 MCP 配置都是 mcpServers 的通用形式：本地服务写 command 启动一个子进程（stdio 传输），远程服务写 url 走 HTTP；密钥一律经环境变量注入，不写明文。

// mcpServers 配置（通用形式；各客户端文件位置略有差异）
{
  "mcpServers": {
    "bank-datalake": {
      "command": "python",
      "args": ["-m", "bank_mcp.server"],
      "env": { "DW_DSN": "${DW_DSN}" }
    },
    "hexin": {
      "type": "http",
      "url": "https://mcp.example.com/hexin",
      "headers": { "Authorization": "Bearer ${HEXIN_TOKEN}" }
    }
  }
}

代码 5-1　客户端接入配置：本地服务用 command + args（stdio），远程服务用 url + headers（HTTP）。ZCode 可经插件市场一键安装，WorkBuddy 提供界面可视化配置，其余客户端以各自文档为准。

行内自建服务也不复杂。用 Python 官方 SDK 的 FastMCP，一个装饰器就能把函数发布为工具——研究部只需定义「要什么指标、什么口径」，实现交 IT/数据部：

# bank_mcp/server.py —— 自建只读 MCP 服务最小示例（Python 官方 SDK 的 FastMCP）
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("bank-datalake")

@mcp.tool()
def get_nim(bank_code: str, period: str) -> dict:
    """查询某银行某报告期的净息差（%），只读。"""
    row = query_dw("select nim, source from bank_kpi where code=%s and period=%s",
                   bank_code, period)
    return {"bank_code": bank_code, "period": period, "nim": row.nim, "source": row.source}

if __name__ == "__main__":
    mcp.run()   # 默认 stdio 传输

代码 5-2　FastMCP 最小实现：函数 docstring 会作为工具说明交给模型；结果里带上 source 字段，让每次取数自带出处。写操作不要照此模式直接放开，须加确认与审计。

5.6Skill 与 MCP 的分工

第四节讲过 Skill（技能）是「教智能体怎么做」的说明书；本章的 MCP 是「让智能体能做到」的插口。两者常被混谈，下表把边界说清：

判断口诀：要新数据、要实时查询——接 MCP；要固定套路、要口径纪律——写 Skill；两样都要——组合使用，正是本章演示取数链路的形态。

5.7安全注意：接入前逐条对照

本章演示数据与工具名以本机 2026 年 10 月实际配置为准；协议细节与各客户端的支持范围，以 modelcontextprotocol.io 及各产品当前官方文档为准。

6.1为什么需要工作流：从「一次对话」到「一条流水线」

前几章的工具解决的是「单点能力」：对话解决问，智能体解决做，Skill 与 MCP 解决专业与拿数据。但银行研究的常态是流程——一条晨报要「抓信息、打分、取数、成稿、审核」，一个年度课题要「选题、文献、实证、成稿、评审」。这类任务交给一次对话会力不从心，交给工作流（Workflow）则步步可控：

6.2一个工作流长什么样：先读它的「身份证」

每条 ZCode 工作流就是一个 .dwf.ts 脚本文件，保存在 ~/.zcode/workflows/ 下。头部注释是它的「身份证」：干什么的（description）、什么时候用（whenToUse）、要什么参数（args）。下面是本机文献综述工作流的真实头部（节选）：

代码 6-1　literature-synthesis.dwf.ts 头部与中间产物类型（节选）

/* zcode-workflow
description: 文献综述③：六路并行检索（arXiv/ScienceDirect/国际综合/中文文献/顶刊语料econ-lit-search/文献计量openalex-api）
  → 去重聚类 → 分簇精读（方法/发现/局限/分歧）→ 撰写全面客观综述 → 引用核验修正，写入文档。
whenToUse: 需要全面客观的文献综述时：论文的文献章节、开题报告文献部分、或进入新领域摸底。
args:
  topic:  { type: string, required: true, description: 综述主题，如「数字普惠金融与家庭风险资产配置」 }
  years:  { type: string, default: 近十年，重点近三年 }
  outPath:{ type: string, default: literature-review.md }
*/
interface PaperHit { title: string; authors: string; year: string; venue: string; finding: string; link: string; }
interface Cluster  { name: string; papers: PaperHit[]; evolution: string; }

研究员不必读脚本体，读懂这段头部就够了：它声明了六路并行检索的来源（arXiv、ScienceDirect、国际综合、中文文献、顶刊语料 econ-lit-search、文献计量 openalex-api），用 interface 约定了每条命中文献必须带哪些字段，并对外只暴露三个参数。换主题只需换 args——「数字普惠金融与家庭风险资产配置」和「存款利率市场化与银行净息差」跑的是同一条流水线。

6.3本机十大学术研究工作流：从选题到终审

本机 ~/.zcode/workflows/ 已保存 10 条学术研究工作流，覆盖论文生产全链条；每条同时配一份 wf-* 通用技能指南（收入 wf-index 索引），供其他智能体按序执行。这十条对银行研究同样成立——把「论文」换成「课题报告」，环节一个不少：

十条工作流可以整条跑，也可以按名单独调用，取决于任务体量：

十条工作流不是十个孤岛，而是一条主线，其中③综述与④数据可并行推进：

↺ 衔接：①idea → ②架构 →（③综述 ‖ ④数据）→ ⑤实证 → ⑥图 → ⑦全文 → ⑧评审 → ⑨修改+回复信 → ⑩终审 →（ssrn-prep 预印本 / journal-advisor 选刊）

6.4设计一条银行研究晨报流水线（示例设计）

把上面机制移植到银行研究的日常：以「工作日晨报」为例给出一条示例设计。这不是已上线的系统，而是一张可直接照着搭的施工图——设计遵循三条原则：定时触发不等人、固定模板不自由发挥、人工门禁不代发；每一步都只用到前面章节讲过的工具（搜索技能、API 打分、MCP 取数、文档技能）：

旁证：本机已有若干定时自动化长期稳定运行——每小时数据备份、日历双向同步、定时报告推送——说明「定时 + 门禁 + 落盘」这一模式在长期无人值守下是可靠的。

6.5从「一次对话」到「流水线」：升级路径

不必一步到位。按任务复现频率与规模，分三级升级，每一级都有明确的风险控制：

判断标准很简单：一个月内要做第二遍的事，就值得技能化；要人守着做第三遍的事，就值得工作流化。

7.1一图总览

7.2怎么读这张图

7.3文字版（打印友好）

8.1三步走推进路径：会问 → 会做 → 成规模

推进分三步走：先让人人会问，再让研究组会做，最后把批量任务成规模并固化为流水线。落到日历上是四个阶段，每段设一个可检验的里程碑——没有里程碑的阶段不算完成：

四个阶段互相咬合：阶段一练出的提示词习惯喂给阶段二的规范技能，阶段三的抽检数据决定阶段四哪条流水线有资格上线。

8.2合规红线：六条底线，一条都不能碰

8.3一页速查表：我要做 X，用第几节的工具

把前七章压缩成一张表，贴在工位上即可；「第几节」列指向本讲义对应章节：

8.4常见问题

8.5结语与资源

本讲义所有示例与数据以各产品当前版本、官方文档及本行制度为准；工具在变，分层思维与红线意识不变。