MCP协议：大模型安全调用外部API的工程化标准
1. 项目概述：MCP不是魔法，而是一把被磨亮的工程钥匙
你有没有试过让大模型直接调用银行账户余额接口？或者让它在不写一行代码的前提下，自动从飞书文档里提取会议纪要、生成周报、再发到钉钉群？我去年在给一家做智能投顾的客户做自动化方案时，就卡在这个环节——LLM明明能理解“查张三上月基金赎回记录”，却死活没法安全、稳定、可审计地把这句话翻译成对Kite API的实际调用。当时我们用了三套临时方案：硬编码API封装、自研轻量级插件桥接、甚至让模型输出curl命令再用shell执行……结果全翻车了：权限失控、参数校验缺失、错误反馈模糊、审计日志为零。直到今年初看到Alex Punnen那篇题为《MCP — The Golden Key for AI Automation》的实操笔记，我才真正意识到：问题从来不在模型能力，而在 交互契约的缺失 。
MCP，全称Model Context Protocol（模型上下文协议），它根本不是什么新模型或新API，而是一套 定义“大模型如何与外部世界安全握手”的通信规范 。你可以把它想象成USB-C接口——不是电源本身，但统一了充电器、显示器、硬盘和手机之间的物理连接方式与数据交换规则。它解决的不是“模型能不能干”，而是“模型该以什么格式说、系统该以什么格式听、双方怎么确认彼此没听错、出错了谁负责回滚”。关键词里的“Towards AI”不是平台背书，而是提醒你：这东西诞生于真实工程现场，不是实验室里的概念玩具。它已经被微软集成进Windows 11的Copilot Runtime底层，也被Google内部多个自动化项目列为默认交互层。我亲手在本地部署过MCP Server，用它驱动一个股票盯盘Agent调用Zerodha Kite（印度头部券商）的实时行情+下单接口，整个链路从用户提问到成交确认，全程无需人工干预，且每一步操作都可追溯、可重放、可限流。这不是PPT架构，是能跑通生产环境的协议栈。
它适合谁？如果你正在做以下任何一件事，MCP就不是“可选项”，而是“避坑刚需”：
- 正在用LangChain/LlamaIndex构建Agent，但发现工具调用逻辑越来越像意大利面条代码；
- 团队里既有算法工程师又有后端开发，每次加一个新API都要开三次会（需求对齐、参数协商、错误码映射）；
- 客户明确要求所有AI操作必须留痕、可审计、符合ISO 27001或等保三级；
- 你厌倦了每次模型升级都要重写一遍工具描述模板（function calling schema）。
MCP的核心价值，从来不是让模型更聪明，而是让系统更可靠。它把“AI能做什么”的权力，从模型的黑盒推理里，交还到工程师可配置、可验证、可运维的白盒协议中。
2. 协议设计原理与工程选型逻辑
2.1 为什么不是继续魔改Function Calling？
很多人第一反应是：“OpenAI的function calling不是已经能调API了吗？何必另起炉灶？” 这是个好问题，也是我踩过最深的坑。去年Q3，我们给某跨境电商SaaS做客服工单自动分派Agent，初期就用OpenAI原生function calling封装了内部CRM的create_ticket接口。表面看很丝滑：用户说“张三投诉物流延迟”，模型直接输出{“name”: “create_ticket”, “arguments”: {“customer_id”: “zhangsan”, “reason”: “logistics_delay”}}。但上线两周后，三个致命问题浮出水面：
- 参数漂移无感知 ：CRM后端把
reason字段从字符串枚举（"logistics_delay", "payment_failed"）悄悄升级为结构化对象，新增了sub_reason和severity。模型依旧输出老格式，接口返回500，但错误日志只显示“invalid JSON”，没人知道是协议失配； - 权限粒度粗暴 ：function calling的授权是“全有或全无”——要么允许调用整个CRM API，要么完全禁止。但我们的真实场景需要：客服Agent只能创建工单，不能修改订单状态，更不能删除用户数据；
- 上下文污染不可控 ：当用户连续追问“这个工单分配给谁了？他处理进度如何？”，模型会把前序调用的返回结果（比如工单ID）硬塞进后续请求的system prompt，导致token爆炸、响应变慢，且无法区分哪些是用户原始输入，哪些是系统注入的上下文。
MCP的设计哲学，就是直面这三个痛点。它不试图让模型“更懂业务”，而是 把业务规则、安全策略、审计要求，全部编译成机器可读、可验证、可版本化的协议描述 。它的核心组件只有三个，但每个都精准卡在传统方案的软肋上：
- MCP Server ：一个独立进程，负责接收模型发出的标准化请求（JSON-RPC 2.0 over HTTP/WebSocket），执行权限校验、参数验证、速率限制，并调用真实后端服务；
- MCP Client SDK ：提供各语言（Python/TypeScript/Java）的轻量级封装，让模型输出的“工具调用指令”变成严格符合协议的结构化消息，自动注入认证头、签名、trace_id；
- MCP Specification（规范文件） ：一份YAML/JSON格式的声明式配置，明确定义每个工具的名称、输入Schema（含必填项、枚举值、正则校验）、输出Schema、所需权限范围（如
crm:ticket:create）、调用成本（用于限流计费）、错误码映射表。
提示：MCP Specification不是文档，是运行时依赖。Server启动时加载它，Client生成请求时也必须引用同一份spec。这保证了“说”和“听”永远基于同一本词典，彻底消灭参数漂移。
2.2 为什么选择JSON-RPC 2.0而非REST或gRPC？
协议底层选型是工程落地的关键。MCP官方推荐JSON-RPC 2.0，而非更常见的RESTful API或性能更强的gRPC，背后有三重务实考量：
第一，兼容性压倒一切 。LLM的function calling输出本质是JSON对象，而JSON-RPC 2.0的request格式就是 {"jsonrpc": "2.0", "method": "tool_name", "params": {...}, "id": 123} 。这意味着：
- 模型无需学习新语法，只需把
function name换成method，arguments换成params； - 现有LangChain等框架的Tool抽象层，几乎不用改代码就能对接MCP Server（我们实测LangChain v0.1.16仅需替换3行初始化代码）；
- 所有HTTP客户端（curl、Postman、浏览器开发者工具）都能直接调试，降低团队学习成本。
第二，语义清晰，避免歧义 。RESTful的 POST /api/v1/tickets 可能对应创建、批量导入、状态更新等多种意图，靠HTTP动词和URL路径难以精确表达。而JSON-RPC的 method 字段强制要求命名唯一、语义单一，比如 crm.ticket.create 、 crm.ticket.update_status 、 crm.ticket.get_history ，天然支持细粒度权限控制。
第三，异步友好，适配AI长尾延迟 。gRPC虽快，但其强类型IDL（Protocol Buffers）要求前后端严格同步编译，而AI应用的工具迭代极快（今天加个飞书消息发送，明天加个Notion页面归档）。JSON-RPC的松耦合特性，让Server端可以动态加载新工具spec，Client端无需重新编译——只要JSON结构合法，就能通信。我们曾在线上环境热更新一个Zerodha行情订阅工具的spec（增加 interval 参数校验），整个过程零重启、零流量丢失。
注意：MCP不排斥gRPC。官方文档明确指出，MCP Server可作为gRPC网关，将JSON-RPC请求转换为gRPC调用。但 初始接入务必坚持JSON-RPC ——它让你用最少的改动，验证协议价值。别一上来就追求“技术先进”，先让第一个工具调用成功，比什么都重要。
2.3 授权体系为何绕不开OAuth 2.1 + PKCE？
MCP Authorization（授权）常被误解为“给模型发个token”，这是危险的认知偏差。真正的授权，是 在模型、用户、后端服务三方之间，建立可验证的信任链 。Alex Punnen文中用Zerodha Kite举例，恰恰揭示了金融级场景的刚性要求：
- 用户（投资者）必须明确授权Agent访问其账户；
- Agent（模型）不能拿到用户密码或长期token；
- 后端服务（Kite API）必须能验证该次调用确属用户本人授权，且权限范围可控（如只读行情，不可下单）；
MCP采用OAuth 2.1 + PKCE（Proof Key for Code Exchange）组合，不是跟风，而是经过血泪教训的选择。我们早期试过简化方案：让模型直接携带用户JWT token调用后端。结果在压力测试中暴露严重漏洞——当模型因超时重试多次，同一个JWT被并发使用，触发了Kite的异常登录检测，直接封禁了测试账号。
PKCE的精妙在于：它把“授权”拆解为两个原子操作：
- 前端授权码获取 ：用户点击“允许AI访问我的账户”后，浏览器跳转至Kite OAuth页面，用户登录授权，Kite返回一个短期有效的
code（有效期10分钟），且该code绑定一个由Client生成的code_verifier（随机字符串）； - 后端Token兑换 ：MCP Server拿到
code后，连同code_verifier一起向Kite的token endpoint发起请求，Kite校验code有效且code_verifier匹配，才发放最终的access_token。
这个设计确保：
code即使被截获也无法单独使用（缺少code_verifier）；access_token永远只在Server端生成和存储，模型全程接触不到敏感凭证；- 每次用户授权都产生新
code，杜绝重放攻击。
我们在Zerodha集成中，把 code_verifier 和 code_challenge （ code_verifier 的SHA256哈希）存入Redis，设置10分钟TTL，并与用户session ID绑定。实测在1000 QPS压力下，授权流程平均耗时87ms，失败率低于0.002%。这才是金融级可用的授权基座。
3. 实操全流程：从零部署MCP Server到驱动股票Agent
3.1 环境准备与最小可行部署
别被“协议”二字吓住。MCP Server的部署复杂度，远低于一个Spring Boot微服务。我用一台4核8G的阿里云ECS（Ubuntu 22.04）完成了全链路验证，全程命令行操作，无Docker依赖（当然你也可以用容器，但首次建议裸机部署，便于理解每一层）。
第一步：安装Python 3.11+与基础依赖
sudo apt update && sudo apt install -y python3.11 python3.11-venv python3.11-dev build-essential libpq-dev
python3.11 -m venv mcp_env
source mcp_env/bin/activate
pip install --upgrade pip
为什么坚持Python 3.11？MCP官方SDK的异步IO优化（尤其是WebSocket长连接）在3.11+的asyncio中表现最佳。我们对比过3.9/3.10/3.11，3.11在100并发连接下内存占用低23%，GC暂停时间减少40%。
第二步：克隆并安装MCP参考实现
MCP目前没有官方“一键安装包”，但社区维护的 mcp-server-python 是事实标准。它由FINOS（金融开源基金会）主导，Zerodha、Bloomberg等机构贡献代码。
git clone https://github.com/finos/mcp-server-python.git
cd mcp-server-python
pip install -e ".[dev]" # 安装为可编辑模式，便于后续调试
这个仓库包含：
mcp_server/：核心Server代码，基于FastAPI + WebSockets；examples/：开箱即用的工具示例（计算器、天气、Zerodha Kite）；spec/：MCP Specification的YAML模板和校验器。
第三步：配置你的第一个工具——本地计算器
这是验证协议通路的黄金步骤。进入 examples/calculator/ 目录，你会看到：
calculator_spec.yaml：声明计算器工具的协议；calculator_tool.py：实现加减乘除的Python函数；server.py：启动带计算器的MCP Server。
关键看 calculator_spec.yaml ：
tools:
- name: "calculator.add"
description: "Add two numbers"
input_schema:
type: "object"
properties:
a:
type: "number"
description: "First number"
b:
type: "number"
description: "Second number"
required: ["a", "b"]
output_schema:
type: "object"
properties:
result:
type: "number"
description: "Sum of a and b"
permissions: ["public"] # 公共权限，无需OAuth
cost: 1 # 调用成本，用于限流
注意 permissions: ["public"] ——这是MCP的权限最小化设计。计算器不需要用户授权，所以标记为public，Server会跳过OAuth校验。而后续的Zerodha工具，这里会写 ["zerodha:marketdata:read", "zerodha:orders:place"] 。
启动Server：
cd examples/calculator
python server.py --host 0.0.0.0 --port 8080
此时，Server已在 http://localhost:8080/mcp 监听。用curl测试：
curl -X POST http://localhost:8080/mcp \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "calculator.add",
"params": {"a": 5, "b": 3},
"id": 1
}'
预期返回：
{"jsonrpc":"2.0","result":{"result":8},"id":1}
恭喜！你已打通MCP的第一公里。 这个看似简单的计算器，验证了协议层、序列化、路由、执行、返回的全链路。所有后续复杂工具，不过是这个流程的放大版。
3.2 集成Zerodha Kite：金融级API的安全接入
Zerodha Kite是印度最大券商的API，其安全性设计堪称行业标杆（类似国内的中信证券信创API）。MCP对它的集成，是检验协议工业级能力的试金石。我们跳过官方文档里冗长的注册流程，直击工程要点。
第一步：申请Kite Developer Key
访问 Kite Developer Portal ，注册企业账号，创建新App，获取：
api_key（你的App唯一ID）api_secret（密钥，只显示一次，务必保存）redirect_uri（设为http://localhost:8000/callback，用于本地调试）
第二步：编写Zerodha工具Spec
在 examples/zerodha/ 下创建 zerodha_spec.yaml 。重点看权限与参数校验：
tools:
- name: "zerodha.marketdata.quote"
description: "Get real-time quote for given instrument tokens"
input_schema:
type: "object"
properties:
instrument_tokens:
type: "array"
items:
type: "integer"
minimum: 1
maximum: 999999999
minItems: 1
maxItems: 500
description: "List of instrument tokens (max 500)"
required: ["instrument_tokens"]
output_schema:
type: "object"
properties:
data:
type: "object"
description: "Quote data keyed by instrument token"
permissions: ["zerodha:marketdata:read"]
cost: 5 # 行情查询成本更高，用于限流
- name: "zerodha.orders.place"
description: "Place a new order"
input_schema:
type: "object"
properties:
variety:
type: "string"
enum: ["regular", "amo", "bo", "co"]
default: "regular"
exchange:
type: "string"
enum: ["NSE", "BSE", "NFO", "CDS", "MCX", "BCD"]
tradingsymbol:
type: "string"
minLength: 2
maxLength: 20
transaction_type:
type: "string"
enum: ["BUY", "SELL"]
quantity:
type: "integer"
minimum: 1
maximum: 1000000
product:
type: "string"
enum: ["MIS", "CNC", "NRML", "BO", "CO"]
order_type:
type: "string"
enum: ["MARKET", "LIMIT", "SL", "SL-M"]
price:
type: ["number", "null"]
minimum: 0.01
trigger_price:
type: ["number", "null"]
minimum: 0.01
required: ["variety", "exchange", "tradingsymbol", "transaction_type", "quantity", "product", "order_type"]
output_schema:
type: "object"
properties:
order_id:
type: "string"
description: "Unique order ID assigned by Kite"
permissions: ["zerodha:orders:place"]
cost: 20 # 下单成本最高，严防误操作
关键细节解析：
enum和minimum/maximum：Kite API对exchange、order_type等字段有严格枚举和数值范围，MCP Spec强制校验，避免模型胡乱猜测；minItems/maxItems：Kite行情接口单次最多查500个标的，Spec直接约束，超限请求在Server层就被拦截，不浪费一次网络调用；cost分级：行情查1次=5点，下单=20点，配合全局限流（如用户每分钟最多消耗100点），天然防刷单、防误操作。
第三步：实现OAuth 2.1授权流
在 zerodha_tool.py 中，我们封装了完整的PKCE流程：
import secrets
import hashlib
import base64
import redis
from fastapi import HTTPException
# 初始化Redis连接（用于存储code_verifier）
redis_client = redis.Redis(host='localhost', port=6379, db=0)
def generate_pkce_codes():
"""生成PKCE code_verifier和code_challenge"""
code_verifier = secrets.token_urlsafe(32)
code_challenge = base64.urlsafe_b64encode(
hashlib.sha256(code_verifier.encode()).digest()
).decode().rstrip('=')
return code_verifier, code_challenge
def store_code_verifier(user_id: str, code_verifier: str, expires_in: int = 600):
"""存储code_verifier，绑定user_id"""
key = f"pkce:{user_id}"
redis_client.setex(key, expires_in, code_verifier)
def verify_code_verifier(user_id: str, code_verifier: str) -> bool:
"""校验code_verifier是否匹配"""
key = f"pkce:{user_id}"
stored = redis_client.get(key)
return stored and stored.decode() == code_verifier
当用户首次请求 zerodha.marketdata.quote 时，Server检测到 zerodha:marketdata:read 权限未授予，会返回一个标准MCP错误：
{
"jsonrpc": "2.0",
"error": {
"code": -32001,
"message": "Permission denied",
"data": {
"auth_url": "https://kite.trade/connect/login?v=3&api_key=your_api_key&code_challenge=xxx&code_challenge_method=S256&redirect_uri=http%3A%2F%2Flocalhost%3A8000%2Fcallback"
}
},
"id": 1
}
前端（如Web UI）捕获此错误，跳转至 auth_url ，用户完成Kite授权后，Kite回调 redirect_uri ，我们的回调接口解析 code ，调用 verify_code_verifier ，再向Kite token endpoint发起兑换，最终将 access_token 存入Redis（key为 token:{user_id} ），并设置24小时TTL。
第四步：执行工具调用
当模型输出：
{
"jsonrpc": "2.0",
"method": "zerodha.marketdata.quote",
"params": {"instrument_tokens": [256265]},
"id": 2
}
Server收到后：
- 校验
method存在且params符合zerodha_spec.yaml； - 检查当前用户（通过JWT或session ID识别）是否拥有
zerodha:marketdata:read权限； - 从Redis读取
token:{user_id}，若不存在或过期，返回auth_url错误； - 构造Kite API请求：
GET https://api.kite.trade/v3/market/quote?i=256265&api_key=your_api_key，带上Authorization: Bearer <access_token>； - 将Kite原始响应透传给模型（MCP不篡改业务数据，只做协议转换）。
我们实测：从用户点击授权，到模型拿到Reliance Industries（代码256265）实时行情，端到端耗时<1.2秒（含网络RTT）。而下单操作，因涉及风控引擎校验，平均3.8秒，但 100%保证原子性 ——如果Kite返回“资金不足”，Server绝不向前端返回“下单成功”，而是透传Kite的完整错误码（如 OrderMarginError ），模型可根据此信息生成自然语言提示：“张三先生，您的账户余额不足，无法买入Reliance，请充值后再试”。
3.3 构建端到端Agent：用MCP驱动股票盯盘机器人
现在，把计算器和Zerodha串起来，打造一个真实可用的Agent。我们不依赖LangChain，用纯Python手写核心逻辑，凸显MCP的轻量本质。
Agent主程序（agent.py）结构：
import asyncio
import json
import httpx
from typing import Dict, Any
class StockWatcherAgent:
def __init__(self, mcp_server_url: str = "http://localhost:8080/mcp"):
self.mcp_url = mcp_server_url
self.client = httpx.AsyncClient()
async def run(self, user_query: str) -> str:
# Step 1: 模型理解用户意图（此处用本地小模型模拟，实际可接Llama 3）
intent = self._parse_intent(user_query)
if intent["action"] == "get_quote":
# Step 2: 调用MCP获取行情
quote_result = await self._call_mcp("zerodha.marketdata.quote",
{"instrument_tokens": intent["tokens"]})
return f"当前{intent['symbol']}股价为{quote_result['data'][str(intent['tokens'][0])]['last_price']}"
elif intent["action"] == "place_order":
# Step 3: 调用MCP下单
order_result = await self._call_mcp("zerodha.orders.place",
intent["order_params"])
return f"已提交订单，ID为{order_result['order_id']}"
async def _call_mcp(self, method: str, params: Dict[str, Any]) -> Dict[str, Any]:
payload = {
"jsonrpc": "2.0",
"method": method,
"params": params,
"id": self._gen_id()
}
response = await self.client.post(self.mcp_url, json=payload)
result = response.json()
if "error" in result:
raise Exception(f"MCP Error: {result['error']['message']}")
return result["result"]
def _parse_intent(self, query: str) -> Dict[str, Any]:
# 简化版意图识别（生产环境应接专用NLU模型）
if "price" in query or "quote" in query:
symbol = "RELIANCE" if "Reliance" in query else "TCS"
token_map = {"RELIANCE": 256265, "TCS": 1270529}
return {"action": "get_quote", "symbol": symbol, "tokens": [token_map[symbol]]}
elif "buy" in query or "sell" in query:
return {"action": "place_order", "order_params": {
"variety": "regular",
"exchange": "NSE",
"tradingsymbol": "RELIANCE",
"transaction_type": "BUY" if "buy" in query else "SELL",
"quantity": 1,
"product": "MIS",
"order_type": "MARKET"
}}
else:
return {"action": "unknown"}
启动Agent并测试：
python agent.py
# 在另一个终端，模拟用户提问：
echo "查一下Reliance Industries的当前股价" | python -c "
import sys; from agent import StockWatcherAgent;
agent = StockWatcherAgent();
import asyncio; print(asyncio.run(agent.run(sys.stdin.read().strip())))"
# 输出："当前RELIANCE股价为2845.55"
这就是MCP的威力： Agent代码里没有一行Kite API调用，没有OAuth逻辑，没有参数拼接。所有复杂性都被MCP Server封装。你只需关注业务意图（ get_quote , place_order ），协议层自动处理安全、校验、重试、限流。当我们把 _parse_intent 换成真实的Llama 3-8B量化模型（Ollama部署），整个Agent的响应延迟稳定在1.8~2.3秒，99分位P99<3.5秒，完全满足交易场景的实时性要求。
4. 常见问题与实战排障手册
4.1 权限校验失败：不是“没授权”，而是“授权没生效”
现象： 用户已完成Kite授权，但调用 zerodha.marketdata.quote 仍返回 Permission denied 错误。
排查路径（按优先级排序）：
-
检查Redis中
token:{user_id}是否存在redis-cli GET "token:abc123" # abc123是你的测试用户ID如果返回
(nil)，说明OAuth兑换流程未执行或失败。查看Server日志中是否有Failed to exchange code for token字样。常见原因：code_verifier不匹配（大小写、padding）、redirect_uri不一致（注意URL编码）、Kite的api_secret错误。 -
检查
token:{user_id}的TTL是否过期redis-cli TTL "token:abc123"如果返回
-2（key不存在）或-1（永不过期，但Kite token本身24小时过期），需重新走授权流程。MCP不自动刷新token，这是设计使然——金融场景要求显式授权。 -
检查MCP Spec中
permissions字段是否拼写错误
在zerodha_spec.yaml中，permissions: ["zerodha:marketdata:read"]必须与Server权限检查逻辑中的字符串 完全一致 （包括大小写、冒号位置）。我们曾因把zerodha:marketdata:read写成zerodha:market_data:read，耗费3小时排查。
实操心得：在Server启动时，打印所有加载的工具及其权限列表。我们在
server.py中加入：for tool in spec.tools: print(f"Loaded tool '{tool.name}' with permissions {tool.permissions}")启动日志一目了然，避免配置遗漏。
4.2 参数校验通过，但Kite返回400 Bad Request
现象： MCP Server日志显示 Validated params for zerodha.orders.place ，但调用Kite后返回 {"status":"error","message":"Invalid instrument token","data":null} 。
根因分析： MCP的Schema校验只保证JSON结构合法，不保证业务语义正确。 instrument_token 在Spec中定义为 integer ，但Kite要求该数字必须是其数据库中存在的有效ID。
解决方案：
- 前置缓存校验 ：在
zerodha_tool.py中，维护一个内存字典valid_instruments = {256265: "RELIANCE", 1270529: "TCS", ...}，在调用Kite前先查字典。 - 动态同步机制 ：每天凌晨，Agent自动调用Kite的
/instruments接口，下载最新标的列表，更新内存字典（生产环境建议用Redis Hash存储）。 - 优雅降级 ：当Kite返回
Invalid instrument token时，Server不抛出500，而是返回标准MCP错误：
模型可据此生成提示：“您查询的标的未找到，建议尝试RELIANCE或TCS”。{ "jsonrpc": "2.0", "error": { "code": -32002, "message": "Instrument not found", "data": {"suggested_symbols": ["RELIANCE", "TCS"]} }, "id": 123 }
4.3 高并发下MCP Server响应延迟飙升
现象： 单用户调用正常（<100ms），但100并发时，P95延迟跳至2.1秒，大量请求超时。
性能瓶颈定位（三步法）：
-
确认是CPU还是IO瓶颈 ：
# 查看CPU使用率 top -b -n1 | grep "mcp_server" # 查看网络连接数 ss -tn state established | grep ":8080" | wc -l我们实测发现，CPU使用率<40%，但
ss显示连接数卡在1024（Linux默认net.core.somaxconn值），说明是内核连接队列满。 -
调整内核参数 ：
echo 'net.core.somaxconn = 65535' | sudo tee -a /etc/sysctl.conf echo 'net.ipv4.tcp_max_syn_backlog = 65535' | sudo tee -a /etc/sysctl.conf sudo sysctl -p -
优化Server异步配置 ：
FastAPI默认的Uvicorn workers数为1，需显式增加：# 启动时指定workers uvicorn server:app --host 0.0.0.0 --port 8080 --workers 4 --limit-concurrency 1000--limit-concurrency 1000防止单个worker被长连接占满。
终极优化：引入连接池
Kite API的HTTP客户端（ httpx.AsyncClient ）默认不复用连接。我们在 zerodha_tool.py 中创建全局连接池：
# 全局连接池，复用TCP连接
kite_client = httpx.AsyncClient(
limits=httpx.Limits(max_connections=100, max_keepalive_connections=20),
timeout=httpx.Timeout(10.0, connect=5.0)
)
优化后，100并发P95延迟降至186ms，吞吐量提升4.2倍。
4.4 模型反复调用同一工具，陷入死循环
现象： 用户问“Reliance股价多少”，模型调用 zerodha.marketdata.quote ，得到结果后，又立刻调用一次，如此循环。
原因： 模型的System Prompt中，未明确禁止重复调用。LLM倾向于“多问几次确保准确”，尤其在金融场景下。
MCP层面的防护：
- 请求去重（Request Deduplication） ：在MCP Server中，为每个
method+params生成MD5哈希，10秒内相同哈希的请求直接返回缓存结果（需开启Redis缓存）。 - 调用频率限制（Rate Limiting） ：在
zerodha_spec.yaml中为高成本工具添加rate_limit字段：
Server会在Redis中记录rate_limit: window_seconds: 60 max_calls: 5rl:zerodha:orders:place:{user_id}的调用次数，超限则返回{"error": {"code": -32003, "message": "Rate limit exceeded"}}。
注意：频率限制必须基于
user_id，而非IP。因为一个用户可能通过多个设备访问Agent。
4.5 审计日志缺失，无法满足合规要求
现象： 客户要求提供“每一次AI下单的完整操作日志，包括用户ID、时间戳、调用工具、输入参数、返回结果、操作人IP”。
MCP原生支持审计 ：Server内置 audit_logger 中间件。只需在启动时启用：
from mcp_server.audit import AuditLogger
audit_logger = AuditLogger(
backend="redis", # 或 "file", "elasticsearch"
redis_url="redis://localhost:6379/1"
)
# 在FastAPI app中挂载
app.middleware("http")(audit_logger.middleware)
每条日志格式为：
{
"timestamp":
欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！
更多推荐
12
0- 0
已为社区贡献2条内容
所有评论(0)