Hermes + MCP：搭建真正可落地的 AI 开发工作流

前面三篇，我们已经把 Hermes 的工程框架一步步搭了起来。

第一篇，我们解决的是入口。

让 Agent 不再只是等待聊天，而是可以通过 Gateway、Cron、Webhook 持续接收任务。

第二篇，我们解决的是协作。

让多个 Agent 不再依赖群聊，而是通过 Kanban 进行任务分派、交接和追踪。

第三篇，我们解决的是角色。

用 Profile 把开发、研究、写作、运维拆成不同的工作身份，让每个 Agent 都拥有自己的配置、记忆、技能和工作目录。

到了这里，一个 Agent 系统已经有了：

入口；
任务；
协作；
角色。

但是，它还缺最后一层能力。

真正能够操作真实世界。

例如：

读取 GitHub Issue；
查询数据库；
修改项目代码；
调用浏览器；
访问企业知识库；
操作 Jira、Notion、飞书、Slack......

这些能力，都不是大模型本身拥有的。

它们需要一层统一的协议，把外部系统接入 Agent。

这就是 MCP（Model Context Protocol，模型上下文协议）。

不过，我并不建议一开始就安装几十个 MCP Server。

很多文章把 MCP 写成了：

"AI 插件市场。"

于是大家开始疯狂安装：

GitHub。

Filesystem。

Browser。

Database。

Docker。

Figma。

Jira。

Notion。

......

最后工具越来越多，真正稳定使用的却只有几个。

问题不是 MCP 不够。

而是没有工作流。

我的判断一直没有变：

MCP 不会让 Agent 更聪明，它只是把 Agent 的手伸进真实系统。真正决定 Agent 能不能落地的，仍然是工作流、权限边界和验收机制。

这一点，也是很多人在实践 Agent 时最容易忽略的地方。

一、MCP 接进来的，不是能力，而是真实世界

很多人第一次接触 MCP，都喜欢把它理解成：

"给 AI 安装插件。"

这种理解并没有错。

但还不够准确。

因为插件强调的是：

增加功能。

而 MCP 更重要的是：

连接真实系统。

真正的调用关系，其实更接近下面这样：

复制代码

用户任务
        │
        ▼
Hermes
        │
        ▼
Profile（谁来做）
        │
        ▼
Skill（怎么做）
        │
        ▼
MCP（调用哪些系统）
        │
        ▼
Git / 文件 / 数据库 / 浏览器 / API
        │
        ▼
返回证据或执行结果

这里最重要的是：

Hermes 并不是直接去操作 GitHub。

也不是直接去连接数据库。

它首先要回答三个问题：

第一，这件事应该交给谁？

Research Profile？

Coder Profile？

还是 Ops Profile？

第二，应该按照什么流程完成？

直接改代码？

还是先查资料、再分析、最后提交 Review？

这属于 Skill。

第三，需要调用哪些工具？

Git？

Filesystem？

Terminal？

Browser？

数据库？

这才属于 MCP。

所以，我一直建议把几个概念分开理解。

它们分别解决不同的问题：

组件	负责什么
Gateway	接收任务
Kanban	管理任务状态
Profile	决定谁执行
Skill	决定如何执行
MCP	提供外部能力
Approval	控制高风险操作

很多文章介绍 MCP 时，都会重点介绍：

能连接多少 Server。

但真正决定工程质量的，从来不是：

接了多少工具。

而是：

工具是否进入了一条稳定、可复用、可验收的工作流。

否则：

今天 GitHub。

明天 Browser。

后天数据库。

Agent 每次都临时决定该怎么调用。

看起来什么都会。

实际上每次都在重新思考。

这样的系统，很难长期稳定运行。

二、真正重要的，不是 MCP，而是任务链路

我建议不要从：

"我要接一个 GitHub MCP。"

开始。

而应该先问自己：

我要让 Agent 完成什么工作？

这是两个完全不同的思路。

举一个最真实的例子。

假设今天来了一个任务：

修复登录失败 Bug。

在人类团队里。

大家不会第一时间打开 GitHub。

而是先完成一整条工程流程。

通常包括：

阅读 Issue，确认问题和验收标准；
阅读认证模块、接口、历史提交和相关测试；
查找类似 Bug 是否出现过；
修改代码；
执行测试、Lint、Build；
输出变更说明；
发起 Code Review；
人工确认后合并。

注意。

这里没有任何一步写着：

"调用 MCP。"

因为：

MCP 从来不是目标。

它只是完成工作的工具。

真正值得设计的，是整条任务链路。

三、真正可复用的，不是 MCP，而是 Skill + MCP

很多人把 MCP 接好以后，使用方式还是这样：

复制代码

Prompt：
帮我检查一下这个 PR。

模型临场决定：
读什么文件？
调用哪些工具？
输出什么格式？

当然可以完成任务。

但问题是，每一次都像第一次执行。

模型需要重新判断步骤，工具调用顺序也可能不同，输出格式也容易变化。

对于个人来说影响不大。

但团队一旦开始复用，就会发现结果越来越不可控。

真正稳定的自动化，应该把工作方法固定下来。

更推荐的结构是：

复制代码

Skill
   │
固定工作流程
   │
按需调用 MCP
   │
执行验收
   │
输出标准交付物

例如，一个 Code Review Skill，可以直接规定：

复制代码

① 读取 PR 描述
② 查看 Git Diff
③ 分析影响文件
④ 检查测试覆盖
⑤ 输出 Review 报告

整个过程中，Agent 不需要自己决定"下一步该做什么"。

它只需要按照 Skill 定义的流程，去调用对应的 MCP。

例如：

复制代码

GitHub MCP
      │
读取 PR

Filesystem MCP
      │
读取源码

Terminal MCP
      │
运行测试

GitHub MCP
      │
发表评论

Skill 负责流程。

MCP 负责工具。

两者职责完全不同。

很多团队喜欢把所有步骤全部写进 Prompt。

短时间看很方便。

但 Prompt 越长，越难维护。

而 Skill 可以不断迭代。

例如：

Version 1：

复制代码

Review Diff

Version 2：

复制代码

Review Diff + 检查单元测试

Version 3：

复制代码

Review Diff + 检查测试 + 检查 Breaking Change + 检查安全风险

整个流程越来越成熟，而不是 Prompt 越来越长。

所以我更推荐一句话：

Prompt 解决一次任务，Skill 解决一类任务。

四、MCP 越多，Agent 越危险

很多人刚接触 MCP 时，都会经历一个阶段：

复制代码

GitHub 接一下
Filesystem 接一下
Docker 接一下
Kubernetes 接一下
数据库接一下
浏览器接一下
SSH 再接一下

看起来能力越来越强。

实际上，风险也在同步放大。

原因很简单：

MCP 提供的是"执行能力"，不是"判断能力"。

Agent 能调用的工具越多，意味着它能够影响的系统也越多。

所以我一直建议：

不要按照 Server 分类，而要按照 Profile 配置工具。

例如：

Researcher：

复制代码

Browser
Documentation
Filesystem(Read Only)
Search

Writer：

复制代码

Filesystem
Markdown
Image

Coder：

复制代码

GitHub

Filesystem

Terminal

Test Runner

Ops：

复制代码

SSH

Docker

Kubernetes

Prometheus

Grafana

不同角色，工具集合完全不同。

这和上一篇 Profile 的思路是一致的：

角色边界，同时也是权限边界。

否则，Profile 只是名字不同，实际上每个 Agent 都拥有同样大的权限。

真正需要遵循的是"最小权限原则（Principle of Least Privilege）"：

复制代码

需要什么工具

只开放什么工具

而不是：

复制代码

反正以后可能会用

全部打开

另外，还有一个经常被忽略的问题：

工具可信，不代表输入可信。

例如：

GitHub Issue

PR 描述

邮件

网页

Wiki

Slack 消息

Webhook Payload

这些都属于外部输入。

它们完全可能包含提示注入（Prompt Injection）或误导性内容。

因此，一个成熟的工作流通常还需要增加几层保护：

复制代码

限制工作目录

限制工具范围

只读优先

审批高风险操作

记录所有调用日志

真正保护 Agent 的，不是 Prompt 写得更长，而是系统边界设计得更清楚。

五、第一条 MCP 工作流，建议这样开始

很多人第一次使用 MCP，就希望让 Agent：

自动修改代码自动提交 PR 自动部署生产

这通常不是一个好的开始。

更稳妥的方式，是先跑通一条低风险、可验证的链路。

例如：

找出项目中所有与登录认证相关的代码。

首先确认 MCP 是否正常工作：

复制代码

hermes mcp list

hermes mcp test project_fs

然后，只允许 Agent 执行一个非常简单的任务：

复制代码

读取项目目录。

找出认证模块相关文件。

输出完整路径。

不要修改任何文件。

不要访问项目目录之外的路径。

整个任务，只需要验证三件事：

第一：

Server 是否连接成功。

第二：

Agent 是否只访问了允许的目录。

第三：

输出是否具有可复核性。

例如：

复制代码

src/auth/login.ts

src/auth/jwt.ts

src/middleware/auth.ts

而不是一句：

我已经分析了认证模块。

只有第一步稳定以后，再逐步放开能力：

复制代码

读取目录
      ↓
读取代码
      ↓
分析代码
      ↓
生成修改建议
      ↓
修改测试
      ↓
修改业务代码
      ↓
提交 PR

权限应该随着验证逐步扩大，而不是第一天就全部开放。

六、一个团队真正能落地的 Hermes + MCP 工作流

如果让我给一个开发团队设计第一条 AI 工作流，我不会一开始就追求"全自动开发"。

真正容易成功的，反而是一条职责明确、边界清晰、每一步都可以验收的流程。

整个流程可以拆成下面几层：

复制代码

需求入口
(Chat / Kanban / Webhook)
          │
          ▼
任务拆解（Kanban）
          │
          ▼
Profile 路由
Researcher / Coder / Reviewer
          │
          ▼
Skill 工作流
读 → 查 → 改 → 验 → 交付
          │
          ▼
MCP 工具执行
GitHub
Filesystem
Terminal
Browser
Documentation
          │
          ▼
验收
测试
Diff
日志
人工审批
          │
          ▼
交付
PR
报告
消息通知
知识库归档

如果把它画成一句话，就是：

Hermes 负责组织工作，MCP 负责连接工具，Agent 负责完成任务。

三者各司其职。

不要让 Hermes 去替代 Git。

也不要让 MCP 去管理任务。

更不要让 Prompt 同时承担角色、流程、工具和验收四件事情。

七、真正的重点，不是工具，而是工作流

很多团队刚接触 MCP 时，都会进入一个误区：

今天接 GitHub。
明天接 Browser。
后天接数据库。
再过两天接 Kubernetes。

Server 越装越多。

配置越来越复杂。

最后却发现：

Agent 还是不知道什么时候该调用工具；

不同 Agent 还是重复干同样的事情；

每次执行流程还是完全不同。

原因其实很简单。

工具只是能力。

真正决定结果稳定性的，是工作流。

例如同样都是修一个 Bug。

一个没有流程的 Agent：

复制代码

收到需求

↓

想到什么做什么

↓

随机调用工具

↓

输出结果

而一条成熟的工程流水线，会变成：

复制代码

收到需求

↓

Research
（收集事实）

↓

Coder
（实现修改）

↓

Review
（检查风险）

↓

Approval
（人工确认）

↓

Merge
（正式交付）

这里最大的变化，并不是工具数量。

而是：

每一步都有负责人。

每一步都有输入。

每一步都有输出。

每一步都可以恢复。

这才是真正的工程系统。

八、从"会聊天"到"会工作"，Hermes 补上了最后一层

如果回头看整个系列，你会发现，前几篇文章其实一直在回答同一个问题：

怎样让 AI 真正参与工作，而不是只参与聊天？

第一篇，我们解决的是入口。

复制代码

Cron
Webhook
Gateway

Agent 不再只是等待用户输入，而是能够主动接收任务。

第二篇，我们解决的是协作。

复制代码

Kanban
Task
Dispatcher

多个 Agent 不再靠聊天，而是围绕任务协同工作。

第三篇，我们解决的是角色边界。

复制代码

Profile

研究、开发、写作、运维开始拥有各自独立的工作身份。

而这一篇，我们补上了最后一层：

复制代码

MCP

它让 Agent 第一次真正能够接触代码、文件、终端、数据库以及各种业务系统。

直到这一刻，整套架构才真正闭环。

复制代码

入口
Gateway / Cron / Webhook
        │
        ▼
任务
Kanban
        │
        ▼
角色
Profile
        │
        ▼
工作方法
Skill
        │
        ▼
工具能力
MCP
        │
        ▼
外部系统
GitHub
Filesystem
Database
Terminal
Browser
        │
        ▼
交付
PR / 文档 / 消息 / API

这里最重要的一点是：

Hermes 并不是一个"更大的聊天机器人"。

它更像是一套 Agent Runtime（运行时）。

负责组织任务、管理角色、调度工具、控制权限，并最终完成一条完整的工作流。

MCP 只是把工具接进来。

真正让这些工具产生价值的，是 Hermes 提供的任务编排能力。

写在最后：不要把 MCP 当插件，把它当生产力接口

很多人第一次接触 MCP，关注的是：

今天又出了多少个 Server？

但真正值得关注的问题应该是：

我的团队，有没有一条值得自动化的工作流？

如果答案还没有，那么接再多 MCP，也只是增加了一份工具清单。

只有当任务流程、角色边界、验收标准都已经明确之后，MCP 才会真正发挥价值。

所以，我一直建议按照下面的顺序搭建：

复制代码

先确定工作流

↓

再拆 Profile

↓

再固化 Skill

↓

最后接入 MCP

不要反过来。

否则，工具越多，系统越复杂；权限越大，风险越高。

真正可落地的 AI 工程，不是让 Agent 能调用一百个工具，而是让它在明确的边界内，把一件事情持续、稳定、可验证地做完。