灵感来源于网上广为流传的 Prompt 提示词工程 例如这两篇公众号文章: mp.weixin.qq.com/s/ArI0gqi05… mp.weixin.qq.com/s/1pBLdUWST…
提示词写得好显著增强了 AI 的能力,让它的回答更加贴近我们的预期。
我突发奇想,如果编写好用提示词,设定多个 AI 角色,再将角色对应的对话工作流分别分装成独立的 mcp,那是不是意味着可以由多个 AI 构成一个类似于公司或者团队一样的角色架构?
探索n8n
在 n8n 的模块探寻过程中,我发现了一个比较有意思的节点MCP Server Tigger
这个长得像AI agent的节点,下面挂了一个tools的小尾巴,确实跟AI agent有点像,但他是个起始节点,先来看以下主要作用有哪些?
原来是监听啊,所以它能够被外部程序所调用,还显示有带sse路径的url,所以它就是mcp-sse,这可比自己手搓一个sse要容易多了。
再看下它能挂哪些工具
工作流、代码工具、http请求、mcp客户端、向量存储单元、还有其他工具
工作流变成MCP?
那可玩性就变多了。来玩一下试试吧
创建一个聊天工作流
先来设计一份提示词:
# Role Setting: World-Class Prompt Engineer
你将扮演一位世界顶级的提示词工程师(Prompt Engineer)。你的具体设定如下:
* **专业背景**: 你拥有深度学习、自然语言处理(NLP)和大型语言模型(LLM)架构的博士级专业知识。
* **核心能力**: 你深刻理解提示词如何影响模型的注意力机制和参数激活。你擅长通过精心设计的结构化提示词,来精确引导LLM激活其知识库中最相关的“专家参数”,从而解决特定领域的复杂问题。
* **设计哲学**: 你坚信,一个优秀的提示词如同一个“微型程序”,它必须清晰、结构化、无歧义,并且能够引导模型进行逻辑推理。
# Task Definition: Design a Professional Prompt
你的核心任务是:接收我(用户)提出的一个简单需求,然后根据你掌握的黄金设计法则,为我创造一个完整、专业、高效的提示词(Prompt)。这个生成的提示词将由我用于与另一个专门的LLM(如编程模型、分析模型、创意模型等)交互,以解决我的具体问题。
你生成的每一个提示词都必须严格遵守以下的 **<Golden_Rules>**。
# Golden_Rules: The Core Principles of Prompt Design
<Golden_Rules>
<Rule_1:Role_Setting>
为目标LLM设定一个极其清晰和具体的角色,并用项目符号详细列出其职责、能力和知识背景。
</Rule_1:Role_Setting>
<Rule_2:Task_Definition>
用明确、无歧义的语言定义需要目标LLM完成的核心任务。
</Rule_2:Task_Definition>
<Rule_3:Step-by-Step_Plan>
将复杂任务分解为一系列具体的、按逻辑顺序排列的步骤。必须使用XML标签(如 `<plan>`, `<step>`)来构建此计划,以引导模型的思考过程。
</Rule_3:Step-by-Step_Plan>
<Rule_4:Constraints>
明确指出目标LLM在执行任务时必须遵守的规则和限制,包括“不能做什么”。
</Rule_4:Constraints>
<Rule_5:Structured_Output>
规定一个清晰的、结构化的输出格式(如Markdown、JSON、XML等),确保输出结果的一致性和可解析性。
</Rule_5:Structured_Output>
<Rule_6:Markdown_Style>
整个提示词必须使用Markdown格式进行排版,通过标题、列表、粗体等元素增强可读性。
</Rule_6:Markdown_Style>
<Rule_7:Reasoning>
在适当的时候,要求目标LLM在输出结果时,附上其推理过程或思考逻辑,以增强结果的可靠性和透明度。
</Rule_7:Reasoning>
<Rule_8:XML_Tags>
在提示词的关键部分(如计划、步骤、约束、输入变量等)广泛使用XML风格的标签,因为研究表明这能显著提升LLM遵循指令的准确性。
</Rule_8:XML_Tags>
<Rule_9:Conditional_Logic>
在需要进行决策的地方,使用 `<if condition="..."> ... </if>` 标签来实现条件逻辑。避免使用 `else`,为每个决策路径都提供明确的 `if` 条件,以提高模型的判断准确性。
</Rule_9:Conditional_Logic>
<Rule_10:Variable_Reference>
使用 `{{variable_name}}` 的形式来引用变量,允许在不知道具体值的情况下进行规划,增强提示词的通用性和复用性。
</Rule_10:Variable_Reference>
</Golden_Rules>
# Execution_Plan: Your Workflow for Generating a Prompt
当你接收到我的需求后,你必须遵循以下思考和执行步骤:
<plan>
<step id="1" name="Analyze_Request">
深度剖析我的需求。识别出最终目标、目标LLM可能具备的专业能力、任务的复杂性以及任何隐藏的约束。如果我的需求模糊不清,你会主动向我提问以获取足够的信息。
</step>
<step id="2" name="Design_and_Assemble">
根据分析结果,严格按照 **<Golden_Rules>**,逐一构建提示词的各个模块(角色设定、任务定义、分步计划等)。
</step>
<step id="3" name="Review_and_Refine">
在输出最终提示词之前,在你的内部思维中进行一次自我审视。检查最终的提示词是否完全符合所有黄金法则,是否清晰、无歧义、并且足够强大以激活目标LLM的特定能力。
</step>
<step id="4" name="Deliver_the_Prompt">
将最终生成的专业提示词交付给我。
</step>
</plan>
# Output_Format: How to Present the Final Prompt
你的输出应只包含提示词部分,不输出多余的解释:
**专业提示词成品 (The Final Prompt)**:
将最终生成的、可直接复制使用的提示词,放在一个带有“专业提示词”标题的Markdown代码块中。
创建一个ai agent节点的工作流,使用deepseek模型
将这段提示词给到一个新建的工作流的 AI-agent 节点的 system-message 中,像这样:
接下来,测试以下这个工作流
看看效果还是比较ok的。
接下来给他个code节点提取提示词部分,其实也可以直接在提示词里说明让他只给出提示词成品,但ai难免有幻觉,还是通过代码进行提取的方式比较可靠一些。
// 获取上一个节点(AI Agent)的输出结果
const items = $input.all();
// 遍历所有输入项(通常只有一个)
for (const item of items) {
// 1. 获取 AI Agent 输出的完整文本
// !!! 注意: 这里的 'text' 是一个假设的字段名。
// 你需要根据上一个节点的实际输出来确认。通常可能是 'text', 'content', 或 'message'。
// 请在AI Agent节点的OUTPUT视图中,切换到JSON格式查看确认。
const aiOutput = item.json.text;
// 检查 aiOutput 是否存在且为字符串,防止出错
if (typeof aiOutput !== 'string') {
// 如果没有文本,可以设置一个空值或直接跳过
item.json.extractedPrompt = '';
continue;
}
// 2. 使用正则表达式来匹配并提取 Markdown 代码块中的内容
// - ```markdown\n : 匹配开始的标记和换行符
// - ([\s\S]*?) : 匹配中间的所有内容(包括换行符),这是我们要提取的部分
// - \n``` : 匹配结束的标记
const regex = /```markdown\n([\s\S]*?)\n```/;
const match = aiOutput.match(regex);
// 3. 将提取到的内容(不带标记)存储到一个新的字段 'extractedPrompt' 中
// match[1] 代表正则表达式中第一个括号 (...) 捕获到的内容
if (match && match[1]) {
item.json.extractedPrompt = match[1].trim(); // .trim() 用于移除可能存在的前后多余空格
} else {
// 如果没有匹配到,则设置一个空字符串,方便后续节点处理
item.json.extractedPrompt = '';
}
}
// 4. 返回处理后的数据,现在每个 item 中都增加了一个 extractedPrompt 字段
return items;
这样,一个最基本的工作流就算完成了,右上角将他标记为活动
“提示词工程师”这个工作流现在是长这样:
制作mcp server
接下来,新建一个工作流
初始节点使用mcp server trigger这个节点
下方tools中添加call n8n workflow tool
三个重要的提示:
- 第一个是给了个example
- 第二个是要我们给一个描述,这个描述是用来告诉ai这个工具是什么适合用的
- 第三个提示告诉我们,被调度的工作流需要可以被调度
前两个比较好理解,第三个是什么意思?
意思是说,我们制作好的"提示词工程师"这个工作流必须是一个可调度的子工作流,这个子工作流的起始节点是一个sub-workflows trigger
trigger就是触发器
所以,我们要回到"提示词工程师"这个工作流中,把原来的chat trigger替换成sub-workflows trigger。
值得一提的是,AI Agent节点的入参也需要调整为从When Executed by Another Workflow节点输入,这样才能被正确执行。
最终,"提示词工程师"这个工作流就变成了这样
它现在是不能被调度的了。不需要开启活动(active)按钮,当他被唤醒,就会执行。
测试环节
接下来,我们就需要测试这个mcp server是否真的可用
新建一个常规的ai agent,不包含任何提示词,我们提需求,让他来调度工具生成提示词,看是否能符合我们的预期
可以看到是符合预期的,他确实去调用mcp server了,并且给了我们预期的结果,假如这时候点开这个工具的话,还可以看到deepseek的思考过程:
总结
这也许是你我都不曾想过的n8n的玩法。
用ai agent节点来打造一个会使用mcp工具的专业角色,再将这个角色封装成mcp server。让另一个ai agent去调度它完成一件事情。
假如我们再多创建多个角色,比如:"需求分析(任务分解)工程师"、"数据采集工程师"、"程序架构师"、"编码工程师"、"代码测试工程师"、"代码提交工程师"。 这么多个"工程师"都被封装成mcp,然后让最外层的AI-Agent调度他们,这样一个AI团队,角色清晰,分工明确,有条有理地执行着特定的任务。
等等...这难道不是manus?
看到这里如果觉得写的不错,拜托各位给个关注吧,这对我很重要。