说实话，很多企业上了AI工具之后发现一个问题：AI很聪明，但不懂你的业务。

你问它"公司差旅报销标准是多少"，它给你搬出一堆通用政策。为什么？因为它没接入你们的知识库。

2025年11月，Anthropic推出的MCP协议（Model Context Protocol）正式移交Linux Foundation治理（来源：jishuzhan.net），这意味着MCP正在从"某个厂商的私有协议"变成行业标准。对开发者来说，这是一个信号：基于MCP做知识库对接，是当前最值得投入的技术方向。

本文以WorkBuddy的MCP能力为例，手把手走一遍从零搭建到实际调用的完整链路。

MCP是什么，为什么值得关注

MCP全称Model Context Protocol，翻译过来就是"模型上下文协议"。

打个比方：传统模式下，每个AI应用要接外部数据源（数据库、API、文件系统），都得单独写适配代码。A模型一套，B模型又一套。MCP做的事就是定义一个标准接口——只要数据源实现了MCP Server，任何支持MCP的Client都能直接调用。

核心架构分三层：

• Client层：AI应用端（如WorkBuddy、Claude Desktop）
• Server层：数据源适配层（数据库、知识库、API等）
• Transport层：通信机制（stdio或streamable-http）

根据MCP中文站(mcpcn.com)的资料，截至2026年5月，社区已贡献200+官方和第三方Server，覆盖文件系统、数据库、Slack、GitHub等常见企业数据源。

实战场景：企业知识库对接

假设这样一个实际需求：

某企业使用飞书/腾讯文档管理产品文档和FAQ，希望AI助手在回答员工问题时能自动检索这些文档，而不是靠训练时的通用知识。

第一步：搭建MCP Server

我们用Python的FastMCP框架来搭（这是目前社区最活跃的MCP开发框架之一）：

# knowledge_server.py
from fastmcp import FastMCP

mcp = FastMCP("enterprise-knowledge")

@mcp.tool()
def search_docs(query: str) -> str:
    """
    搜索企业知识库文档
    参数:
        query: 搜索关键词
    返回: 匹配的文档内容摘要
    """
    # 这里替换为实际的文档检索逻辑
    # 可以是向量数据库搜索、全文索引、或API调用
    documents = [
        {"title": "差旅报销政策", "content": "一线城市住宿标准500元/天..."},
        {"title": "IT设备申领流程", "content": "新员工入职可申请笔记本一台..."},
    ]
    
    results = [doc for doc in documents if query in doc["content"]]
    if not results:
        return f"未找到与'{query}'相关的内容"
    
    return "\n".join([f"- {r['title']}: {r['content'][:100]}" for r in results[:3]])

if __name__ == "__main__":
    mcp.run()

关键点说明：

1. @mcp.tool()装饰器：把普通函数注册为MCP可调用的工具
2. docstring是必须的：AI会根据函数描述决定什么时候调用这个工具
3. 返回值保持文本格式：MCP tool返回的是字符串，结构化数据建议用JSON字符串

第二步：配置Client端连接

在WorkBuddy中配置MCP连接，需要在mcp.json中添加Server配置：

{
  "mcpServers": {
    "enterprise-knowledge": {
      "command": "python",
      "args": ["path/to/knowledge_server.py"],
      "env": {
        "DOC_API_KEY": "your-api-key",
        "DOC_BASE_URL": "https://your-docs-api.example.com"
      }
    }
  }
}

配置项含义：

字段	说明
command	启动Server的可执行命令
args	命令参数列表
env	环境变量（放密钥等敏感信息）

第三步：实际调用效果对比

配置完成后，同样的问题，回答质量差异明显：

配置前：

用户：公司差旅报销标准是多少？
AI：一般企业的差旅报销标准因公司而异，通常包括交通费、住宿费和餐补...

配置后：

用户：公司差旅报销？
AI：（调用search_docs工具）根据公司知识库，一线城市住宿标准500元/天，交通费凭票实报实销，需部门经理审批。完整政策见《差旅报销政策v3.2》。

区别在于：后者是基于企业真实文档给出的精准回答，而不是泛泛而谈。

进阶：多数据源聚合

实际企业场景往往不止一个数据源。MCP支持同时配置多个Server：

{
  "mcpServers": {
    "knowledge-base": {
      "command": "python", "args": ["doc_server.py"]
    },
    "crm-data": {
      "command": "python", "args": ["crm_server.py"]  
    },
    "calendar": {
      "command": "node", "args": ["calendar_server.js"]
    }
  }
}

WorkBuddy会自动加载所有可用工具，AI根据问题类型智能选择调用哪个数据源的接口。这个过程对用户完全透明——你只管问问题，系统自己判断该查哪里。

几个踩过的坑

坑1：Server启动太慢导致超时

如果知识库Server初始化需要加载大量数据（比如建索引），Client端可能超时。解决办法是在Server内部做懒加载，或者增加Client的超时配置。

坑2：返回内容过长

MCP tool的返回值会被塞进上下文窗口。如果一次返回几万字，很快token就爆了。建议做截断处理，只返回最相关的部分，让AI按需追问更多细节。

坑3：权限控制缺失

不是所有人都应该能搜到所有文档。在Server层面要做身份验证，根据当前用户的角色过滤可访问的文档范围。可以把用户身份通过环境变量传递给Server。

def search_docs(query: str, user_role: str = "guest") -> str:
    # 根据角色限制搜索范围
    allowed_collections = ROLE_DOC_MAP.get(user_role, [])
    # ...

小结

MCP协议解决的核心问题是AI应用与外部数据源的标准化对接。对企业来说，这意味着：

• 不用为每个AI产品单独写集成代码
• 知识库、CRM、OA等系统可以一次性接入
• 切换AI后端时（比如从GPT换到DeepSeek），前端业务逻辑不用动

目前MCP生态还在快速发展期，Agentic AI Foundation接管后的标准化进程值得持续关注。对于有企业知识库对接需求的团队，现在入场正是时候。

参考链接

• MCP中文技术社区：https://mcpcn.com/
• FastMCP官方文档：https://fastmcp.dev/
• Agentic AI Foundation（Linux Foundation）：https://www.linuxfoundation.org/agentic-ai-foundation/

公司简介

上海华万通信科技有限公司，专注为企业提供腾讯系SaaS产品的一站式选型与集成服务，包括腾讯会议、企业微信、腾讯电子签等。欢迎联系我们了解更多。