Go + MCP 实战探索：聚焦业务层，打造能“办业务”的AI智能体

大家好，我是地鼠哥。

上一篇文章发出后，收到了大家非常多的反馈和投票，非常感谢！果然，“企业级 RAG 知识库与业务办理 Agent”这个方向获得了最高的关注度。大家和我一样，都希望AI不止于“聊天”，更能“办事”，产生实际的业务价值。

这也坚定了我的想法：就从这个最硬核、最具商业潜力的方向入手，搞一次真正的实战。

所以，这篇续作不再停留在“构想”，我会把自己这几天的深入设计、技术选型思考以及踩到的第一个“坑”分享出来。目标是打造一个 “既能回答，又能办事” 的双模企业AI智能体。

方向再聚焦：从“双模”到“三层架构”

上次我提到了“Read”和“Write”两种模式。经过细化，我认为一个完整的企业级智能体应该具备三层能力，就像一个有经验的员工：

1. 知识层（Know Everything）：快速学习并精准回答公司内部的所有文档、政策、流程问题。这是基础的“Read”能力。
2. 洞察层（Analyze Everything）：不仅能查，还能分析。连接公司数据源（脱敏后），对业务数据进行简单的趋势解读、异常定位。这是“高级Read”。
3. 执行层（Do Something）：在安全、合规的强约束下，执行定义好的业务流程。例如：提交审批、创建工单、查询订单状态。这是核心的“Write”能力。

用Go来实现，优势就在于：用高并发处理海量文档解析（知识层），用高效的内存和网络IO处理实时数据分析（洞察层），用健壮的错误处理和链路追踪来保障业务流程执行（执行层）的稳定。

技术蓝图与核心挑战

1. 整体架构设计

我们的智能体将作为一个 MCP Server 来构建，通过标准协议与 Cursor/Claude Desktop 等客户端通信。架构核心如下：

• MCP Server 框架：直接基于 Anthropic 官方的 go-mcp SDK 开发，省去协议层面的烦恼。
• 决策路由：这是大脑。需要解析用户意图，判断该调用哪个（或哪几个）工具。初期计划用一套规则引擎+意图关键词来实现，后期可引入一个轻量级分类模型。

2. 知识层实现：用Go暴力破解文档处理

挑战：企业文档格式杂乱（Word, PDF, PPT, Excel, 网页），Python的解析库虽多，但在处理十万级文档时，速度和内存是瓶颈。

Go的解法：

• 并发解析流水线：利用 goroutine + channel，构建一个多阶段并发处理流水线。
  • 阶段一：文件分类与原始文本提取（使用如 docconv, unipdf 等纯Go库）。
  • 阶段二：文本清洗、分块（strings, regexp 标准库足以，快）。
  • 阶段三：向量化嵌入（调用外部Embedding API，Go的HTTP客户端并发能力强）。
  • 阶段四：批量写入向量数据库（如 weaviate-go 或 qdrant-go 客户端）。
• 收益：利用Go的并发原语，我们可以将CPU密集型的解析、IO密集型的网络请求和数据库写入高效重叠，实现近乎线性增长的文档处理速度。这是Python的异步编程模型难以比拟的。

3. 执行层实现：安全与能力的平衡

这是最大的挑战，也是价值所在。 让AI调用业务接口，我们必须解决：

• 身份与权限：AI操作背后必须是具体的员工身份。我们计划通过MCP连接时的上下文，传递员工的加密Token。Server端解密后，用该身份调用业务接口，并做权限校验。
• 操作确认：对于高风险操作（如“审批通过”、“删除数据”），必须在执行前向用户明确请求二次确认。MCP Tool 可以返回一个特殊的 confirmationRequired 标记，引导客户端弹出确认框。
• 参数标准化与验证：AI生成的参数可能不标准。我们需要为每个业务Tool编写严格的参数校验和转换逻辑（比如，将“下周一”转换为具体的日期格式）。这部分代码虽繁琐，但Go的静态类型和结构体Tag（如 validate:"required"）能让它非常清晰健壮。

第一个实战坑：MCP 工具的动态注册

在原型开发阶段，我立刻遇到了一个棘手的问题。我们的业务工具（比如“请假申请”、“数据查询”）可能会经常变化，难道每次都要修改代码、重启Server吗？

解决方案：基于配置文件的动态加载。

1. 我为每个“业务办理能力”定义了一个 YAML 配置文件，描述其名称、参数模式、对应的后端API端点以及权限要求。
2. Server启动时，扫描指定目录，读取所有YAML配置。
3. 利用Go的 text/template 包和 reflect 机制，动态生成符合MCP规范的Tool Definition，并注册到Server中。

这样一来，新增一个业务功能，只需要编写一个YAML配置文件和一个处理函数，无需触动核心框架。这为未来的“低代码”配置化打下了基础。

# tool_apply_leave.yaml
name:"apply_leave"
description:"提交请假申请"
parameters:
-name:"type"
    type:"string"
    enum:["annual","sick","personal"]
    description:"请假类型"
-name:"days"
    type:"number"
    description:"请假天数"
backend:
endpoint:"http://hr-service/v1/leave/apply"
method:"POST"
auth_required:true
confirmation_prompt:"确认提交请假申请吗？"

下一步行动路线图

1. Week 1-2: 搭建最小可行产品（MVP）
   • 完成MCP Server基础骨架与动态工具加载。
   • 实现一个最简单的“知识库问答”工具（连接测试向量库）。
   • 实现一个最安全的“业务办理”工具（如：查询个人假期余额）。
2. Week 3-4: 核心能力深化
   • 集成企业微信/钉钉身份验证。
   • 构建完整的文档并发处理流水线。
   • 实现基本的意图路由规则引擎。
3. Week 5+: 内部试点与迭代
   • 在公司内部找一个试点部门（如IT支持或HR），接入真实的文档和1-2个业务流程。
   • 收集反馈，重点优化意图识别的准确率和操作流程的流畅度。

这条路肯定不轻松，尤其是执行层的安全和可靠性设计，需要投入大量精力。但一想到能做出一个真正“能干活的AI同事”，就觉得格外有动力。

你对这个“业务办理Agent”的具体实现有什么想法吗？或者，如果你来设计，最希望它优先处理你们公司的哪个业务流程？ 欢迎在评论区继续交流，你们的建议会直接影响到我的开发优先级！